Re: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-channel - "a=setup" versus "a=dcsa:x setup"
Christer Holmberg <christer.holmberg@ericsson.com> Wed, 21 October 2015 18:10 UTC
Return-Path: <christer.holmberg@ericsson.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 97BF41A875E for <mmusic@ietfa.amsl.com>; Wed, 21 Oct 2015 11:10:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Level:
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 o77JHWHXi2bW for <mmusic@ietfa.amsl.com>; Wed, 21 Oct 2015 11:10:54 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801A71A877B for <mmusic@ietf.org>; Wed, 21 Oct 2015 11:10:46 -0700 (PDT)
X-AuditID: c1b4fb30-f79626d000006adf-d8-5627d524c19b
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 33.57.27359.425D7265; Wed, 21 Oct 2015 20:10:44 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0248.002; Wed, 21 Oct 2015 20:10:44 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Christian Groves <Christian.Groves@nteczone.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>
Thread-Topic: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-channel - "a=setup" versus "a=dcsa:x setup"
Thread-Index: AQHRAptKOrKJQjdNlEOZxQotRUuV5J5kIoLvgAUjjgCAACJ0EIABtwMAgAKhaJeACEHygIAATbtw
Date: Wed, 21 Oct 2015 18:10:43 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B37B82481@ESESSMB209.ericsson.se>
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> <5627AE91.5070605@nteczone.com>
In-Reply-To: <5627AE91.5070605@nteczone.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="windows-1255"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3RlflqnqYwbd9OhZ/Wn8xWnx538hi 8bRtOZvF1OWPWRxYPFqf7WX1WLLkJ5PHivMzWQKYo7hsUlJzMstSi/TtErgylj9TK7heUnHp z0KWBsZ3YV2MnBwSAiYS7/83MELYYhIX7q1n62Lk4hASOMoo0dLawwzhLGaUaNy0AqiKg4NN wEKi+582SFxE4BejxO6/n1hAuoUFUiUuvFnNCmKLCKRJdE98wgRhR0ks+LSZGcRmEVCV2NHS zg5i8wr4Shz5+xFq2yxmib1rWthAEpwCOhIv7jwEK2IEOun7qTVgg5gFxCVuPZnPBHGqgMSS PeeZIWxRiZeP/7FC2EoSK7ZfYoSoN5A4t30jO4StLbFs4WtmiMWCEidnPmGZwCg6C8nYWUha ZiFpmYWkZQEjyypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwDg6uOW3wQ7Gl88dDzEKcDAq 8fAm7FQLE2JNLCuuzD3EKMHBrCTCW7JRPUyINyWxsiq1KD++qDQntfgQozQHi5I4bzPTg1Ah gfTEktTs1NSC1CKYLBMHp1QDo3LUP6dT3553e0rXuXDGXf5ck/Q0IkxFRctItoq/5eTpxD2u n9P8RVZKTePdtpK98Ockw73nvma9Pb/y3qUJRyKmHa44r7tC9nO89eXmkLp9HCebeIreS31u mKG02mH73zSexe7LFluFP1tjanr3T5qE9i7uW2c7TW6H6PxYlNaxomR3r11gohJLcUaioRZz UXEiAB81a7ifAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/vvs7wyG6dSePk65A1NBZvMDIm3k>
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 18:10:57 -0000
Hi, >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. Correct. I want a=setup to only impact the data channel itself - not what is "inside" the data channel. >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. You can always give a=dsca:setup the same value as a=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. I see no problem in sending both, as they are used for different things. Regards, Christer 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