On June 03, 2020 at 22:17 George Joseph wrote:
Greetings All,
We've been working hard on new codec negotiation stuff for Asterisk 18 and
we've got some stuff to run by you. It's a lot so please read carefully.
Thank you very much for your ongoing effort! I really appreciate it!
I additionally read this documentation here [1].
During writing down those lines I got the feeling how complicated could be ... .
Therefore there must be some basic principals on how to handle things. I tried
to write them down as follows:
0. Asterisk is the only one which decides the codecs to be used on base of the allow
list on each leg phone <-> Asterisk because I want to be sure about the codecs
used on each leg
(because of existing network bandwidth restrictions e.g.)
1. The phone must support at least one of the codecs of the allow list. If not:
drop the call
2. Bringing together the legs: the actually used codec list on each leg only
contains the codecs supported by the respective device and which are allowed on
the allow list on the
other hand.
3. At this point Asterisk decides: if there are common codecs on both legs ->
use these / this. If there are no common codecs between two legs: transcode (Use
case: don't prevent a
call as long as the codecs on each leg itself are allowed).
4. Each phone on each call leg may define its own codec order. But Asterisk
finally has to decide, which side to prefer (-> switchable).
5. Basically, a phone mustn't advertise codecs it can't handle - if this can't
be prevented, the codec has to be removed on the respective allow list of the
line on Asterisk side.
[...]
Simple use case, Alice to Bob, no direct media.
1. Under what conditions would we accept a format on an incoming offer
from a UAC (Alice) that *wasn't* in the UAC's endpoint allow= parameter?
The use case of this consideration seems to me: How to handle broken
configurations.
Does whether we accept formats not on the endpoint need to be
configurable? Don't just say "yes". :)
No. From my point of view it never ever is Asterisk's job to handle broken
configurations. Simple example: Phone sends SDP offer codec a) and b) which are
both not on the allow list
for this endpoint -> drop the call.
We need use cases.
Use case: It's not Asterisk's job to repair broken configurations. I must be
sure that only allowed codecs are used on a defined port because of bandwidth
restrictions e.g.
We could
use the offer's list exclusively, use the endpoint's list exclusively,
merge the two together, or use only those in common.
Asterisk finally defines which codec to use. Therefore all codecs of the phones
offer have to be dropped which are not part of the allow list. Furthermore all
codecs of the allow
list have to be dropped, which are not contained in the SDP offer of the device.
What happens if after
applying that operation, there are no formats in common? Drop the call?
Exactly. Because it's a result of misconfiguration. It's not Asterisk's job to
repair broken configurations.
Transocde?
Transcoding only if there is an allowed and supported codec on both sides which
are not common. If there is one common codec on both sides - use this codec and
do not transcode.
Using what format? It'd have to be one Alice accepts. We'll
save the process of transcoding for a follow-on discussion.
2. Under what conditions would we send a codec in an offer to a UAS (Bob)
that *wasn't* in the UAS's endpoint allow= parameter.
Never! I must be sure about the codecs to be used on a line (bandwidth).
Similarly, under
what conditions would we send a format to Bob that *was* in his endpoint
allow= parameter but *wasn't* in the reconciled list we got from Alice via
the core? Same possible options and questions as above.
Asterisk just should send the codecs to Bob which are part of the allow list -
nothing more. The order could be defined by the reconciled list we got from
Alice. Always the same use
case: Asterisk defines which codec to use just to be sure that bandwidth
requirements can be enforced (or other requirements)
3. OK now whatever we've decided to send to Bob, according to RFC3264 para
6.1, Bob MUST send back an answer that contains a common format OR reject
the stream if there are no formats in common. It doesn't say whether it's
valid for Bob to send back formats we didn't request *in addition *to ones
we did request. It wouldn't make sense for him to do that because that
same RFC and paragraph only says we MUST accept media in a format we sent.
It doesn't mention what should happen if we get media in a format we
*didn't* request. Based on this, unless someone can give us a valid use
case for this, and rules governing when it's acceptable and when it's not,
we do NOT plan on supporting receiving media in a format we didn't
request.
Yes.
We'd just drop the frames.
Correctly.
If Bob wants to use a format not in
the offer, he should RE-INVITE.
Which would lead to a drop - remember: we don't allow any codec not on the
allow list.
4. Now we've got Bob's answer and are passing it back to the core so we
need to send an answer back to Alice.
All codecs not on Bob's allow list have to be removed. The order may be adopted.
First, unless someone can give us a
valid use case, we will never send Alice a format she didn't request in her
offer so those will get removed.
Correct. Furthermore, you mustn't send any format which is not part of Alice's
allow list.
Based on options specified above though,
the potential answer MAY contain formats NOT in Alice's endpoint allow=
parameter. Same options and questions as "1".
No - the answer mustn't contain any format not allowed in the allow list. It's
the allow list which finally defines codecs to be used. I must count on the
allow list!
Now let's talk about format preference order.
On the Alice to Bob side...
1. On Alice's incoming leg, after reconciling Alice's offer and Alice's
endpoint, we can sort by Alice's preferred order or Alice's endpoint's
preferred order based on configuration and send that order to the core.
The order can be defined by the phone based on the allowed codecs. That's ok
for me. It's just important to remove each codec which is not on the allow list.
2. On Bob's outgoing leg, after reconciling what came from the core and
Bob's endpoint, we can also sort based on either and send that in the offer.
Based on the fact, that only the allowed codecs are contained in the offer and
furthermore based on the fact, that each phone must be able to handle the
codecs it advertises /
accepts -> fine with me.
3. Bob can re-order the formats in his answer so I guess we need another
option to use the order we sent or the order we received before we send it
back to the core. Do we care about the order we got *from* the core or on
Bob's endpoint any more? Hopefully not.
No - keep the formats based on the received order - but remove the not allowed
codecs.
4. Now we've got a list from the core and we need to send an answer back
to Alice... Do we need any sort alterations at all here or can we just use
what came from the core?
Goal is to find a codec supported by both just to prevent transcoding. Therefore
use the first codec based on the order of the initial call of Alice. If there is
no common codec ->
transcode between the first codec in the list on both lines.
One more thing to consider... Alice and Bob may *not* both be using a
pjsip channel. In this case, the process can only be applied on the call
leg that *is* pjsip. Let's say that Alice's leg is pjsip and Bob's isn't.
We can make Alice's channel aware that Bob isn't capable of the advanced
codec process but only after Bob's channel has been created so the process
Alice runs when passing the list to the core won't know. The process that
runs when constructing Alice's answer *will* know by virtue of *not getting
anything* from the core because today there's no feedback at all from the
core. On the flip side, if Alice is chan_sip and Bob is chan_pjsip, Bob
*will* know whether what came from the core is "advanced" or not. Now the
question is, given all that's talked about above, do the rules change
depending on whether both channels are pjsip or not? Of course, if
*neither* is pjsip, none of the above applies and the old process is used.
I would say: The new process can be used only if all call legs are ruled by pjsip.
If one call leg is not ruled by pjsip -> use the traditional process.
I know this is a lot to take in but I'd implore you to read thoroughly,
respond with real life scenarios and ask questions if something isn't
clear. We are NOT going to shove this into 18 without everyone
understanding the implications, and if the process gets too complex, we'll
NEVER put it in because it'll work no better and be no better understood
than the current process.
Well, there must be principles as written above. If those are kept, I can't see
any problem at the moment - it seems to me pretty simple.
Some examples:
1) Drop call
Alice: g722/g711
Asterisk allow: g729
=> all calls from and to Alice will be dropped. It's just a misconfiguration ->
admins fault. It's not the job of asterisk to repair it.
2) Prevent transcoding
Alice: g722/g711
------------------------------------
Asterisk Alice allow: g729/g711/g722
Asterisk Bob allow: g722/g711/g726
------------------------------------
Bob: gsm/g729/g711/g722
Alice calls Bob:
- Asterisk drops g729 on the possible list of used codecs for this call leg
based on the offer of Alice.
- Asterisk sends to Bob: g722/g711/g726 (it's always Bobs allow list based on
the order of Alice's offer)
- Bob sends to Asterisk: gsm/g729/g711/g722 - Asterisk drops gsm and g729
(because not on the allow list). g711/g722 is given to the core to compare and
find the chosen codec: Result
will be: g722 (based on the order of the incoming call leg g722/g711). If you
would have preferred the outgoing call leg, the resulting common codec would
have been g711.
3) Transcoding example
Alice: g729
------------------------------------
Asterisk Alice allow: g722/g711/g729
Asterisk Bob allow: g722/g711
------------------------------------
Bob: gsm/g729/g711/g722
Alice calls Bob:
- Asterisk drops g711/g729 on the possible list of used codecs for this call
leg based on the offer of Alice.
- Asterisk sends to Bob: g722/g711 (it's always Bobs allow list based on the
order of Alice's offer - if possible :-))
- Bob sends to Asterisk: gsm/g729/g711/g722 - Asterisk drops gsm and g729
(because not on the allow list). g711/g722 is given to the core to compare and
find the chosen codec: In
this case, the call is transcoded between g729 and g711 (because there is no
common codec between both call legs and transcoding usually is better than
dropping - but this decision
may be switchable).
Hope this helps!
Thanks
Kind regards
Michael
[1]
https://wiki.asterisk.org/wiki/display/AST/Asterisk+18+Codec+Negotiation+Proposal
