Subject: [Sip] RFC4320 and 408 to non-INVITE

From: Jeroen Van Bemmel <[email-masked]>
Date: Thu, 27 Jul 2006 19:29:34 +0200

Robert,

RFC4320 bans 408 responses to NIT, but I think there are situations in which it is still useful and needed. In particular, consider when the UAC is using T1=2000 and the proxy uses T1=500 (eg because the client is on a slow wireless link)

The CT at the proxy times out after 64*T1=32 sec, while the client is still retransmitting. In this case, 408 does help

Regards,
Jeroen

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: Thu, 27 Jul 2006 12:51:28 -0500

This is not the way the timers are meant to be changed.

Both of the transaction-stateful things on either end of a given  
transaction must share the same
values for the transaction timers or the results are not defined.

What you describe is not unlike throwing away the timing belt in an  
engine and spinning
the head at some rate unrelated to the crankshaft. You might get  
lucky, but usually very bad things
are going to happen.

RjS

On Jul 27, 2006, at 12:29 PM, Jeroen Van Bemmel wrote:

> Robert,
>
> RFC4320 bans 408 responses to NIT, but I think there are situations  
> in which it is still useful and needed. In particular, consider  
> when the UAC is using T1=2000 and the proxy uses T1=500 (eg because  
> the client is on a slow wireless link)
>
> The CT at the proxy times out after 64*T1=32 sec, while the client  
> is still retransmitting. In this case, 408 does help
>
> Regards,
> Jeroen

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 27 Jul 2006 21:21:41 +0200

> the head at some rate unrelated to the crankshaft. You might get  lucky, 
> but usually very bad things
> are going to happen.

That's interesting, because it is exactly what is prescribed for IMS

Refer to TS 24.229 release 7 table 7.8 "SIP Timers" 
(http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-740.zip, page 
132 for me)

It says:
Value to be applied at the UE: T1 = 2s default
Value to be applied between IM CN subsystem elements: T1=500ms default

So you are saying that in IMS configured this way, very bad things will 
happen?

Regards,

jeroen

>> RFC4320 bans 408 responses to NIT, but I think there are situations  in 
>> which it is still useful and needed. In particular, consider  when the 
>> UAC is using T1=2000 and the proxy uses T1=500 (eg because  the client is 
>> on a slow wireless link)
>>
>> The CT at the proxy times out after 64*T1=32 sec, while the client  is 
>> still retransmitting. In this case, 408 does help
>>
>> Regards,
>> Jeroen
>

---

From: Robert Sparks <[email-masked]>
Date: Thu, 27 Jul 2006 14:48:31 -0500

So, specifically, that table says:
SIP Timer
Value to be applied between IM CN subsystem elements
Value to be applied at the UE
Value to be applied at the P-CSCF toward a UE
Meaning
T1
500ms default
2s default
2s default
RTT estimate

So the P-CSCF and the UE are both using 2s for T1.
When the P-CSCF talks to other things (that are not the UE), it uses  
500ms for T1.

What you were describing would be the P-CSCF using 500ms on its side  
of a transaction it was in with a
UA that was using 2s, which is not what this table says to do. In  
that case, yes, undefined things can happen.

RjS

On Jul 27, 2006, at 2:21 PM, Jeroen van Bemmel wrote:

>> What you describe is not unlike throwing away the timing belt in  
>> an engine and spinning
> Refer to TS 24.229 release 7 table 7.8 "SIP Timers" (http://www. 
> 3gpp.org/ftp/Specs/archive/24_series/24.229/24229-740.zip, page 132  
> for me)
>
> It says:
> So you are saying that in IMS configured this way, very bad things  
> will happen?
>
> Regards,
>
> jeroen
>
>>
>> RjS
>>
>>> RFC4320 bans 408 responses to NIT, but I think there are  
>>> situations  in which it is still useful and needed. In  
>>> particular, consider  when the UAC is using T1=2000 and the proxy  
>>> uses T1=500 (eg because  the client is on a slow wireless link)
>>>
>>> The CT at the proxy times out after 64*T1=32 sec, while the  
>>> client  is still retransmitting. In this case, 408 does help
>>>
>>> Regards,
>>> Jeroen
>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 27 Jul 2006 21:54:56 +0200

inline
  ----- Original Message ----- 
  From: Robert Sparks 
  To: Jeroen van Bemmel 
  Cc: [email-masked] 
  Sent: Thursday, July 27, 2006 9:48 PM
  Subject: Re: RFC4320 and 408 to non-INVITE

  So, specifically, that table says:
        SIP Timer  Value to be applied between IM CN subsystem elements  Value to be applied at the UE Value to be applied at the P-CSCF toward a UE Meaning 
        T1 500ms default 2s default 2s default RTT estimate 

  So the P-CSCF and the UE are both using 2s for T1.
  When the P-CSCF talks to other things (that are not the UE), it uses 500ms for T1.

  What you were describing would be the P-CSCF using 500ms on its side of a transaction it was in with a
  UA that was using 2s, which is not what this table says to do. In that case, yes, undefined things can happen.

Then perhaps I was not clear enough. What I meant was the UA using T1=2000 towards the P-CSCF, and the P-CSCF using T1=500 towards the S-CSCF. If the latter transaction times out (after 64*500=32 seconds), it seems to me that the P-CSCF should send a 408 response towards the UA. If not, it will keep retransmitting until 64*2000 = 128 seconds (all assuming UDP of course)

Regards,

Jeroen

  RjS

      Both of the transaction-stateful things on either end of a given transaction must share the same
      values for the transaction timers or the results are not defined.

      What you describe is not unlike throwing away the timing belt in an engine and spinning
      the head at some rate unrelated to the crankshaft. You might get  lucky, but usually very bad things
      are going to happen.

    Refer to TS 24.229 release 7 table 7.8 "SIP Timers" (http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-740.zip, page 132 for me)

    It says:

    So you are saying that in IMS configured this way, very bad things will happen?

    Regards,

    jeroen

      RjS

        Robert,

        Regards,
        Jeroen

---

From: Robert Sparks <[email-masked]>
Date: Thu, 27 Jul 2006 15:42:46 -0500

Yeah - I definitely needed that clarification for the problem you are  
describing.

What you are describing now is a special case of something that is  
not timer
specific. The general case is that of a proxy where all possible  
downstream
legs have failed before the original request times out, but none of  
those legs
provided a SIP response that was suitable for forwarding as the  
"best" response.

For instance, each of the downstream legs could have produced an ICMP  
error
immediately.

The response to send in this situation is 480.

RjS

On Jul 27, 2006, at 2:54 PM, Jeroen van Bemmel wrote:

> Then perhaps I was not clear enough. What I meant was the UA using  
> T1=2000 towards the P-CSCF, and the P-CSCF using T1=500 towards the  
> S-CSCF. If the latter transaction times out (after 64*500=32  
> seconds), it seems to me that the P-CSCF should send a 408 response  
> towards the UA. If not, it will keep retransmitting until 64*2000 =  
> 128 seconds (all assuming UDP of course)
>
> Regards,
>
> Jeroen
>
>
> RjS
>
>> 3gpp.org/ftp/Specs/archive/24_series/24.229/24229-740.zip, page  
>> 132 for me)
>>
>> It says:
>>>> particular, consider  when the UAC is using T1=2000 and the  
>>>> proxy uses T1=500 (eg because  the client is on a slow wireless  
>>>> link)
>>>>