I have Asterisk 13.21 with PJSIP endpoints A and B.
In order to enable all the supported audio and video codecs, allow=all parameter is set for both endpoints.
A call is coming from endpoint A and is routed to endpoint B according to the dialplan.
Could you clarify in which order codecs in outgoing INVITE towards endpoint B are announced:
Asterisk respects the order in SDP received from endpoint A, or
Asterisk sends codecs in some fixed order?
If the latter is correct, where is this order defined?
The codec negotiation for chan_sip was the following
; Codec negotiation
;
; When Asterisk is receiving a call, the codec will initially be set to the
; first codec in the allowed codecs defined for the user receiving the call
; that the caller also indicates that it supports. But, after the caller
; starts sending RTP, Asterisk will switch to using whatever codec the caller
; is sending.
;
; When Asterisk is placing a call, the codec used will be the first codec in
; the allowed codecs that the callee indicates that it supports. Asterisk will
; *not* switch to whatever codec the callee is sending.
it is documented on the sip sample file, I dont know if for pjsip it is the same , it will be needed a sip trace to determine it
Thank you @ambiorixg12
The first thing (as you noticed) is that this instruction is related to chan_sip.
The other is that "When Asterisk is placing a call, the codec used will be the first codec in the allowed codecs " - but what is the order if allow=all parameter is set?
If no-one knows it for sure, I will set up this simple config in a lab and collect traces.
I don’t think there really is a defined/documented/guaranteed order for “allow=all”. For most people you should explicitly specify codecs, which defines the preference order.
Thank you @jcolp
So, to allow all the codecs in a predictable order, I should take them from core show codecs and list explicitly?
Is there any way to respect the order of the codecs received from the originating party? Or Asterisk as a pure B2BUA will not respect it?
For outgoing that may be correct these days - there were times where it flip flopped back and forth as things developed. They are still independently negotiated, though.
So in doing this, do you use the NAME column or FORMAT column? I’d assume the latter since there are many duplicates in the former.
Is there any generally accepted preference list, in terms of good, better, best codecs to use? Isn’t the graph on this page basically demonstrating that opus is the best codec to use if both ends support it?
Complex codecs can impose significant CPU loads, if the media has to be manipulated or analyzed in any way.
There is quite a lot of overhead on RTP over UDP over IP over, PPP over DSL and anything that goes over the PSTN will be limited to A or mu-law G.711 quality. That means the savings in bandwidth may not be particularly high, and also the improvements in quality may be wasted, and the result may be marginally worse overall.
Complex codecs have difficulty with signals intended for machine consumption, and, at low bit rates, can have difficulty with music (because they assume speech).
Packet loss may have a bigger impact with complex codecs, or reduce other advantages.
That means that one needs to consider the complete requirement. Complex codecs like Opus are probably most useful for calls between executives in an organisations. They are of limited benefit if most calls originate on the PSTN, and even less so if most originate as standard mobile phone calls.
So it seems like Asterisk could take more into account in selecting the best codec than just an ordered list for an endpoint.
I.e. if a call is set up between a single endpoint and Asterisk, a higher quality codec would be useful (at least not wasted). But if a call is set up between an endpoint that can use opus and a ITSP that is bridging calls from the PSTN, using G.711u there is no point in using opus with that endpoint.
So ideally Asterisk needs to be making the best choices for each call, not just each endpoint. Yes?