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

[Christer Holmberg <[e-mail]>]

Hi Paul,

As always, thank You for your detailed review and constructive feedback! :)

Comments inline.

> 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.

Yes.

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.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.

I've left section 6.2 untouched on purpose for quite a while, as the SDP attribute impacts on BUNDLE are described in draft-nandakumar-sdp-mux-attributes. At some point, we'll need to decide whether we are going to move text from there into the BUNDLE spec, or whether the BUNDLE spec is only going to reference it.

There has been very little discussion on that draft, so I encourage people to take a look and give comments :)

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

> 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.

My assumption is that there doesn't have to be only one shared address within a BUNDLE group. And, that is also the reason I separated the "BUNDLE address" and "shared address" terminology. "BUNDLE address" means the transport address used for a BUNDLE group, while "shared address" means an address shared by multiple m- lines. Of course, when the BAS Offer is sent, the value of those addresses are the same :)

But, some further clarification text about that is probably useful.

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

> 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.

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 :)

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

> 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.

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

> 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).

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.

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

> 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.

This is another section that I haven't touched for a long time on purpose, as we are still discussing the criteria for PT value re-usage. There is an e-mail thread on that specific topic.

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

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

Another section I've left untouched, since I assume it will be covered in draft-nandakumar-sdp-mux-attributes.

I should probably add notes in places where we have the draft-nandakumar-sdp-mux-attributes dependency.

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

Regards,

Christer