> This issue is totally independent from E.164
Not fully. SBCs may exchange the domain part of the E.164 SIP URI, which causes a break of the RFC 4474 signature. With email-style URIs a simple exchange is not possible. > > I don't like the idea of requiring DTLS-SRTP to provide proof of > possession of the keying material. It is also the other way round. If you use DTLS-SRTP to encrypt RTP, the terminating domain is interested where the call originates from and in which domain the SRTP connection is terminated. DTLS-SRTP is not initially used as mean to establish an identity rather than as the initial aim to encrypt RTP. Kai > > Ciao > Hannes > > > Elwell, John wrote: > > SBCs do exist, often for good reasons that Hadriel has expanded on > > already. I firmly believe that DTLS-SRTP will not be deployable in a > > meaningful way without addressing this problem. Concerning > solutions, we > > have drafts from Kai and Dan, or perhaps a merger of the two somehow > > would work. It also depends to some extent whether we are > talking only > > about email-style URIs or about E.164-based URIs too. > > > > John > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use [EMAIL PROTECTED] for questions on current sip > > Use [EMAIL PROTECTED] for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
