Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19

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:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 17 April 2015 18:07
To: Paul Kyzivat; mmusic@ietf.org
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:pkyzivat@alum.mit.edu>
Sent: ‎17/‎04/‎2015 16:52
To: mmusic@ietf.org<mailto:mmusic@ietf.org>
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
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic