Subject: RE: [Sip] 482 handling by proxies

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 31 Oct 2001 02:47:10 -0800

> >>Yes. I was just worried about cases where it actually may take a
> >>relatively long time before the 200 final response is sent, 
> due to other
> >>call setup actions (PRACK, INFO etc), because I guess the 
> proxy won't
> >>wait "forever" for the final response until it takes some 
> actions (of
> >>course, in a real-life situation the call setup probably 
> won't be that
> >>long) for the pending legs.
> >>
> > 
> >The proxy has ACKed already the 482 response. The only thing 
> it does is
> >to store it in a buffer as one of the non-2xx final 
> responses received
> >so far. This way it will be able to choose the "best" one to 
> send back.
> > 
> >I do not know why you are raising this now, because this has been
> >standard SIP behavior since the beginning.
> 
> I just wanted to clarify the specific case where it takes a long time
> before the final response is received for a specific leg, because the
> use of call pre-setup transactions etc has NOT been standard SIP
> behavious since the beginning...
> 

Christer,

There are two alternatives: 

When a proxy forks a request it slaps on a proxy-selected "No-Answer
Timeout" on INVITE requests, that is, a proxy will wait around for a certain
time for final responses from all branches and otherwise it will just return
the best non-2xx response received and CANCEL out other branches.
Imposing local timers that affect answer timeouts is a bad thing !! 

The other alternative is that the proxy "never" times outs and will only
send a final response when _all_ branches have responded with a non-2xx
response (assuming that a 1xx has been received from each branch) OR one
branch has returned a 2xx response OR the caller CANCEL's. 

It is obvious that proxies must protect themselves from stale state and so
the obvious conclusion from this is that a timeout should be used but the
timeout should not affect the normal "Answer Timeout" of a call. The draft
should recommend an appropriate minimum value - probably on the order of a
few hours or even more (it should be remembered that this is a timeout on
the proxy and not the UA devices). 

Very long "ring" times can have their uses.

Robert.

_______________________________________________
Sip mailing list  http://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: Christer Holmberg <[email-masked]>
Date: Wed, 31 Oct 2001 13:20:34 +0200

Hi Robert,

>Imposing local timers that affect answer timeouts is a bad thing !!

Agree.
 
>Very long "ring" times can have their uses.

Yes.

This is affects the C timer (the time a client waits for a final
response after it has received a provisional response). If an INVITE is
sent, and a provisional response is received, the C timer should also be
long enough so that the client will remain in the "proceeding state" (as
defined on page 94) long enough for all the other pre call setup
transactions to take place.

A couple of questions related to the C timer:

1. Is if for the whole call setup, or per early leg? Ie, the UAC may
receive provisional responses from two separate UAS, but at some state
the C timer expires for one leg. Does the UAC then terminate that
specific leg?

2. Is the C timer set to zero every time a new provisional response is
received? IF so, again, is it set to zero for the whole call setup, or
only for that specific early leg?

Regards,

Christer Holmberg
Ericsson Finland