Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th)

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 14 June 2013 18:34 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 4AF3921F90E4 for <mmusic@ietfa.amsl.com>; Fri, 14 Jun 2013 11:34:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.062
X-Spam-Level: *
X-Spam-Status: No, score=1.062 tagged_above=-999 required=5 tests=[AWL=-1.401, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_56=0.6, MANGLED_FORM=2.3, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJzVl-tZ0s1r for <mmusic@ietfa.amsl.com>; Fri, 14 Jun 2013 11:34:27 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id A435521F9AF9 for <mmusic@ietf.org>; Fri, 14 Jun 2013 11:34:26 -0700 (PDT)
Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta14.westchester.pa.mail.comcast.net with comcast id oGuQ1l0091uE5Es5EJaRnU; Fri, 14 Jun 2013 18:34:25 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id oJaR1l00W3ZTu2S3cJaRSA; Fri, 14 Jun 2013 18:34:25 +0000
Message-ID: <51BB622F.60007@alum.mit.edu>
Date: Fri, 14 Jun 2013 14:34:23 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <7594FB04B1934943A5C02806D1A2204B1C388BD8@ESESSMB209.ericsson.se> <51BA08D0.3030301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C38AA73@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C38AA73@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371234865; bh=LPZU6xsaJ8i5XM2wnKxcmSME6tVwilZVRQvACLsOQUo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Ux8r9wYujM8AesCRvil6SXdIjndU64CxIYI7Tu+THkgcdPAABQ5vR/xXLdGZVKHcl 9bvSsByZMLOHilUsFp1/4odhaH8abfNzuNO6vLtTokGU0xD6K1XXRDRy6VrSDLo07K uXiEpogos1SVmv9Y4Wto5o4rNE4PjrNHjivGlzl3+v1al+KL6YD5Ke7RhmERc5V8lQ W86XDC+8Xpjuk0KcWvuXW/Ioer8M1dolPM8j2rHsK2sZzG8r50nqim6pEddYF4YYiT QAePNZsyen4ThmVvoHSBZYLXrUgDzDrXG+BACCzIj1YC3lU6Uh2Mai6vEm4FH0vHyW qH1Y6QxKI4YZA==
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Fri, 14 Jun 2013 18:34:39 -0000

Hi Christer,

More discussion inline.

On 6/14/13 7:35 AM, Christer Holmberg wrote:
> Hi,
>
>>> 6.1.  General
>>>
>>>      This section describes the usage of the SDP Offer/Answer mechanism
>>>      [RFC3264] to negotiate the usage of the BUNDLE mechanism, to
>>>      negotiate the bundle address, and to add, remove and reject SDP
>>>      Media Descriptions ("m=" lines) associated with a BUNDLE group.
>>>
>>>      The generic rules and procedures defined in [RFC3264] and
>>>      [RFC5888]apply when the SDP Offer/Answer mechanism is used for BUNDLE.  For
>>>      example, if an SDP Offer is rejected, the previously negotiated  SDP
>>>      parameters and characteristics (including those associated with BUNDLE groups) apply.
>>>
>>>      When an endpoint generates an SDP Offer, or an SDP Answer, which
>>>      contains a BUNDLE group, the endpoint MUST assign SDP media-level
>>>      mid value for each "m=" line in the BUNDLE group.  In addition, the
>>>      endpoint MUST insert an SDP session-level group:BUNDLE attribute,
>>>      and place each mid value associated with the BUNDLE group in the
>>>      attribute mid value list.
>>>
>>>      Until the Offerer knows whether the Answerer supports the BUNDLE
>>>      mechanism, the Offerer MUST, for each "m=" line in a BUNDLE group:
>>
>> Under what circumstances may the offerer presume to *know* whether the answerer supports BUNDLE?
>>
>> The minimal answer is that if an offer included a bundle group, and the answer also contains a corresponding bundle group, then the answerer
>> supported *that* bundle at the time of *that* answer, and continues to do so at least until there is another offer.
>
> Yes.
>
> I was actually thinking about removing the "until the Offerer knows" text, and simply generally say that the bundle address is negotiated by assigning a unique address to each "m=" line.
>
> But, as you want to be able to assign a bundle address to multiple "m=" lines before it has been negotiated, it would not work.
>
>> But we want to assume more - at least that if *a* bundle was supported by both sides in one O/A exchange, then both sides can be presumed to
>> *understand* bundle, including the use of the same address info for multiple m-lines in a bundle offer, in future offers within the same signaling session.
>
> I would rather say SDP session, to keep it independent from the signaling protocol. That is the same as for any other parameter you negotiate using SDP O/A - it's valid until re-negotiated.

Sure, I think "SDP session" will work.

>> Is, or should there be, a way to go back on that presumption - to stop supporting bundle? I guess if an end wanted to stop supporting bundle
>> while a bundle was in effect it would need to send an offer that didn't include any bundles. But it might want to send such an offer just because
>> it doesn't currently need a bundle though it still supports them.
>
> Sure, but if anyone then wants to start using BUNDLE again, it will send an Offer and suggest the usage.

My point was that if support for bundle can be presumed, then it no 
longer is necessary to offer unique address info for each m-line when 
adding to bundles or proposing new bundles.

In particular, this becomes significant for the bundle splitting case:

1) X sends offer to Y proposing a bundle, uses unique address info
2) Y sends answer to x accepting the bundle,
    but rejecting some of the m-lines in it
