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@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@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