<div dir="ltr"><div dir="ltr">On Thu, Dec 17, 2020 at 10:14 AM Floimair Florian <<a href="mailto:f.floimair@commend.com">f.floimair@commend.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="DE-AT" style="overflow-wrap: break-word;">
<div class="gmail-m_-5140205057201989504WordSection1">
<div>
<div>
<div>
<p class="MsoNormal">Hi List!<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span lang="EN-US">I am running into an „issue” that I cannot really explain.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">I have a call from Station A to Station B with both legs connected to Asterisk via Kamailio.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Asterisk used is latest 18.1.0 with chan_pjsip.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Station A -> Kamailio -> Asterisk -> Kamailio -> Station B<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Now when Station B gets the INVITE it answers with 183 Session Progress to initiate Early Media.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">However Asterisk not only passes this 183 Session Progress on to Station A, it creates a second 183 Session Progress with basically the same<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Content (only some Header lines might have switched position but their content is identical) to Station A.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">The first question that comes to mind is:<br>
Why does Asterisk send the second 183 Session Progress in the first place (it did not get anything from Station A or Station B that would explain this)?</span></p></div></div></div></div></div></blockquote><div><br></div><div>There is already an open issue for this[1], but noone has worked on it as of yet.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="DE-AT" style="overflow-wrap: break-word;"><div class="gmail-m_-5140205057201989504WordSection1">
<p class="MsoNormal"><span lang="EN-US">And in turn this leads to an issue if I replace station A with another Asterisk and put station A behind this Asterisk.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Station A -> Asterisk2 -> Kamailio -> Asterisk -> Kamailio -> Station B<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">In that case whatever was in the SDP of the first 183 Session Progress (e.g. audio=recvonly video=inactive) will cause the second Asterisk to put both media streams to sendrecv, and starts sending RTP packets from Station
 A for both audio and video which clearly is a bug in Asterisk. By the way we tested with different versions from the latest 18 back to an early 16 version. They all show this behaviour.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">To recap both 183 Session Progress contain the same SDP, the first one leads to wanted behaviour, the second one causes Asterisk to send both audio and video even though it shouldn’t.</span></p></div></div></blockquote><div><br></div><div>I can't say for certainty, but this is likely because of the way codec and stream negotiation in Asterisk works. Each leg is independent (negotiated between Asterisk and an endpoint), and the result of an outgoing leg (be it from a 200 OK or 183 Session Progress) is not forwarded to the calling side. There is continued work being done to improve this so in the future it could become smarter, but it is not yet there.</div><div><br></div><div>[1] <a href="http://issues.asterisk.org/jira/browse/ASTERISK-28185">issues.asterisk.org/jira/browse/ASTERISK-28185</a> </div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-family:tahoma,sans-serif"><font color="#073763">Joshua C. Colp</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Asterisk Technical Lead</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Sangoma Technologies</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Check us out at <a href="http://www.sangoma.com" target="_blank">www.sangoma.com</a> and <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a></font><br></div></div></div></div></div></div></div></div></div></div></div>