<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Great!!! happy i could help!<div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 8, 2016, at 3:59 PM, Colin Morelli <<a href="mailto:colin.morelli@gmail.com" class="">colin.morelli@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Following up in case anyone else benefits from this -<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Thank you Michael for the pointers.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Colin</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, Jul 8, 2016 at 8:14 AM Colin Morelli <<a href="mailto:colin.morelli@gmail.com" class="">colin.morelli@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">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.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Thanks for the pointer Michael! I'll see if I can fix the signaling issue which should then resolve the rest of the problems.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Colin</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, Jul 8, 2016 at 2:07 AM Michael Jerris <<a href="mailto:mike@jerris.com" target="_blank" class="">mike@jerris.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">in may be only on media address change. You'd be looking on switch_core_media.c to find it<span class=""></span><div class=""><br class="">On Thursday, July 7, 2016, Colin Morelli <<a href="mailto:colin.morelli@gmail.com" target="_blank" class="">colin.morelli@gmail.com</a>> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">Hey all,<div class=""><br class=""></div><div class="">Reviving this thread just to see if anyone has thoughts here?</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Colin</div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, May 13, 2016 at 9:34 PM Colin Morelli <<a class="">colin.morelli@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">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:<div class=""><br class=""></div><div class="">2016-05-13 21:28:24.216684 [DEBUG] sofia.c:7614 Processing updated SDP<br class=""></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Thanks for the response.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Colin</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, May 13, 2016 at 9:14 PM Michael Jerris <<a class="">mike@jerris.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">we already re-open the auto adjust window on reinvite <span class=""></span><br class=""><br class="">On Friday, May 13, 2016, Colin Morelli <<a class="">colin.morelli@gmail.com</a>> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">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.<div class=""><br class=""></div><div class="">I've tried using the RTP ALWAYS_AUTO_ADJUST bug, but that results in <i class="">very</i> 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 <i class="">will</i> send a re-invite when its address changes. Is there any way to perform RTP audio adjust only on a re-invite?</div><div class=""><br class=""></div><div class="">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"</div><div class=""><br class=""></div><div class="">Would appreciate any help.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Colin</div></div></blockquote></blockquote></div></blockquote></div></div></blockquote></div></blockquote></div></blockquote></div></div></blockquote></div></div></body></html>