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

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Dec 2014 07:37:03 +0000

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.

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

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

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

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

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.

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.

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

> Section 11.2.1 says:
>
>    When an offerer assigns a unique address to a bundled "m=" line
>    (excluding and bundle-only "m=" line), it MUST also associate unique
>    ICE candidates [RFC5245] to the "m=" line.
>
> The parenthetical remark doesn't make sense to me. Did you perhaps mean: 
> "(excluding any bundle-only "m=" lines)"?

Yes. I'll fix that.

Thanks! 

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Dec 2014 09:32:53 -0500

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

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

> 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 bee…

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…

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 offere…

True. That is an argument in favor of keeping things as they are.

I guess you have convinced me.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Dec 2014 07:01:54 +0000

Hi Paul,

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

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

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

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

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

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Dec 2014 18:46:06 +0000

Hi,

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

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

I wonder whether others have an opinion on this issue.

The idea would be to, when a new offerer BUNDLE address is suggested, assign that suggested address to ALL bundle m- lines within the offer (instead of only assigning it to one m- line within the offer, and keep the previously selected offerer BUNDLE address for the other m- lines).

The advantage would be that no BAS offer is needed.

The only disadvantage is that, if the answerer does not accept (which I think will be an extremely rare case) the new offerer BUNDLE address, it has to reject the offer in order to fallback to the previous offerer BUNDLE address.

Also, when a new m- line is added to a BUNDLE group, the idea would be to always assign the current offerer BUNDLE address to that m- line. If the answerer does not accept the m- line in the BUNDLE group, it has to reject the m- line. But, there would be no need for a BAS offer.

Personally, the more I think about it, the more I like the suggestion :)

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 13 Dec 2014 02:03:25 +0100

2014-12-11 8:01 GMT+01:00 Christer Holmberg <[email-masked]>:
> 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,

But you know it wont XD

Why to try again by changing "something"?

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 13 Dec 2014 06:56:55 +0000

Hi,

You can try again by not adding the m- line to the BUNDLE group.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Iñaki Baz Castillo<mailto:[email-masked]>
Sent: ‎13/‎12/‎2014 03:03
To: Christer Holmberg<mailto:[email-masked]>
Cc: IETF MMUSIC WG<mailto:[email-masked]>; Paul Kyzivat<mailto:[email-masked]>
Subject: Re: [MMUSIC] bundle-13 - Paul's comments

But you know it wont XD

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 13 Dec 2014 10:39:58 +0100

You don't know why the peer rejected it, so trying again (by randomly
changing something) does not provide a determinist behavior/result.
On 13 Dec 2014 07:56, "Christer Holmberg" <[email-masked]>
wrote:

>  ------------------------------
> From: Iñaki Baz Castillo <[email-masked]>
> To: Christer Holmberg <[email-masked]>
> Cc: IETF MMUSIC WG <[email-masked]>; Paul Kyzivat <[email-masked]>
> > 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.
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 13 Dec 2014 11:05:41 +0000

Hi,

>You don't know why the peer rejected it, so trying again (by randomly >changing something) does not provide a determinist behavior/result.

Well, that is unfortunately a general problem in SDP O/A. You don’t always know exactly why something is rejected.

Also keep in mind that the current draft, when an m- line is added to an BUNDLE group, already allows assigning the BUNDLE address to that m- line. So, that is nothing new. What is new is that the offerer would always add the BUNDLE address to the added m- line, which also helps setting the associated SDP attribute values etc (the values may be different depending on whether an m- line is within a BUNDLE group or not, as described in the sdp-mux draft).

The second new thing (which triggered this discussion) is that, when a new BUNDLE address is suggested, that BUNDLE address should be assigned to all m- lines within the BUNDLE group. If the answerer accepts it, there is no need for a BAS offer. If the answerer rejects it, there will be a fallback to the current BUNDLE address (using normal 3264 rules). I believe an address change will be accepted in most cases, and if it’s not then there is probably going to be problems anyway…

So, regarding the first change (always assign the bundle address to a new m- line), I support that one. But, I do realize people may have other opinions, so that’s why I like to hear them :)

Regarding the second change (assign the new address to all m- lines), I personally support also that one, and I can’t see a reason not to do it. But, again, feel free to prove me wrong :)

Regards,

Christer

On 13 Dec 2014 07:56, "Christer Holmberg" <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

But you know it wont XD

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Sat, 13 Dec 2014 16:48:02 +0000

>From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
>Sent: Saturday, December 13, 2014 5:06 AM

