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

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 3 Aug 2001 14:17:31 -0400

> -----Original Message-----
> From: Connie Blanchard [mailto:[email-masked]]
> Sent: Thursday, August 02, 2001 5:12 PM
> To: [email-masked]
> Subject: [Sip] Response Code of 422 in Session-Timer draft
> 
> 
> 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?

Oops. The formal definition of it needs to be defined with the session timer
spec itself. It is sent when a proxy or UAS feels that the session timer
value in a request was too small. The -05 spec does describe the overall
semantics for it, but its scattered in the various sections.

I'll include a separate discussion in -06.

-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://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: Joerg Ott <[email-masked]>
Date: Mon, 06 Aug 2001 17:41:56 +0200

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?

Joerg

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 8 Aug 2001 08:19:33 -0400

> by having Min-SE: in there set to the value desired by P-B in the

Solution 1) Have P1 return a 503 with 
Retry-After of 1 second.  This is bad because 
the same proxies might not be in the path of 
the subsequent INVITE.  A might not submit 
the request with the same Call-ID.  A might 
not retry at all.

Solution 2) Define a new 5xx response which
means resubmit the request.  The response
would be basically mean the same as a 503;
however the resubmit should be immediate and
the proxies should record-route if they
wish to be part of the resubmit.  The resubmit
may use the same call-id with a higher cseq.
One problem is that this would require a bis
change.  Second problem is that the originator
would have to limit the resubmits to avoid
attacks and infinite resubmits.

Solution 3) Allow P1 to fork the same 
request to P2 but use a higher Session-Expires.  
This is bad because P2 potentially may not 
realize that it is a different request and 
assume that a forked request merged.  Thus the
same negative response might get returned.

Solution 3's problem is common for any 
merged forking situation where a proxy includes 
different headers or header values on the 
different branches.  This could be hopefully 
avoided by specifying in the bis that if a 
negative response was returned on a merged branch 
request, subsequent merged requests must still 
be checked to see if the same response applies.

I prefer solutions 3 if SIP intends to 
allow proxies to become smarter.

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