3) X sends a BAS to Y to finalize the initial bundle.
4) Y sends answer to X accepting the BAS
5) Y sends offer to X keeping the existing bundle,
    and proposing a new bundle for the previously rejected
    m-lines. Because it knows X supports bundle, and it knows
    that X was willing to have the m-lines in question bundled,
    this offer is in the form of a BAS, with all the m-lines
    in the new bundle having common address info.
6) X sends answer to Y, presumably accepting both bundles.

In this case it is quite wasteful if Y has to provide separate address 
info for each of the m-lines in the new bundle, and then yet another BAS 
has to be exchanged to fix that up.

Of course being able to presume support also is useful in cases where no 
bundle splitting is needed. E.g., Y was able to accept the initial 
bundle from X in full. Then later it wanted to offer an additional 
separate bundle. And it could also cover the case where an initial O/A 
is done when no bundle is yet needed, but *support* for bundle is 
negotiated. Then later, when a bundle is needed, it may be offered in 
BAS form, so only a single O/A is required.

The above also points out another issue: (3) & (4) are quite a waste. It 
would be nice to be able to avoid them in this case. One way to achieve 
that would be to put the burden on the answerer that accepts a bundle 
where the address info is not all the same to send the BAS. In this case 
that would mean that (5) would also serve as a substitute for (3), and 
(6) would then substitute for (4).

>> Perhaps we should say that an offerer or answerer who supports bundle should *always* include an a=group:bundle in its offers and
>> answers. If it doesn't currently want a bundle it can simply include "a=group:bundle" without any mid  values.
>
> Or, we could leave it up to the signaling protocol. For SIP, one could define a media feature tag. That would also allow SIP entities to request that INVITEs are sent to entities to support BUNDLE (and have indicated so during registration).

Yes, we could. I don't have a strong preference one way or the other.

> --------------------------------------
>
>
>>> 6.2.1.  SDP Offerer Bundle Address Request and Usage
>>>
>>>      An Offerer can assign an address to multiple "m=" lines in a
>>>      BUNDLE group, once the address has been selected as the Offerer's local
>>>      bundle address.  An Offerer MUST NOT assign an address to multiple
>>>      "m=" lines until the address has been selected as a bundle address
>>>      for that BUNDLE group.
>>>
>>>      In order to negotiate (or, to re-negotiate) the bundle address
>>>      associated with a BUNDLE group, the Offerer, in the SDP Offer,
>>>      assigns a unique address to each "m=" line in the BUNDLE group.
>>>      In addition, the Offerer indicates which unique address it wishes to
>>>      use as its local bundle address.  There Offerer places the mid value,
>>>      associated with the "m=" line that contains the preferred address
>>>      first in the SDP group:BUNDLE attribute mid list.  The Answerer
>>>      then selects the local bundle address for the Offerer ([ref-to-be-added]).
>>
>> I don't understand what the last sentence above is trying to tell me.
>
> The intention is to say that the Answerer selects the Offerer's bundle address.

