<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 16, 2020 at 2:02 PM 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 went back all the way to RFC 3264 on these and it's relatively clear to me from the reading it that different sending and receiving codecs is, at least strictly speaking, legal:<div>,</div><div><pre style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)">Once the answerer has sent the answer, it MUST be prepared to receive
media for any recvonly streams described by that answer. It MUST be
prepared to send and receive media for any sendrecv streams in the
answer, and it MAY send media immediately. The answerer MUST be
prepared to receive media for recvonly or sendrecv streams using any
media formats listed for those streams in the answer, and it MAY send
media immediately. When sending media, it SHOULD use a packetization</pre><pre style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"> interval equal to the value of the ptime attribute in the offer, if
any was present. It SHOULD send media using a bandwidth no higher
than the value of the bandwidth attribute in the offer, if any was
present. The answerer MUST send using a media format in the offer
that is also listed in the answer, and SHOULD send using the most
preferred media format in the offer that is also listed in the answer.</pre></div><div><br></div><div>In the same RFC section discussing unicast stream negotiation, this language appears, in more or less direct contradiction:</div><div><br></div><div><pre style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)">This helps assure that the same codec is used in
both directions.</pre></div><div><br></div></div></blockquote><div><br></div><div>Oh yeah, it's "legal" and a non issue if you're an endpoint. It's a whole different story when you're a Back-to-Back UA like Asterisk though. :)</div><div>And yeah.. I saw that contradictory statement as well.</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>I also agree with the sentiments about this being kind of a weird situation. As for the necessity of this functionality, I know it's been desirable for us to avoid transcoding burden in some situations and I could imagine some weird edge cases where extreme asymmetric send/receive bandwidth situations could make this kind of functionality desirable. I don't really think either of those are show-stoppingly major issues, but someone else might.</div></div></blockquote><div><br></div><div>Fair enough.</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><br></div><div>The issues you raise on Alice's behavior are also legitimate, and I don't love the scenarios there with topology changes and reinvites from a practical point of view.</div></div></blockquote><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><br></div><div>As for whether this is broken UA behavior, I think that's a conversation for happy hour beers somewhere, whenever that's allowed again. :) This is one area where some UA designers have deviated from a strict reading of the spec and done the thing that makes sense to them and simplifies behavior. So really, what's the philosophical definition of "broken"?</div></div></blockquote><div><br></div><div>Instead of "broken", how about "weird"? :) In this case, if Bob responds with g722, ulaw,alaw in that order in the answer but starts sending alaw, that's "legal" but "weird". If he didn't like g722 or ulaw then he shouldn't have included it in the answer and if he preferred alaw, that should have been the first codec in the answer "m" line. It gets even more complicated for a B2B-UA if Bob starts sending media _before_ the SDP answer. We would _like_ to send Alice an SDP answer where the first codec matches the media she's already getting or will be getting.</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><br></div><div>If the community consensus is that it's not worth maintaining this functionality, I'm totally fine with eliminating it. We'll just have to do some planning for how to accommodate the transition.</div></div></blockquote><div><br></div><div>Let's see how things go. </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 dir="ltr"><div><br></div><div>Hope that helps muddy the water!</div></div></blockquote><div><br></div><div>Heh, just wait until we start in on Direct Media. :)</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><br></div><div>Josh</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 15, 2020 at 1:01 PM George Joseph <<a href="mailto:gjoseph@digium.com" target="_blank">gjoseph@digium.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"><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" target="_blank">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"><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>
-- <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>