[Home]

Summary:ASTERISK-29182: Audio/Video Codecs: Alternative formats get lost.
Reporter:Alexander Traud (traud)Labels:
Date Opened:2020-11-27 08:13:44.000-0600Date Closed:
Priority:MajorRegression?
Status:Open/NewComponents:Core/CodecInterface
Versions:16.15.0 18.1.0 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Some codecs create incompatible media formats. Therefore†, some user agents offer several formats of that codec. When Asterisk plays a Back-to-Back User Agent ([B2BUA|https://en.wikipedia.org/wiki/Back-to-back_user_agent]), Asterisk presents not all but just one of those alternatives on egress.

chan_sip picks the lowest media format ID. It is not the order of the media formats; it is just the ID. chan_pjsip picks the first media format (of the m= line).

The most specialized media format is the better one (less bandwidth, more quality). And that is preferred. Therefore, user agents put that first in their SDP offer, often with a lower ID.

For example, with the video-codec H.264, Asterisk might pick the more specialized, the incompatible media format. And indeed, it does. Let us have a look at the Cisco IP Phone 8865 with Multiplatform Firmware (MPP). With that, with default configuration settings, chan_pjsip forwards the "wrong" format, not the H.264 Basic Profile but the H.264 High Profile not everyone understands. Consequently, a video call can be established only if the "right" party starts the call.

Similar drama happens with iLBC, 3GPP-EVS, AMR-WB, and AMR. With audio codecs, it is not that dramatic because the call falls back to another audio codec like G.722 or G.711. With video however, it is yes or no. Below is the SDP of the Cisco IP Phone 8865:{code}v=0
o=- 14251 14251 IN <ip address>
s=-
c=IN <ip address>
b=AS:4064
t=0 0
m=audio 16416 RTP/AVP 0 8 9 18 97 105 96 103 99 101 107 108
b=TIAS:64000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:18 G729a/8000
a=fmtp:18 annexb=yes
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=rtpmap:105 iLBC/8000
a=fmtp:105 mode=30
a=rtpmap:96 AMR-WB/16000
a=fmtp:96 channels=1;octet-align=0;mode-change-capability=2;mode-change-neighbor=0;crc=0;robust-sorting=0;interleaving=0;max-red=0
a=rtpmap:103 AMR-WB/16000
a=fmtp:103 channels=1;octet-align=1;mode-change-capability=2;mode-change-neighbor=0;crc=0;robust-sorting=0;interleaving=0;max-red=0
a=rtpmap:99 OPUS/48000/2
a=fmtp:99 maxplaybackrate=16000;sprop-maxcapturerate=16000;maxaveragebitrate=64000;stereo=0;sprop-stereo=0;usedtx=0
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:107 telephone-event/16000
a=fmtp:107 0-15
a=rtpmap:108 telephone-event/48000
a=fmtp:108 0-15
a=ptime:20
a=sendrecv
m=video 16418 RTP/AVP 112 111 110
b=TIAS:4000000
a=rtpmap:112 H264/90000
a=fmtp:112 profile-level-id=640c16;packetization-mode=1;max-fs=3600;max-mbps=108000
a=rtpmap:111 H264/90000
a=fmtp:111 profile-level-id=428016;packetization-mode=1;max-fs=3600;max-mbps=108000
a=rtpmap:110 H264/90000
a=fmtp:110 profile-level-id=428016;packetization-mode=0;max-fs=3600;max-mbps=108000
a=imageattr:* recv [x=800,y=480,q=0.60] [x=1280,y=720,q=0.50]
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=sendrecv{code}

*Workaround*
Disable alternative media formats on the ingress user-agent. In the case of Cisco MPP, disable not as ‘user’ but as ‘admin’ via Web interface → Voice → Ext(ension) → (Video configuration) everything except "H264 BP0" (Basic Profile).

† This is a bug in the SDP specification or at least in the RFC process which passes those. Each codec should have (and actually has) one format all parties have to implement, a default. With that, only the specialized alternative(s) should be advertised. If the SDP negotiation fails, everything falls back to the default. Actually, with iLBC and AMR-WB, only one incompatible alternative exists. However, the current situation is, RFCs instruct user agents to offer each alternative they support. Those codecs are offered several times in SDP. That bloats SDP messages. And as shown by this issue, that is incompatible with Asterisk.
Comments:By: Asterisk Team (asteriskteam) 2020-11-27 08:13:47.311-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.

Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/].
By: Kevin Harwell (kharwell) 2020-12-01 11:35:30.945-0600

As to why chan_pjsip chooses the first in the ordered list my guess is it was done that way per [rfc - section-5.14|https://tools.ietf.org/html/rfc4566#section-5.14] <fmt> description, second paragraph:
{quote}
If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt> sub-fields contain RTP payload type numbers.  When a list of payload type numbers is given, this implies that all of these payload formats MAY be used in the session, but the first of these formats SHOULD be used as the default format for the session.
{quote}
_SHOULD_, of course is the unfortunate key word there.

This teeters on an improvement, but as this may break expectations from those coming from chan_sip, and also how some endpoints handle negotiations I can see how it could be interpreted as a bug too.
By: Alexander Traud (traud) 2020-12-01 12:00:52.635-0600

Well, I know that paragraph. And yes, that paragraph makes sense if the audio codec had a default to which everyone would fallback. However, the recent IETF documents instruct the SIP User Agent creators to include one format for each incompatible format attribute set. And then, the most specialist format must be first otherwise it is not chosen at all. In other words, there is chaos in the SDP format negotiation within the IETF as well.

Anyway, I do not understand why the severity was reduced here. From within Asterisk, there is no easy workaround available, there is no workaround available at all. For this example, the correct SIP User Agent must be re-configured to make it the video call work (in chan_pjsip). In chan_sip it works out of luck (or Cisco Sipura team knew that and leverages that ‘feature’, as they have an Asterisk mode actually). I am not saying that chan_sip is doing it right. It is chaos because it took me *hours* to figure that out. It just matches the default of Cisco Sipura. Therefore a video call with chan_sip worked in one direction but not in the other direction, and not with chan_pjsip at all.