Subject: RE: [Sip] UPDATE and Expires

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 10 May 2002 13:37:42 -0400

Pick up your phone and dial a number without a message system.
It will ring quite a while (not forever).  Mine waits multiple minutes.
The problem with making assumptions on how long to time out is 
that it's the user, not the UAC, that knows how long is long enough.  
What do you want to do, have him type in a timer length?  
Yes, you can use a timer on either end, but it needs to be on the 
order of minutes, not seconds, and it does not express the wishes 
of either the caller or the callee.  It's the system designer (or 
administrator if it's programmable)'s idea of how long is enough.

Note that in SIP, there are no messages passing while you are
waiting.  Of course, I want there to be a few (UPDATE with
Expire), just so that the called party knows the calling party
still thinks it ought to be ringing.  Then the expiry can be
on the order of seconds.

Brian

> -----Original Message-----
> From: Prabhas Sinha [mailto:[email-masked]]
> Sent: Friday, May 10, 2002 1:06 PM
> To: Bert Culpepper; 'Rosen, Brian'; [email-masked]
> Subject: Re: [Sip] UPDATE and Expires
> 
> 
> > I would think the caller will have an idea of how long 
> he/she wants to
> wait
> > for answer, and set the value of the Expires header 
> accordingly in the
> > INVITE request.  However, if the caller's UA doesn't 
> support this and it
> > crashes, then I believe it's an implementation issue for 
> the UAS.  Or when
> > the callee answers the call, current defined protocol 
> behavior (no ACK
> > received) will suffice here.
> >
> > Regards,
> > Bert
> >
> 
> on the contrary, why dont dont we support it from the callee 
> end like PSTN ?
> If the callee is not at his seat, then why to hold up the 
> resources until
> caller's "Expire" header?
> Think of the performance when there are millions of users 
> hitting this bend
> and blocking the resources for more than actually needed.
> If I know that I am not available then I can configure my UAC 
> somehow to
> inform the caller on the very first ring that
> I am not able to pick up the phone. I am just thinking it on 
> the lines of
> PSTN operation -- its not the caller who decides how long the 
> call should be
> presented
> but its the callee's phone which handles it. If the current bis doesnt
> support it then we might wanna bring in a minor extension to 
> handle this.
> 
> Does it sound ok ?
> 
> Prabhas
> 
> 
> 

_______________________________________________
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: "Mark J. Yusko" <[email-masked]>
Date: Fri, 10 May 2002 14:14:46 -0400

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, May 10, 2002 1:38 PM
> To: 'Prabhas Sinha'; Bert Culpepper; [email-masked]
> Subject: RE: [Sip] UPDATE and Expires
> 

I believe some class 4 switches (AT&T) have a 2 minute timeout for
ringing.  With 1 ring = 6 seconds, that's 20 rings.

> The problem with making assumptions on how long to
> time out is that it's the user, not the UAC, that
> knows how long is long enough.  
> Yes, you can use a timer on either end, but it needs
> to be on the order of minutes, not seconds, and it
> does not express the wishes of either the caller or > the callee.
It's the system designer (or 
> Note that in SIP, there are no messages passing
> while you are waiting.  Of course, I want there to
> be a few (UPDATE with Expire), just so that the
> called party knows the calling party still thinks it > ought to be
ringing.  Then the expiry can be on the > order of seconds.

---

From: "Prabhas Sinha" <[email-masked]>
Date: Fri, 10 May 2002 16:01:25 -0400

I am not sure if Tom's reply reached all, just sending it for your
information.

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: "Prabhas Sinha" <[email-masked]>
Sent: Friday, May 10, 2002 1:13 PM
Subject: Re: [Sip] UPDATE and Expires

>
> CPL provides the functionality that you recommend. Calls can be declined
with
> reasons given either to everyone or to specific individuals
>
>

----- Original Message -----
From: "Rosen, Brian" <[email-masked]>
To: "'Prabhas Sinha'" <[email-masked]>; "Bert Culpepper"
<[email-masked]>; <[email-masked]>
Sent: Friday, May 10, 2002 1:37 PM
Subject: RE: [Sip] UPDATE and Expires

---

From: "P. Vijay" <[email-masked]>
Date: Fri, 10 May 2002 15:06:47 -0500

I think the solution is either a policy decision implemented at the SIP
service provider level or a basic addition to the
INVITE/TRYING/RINGING/OK/ACK message flow.  I am for using INVITE expires
and letting the SP decide on (a) using its internal timer or expires,
whichever is lesser and (b) resetting the timer when it receives an UPDATE.
The call is cleared when the timer expires. This is based on reasons given
below.

	In the traditional telehpony world, answer timers (the time between start
of ringing and a valid answer) are (typically) set to avoid holding up
bandwidth for unbillable calls.  This is especially true for inband
signalling.  Even for out-of-band signaling, ISDN/ISUP, etc., the protocol
DEFINES timers between the state when the called party acknowledges (180)
the call (INVITE) and the state when a valid answer (200)is received.  If
the timer expires, then the call is cleared by the caller.  In reality, the
call is cleared by the switch that handles the caller's CPE (even that is a
gross simplification, but it will do).  In fact, the tandems with the lowest
configured answer timers clear the call and propagate the clearing in both
directions.  The important point here is that this behaviour is a
codification of what is seen as good policy (i.e, don't waste resources,
etc.), not necessarily essential for call control.

	In this case, the problem arose because the caller (UAC) died after sending
INVITE and UAS did not detect the client death.  Can that not be handled at
the trasport (tcp timers, heartbeats, etc.) and clear the call?

	In the case where the UAC is alive and keeps waiting for the 200, either
UAS or the called (UAS/UAC) could clear the call as described above.

	I have seen answer timers cause problems in regular telephony services, so
putting in mandatory timers (a-la ISDN or ISUP) would be a hindrance.
However, SP's need policies, preferably encoded in RFC's, that allow for
both call terminations on ring-no-answer and possibly extending the timer
(e.g. via UPDATE).

	SIP does not have to codify an answer timer, although it may be a good idea
to do provide some guidance.  Also, the timer can be exchanged in SDP,
except it would need to be sent in TRYING or RINGING. In the absence of a
timer, the matter of detecting a crashed device needs to addressed.

--Vijay--

> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Rosen,
> Brian
> Sent: Friday, May 10, 2002 12:38 PM

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 May 2002 14:34:49 -0400

Far as I can tell, the spec already specifies a fix to this problem. Its
timer C in the proxies. When an INVITE traverses a proxy, it sets timer
C to some value 3 minutes or greater, determined by the service
provider. Each time a provisional response is received, the timer is
reset. This allows a UAS to extend the timer. However, in the case
outlined by Brian, I assume that the UAS doesn't want to explicitly
extend the timer. Therefore, after 3 minutes, the timer will fire in a
proxy. According to section 16.8, unless the provider wishes to extend
the timer, the proxy will generate a CANCEL. This will cause the UAS to
cease ringing and generate a 487. That will also terminate the
transaction at the UAC, assuming its still alive. It will also clean up
state in any proxies along the path.

Thus, Brian's problem was due to a proxy which has not implemented timer
C as specified in bis.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com