I don't understand the focus on PSTN gateways. Is it believed that only PSTN gateways ever create URIs with numeric user parts? Or that PSTN gateways are particularly untrustworthy? Neither seems reasonable to me.
tim > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dean Willis > Sent: Thursday, March 13, 2008 12:00 PM > To: IETF SIP List > Subject: [Sip] The thing we're missing in the RFC 4474 and > DTLS-SRTP discussion > > > We seem to agree that RFC 4474 assertions involving things that look > like phone numbers can not really be trusted, and probably therefore > should not be sent. > > However, DTLS-SRTP doesn't function without RFC 4474. > > So, if you need to use DTLS-SRTP to protect a phone call that > involves > a numeric identity (and that includes E.164, private phone numbers, > and numeric user parts of any kind), you end up having to > send an RFC > 4474 Identity header that is going to mislead people. > > So as things are currently written, one can never use > DTLS-SRTP with a > numeric userpart in the identity. > > That's the part that we absolutely have to sort out. > > We could fix this by having gateways encode their identity using a > reserved userpart. This has to have the property of saying "Do not > display this as caller-ID". Using "sip:domain" or > "sip:ipaddress" does > not work, as those might actually be valid URIs that be be displayed > as IDs. > > It might work to have the gateway use a reserved value, like > "sip:[EMAIL PROTECTED] > ". > > Or it might work to extend RFC 4474 to have a "strength of > assertion" > indicator. > > It's certainly easier to add guidance in DTLS-SRTP about what > gateways > should do and about how UASes should interpret various header fields > than it is to change RFC 4474. > > However, we need to note that a standards-track document cannot say > "Use P-Asserted-Identity". That would be an unacceptable downref. It > could however say "If the identity encoded in the RFC 4474 Identity > header has the reserved userpart "pstngateway", then the UAS > MUST NOT > display this to the user as the calling party identifier. > Rather, the > UAS should use other indicators of calling party identity > that may be > available to it. > > -- > Dean > _______________________________________________ > 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
