Subject: [rtcweb] Codecs in re-offer [PR #269]

From: Andy Hutton <[email-masked]>
Date: Wed, 27 Jul 2016 15:36:59 +0100

The issue of whether a re-offer in WebRTC must be limited to the set of
codec's within the previously negotiated envelope was discussed during
IETF96 but I don't think a conclusion was reached.

Justin mentioned that this had been discussed previously so sorry for
bringing it up again I cannot remember all the old arguments and a quick
search did not find that discussion.

Personally I don't get the argument for making this a restriction in WebRTC
even if there are potential workaround solutions like creating a new PC. As
was mentioned in the meeting there are ways around the toggling of codec's
depending on who creates the next offer without imposing a restriction
which is likely to be a cause of interoperability issues.

At a minimum I would suggest that WebRTC implementations must be able to
receive and process and offer/answer which is not within the previously
negotiated envelop and that should be stated something in JSEP.  However I
think it would also be preferable if the re-offer could contain the full
set of capabilities.

Regards
Andy

---

From: Roman Shpount <[email-masked]>
Date: Wed, 27 Jul 2016 12:00:29 -0400

I agree that re-offer should contain the full set of codecs or this will
cause interesting problems with 3pcc or SIP interop. The order of codecs
should ideally be the same as currently negotiated to avoid codec flips.
Essentially, what this means all supported codecs not currently negotiated
should be added to the end of the offer after the currently negotiated ones.

Regards,

_____________
Roman Shpount

On Wed, Jul 27, 2016 at 10:36 AM, Andy Hutton <[email-masked]>
wrote:

> Personally I don't get the argument for making this a restriction in
> WebRTC even if there are potential workaround solutions like creating a new
> PC. As was mentioned in the meeting there are ways around the toggling of
> codec's depending on who creates the next offer without imposing a
> restriction which is likely to be a cause of interoperability issues.
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Andy Hutton <[email-masked]>
Date: Thu, 28 Jul 2016 11:44:39 +0100

I found the original discussion which mainly occurred in GitHub at
https://github.com/rtcweb-wg/jsep/issues/266 but I could not find any
conclusion to this on the mailing list.

IMHO we have got this wrong and need to think again the default case should
be that an offer contains the full set of capabilities not what was
previously negotiated. In the GitHUB #266 discussion a use case is
mentioned in which the application (SFU) wants to initiate a new
offer/answer because something changed such as a new party joining a
conference.  In this scenario it may be that the applications wants the
endpoint and not the SFU to generate the offer because it wants the full
set of capabilities to be re-negotiated, this is common in existing SIP
scenarios.

The default behavior in JSEP should be for the offer to contain the full
set of capabilities of the endpoint.

Regards
Andy