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

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Apr 2015 09:58:47 +0000

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.

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

> The optionality in section 8.5.2 seems unnecessarily complex, and it's difficult to see what it gains us. Why don't we simply specify that each pre-existing m= line MUST have a single shared address?
>
>To be clear: if we keep this behavior, then I think we want the answer to that question in the document.

Personally, I would be happy to always mandating a shared address.

I think the main reason for not mandating a shared address is if a new m- line is added to the BUNDLE group. If you assign the shared address to the new m- line, and the UAS does not accept it into the BUNDLE group, it has to reject it.

Of course, we COULD say that one cannot add a new m- line, and suggest a new BUNDLE address, within the same offer...

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

Thanks!

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Apr 2015 09:52:17 -0400

Comment at end.

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

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Apr 2015 15:07:19 +0000

Hi Paul,

Correct, it would also apply to the address.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Paul Kyzivat<mailto:[email-masked]>
Sent: ‎17/‎04/‎2015 16:52
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments

Comment at end.

        Thanks,
        Paul

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Apr 2015 16:21:54 +0000

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:[email-masked]] On Behalf Of Christer Holmberg
Sent: 17 April 2015 18:07
To: Paul Kyzivat; [email-masked]
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments

Hi Paul,

Regards,

Christer

        Thanks,
        Paul

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Apr 2015 16:29:13 +0000

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?

Regards,

Christer

From: Christer Holmberg
Sent: 17 April 2015 19:22
To: Christer Holmberg; Paul Kyzivat; [email-masked]
Subject: RE: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments

Hi,

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 17 April 2015 18:07
To: Paul Kyzivat; [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments

Hi Paul,

Regards,

Christer

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 18 Apr 2015 15:17:13 -0400

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?

> 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; [email-masked]
> *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:[email-masked]] *On Behalf Of *Christer
> Holmberg
> *Sent:* 17 April 2015 18:07
> *To:* Paul Kyzivat; [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [MMUSIC] WGLC for
> draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments
>
> Hi Paul,
>
> ------------------------------------------------------------------------
>
> *From: *Paul Kyzivat <mailto:[email-masked]>
> *Sent: *‎17/‎04/‎2015 16:52
> *To: [email-masked] <mailto:[email-masked]>
> *Subject: *Re: [MMUSIC] WGLC for
> draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments
>
> Comment at end.
>
> [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 Apr 2015 09:48:48 +0000

Adam, do you have any comments on this? Otherwise I will not do any technical changes.

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 18. huhtikuuta 2015 22:17
To: Christer Holmberg; [email-masked]
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-19 - Adam's technical comments

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?

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

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

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