Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Identity Assertions and RTCDtlsTransport objects #114
Since it is now possible to have distinct RTCDtlsTransport objects for RTP and RTCP, this raises some questions. For example:
a. Are the certificates used for RTP and RTCP DTLS Transports necessarily the same on both the local and remote side? If they are supposed to be the same, what happens if they aren't?
Within a browser, it would appear to me that the certificates used for RTP and RTCP DTLS Transports should be the same (assuming that RTP and RTCP aren't multiplexed).
However, I am wondering whether a SFU could potentially terminate RTCP but not RTP, in which case the certificates and asserted identities might be different between RTP and RTCP.
A question is whether a browser should care about what the asserted identity is for RTCP, or whether it should just focus on RTP. So while a browser would always use the same certificate and identity for both RTP and RTCP, the question is whether it should be "strict in what it sends, liberal in what it is willing to receive".
As noted by Martin:
"a=identity is a session-level attribute and they should (MUST?) only be one."
[BA] So an application desiring compatibility with WebRTC 1.0 needs to require that the validated peer identities for RTP and RTCP be the same. Also, an ORTC implementation will only assert a single identity for RTP and RTCP. However, an application not requiring backward compatibility with WebRTC 1.0 could allow validated peer RTP and RTCP identities to be different.
Add the following text to Section 14.5:
"NOTE: Where RTP and RTCP are not multiplexed, distinct RTCRtpIceTransport, RTCRtpDtlsTransport and RTCIdentity objects can be constructed for RTP and RTCP. However, while it is possible for getIdentityAssertion() to be called with different values of provider, protocol and username for the RTP and RTCP RTCIdentity objects, application developers desiring backward compatibility with WebRTC 1.0 are strongly discouraged from doing so, since this is likely to result in an error."
Change the following text in Section 14.6 from:
" It is possible that multiple assertions will be signalled. A browser MAY either choose to treat
" Where RTP and RTCP are not multiplexed, it is possible that the assertions for both the RTP and RTCP DTLS transports will be validated, but that the identities will not be equivalent. For applications requiring backward compatibility with WebRTC 1.0, this MUST be considered an error. However, if backward compatibility with WebRTC 1.0 is not required the application MAY consider an alternative, such as ignoring the RTCP identity assertion."
pushed a commit
Jul 16, 2014
At the ORTC CG meeting on July 20, it was suggested that the same provider, protocol and username should be automatically shared between the RTP and RTCP RTCIdentity objects. However, it was not clear how to make this happen.
While the "component" of an RTCIdentity object can be determined from RTCIdentity.transport.transport.component, there is no easy way to determine the RTP RTCIceTransport given the RTCP RTCIceTransport, RTP RTCDtlsTransport given the RTCP RTCDtlsTransport or RTP RTCIdentity object given the RTCP RTCIdentity object.