[MMUSIC] comments on draft-ietf-mmusic-sdp-bundle-negotiation-05

[Paul Kyzivat <[e-mail]>]

I did a fairly careful read of this version.
The good news is that it keeps improving.
But I still found a number of things that I would like to see improved:

Regarding rtcp-mux:

The definition of Bundled media in section 2 implies that rtcp-mux is 
optional, but must be the same for all m-lines in the bundle.

Section 6.2.3 says m-lines in a bundle MUST have the rtcp-mux attribute.

Section 6.2.4 implies the use of the rtcp attribute is optional, but 
must be the same in all m-lines in the bundle.

IIRC there was discussion of what the rtcp attribute should be if 
rtcp-mux is in use. Either it shouldn't be used, or it should be the 
same port as for the rtp, or it doesn't matter. Seems like it would be 
best to say what to use in this case.

Section 6.2.6:

I'm not sure, but ISTM unique crypto attributes should be used for 
m-lines that have unique addresses, and should have identical values for 
m-lines that have identical addresses.

Section 6.4.1:

You talk about a "shared address" here and in later sections. But I 
can't find a statement anywhere that there can only be one shared 
address per bundle group. You might want to put this in the terminology 
section.

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.

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.

Section 6.5.4:

What should be done if rejecting the m-line causes the bundle group to 
be empty?

Section 7.2:

    o  The dynamic payload type values used in the "m=" lines MUST NOT
       overlap.

What do you mean by overlap? I thought we were going to allow the same 
PT to be used in multiple bundled m-lines as long as the definition of 
that PT was the same.

Section 8.2:

Shouldn't it be sufficient to supply candidates for one of the m-lines 
that share an address?

	Thanks,
	Paul