Subject: Re: [Sip] Providing Delayed Call Information

From: David Benoit <[email-masked]>
Date: Thu, 26 Jan 2006 12:42:59 -0400

On Thu, Jan 26, 2006 at 04:16:39PM -0000, Steve Langstaff wrote:
> I know you say that you are not willing to hold back the INVITE, but 100ms is not
> really a long time (assuming the calls are generated by people hitting keys)!

My problem is that sometimes what might be responding might be an
automated system.  It may also be just one piece of a chain of systems
that are working together to provide a service; 100ms is a long time when
you are talking latency.  So, in short, we can't wait.  100ms is a LONG
time; we can serve about 2000 other things in that time, and the more
things I can do in parallel the better.

> Here's a nasty workround... SIP's T1 timer is 5 times this at 500ms, so you could probably
> just trigger off whatever lookups you want to and drop the initial INVITE. 500ms later
> you will get another INVITE through and you can use your (cached) lookup results to rewrite
> the calling information.

Most of the time the systems I'm talking to get the initial trying back to
me in about 2ms.  Waiting an additional 498ms to move to the next step of
processing is not an option.  Relying on the resends should _only_ be used
to deal with failures i.e. packet loss, which on "good" networks doesn't
really happen.

The entire crux of my problem is that I don't want to wait.  I want to
provide updated information to the callee about the caller.  Even the POTS
does this type of thing out to your phone... it sends the initial voltage
to make your phone ring and then sends the calling information in the
WINK... Surely we should be able to this within SIP.

Here is another example of why I would want this.  Perhaps the "system" I
consult is actually the caller.  Sometimes we ask the caller if they would
like to provide calling information.  For example, based on the
preferences of the called party we may ask the caller if they want to
"lift" their privacy (if the callee doesn't accept calls from unknown
parties).  That's a LOT of latency.  And again, the act of providing this
information doesn't constitute a new call, but simply changes some of the
attributes of an existing call.

If all else fails, I would be willing to work on a draft of how to support
this type of update.

David

> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> David Benoit
> Sent: 26 January 2006 15:41
> To: [email-masked]
> Subject: [Sip] Providing Delayed Call Information
> 
> 
> Cross posting this as it may be more applicable here.
> 
> ----- Forwarded message from David Benoit <[email-masked]> -----
> 
> Date:	Tue, 24 Jan 2006 16:49:00 -0400
> From:	David Benoit <[email-masked]>
> To:	[email-masked]
> Subject: [Sip-implementors] Providing Delayed Call Information
> 
> Hi,
> 
> I want to solve the following problem.  A large number of the calls that
> we get from our providers have all the calling information present
> (i.e. the name of the caller, or CNAM if you wish), but some of the calls
> don't have that present.  We have several alternative sources for calling
> name information that we consult to populate that name (caches, databases,
> etc.) but that lookup can take "time" (not a long time, but not
> instantaneous).
> 
> The problem is, I don't want to hold back the INVITE until I get that
> information back; it could take like 100ms or so depending on the source
> and I am not willing to wait.  I want to send out the INVITE to the UAC
> and when the calling name information has been determined, send that to
> update the information that was in the INVITE.  As an example, for any of
> you Q.931/850 types out there, it would be the same as getting the Setup
> message without a calling name and getting a Facility message sometime
> later on with that name.
> 
> I initially thought that the UPDATE method was what I wanted, but after
> actually reading the RFC, it's not at all what I want.  I then thought
> that I wanted an INVITE/Replaces, but that seems to me like using a
> sledgehammer to hang a picture :)  and I'm not really sure it would have
> the desired effect.
> 
> So, I need to know if this is already "handled" in SIP.  I can't find
> anything that suggests how to do this and even though I could add support
> in our systems for a custom method that would allow this, I would rather
> not if the problem has already been solved.
> 
> Suggestions?   Thanks in advance!
> 
> David
> -- 
> [email-masked] | phone: 902-832-2649  fax: 902-832-1015
>  "Complex problems have simple, neat and wrong solutions" - H. L. Menken
> _______________________________________________
> Sip-implementors mailing list
> [email-masked]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> 
> ----- End forwarded message -----
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip

-- 
[email-masked] | phone: 902-832-2649  fax: 902-832-1015
 "Complex problems have simple, neat and wrong solutions" - H. L. Menken

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 26 Jan 2006 13:54:42 -0500

But if the issue is providing information in "trusted" headers, isn't
the From a non-starter?

Wouldn't SASL or some P-header approach be the focus of attention?

Mike

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Brett Tate
> Sent: Thursday, January 26, 2006 1:50 PM
> To: James Polk (jmpolk); 'David Benoit'
> Cc: [email-masked]
> Subject: RE: [Sip] Providing Delayed Call Information
> 
> > But that list is the
> > 
> > Call-ID
> > To
> > From (and tag)
> > CSeq
> > 
> > and this "problem" seems to want to modify the From (and From tag) 
> > fields, which makes UPDATE and reINVITE each a non-starter.
> 
> I agree that no RFC has yet obsoleted the RFC 3261 backward 
> compatibility requirement concerning changing To and From 
> URIs.  And I do not recall if RFC 3261 has the same 
> requirement concerning the display name of the To and From.
> 
> If the devices support the various identity extensions (or 
> changing display names is valid), using UPDATE might solve 
> the problem.
> 
> Per RFC 3891 section 4, INVITE with Replaces MUST NOT be sent 
> to replace an early dialog unless the receiver originated the 
> dialog to be replaced.  It indicates forking as the reason.  
> Thus the "sledgehammer" approach which was mentioned is also 
> not currently valid (unless the restriction is removed by 
> another RFC).
> 
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 26 Jan 2006 13:13:12 -0600

>Wouldn't SASL or some P-header approach be the focus of attention?

Are you suggesting an assertion after the initial INVITE?

This is an interesting thought on the surface