Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00

["Makaraju, Maridi Raju (Raju)" <[e-mail]>]

Hi Paul,

Please see comments inline.

> Christer - comment at end
> 
> On 2/25/14 4:08 AM, Christer Holmberg wrote:
> > Hi Raju,
> >
> >>> Anyway, can you give me an example of a case where you want to use
> >>> SDP, and where you need to negotiate the re-transmission values etc?
> >>
> >> [Raju] A simple example would be 2 browsers talking thru an intermedia
> proxy, which wants to know what protocols are
> >> being negitiated and used as part of the session.
> >
> > Sure. I don't question the use-case/need for using SDP to negotiate
> channel usages.
> >
> >> 1. Calling client creates data channel (using
> http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel)
> with desired
> >> attributes and sets negotiated=true. So, calling browser saves the
> attributes for the data channel but won't use DCP.
> >> 2. These attributes are sent via SDP to peer client (via proxy).
> >> 3. Peer client sets these same attributes while creating data channel and
> sets negotiated=true but won't do DCP.
> >> 4. Peer client echo the same attributes back in SDP answer.
> >>
> >> Now, data channel stacks on both ends will use same attributes, similar
> to DCP use case, with the only difference being DCP is not used here.
> >
> > My question was regarding the re-transmission values etc.
> >
> > Why do the peers need to negotiate those? Why would an intermediary need
> to know about those? Why not simply define those in the protocol
> description, and each endpoint supporting the protocol will then know what
> values to use?
> 
> IIUC, the webrtc people are "humoring* us by making provision for
> registered subprotocol names, and using SDP to negotiate channels. I
> suspect that for the most part they have no intention of using those.
> (The subprotocol name is *optional*.)
> 
> So these parameters are needed to properly initialize a channel when the
> subprotocol is not specified.

[Raju] If I understand correctly, these parameters simply define the 
data channel transport properties. Yes, they may have some correletion with 
subprotocol, but that's not a one-to-one mapping.
For example, a given subprotocol could run on a reliable or 
unreliable transport; depending on app needs it may use unreliable 
transport and deal with reliablity at subprotocol stack (or ignore it).

> 
> Also, we still have an open question about what attributes must be
> present in a subprotocol specification. It is at least possible that
> some subprotocols may work with a variety of settings of these attributes.

[Raju] Right, this fits into my explanation above.

> 
> This draft should probably say more about this. It could say that:
> 
> * the SDP MUST be consistent with the attributes specified in the
> subprotocol definition, OR
> 
> * the SDP MUST NOT specify attributes specified in the subprotocol
> definition, OR
> 
> * attributes specified in the SDP override those specified in the
> subprotocol definition.

[Raju] Good point. I like item 1 above; sure we can add it to this 
draft. Then individual subprotocol drafts 
(e.g. draft-ejzak-dispatch-msrp-data-channel-00) could get into the
details of what that consistency is.

Best Regards
Raju