Subject: [MMUSIC] [dispatch] SDP negotiation of data channel sub-protocols

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 7 Nov 2013 04:54:51 +0000

Please excuse this one-time cross-posting but I understand that this issue and the following drafts now move from dispatch to MMUSIC.  Please respond only on the MMUSIC list.

draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt
draft-ejzak-dispatch-msrp-data-channel-00.txt

At the mike, Hadriel Kaplan proposed an alternative approach to the one I presented in dispatch yesterday (and in the first draft above), and I hope to get consensus on the list regarding which approach I should document going forward.

Hadriel's proposal is to represent each data channel to be negotiated with SDP with its own m line and use BUNDLE to link them together onto a single SCTP association.  This is in contrast to the proposal in the draft that keeps all the information about data channels within a single m line.

I think Hadriel's proposal has some significant disadvantages:

1)      BUNDLE would need to be extended to add this new form of muxing, just to put Humpty Dumpty back together again.

2)      This approach requires WebRTC browsers to deal with tracking multiple m lines representing a single SCTP association; else the application has to implement the BUNDLE extensions for data channels.

3)      It makes the gateway scenario simpler at the cost of complicating the direct e2e scenario.

4)      It unnecessarily adds additional requirements on an important rtcweb dependency (BUNDLE) to support this work.

There are some advantages to Hadriel's scheme (simplifies gateway scenarios, more closely resembles current SDP usage of sub-protocol attributes), but the disadvantages seem more significant to me.

Comments, please?

Richard

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Nov 2013 21:44:49 -0800

On 11/6/13 8:54 PM, Ejzak, Richard P (Richard) wrote:
> Please excuse this one-time cross-posting but I understand that this
> issue and the following drafts now move from dispatch to MMUSIC.  Please
> respond only on the MMUSIC list.
>
> At the mike, Hadriel Kaplan proposed an alternative approach to the one
> I presented in dispatch yesterday (and in the first draft above), and I
> hope to get consensus on the list regarding which approach I should
> document going forward.
>
> Hadriel’s proposal is to represent each data channel to be negotiated
> with SDP with its own m line and use BUNDLE to link them together onto a
> single SCTP association.  This is in contrast to the proposal in the
> draft that keeps all the information about data channels within a single
> m line.

If SDP had a richer syntax (e.g., a recursive structure like XML), then 
I think this would be a good idea.

But given the syntax bounds we must live within I don't think it flies.
We are already stretching things a lot to get Bundle to work in the 
current form. And we haven't yet extended Bundle to include the data 
channel SCTP m-line. (That is a desire of RTCWEB.)

If we attempted to also bundle data channels, then we would end up with 
the following (not using SDP syntax):

Bundle(
   rtp m-line
   rtp m-line
   ...
   Bundle(
     sctp m-line
     channel m-line
     channel m-line
     ...
   )
)

I really don't want to even think about how to do that in SDP.

Also, if we really thought this was the right thing to do, then it would 
probably be right to have separate m-lines for each SCTP port 
multiplexed on the same UDP port. That would give yet another level of 
nesting!

	Thanks,
	Paul

> I think Hadriel’s proposal has some significant disadvantages:
>
> 1)BUNDLE would need to be extended to add this new form of muxing, just
> to put Humpty Dumpty back together again.
>
> 2)This approach requires WebRTC browsers to deal with tracking multiple
> m lines representing a single SCTP association; else the application has
> to implement the BUNDLE extensions for data channels.
>
> 3)It makes the gateway scenario simpler at the cost of complicating the
> direct e2e scenario.
>
> 4)It unnecessarily adds additional requirements on an important rtcweb
> dependency (BUNDLE) to support this work.
>
> There are some advantages to Hadriel’s scheme (simplifies gateway
> scenarios, more closely resembles current SDP usage of sub-protocol
> attributes), but the disadvantages seem more significant to me.
>
> Comments, please?
>
> Richard
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 07 Nov 2013 07:39:58 +0100

On 11/07/2013 06:44 AM, Paul Kyzivat wrote:
> If SDP had a richer syntax (e.g., a recursive structure like XML),
> then I think this would be a good idea.
>
> If we attempted to also bundle data channels, then we would end up
> with the following (not using SDP syntax):
>
> Bundle(
>   rtp m-line
>   rtp m-line
>   ...
>   Bundle(
>     sctp m-line
>     channel m-line
>     channel m-line
>     ...
>   )
> )
>
> Also, if we really thought this was the right thing to do, then it
> would probably be right to have separate m-lines for each SCTP port

