"Even, Roni" <roni.even at polycom.co.il> writes:RTP is by nature unidirectional while RTCP is bi-directional. The comments has to with this
RTCP is not bidirectional (in terms of ports). Both RTP and RTCP are
unidirectional and specified by the receiver. I understand what you mean,
but technically it's not the case.
1. The draft should address the behavior of both sides when they are not
in a default sndrcv mode. Meaning the offerer wants to send only. Also
address hold scenario.
Ok, though it's not any different than normal - unless there's some
difference from normal behavior I don't see the need to add text - and
adding it could confuse people; they'll assume there has to be something
different for you to need to mention it.
Right - I don't think anything different happens here when multiplexing.
2. Since RTP is unidirectional what about multiplexing only to one
direction, currently you prevent it. The offerer may offer the same RTP
and RTCP port, the remote side can send both RTP and RTCP to the same
port but prefers to receive on different ports, do you think it makes
sense.
The current spec makes that impossible since it uses rtcp == rtp as a
form of indirect signalling that the answerer is ok with this. Note that
most implementations that support a=rtcp would support rtcp == rtp without
any modification, if the spec didn't mandate that they respond with rtcp ==
rtp. While I can't think of why an existing implementation with a=rtcp
support *wouldn't* work if it got an rtp == rtcp offer, I suppose it's
possible.
You could add another parameter (a=rtcpmux:ok or some such) to indicate
that it was understood, but the responder doesn't want to receive muxed
data for some reason. (Perhaps some issue with gateways, relays or QoS for
example, though I can't think of one now..)
I'd be strongly tempted to remove the requirement to respond with rtcp=rtp,
*perhaps* add a=rtcpmux:ok, and allow the implementation to decide whether a
renegotiation is required. (For example, if it gets the RTCP on the RTP
port, the other side probably is handling it ok anyways.)
Colin
_______________________________________________ Audio/Video Transport Working Group avt at ietf.org https://www1.ietf.org/mailman/listinfo/avt