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

[Paul Kyzivat <[e-mail]>]

Following up on some items...

On 10/28/13 6:45 AM, Christer Holmberg wrote:

>> 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.
>
> What I am trying to say is: in the Offer, unless the BUNDLE address (determined by the Answerer) was assigned to each m= line in the BUNDLE group, a new Offer must be sent.

*That* I can understand! But IMO it is not what you need to say here. It 
is over simplified. It doesn't cover the case where some of the m-lines 
have been rejected in the answer. Also, it doesn't really say what 
"BUNDLE address (determined by the Answerer)" means. (In reality, a 
bundle has two addresses - one in the offer and one in the answer. The 
thing that will eventually be in common between the offer and the 
answer, that determines those addresses, is the mid value.)

> Maybe the following text is easier to understand:
>
> 	"When an Offerer receives an Answer, in which an offered BUNDLE group is accepted,
> 	unless, in the Offer, the BUNDLE address (determined by the Answerer [ref-to-section-6.5.1])
> 	was assigned to each "m=" line within the BUNDLE group, 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.
>
> Perhaps it can be even further simplified, but hopefully it is at least easier to understand now :)

It has too many complex clauses. It needs to be simplified. As I 
suggested previously, I think trying to say it in one sentence is too 
much to attempt in the English language. So I suggest something of the form:

"When the Offerer receives an Answer it checks if the answer meets all 
of the following conditions:
- something
- something else
- ...

If so, 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.

> ----------------------------
>
>> Section 6.5.1
>>
>> This section is titled "Offerer Bundle Address Selection", and starts out:
>>
>>     When an Answerer generates an Answer that contains a BUNDLE group,
>>     the Answer MUST select the Offerer's BUNDLE address.
>>
>> As I noted earlier, I find this terminology confusing about who is doing what. I think it would be clearer to say this as follows:
>>
>>     6.5.1. Answerer Selection of Offerer's Bundle Address
>>
>>     When an Answerer generates an Answer that contains a BUNDLE group,
>>     the Answer MUST select the m-line that will determine the BUNDLE
>>     address for offerer and answerer.  The first mid value in the SDP
>>     group:BUNDLE attribute mid list of the Offer represents the m-line
>>     which the Offerer wishes the Answer to select. (Section 6.4.2.)
>>
>>     The Answerer SHOULD select the the first mid value from the offer,
>>     unless the Answerer in the associated Answer will reject the
>>     "m=" line associated with that mid value, or remove the "m=" line
>>     from the BUNDLE group.  In such case the Answerer MUST select
>>     the first unrejected mid value that remains in the SDP group:BUNDLE
>>     attribute mid list of the Offer.
>
> Looks good. Maybe we should not use the word "Selection" in the subject, though, if we are going to use "determine" terminology.

OK

> ----------------------------
>
>> Section 6.5.4:
>>
>> What should be done if rejecting the m-line causes the bundle group to be empty?
>
> I've been thinking about that myself.
>
> Either the Answer doesn't contain the SDP group:BUNDLE attribute, or it contains an SDP group:BUNDLE attribute with an empty value list (we would need to double check whether the group attribute ABNF allows that).

It not only allows it, it requires that it be used this way. (See 5888 
section 9.2.)

> I think it would be a little strange to include an empty attribute, though. The only advantage is that it could be used to indicate support of the BUNDLE mechanism. But, if we need to be able to do that even if there is no BUNDLE group we should probably define something else.

I don't think we need another mechanism. This one seems to suit the 
purpose well.

	Thanks,
	Paul