> > >> 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. > > > This is true but this applies to SIP Identity in general and not to > E.164 number usage with SIP Identity only. > Hence, I would not tie it to this discussion.
My point was, that with E.164 an intermediary SBC is able to exchange the domain part without a possibility on the terminating side to recognize the change. With email-like SIP URIs the domain change is not possible or only with a hack. Two cases need to be differentiated: -SBC modifies SDP: This results in a necessity to create a new SIP Identity signature and a change of the domain part in the From header (valid for both types of SIP URIs email and E.164) -SBC modifies From header field only: This is applicable to E.164 only and as far as I have recognized from the past discussions a real world behavior > > > > >> 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. > > > > I understand the need to know who the end points are. However, tying > DTLS-SRTP is not a good idea since it > a) increases the liklihood that SIP identity never get's > deployed (since > it is suddently far more complex than before) > b) SIP identity is used also as a identity mechanism in areas > where no > media is exchanged. Do you propose to not apply RFC 4474 for DTLS-SRTP fingerprint protection and to rely on something different? Kai > > Ciao > Hannes > > > 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
