transfer to outside number (mobile) in DR fails

[landfiets]

Hi, is there anyone who got the transfer to outside number (mobile) running under DR?
When I dial the extension from the local network it transfers to outside number without a prob, but as soon as I put that one in DR it's not working.

This is the log:

Call::RouteFailed [CM503014]: Call(30): Attempt to reach [sip:[email protected]] failed. Reason: Not Registered

 

[landfiets]

Now I tried to register 2 phones officially and transfered the call when not picked up in 2 seconds to my mobile, and still transfer fails in DR

 

[zyonee]

I'm having the same problem, and that's the only reason I'm still sticking with version 3.1.2434.0 instead of 5.x. Here's a the part where it fails in 3CXPhoneSystem.log:

19:27:23.912|.\SLServer.cpp(381)|Log2|MediaServer|MediaServerReporting:TMFhandler:[MS211000] C:3.1: 62.80.200.53:64034 is delivering DTMF using RTP payload (RFC2833). In-Band DTMF tone detection is disabled for this call segment.
19:27:27.771|.\CallCtrl.cpp(210)|Log3||CallCtrl:nSelectRouteReq:[CM503010]: Making route(s) to <sip:[email protected]>
19:27:27.802|.\CallCtrl.cpp(286)|Log2||CallCtrl:nSelectRouteReq:[CM503004]: Call(3): Calling: VoIPline:10001@[Dev:sip:[username removed]@sip.VoipStunt.com:5060, Dev:sip:[username removed]@sip.VoipStunt.com:5060]
19:27:27.896|.\CallLeg.cpp(180)|Log2||CallLeg:nFailure:[CM503003]: Call(3): Call to sip:[number removed]@sip.VoipStunt.com:5060 has failed; Cause: 400 Bad request; from IP:194.120.0.198
19:27:28.037|.\CallLeg.cpp(180)|Log2||CallLeg:nFailure:[CM503003]: Call(3): Call to sip:[number removed]@sip.VoipStunt.com:5060 has failed; Cause: 400 Bad request; from IP:194.120.0.198
19:27:28.037|.\Call.cpp(426)|Log2||Call::RouteFailed:[CM503014]: Call(3): Attempt to reach <sip:[email protected]> failed. Reason: Reason Unknown
19:27:29.787|.\Line.cpp(298)|Log2||LineCfg::getInboundTarget:[CM503011]: Inbound out-of-office hours' rule for LN:10000 forwards to DN:800
19:27:29.802|.\Call.cpp(567)|Log2||Call::Terminate:[CM503008]: Call(3): Call is terminated


I removed telephone numbers and usernames for my SIP provider in the log excerpts. I should also add that this is working perfectly in version 3.1.2434.0 but not in any of the 5.x versions I've tried.

