- From: Sergio Garcia Murillo via GitHub <sysbot+gh@w3.org>
- Date: Fri, 01 Apr 2016 09:37:07 +0000
- To: public-ortc@w3.org
murillo128 has just created a new issue for https://github.com/openpeer/ortc: == Clarification on usage of ssrc value on RTCRtpReceiver == ``` ssrc of type unsigned long The SSRC to be used in the "SSRC of packet sender" field defined in [RFC3550] Section 6.4.2 (Receiver Report) and [RFC4585] Section 6.1 (Feedback Messages), as well as the "SSRC" field defined in [RFC3611] Section 2 (Extended Reports). This is only set for an RTCRtpReceiver. If unset, ssrc is chosen by the browser, and the chosen value is not reflected in RTCRtcpParameters.ssrc. If the browser chooses the ssrc it may change it in event of a collision, as described in [RFC3550]. ``` This is a tricky one. The configured ssrc is going to be used at the RTPReceiver for sending back RTCP messages to the sender. Typically on a one-to-one situation this would be the same ssrc of the RTPSender. As we have no relationship between the RTPSenders/RTPReceiver this ssrc s the only field that to "match" them and send RTCP SR/RR on same ssrc. Not sure if it provides really any functionality for the API user, and if would be ever be needed. I think this should be handled internally by the ortc implementation and not exposed at all. Also note that browser may change it at any time without notification, ORTC spec is already too complex to add stuff that would not be used at all. Or do you foresee any use case in which this could be usable/needed at all? Please view or discuss this issue at https://github.com/openpeer/ortc/issues/449 using your GitHub account
Received on Friday, 1 April 2016 09:37:09 UTC