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

Tue Aug 15 08:01:23 UTC 2017

Hi Brian,

sip_unhold_nosdp isn't working for me. I will have to do some traces later.

I agree that people should just abide by standards but as you can imagine I
can't just tell the local police force to change their phone system :)

Kind regards,

On Tue, 15 Aug 2017 at 03:16 Brian West <brian at freeswitch.org> wrote:

> sip_unhold_nosdp is a hack to allow this non-compliant behavior to exist.
>
>
> /b
>
>
> On Mon, Aug 14, 2017 at 3:14 AM, Andrew Cassidy <
> andrew at cassidywebservices.co.uk> wrote:
>
>> Hi Michael,
>>
>> Thanks, I totally agree. Long story short, my customer and <large public
>> sector organisation> are using the same SIP provider, so all messages from
>> their cisco call manager are reaching us pretty much unmodified. Their
>> system also does some other strange things.
>>
>> I'll give sip_unhold_nosdp a go and see how I get on but as this is
>> non-standard behaviour will only enable it on a case-by-case basis.
>>
>> Kind regards,
>>
>> On Mon, 14 Aug 2017 at 01:38 Michael Jerris <mike at jerris.com> wrote:
>>
>>> I was responding to the original question from Andrew.
>>>
>>> On Aug 13, 2017, at 4:09 AM, Dmitriy Borisov <borik.internet at gmail.com>
>>> wrote:
>>>
>>> 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
>>>
>>> _________________________________________________________________________
>>> 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
>>>
>>>
>>> _________________________________________________________________________
>>> 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
>>
>>
>> _________________________________________________________________________
>> 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
>>
>
>
>
> --
>
> *Brian West*
> brian at freeswitch.org
>
> *Twitter: @FreeSWITCH , @briankwest*
>
> http://www.freeswitchbook.com
> http://www.freeswitchcookbook.com
>
> Book a phone call (CST) <https://freeswitch.com/appointment>
>
> Allison prompts for FreeSWITCH:
>
> *https://www.gofundme.com/allison-prompts-for-freeswitch*
> <https://www.gofundme.com/allison-prompts-for-freeswitch>
>
> Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit:
> /r/freeswitch <https://www.reddit.com/r/freeswitch>
>
> *T:*+19184209001 <+1%20918-420-9001> | *F:*+19184209002
> <+1%20918-420-9002> | *M:*+1918424WEST (9378)
> *Skype:*briankwest
> _________________________________________________________________________
> 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/20170815/4932856d/attachment-0001.html>