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

"Makaraju, Maridi Raju (Raju)" <> Mon, 24 February 2014 20:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B24BA1A02F4 for <>; Mon, 24 Feb 2014 12:38:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.5
X-Spam-Status: No, score=-5.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ucRikw0UShU7 for <>; Mon, 24 Feb 2014 12:38:26 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5E5991A0256 for <>; Mon, 24 Feb 2014 12:38:25 -0800 (PST)
Received: from ( []) by (8.13.8/IER-o) with ESMTP id s1OKcLQJ026213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Feb 2014 14:38:21 -0600 (CST)
Received: from ( []) by (GMO) with ESMTP id s1OKcK8P010520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Feb 2014 15:38:20 -0500
Received: from ([]) by ([]) with mapi id 14.02.0247.003; Mon, 24 Feb 2014 15:38:20 -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//+a7YD//x16EP/+ONLQ
Date: Mon, 24 Feb 2014 20:38:19 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
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 20:38:28 -0000


> Hi,
> I don't see why an SDP based mechanism by default must provide the same
[Raju] Because, whether browser based or not each side will use a data channel stack. Independent of DCP used or not, the data channel stack has to have these attributes to do various order/unordered, reliab/unreliable, retransmit/timed modes.
With external negotiation, the same SDP will be used to negotiate these values (similar to what DCP data channel open does).
This way the only difference between external based negotiation vs. DCP is "DCP" itself, neither more nor less; rest of the attributes of data channel are exactly identical on both ends. This is what we want to achieve with external negotiation.

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

[Raju] Using DCP means the intermediate elements have no ("easy") visibility into what channels are being negotiated; such visibility is needed for various reasons like to have interworking functionality with other protocols, such as MSRP; or regulatory needs; or value added services with billing implications etc.

> 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.
[Raju] On top of data channel standard IANA registered protocols, such as MSRP, will typically be used; so modifying such protocols for this use case is not an option.

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

[Raju] A simple example would be 2 browsers talking thru an intermedia proxy, which wants to know what protocols are being negitiated and used as part of the session.
1. Calling client creates data channel (using with desired attributes and sets negotiated=true. So, calling browser saves the attributes for the data channel but won't use DCP.
2. These attributes are sent via SDP to peer client (via proxy).
3. Peer client sets these same attributes while creating data channel and sets negotiated=true but won't do DCP.
4. Peer client echo the same attributes back in SDP answer.

Now, data channel stacks on both ends will use same attributes, similar to DCP use case, with the only difference being DCP is not used here.

Best Regards