Incoming call from registered gateway with DID in To: not URI
Hi everyone, I have a gateway registering to numbergroup.com, this is the configuration: <gateway name="numbergroup"> <param name="realm" value="sip.numbergroup-services.com"/> <param name="username" value="XXXXXX"/> <param name="password" value="XXXXXX"/> <param name="register" value="true"/> <param name="extension-in-contact" value="true"/> <param name="caller-id-in-from" value="true"/> <param name="ping" value="60"/> <param name="ping-max" value="10"/> <param name="ping-min" value="1"/> <param name="retry-seconds" value="5"/> <param name="expire-seconds" value="60"/> </gateway> Incoming calls from my DID to a SIP URI on the server work fine. However I'm having problems sending it to the SIP Trunk (the registration above). The call arrives on the server fine, but the URI is the username@sip.numbergroup-services.com. The DID is in the To: header destination_number in the dialplan is the username not the DID as a result. Does anyone know how to configure the gateway so that the destination_number would contain the DID from the To header instead? Here's the INVITE: INVITE sip:username@81.27.101.246:5060;transport=udp;gw=numbergroup SIP/2.0 Via: SIP/2.0/UDP 80.93.165.111;rport;branch=z9hG4bKD4m88SNemDSBg Max-Forwards: 65 From: "+myphonenumber" <sip:+myphonenumber@80.93.165.111>;tag=y9DBpB33yBHNN To: <sip:+mydidnumber@sip.numbergroup-services.com> Call-ID: 9ee8ce2d-9544-122e-c2a7-002655d1d302 CSeq: 6881084 INVITE Contact: <sip:numbergroup@80.93.165.111:5060> User-Agent: numbergroup.com Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Allow-Events: talk, hold, refer Session-Expires: 900 Min-SE: 90 Privacy: none Content-Type: application/sdp Content-Disposition: session Content-Length: 593 P-Charging-Vector: icid-value=f4571a9c-1aa1-11e0-8310-5798bfd3ad89;icid-generated-at=80.93.165.110;orig-ioi=numbergroup.com P-Asserted-Identity: "+myphonenumber" <sip:+myphonenumber@80.93.165.111> v=0 o=numbergroup 1294416066 1294416067 IN IP4 80.93.165.111 s=numbergroup c=IN IP4 80.93.165.111 t=0 0 m=audio 18230 RTP/AVP 8 9 98 3 18 99 100 101 102 103 104 0 105 101 13 a=rtpmap:98 G7221/32000 a=fmtp:98 bitrate=48000 a=rtpmap:99 SPEEX/8000 a=rtpmap:100 iLBC/8000 a=fmtp:100 mode=20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:102 G726-24/8000 a=rtpmap:103 G726-32/8000 a=rtpmap:104 G726-40/8000 a=rtpmap:105 CELT/48000 m=video 18540 RTP/AVP 106 107 34 31 a=rtpmap:106 THEORA/90000 a=rtpmap:107 H264/90000 a=rtpmap:34 H263/90000 a=rtpmap:31 H261/90000 -Steve
I'm currently handling it with: <param name="context" value="numbergroup"/> and: <context name="numbergroup"> <extension name="numbergroup"> <condition field="destination_number" expression="^USERNAME$"> <action application="transfer" data="${sip_to_user} XML default"/> </condition> </extension> </context> Is there a better way of handling it? Such as a param that tells Sofia to use the To not the URI to populate destination_number? -Steve On 7 January 2011 21:08, Steven Ayre <steveayre@gmail.com> wrote:
Hi everyone,
I have a gateway registering to numbergroup.com, this is the configuration:
<gateway name="numbergroup"> <param name="realm" value="sip.numbergroup-services.com"/> <param name="username" value="XXXXXX"/> <param name="password" value="XXXXXX"/> <param name="register" value="true"/> <param name="extension-in-contact" value="true"/> <param name="caller-id-in-from" value="true"/> <param name="ping" value="60"/> <param name="ping-max" value="10"/> <param name="ping-min" value="1"/> <param name="retry-seconds" value="5"/> <param name="expire-seconds" value="60"/> </gateway>
Incoming calls from my DID to a SIP URI on the server work fine. However I'm having problems sending it to the SIP Trunk (the registration above).
The call arrives on the server fine, but the URI is the username@sip.numbergroup-services.com. The DID is in the To: header
destination_number in the dialplan is the username not the DID as a result. Does anyone know how to configure the gateway so that the destination_number would contain the DID from the To header instead?
Here's the INVITE:
INVITE sip:username@81.27.101.246:5060;transport=udp;gw=numbergroup SIP/2.0 Via: SIP/2.0/UDP 80.93.165.111;rport;branch=z9hG4bKD4m88SNemDSBg Max-Forwards: 65 From: "+myphonenumber" <sip:+myphonenumber@80.93.165.111>;tag=y9DBpB33yBHNN To: <sip:+mydidnumber@sip.numbergroup-services.com> Call-ID: 9ee8ce2d-9544-122e-c2a7-002655d1d302 CSeq: 6881084 INVITE Contact: <sip:numbergroup@80.93.165.111:5060> User-Agent: numbergroup.com Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Allow-Events: talk, hold, refer Session-Expires: 900 Min-SE: 90 Privacy: none Content-Type: application/sdp Content-Disposition: session Content-Length: 593 P-Charging-Vector: icid-value=f4571a9c-1aa1-11e0-8310-5798bfd3ad89;icid-generated-at=80.93.165.110;orig-ioi=numbergroup.com P-Asserted-Identity: "+myphonenumber" <sip:+myphonenumber@80.93.165.111>
v=0 o=numbergroup 1294416066 1294416067 IN IP4 80.93.165.111 s=numbergroup c=IN IP4 80.93.165.111 t=0 0 m=audio 18230 RTP/AVP 8 9 98 3 18 99 100 101 102 103 104 0 105 101 13 a=rtpmap:98 G7221/32000 a=fmtp:98 bitrate=48000 a=rtpmap:99 SPEEX/8000 a=rtpmap:100 iLBC/8000 a=fmtp:100 mode=20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:102 G726-24/8000 a=rtpmap:103 G726-32/8000 a=rtpmap:104 G726-40/8000 a=rtpmap:105 CELT/48000 m=video 18540 RTP/AVP 106 107 34 31 a=rtpmap:106 THEORA/90000 a=rtpmap:107 H264/90000 a=rtpmap:34 H263/90000 a=rtpmap:31 H261/90000
-Steve
update to the latest code this was fixed yesterday. Broken the day before that. /b On Jan 7, 2011, at 5:24 PM, Steven Ayre wrote:
I'm currently handling it with:
<param name="context" value="numbergroup"/>
and:
<context name="numbergroup"> <extension name="numbergroup"> <condition field="destination_number" expression="^USERNAME$"> <action application="transfer" data="${sip_to_user} XML default"/> </condition> </extension> </context>
Is there a better way of handling it? Such as a param that tells Sofia to use the To not the URI to populate destination_number?
-Steve
Thanks Brian. :) Steve on iPhone On 8 Jan 2011, at 02:50, Brian West <brian@freeswitch.org> wrote:
update to the latest code this was fixed yesterday. Broken the day before that.
/b
On Jan 7, 2011, at 5:24 PM, Steven Ayre wrote:
I'm currently handling it with:
<param name="context" value="numbergroup"/>
and:
<context name="numbergroup"> <extension name="numbergroup"> <condition field="destination_number" expression="^USERNAME$"> <action application="transfer" data="${sip_to_user} XML default"/> </condition> </extension> </context>
Is there a better way of handling it? Such as a param that tells Sofia to use the To not the URI to populate destination_number?
-Steve
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Also if you set the extension to auto_to_user it'll do it also. /b On Jan 7, 2011, at 5:24 PM, Steven Ayre wrote:
I'm currently handling it with:
<param name="context" value="numbergroup"/>
and:
<context name="numbergroup"> <extension name="numbergroup"> <condition field="destination_number" expression="^USERNAME$"> <action application="transfer" data="${sip_to_user} XML default"/> </condition> </extension> </context>
Is there a better way of handling it? Such as a param that tells Sofia to use the To not the URI to populate destination_number?
-Steve
<param name="extension" value="auto_to_user"/> was what did the trick though. Thanks! :) There's a minor issue from it where the trunk shows unregistered on their website (they expect the Contact header to be username@ip") but incoming calls are still sent through fine so it doesn't actually matter at all. They can still see FS registered on their switch. I've added the configuration to the SIP Provider Examples section of the Wiki. One of their guys said by email they tested on Git within the last few weeks and found calls were hanging up after 2m40s due to something about how we handle timers... I'm going to test that next. Were there any versions in Git recently that might have had problems? -Steve On 8 January 2011 02:50, Brian West <brian@freeswitch.org> wrote:
Also if you set the extension to auto_to_user it'll do it also.
/b
On Jan 7, 2011, at 5:24 PM, Steven Ayre wrote:
I'm currently handling it with:
<param name="context" value="numbergroup"/>
and:
<context name="numbergroup"> <extension name="numbergroup"> <condition field="destination_number" expression="^USERNAME$"> <action application="transfer" data="${sip_to_user} XML default"/> </condition> </extension> </context>
Is there a better way of handling it? Such as a param that tells Sofia to use the To not the URI to populate destination_number?
-Steve
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
One of their guys said by email they tested on Git within the last few weeks and found calls were hanging up after 2m40s due to something about how we handle timers... I'm going to test that next. Were there any versions in Git recently that might have had problems?
There does appear to be an issue here. Calls of 4mins duration with no problems with enable-timer=false With enable-timer=true the call times out. The reason is they send an INVITE and we reply 400 Bad Session Description. http://pastebin.freeswitch.org/14957 shows those two packets. -Steve On 8 January 2011 15:56, Steven Ayre <steveayre@gmail.com> wrote:
<param name="extension" value="auto_to_user"/> was what did the trick though. Thanks! :)
There's a minor issue from it where the trunk shows unregistered on their website (they expect the Contact header to be username@ip") but incoming calls are still sent through fine so it doesn't actually matter at all. They can still see FS registered on their switch.
I've added the configuration to the SIP Provider Examples section of the Wiki.
One of their guys said by email they tested on Git within the last few weeks and found calls were hanging up after 2m40s due to something about how we handle timers... I'm going to test that next. Were there any versions in Git recently that might have had problems?
-Steve
On 8 January 2011 02:50, Brian West <brian@freeswitch.org> wrote:
Also if you set the extension to auto_to_user it'll do it also.
/b
On Jan 7, 2011, at 5:24 PM, Steven Ayre wrote:
I'm currently handling it with:
<param name="context" value="numbergroup"/>
and:
<context name="numbergroup"> <extension name="numbergroup"> <condition field="destination_number" expression="^USERNAME$"> <action application="transfer" data="${sip_to_user} XML default"/> </condition> </extension> </context>
Is there a better way of handling it? Such as a param that tells Sofia to use the To not the URI to populate destination_number?
-Steve
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
From the source code it looks like that means the SDP is invalid - do you see the problem in those packet traces?
Warm Regards, -Steve On 8 January 2011 16:08, Steven Ayre <steveayre@gmail.com> wrote:
One of their guys said by email they tested on Git within the last few weeks and found calls were hanging up after 2m40s due to something about how we handle timers... I'm going to test that next. Were there any versions in Git recently that might have had problems?
There does appear to be an issue here.
Calls of 4mins duration with no problems with enable-timer=false
With enable-timer=true the call times out. The reason is they send an INVITE and we reply 400 Bad Session Description. http://pastebin.freeswitch.org/14957 shows those two packets.
-Steve
On 8 January 2011 15:56, Steven Ayre <steveayre@gmail.com> wrote:
<param name="extension" value="auto_to_user"/> was what did the trick though. Thanks! :)
There's a minor issue from it where the trunk shows unregistered on their website (they expect the Contact header to be username@ip") but incoming calls are still sent through fine so it doesn't actually matter at all. They can still see FS registered on their switch.
I've added the configuration to the SIP Provider Examples section of the Wiki.
One of their guys said by email they tested on Git within the last few weeks and found calls were hanging up after 2m40s due to something about how we handle timers... I'm going to test that next. Were there any versions in Git recently that might have had problems?
-Steve
On 8 January 2011 02:50, Brian West <brian@freeswitch.org> wrote:
Also if you set the extension to auto_to_user it'll do it also.
/b
On Jan 7, 2011, at 5:24 PM, Steven Ayre wrote:
I'm currently handling it with:
<param name="context" value="numbergroup"/>
and:
<context name="numbergroup"> <extension name="numbergroup"> <condition field="destination_number" expression="^USERNAME$"> <action application="transfer" data="${sip_to_user} XML default"/> </condition> </extension> </context>
Is there a better way of handling it? Such as a param that tells Sofia to use the To not the URI to populate destination_number?
-Steve
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Sofia debugging shows this if it helps identify the problem at all: nta: INVITE (6915472) going to existing leg nta: timer shortened to 200 ms nua: nua_stack_process_request: entering soa_init_offer_answer(static::0x2346220) called soa_set_remote_sdp(static::0x2346220, (nil), 0x233a90e, 521) called nua(0x22f3260): INVITE server: error parsing SDP nua: nua_invite_server_respond: entering soa_clear_remote_sdp(static::0x2346220) called tport_tsend(0x23720e0) tpn = UDP/80.93.165.111:5060 tport_resolve addrinfo = 80.93.165.111:5060 tport_by_addrinfo(0x23720e0): not found by name UDP/80.93.165.111:5060 tport_vsend(0x23720e0): 572 bytes of 572 to udp/80.93.165.111:5060 tport_vsend returned 572 nta: sent 400 Bad Session Description for INVITE (6915472) -Steve On 8 January 2011 16:11, Steven Ayre <steveayre@gmail.com> wrote:
From the source code it looks like that means the SDP is invalid - do you see the problem in those packet traces?
Warm Regards, -Steve
On 8 January 2011 16:08, Steven Ayre <steveayre@gmail.com> wrote:
One of their guys said by email they tested on Git within the last few weeks and found calls were hanging up after 2m40s due to something about how we handle timers... I'm going to test that next. Were there any versions in Git recently that might have had problems?
There does appear to be an issue here.
Calls of 4mins duration with no problems with enable-timer=false
With enable-timer=true the call times out. The reason is they send an INVITE and we reply 400 Bad Session Description. http://pastebin.freeswitch.org/14957 shows those two packets.
-Steve
On 8 January 2011 15:56, Steven Ayre <steveayre@gmail.com> wrote:
<param name="extension" value="auto_to_user"/> was what did the trick though. Thanks! :)
There's a minor issue from it where the trunk shows unregistered on their website (they expect the Contact header to be username@ip") but incoming calls are still sent through fine so it doesn't actually matter at all. They can still see FS registered on their switch.
I've added the configuration to the SIP Provider Examples section of the Wiki.
One of their guys said by email they tested on Git within the last few weeks and found calls were hanging up after 2m40s due to something about how we handle timers... I'm going to test that next. Were there any versions in Git recently that might have had problems?
-Steve
On 8 January 2011 02:50, Brian West <brian@freeswitch.org> wrote:
Also if you set the extension to auto_to_user it'll do it also.
/b
On Jan 7, 2011, at 5:24 PM, Steven Ayre wrote:
I'm currently handling it with:
<param name="context" value="numbergroup"/>
and:
<context name="numbergroup"> <extension name="numbergroup"> <condition field="destination_number" expression="^USERNAME$"> <action application="transfer" data="${sip_to_user} XML default"/> </condition> </extension> </context>
Is there a better way of handling it? Such as a param that tells Sofia to use the To not the URI to populate destination_number?
-Steve
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Trying to reproduce this, and found it happens on every call. The INVITE: http://pastebin.freeswitch.org/14958 The reINVITE: http://pastebin.freeswitch.org/14959 Full packet trace: http://pastebin.freeswitch.org/14960 I'm pretty sure there's a problem in the SDP they're sending in the reINVITE. It's different from the SDP in the first invite. The only part of the reINVITE that stands out as looking odd to me is this line: a=rtpmap:96 /0 Would that make the Sofia SDP parser fail? 96 isn't a payload number they offer in the initial INVITE, or that we offer in the 200 OK, so I don't know where that number shows up from. Warm regards, -Steve On 8 January 2011 16:32, Steven Ayre <steveayre@gmail.com> wrote:
Sofia debugging shows this if it helps identify the problem at all:
nta: INVITE (6915472) going to existing leg nta: timer shortened to 200 ms nua: nua_stack_process_request: entering soa_init_offer_answer(static::0x2346220) called soa_set_remote_sdp(static::0x2346220, (nil), 0x233a90e, 521) called nua(0x22f3260): INVITE server: error parsing SDP nua: nua_invite_server_respond: entering soa_clear_remote_sdp(static::0x2346220) called tport_tsend(0x23720e0) tpn = UDP/80.93.165.111:5060 tport_resolve addrinfo = 80.93.165.111:5060 tport_by_addrinfo(0x23720e0): not found by name UDP/80.93.165.111:5060 tport_vsend(0x23720e0): 572 bytes of 572 to udp/80.93.165.111:5060 tport_vsend returned 572 nta: sent 400 Bad Session Description for INVITE (6915472)
-Steve
On 8 January 2011 16:11, Steven Ayre <steveayre@gmail.com> wrote:
From the source code it looks like that means the SDP is invalid - do you see the problem in those packet traces?
Warm Regards, -Steve
On 8 January 2011 16:08, Steven Ayre <steveayre@gmail.com> wrote:
One of their guys said by email they tested on Git within the last few weeks and found calls were hanging up after 2m40s due to something about how we handle timers... I'm going to test that next. Were there any versions in Git recently that might have had problems?
There does appear to be an issue here.
Calls of 4mins duration with no problems with enable-timer=false
With enable-timer=true the call times out. The reason is they send an INVITE and we reply 400 Bad Session Description. http://pastebin.freeswitch.org/14957 shows those two packets.
-Steve
On 8 January 2011 15:56, Steven Ayre <steveayre@gmail.com> wrote:
<param name="extension" value="auto_to_user"/> was what did the trick though. Thanks! :)
There's a minor issue from it where the trunk shows unregistered on their website (they expect the Contact header to be username@ip") but incoming calls are still sent through fine so it doesn't actually matter at all. They can still see FS registered on their switch.
I've added the configuration to the SIP Provider Examples section of the Wiki.
One of their guys said by email they tested on Git within the last few weeks and found calls were hanging up after 2m40s due to something about how we handle timers... I'm going to test that next. Were there any versions in Git recently that might have had problems?
-Steve
On 8 January 2011 02:50, Brian West <brian@freeswitch.org> wrote:
Also if you set the extension to auto_to_user it'll do it also.
/b
On Jan 7, 2011, at 5:24 PM, Steven Ayre wrote:
I'm currently handling it with:
<param name="context" value="numbergroup"/>
and:
<context name="numbergroup"> <extension name="numbergroup"> <condition field="destination_number" expression="^USERNAME$"> <action application="transfer" data="${sip_to_user} XML default"/> </condition> </extension> </context>
Is there a better way of handling it? Such as a param that tells Sofia to use the To not the URI to populate destination_number?
-Steve
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (2)
-
Brian West
-
Steven Ayre