Subject: Re: [MMUSIC] comments on draft-ietf-mmusic-sdp-bundle-negotiation-05 - Paul's comments 20131027 - Section 6.4.3

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Dec 2013 11:55:03 +0000

Hi Paul,

I am working on a new version of BUNDLE, so I took a closer look at your comments on -05. I will address them in separate e-mails.

I GUESS we should allow it, at least in the initial Offer, in case the Answerer doesn't support BUNDLE. But, in the BAS Offer I guess we should either say that it is not used, that the value MUST be identical to the RTP port, or that the value doesn't matter.

----------------------------

> Section 6.4.3 says:
>
>    When an Offerer receives an Answer, in which an offered BUNDLE group
>    is accepted, if the Offerer in the associated Offer assigned an
>    address (unique or shared), that does not represent the BUNDLE
>    address selected for the Offerer, to an "m=" line within the BUNDLE
>    group, the Offerer MUST send a subsequent Offer, in which it assigns
>    the BUNDLE address selected for the Offerer to each "m=" line within
>    the BUNDLE group.  This procedure is referred to as Bundle Address
>    Synchronization (BAS), and the Offer is referred to as a BAS Offer.
>
> I tried to parse it below. To do so, I had to move "that does not represent the BUNDLE address selected for the Offerer,".
>
>   When an Offerer receives an Answer,
>     in which an offered BUNDLE group is accepted,
>        if the Offerer in the associated Offer assigned an address
>        (unique or shared), to an "m=" line within the BUNDLE group,
>           that does not represent the BUNDLE address selected for the
>           Offerer,
>
>    the Offerer MUST send a subsequent Offer, in which it assigns
>    the BUNDLE address selected for the Offerer to each "m=" line within
>    the BUNDLE group.  This procedure is referred to as Bundle Address
>    Synchronization (BAS), and the Offer is referred to as a BAS Offer.
>
> Even so, it still doesn't quite make sense to me. The problem is with "selected for the Offerer". IIUC it would state that as "selected by the Answerer".
>
> And in any case I'm not sure if I then have the intended interpretation.
>
> I *think* the condition you are trying to describe is:
>
> - offer included bundle group
> - answer accepted bundle group
> - M is the first mid in the bundle group in the answer
> - A is the media address of the m-line in the offer that
>   has mid M
> - some m-line in offered bundle group that was accepted in the answer
>   doesn't have media address A
>
> If that is what you are trying to say, then we just have to figure out how to say it intelligibly. I think trying to string it out into a sentence is not going to work, and so you need to break it down something like I did above.

I replied to this earlier, but I'll modify my reply a bit.

The mid has nothing to do with whether a BAS Offer needs to be sent or not. The Answerer will indicate which mid value represents the determined BUNDLE address, and it doesn't matter if that is not the same address as the Offerer requested to become its BUNDLE address.

The only thing which matters is whether the Offer contained addresses that are different from the determined BUNDLE address (in the initial Offer that will always be the case, as each address with a non-zero port value must be unique).

Never the less, I still tried to make the text more clear:

------------

6.4.3.  Bundle Address Synchronization (BAS)

   When an Offerer receives an Answer, in which an offered BUNDLE group
   has been accepted by the Answerer, it checks the following criteria:

   o  In the Offer the Offerer assigned an address (unique or shared) to
      one or more "m=" lines within the BUNDLE group, that is different
      than the BUNDLE address determined by the Answerer Section 6.4.2.

   If the criteria is fulfilled, the Offerer MUST send a subsequent
   Offer, in which it assigns the BUNDLE address to each "m=" line
   within the BUNDLE group.  This procedure is referred to as Bundle
   Address Synchronization (BAS), and the Offer is referred to as a BAS
   Offer.

   The Offerer MAY modify any SDP parameter in a BAS Offer.

   NOTE: It is important that the BAS Offer gets accepted by the
   Answerer.  For that reason the Offerer needs to consider the
   necessity to modify SDP parameters that could get the Answerer to
   reject the BAS Offer.  Removing "m=" lines, or reducing the number of
   codecs, in the BAS Offer used for the is considered to have a low
   risk of being rejected.

   NOTE: The main purpose of the BAS Offer is to make sure that
   intermediaries, that might not support the BUNDLE mechanism, have
   correct information regarding which address is going to be used for
   the bundled media.

   Section 12.1 shows an example of an BAS Offer.

----------------------------

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Dec 2013 12:58:49 -0500

Hi Christer

> I GUESS we should allow it, at least in the initial Offer, in case the Answerer doesn't support BUNDLE. But, in the BAS Offer I guess we should either say that it is not used, that the value MUST b…

The first mid in the bundle group in the answer determines which address 
in the offer will be the bundle address. This restates what you have in 
6.4.2.

> The only thing which matters is whether the Offer contained addresses that are different from the determined BUNDLE address (in the initial Offer that will always be the case, as each address with…

That isn't always true. When making this determination, the offerer 
should only consider m-lines that were accepted in the answer.

It might have to send a BAS if all the m-lines were accepted, but not 
need to do so if some were rejected and all the ones that were accepted 
matched the bundle address.

The trick is figuring out how to state that.

> Never the less, I still tried to make the text more clear:

This has the problem I just described. It may call for an unnecessary 
BAS offer.

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 8 Dec 2013 18:04:22 +0000

Hi Paul,

…
…
…

> in the offer will be the bundle address. This restates what you have in

Correct.

>> The only thing which matters is whether the Offer contained addresses that are different
>> from the determined BUNDLE address (in the initial Offer that will always be the case, as
>> each address with a non-zero port value must be unique).
>

Ok, I hear you. That is correct, and must be clear in the text.

> matched the bundle address.

Yes.

>The trick is figuring out how to state that.

Perhaps something like:

“When an Offerer receives an Answer, in which an offered BUNDLE group has
been accepted by the Answerer, the Offer checks each “m=” line within the
accepted BUNDLE group against the following criteria:

o  In the Offer the Offerer assigned an address (unique or shared) to
    the "m=" line, that is different than the BUNDLE address determined
    by the Answerer Section 6.4.2.”

Regards,

Christer (from LH404, somewhere over the English channel)

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Dec 2013 18:17:48 -0500

I guess this will work.

	Thanks,
	Paul

On 12/8/13 1:04 PM, Christer Holmberg wrote:
> /“When an Offerer receives an Answer, in which an offered BUNDLE group has /
> /been accepted by the Answerer, the Offer checks each “m=” line within the /
> /accepted BUNDLE group against the following criteria:/
> //
> /o  In the Offer the Offerer assigned an address (unique or shared) to
>      the "m=" line, that is different than the BUNDLE address determined /
> /    by the Answerer Section 6.4.2.”
> /
>
> Regards,
>