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