Re: [AVTCORE] Draft new: draft-holmberg-avtcore-5761-update-00

[Christer Holmberg <[e-mail]>]

Hi,

>>>> */That is tied to my question about can the answerer use a=RTCP to 
>>>> receive multiplex RTP and RTCP without explicitly using rtcp-mux
>>>> attribute?/*
>>>
>>> I agree that is fuzzy. IMO, attempts to do that ought to be 
>>> considered an error. But I don't know what sort of recovery action 
>>> should be taken for this error.
>>>
>>> Note that for an *answerer* to attempt this leads to nonsense. It 
>>> means the offerer will be sending both RTP and RTCP to a single port 
>>>> while the answerer (who set this up) must still send them to separate 
>>> ports. And since it wasn't anticipating that these be multiplexed it 
>>> will presumably be buffering as if they are going to separate ports. 
>>> I would think that would make a mess.
>>>
>>> It would be less problematic if first signaled by the offerer, 
>>> because then the answerer knows what is going on if it also uses a 
>>> single for both in the answer. But in this case they ought to be 
>>> explicitly signaling that they are multiplexing.
>>>
>>> It would be good to revise the definition of a=rtcp to clarify this, 
>>> so somebody not aware of a=rtcp-mux doesn't do this by accident.
>>
>>
>> I guess we¹d just need to add an sentence (to section 2.1 of RFC 3605) 
>> saying that one MUST NOT include the RTP port value in the attribute, 
>> right?
>
> I *think* that's right, at least in general. I haven't considered whether it might make sense in certain contexts in conjunction with other options/parameters.

I am not aware of such usage. And, considering the fact that people don't want to define new a=rtcp usages to begin with, I don't think there is a big risk for something to come up.

Regards,

Christer