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

Sorry I'm late to the thread, but this issue already has Chrome and Firefox
bugs:

https://bugs.chromium.org/p/webrtc/issues/detail?id=5847
https://bugzilla.mozilla.org/show_bug.cgi?id=1247725

In short, we came to the same conclusion back then as we came to now. Which
is that Firefox offering two payload types is allowed but not necessary,
but Chrome failing to do SLD with an answer it creates is clearly an issue.

On Thu, Sep 8, 2016 at 10:29 AM, Cullen Jennings <fluffy@iii.ca> wrote:

> It also looks like it might be an bug^H^H^H "unintended feature" in FF.
> Sort of weird it offer the 2nd opus. I wonder why it does that.
>
>
>
> > On Sep 8, 2016, at 4:55 AM, Harald Alvestrand <hta@google.com> wrote:
> >
> > It's a for sure a Chrome bug that it doesn't allow setLocalDescription
> with SDP that it produces itself. That's supposed to always work (in the
> case of no changes to local state or to the SDP).
> >
> > So do file a bug for it. https://crbug.com/
> >
> > On Thu, Sep 8, 2016 at 12:37 PM, Iñaki Baz Castillo <ibc@aliax.net>
> wrote:
> > 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>
> >
> >
>
>
>