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

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)" <richard.ejzak@alcatel-lucent.com> 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.
>  
> 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
>  
>  
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch