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

[Michael Jerris]

Great!!! happy i could help!


> On Jul 8, 2016, at 3:59 PM, Colin Morelli <colin.morelli at gmail.com> wrote:
> 
> 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 <mailto: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 <mailto: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 <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20160708/e83fb622/attachment-0001.html