Re: [MMUSIC] bundle-13 - Paul's comments

[Christer Holmberg <[e-mail]>]

Hi Paul,

>>> In general the use of the new terminology (identification-tag) is an improvement. I have the following comments:
>>>
>>> Section 5.1 says:
>>>
>>>     A single address:port combination is also used for sending bundled
>>>     media.  The address:port combination used for sending bundled media
>>>     MAY be the same as the BUNDLE address, used to receive bundled media,
>>>     depending on whether symmetric RTP is used.  A given address:port
>>>     combination MUST NOT be used for sending media associated with
>>>     multiple BUNDLE groups.
>>>
>>> If symmetric RTP is *not* used, what is the value of requiring that a single address:port be used for sending? The receiver, and intermediaries, won't know what that address is until the media starts flowing.
>>>
>>> Also, why would it be forbidden to use the same address to send to multiple bundle groups?
>>>
>>> The restriction makes sense with ICE, but in that case it is ICE providing the restriction. In the absence of ICE these restrictions seem arbitrary and without motivation.
>>>
>>> (Note that this limitation is also mentioned in section 10.3.1.)
>>
>> I thought we agreed in Honolulu that we would use a single address:port also for sending.
>
> I don't recall exactly what was said.
>
> Here I'm asking if such a restriction adds any value and makes any sense.

First, the SDP attribute handling rules in draft-nandakumar-mmusic-sdp-mux-attributes are based on the media being multiplexed. It would be difficult e.g. for an intermediary to apply those, if e.g. one endpoint DOES send media from a single address:port, and the other endpoint doesn't (in which cases the rules in draft-nandakumar-mmusic-sdp-mux-attributes don't apply). And, the intermediary wouldn't even know whether an endpoint uses a single address:port until the endpoint start sending media. So, it think mandating a single address:port provides consistency, which makes the life easier especially for intermediaries (but perhaps also for endpoints).

Second, doesn't the definition of 5-tuple imply using a single address:port also for sending?


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


>>> Section 7.2:
>>>
>>> I presume that the "c=" line associated with a bundled "m=" line could either be a media-level c-line following the m-line, or a session-level c-line preceding the first m-line. Is that right?
>>
>> Yes.
>>
>>> Perhaps that should be stated.
>>
>> Eventhough I think it's basic SDP, I can add some text.
>>
>> But, in that case one could argue that we have to say the same thing for SDP attributes which can be both session-level and media-level...
>
> My question is really about the meaning of the general phrase: 'the "<something>=" line *associated with a bundled "m=" line.'
>
> To me it makes sense that it would include both session and media-level lines. I'm just not certain that this will be obvious to everyone.

Do you have some clarification text in mind?

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

>>> Section 8.5.2:
>>>
>>> I want to check what is intended here.
>>>
>>> Suppose I have previously established a bundle group. It has several m-lines. In the prior O/A all of those m-lines had the same address:port. Now I want to change the bundle address.
>>>
>>> As I read the text in this section, I must change the address in *1* of the m-lines, and suggest it as the offerer bundle address, but leave the old address in the other m-lines.
>>>
>>> That isn't what I had been thinking happened. I had been assuming that the address would be changed in all the m-lines.
>>>
>>> The consequence of this is that if the answerer doesn't want the 
>>> change, it will have to reject the one changed m-line, and select the old address as the bundle address. If I was making the change because I am no longer capable of using the old address then this won't work for me.
>>> It would be better for me to have the entire bundle rejected.
>>
>> The thinking has been that only an accepted BUNDLE address can be assigned to multiple m- lines. Your suggestion would change that, because the new address (when suggested in the offer) has not been accepted as a BUNDLE address yet.
>
> First I just wanted to verify that is what is intended.
> That is now settled.
>
> Next is whether that is the best way to handle this.
>
>> Also, even if the offerer assigns the new address to all m- lines, and the answerer rejects the offer, the offerer still has to fall back to the previous offerer BUNDLE address - no matter whether it can use it or not.
>
> The answerer could reject all the m-lines yet accept the offer.
>
> But yes, if the offer itself is rejected then there is need to fall back.
>
>> AND, assuming we go along with your suggestion, I guess that also means that if a new m- line is added (section 8.5.3), and if the 
>> offerer wants the address of that m- line to become the new offerer BUNDLE address, the offerer must also assign the address of the 
>> new m- line also to the other m- lines in the BUNDLE group.
>
> True. That is an argument in favor of keeping things as they are.
>
> I guess you have convinced me.

I wasn't trying to convince you - I just wanted to make sure we take all the impacts into consideration. I have learned that, what first may look like a small and isolated change, may have big impacts throughout the document :)

The advantage of assigning the suggested new offerer BUNDLE address to all "m=" lines is that you don't have to send a BAS offer afterwards - which is a big advantage.

Of course, in the case of adding a new m- line to a BUNDLE group, if the answerer does not accept it in the BUNDLE group, the answerer will have to reject it. In that case, the offerer could send a new offer, and keep the new "m=" line outside the BUNDLE group. But, IF the new "m=" line IS accepted in the BUNDLE group, the BAS offer is not needed.

So, personally I have no problem with your suggestion. Mandating a shared address (whether it's a previously selected offerer BUNDLE address, or a new suggested offerer BUNDLE address) makes things more clear. I just want to make sure others are ok too, because it would be a technical change.

Regards,

Christer