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
