<div dir="ltr">Hi All,<div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>Are there specific variables which might allow me to manage the SDP attributes?</div><div><br></div><div>Please find a trace log attached. </div><div><br></div><div>Platform:</div><div>FreeSWITCH Version 1.8.5-6-31281a0bf1~64bit (-6-31281a0bf1 64bit)<br></div><div>Linux my.network 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux<br></div><div><br></div><div>Let me know if I can offer any more details regarding the implementation, thanks,</div><div><br></div><div>Callum</div><div><br></div></div>

<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;text-align:justify"><font size="3" face="Verdana"><span style="font-size:8px;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"></span></font></p><div><img src="https://www.x-on.co.uk/email/footer/banner-surgeryconnect-jun-sep-19.jpg"></div><div><br></div><div><div><div><font size="4"><b>^{<font face="Verdana">0333 332 0000  |  <a href="http://www.x-on.co.uk" target="_blank">www.x-on.co.uk</a>  |  </font>}</b></font><font size="4"><b>_{^{<font face="Verdana"><a href="https://www.linkedin.com/company/x-on" target="_blank"><img src="http://www.x-on.co.uk//images/icon/linkedin.png" width="24" height="24"></a>  <a href="https://www.facebook.com/XonTel" target="_blank"><img src="http://www.x-on.co.uk//images/icon/facebook.png" width="24" height="24"></a>  <a href="https://twitter.com/xonuk" target="_blank"><img src="http://www.x-on.co.uk//images/icon/twitter.png" width="24" height="24"></a></font>}} </b></font><br><p><span style="font-size:6.0pt;font-family:Verdana;color:black">X-on
is a trading name of Storacall Technology Ltd a limited company registered in
England and Wales.<br>
Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead,
Herts, HP3 9SD. Company Registration No. 2578478.<br>
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 <span>+44(0)333 332 0000</span> and delete the<br>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. </span><span style="font-size:6.0pt;font-family:Verdana;color:black">Views
or opinions expressed by an individual<br>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<br>for
viruses. X-on makes no representation or warranty as to the absence of viruses
in this email or any attachments.</span></p>





<p><span style="font-size:6.0pt;font-family:Verdana;color:black"></span><font size="2"><span style="font-size:6.0pt;font-family:Verdana;color:black"></span></font></p></div></div></div>