Re: [rtcweb] Data channel setup and signalling

[Hadriel Kaplan <[e-mail]>]

On Nov 15, 2011, at 1:42 AM, Randell Jesup wrote:

> The signalling discussion and how it touched on data channels got me thinking.
> 
> One open issue is how we define data channels, both in the "internal" case (no interop) and the federated case (which may have the same JS app or different ones at either end).

Well one question is if there should be two different ways for doing it to begin with. :)
I think it's obvious that from a practical perspective there'll be tons of web-app data-channel usage which will only be in the same WebRTC domain. But I don't see how we can honestly create a SDP media attribute to mean "void".

Months ago when I was arguing against putting SDP in the browser, I pointed out that using SDP means using SDP and being stuck with actually following SDP, including IANA registries, having to be *real* SDP which can go anywhere, etc.

Maybe we do something like:
  m=application 1234 UDP/DTLS/SCTP/APP *
  a=app-type:www.mydomain.com



> One solution is that all data channels are defined as m= lines.  They could be generic "m=data", or they could specify the data to be passed in the m= line.  For "public" message structures that might be used by different applications (an IM protocol, for example), one would specify that in some manner in the media description (perhaps via a MIME type).  This also implies that any addition or removal (or change to) a data channel requires a full replacement OFFER and ANSWER.  If we stick with the SDP requirement about never removing m= lines, then the OFFER size may become unbounded.

I'm not sure the above is a problem: you can re-use m-lines.

-hadriel