Subject: Re: [Sip] Providing Delayed Call Information

From: David Benoit <[email-masked]>
Date: Thu, 26 Jan 2006 13:07:07 -0400

On Thu, Jan 26, 2006 at 04:53:11PM -0000, Steve Langstaff wrote:
> Fair enough (you have your reasons :) but maybe I expressed myself
> unclearly. 
> 
> I was proposing that you don't hang round waiting for the response to
> your queries doing nothing else, but that this could be part of a parallel
> process (i.e. you could have thousands of such requests outstanding. 
> 
> So, yes, the latency would be say 100ms, but it would not increase for
> each INVITE in such a state. 

Certainly we would parallelize the requests and have, like you say,
thousands of these outstanding.  That is the current approach, and it
works.  I just don't like it.  I would rather have a system that can
provide updates.  We can provide updates to the media, why not the caller
info?

> Oh, and the act of providing this information might constitute a new
> call, if I've already (automatically?) rejected an anonymous call.  

Agreed, it might.  However, the large majority of such interactions happen
with a real person and not with an automated system.

I guess the answer I'm getting in that this type of thing is not really
handled, and the details of any method of providing such updates would
have to be explored.

On Thu, Jan 26, 2006 at 05:01:28PM -0000, Steve Langstaff wrote:
> Another (less yucky) approach might be to send a re-INVITE once you have
> the calling information buT:
>
> *) you are maybe not guaranteed that the called device will render the
>    new information to the user.
> *) you might have to wait for the initial INVITE/OK/ACK to complete
>    before you can send s re-INVITE.
> *) the called device might already have cleared the call.
>
> Is the device doing this lookup a proxy or B2BUA? It sounds like it's
> going to have to track the state of the calls in progress.

It's a B2BUA.  In terms of using a re-INVITE, I want to present the
updated information _before_ the call is answered, so that's a no go.
That's also why I had initially looked into using the UPDATE method, but,
sadly, that doesn't seem to be able to affect anything but the media
parameters.

Any chance UPDATE could be updated to do so?

David

> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 26 January 2006 16:43
> To: Steve Langstaff
> Cc: [email-masked]
> Subject: Re: [Sip] Providing Delayed Call Information
> 
> 
> 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

-- 
[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: Cullen Jennings <[email-masked]>
Date: Thu, 26 Jan 2006 09:35:11 -0800

There has been discussion on changing UPDATE to be able to modify some of
the non dialog forming information, or at least making UPDATE clearer about
what it means if various bits of information changing from the INVITE to the
UPDATE. I hope this work does happen,  however, I don't think this would
solve your problem...

It sounds like you have a problem where you are trying to modify the From
information before the the dialog is formed and UPDATE won't work in that
case. I also doubt that adding 100 ms to the post dial delay time will
really matter. Consider if your SIP device that is doing this lookup for the
CNAM was instead doing a DNS look up to resolve the host it was going to
send to. The DNS lookup could take way more than 100 ms. Your SIP server
would not stop doing the 2000 other things while this lookup happened - it
would keep doing them and wait for the response from the lookup then
continue with the processing. SIP servers do this all the time and it seem
to work fine. 

Cullen

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 26 Jan 2006 12:48:25 -0500

> It's a B2BUA.  In terms of using a re-INVITE, I want to 
> present the updated information _before_ the call is 
> answered, so that's a no go. That's also why I had initially 
> looked into using the UPDATE method, but, sadly, that doesn't 
> seem to be able to affect anything but the media parameters.
> 

UPDATE can basically update everything that a re-INVITE can.  However if I
recall correctly, some on the sip list view the concepts of updating
identities and retargeting as evil.

The topic was discussed within the following thread.  

http://130.230.52.14/list-archive/sip/msg07664.html

---

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

At 12:48 PM 1/26/2006 -0500, Brett Tate wrote:
>UPDATE can basically update everything that a re-INVITE can.

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.

>However if I

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 26 Jan 2006 13:50:23 -0500

> 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).