Hi Amar,
In that normal scenario (A calls B), as soon as Timer C fires in a proxy,
a CANCEL is generated toward B and a 487 Request Terminated
toward A as response to the original INVITE request. So there is no need
for a separate notification.
On the other hand, if we moved Timer C out of a proxy,
we might end up with the following situation: A calls B, a stateful proxy
forwards
the INVITE, B sends back a provisional and then both A and B crash or
are disconnected. The proxy would have no way to clear the transaction
because it is stuck in Proceeding State. It's then really up to the UAS to take
care of any involved Timer C in the same way it's up to the UAC to get out
of the Proceeding State.
Ettore Benedetti
THALES COMMUNICATIONS B.V.
Bestevaer 46, 1271 ZA Huizen
The Netherlands
Unclassified
>>> <[EMAIL PROTECTED]> 12/1/05 5:50:37 AM >>>
inline
Rgds,
Amar
Mobile: +919886395894
The greatest enemy of best is "good." If you're willing to accept "good"
you'll never be the "Best."
"Vijay K.
Gurbani"
<[EMAIL PROTECTED]> To
[EMAIL PROTECTED]
12/01/2005 01:12 .com
AM cc
Ettore Benedetti
<[EMAIL PROTECTED]
m>
Subject
Re: [Sip-implementors] wait time
for 200 ok
[EMAIL PROTECTED] wrote:
> Hi,
>
> I will not be right to generate CANCEL to drop the call as timer C
> fires, because proxy cannot know the user's intension.
Actually, it is perfectly okay for the proxy to generate a CANCEL
when Timer C fires (see Section 16.8 of rfc3261). Timer C is
updated dynamically if the UAS decides that it wants to keep the
session up (for instance, if the caller is being queued).
Amar>> That's fine with me, But timer C will be updated only upon
triggerd by an event. These event are based on either from the
caller or callee side. In case of Call Q, Call Waiting, Call Forward
busy, Call forward No answer, etc (all are Callee based), its MUST to
update Timer C.
But in cases when we don't have services like this, what will trigger
Proxy to update TimerC. for example normal A to B scenario, A calls B &
B's Phone is ringing. Where A may to continue event after Timer C fires.
A SIP/non-SIP based event may be generated for this. This will increase
the processing overhead.
If we move the Timer C out of this context we don't have to set/reset
Timer C while forwarding the request out or upon receiving provisional
responses.
Infact if we move this timer to the scope of User Agent side. Then
probably it will solve our problem of hanging in proceeding state.
- vijay
--
Vijay K. Gurbani, Ph.D. [EMAIL PROTECTED],research.bell-labs.com,acm.org}
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566 Voice: +1 630 224 0216
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
