Re: [rtcweb] draft-ietf-rtcweb-jsep-05

I would just like to say that I agree with the points raised by Paul and Partha here that it has to be possible for the application to create an offer with a complete set of current capabilities.  The reason for this is of course interoperability with existing SIP implementations which need this.  Having to create a new peer connection and force use of INVITE with replaces doesn’t work well with existing implementations and would be a high cost to pay for what is hopefully a simple API constraint to create a full offer.

Regards
Andy

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Parthasarathi R
Sent: 04 November 2013 09:44
To: 'Justin Uberti'; 'Paul Kyzivat'
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers

Justin,

As the signaling is not defined in WebRTC, it is not possible to assume that the remote side capabilities will not change between browser to browser scenario as well.  RTCWeb Server shall transfer the session using RE-INVITE equivalent functionality.

Re-INVITE without offer is a power tool in SIP for getting the capabilities before selecting the final codec. It shall be used to initiate the offer from the remote side. One of the INIVTE/Re-INVITE without offer usecase in WebRTC shall be used to get ICE-TCP candidate from the browser wherein the incoming TCP connection is forbidden by the firewall.

Thanks
Partha

From: rtcweb-bounces@ietf.org<mailto:rtcweb-bounces@ietf.org> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Monday, November 04, 2013 12:26 PM
To: Paul Kyzivat
Cc: rtcweb@ietf.org<mailto:rtcweb@ietf.org>
Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers

On Fri, Nov 1, 2013 at 2:45 PM, Paul Kyzivat <pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>> wrote:
Section 5.2.2 (Subsequent Offers) says:

   o  The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST
      only include codecs present in the remote description.

   o  The RTP header extensions MUST only include those that are present
      in the remote description.

   o  The RTCP feedback extensions MUST only include those that are
      present in the remote description.

   o  The "a=rtcp-mux" line MUST only be added if present in the remote
      description.

   o  The "a=rtcp-rsize" line MUST only be added if present in the
      remote description.

Including only codecs that were present in the prior answer is a bad idea. It doesn't play well with SIP. There is no harm in continuing to include all the codecs you support. And it keeps options open for changing codecs later.

The same is true for most other things that are being restricted based on what was in the last answer. (But I won't say that with certainty without checking the semantics of each one.)

For further info, see RFC 6337, especially section 5.1.

According to section 5.2.5, it seems that this is only the cases for offers triggered by offerless reINVITEs. I don't think we want to be re-allocating and negotiating codecs every time we want to make a change to the session descriptions in use.

Generally I think we should consider that the capabilities of the remote side will not change unexpectedly during the call, and so full renegotiation is not needed with each reINVITE. If full renegotiation is needed, use an INVITE-with-replaces, as Cullen has suggested. This avoids complicated cases like having to unBUNDLE in mid-call, or re-reserve codecs that are unlikely to be used.

        Thanks,
        Paul
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb