<div dir="ltr"><div dir="ltr">On Thu, Jun 25, 2020 at 7:39 AM Alex Hermann <<a href="mailto:alex-lists@wenlex.nl">alex-lists@wenlex.nl</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">On woensdag 3 juni 2020 22:17:52 CEST George Joseph wrote:<br>
> Now let's talk about format preference order.<br>
<br>
I haven't seen my use case pass by yet, so I'll throw it in...<br>
<br>
My use case is where Asterisk is functioning as a sort of SBC and needs <br>
to respect both party's codec preference, disallow unwanted codecs and <br>
reduce transcoding when possible.<br>
<br>
So, Alice should get to talk in her preferred codec, and Bob in his. The  <br>
"allow" list of Asterisk is only used to filter out unwanted codecs. The <br>
ordering of codecs in the "allow" list is mostly ignored.<br>
<br>
To reduce transcoding The offer to Bob should contain the codecs in the <br>
order Alice offered them.<br>
<br>
<br>
Asterisk (13) forces the order of the "allow" list on each leg, so I <br>
have patched my Asterisk 13 with PJSIP to do approximately the above. <br>
This behaviour is best put under a config option like <br>
"prefer_remote_codec_order" on the endpoint.<br>
<br>
<br>
My Asterisk uses the following steps:<br>
<br>
1) Retain the codec order from the offer received from Alice.<br>
2) Filter out all codecs from the offer that are not in the allow list <br>
for Alice<br>
3) Merge the list from step 2 with the allow list from Bob, but keep the <br>
ordering from the offer from Alice (prepend Alice's received list to <br>
Bob's and remove duplicates).<br>
4) Filter list from step 3 with the allow list from Bob.<br>
<br>
The offer to Bob now contains all the codecs in his allow list, with the <br>
common codecs between Alice and Bob at the top of the list in the order <br>
Alice sent them.<br>
<br>
5) On receiving the answer from Bob, retain his codec ordering<br>
6) Answer Bob with the received codec ordering from himself<br>
7) Use Bob's most preferred codec in his call leg<br>
8) Answer Alice with the received codec ordering from herself<br>
9) Use Alice's most preferred codec in her call leg<br>
<br>
10) When Alice or Bob decides to switch the actual codec in the RTP to <br>
another codec from the negotioted list, adjust the codec on that leg <br>
only (to keep codecs symmetric), but don't change anything on the <br>
bridged leg.<br></blockquote><div><br></div><div>I just want to chime in from a general sense on this. I don't expect all functionality and every case someone thinks up will exist out of the gate, but I want to say that at least providing such things helps ensure that the fundamental design and implementation don't prohibit it from occurring in the future. Like many things in Asterisk in recent times it starts with a base, and then cool things get added and grow from it.</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>