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

"Makaraju, Maridi Raju (Raju)" <> Mon, 24 February 2014 19:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1D57E1A01CA for <>; Mon, 24 Feb 2014 11:16:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xNHobBq8pdWR for <>; Mon, 24 Feb 2014 11:16:19 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 617571A0235 for <>; Mon, 24 Feb 2014 11:16:17 -0800 (PST)
Received: from ( []) by (8.13.8/IER-o) with ESMTP id s1OJGDkl009767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Feb 2014 13:16:14 -0600 (CST)
Received: from ( []) by (GMO) with ESMTP id s1OJG2I0009371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Feb 2014 14:16:13 -0500
Received: from ([]) by ([]) with mapi id 14.02.0247.003; Mon, 24 Feb 2014 14:16:04 -0500
From: "Makaraju, Maridi Raju (Raju)" <>
To: Christer Holmberg <>, Richard Ejzak <>
Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00
Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzw//+a7YA=
Date: Mon, 24 Feb 2014 19:16:03 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on
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 19:16:22 -0000

> >>>> Q4:
> >>>>
> >>>> I have issues with the max_retr, max_time and unordered parameters.
> >>>>
> >>>> First, they seem to specify SENDING capabilities, rather than RECEIVING
> 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