[asterisk-bugs] [JIRA] (ASTERISK-29182) Audio/Video Codecs: Alternative formats get lost.

[Alexander Traud (JIRA)]

Alexander Traud created ASTERISK-29182:
------------------------------------------

             Summary: Audio/Video Codecs: Alternative formats get lost.
                 Key: ASTERISK-29182
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29182
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: . I did not set the category correctly.
    Affects Versions: 18.1.0, 16.15.0
            Reporter: Alexander Traud


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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)