Re: Issue 114: Identity Assertions and RTCDtlsTransport objects

While it makes sense for ORTC implementations to utilize the same provider, protocol and username when formulating an Identity Assertion for RTP and RTCP, it is not clear to me how we can require this, since it is possible to construct distinct RTCIdentity objects for RTP and RTCP and call getIdentityAssertion() with different parameters.  Without a "createdAssociatedIdentity" method to enable construction of an RTCIdentity object for RTCP from the one for RTP, it's not clear to me how we can avoid this.  

Assuming we don't want to go down that road, the following resolution might be the best we could do: 


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
this as an error or ignore the additional assertions. If multiple different
assertions are validated, then they MUST produce identical identity
values."

To:

"NOTE: Where RTP and RTCP are not multiplexed, it is possible that the assertions for both the RTP and RTCP 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."

Received on Monday, 14 July 2014 21:57:38 UTC