I'm still having trouble making sense of this. Let me break out some 
things to try and understand. (I'm trying to state what I think you 
mean, not as it ought to be written in a draft, just for maximal clarity.)

It is the *answer* that selects the m-line that defines the bundle 
addresses for both offerer and answerer. Until then it isn't known.

Only after the bundle addresses are known may an offer be sent that has 
a common address for multiple m-lines in the bundle, and if so it must 
be the one that was previously defined as the bundle address.

As a consequence, on the initial offer that proposes a bundle, every 
m-line must have unique address info.

When sending an subsequent offer, after a bundle has previously been 
defined, (so the bundle addresses are known), multiple m-lines in that 
bundle *may* be offered with the same address info, but that address 
info must be the previously agreed bundle address.

As a consequence, to *change* a previously agreed bundle address, an 
offer must be sent where every m-line in the bundle has unique address info.

Does that accurately restate what you meant above?

(If so, you know that I don't agree - I find it much more prescriptive 
than it needs to be, with negative consequences. But lets be certain we 
agree what you are intending to say first.)

> --------------------------------------
>
>
>>>      If the Offerer, in a subsequent SDP Offer, wants to re-negotiate
>>>      the bundle address associated with a BUNDLE group, it MAY assign the
>>>      previously negotiated bundle address as a unique address to one of
>>>      the "m=" lines in the BUNDLE group.
>>>
>>>      If the Offerer assigns the bundle address to more than one "m="
>>>      line in a BUNDLE group, the first mid value in the SDP group:BUNDLE
>>>      attribute mid value list MUST represent an "m=" line to which the
>>>      bundle address is assigned.  Hence, in order to re-negotiate the
>>>      bundle address, the Offerer needs to assign a unique address to
>>>      each "m=" line in the BUNDLE group, as described above.
>>
>> I still object to this. It is a significant cost, and I don't understand how it adds any value over simply assigning a new address to all the bundled m-lines.
>
> The problem is not assigning a new address to all m- lines.

Then what is the problem?

>>From a specification perspective, it becomes a little more tricky when you add a new bundle address to some m- lines, and unique addresses to others.
>
> Also, the Answerer will have check and figure out that the suggested new BUNDLE address has been assigned to multiple "m=" lines, and that it therefore cannot move it out of the BUNDLE group without rejecting it, etc.

Yes. That doesn't seem to be any great burden.

> I guess one alternative could be to say that a suggested new BUNDLE address would have to be assigned to each "m=" line in the BUNDLE group. I.e. the Offerer would not be allowed to assign both a new BUNDLE address and unique addresses (e.g. for "m=" lines being added to the BUNDLE group).

Even that seems over prescriptive.

ISTM that the problem is being driven by what is easy to describe, 
rather than what is useful to do, even though the actual implementation 
effort would probably be the same or even less difficult.

While I do agree that clarity of explanation is important, that tells me 
we need to continue to work to find a clear way to express constraints 
without being over restrictive.

I previously tried - offering a set of constraints on offers and answers 
that I thought covered the cases. I still think that could work.

