Re: [Sip] Providing Delayed Call Information

[David Benoit <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]On Behalf Of
> David Benoit
> Sent: 26 January 2006 15:41
> To: [e-mail]
> Subject: [Sip] Providing Delayed Call Information
> 
> 
> Cross posting this as it may be more applicable here.
> 
> ----- Forwarded message from David Benoit <[e-mail]> -----
> 
> Date:	Tue, 24 Jan 2006 16:49:00 -0400
> From:	David Benoit <[e-mail]>
> To:	[e-mail]
> 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
> -- 
> [e-mail] | phone: [phone]  fax: [phone]
>  "Complex problems have simple, neat and wrong solutions" - H. L. Menken
> _______________________________________________
> Sip-implementors mailing list
> [e-mail]
> 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 [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip

-- 
[e-mail] | phone: [phone]  fax: [phone]
 "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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip