Subject: [rtcweb] #23: Section 4.4 SDP signaling requirement

From: "rtcweb issue tracker" <[email-masked]>
Date: Sun, 25 Aug 2013 22:30:01 -0000

#23: Section 4.4 SDP signaling requirement

 If such RTP session set-up is to be used, this MUST be negotiated during
 the signalling phase [I-D.ietf-mmusic-sdp-bundle-negotiation].

 [BA] What about WebRTC applications that don't use SDP for signaling? Or
 applications that decide to multiplex Audio and Video because they know
 that the peer supports it?  Mandating the use of BUNDLE negotiation on the
 wire doesn't make sense.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-rtcweb-rtp-
  [email-masked]          |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  critical                 |  Milestone:  milestone1
Component:  rtp-usage                |    Version:  1.0
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/23>
rtcweb <http://tools.ietf.org/rtcweb/>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Aug 2013 08:29:52 +0200

>  that the peer supports it?  Mandating the use of BUNDLE negotiation on the

Well, the current API to my understanding only provides SDP in the API
to input and output information related to bundle signaling.

The goal from our perspective is to ensure that features that affects
RTP session configuration are negotiated between the peers in the RTP
session. As interoperability failure will occur if the peers don't agree
on using one RTP session for all media types or using a separate RTP
session per media type this is something that requires negotiation.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "rtcweb issue tracker" <[email-masked]>
Date: Mon, 26 Aug 2013 07:01:36 -0000

Comment (by [email-masked]):

 [Magnus Westerlund]

 [BA] Agree that A/V multiplexing needs to be agreed upon between the
 parties.  The part that is odd is to mandate BUNDLE over the wire.  Maybe
 say "this MUST be agreed upon between the parties.  In SDP Offer/Answer
 this is handled using [I-D.ietf-mmusic-sdp-bundle-negotiation]."

 Severity:  Active WG Document       |  Resolution:
 Keywords:                           |

Ticket URL: <http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/23#comment:1>
rtcweb <http://tools.ietf.org/rtcweb/>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 26 Aug 2013 12:22:19 +0200

> session per media type this is something that requires negotiation.
I think we're pointing at a more general issue here, which is more a 
separation-of-concerns thing than anything else.

With regard to the -rtp-usage- draft, the question can be phrased as:
Should -rtp-usage- make statements about the signalling protocol in use?

My interpretation is clearly "no". We have consensus not to mandate a 
signalling protocol, so it's impossible for -rtp-usage- to make 
normative statements about it.

The next question down is:
Should -rtp-usage- make requirements on the SDP passed across the W3C API?
Again, my interpretation is "no". I could argue both that this is out of 
IETF scope and that -jsep- is the only place that should describe it - 
the two arguments are inconsistent, but both indicate that -rtp-usage- 
is not the right place to make those statements.

Third level is:
Should -rtp-usage- use *informative* references to SDP mechanisms as 
*examples* of how specific features can be negotiated?
My suggestion would be "yes". At the moment, we don't have a better 
description mechanism than the one provided by describing SDP extensions 
that shows clearly how negotiation can occur.
In my opinion, there can be other mechanisms (including "cheating" ones 
like saying "Hey, I know this application I'm talking to, it's only 
going to run on a browser capable of doing X, and it's going to 
configure the browser to use X" - we should NOT standardize such 
mechanisms, but people WILL use them, and suffer the consequences) that 
achieve the goal of configuring the endpoints correctly.

It is a bit onerous to write, instead of

formulating oneself as

  If such RTP session set-up is to be used, both sides MUST agree beforehand on
  its usage. In an SDP context, [I-D.ietf-mmusic-sdp-bundle-negotiation] will achieve this.

But I think it's a more reasonable approach.

---

From: Colin Perkins <[email-masked]>
Date: Mon, 26 Aug 2013 16:08:37 +0100

On 26 Aug 2013, at 11:22, Harald Alvestrand <[email-masked]> wrote:
>> Well, the current API to my understanding only provides SDP in the API to input and output information related to bundle signaling.
>> 
>> The goal from our perspective is to ensure that features that affects RTP session configuration are negotiated between the peers in the RTP session. As interoperability failure will occur if the peers don't agree on using one RTP session for all media types or using a separate RTP session per media type this is something that requires negotiation.
> I think we're pointing at a more general issue here, which is more a separation-of-concerns thing than anything else.
> 
> My interpretation is clearly "no". We have consensus not to mandate a signalling protocol, so it's impossible for -rtp-usage- to make normative statements about it.
> 
> Again, my interpretation is "no". I could argue both that this is out of IETF scope and that -jsep- is the only place that should describe it - the two arguments are inconsistent, but both indicate that -rtp-usage- is not the right place to make those statements.
> 
> Third level is:
> Should -rtp-usage- use *informative* references to SDP mechanisms as *examples* of how specific features can be negotiated?
> My suggestion would be "yes". At the moment, we don't have a better description mechanism than the one provided by describing SDP extensions that shows clearly how negotiation can occur.
> In my opinion, there can be other mechanisms (including "cheating" ones like saying "Hey, I know this application I'm talking to, it's only going to run on a browser capable of doing X, and it's going to configure the browser to use X" - we should NOT standardize such mechanisms, but people WILL use them, and suffer the consequences) that achieve the goal of configuring the endpoints correctly.
> 
> If such RTP session set-up is to be used, this MUST be negotiated during the signalling phase [I-D.ietf-mmusic-sdp-bundle-negotiation].
> 
> formulating oneself as
> 
> If such RTP session set-up is to be used, both sides MUST agree beforehand on its usage. In an SDP context, [I-D.ietf-mmusic-sdp-bundle-negotiation] will achieve this.
> 

I'm not sure about the precise wording, but I agree with the principle, and will try to clarify this in the next version of the draft.

-- 
Colin Perkins
http://csperkins.org/

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 26 Aug 2013 10:43:16 -0700

> normative statements about it.
[BA] I agree. 
> is not the right place to make those statements.
[BA] I agree with this as a general principle (and not just for rtp-usage). Keeping the RTP usage document focused on RTP and removing thingsthat don't need to be there will allow us to complete it more quickly,and with fewer dependencies on other documents.  That also will makethis and other documents easier to maintain. 
> But I think it's a more reasonable approach.

[BA] Yes, something like this is what I had in mind.