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@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@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@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@jerris.com> wrote:
we already re-open the auto adjust window on reinvite 

On Friday, May 13, 2016, Colin Morelli <colin.morelli@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@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@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@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@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org