> --------------------------------------
>
>
>>> 6.2.2.  Bundle Address Synchronization (BAS)
>>>
>>>      When an Offerer has sent an SDP Offer, a bundle address has been
>>>      selected by the Answerer, and the bundle address was in the SDP
>>>      Offer not assigned to each "m=" line in the BUNDLE group, the Offerer
>>>      MUST send a new SDP Offer, in which it assigns the negotiated bundle
>>>      address to each "m=" line in the BUNDLE group.  This procedure is
>>>      referred to as Bundle Address Synchronization (BAS).
>>>
>>>      The Offerer MUST NOT modify any parameters associated with the
>>>      BUNDLE group when it performs a BAS.
>>
>> I still don't understand the point of this restriction.
>> What value does it add?
>>
>> Suppose that a need to make another change arises after the offer that proposed the bundle, but before the answer has been
>> received. Then, when the answer is received it will be necessary to send a BAS before sending another offer to make the new change. Why wait?
>>
>> ISTM that it would be better to say that after receiving an answer, if there is at that moment no need to send another offer, if the corresponding
>> offer had bundled m-lines with different addresses, then a BAS must be sent.
>
> The main reason for not allowing any parameter modifications in the BAS was to decrease the likelihood that the Answerer would reject the BAS (because it doesn't accept the suggested parameter changes).

You mean in the sense that the entire offer would be rejected at the 
signaling level - e.g., a sip 488?

The trouble is that this also disallows reasonable and non-risky 
changes, such as dropping an m-line, or reducing the set of codecs 
offered to a subset of what had been agreed.

> So, we can for sure allow parameter modifications in a BAS, but I think we need some text saying that an Offerer must perform a BAS until it is accepted.

Sure, that would be ok. And there could be a note that the offerer 
should try to construct the BAS to minimize the possibility that it will 
be rejected.

> --------------------------------------
>
>
>>> 6.2.4.  Removing A Media Description From A BUNDLE Group
>>>
>>>      When an Offerer removes an "m=" line from a BUNDLE group, the
>>>      Offerer MUST assign a unique address to the "m=" line that is removed.  In
>>>      addition, the Offerer MUST NOT place the mid value that was
>>>      previously defined for the "m=" line in the SDP group:BUNDLE
>>>      attribute mid value list associated with the BUNDLE group.
>>
>> nit: I don't think this should say anything about the mid value that was previously defined for the m-line. That implies that mid
>> values must be preserved from one o/a to another. While they probably will in most cases I don't think that should be required.
>> If I want, I should be able to "relabel" the m-lines with new mid values. This reduces the amount of state that is required to be
>> preserved from one o/a to the next.
>>
>> The statement "remove an m-line from a bundle group" already implies that the group does not contain a mid-value identifying that m-line (in
>> *this* offer or answer).
>
> Maybe I could say that the mid value that was previously defined is no more valid, and must not be present in any Offer or Answer.

The mid values from the previous o/a have *no* relevance to the new o/a.
It is *possible* (though not likely) that some of the same values may be 
used in the new offer to identify *different* m-lines. So saying that a 
value from a previous o/a must not be present is also not correct.

I don't think you need to say anything about this. Possibly you could 
say that the bundle group identifies the m-lines that are to be in the 
bundle, and so must not mention m-lines that are no longer in the 
bundle. But this is so obvious that stating it is likely to confuse 
people more than not stating it.

> --------------------------------------
>
>
>>> 6.2.5.  Rejecting A Media Description In A BUNDLE Group
>>>
>>> I agree with prior comment that using "Rejecting" here is weird and confusing. I agree that "disabling" is probably more appropriate.
>>> But then "disabling a media description in a bundle group" is still a little confusing, because it is then no longer "in" the bundle group.
>>>
>>> It might be clearer to just incorporate this into the prior section on removing a media description from a bundle group. E.g., in 6.2.4:
>>>
>>>     When an Offerer removes an "m=" line from a BUNDLE group, the Offerer
>>>     MUST assign either a unique address *or a zero port* to the "m=" line
>>>     that is removed.
>
> I at least intend to put back "disabling". I was also thinking about combining the sections, as you suggest, as the only difference is that
> the port value is set to zero in the reject/disable case.
>
>>>      When an Offerer rejects an "m=" line in a BUNDLE group, the
>>>      Offerer MUST assign a unique address, with a zero port value [RFC3264], to
>>
>> as long as the port is zero the address need not be otherwise unique.
>
> True. I guess your suggested text above ("unique address or a zero port") will fix that.
>
> As a side note, I intend to replace "unique address" and "bundle address" with "unique transport parameters" and "bundle transport parameters", as suggested by Martin.
>
> ...except in cases where the text actually talks about the IP address, that is :)

WFM.

	Thanks,
	Paul

> Regards,
>
> Christer
>