>Well, that is unfortunately a general problem in SDP O/A. You don’t always >know exactly why something is rejected.
>Also keep in mind that the current draft, when an m- line is added to an >BUNDLE group, already allows assigning the BUNDLE address to that m- line. >So, that is nothing new. What is new is that the offerer would always add >the BUNDLE address to the added m- line, which also helps setting the >associated SDP attribute values etc (the values may be different depending >on whether an m- line is within a BUNDLE group or not, as described in the >sdp-mux draft).
>The second new thing (which triggered this discussion) is that, when a new >BUNDLE address is suggested, that BUNDLE address should be assigned to all >m- lines within the BUNDLE group. If the answerer accepts it, there is no >need for a BAS offer. If the answerer rejects it, there will be a fallback >to the current BUNDLE address (using normal 3264 rules). I believe an >address change will be accepted in most cases, and if it’s not then there is >probably going to be problems anyway…
>So, regarding the first change (always assign the bundle address to a new m- >line), I support that one. But, I do realize people may have other opinions, >so that’s why I like to hear them :)

<Raju>
If answerer rejects BUNDLE for new m= line then a BAS offer is required. Such BAS is required for initial offer/answer only if BUNDLE is negotiated. But for sub-sequent offer/answer making BAS requirement for non-BUNDLE case is kind of confusing and inconsistent. IMHO, having BAS requirement only for BUNDLE case of initial and sub-sequent offers is clear and simple.

Also, if the offerer wants new m= line as 'bundle-only' then won't it still set port to 0? Again, IMO, making semantics for this consistent with initial offer is also clear and simple.

Initial offer/answer negotiating a BUNDLE is no guarantee that sub-sequent offer/answers also do so. This is because newly added m= line's destination could be different from previously negotiated BUNDLED destination address as it may traverse different middle boxes (e.g. video transcoding requirements for newly added m= line). 

</Raju>

>Regarding the second change (assign the new address to all m- lines), I >personally support also that one, and I can’t see a reason not to do it. >But, again, feel free to prove me wrong :)

<Raju>
When a new BUNDLE address is suggested, the same SDP may change some other parameters (like video codecs). Such changes may require different destination(s) to be provided in SDP answer and as a result previous BUNDLE address can't be used. So, even in this case it is better to be consistent and have same rules as initial offer/answer, i.e. to assign unique address for each m= line and if BUNDLE is negotiated then follow up with BAS offer.

Even if the SDP just changes BUNDLE address only, IMHO, to preserve consistency and keeping it simple it is better to stick to initial offer/answer semantics.

</Raju>

BR
Raju

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 13 Dec 2014 17:28:21 +0000

Hi,

>>Also keep in mind that the current draft, when an m- line is added to an 
>>BUNDLE group, already allows assigning the BUNDLE address to that m- line. 
>>So, that is nothing new. What is new is that the offerer would always add 
>>the BUNDLE address to the added m- line, which also helps setting the 
>>associated SDP attribute values etc (the values may be different depending 
>>on whether an m- line is within a BUNDLE group or not, as described in the 
>>sdp-mux draft).
>>
>>The second new thing (which triggered this discussion) is that, when a 
>>new BUNDLE address is suggested, that BUNDLE address should be 
>>assigned to all m- lines within the BUNDLE group. If the answerer 
>>accepts it, there is no need for a BAS offer. If the answerer rejects 
>>it, there will be a fallback to the current BUNDLE address (using 
>>normal 3264 rules). I believe an address change will be accepted in 
>>most cases, and if it’s not then there is probably going to be 
>>problems anyway… So, regarding the first change (always assign the 
>>bundle address to a new m- line), I support that one. But, I do 
>>realize people may have other opinions, >so that’s why I like to hear 
>>them :)
>
>If answerer rejects BUNDLE for new m= line then a BAS offer is required.

Why?

A BAS offer is only needed if the selected offerer BUNDLE address is different from on or more of the addresses in the offer.

>Such BAS is required for initial offer/answer only if BUNDLE is negotiated. But for 
> sub-sequent offer/answer making BAS requirement for non-BUNDLE case is kind of >confusing and inconsistent.

Non-BUNDLE case? I am not sure I understand...

>IMHO, having BAS requirement only for BUNDLE case of initial and sub-sequent >offers is clear and simple.

Well, that is what the draft currently says. Paul's suggestion removes the need for a BAS in sub-sequent offers, which is good.

>Also, if the offerer wants new m= line as 'bundle-only' then won't it still set port to >0? Again, IMO, making semantics for this consistent with initial offer is also clear and >simple.

Port zero is not needed in sub-sequent offers, because you get the same effect by assigning the BUNDLE address to the new m- line: if the answerer does not accept it into the BUNDLE group, it MUST reject it. And, if the answerer accepts the new m- line into the BUNDLE group, a BAS offer is not needed (as the BUNDLE address was assigned to the new m- line in the offer). 

>Initial offer/answer negotiating a BUNDLE is no guarantee that sub-sequent >offer/answers also do so. This is because newly added m= line's destination could be >different from previously negotiated BUNDLED destination address as it may traverse >different middle boxes (e.g. video transcoding requirements for newly added m= >line).

