Re: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-channel - "a=setup" versus "a=dcsa:x setup"
Christian Groves <Christian.Groves@nteczone.com> Wed, 21 October 2015 15:26 UTC
Return-Path: <Christian.Groves@nteczone.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63EC1A8A4C for <mmusic@ietfa.amsl.com>; Wed, 21 Oct 2015 08:26:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 1ZknPvKBpJNp for <mmusic@ietfa.amsl.com>; Wed, 21 Oct 2015 08:26:21 -0700 (PDT)
Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 707761A8A63 for <mmusic@ietf.org>; Wed, 21 Oct 2015 08:26:20 -0700 (PDT)
Received: from [156.106.225.28] (port=54366) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from <Christian.Groves@nteczone.com>) id 1ZovHK-000DYw-FQ; Thu, 22 Oct 2015 02:26:15 +1100
To: Christer Holmberg <christer.holmberg@ericsson.com>, "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>, "Stoetzer-Bradler, Juergen (Juergen)" <juergen.stoetzer-bradler@alcatel-lucent.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <5617C92A.4030009@alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B37B388F5@ESESSMB209.ericsson.se> <561CFF32.5080601@alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B37B41098@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1ACDF79BE0B@FR711WXCHMBA01.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B37B45C07@ESESSMB209.ericsson.se>
From: Christian Groves <Christian.Groves@nteczone.com>
Message-ID: <5627AE91.5070605@nteczone.com>
Date: Wed, 21 Oct 2015 17:26:09 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B45C07@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="windows-1256"; format="flowed"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Authenticated-Sender: cserver5.myshophosting.com: christian.groves@nteczone.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/VxaontJURbmSvmtgNM1oT1OqdIc>
Subject: Re: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-channel - "a=setup" versus "a=dcsa:x setup"
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Oct 2015 15:26:23 -0000
Hello Albrecht and Christer, The "rule of thumb" I had is covered by Juergen's text. It was basically that an endpoint only includes a=dsca:setup if it wanted a role different than what is indicated in a=setup. However I think Christer has a separate view. I think the original source of the problem is that RFC6135 links the MSRP establishment role to the a=setup. I.e. the active side is the one that sends the first MSRP message. So these are linked. To unlink it for MSRP over DC its proposed to use a=setup (which was defined for transport connection setup) in the DC (via dsca) to control the MSRP protocol setup. I think at the end of the day the decision is whether we want every WebRTC endpoint to send "a=setup" and "a=dsca:setup" every time it wants to set up a MSRP datachannel or whether it only has to send a=dsca:setup if wants a different role from the a=setup. Regards, Christian On 16/10/2015 9:20 AM, Christer Holmberg wrote: > Albrecht, I can't parse what you said. > > If a piece of information is required in order for something to work, > then it must be mandatory to include that piece of information. Of > course, you may define an implicit default value, but the information > must be there. > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------------------------------------------------ > From: Schwarz, Albrecht (Albrecht) > <mailto:albrecht.schwarz@alcatel-lucent.com> > Sent: 14/10/2015 20:09 > To: Christer Holmberg <mailto:christer.holmberg@ericsson.com>; > Stoetzer-Bradler, Juergen (Juergen) > <mailto:juergen.stoetzer-bradler@alcatel-lucent.com>; mmusic@ietf.org > <mailto:mmusic@ietf.org>; Christian Groves > (Christian.Groves@nteczone.com) <mailto:Christian.Groves@nteczone.com> > Subject: RE: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-channel - > "a=setup" versus "a=dcsa:x setup" > > Hello Christer, > > such a prescriptive sentence > > />//If a setup value is required for the MSRP session establishment, > then the dcsa setup attribute must be mandatory./ > > relates to a “*conditionally ‘mandatory’*”, i.e., an *optional* > tagging in general, right? > > @Christian, you had a good rule of thumb proposed, covering the > conditionality. > > What’s your view? > > Regards, > > Albrecht > > *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* Dienstag, 13. Oktober 2015 15:01 > *To:* Stoetzer-Bradler, Juergen (Juergen); mmusic@ietf.org > *Subject:* Re: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-channel - > "a=setup" versus "a=dcsa:x setup" > > Hi, > > If a setup value is required for the MSRP session establishment, then > the dcsa setup attribute must be mandatory. > > Regards, > > Christer > > *From:*Juergen Stoetzer-Bradler > [mailto:Juergen.Stoetzer-Bradler@alcatel-lucent.com] > *Sent:* 13. lokakuuta 2015 15:55 > *To:* Christer Holmberg; mmusic@ietf.org <mailto:mmusic@ietf.org> > *Subject:* Re: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-channel - > "a=setup" versus "a=dcsa:x setup" > > Hello Christer, > > Thank you for your comments. > > A dcsa embedded setup attribute does not have any MSRP transport > protocol related establishment role semantics. > But an MSRP over data channel endpoint still needs to know its MSRP > session establishment role. > In some data channel to TCP (or TLS) transport interworking cases, > which are described in section 6, > this MSRP session establishment role cannot always be derived from the > DTLS/SCTP establishment role. > In such cases a dcsa embedded setup attribute for MSRP seems to be > required. > However, in some other interworking cases, and especially in > end-to-end data channel cases the MSRP session > establishment role could be tightly coupled with the DTLS/SCTP > establishment roles and hence with the "a=setup" attribute. > If we don't allow the "a=setup" attribute to also describe the MSRP > session establishment role (if no "a=dcsa:x setup" > attribute is present), then we should probably specify that a dcsa > embedded setup attribute is mandatory > for MSRP over data channel sessions. > > For MSRP as sub-protocol, would a mandatory "a=dcsa:x setup:<role>" > attribute be agreeable? > > Thanks, > Juergen > > On 10.10.2015 06:26, Christer Holmberg wrote: > > Hi. > > First, I think you suggest far too much text, but that is editorial. > > Second, as you say, the media level 'setup' attribute is used to > negotiate the SCTPoDTLS association establishment. But, I don't > think it should be used to negotiate the MSRP roles etc in case > the 'dcsa:x setup' is not present. The 'setup' attribute has > nothing to do with the protocol carried within the data channel - > the reason we defined the 'dsca' attribute was to be able to carry > such information. > > Regards, > > Christer > > Sent from my Windows Phone > > ------------------------------------------------------------------------ > > *From: *Juergen Stoetzer-Bradler > <mailto:Juergen.Stoetzer-Bradler@alcatel-lucent.com> > *Sent: *09/10/2015 17:03 > *To: *mmusic@ietf.org <mailto:mmusic@ietf.org> > *Subject: *[MMUSIC] draft-ietf-mmusic-msrp-usage-data-channel - > "a=setup" versus "a=dcsa:x setup" > > Hello, > > An MSRP over data channel related SDP media description will have > a media level "a=setup:<role>" attribute and may additionally > contain an "a=dcsa" encapsulated setup attribute "a=dcsa:x > setup:<role>". Current version > draft-ietf-mmusic-msrp-usage-data-channel-02 > does not yet have any text related to the setup attribute except > for listing it as potential dcsa encapsulated MSRP specific attribute. > As the media level "a=setup" attribute is used to negotiation the > DTLS and SCTP establishment roles, and as the setup attribute is > also used > in MSRP over TCP cases to negotiate the "active" role of MSRP > session endpoints (RFCs 6135, 6714) we propose to explicitly describe > the semantics of dcsa encapsulated setup attributes for MSRP over > data channel in draft-ietf-mmusic-msrp-usage-data-channel. > > We propose to add a new section 5.1.1.3 "Media Description Level > setup Attribute Versus Data Channel Specific setup Attribute" > after section 5.1.1.2 ("Use of dcsa Attribute") and to extend > existing section 6 ("Gateway Configuration") with setup attribute > related procedures. > > Would the following new section 5.1.1.3 and modified section 6 be > agreeable? > > Thanks, > Juergen > > Proposed new Section 5.1.1.3: > > 5.1.1.3. Media Description Level setup Attribute Versus Data > Channel Specific setup Attribute > > The SDP setup attribute, as introduced in [RFC4145], can be used in > WebRTC data channel related SDP media descriptions as a media level > attribute, which is directly associated with the corresponding > DTLS/ > SCTP "m" line. In this case the setup attribute is of the form > "a=setup:<role>", where <role> assumes values as defined in > [RFC4145]. Such a setup attribute is then used as specified in > [I-D.ietf-mmusic-sctp-sdp] in order to negotiate the establishment > roles of the DTLS connection and the SCTP association. > > Additionally, the setup attribute can be embedded in a dcsa > attribute > and hence can explicitly be associated with an MSRP session over a > specific data channel. In such a case it is of the form "a=dcsa:x > setup:<role>", with x being the data channel's SCTP stream > identifier. Such a dcsa attribute embedded setup attribute has no > relationship with the DTLS connection and SCTP association > establishment roles. > > dcsa attribute embedded setup attributes are OPTIONAL for MSRP > sessions over data channels. > > If an MSRP over data channel description contains a dcsa embedded > setup attribute, then this embedded setup attribute is used to > negotiate, which MSRP session endpoint assumes the active role > as per > Section 4.2.2 of [RFC6135] and Section 5.4 of [RFC4975]. > > If an MSRP over data channel description does not contain a dcsa > embedded setup attribute, then the media description level > "a=setup" > attribute, which is associated with the data channel's DTLS > connection and SCTP association, is used to negotiate, which MSRP > session endpoint assumes the active role. > > If an MSRP over data channel endpoint wants to negotiate an > active or > non-active MSRP session establishment role, which is different from > its DTLS connection and SCTP association establishment role, > then it > MUST include a dcsa embedded setup attribute for this MSRP session. > In this case this dcsa embedded setup attribute's value is > different > from the value of the DTLS/SCTP "m" line's "a=setup" attribute. > > > Proposed modified section 6: > > 6. Gateway Configuration > > This section describes the network configuration where one MSRP > endpoint uses data channels as MSRP transport, the other MSRP > endpoint uses TLS/TCP connections as MSRP transport, and the > two MSRP > endpoints interwork via an MSRP gateway. > > Specifically, a gateway can be configured to interwork an MSRP > session over a data channel with a peer that does not support data > channel transport in one of two ways. In one model, the gateway > performs as a MSRP B2BUA to interwork all the procedures as > necessary > between the endpoints. No further specification is needed for this > model. > > Alternately, the gateway can use CEMA procedures to provide > transport > level interworking between MSRP endpoints using different transport > protocols as follows. > > When the gateway performs transport level interworking between MSRP > endpoints, all of the procedures in Section 5 apply to each peer, > with the following additions: > > o The endpoint establishing an MSRP session using data channel > transport SHALL NOT request inclusion of any relays, although it > MAY interoperate with a peer that signals the use of relays. > > o The gateway receiving an SDP offer that includes a request to > negotiate an MSRP session on a data channel can provide > transport > level interworking in the same manner as a CEMA SBC by > forwarding > TCP or TLS transport parameters in a new "m" line with the > appropriate attributes within the forwarded SDP offer. > > * If the received data channel side SDP offer contains a dcsa > embedded setup attribute for the to be negotiated MSRP > session, > then the gateway interworks this dcsa embedded setup > attribute > with the media description level "a=setup" attribute of this > MSRP session's "m" line in its forwarded SDP offer. > > * If the received data channel side SDP offer does not > contain a > dcsa embedded setup attribute for the to be negotiated MSRP > session, then the gateway interworks the media description > level "a=setup" attribute, which is directly associated with > the data channel's DTLS/SCTP "m" line, with the media > description level "a=setup" attribute of this MSRP session's > "m" line in its forwarded SDP offer. > > o Similarly, a gateway receiving an SDP offer to negotiate an MSRP > session using TCP or TLS transport with an endpoint that only > supports data channel transport for MSRP can provide transport > level interworking in the same manner as a CEMA SBC by > establishing a new data channel for the MSRP session with the > target endpoint. > > * In this case the gateway interworks the TCP or TLS associated > media description level "a=setup" attribute of the to be > negotiated MSRP session's received "m" line either with the > media description level "a=setup" attribute of the data > channel's DTLS/SCTP "m" line, or with the dcsa embedded setup > attribute of this MSRP session's new data channel. > > * If the gateway's DTLS connection and SCTP association > establishment role on its data channel side is equal to the > "a=setup" attribute's value of the received MSRP over TCP or > TLS "m" line, then the gateway MAY add a dcsa embedded setup > attribute to the description of the MSRP session's new data > channel in its generated data channel side offer. > Alternatively, in this case the gateway MAY omit adding > such a > dcsa embedded setup attribute to the description of the MSRP > session's new data channel in its generated data channel side > offer. Otherwise, if the gateway's DTLS connection and SCTP > association establishment role is different from the MSRP > over > TCP or TLS associated received "a=setup" attribute's value, > then the gateway MUST add a dcsa embedded setup attribute to > the description of the MSRP session's new data channel in its > generated data channel side offer. > > * If the gateway adds a dcsa embedded setup attribute > associated > with this MSRP session to its data channel side SDP > offer, then > the value of this embedded setup attribute MUST be equal > to the > value of the "a=setup" attribute, which is associated > with this > MSRP session's "m" line in the received TCP or TLS side SDP > offer. >
- [MMUSIC] draft-ietf-mmusic-msrp-usage-data-channe… Juergen Stoetzer-Bradler
- Re: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-ch… Christer Holmberg
- Re: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-ch… Juergen Stoetzer-Bradler
- Re: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-ch… Christer Holmberg
- Re: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-ch… Schwarz, Albrecht (Albrecht)
- Re: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-ch… Christer Holmberg
- Re: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-ch… Christian Groves
- Re: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-ch… Paul Kyzivat
- Re: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-ch… Christer Holmberg
- Re: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-ch… Christer Holmberg
- Re: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-ch… Christian Groves
- Re: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-ch… Juergen Stoetzer-Bradler