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

["Ejzak, Richard P (Richard)" <[e-mail]>]

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