<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I was responding to the original question from Andrew.<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 13, 2017, at 4:09 AM, Dmitriy Borisov <<a href="mailto:borik.internet@gmail.com" class="">borik.internet@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><p dir="ltr" class="">Hi!</p><p dir="ltr" class="">Logic in your code conflict with your words. When sip_unhold_nosdp is set, FreeSWITCH replies with 200 OK with SDP a=sendrecv. After that other party replies with ACK with SDP a=sendrecv FreeSWITCH does NOT unhold a channel after receiving this ACK. This is an issue, I think</p>
<br class=""><div class="gmail_quote"><div dir="ltr" class="">вс, 13 авг. 2017 г., 10:41 Michael Jerris <<a href="mailto:mike@jerris.com" class="">mike@jerris.com</a>>:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">There is nothing to fix. A re-invite w/o an sip does not modify the media session and does not take a call off hold. If someone thinks that it is, they misunderstand how sip and sdp work.</div><div style="word-wrap:break-word" class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 12, 2017, at 7:16 PM, Dmitriy Borisov <<a href="mailto:borik.internet@gmail.com" target="_blank" class="">borik.internet@gmail.com</a>> wrote:</div><br class="m_4979663919512581248Apple-interchange-newline"><div class=""><p dir="ltr" class="">Hello!</p><p dir="ltr" class="">I'm sorry, but it is not fixed now. Not for 1.6 nor master. There are some code used sip_unhold_nosdp channel variable, but in my situation channel state not changed on FreeSWITCH side (FreeSWITCH showing channel in HOLD state and not originating RTP to other side). I made a push request with little patch (<a href="https://freeswitch.org/stash/projects/FS/repos/freeswitch/pull-requests/1362/overview" target="_blank" class="">https://freeswitch.org/stash/projects/FS/repos/freeswitch/pull-requests/1362/overview</a>) to fix the issue, but it not reviewed for now.</p><p dir="ltr" class="">Also I see discussion of Anthony with reporter in issue FS-9378 <a href="https://freeswitch.org/jira/plugins/servlet/mobile#issue/FS-9378" target="_blank" class="">https://freeswitch.org/jira/plugins/servlet/mobile#issue/FS-9378</a>, but there some incorrection: FreeSWITCH do correct (as I know this protocol) SDP negotiation, but it is not unhold the session. It resulted in HOLDED state of channel on FreeSWITCH side and unholded state of call on other side.</p><p dir="ltr" class="">And yes, this issue on broadsoft PBX too...</p>
<br class=""><div class="gmail_quote"><div dir="ltr" class="">пт, 11 авг. 2017 г., 20:13 Brian West <<a href="mailto:brian@freeswitch.org" target="_blank" class="">brian@freeswitch.org</a>>:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><div dir="auto" class="">Fixed in 1.6</div></div><div class=""><br class=""><div class="gmail_quote"><div class="">On Fri, Aug 11, 2017 at 9:57 AM Dave Horton <<a href="mailto:daveh@beachdognet.com" target="_blank" class="">daveh@beachdognet.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 style="word-wrap:break-word" class="">I am personally not familiar with a re-invite call flow working like you describe. Since you are being told by someone that this should work, I’d suggest asking them to point to the relevant section of the RFC ?<div class=""><br class=""></div><div class="">A re-invite with no SDP I have typically only seen as a 3pcc INVITE when first setting up a session (ie when the initiator wants to delay sending its SDP until the ACK). </div><div class=""><br class=""></div><div class="">Perhaps others have had experience with this in a reinvite scenario as you describe, but I find it pretty atypical.</div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class=""><br class=""><div class=""><div class="">On Aug 11, 2017, at 10:48 AM, Andrew Cassidy <<a href="mailto:andrew@cassidywebservices.co.uk" target="_blank" class="">andrew@cassidywebservices.co.uk</a>> wrote:</div><br class="m_4979663919512581248m_5628017086708472104m_-3697468907440654578Apple-interchange-newline"><div class=""><div class="">Hi Guys,<div class=""><br class=""></div><div class="">Just wanted to check a behaviour with you guys before rushing to upgrade FreeSWITCH from 1.4.26-37</div><div class=""><br class=""></div><div class="">We are reciveing a reinvite with a=inactive followed by an reinvite with no SDP. I am being told the one with no SDP should revert the media the the previously established.</div><div class=""><br class=""></div><div class="">FreeSWITCH isn't currently doing that, (or passing the empty one back to the endpoint) it's just keeping the call held. Which is the correct behaviour?</div><div class=""><br class=""></div><div class="">Kind regards,</div><div class=""><div class=""><br class=""></div></div></div></div></div></div></div></blockquote></div></div></blockquote></div></div></blockquote></div><br class=""></div></div>_________________________________________________________________________<br class="">
Professional FreeSWITCH Consulting Services:<br class="">
<a href="mailto:consulting@freeswitch.org" target="_blank" class="">consulting@freeswitch.org</a><br class="">
<a href="http://www.freeswitchsolutions.com/" rel="noreferrer" target="_blank" class="">http://www.freeswitchsolutions.com</a><br class="">
<br class="">
Official FreeSWITCH Sites<br class="">
<a href="http://www.freeswitch.org/" rel="noreferrer" target="_blank" class="">http://www.freeswitch.org</a><br class="">
<a href="http://confluence.freeswitch.org/" rel="noreferrer" target="_blank" class="">http://confluence.freeswitch.org</a><br class="">
<a href="http://www.cluecon.com/" rel="noreferrer" target="_blank" class="">http://www.cluecon.com</a><br class="">
<br class="">
FreeSWITCH-users mailing list<br class="">
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank" class="">FreeSWITCH-users@lists.freeswitch.org</a><br class="">
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" rel="noreferrer" target="_blank" class="">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br class="">
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" rel="noreferrer" target="_blank" class="">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br class="">
<a href="http://www.freeswitch.org/" rel="noreferrer" target="_blank" class="">http://www.freeswitch.org</a></blockquote></div>
_________________________________________________________________________<br class="">Professional FreeSWITCH Consulting Services:<br class=""><a href="mailto:consulting@freeswitch.org" class="">consulting@freeswitch.org</a><br class="">http://www.freeswitchsolutions.com<br class=""><br class="">Official FreeSWITCH Sites<br class="">http://www.freeswitch.org<br class="">http://confluence.freeswitch.org<br class="">http://www.cluecon.com<br class=""><br class="">FreeSWITCH-users mailing list<br class="">FreeSWITCH-users@lists.freeswitch.org<br class="">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users<br class="">UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users<br class="">http://www.freeswitch.org</div></blockquote></div><br class=""></div></body></html>