Subject: [Sip] Response Code of 422 in Session-Timer draft

From: "Connie Blanchard" <[email-masked]>
Date: Thu, 2 Aug 2001 17:12:10 -0400

Section 4 of the Session-Timer draft makes reference to a Response code of
422. I cannot find in any of the documents listed in the bibliography of
that response code. Is this a mis-print or am I missing a document?

_______________________________________________
Sip mailing list  http://www.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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Aug 2001 16:19:47 -0400

Comments below.

> -----Original Message-----
> From: Joerg Ott [mailto:[email-masked]]
> Sent: Monday, August 06, 2001 11:42 AM
> To: Jonathan Rosenberg
> Cc: 'Connie Blanchard'; [email-masked]
> Subject: Re: [Sip] Response Code of 422 in Session-Timer draft
> 
> 
> Since we did not get to Session Timer today...
> 
> There could be another issue with a 422 response (which may or may not
> be intended or accepted as such).
> 
> You run into an interesting failure scenario if you have e.g. two
> timer-aware proxies and a timer-unaware UAC as follows:
> 
>      UAC ----- P-A ----- P-B ------ UAS
> 
> Now consider P-A with a preferred session timeout of 10 minutes
> (which it always inserts) and P-B with a preferred session timeout
> of 15 minutes (which it always wants to insist on).
> 
> 1.  UAC sends a simple INVITE w/o any session timer.
> 2.  P-A inserts Session-Expires: 600
> 3.  P-B detects that this value is too small and generates a
> 
>     422 Session Timer too small
>     Session-Expires: 900
> 
> 4.  P-A forwards this up the UAC
> 
>     The INVITE transaction has completed so P-A clears all state
>     (there was no call established).
> 
> 5.  The UAC receives 422 Response but does not understand it.
>     Hence, the 422 defaults to 400 class response; no retry with
>     different timer value is done.
> 
>     -> The UAS was not reached because of a client error which simply
>        was not caused by the client.  In particular, the UAC has no
>        idea what to do differently.
> 
> Interestingly enough, in the other direction, calls go through just
> fine (assuming a UAS that supports timer).  A UAC supporting timer can
> also initiate calls just fine.
> 
> A similar scenarion may arise if you have P-A always reducing the
> Session-Expires: header below what P-B expects (even if the UAC
> understands and uses Session-Expires:).  But this one is solved
> by having Min-SE: in there set to the value desired by P-B in the
> UAC.
> 
> Am I missing something?

No, you are correct that this is a problem. I wish I had seen this email
earlier. I discovered this problem as well yesterday when updating the
session timer draft. I forwarded a note to the list with a proposed
solution, which was basically to have the proxy insert a Min-SE header in
this case, instead of rejecting it, and then proxying it on. The UAS chooses
the session timer to be the MAX(Min-SE, Session-Expires) and returns that in
the Session-Expires header in the response. 

I welcome your comments on this mechanism.

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

Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip