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

[Paul Kyzivat <[e-mail]>]

On 4/17/15 12:29 PM, Christer Holmberg wrote:
> More about this:
>
> 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?

Another related problem: Consider Adam's example:

> a=group:BUNDLE foo bar
> m=video 20002 RTP/AVP 97
> a=rtpmap:97 H261/90000
> a=mid:foo
> m=video 0 RTP/AVP 97 98
> a=rtpmap:97 H261/90000
> a=rtpmap:98 VP8/90000
> a=bundle-only
> a=mid:bar

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?

That of course makes little sense, since without foo there is no bundle.

But I think the same is true for Adam's case. So I think this is a 
"problem" that doesn't need fixing.

	Thanks,
	Paul


> Regards,
>
> Christer
>
> *From:*Christer Holmberg
> *Sent:* 17 April 2015 19:22
> *To:* Christer Holmberg; Paul Kyzivat; [e-mail]
> *Subject:* RE: [MMUSIC] WGLC for
> draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments
>
> Hi,
>
> 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?
>
> 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.
>
> Regards,
>
> Christer
>
> *From:*mmusic [mailto:[e-mail]] *On Behalf Of *Christer
> Holmberg
> *Sent:* 17 April 2015 18:07
> *To:* Paul Kyzivat; [e-mail] <mailto:[e-mail]>
> *Subject:* Re: [MMUSIC] WGLC for
> draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments
>
> Hi Paul,
>
> Correct, it would also apply to the address.
>
> Regards,
>
> Christer
>
>
>
> Sent from my Windows Phone
>
> ------------------------------------------------------------------------
>
> *From: *Paul Kyzivat <mailto:[e-mail]>
> *Sent: *‎17/‎04/‎2015 16:52
> *To: *[e-mail] <mailto:[e-mail]>
> *Subject: *Re: [MMUSIC] WGLC for
> draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments
>
> Comment at end.
>
> On 4/17/15 5:58 AM, Christer Holmberg wrote:
>> Hi Adam,
>>
>> Most of your editorial comments seem ok. I'll comment them later.
>>
>> However, at least a couple (please let me know if you think there are more non-editorial ones) of your comments was technical, and I'll focus on those in this reply.
>>
>> ---------------------------------------------------------------------------
>>
>>> The procedure described in Section 8.3.2 has a rather unfortunate property that I'm not sure we want. If I were to offer something like:
>>>
>>> a=group:BUNDLE foo bar
>>> m=video 20002 RTP/AVP 97
>>> a=rtpmap:97 H261/90000
>>> a=mid:foo
>>> m=video 0 RTP/AVP 97 98
>>> a=rtpmap:97 H261/90000
>>> a=rtpmap:98 VP8/90000
>>> a=bundle-only
>>> a=mid:bar
>>>
>>> And the remote endpoint wanted to reject the first stream, it would be forced to also reject the second. The historical intention of using "bundle-only" was as a mechanism
>>> for UDP port preservation on the offerer's side. This procedure unintentionally turns it into a semantic binding among streams in bundle.
>>>
>>> I think we could restore the original purpose of the bundle-only handling if we used the port from the rejected 'm=' line containing the BUNDLE-tag for any 'bundle-only' lines.
>>
>> So, I guess that means we would *always* use the BUNDLE-tag m- line port - even if the m- line is rejected, AND even if there are other non-bundle-only m- lines that are NOT rejected.
>>
>> Example:
>>
>> a=group:BUNDLE foo bar zoo
>> m=video 20002 RTP/AVP 97
>> a=rtpmap:97 H261/90000
>> a=mid:foo
>> m=video 40002 RTP/AVP 97
>> a=rtpmap:99 H264/99999
>> a=mid:zoo
>> m=video 0 RTP/AVP 97 98
>> a=rtpmap:97 H261/90000
>> a=rtpmap:98 VP8/90000
>> a=bundle-only
>> a=mid:bar
>>
>> Now, if the UAS rejects the "foo" m- line, it would still select port 20002 for the offerer. The UAS would NOT select port 40002, even if it accepts the "zoo" m- line.
>
> There are more implications. If you are going to do this for the port,
> then you need to do it for the address (c=) too. While most likely you
> would see the same address used for each, it is possible that when
> getting a unique address/port pairs that you can't (or at least don't)
> get the same address for each. We don't require them to be the same.
>
>          Thanks,
>          Paul
>
> _______________________________________________
> mmusic mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mmusic
>