IETF Logo Mail Archive

Re: [MMUSIC] Eric Rescorla's No Objection on draft-ietf-mmusic-sdp-bundle-negotiation-51: (with COMMENT)

Ben Campbell <ben@nostrum.com> Tue, 22 May 2018 02:55 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39420120713; Mon, 21 May 2018 19:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 EXVYl8ljERFS; Mon, 21 May 2018 19:55:18 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09DD1120047; Mon, 21 May 2018 19:55:18 -0700 (PDT)
Received: from [10.0.1.94] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4M2tBGc041461 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 21 May 2018 21:55:12 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.94]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <5DC7BE03-19FF-4E26-988C-95577F0F74C7@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_2731224F-405B-465A-8738-F11E6C9737AA"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Mon, 21 May 2018 21:55:10 -0500
In-Reply-To: <54A24D59-4EC7-415D-B83D-1FFFF7AA715E@ericsson.com>
Cc: Adam Roach <adam@nostrum.com>, Eric Rescorla <ekr@rtfm.com>, Flemming Andreasen <fandreas@cisco.com>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, mmusic WG <mmusic@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" <draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org>
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <152676110260.28001.7412898846338225219.idtracker@ietfa.amsl.com> <CABcZeBN43yTCK+XbLLih_xeaBwsGVMa6XcPQkrcyQjzQHfzNuQ@mail.gmail.com> <CABcZeBO5b4OMaV5z-XhQPVOUpX6eB_GZKPu7b9Ti6MOCwsJ5xQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B72EF825B@ESESSMB109.ericsson.se> <CABcZeBM5Vqmw-txmTmrcOXndwsW=20oUvXywdeLR9OMBPFp1cQ@mail.gmail.com> <701d1e42-fcb9-a849-2865-9f1a71176a50@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72EF9591@ESESSMB109.ericsson.se> <d6143d6e-7177-36dc-76ea-b85e8b519724@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72EF9626@ESESSMB109.ericsson.se> <EA1B8B7B-B908-422E-8D75-ECABF47E8690@ericsson.com> <54A24D59-4EC7-415D-B83D-1FFFF7AA715E@ericsson.com>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/x7uTj3V0JbdLl-znbueno7X2sS0>
Subject: Re: [MMUSIC] Eric Rescorla's No Objection on draft-ietf-mmusic-sdp-bundle-negotiation-51: (with COMMENT)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 22 May 2018 02:55:21 -0000


> On May 21, 2018, at 11:34 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
> 
> In my opinion, if the problem is that there is a conflict with the terminology in RFC 3261 and/or 3264, then let’s fix those specs instead.

I don’t follow -- are you suggesting we should change the terminology in 3264 to match that of work-in-process extensions? Or did I misread that?

Ben.

> 
> Regards,
> 
> Christer
> 
> Sent from my iPhone
> 
> On 21 May 2018, at 19.23, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
> 
>> ...and, to use an example you may be more familiar with: RID.
>> 
>> Are you saying that the “initial offer” procedures can only be used for the initial offer of the SIP session, meaning I can’t introduce RID later in the session (to an existing and/or new m- line)? If so, I think that should be explicitly stated in the draft.
>> 
>> Regards,
>> 
>> Christer
>> 
>> 
>> Sent from my iPhone
>> 
>> On 21 May 2018, at 18.37, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
>> 
>>> Hi,
>>> 
>>>>> It is also important to remember that this affects virtually every SDP attribute we define, >> unless there are cases where "initial offer" always means the initial offer of a session, i.e., >> it is not possible to introduce an attribute later in a session.
>>>> 
>>>> I'm not following your logic here. Can you give an example?
>>> 
>>> Assume I establish a session, with audio and video.
>>> 
>>> The initial offer will contain the m- lines, and associated SDP attributes, for audio and video.
>>> 
>>> Later in the session, I send a subsequent offer, adding a BFCP m- line.
>>> 
>>> When setting the SDP attributes associated with the BFCP m- line, I will now use the "initial offer" procedures for those attributes, because it is the initial offer for those attributes (while a subsequent offer for the SIP session).
>>> 
>>> Regards,
>>> 
>>> Christer
>>>

v2.23.0 | Report a Bug | By Email