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

[Paul Kyzivat <[e-mail]>]

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.
>
> 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.

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>