[Freeswitch-users] Incoming call from registered gateway with DID in To: not URI

[Steven Ayre]

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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.freeswitch.org
>>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>>>> http://www.freeswitch.org
>>>>>
>>>>
>>>
>>
>