W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2016

Re: Codec PT mismatch during renegotiation, valid or not?

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Thu, 8 Sep 2016 12:37:04 +0200
Message-ID: <CALiegfnLouMbDGpAmLSOpGZ9XqERE-GeC8TOB575jAVkvC4Hbw@mail.gmail.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
NOTE: I've been suggested to report this in rtcweb mailing list. Done.
Please, ignore this thread.

2016-09-08 12:22 GMT+02:00 Iñaki Baz Castillo <ibc@aliax.net>:
> Hi,
>
> The following scenario causes setLocalDescription() to fail after
> renegotiation because the re-offerer (Firefox) introduces new codec PT
> in the same m= lines):
>
>
>
> 1) Chrome calls to Firefox with an audio track. SDP offer (simplified):
>
> m=audio 58234 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
> a=setup:actpass
> a=mid:audio
> a=sendrecv
> a=rtcp-mux
> a=rtpmap:111 opus/48000/2
> a=rtcp-fb:111 transport-cc
> a=fmtp:111 minptime=10;useinbandfec=1
> a=rtpmap:103 ISAC/16000
> a=rtpmap:104 ISAC/32000
> a=rtpmap:9 G722/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:106 CN/32000
> a=rtpmap:105 CN/16000
> a=rtpmap:13 CN/8000
> a=rtpmap:126 telephone-event/8000
>
>
>
> 2) Firefox SDP answer:
>
> m=audio 65515 UDP/TLS/RTP/SAVPF 111
> a=recvonly
> a=fmtp:111 maxplaybackrate=48000;stereo=1
> a=mid:audio
> a=rtcp-mux
> a=rtpmap:111 opus/48000/2
> a=setup:active
>
> Firefox has chosen PT 111 (opus). Fine.
>
>
>
> 3) Firefox re-offers with its own audio track. SDP re-offer:
>
> m=audio 65515 UDP/TLS/RTP/SAVPF 109 9 0 8 111
> a=sendrecv
> a=fmtp:111 maxplaybackrate=48000;stereo=1
> a=mid:audio
> a=rtcp-mux
> a=rtpmap:109 opus/48000/2
> a=rtpmap:9 G722/8000/1
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:111 opus/48000/2
> a=setup:actpass
>
> Here Firefox has introduced a new PT value: 109 (also opus). Note that
> PT 111 (opus) is also present.
>
>
>
> 4) Chrome gets the SDP re-offer, calls setRemoteDescription()
> (success) and calls createAnswer(), which produces the following SDP
> answer:
>
> m=audio 58234 UDP/TLS/RTP/SAVPF 109 9 0 8
> a=setup:passive
> a=mid:audio
> a=sendrecv
> a=rtcp-mux
> a=rtpmap:109 opus/48000/2
> a=fmtp:109 minptime=10;useinbandfec=1
> a=rtpmap:9 G722/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
>
> Note that Chrome has chosen PT 109 (opus) instead of the previously
> used PT 111 (opus).
>
>
>
> 5) Such a call to setLocalDescription() in Chrome produces this error:
>
>> Uncaught OperationError: Failed to set local answer sdp: Session error code: ERROR_CONTENT. Session error description: Failed to set local audio description recv parameters.
>
>
>
> So my main question is: can an endpoint perform a PeerConnection
> renegotiation and introduce new PT values within an existing m= line?
> AFAIR this is NOT valid.
> - If valid, then this is a Chrome bug.
> - If invalid, then this is a Firefox bug.
>
>
> Thanks a lot.
>
>
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>



-- 
Iñaki Baz Castillo
<ibc@aliax.net>
Received on Thursday, 8 September 2016 10:38:00 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:49 UTC