Re: [MMUSIC] BUNDLE and RTCP

[Christer Holmberg <[e-mail]>]

Hi,

...
...
...
HOWEVER, we could make it SIMPLE and either:


1)      Mandate usage of rtcp-mux with BUNDLE. I.e. if BUNDLE is negotiated, rtcp-mux MUST be used.
This was already suggested in the past, but Paul(?) said we should not make such restriction without a good reason. I think the current issue is a good reason :)
             m=data channel 10000
m=rtp 11111
a=rtcp-mux
m=rtp 11222
a=rtcp-mux


2)      Mandate usage of either rtcp-mux OR the default "+1" port with BUNDLE. I.e. if BUNDLE is negotiated, rtcp-mux or "+1" MUST be used. The selection is based on whether the rtcp-mux attribute was included in the offer/answer or not.
m=data channel 10000             // rtcp-mux
m=rtp 11111
a=rtcp-mux
m=rtp 11222
a=rtcp-mux

m=data channel 10000             // "+1"
m=rtp 11111
m=rtp 11222

The solutions above would not allow explicit negotiation of an RTCP port when BUNDLE is used, but maybe we could live with that?
>Well, I could live with both of your suggestions, but I thought you wanted a solution that can also negotiate which a=rtcp attribute to use.

>If nobody really needs something like that , I would prefer 1) as it removes the needs for several implementation option that would only be needed to cover full backwards compatibility but would hardly be used.

Personally I don't have a strong preference, but as far as I know there may be environments where separate ports for RTP and RTCP are desired - even if BUNDLE is used.

>>Now, if we can agree on a way forward before Yokohama, you won't have to sit listening to me talking about BUNDLE at the meeting :)
>
>Well, I wouldn't be sitting there anyhow but understand that your motivation to speak there about BUNDLE again is probably limited.
I don't mind talking about BUNDLE - but I'd like to talk about it in the context of the great RFC that we have published :)
Regards,
Christer