Sure. But, in that case the offerer can send a new offer, where the new m- line is not added to the BUNDLE group. That is the case already today, because the draft allows assigning the BUNDLE address to the new m- line.

>>Regarding the second change (assign the new address to all m- lines), I 
>>personally support also that one, and I can’t see a reason not to do 
>>it. But, again, feel free to prove me wrong :)
>
>
>When a new BUNDLE address is suggested, the same SDP may change some other >parameters (like video codecs). Such changes may require different destination(s) to >be provided in SDP answer and as a result previous BUNDLE address can't be used. >So, even in this case it is better to be consistent and have same rules as initial >offer/answer, i.e. to assign unique address for each m= line and if BUNDLE is >negotiated then follow up with BAS offer.
>
>Even if the SDP just changes BUNDLE address only, IMHO, to preserve consistency >and keeping it simple it is better to stick to initial offer/answer semantics.

Perhaps we should allow both alternatives then. It enables the case of not having to send the BAS offer is the offer is accepted.

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Sun, 14 Dec 2014 14:55:30 +0000

> >If answerer rejects BUNDLE for new m= line then a BAS offer is required.

<Raju>
I meant a new offer, not BAS offer, to try m= line without BUNDLE. Sorry for stating it wrong.

</Raju>

> 
> A BAS offer is only needed if the selected offerer BUNDLE address is
> different from on or more of the addresses in the offer.
> 

<Raju>
For initial offer, a new offer (BAS) is needed to sync up the addressees in case BUNDLE is negotiated. But, making such a new offer requirement when BUNDLE is rejected for sub-sequent offer makes the initial and sub-sequent offer procedures inconsistent.  
</Raju>

> Well, that is what the draft currently says. Paul's suggestion removes the
> need for a BAS in sub-sequent offers, which is good.

<Raju>
IMO, I still think current text is clear and simple. Trying to optimize sub-sequent offers based on prior negotiation of BUNDLE may complicate and adds exceptions to the rule while overall gains may be minimal. I am ok either way though, but my preference vote is to keeping it simple in such scenarios.
</Raju>

> 
> >Also, if the offerer wants new m= line as 'bundle-only' then won't it still
> set port to >0? Again, IMO, making semantics for this consistent with
> initial offer is also clear and >simple.
> 
> Port zero is not needed in sub-sequent offers, because you get the same
> effect by assigning the BUNDLE address to the new m- line: if the answerer
> does not accept it into the BUNDLE group, it MUST reject it. And, if the
> answerer accepts the new m- line into the BUNDLE group, a BAS offer is not
> needed (as the BUNDLE address was assigned to the new m- line in the offer).

<Raju>
Port 0 is then another exception to the rule which is different for first offer vs. sub-sequent offers. Again, my preference would be to keep it simple for this as well. If we allow sub-sequent offers to be different then we need to define sub-sequent offers being offers that occur after BUNDLE negotiation is done as first BUNDLE itself could be negotiated in a sub-sequent offers.

Related questions on 8.4.2.  Bundle Address Synchronization (BAS)...
a. Can a BAS offer contain new m= lines? If yes, what are the semantics?
   I would assume same semantics as a non-BAS offer. A clarification
   would be good.
b. Can answerer originate an offer before the BAS offer/answer is done? If answerer sends another offer before BAS offer then can BAS sync be done in that round of SDP offer/answer?

</Raju>

> 
> >Initial offer/answer negotiating a BUNDLE is no guarantee that sub-sequent
> >offer/answers also do so. This is because newly added m= line's destination
> could be >different from previously negotiated BUNDLED destination address
> as it may traverse >different middle boxes (e.g. video transcoding
> requirements for newly added m= >line).
> 
> Sure. But, in that case the offerer can send a new offer, where the new m-
> line is not added to the BUNDLE group. That is the case already today,
> because the draft allows assigning the BUNDLE address to the new m- line.

<Raju>
Yes, but IMO sticking to initial offer/semantics makes it simple and still handle all offer/answer scenarios. I consider the proposed changes as an optimization, which may not have many benefits but introduces some risks (as already pointed by Iñaki Baz Castillo earlier, of second guessing the reason for offer rejection) and more implementation logic.
</Raju>

> >When a new BUNDLE address is suggested, the same SDP may change some other
> >parameters (like video codecs). Such changes may require different
> destination(s) to >be provided in SDP answer and as a result previous BUNDLE
> address can't be used. >So, even in this case it is better to be consistent
> and have same rules as initial >offer/answer, i.e. to assign unique address
> for each m= line and if BUNDLE is >negotiated then follow up with BAS offer.
> >
> >Even if the SDP just changes BUNDLE address only, IMHO, to preserve
> consistency >and keeping it simple it is better to stick to initial
> offer/answer semantics.
> 
> Perhaps we should allow both alternatives then. It enables the case of not
> having to send the BAS offer is the offer is accepted.

<Raju>
I am ok to allow both alternatives.
</Raju>

Thanks
Raju