Re: [Sip] submission of a new I-D: "Dialog Event foRIdentityVErification"

["Dan Wing" <dwing at cisco.com>]

> While I agree with what you say, this only works if the verification 
> will happen in a timely way. If you want white/black lists, then the 
> verification must happen even before the phone rings. Is it 
> reasonable 
> to assume that in typical deployments the time for the reverse lookup 
> will be quick enough to give reasonable experience to the caller? Or 
> will he have already hung up? (I don't have a good sense for 
> the numbers here.)

It's an extra round trip, yes.  So are ICE, DTLS-SRTP, connectivity
preconditions, security preconditions, QoS preconditions, Connected-
Identity, and a myriad of other things.  Why should DERIVE be viewed
with derision when SIP has already enjoyed a rich history of 
additional messages to handle important cases?  And if validating
a "From:" isn't important, I have a phone call from George W. Bush
for you..

> What will the caller be hearing until this gets done? Perhaps 
> 180 could be returned, which would at least give *some* feedback.

Sure.  Let's discuss the bigger picture, though:  do we need 
something like DERIVE.

> If this takes too long, then I think it ends up being info 
> that may be delivered after the call is established. (Perhaps 
> your callerid starts out yellow and turns green when it 
> has been confirmed.)

Yep, that is a reasonable approach, too.  If/when spoofed
>From becomes a common problem (how is everyone's daily dose
of email spam today?), this allows the called party to tighten
up their local policy to only ring the phone after the From:
is validated.

-d

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip