[Freeswitch-users] Empty Re-Invite after a=inactive

[Dmitriy Borisov]

Hi!

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

вс, 13 авг. 2017 г., 10:41 Michael Jerris <mike at jerris.com>:

> 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.
>
> On Aug 12, 2017, at 7:16 PM, Dmitriy Borisov <borik.internet at gmail.com>
> wrote:
>
> Hello!
>
> 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 (
> https://freeswitch.org/stash/projects/FS/repos/freeswitch/pull-requests/1362/overview)
> to fix the issue, but it not reviewed for now.
>
> Also I see discussion of Anthony with reporter in issue FS-9378
> https://freeswitch.org/jira/plugins/servlet/mobile#issue/FS-9378, 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.
>
> And yes, this issue on broadsoft PBX too...
>
> пт, 11 авг. 2017 г., 20:13 Brian West <brian at freeswitch.org>:
>
>> Fixed in 1.6
>>
>> On Fri, Aug 11, 2017 at 9:57 AM Dave Horton <daveh at beachdognet.com>
>> wrote:
>>
>>> 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 ?
>>>
>>> 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).
>>>
>>> Perhaps others have had experience with this in a reinvite scenario as
>>> you describe, but I find it pretty atypical.
>>>
>>>
>>> On Aug 11, 2017, at 10:48 AM, Andrew Cassidy <
>>> andrew at cassidywebservices.co.uk> wrote:
>>>
>>> Hi Guys,
>>>
>>> Just wanted to check a behaviour with you guys before rushing to upgrade
>>> FreeSWITCH from 1.4.26-37
>>>
>>> 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.
>>>
>>> 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?
>>>
>>> Kind regards,
>>>
>>>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20170813/26149771/attachment.html>