Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00

Christer Holmberg <> Mon, 24 February 2014 20:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4B8C31A0131 for <>; Mon, 24 Feb 2014 12:15:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oDCMimSsEVhf for <>; Mon, 24 Feb 2014 12:15:39 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 89F671A024D for <>; Mon, 24 Feb 2014 12:15:38 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-bb-530ba8690ddb
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id E6.C0.04853.968AB035; Mon, 24 Feb 2014 21:15:37 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 21:15:36 +0100
From: Christer Holmberg <>
To: "Makaraju, Maridi Raju (Raju)" <>, Richard Ejzak <>
Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00
Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzw//+a7YD//x16EA==
Date: Mon, 24 Feb 2014 20:15:35 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: fi-FI
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM+JvjW7mCu5gg3MTpCwaNl5htXjW28Bq sfZfO7sDs0frs72sHjtn3WX3WLLkJ1MAcxSXTUpqTmZZapG+XQJXxt/Vj9gKTqhUzL7bwNjA eE22i5GTQ0LARGJX93MWCFtM4sK99WxdjFwcQgInGCUOPdzICOEsYZQ4+/AlcxcjBwebgIVE 9z9tkAYRgSKJb5//gTUzC6hL3Fl8jh3EFhaIldh9dD0jRE2cxKMH29gh7DCJ3lXz2EBsFgFV iUNH/oPV8Ar4Srw7+oEJYtc2Zol1z+8zgSQ4gQbNe9ELVsQIdN33U2uYIJaJS3w4eJ0Z4moB iSV7zkPZohIvH/9jhbCVJNYe3g51nJ7EjalT2CBsbYllC18zQywWlDg58wnLBEaxWUjGzkLS MgtJyywkLQsYWVYxShanFhfnphsZ6OWm55bopRZlJhcX5+fpFaduYgRG18Etv412MJ7cY3+I UZqDRUmc9zprTZCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxq3Jp5ccelLmNe3dx1sZ513/ SGd1rVfq33/nufTFnJqlhsLzf9VeSdV56HKDP53hK+eRqYZrFzw4mHvrCaNBH+P89ZoREjVB 7C99KiO3Gz8vmft3pbrLOR/rmu8/hC+1hD+KnxS/IPrXi+AzDq6lZ2RrLoR1q22+t/D802qB xIKJc19pVOtx31ViKc5INNRiLipOBACDZA4BfAIAAA==
Cc: "" <>
Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Feb 2014 20:15:40 -0000


I don't see why an SDP based mechanism by default must provide the same capabilities as the DCP. If you need to communicate everything that DCP provides, then you use DCP. Otherwise you may use SDP (or whatever other external mechanism).

OR, you can define a mechanism to communicate low-level information (re-transmission timer values etc) within the protocol that you are going to transport on top of the data channel.

Anyway, can you give me an example of a case where you want to use SDP, and where you need to negotiate the re-transmission values etc?



-----Alkuperäinen viesti-----
Lähettäjä: Makaraju, Maridi Raju (Raju) [] 
Lähetetty: 24. helmikuuta 2014 21:16
Vastaanottaja: Christer Holmberg; Richard Ejzak
Aihe: RE: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00

> >>>> Q4:
> >>>>
> >>>> I have issues with the max_retr, max_time and unordered parameters.
> >>>>
> >>>> First, they seem to specify SENDING capabilities, rather than 
> capabilities.
> >>>>
> >>>> Second, they seem to describe characteristics associated with the
> subprotocol, in which case they could be specified in the associated 
> subprotocol specification.
> >>>
> >>> This should be a topic for discussion in London.  As it is 
> >>> currently
> written, these parameters are of the "take it or leave it" variety, 
> i.e., the answerer either accepts the options listed
> >>> in the offer or rejects the data channel outright.  This is true 
> >>> for the
> in-band control protocol (please correct me if I am wrong on this), so 
> we adopted the same approach for the
> >>> SDP-negotiated case.  Some have suggested that we should allow 
> >>> more
> flexibility in negotiation of these parameters when using SDP.  If 
> there is general agreement that it should be
> >>> done this way, I see no problem with defining parameter 
> >>> negotiation
> rules for SDP in the next version of the draft.
> >> The difference is that your draft is based on Offer/Answer, which 
> >> is
> about indicating receiving capabilities (yes, I know we have broken 
> that rule in the past).
> >
> > There are many examples of attributes that use different negotiation
> models than this.  The only requirement is that the semantics of the 
> negotiation be defined in the document defining the attribute.
> I still don't think the information belong to SDP - they define 
> protocol characteristics. The protocol specification should define 
> re-transmission timers etc.
> Anyway, we can argue about it later. At this moment I think the focus 
> should be on whether to move forward with the mechanism to begin with, 
> and the main feature of the mechanism - which is about negotiating 
> usage of channels :)

[Raju] Sorry to continue this discussion here instead of London, which I won't be attending.

I also believe that we do need these max_retr, max_time and unordered in the SDP.
These map to the data channel init parameters specified in . In case of DCP these are used by "5.1.  DATA_CHANNEL_OPEN Message" of
Combination of these parameters will determine the type of DATA_CHANNEL_OPEN open that will be sent.

For non-DCP external negotiation use case, these values have to be communicated to the peer. Since we want to closely follow DCP, which allows only one set of these values to be negotiated for both the directions, SDP offer/answer will do that same. Receiving end should accept these values, give it to data channel stack and echo them back to the offerer.
This way in external negotiation case as well, similar to DCP, both the peers will have same set of data channel attributes (reliable or partial reliable, ordered or unordered, timed or # of retransmission).

We will make the following changes, if agreed by others, in the next draft:
1. Add a new "reliable/partial reliable" SDP attribute, which is missing now.
   This is needed to map to the exact data channel type using external negotiation.
2. Map these SDP attributes to relevant DCP and PeerConnection sections.
   Need to make updates to SDP whenever DCP and/or PeerConnection is changed.
3. Specify either max_retr (retransmit data channel) or max_time (timed data channel)   
   present, but NOT both.

Best Regards