Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments

From: Adam Roach <[email-masked]>
Date: Tue, 02 Jun 2015 16:58:13 -0500

On 4/27/15 04:48, Christer Holmberg wrote:
> Adam, do you have any comments on this? Otherwise I will not do any technical changes.

Sorry for the long delay in responding. I'm okay with leaving this 
property as it is described, for the sake of completing sooner. However, 
I do think the problem is pretty tractable. Some responses to the 
questions that were answered:

> Correct, it would also apply to the address.

Agreed.

> One issue related to this: if the answerer rejects the m- line, by 
> setting the port value to zero, how will it provide the port value 
> associated with the answerer BUNDLE address?
>

As normal: the answer will have its own "group:BUNDLE", and the first 
thing listed in it will indicate the port.

> The answerer BUNDLE port will of course be assigned to the other “m=” 
> lines within the BUNDLE group, but the port value associated with the 
> answerer BUNDLE tag will be zero.
>

Given that the line is being rejected, it's not part of the bundle, so 
it's lo longer the BUNDLE-tag.

> If the answerer rejects the “m=” line, it won’t (at least not 
> currently) even be part of the BUNDLE group. So, how will the offerer 
> know which port has been selected as the offerer BUNDLE port?
>

It will remember what the BUNDLE port was when it created its offer.

> Suppose, instead of rejecting foo, the answerer wants to accept it, 
> but doesn't want it to be part of the bundle. Yet it still wants to 
> accept bar as part of the bundle? 

Yes, this is an additional constraint introduced by the proposal, albeit 
one with basically no practical effect. As things presently stand, 
you're forced to unbundle everything if the the line you want to reject 
just happens -- by sheer and random coincidence -- to be the first line 
listed. In the case you describe, you're prevented from unbundling (why 
would you do that?) the first line without unbundling everything. Given 
that the first constraint runs afoul some real use cases, and the second 
seems quite esoteric, I think this trade-off would be a net win.

All that said, I don't want to hold up publication just to fix what is 
basically a minor flaw. If you want to publish as-is, I'm not going to 
object.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Jun 2015 11:41:28 +0000

Hi Adam,

>>One issue related to this: if the answerer rejects the m- line, by setting the port value to zero, how will it provide the port value associated with the answerer BUNDLE address?
>As normal: the answer will have its own "group:BUNDLE", and the first thing listed in it will indicate the port.

Currently, the “group:BUNDLE” attribute in the answer indicates the selected OFFERER bundle address – not the answerer BUNDLE address.

>>If the answerer rejects the “m=” line, it won’t (at least not currently) even be part of the BUNDLE group. So, how will the offerer know which port has been selected as the offerer BUNDLE port?
>

Currently, if the m- line with the port suggested as the offerer BUNDLE port is rejected (or moved out of the bundle group), the answerer must select another port from the offer - and indicate that port in the "group:BUNDLE" attribute of the answer.

>> Suppose, instead of rejecting foo, the answerer wants to accept it, but doesn't want it to be part of the bundle. Yet it still wants to accept bar as part of the bundle? 
>
> Yes, this is an additional constraint introduced by the proposal, albeit one with basically no practical effect. As things presently stand, you're forced to unbundle everything if the line you want to reject just happens -- by sheer and random coincidence -- to be the first line listed.

That is not correct. The answerer can select the port of another m= line in the offer for the offerer BUNDLE address.

>> In the case you describe, you're prevented from unbundling (why would you do that?) the first line without unbundling everything. Given that the first constraint runs afoul 
>> some real use cases, and the second seems quite esoteric, I think this trade-off would be a net win.
> All that said, I don't want to hold up publication just to fix what is basically a minor flaw. If you want to publish as-is, I'm not going to object.

I have no problem improving things, but I have a feeling that your suggestions would require a rather big re-design of BUNDLE.

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Wed, 03 Jun 2015 09:23:11 -0500

> I have no problem improving things, but I have a feeling that your suggestions would require a rather big re-design of BUNDLE.

Like I said, I'm all for publishing without any technical changes here. 
The flaw I've identified is a pretty minor one.

/a