Empty Re-Invite after a=inactive
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, -- *Andrew Cassidy BSc (Hons) MBCS SSCA* Managing Director 03303 880 960 andrew@cassidyweb.co.uk <andrew@cassidywebservices.co.uk> www.cassidyweb.co.uk <http://www.cassidywebservices.co.uk>
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@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, -- Andrew Cassidy BSc (Hons) MBCS SSCA Managing Director 03303 880 960 andrew@cassidyweb.co.uk <mailto:andrew@cassidywebservices.co.uk> www.cassidyweb.co.uk <http://www.cassidywebservices.co.uk/>_________________________________________________________________________ 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
Fixed in 1.6 On Fri, Aug 11, 2017 at 9:57 AM Dave Horton <daveh@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@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,
-- *Andrew Cassidy BSc (Hons) MBCS SSCA* Managing Director
03303 880 960 andrew@cassidyweb.co.uk <andrew@cassidywebservices.co.uk> www.cassidyweb.co.uk <http://www.cassidywebservices.co.uk/> _________________________________________________________________________ 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
-- *Brian West* brian@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 | *F:*+19184209002 | *M:*+1918424WEST (9378) *Skype:*briankwest
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...) 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@freeswitch.org>:
Fixed in 1.6
On Fri, Aug 11, 2017 at 9:57 AM Dave Horton <daveh@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@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,
-- *Andrew Cassidy BSc (Hons) MBCS SSCA* Managing Director
03303 880 960 andrew@cassidyweb.co.uk <andrew@cassidywebservices.co.uk> www.cassidyweb.co.uk <http://www.cassidywebservices.co.uk/> _________________________________________________________________________ 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
--
*Brian West* brian@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 | *F:*+19184209002 | *M:*+1918424WEST (9378) *Skype:*briankwest _________________________________________________________________________ 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
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@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... <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 <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@freeswitch.org <mailto:brian@freeswitch.org>>: Fixed in 1.6
On Fri, Aug 11, 2017 at 9:57 AM Dave Horton <daveh@beachdognet.com <mailto:daveh@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@cassidywebservices.co.uk <mailto:andrew@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,
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@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@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...) 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@freeswitch.org>:
Fixed in 1.6
On Fri, Aug 11, 2017 at 9:57 AM Dave Horton <daveh@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@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@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
I was responding to the original question from Andrew.
On Aug 13, 2017, at 4:09 AM, Dmitriy Borisov <borik.internet@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@jerris.com <mailto:mike@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@gmail.com <mailto:borik.internet@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... <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 <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@freeswitch.org <mailto:brian@freeswitch.org>>: Fixed in 1.6
On Fri, Aug 11, 2017 at 9:57 AM Dave Horton <daveh@beachdognet.com <mailto:daveh@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@cassidywebservices.co.uk <mailto:andrew@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@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <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
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@jerris.com> wrote:
I was responding to the original question from Andrew.
On Aug 13, 2017, at 4:09 AM, Dmitriy Borisov <borik.internet@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@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@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...) 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@freeswitch.org>:
Fixed in 1.6
On Fri, Aug 11, 2017 at 9:57 AM Dave Horton <daveh@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@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@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
_________________________________________________________________________ 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
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@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@jerris.com> wrote:
I was responding to the original question from Andrew.
On Aug 13, 2017, at 4:09 AM, Dmitriy Borisov <borik.internet@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@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@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@freeswitch.org>:
Fixed in 1.6
On Fri, Aug 11, 2017 at 9:57 AM Dave Horton <daveh@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@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@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
_________________________________________________________________________ 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
-- *Brian West* brian@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 | *F:*+19184209002 | *M:*+1918424WEST (9378) *Skype:*briankwest
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@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@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@jerris.com> wrote:
I was responding to the original question from Andrew.
On Aug 13, 2017, at 4:09 AM, Dmitriy Borisov <borik.internet@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@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@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...) 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@freeswitch.org>:
Fixed in 1.6
On Fri, Aug 11, 2017 at 9:57 AM Dave Horton <daveh@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@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@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
_________________________________________________________________________ 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
--
*Brian West* brian@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@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
Hi! You can try to use this patch: https://freeswitch.org/stash/projects/FS/repos/freeswitch/pull-requests/1362... вт, 15 авг. 2017 г., 11:02 Andrew Cassidy <andrew@cassidywebservices.co.uk>:
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@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@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@jerris.com> wrote:
I was responding to the original question from Andrew.
On Aug 13, 2017, at 4:09 AM, Dmitriy Borisov <borik.internet@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@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@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...) 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@freeswitch.org>:
Fixed in 1.6
On Fri, Aug 11, 2017 at 9:57 AM Dave Horton <daveh@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@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@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
_________________________________________________________________________ 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
--
*Brian West* brian@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@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
Bahahahha, thats so true! On Tue, Aug 15, 2017 at 3:01 AM, Andrew Cassidy < andrew@cassidywebservices.co.uk> wrote:
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@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@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@jerris.com> wrote:
I was responding to the original question from Andrew.
On Aug 13, 2017, at 4:09 AM, Dmitriy Borisov <borik.internet@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@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@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@freeswitch.org>:
Fixed in 1.6
On Fri, Aug 11, 2017 at 9:57 AM Dave Horton <daveh@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@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@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
____________________________________________________________ _____________ 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
--
*Brian West* brian@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@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
-- *Brian West* brian@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 | *F:*+19184209002 | *M:*+1918424WEST (9378) *Skype:*briankwest
participants (5)
-
Andrew Cassidy
-
Brian West
-
Dave Horton
-
Dmitriy Borisov
-
Michael Jerris