[Freeswitch-users] Update RTP Address On Re-Invite

[Colin Morelli]

Following up in case anyone else benefits from this -

After fixing the client to properly create new transports over the correct
interface, Kamailio successfully rewrites the SDP using proper IP/port
information, FS detects the changes, auto-adjust opens, and everything
works as expected.

Thank you Michael for the pointers.

Best,
Colin

On Fri, Jul 8, 2016 at 8:14 AM Colin Morelli <colin.morelli at gmail.com>
wrote:

> Aha, thank you! That was helpful - I was able to see what you're referring
> to. It does look like its only on IP address change.
>
> And, that just led me to the second issue, which is that on the client
> device the TLS transports aren't being recreated over the new interface so
> the external IP stays the same for signaling requests, which means Kamailio
> rewrites the same external IP in the SDP. Which means FS doesn't re-enable
> auto-adjust.
>
> Thanks for the pointer Michael! I'll see if I can fix the signaling issue
> which should then resolve the rest of the problems.
>
> Best,
> Colin
>
> On Fri, Jul 8, 2016 at 2:07 AM Michael Jerris <mike at jerris.com> wrote:
>
>> in may be only on media address change.  You'd be looking on
>> switch_core_media.c to find it
>>
>> On Thursday, July 7, 2016, Colin Morelli <colin.morelli at gmail.com> wrote:
>>
>>> Hey all,
>>>
>>> Reviving this thread just to see if anyone has thoughts here?
>>>
>>> I've tried digging through the source and can't seem to find where the
>>> re-opening of auto_adjust happens during a re-invite. As an aside bug (I'll
>>> report in JIRA) - it looks like the always_auto_adjust RTP bug results in
>>> very choppy audio.
>>>
>>> That said, I don't need always_auto_adjust, as I'm fine with sending a
>>> re-invite when I need this to happen. It just doesn't seem to be working.
>>> Is there something else that needs to be set or is this also a bug?
>>>
>>> Best,
>>> Colin
>>>
>>> On Fri, May 13, 2016 at 9:34 PM Colin Morelli <colin.morelli at gmail.com>
>>> wrote:
>>>
>>>> Is this the case even when the RTP IP in the SDP doesn't change? I'm
>>>> seeing successful re-invites being processed with no auto adjust happening
>>>> afterwards. I see:
>>>>
>>>> 2016-05-13 21:28:24.216684 [DEBUG] sofia.c:7614 Processing updated SDP
>>>>
>>>> Indicating that FS did receive the SDP in the re-invite but nothing
>>>> else about RTP auto adjust afterwards. This is on FreeSWITCH Version
>>>> 1.6.7-14-d38d065~64bit (-14-d38d065 64bit) running on Debian 8 x86_64.
>>>>
>>>> Thanks for the response.
>>>>
>>>> Best,
>>>> Colin
>>>>
>>>> On Fri, May 13, 2016 at 9:14 PM Michael Jerris <mike at jerris.com> wrote:
>>>>
>>>>> we already re-open the auto adjust window on reinvite
>>>>>
>>>>> On Friday, May 13, 2016, Colin Morelli <colin.morelli at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I have mobile applications running behind NAT. When their
>>>>>> reachability changes (and the device's local route updates), I want to
>>>>>> automatically switch the RTP stream to the new address/port combination.
>>>>>>
>>>>>> I've tried using the RTP ALWAYS_AUTO_ADJUST bug, but that results in
>>>>>> *very* choppy audio. I also don't really need it, as the only time I
>>>>>> care to perform RTP auto-adjust is after an invite session. For this case I
>>>>>> can safely assume that the client *will* send a re-invite when its
>>>>>> address changes. Is there any way to perform RTP audio adjust only on a
>>>>>> re-invite?
>>>>>>
>>>>>> Using STUN doesn't seem right for two reasons: 1) on its own it can't
>>>>>> solve this problem (even if it determines the external IP, the port is
>>>>>> still wrong). 2) it results in issues on FS "Invalid STUN/ICE packet
>>>>>> received 20 bytes"
>>>>>>
>>>>>> Would appreciate any help.
>>>>>>
>>>>>> Best,
>>>>>> Colin
>>>>>>
>>>>>
>>>>> _________________________________________________________________________
>>>>> Professional FreeSWITCH Consulting Services:
>>>>> consulting at freeswitch.org
>>>>> http://www.freeswitchsolutions.com
>>>>>
>>>>> Official FreeSWITCH Sites
>>>>> http://www.freeswitch.org
>>>>> http://confluence.freeswitch.org
>>>>> http://www.cluecon.com
>>>>>
>>>>> 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
>>>>
>>>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://confluence.freeswitch.org
>> http://www.cluecon.com
>>
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20160708/b8a8460e/attachment.html