On 3/13/08 11:59 AM, Dean Willis wrote: > 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. >
That's the problem I have -- if the calling party reported by the PSTN has been completely pulled out of the "From" header field, then you'll have very bad interaction with currently deployed phones. I don't think that's a reasonable trade-off. That's why I think this... > It might work to have the gateway use a reserved value, like "sip:[EMAIL > PROTECTED]". > ...is a non-starter. > Or it might work to extend RFC 4474 to have a "strength of assertion" > indicator. > You mean something like: From: <sip:[EMAIL PROTECTED];user=phone;trusted=no> ? Or something more like: Identity: "LotsOfBase64EncodedGunk==";trusted=no (I acknowledge that this can be more nuanced than yes/no, but let's decide where the bike shed goes before we begin the argument about its color). > 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. > That would argue for some indication on the *From* header field that indicates a level of trust. I'm not sure it's really the proper place to place that information, from a semantic perspective -- but it does seem to be a potential way to get through this maze of thorns without losing too much blood. /a _______________________________________________ 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
