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

[Christer Holmberg <[e-mail]>]

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