Also, different VOIP providers give different error messages. VoipStunt gives "Bad request", while Pennytel had something else (can't remember) - but the point is that it worked in 3.x. I would like to know if there's anything I can change in 5.x to make it act like the 3.x did in this situation.

Thanks in advance.

 

[zyonee]

It's been more than a week now. I (and probably others) sure would appreciate any comments from the 3xc team. Please help us with this issue.

 

[landfiets]

Hi,

Will this problem be solved soon? We still are waiting for news from the developers side.
I need my mobile to be called as soon as someone presses "7" in the DR

 

[eddietang]

This is the way I setup my DR to call my mobile which might work for you.

1. I have a primary DR anwsering my main line.

2. If caller press 7, I set my DR to transfer to my internal extention which is 519. If there is no pickup from my extension after 10 seconds , I divert the caller to a second DR which prompts the caller to press 1 to leave a voice mail for my mailbox 519 or 2 to transfer to my mobile.

3. If the caller presses 2, I divert the caller to a un-registered extension which has a rule that always calls an outside number (my mobile) on an un-registered status.

Hope this helps.

I am using v5.0 and am using 2 VoIP gateways being AudioCodes Mediant 2000 and AudioCodes MP-408.

 

[zyonee]

That's kind of the same setup I have, although I dial my DR and then key in the unregistered extensions directly instead of making shortcuts in the DR. However, it will still not work in 5.0 or 5.1 beta (tried in both). I get different error messages dependent on which voip provider I'm using:

Cellip (Swedish provider) gives me: 403 Do not use late offer-answer model
The Betamax services (VoipStunt, VoipCheap, VoipBuster and many more) gives me: 400 Bad request
Pennytel (Australian provider) gives me: 403 Do not use late offer-answer model

Now please note that this setup works without a hitch in v3.1, so it must be v5.0 and above that uses some other way of transferring the calls. I'd sure like to know either how to solve the problem or at least how to make v5.x act like v3.1 in this very situation. Any help would be greatly appreciated.

 

[eddietang]

Is your main line number attached to a VoIP gateway? If so you might just want to try for curiosity sake divert the caller to use your VoIP gateway instead of your VoIP service provider. See if that works.

 

[Hoover87]

Are you able to make the same outbound call with a registered extension, not going through the DR?

Put a sniffer (wireshark) on it and compare what is working against what is not working.

 

[Philco]

Do I take it that in the above the outside number is set in the extension config to 'always forward all calls to an outside number' if the extension is called, but in this case a mobile. Does it also fail if you forward to PSTN number?

I have a similar problem where I want to forward all calls to an extension to an outside number which is provided by a voip provider that doesnt support reinvite and all calls fail. If I use a sipgate number its fine it works fine.

I did post in this thread
http://www.3cx.com/forums/anyway-of-ignoring-sip-for-a-through-call-4158.html

and I suspect its the same problem.


I was told that there was a bug on the support reinvite issue in V5.0 and was fixed in V5.1 but I dont seem to see it has, or its just not working for me.

Phil

 

[zyonee]

Is your main line number attached to a VoIP gateway? If so you might just want to try for curiosity sake divert the caller to use your VoIP gateway instead of your VoIP service provider. See if that works.

Depends on what you mean by VoIP gateway. I've merely configured VoIP lines in 3CX with the SIP addresses to the various providers that I'm using, like for instance sip.voipcheap.com, etc. Same with Cellip, my incoming provider. Then I simply add a DR and some extensions that are always offline but always forwarded to an outside number.

Do I take it that in the above the outside number is set in the extension config to 'always forward all calls to an outside number' if the extension is called, but in this case a mobile. Does it also fail if you forward to PSTN number?

I have a similar problem where I want to forward all calls to an extension to an outside number which is provided by a voip provider that doesnt support reinvite and all calls fail. If I use a sipgate number its fine it works fine.

As far as I can remember, I've tried it on both mobiles and PSTN numbers, both fail in v5.x but not in v3.x. I'll have to try sniffing the network traffic at some point, but right now, I'm too tired to go through backing up the config, upgrading, deinstalling, etc. One thing is for sure; that v3.x and v5.x don't handle the call transfer the same way. I've even tried turning off the support for reinvite, etc. in v5.0 and v5.1, but still the same error appears.

 

[Philco]

Well I guess your voip providers like the main one I use (voip.co.uk) dont support reinvite, but worked ok in 3.1.

As I have mentioned sipgate works.


We'll await a resonse..


Phil

 

[zyonee]

Ok, so I used wireshark to sniff the network traffic. Here's the difference in how the call transfer works in v3.1 and v5.1. I've removed my own IP address and all the phone numbers for obvious reasons. If anyone wants a detailed wireshark dump, let me know and I can e-mail it or something.

In version 3.1.x:
-----------------
Cellip -> 3CX: Request: INVITE sip:incoming number@my IP address:5060;rinstance=825a98534c499763
3CX -> Cellip: Status: 100 Trying
3CX -> Cellip: Status: 200 OK
Cellip -> 3CX: Request: ACK sip:incoming number@my IP address:5060
3CX -> VS: Request: INVITE sip:recepient number@sip.VoipStunt:5060
VS -> 3CX: Status: 401 Unauthorized
3CX -> VS: Request: ACK sip:recepient number@sip.VoipStunt.com:5060
3CX -> VS: Request: INVITE sip:recepient number@sip.VoipStunt:5060
VS -> 3CX: Status: 100 Trying
VS -> 3CX: Status: 183 Session progresss
VS -> 3CX: Status: 200 OK
3CX -> VS: Request: ACK sip:recepient number@194.120.0.198:5060
(call is in progress here)
Cellip -> 3CX: Request: BYE sip:recepient number@195.198.25.42:5060
3CX -> Cellip: Status: 200 OK
3CX -> VS: Request: BYE sip:recepient number@194.120.0.198:5060
VS -> 3CX: Status: 200 OK


In version 5.1.x:
-----------------
Cellip -> 3CX: Request: INVITE sip:incoming number@my IP address:5060;rinstance=270c4663b530cb7e
3CX -> Cellip: Status: 180 Ringing
Cellip -> 3CX: Request: ACK sip:my IP address:5060
3CX -> VS: Request: INVITE sip:recepient number@sip.VoipStunt.com:5050
VS -> 3CX: Status: 400 Bad request
3CX -> VS: Request ACK: sip:recepient number@sip.VoipStunt.com:5050
Cellip -> 3CX: Request: BYE sip:my IP address:5060
3CX -> Cellip: Status: 200 OK

Let me know if there's anything more you want to know. I'm off to uninstalling 5.1 ans reinstalling/restoring 3.1 now...

 

[zyonee]

So I guess there's no real solution to this problem yet? The updates that have been released so far haven't helped my case.

 

[Philco]

Lets hope they are working on it.

At the moment, in our test set up utilising the outgoing rules, we have calls to outside numbers that are keyed from a phone going via one provider and our diverts/external transfers are being sent via Sipgate. Not ideal but seems to work.


Phil

 

[archie]

First, thank you for input.

In version 5.1.x:
-----------------
Cellip -> 3CX: Request: INVITE sip:incoming number@my IP address:5060;rinstance=270c4663b530cb7e
3CX -> Cellip: Status: 180 Ringing
Cellip -> 3CX: Request: ACK sip:my IP address:5060

Here we have a problem which is not 3CX I suppose: Cellip sends ACK without having 200 OK response. It's completely wrong.

3CX -> VS: Request: INVITE sip:recepient number@sip.VoipStunt.com:5050
VS -> 3CX: Status: 400 Bad request

Here we should see our INVITE and 400 response bodies to understand what VS doesn't like. OR we can compare v5.1 INVITE with one generated by v3.1 to find the difference.

 

[zyonee]

Ok, so here are the INVITE bodies from 3.1 and 5.1:

3.1:
INVITE sip:recepient number@sip.VoipStunt.com:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.254:5060;branch=z9hG4bK-d87543-b92cc543b9519762-1--d87543-;rport
Max-Forwards: 70
Contact: <sip:zyonee@my ip address:5060>
To: "recepient number"<sip:recepient number@sip.VoipStunt.com:5060>
From: "incoming number"<sip:[email protected]>;tag=4f75e820
Call-ID: MjY3NTI4YzAzNmVjZjg2MjkzMTY2NjU3ODBhZDhiYTA.
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO
Content-Type: application/sdp
User-Agent: 3CXPhoneSystem
Authorization: Digest username="zyonee",realm="sip.VoipStunt.com",nonce="3368774517",uri="sip:recepient number@sip.VoipStunt.com:5060",response="342240e9eae880ff2acee1829c2e4d02",algorithm=MD5
Content-Length: 249

5.1:
INVITE sip:recepient number@sip.VoipStunt.com:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.254:5060;branch=z9hG4bK-d87543-834e3875a03d8c07-1--d87543-;rport
Max-Forwards: 70
Contact: <sip:zyonee@my ip address:5060>
To: <sip:recepient number@sip.VoipStunt.com:5060>
From: "incoming number"<sip:[email protected]:5060>;tag=40310a61
Call-ID: NDUwZmI1NmFjMDk2NzdhZGFhY2FlN2YwOWFmZmNhN2E.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO
User-Agent: 3CXPhoneSystem 5.1.4078.0
Content-Length: 0

and the 400 body in 5.1:

SIP/2.0 400 Bad request
Via: SIP/2.0/UDP 192.168.0.254:5060;branch=z9hG4bK-d87543-834e3875a03d8c07-1--d87543-;rport
From: "incoming number" <sip:[email protected]:5060>;tag=40310a61
To: <sip:recepient number@sip.VoipStunt.com:5060>
Contact: sip:recepient number@194.120.0.198:5060
Call-ID: NDUwZmI1NmFjMDk2NzdhZGFhY2FlN2YwOWFmZmNhN2E.
CSeq: 1 INVITE
Server: (Very nice Sip Registrar/Proxy Server)
Allow: ACKBYE,CANCEL,INVITE,REGISTER,OPTIONS,INFO,MESSAGE
Content-Length: 0

I hope this is the information that you wanted to see. If you want them, I have wireshark tcp dumps that I could send you. I don't know why Cellip doesn't wait for a 200 OK response before requesting ACK. Is there any way to work around this? Exactly why does that cause any problem, anyway?

 

[archie]

I hope this is the information that you wanted to see. If you want them, I have wireshark tcp dumps that I could send you. I don't know why Cellip doesn't wait for a 200 OK response before requesting ACK. Is there any way to work around this? Exactly why does that cause any problem, anyway?

Yes, it's all clear now. VoipStunt just doesn't fully comply to RFC 3264, that is why it is not 3CX supported provider and that is why it doesn't work properly with v5.1.
In v5.1 we decided to do NOT workarounds for non-standard devices/providers. Either they will eventually obey standards, or we don't want to work with them. We don't want to increase entropy. Sepcificly, VoipStunt doesn't accept INVITE without SDP. It is their problem then, not ours.

Re 200/ACK - it's also standard defined feature (RFC3261). ACK must acknowledge final responses. Final responses has response code >= 200. It means one shouldn't acknowledge provisional responses (18x), beacuse it breaks a standard flow.

 

[Philco]

Archie, so do I take it that even with reinvite off it is not possible to transfer to an outside number when a voip provider being used does not support reinvite?

It would be nice to be able to transfer a call to an outiside number via a none supported provider. Interesting you can assign an extension number to always forward to an outside number via a none supported provider, but you cant transfer.

Phil

 

[archie]

It is NOT reinvite. It is first INVITE, but without SDP. In case of blind transfer we can not make a SDP to offer, because we already have some negotiated codecs set in the first call. So we should ask for offer from third party (one we're going to transfer to) and use it as a start point for new codecs negotiation. By the way, in your case you're still able to make ATTENDED transfer, because it intiates new separated call.