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

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 27 February 2014 21:51 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8BD1A0676; Thu, 27 Feb 2014 13:51:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.04
X-Spam-Level:
X-Spam-Status: No, score=-0.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hzx9tDyqZyMZ; Thu, 27 Feb 2014 13:51:16 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id BFD9C1A0675; Thu, 27 Feb 2014 13:51:15 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-40-530fb35172e6
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 8E.D9.04853.153BF035; Thu, 27 Feb 2014 22:51:13 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0387.000; Thu, 27 Feb 2014 22:51:12 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>, "Paul Kyzivat" <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel
Thread-Index: Ac8y9YTn0Ql62f4ZSwiP0pv/vZVV7v///hmAgABkRoCAAAQtAIABiUuA///PR8A=
Date: Thu, 27 Feb 2014 21:51:11 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1C023A@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1D1BC516@ESESSMB209.ericsson.se> <CAJuyhsyk4jO_TS=5khD9ROAx7uYU1YAkCV0Xy4QVUkiqXBJJfg@mail.gmail.com> <E1FE4C082A89A246A11D7F32A95A17826DFFB545@US70UWXCHMBA02.zam.alcatel-lucent.com> <530E4E34.4010707@alum.mit.edu> <E1FE4C082A89A246A11D7F32A95A17826DFFEDAB@US70UWXCHMBA02.zam.alcatel-lucent.com>
In-Reply-To: <E1FE4C082A89A246A11D7F32A95A17826DFFEDAB@US70UWXCHMBA02.zam.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+JvjW7gZv5gg7MrpSymLn/MYrFiwwFW i4aNV1gt1v5rZ3dg8Wh9tpfV4+/7D0weS5b8ZApgjuKySUnNySxLLdK3S+DKaHzZxlrQZVBx 48hGxgbGuWpdjJwcEgImEscuf2GEsMUkLtxbz9bFyMUhJHCCUWLPmcVMEM4SRonJH54AVXFw sAlYSHT/0waJiwjsZpT4+vwCM0i3sECsxNFlV5lAakQE4iRenlMBCYsI+El8OrqFBcRmEVCV uP7qI1gJr4CvxL3jUhDj7zBJnD9ygh2khhNozIY1M8AOYgQ66PupNUwgNrOAuMSHg9eZIQ4V kFiy5zyULSrx8vE/VghbSWLF9kuMEPV6EjemTmGDsLUlli18DVbPKyAocXLmE5YJjKKzkIyd haRlFpKWWUhaFjCyrGKULE4tLs5NNzLQy03PLdFLLcpMLi7Oz9MrTt3ECIymg1t+G+1gPLnH /hCjNAeLkjjvddaaICGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MlYLzvqp/OTCv9I/biuxC Jt1jR/20Z2T3Ja0/qeWxWvpGoITv7HNL70hXbdn4oIwl9J+uA0PCFfm8Hacmvmx6nhSyqkYx 13f6sVrRo9OfzbKIczBbeiG8p8DFettKqyaxVT53ZsseZHRe05iRGMl+eLpjo9H8JxZ5rpVL c2cy9Uxr0bqx71afEktxRqKhFnNRcSIAmYhj6nQCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/WICeyrOjrmogyrWeqKgHPGKKVWs
Subject: Re: [rtcweb] [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2014 21:51:18 -0000

Hi,

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?

Or something like that...

Regards,

Christer




-----Alkuperäinen viesti-----
Lähettäjä: mmusic [mailto:mmusic-bounces@ietf.org] Puolesta Makaraju, Maridi Raju (Raju)
Lähetetty: 27. helmikuuta 2014 21:55
Vastaanottaja: Paul Kyzivat; mmusic@ietf.org; rtcweb@ietf.org
Aihe: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel

+ rtcweb as it impacts DCP draft.

Please see comments inline.

> I would like some clarity about how this interacts with DCEP.
> 
> IMO these are not mutually exclusive. But they must be used with care.

[Raju] I debated on this with myself before concluding in my earlier reply that they are mutually exclusive. My mistake, instead of concluding I should have given options. To make this internal or external per data channel granuality we need to add more restrictions/notes to these draft. 

http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-03#section-4 says:
   "To avoid glare in opening Channels, each side MUST use either even or
   odd Streams when sending a DATA_CHANNEL_OPEN message.  The method
   used to determine which side uses odd or even is based on the
   underlying DTLS connection role when used in WebRTC, with the side
   acting as the DTLS client using even stream identifiers."

Where as draft-ejzak-mmusic-data-channel-sdpneg determines this based on SDP offerer (even) and answerer (odd).

What if the SDP answerer becomes TLS client? The stream #id assignments conflict with SDP offer/answer.
So, to avoid such conflict we need to add the following clarifications:
1. draft-ejzak-mmusic-data-channel-sdpneg
   If DCP is used along with external negotiation, when creating
   data channel the client should always specify the stream id 
   to use. Leaving selection to data channel stack (DCSK) will 
   result in conflicts as DCSK (browser) will assign stream ids 
   per DTLS role.

2. draft-ietf-rtcweb-data-protocol-03
   Item (1) above conflicts with DCP's odd/even rule, for which
   the draft says "MUST" ("each side MUST use either even or 
   odd Streams").
   This section 4 (and other sections) text has to be updated
   to "SHOULD" or "MAY".

If we all agree to these updates then I am ok to make internal or external negotiation granularity per data channel.

Best Regards
Raju

> 
> So, when a channel that was in the SDP previously then disappears from 
> the SDP it is necessary to close the corresponding channel. But 
> channels that were opened via DCEP should not be closed.
> 
> That also means that one should never mention a DCEP channel in SDP.
> 
> 	Thanks,
> 	Paul
> 
> On 2/26/14 3:12 PM, Makaraju, Maridi Raju (Raju) wrote:
> > Please find my comments inline.
> >
> > But, there is no text on rejecting a data channel in the SDP answer.
> >
> > The answer can of course reject the whole m- line, using port zero 
> > in the Answer m- line. But, how does the answerer reject an 
> > individual sub-protocol data channel?
> >
> > Only attributes for "accepted data channels" are included in the SDP 
> > answer, which indicates back to the offerer which ones are rejected 
> > (they just aren't there).  This should be made clearer in the text.
> >
> >     Section 5.1.1 says, regarding the SDP dcmap attribute, for accepted
> >     data channels:
> >
> >     "This line MUST be replicated without changes in the SDP answer, 
> > if
> >
> >                      the answerer accepts the offered data channel."
> >
> >     I guess one way to reject would be to simply not include the dcmap
> >     attribute in the Answer, and the Offerer then needs to figure out
> >     what was rejected based on the stream values not present in the
> Answer.
> >
> > Yes.  That is what was intended.
> >
> > /[Raju] In addition to the above mentiooed cases, if we all agree we 
> > need to add the following cases in the next draft:/
> >
> > */1./*SDP offer has no a=dcmap. This has two use cases:
> >
> > a.Initial SDP offer: no data channel streams (DCS) are open yet.
> >
> > b.Subsequent SDP offer: Remove all previously opened data
> channels/streams.
> >
> > In either case, the SCTP association is kept open (and ICE 
> > procedures are performed) even when no data channels are in use.
> >
> > */2./*Creation of new DCS(s) using SDP offer (initial or subsequent)
> >
> > a.Offerer has to create the data channels locally first by doing 
> > createDataChannel or equivalent API into data channel stack before 
> > sending offer.
> >
> > */3./*SDP offer was rejected
> >
> > a.DCSs are kept per previous SDP offer/answer. This means DCSs that 
> > are to be deleted has to be deleted (i.e. calling createDataChannel 
> > or equivalent API) only after successful SDP answer.
> >
> > b.If any new DCSs are attempted to be created per new SDP offer, 
> > these have to be closed now.
> >
> > */4./*Per
> > http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-peerconnection-
> createdatachannel
> > createDataChannel() API the 'external' negotiation field is per data 
> > channel.  But this draft only allows external negotiation to be used 
> > for all or no streams; it can't be selective. This restriction is 
> > also needed so that the SDP offer/answer odd/even stream id 
> > allocation won't conflict DCP's TLS role based odd/even mechanism.
> >
> > Best Regards!
> >
> > Raju
> >
> >
> >
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
> >
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic