Late SDP causing switch to sendonly mode - one way calls (3PCC?)
Hi All, In short I have an established bridged call out to a 3rd party SIP IVR - this IVR appears to be performing 3pcc meaning I am receiving RE-INVITEs w/o SDP as the call plays prompts, goes to queue and when it is answered. For each INVITE FreeSWITCH responds with 200 with SDP and we get an ACK back with SDP. During the queue phase the ACK SDP contains a=sendonly - all previous SDP have implied sendrecv on both sides. All is OK at this stage. When the call is finally answered we get an INVITE w/o SDP and FreeSWITCH responds with SDP including a=sendonly, to which the remote replies a=sendrecv. Hence we get one way audio at the time when the conversation should be starting. Can anyone help explain why FreeSWITCH would be switching to sendonly mode? I have enable_3pcc=true configured but otherwise this is a fairly standard/vanilla configuration. The behaviour I would expect is for FreeSWITCH to continue to omit the attribute and imply sendrecv. Are there specific variables which might allow me to manage the SDP attributes? Please find a trace log attached. Platform: FreeSWITCH Version 1.8.5-6-31281a0bf1~64bit (-6-31281a0bf1 64bit) Linux my.network 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux Let me know if I can offer any more details regarding the implementation, thanks, Callum -- *0333 332 0000 | www.x-on.co.uk <http://www.x-on.co.uk> | ** <https://www.linkedin.com/company/x-on> <https://www.facebook.com/XonTel> <https://twitter.com/xonuk> * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments.
On May 24, 2019, at 8:54 AM, Callum Guy <callum.guy@x-on.co.uk> wrote:
Hi All,
In short I have an established bridged call out to a 3rd party SIP IVR - this IVR appears to be performing 3pcc meaning I am receiving RE-INVITEs w/o SDP as the call plays prompts, goes to queue and when it is answered. For each INVITE FreeSWITCH responds with 200 with SDP and we get an ACK back with SDP. During the queue phase the ACK SDP contains a=sendonly - all previous SDP have implied sendrecv on both sides. All is OK at this stage. When the call is finally answered we get an INVITE w/o SDP and FreeSWITCH responds with SDP including a=sendonly, to which the remote replies a=sendrecv. Hence we get one way audio at the time when the conversation should be starting.
Can anyone help explain why FreeSWITCH would be switching to sendonly mode? I have enable_3pcc=true configured but otherwise this is a fairly standard/vanilla configuration. The behaviour I would expect is for FreeSWITCH to continue to omit the attribute and imply sendrecv.
"During the queue phase the ACK SDP contains a=sendonly” Freeswitch is NOT switching it.. the other side is.
Are there specific variables which might allow me to manage the SDP attributes?
Please find a trace log attached.
Platform: FreeSWITCH Version 1.8.5-6-31281a0bf1~64bit (-6-31281a0bf1 64bit) Linux my.network 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux
Let me know if I can offer any more details regarding the implementation, thanks,
Callum
0333 332 0000 | www.x-on.co.uk <http://www.x-on.co.uk/> | <https://www.linkedin.com/company/x-on> <https://www.facebook.com/XonTel> <https://twitter.com/xonuk> X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments.
<sdp-sendonly.log>_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://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 https://freeswitch.com
I think your issue is similar to this one : https://freeswitch.org/jira/browse/FS-8573 I am also facing it but with different scenario. On Fri, May 24, 2019 at 10:26 PM Mike Jerris <mike@freeswitch.org> wrote:
On May 24, 2019, at 8:54 AM, Callum Guy <callum.guy@x-on.co.uk> wrote:
Hi All,
In short I have an established bridged call out to a 3rd party SIP IVR - this IVR appears to be performing 3pcc meaning I am receiving RE-INVITEs w/o SDP as the call plays prompts, goes to queue and when it is answered. For each INVITE FreeSWITCH responds with 200 with SDP and we get an ACK back with SDP. During the queue phase the ACK SDP contains a=sendonly - all previous SDP have implied sendrecv on both sides. All is OK at this stage. When the call is finally answered we get an INVITE w/o SDP and FreeSWITCH responds with SDP including a=sendonly, to which the remote replies a=sendrecv. Hence we get one way audio at the time when the conversation should be starting.
Can anyone help explain why FreeSWITCH would be switching to sendonly mode? I have enable_3pcc=true configured but otherwise this is a fairly standard/vanilla configuration. The behaviour I would expect is for FreeSWITCH to continue to omit the attribute and imply sendrecv.
"During the queue phase the ACK SDP contains a=sendonly”
Freeswitch is NOT switching it.. the other side is.
Are there specific variables which might allow me to manage the SDP attributes?
Please find a trace log attached.
Platform: FreeSWITCH Version 1.8.5-6-31281a0bf1~64bit (-6-31281a0bf1 64bit) Linux my.network 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux
Let me know if I can offer any more details regarding the implementation, thanks,
Callum
*0333 332 0000 | www.x-on.co.uk <http://www.x-on.co.uk/> | ** <https://www.linkedin.com/company/x-on> <https://www.facebook.com/XonTel> <https://twitter.com/xonuk> *
X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments.
<sdp-sendonly.log> _________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://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 https://freeswitch.com
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://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 https://freeswitch.com
-- Thanks, Sagar
Mike, Sagar, Thanks for your responses. I've understood from this that the consensus is that I am dealing with a misbehaving remote device and as such should not be looking to change anything on my FreeSWITCH setup to resolve. RFC3264 <https://www.ietf.org/rfc/rfc3264.txt> (6.1) suggests that the initial behaviour is acceptable and valid - FreeSWITCH is sending sendrecv but the remote is responding sendonly. f this is triggering the state change in FreeSWITCH would it not be to a state of recvonly as the remote has informed us it will only be sending at this time? If anything I would have thought that the subsequent transaction would result in FreeSWITCH reporting that it is in recvonly mode rather than sendonly? Having said that I can see that with this scenario I am dealing with where all RE-INVITE transactions are late SDP I don't see how we would overcome this configuration FreeSWITCH side. Unfortunately I am have no communication path with the remote provider at this time. On that basis I will have to look at intercepting on our SIP proxy and manipulating the SDP manually to handle this scenario - I'm sure if I prevent the sendonly from coming through then the issue will not surface. I am a little concerned about a blanket change which prevents sendonly on all late SDP requests however I can't immediately see a scenario (i.e. normal call hold) where this would be useful as hold actions should be sent on the RE-INVITE itself. If anyone is aware of a scenario where sendonly on late SDP would be necessary please let me know! Thanks, Callum On Sat, 25 May 2019 at 07:20, sagar malam <sagarmalam@gmail.com> wrote:
I think your issue is similar to this one : https://freeswitch.org/jira/browse/FS-8573
I am also facing it but with different scenario.
On Fri, May 24, 2019 at 10:26 PM Mike Jerris <mike@freeswitch.org> wrote:
On May 24, 2019, at 8:54 AM, Callum Guy <callum.guy@x-on.co.uk> wrote:
Hi All,
In short I have an established bridged call out to a 3rd party SIP IVR - this IVR appears to be performing 3pcc meaning I am receiving RE-INVITEs w/o SDP as the call plays prompts, goes to queue and when it is answered. For each INVITE FreeSWITCH responds with 200 with SDP and we get an ACK back with SDP. During the queue phase the ACK SDP contains a=sendonly - all previous SDP have implied sendrecv on both sides. All is OK at this stage. When the call is finally answered we get an INVITE w/o SDP and FreeSWITCH responds with SDP including a=sendonly, to which the remote replies a=sendrecv. Hence we get one way audio at the time when the conversation should be starting.
Can anyone help explain why FreeSWITCH would be switching to sendonly mode? I have enable_3pcc=true configured but otherwise this is a fairly standard/vanilla configuration. The behaviour I would expect is for FreeSWITCH to continue to omit the attribute and imply sendrecv.
"During the queue phase the ACK SDP contains a=sendonly”
Freeswitch is NOT switching it.. the other side is.
Are there specific variables which might allow me to manage the SDP attributes?
Please find a trace log attached.
Platform: FreeSWITCH Version 1.8.5-6-31281a0bf1~64bit (-6-31281a0bf1 64bit) Linux my.network 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux
Let me know if I can offer any more details regarding the implementation, thanks,
Callum
*0333 332 0000 | www.x-on.co.uk <http://www.x-on.co.uk/> | ** <https://www.linkedin.com/company/x-on> <https://www.facebook.com/XonTel> <https://twitter.com/xonuk> *
X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments.
<sdp-sendonly.log> _________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://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 https://freeswitch.com
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://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 https://freeswitch.com
-- Thanks,
Sagar _________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://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 https://freeswitch.com
-- *0333 332 0000 | www.x-on.co.uk <http://www.x-on.co.uk> | ** <https://www.linkedin.com/company/x-on> <https://www.facebook.com/XonTel> <https://twitter.com/xonuk> * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments.
Hi, I think you have to use something like this towards IVR <action application="export" data="nolocal:sip_unhold_nosdp=true"/> On 28/05/2019 12:20, Callum Guy wrote:
Mike, Sagar,
Thanks for your responses.
I've understood from this that the consensus is that I am dealing with a misbehaving remote device and as such should not be looking to change anything on my FreeSWITCH setup to resolve.
RFC3264 <https://www.ietf.org/rfc/rfc3264.txt> (6.1) suggests that the initial behaviour is acceptable and valid - FreeSWITCH is sending sendrecv but the remote is responding sendonly. f this is triggering the state change in FreeSWITCH would it not be to a state of recvonly as the remote has informed us it will only be sending at this time? If anything I would have thought that the subsequent transaction would result in FreeSWITCH reporting that it is in recvonly mode rather than sendonly? Having said that I can see that with this scenario I am dealing with where all RE-INVITE transactions are late SDP I don't see how we would overcome this configuration FreeSWITCH side.
Unfortunately I am have no communication path with the remote provider at this time. On that basis I will have to look at intercepting on our SIP proxy and manipulating the SDP manually to handle this scenario - I'm sure if I prevent the sendonly from coming through then the issue will not surface. I am a little concerned about a blanket change which prevents sendonly on all late SDP requests however I can't immediately see a scenario (i.e. normal call hold) where this would be useful as hold actions should be sent on the RE-INVITE itself. If anyone is aware of a scenario where sendonly on late SDP would be necessary please let me know!
Thanks,
Callum
On Sat, 25 May 2019 at 07:20, sagar malam <sagarmalam@gmail.com <mailto:sagarmalam@gmail.com>> wrote:
I think your issue is similar to this one : https://freeswitch.org/jira/browse/FS-8573
I am also facing it but with different scenario.
On Fri, May 24, 2019 at 10:26 PM Mike Jerris <mike@freeswitch.org <mailto:mike@freeswitch.org>> wrote:
On May 24, 2019, at 8:54 AM, Callum Guy <callum.guy@x-on.co.uk <mailto:callum.guy@x-on.co.uk>> wrote:
Hi All,
In short I have an established bridged call out to a 3rd party SIP IVR - this IVR appears to be performing 3pcc meaning I am receiving RE-INVITEs w/o SDP as the call plays prompts, goes to queue and when it is answered. For each INVITE FreeSWITCH responds with 200 with SDP and we get an ACK back with SDP. During the queue phase the ACK SDP contains a=sendonly - all previous SDP have implied sendrecv on both sides. All is OK at this stage. When the call is finally answered we get an INVITE w/o SDP and FreeSWITCH responds with SDP including a=sendonly, to which the remote replies a=sendrecv. Hence we get one way audio at the time when the conversation should be starting.
Can anyone help explain why FreeSWITCH would be switching to sendonly mode? I have enable_3pcc=true configured but otherwise this is a fairly standard/vanilla configuration. The behaviour I would expect is for FreeSWITCH to continue to omit the attribute and imply sendrecv.
"During the queue phase the ACK SDP contains a=sendonly”
Freeswitch is NOT switching it.. the other side is.
Are there specific variables which might allow me to manage the SDP attributes?
Please find a trace log attached.
Platform: FreeSWITCH Version 1.8.5-6-31281a0bf1~64bit (-6-31281a0bf1 64bit) Linux my.network 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux
Let me know if I can offer any more details regarding the implementation, thanks,
Callum
*^0333 332 0000 | www.x-on.co.uk <http://www.x-on.co.uk/> | _**_^<https://www.linkedin.com/company/x-on> <https://www.facebook.com/XonTel> <https://twitter.com/xonuk> *
X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments.
<sdp-sendonly.log>_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com <mailto:sales@freeswitch.com> https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://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 UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com <mailto:sales@freeswitch.com> https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://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 UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
-- Thanks,
Sagar _________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com <mailto:sales@freeswitch.com> https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://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 UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
*^0333 332 0000 | www.x-on.co.uk <http://www.x-on.co.uk> | _**_^<https://www.linkedin.com/company/x-on> <https://www.facebook.com/XonTel> <https://twitter.com/xonuk> *
X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments.
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://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 https://freeswitch.com
-- Serge S. Yuriev Senior VoIP engineer
Thanks Serge, I'll give this a whirl and see if it works as a temporary solution - really appreciate you pointing out that option On Tue, 28 May 2019 at 12:38, Serge S. Yuriev <me@nevian.org> wrote:
Hi,
I think you have to use something like this towards IVR <action application="export" data="nolocal:sip_unhold_nosdp=true"/>
Mike, Sagar,
Thanks for your responses.
I've understood from this that the consensus is that I am dealing with a misbehaving remote device and as such should not be looking to change anything on my FreeSWITCH setup to resolve.
RFC3264 <https://www.ietf.org/rfc/rfc3264.txt> (6.1) suggests that the initial behaviour is acceptable and valid - FreeSWITCH is sending sendrecv but the remote is responding sendonly. f this is triggering the state change in FreeSWITCH would it not be to a state of recvonly as the remote has informed us it will only be sending at this time? If anything I would have thought that the subsequent transaction would result in FreeSWITCH reporting that it is in recvonly mode rather than sendonly? Having said that I can see that with this scenario I am dealing with where all RE-INVITE transactions are late SDP I don't see how we would overcome this configuration FreeSWITCH side.
Unfortunately I am have no communication path with the remote provider at this time. On that basis I will have to look at intercepting on our SIP proxy and manipulating the SDP manually to handle this scenario - I'm sure if I prevent the sendonly from coming through then the issue will not surface. I am a little concerned about a blanket change which prevents sendonly on all late SDP requests however I can't immediately see a scenario (i.e. normal call hold) where this would be useful as hold actions should be sent on the RE-INVITE itself. If anyone is aware of a scenario where sendonly on late SDP would be necessary please let me know!
Thanks,
Callum
On Sat, 25 May 2019 at 07:20, sagar malam <sagarmalam@gmail.com <mailto:sagarmalam@gmail.com>> wrote:
I think your issue is similar to this one : https://freeswitch.org/jira/browse/FS-8573
I am also facing it but with different scenario.
On Fri, May 24, 2019 at 10:26 PM Mike Jerris <mike@freeswitch.org <mailto:mike@freeswitch.org>> wrote:
On May 24, 2019, at 8:54 AM, Callum Guy <callum.guy@x-on.co.uk <mailto:callum.guy@x-on.co.uk>> wrote:
Hi All,
In short I have an established bridged call out to a 3rd party SIP IVR - this IVR appears to be performing 3pcc meaning I am receiving RE-INVITEs w/o SDP as the call plays prompts, goes to queue and when it is answered. For each INVITE FreeSWITCH responds with 200 with SDP and we get an ACK back with SDP. During the queue phase the ACK SDP contains a=sendonly - all previous SDP have implied sendrecv on both sides. All is OK at this stage. When the call is finally answered we get an INVITE w/o SDP and FreeSWITCH responds with SDP including a=sendonly, to which the remote replies a=sendrecv. Hence we get one way audio at the time when the conversation should be starting.
Can anyone help explain why FreeSWITCH would be switching to sendonly mode? I have enable_3pcc=true configured but otherwise this is a fairly standard/vanilla configuration. The behaviour I would expect is for FreeSWITCH to continue to omit the attribute and imply sendrecv.
"During the queue phase the ACK SDP contains a=sendonly”
Freeswitch is NOT switching it.. the other side is.
Are there specific variables which might allow me to manage the SDP attributes?
Please find a trace log attached.
Platform: FreeSWITCH Version 1.8.5-6-31281a0bf1~64bit (-6-31281a0bf1
64bit)
Linux my.network 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux
Let me know if I can offer any more details regarding the implementation, thanks,
Callum
*^0333 332 0000 | www.x-on.co.uk <http://www.x-on.co.uk/> | _**_^<https://www.linkedin.com/company/x-on> <https://www.facebook.com/XonTel> <https://twitter.com/xonuk> *
X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No.
On 28/05/2019 12:20, Callum Guy wrote: 2578478.
The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments.
<sdp-sendonly.log>_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com <mailto:sales@freeswitch.com> https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://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 UNSUBSCRIBE:
http://lists.freeswitch.org/mailman/options/freeswitch-users
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com <mailto:sales@freeswitch.com> https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://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 UNSUBSCRIBE:
http://lists.freeswitch.org/mailman/options/freeswitch-users
-- Thanks,
Sagar
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire
Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com <mailto:sales@freeswitch.com> https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://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 UNSUBSCRIBE:
http://lists.freeswitch.org/mailman/options/freeswitch-users
*^0333 332 0000 | www.x-on.co.uk <http://www.x-on.co.uk> | _**_^<https://www.linkedin.com/company/x-on> <https://www.facebook.com/XonTel> <https://twitter.com/xonuk> *
X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments.
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN
services.
Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://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 https://freeswitch.com
-- Serge S. Yuriev Senior VoIP engineer
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://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 https://freeswitch.com
-- *0333 332 0000 | www.x-on.co.uk <http://www.x-on.co.uk> | ** <https://www.linkedin.com/company/x-on> <https://www.facebook.com/XonTel> <https://twitter.com/xonuk> * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments.
participants (4)
-
Callum Guy
-
Mike Jerris
-
sagar malam
-
Serge S. Yuriev