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

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 26 Feb 2014 18:59:26 +0000

+ mmusic
- rtcweb (in bcc)

Hi Paul,
I wanted to close this email loop. Please see my inline comments.

> >
> > [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).
> 
> In some cases. But in general it is easy and common to define a protocol
> that needs a reliable transport, and it won't work without one.
> 
> What if every application in the world that uses TCP had the option to
> specify if it was reliable or not? How many would screw it up?
> 
[Raju] 
Application subprotocol users need to know the transport needs for the protocol and select a single transport if multiple options exist. This is similar to how users select TCP or UDP when implementing any Layer5 protocol (e.g. SIP) on top of Layer 4.

If APIs abstract this subprotocol then the transport selection can be hidden under the API (if only one choice exists) and API user won't have to specify a transport. 

We really appreciate your time in providing valuable comments on these drafts!

Best Regards!
Raju

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Feb 2014 19:53:55 +0000

Hi,

>I wanted to close this email loop. Please see my inline comments.

I am ok closing it for now - but I still have a different opinion :)

>> data channel transport properties. Yes, they may have some 
>> correletion with
>> In some cases. But in general it is easy and common to define a 
>> protocol that needs a reliable transport, and it won't work without one.
>> 
>Application subprotocol users need to know the transport needs for the protocol and select a single >transport if multiple options exist. This is similar to how users select TCP or UDP when >implementing any Layer5 protocol (e.g. SIP) on top of Layer 4.

RFC 3261, i.e. the "sub-protocol specification", defines the characteristics when using TCP or UDP for SIP. There is no mechanism in UDP or TCP to negotiate SIP timers.

I DO buy the argument that, when using DCP, there may not be a registered sub-protocol to begin with, so this type of low-level information needs to be negotiated.

BUT, when using draft-ejzak my assumption is that people will indicate the sup-protocol.

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 26 Feb 2014 20:18:46 +0000

Hi,
Please see my comments inline.

> I am ok closing it for now - but I still have a different opinion :)

[Raju] There won't be much fun if we all agree on everything. Isn't it?! :-)

> >Application subprotocol users need to know the transport needs for the
> protocol and select a single >transport if multiple options exist. This is
> similar to how users select TCP or UDP when >implementing any Layer5
> protocol (e.g. SIP) on top of Layer 4.
> 
> RFC 3261, i.e. the "sub-protocol specification", defines the characteristics
> when using TCP or UDP for SIP. There is no mechanism in UDP or TCP to
> negotiate SIP timers.

[Raju] What you said is correct! However, int his case DCP does negotiate these timers inband. The external negotiation is simply providing similar mechanism so that both peers have same data channel properties (similar to DCP).

Thanks
Raju

> 
> I DO buy the argument that, when using DCP, there may not be a registered
> sub-protocol to begin with, so this type of low-level information needs to
> be negotiated.
>