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

[Asterisk Team (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-29182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=252845#comment-252845 ] 

Asterisk Team commented on ASTERISK-29182:
------------------------------------------

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/].

> 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: 16.15.0, 18.1.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)