Re: [rtcweb] [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel

"Makaraju, Maridi Raju (Raju)" <> Fri, 28 February 2014 16:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 46D771A00D1; Fri, 28 Feb 2014 08:46:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.3
X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id shksOz-QIkEM; Fri, 28 Feb 2014 08:46:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 33F111A00EF; Fri, 28 Feb 2014 08:46:47 -0800 (PST)
Received: from ( []) by (8.13.8/IER-o) with ESMTP id s1SGkesF028681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Feb 2014 10:46:40 -0600 (CST)
Received: from ( []) by (GMO) with ESMTP id s1SGkY0i016154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Feb 2014 11:46:40 -0500
Received: from ([]) by ([]) with mapi id 14.02.0247.003; Fri, 28 Feb 2014 11:46:34 -0500
From: "Makaraju, Maridi Raju (Raju)" <>
To: Paul Kyzivat <>, Christer Holmberg <>, "" <>, "" <>
Thread-Topic: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel
Thread-Index: AQHPMv00Ot+PDux+H0inH2oRraNWlJrH7JxQgABjlQCAAR/dwIAAideA//+55ECAAXTlAP//tqXA
Date: Fri, 28 Feb 2014 16:46:33 +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
Subject: Re: [rtcweb] [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel
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: Fri, 28 Feb 2014 16:46:50 -0000

Hi Paul,

> >> Isn't it enough to, in the data channel protocol spec, say that the
> odd/even
> >> rule applies unless the stream id is explicitly negotiated using some
> other
> >> mechanism?
> >>
> > [Raju] Yes, that is sufficient from DCP draft. draft-ejzak-mmusic-data-
> channel-sdpneg should still need to say that "when both external and DCP are
> used, even for DCP created streams the stream ids have to be specified and
> managed by the application (else DCP stack will default to odd/even rule per
> DTLS role which may conflict with SDP offer/answer rule)".
> Can we assume there must be a mechanism for using DCEP and still
> controlling which channels are used?

[Raju] Yes, we can assume that and it is already supported by :
I believe it is safe to assume non-browser implementations of 
data channel stack gives an option for application to select 
stream ids independent of DCEP or external negotiation.

> It might help if the O/A negotiation also followed the even/odd rule.
[Raju] May be I am missing something here. Richard's draft already has
a specific even/odd rule for O/A. But the issue is TLS based rule may
conflict with the O/A rule as TLS roles may change depending on a=setup.

> But there are difficulties in knowing who is even and who is odd for the
> first O/A.

[Raju] Not related to first or subsequent O/A, but rather a conflict 
between TLS roles vs. O/A.

> If the offerer always creates the channel before sending the offer, then
> that will prevent the two mechanisms from stepping on one another's
> stream ids.
In some cases, initial offer may not have a data channel stream created. 
I don't know how this can prevent stepping on each other?!
May be I am missing something here?! In most cases TLS role is 
determined after O/A is completed, but offerer creates a data 
channel before answer, then how does it know even/odd rule? 
So, trying to use TLS role for external negotiation is problematic.