<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 15, 2020 at 11:57 AM Joshua Elson <<a href="mailto:joshelson@gmail.com">joshelson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">So I am the one responsible for this situation, if I recall the discussion a few years back. We actually have had to support several phones - Yealink being the most distinctly memorable - that support asymmetric codecs on a single call leg, and from our reading, it's legal in the RFC. In some very high throughput cases, it was preferable to reduce overall transcoding use in our infrastructure when you did the math on having a few thousand of these phones in the same situation.<div><br></div></div></blockquote><div><br></div><div>So if we send an offer to Bob (who has one of the phones in question) with g722, ulaw, alaw in that order, would Bob respond with an answer in the same order but then start sending ulaw for instance? Or would Bob send an answer with uaw, g722, alaw? The reason I ask is that if they respond with g722, ulaw, alaw, then we'll probably also send that back in the answer to Alice. If Bob subsequently starts sending ulaw, we _may_ (I have to check) simply pass that through to Alice since ulaw was in the final topology but Alice's phone might not be prepared to receive media in a format other than the first in the answer. This seems to be common, especially if the phone uses the pjproject SIP stack.</div><div><br></div><div>Other things to consider...</div><div>Does Alice's asymmetric_codecs setting apply?</div><div>If transcode is "no" would we have to trigger a topology change and do re-INVITES? This could get ugly.</div><div>If transcode is "yes" but Alice's asymmetric_codecs is "no" do we transcode in the 1 direction only?</div><div><br></div><div>How does this fit with earlier "general" assumptions that Asterisk should not be trying to compensate for broken UAs?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>That being said, it's conceivable we could live without that option now, and some phone vendors do still not properly implement the RFC standard around this, but we do still run in production with asymmetric codecs on a single call leg for a slight majority of our devices.</div><div><br></div><div>Josh</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 15, 2020 at 10:42 AM Michael Maier <<a href="mailto:m1278468@mailbox.org" target="_blank">m1278468@mailbox.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello George,<br>
<br>
in terms of uses cases? I'm not aware of any use case which would need asymmetric codecs. The opposite is true: my phones can't handle asymmetric codecs at all - therefore it's<br>
forbidden.<br>
<br>
But I'm not the only one using asterisk - others may have an use case.<br>
<br>
<br>
On 15.06.20 at 01:56 George Joseph wrote:<br>
> Given the earlier discussions, under what conditions is it desirable to use<br>
> a different codec in one direction than the other on the same call leg?<br>
<br>
<br>
Thanks<br>
Michael<br>
<br>
-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div>
-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr" style="font-size:12.8px"><div dir="ltr" style="font-size:12.8px"><div style="font-family:tahoma,sans-serif;font-size:small"><span style="color:rgb(7,55,99)">George Joseph</span><br></div></div><div dir="ltr" style="font-size:small"></div><div style="font-family:tahoma,sans-serif;font-size:small"><span style="color:rgb(7,55,99)">Asterisk Software Developer</span><br></div><span style="color:rgb(7,55,99);font-family:tahoma,sans-serif;font-size:small">direct/fax +1 256 428 6012</span><br><div style="font-family:tahoma,sans-serif;font-size:small"><font color="#073763" style="--darkreader-inline-color:#97cdf8;">Check us out at</font> <a href="http://www.sangoma.com/" style="color:rgb(17,85,204)" target="_blank">www.sangoma.com</a> and <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a><br></div><div style="font-family:tahoma,sans-serif;font-size:small"><img src="cid:ii_k3abte590" alt="image.png" width="184" height="32" style="margin-right: 0px;"></div></div></div></div></div></div></div></div></div>