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

[Alexander Traud (JIRA)]

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

Alexander Traud commented on ASTERISK-29182:
--------------------------------------------

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.

> 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: Core/CodecInterface
>    Affects Versions: 16.15.0, 18.1.0
>            Reporter: Alexander Traud
>            Severity: Minor
>
> 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)