I agree with Paul here.

For normal (as I think of it) WebRTC usage, we want one m-line to
describe the SCTP association, and the channels are completely invisible.

Richard's proposal makes the channels visible, but otherwise retains the
syntax of the WebRTC usage.

Having an alternate SDP description of an SCTP association would add
parsing complexity, reduce interoperability and generally be a pain in
the posterior.

Let's just not go there.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 7 Nov 2013 13:14:20 -0500

I had assumed the proposal was to make this draft-thing usable in SIP or other protocols, not just WebRTC.  True?  If not true, and this is only for WebRTC, then yeah do whatever and please ignore this email.

Technically SCTP is a transport, not a media type.  By having multiple sctp-based application/media types in the same m-line, it's semantically equivalent to putting audio+video in the same m-line.  Even your example SDP in the draft shows this, since MSRP is a "message" media type while one of the others is a "application" one.

To put this more concretely, pretend that we had standardized not only MSRP, BFCP, and T.38 fax to run over SCTP, but also video and audio too.  Maybe not real-time video, but rather TV-style streaming of video or whatever.  So now you'd have SDP with one m-line for "SCTP" with audio, video, message, and application types within it.

I'm ok if the group consensus is to do it anyway, but my point at the mic was to make this more obvious to people - that by doing this, SDP semantics are not being consistent.  I realize that consistency no longer matters at the altar of WebRTC expediency, but just thought it should be pointed out... if for no other reason than to have this stored in the email archives.

-hadriel

On Nov 6, 2013, at 11:54 PM, "Ejzak, Richard P (Richard)" <[email-masked]> wrote:

> Hadriel’s proposal is to represent each data channel to be negotiated with SDP with its own m line and use BUNDLE to link them together onto a single SCTP association.  This is in contrast to the proposal in the draft that keeps all the information about data channels within a single m line.
>  
> There are some advantages to Hadriel’s scheme (simplifies gateway scenarios, more closely resembles current SDP usage of sub-protocol attributes), but the disadvantages seem more significant to me.
>  
> Comments, please?
>  
> Richard
>  
>  
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 7 Nov 2013 13:33:54 -0500

> describe the SCTP association, and the channels are completely invisible.

Sure for WebRTC, of course that's true - because they're all one media type: application.  Only the application above (the one in JS) knows what's in the specific SCTP channels, right?  My comment at the mic about this was for non-WebRTC cases, such as if we were to standardize MSRP, BFCP, fax, etc. on SCTP. (or at least that's what I thought Richard's proposal was for, but I could be misunderstanding it)

-hadriel

---

From: Mary Barnes <[email-masked]>
Date: Thu, 7 Nov 2013 12:38:49 -0600

On Thu, Nov 7, 2013 at 12:33 PM, Hadriel Kaplan
<[email-masked]>wrote:

> Sure for WebRTC, of course that's true - because they're all one media
> type: application.  Only the application above (the one in JS) knows what's
> in the specific SCTP channels, right?  My comment at the mic about this was
> for non-WebRTC cases, such as if we were to standardize MSRP, BFCP, fax,
> etc. on SCTP. (or at least that's what I thought Richard's proposal was
> for, but I could be misunderstanding it)
>
> [MB] The intent is for this to support non-WebRTC cases.  CLUE is another
example that could use this mechanism.

This is the proposed deliverables:

 – Define generic SDP procedures to enable external negotiation of
DataChannel transport for sub-protocol sessions, and to enable negotiation
of sub-protocol specific options.

– Describe how to use the generic SDP procedures negotiate DataChannel
transport for specific protocols, potentially including

MSRP, BFCP, T.140, T.38 and the CLUE control protocol.

I think part of the confusion is that the drafts were originally very
WebRTC centric.
[/MB]

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Nov 2013 11:00:25 -0800

Hadriel,

Did you see my reply to Richard?
In principle I agree with you, but in practice I don't think it is 
feasible to go that way.

The audio/video/application thing merely reflects a case where SDP got 
it wrong in the first place. Technically codecs are identified by a 
mime-type/subtype, but the type is put in the type field of the m-line, 
and the subtype is put either into the format field of the m-line or 
into an attribute.

When doing it over in a new context we can simply represent it as 
type/subtype.

	Thanks,
	Paul