On Mar 13, 2008, at 1:58 PM, Adam Roach wrote:
> 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...
That;s why John proposed P-AI-ID as the Caller-ID source.
>
>
>> It might work to have the gateway use a reserved value, like "sip:[EMAIL
>> PROTECTED]
>> ".
>>
>
> ...is a non-starter.
How about:
From: +12142821376 <sip:[EMAIL PROTECTED]>
>
>
>
>> 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).
yeah, those might work as well. Although this approach has the
advantage of not modifying RFC 4474, just giving guidance about how
gateways could use it. This could be done in DTLS-framework.
>
>
>> 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.
I like 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
