[Sip-implementors] restarting timer c on failures
Jeroen van Bemmel
jbemmel at zonnet.nl
Wed Sep 7 04:28:53 EDT 2005
Additionally, I suppose the proxy implementation is free to treat the firing
of timer B (of which it gets informed by the transaction layer) as if a 408
response was received. For an outside observer this behavior would appear as
if the proxy used a value of 64*T1 for Timer C
If the proxy does not intend to add new targets to the set, and all
clienttransactions have terminated, I see no reason why the proxy should
----- Original Message -----
From: "Jeroen van Bemmel" <jbemmel at zonnet.nl>
To: "Taisto Qvist" <taisto.qvist at IP-Solutions.se>
Cc: <sip-implementors at cs.columbia.edu>
Sent: Wednesday, September 07, 2005 9:44 AM
Subject: Re: [Sip-implementors] restarting timer c on failures
> Hi Taisto,
>> "If the client transaction has not received a provisional response, "
>> "the proxy MUST behave as if the transaction received a 408 "
>> "(Request Timeout) response.""
>> Now if I restart timer C for every new txn, and the above rule is
>> talking about not receiving any provisionals, then the transaction
>> should timeout(timer B or F) long before timer C is ever reached!
> That is correct, timer B will have fired. This means the transaction is
> already terminated, but what's missing is a trigger for the proxy to
> select a final response for forwarding (step 6 of section 16.7). Therefore
> the text says that timer C firing should be treated as if receiving a 408,
> hence it triggers the proxy to decide on a final response. Timer B does
> not do that
>> So unless we change T1 so that T1*64 is larger than the minimum of
>> 3 minutes for Timer C, the above scenario should be impossible, since
>> timer C couldnt pop for a txn, since the txn has failed long before
>> not receiving any provisionals.
> In this case both timer B and timer C fire for the transaction
> Sip-implementors mailing list
> Sip-implementors at cs.columbia.edu
More information about the Sip-implementors