In your flow, 4th step seems to be incorrect. It is true that P2 remembers the Session-Expires that it has examined/modified in the request, but it will not insert session-expires in 2xx response because the request did not have "supported: timer" when it was processed by P2 (indicating that UAC does not support session timer). So it should simply forward the response upstream.
Following are excerpts from the RFC >> If the request contains a Supported header field with a value >> 'timer', the proxy MAY reject the INVITE request with a 422 (Session >> Interval Too Small) response if the session interval in the >> Session-Expires header field is smaller than the minimum interval >> defined by the proxy's local policy. When sending the 422 response, >> the proxy MUST include a Min-SE header field with the value of its >> minimum interval. That minimum MUST NOT be lower than 90 seconds. >> If the request doesn't indicate support for the session timer but >> contains a session interval that is too small, the proxy cannot >> usefully reject the request, as this would result in a call failure. This makes it clear that UAC's support for session timer is indicated by the presence of "supported: timer" rather than the presence of session-expires header itself. Regards Pandu On Wed, Nov 25, 2009 at 11:01 AM, Dushyant Dhalia <[email protected]> wrote: > All that I can agree to is "a proxy should not implement session expiration > procedures if neither of the UAC or UAS supports RFC 4028". > 1. But as elaborated in the below mentioned scenario, P1 assumes that UAS > would support RFC 4028 and it puts Session-Expiration header and Min-SE > header in initial INVITE (RFC 4028 sec 8.1). The possible benefit is - if > UAS supports RFC 4028 and wants to apply session expiration procedures, it > would know the values of Min-SE which P1 and P2 support. > 2. P2 receives INVITE with Min-SE and Session-Expires headers (and remembers > it). > 3. UAS doesn't support RFC 4028, therefore doesn't insert the session > expiration headers in 200 OK. > 4. P2 receives 200 OK without Session-Expires headers but remembers (in step > 2 above) as per sec 8.2 that it received INVITE request with Session-Expires > header, therefore inserts the session expires headers. So P2 thinks that UAC > supports RFC 4028 therefore it starts timer. > > In section 7.1 the RFC says - > > A UAC that supports the session timer extension defined here MUST > include a Supported header field in each request (except ACK), > listing the option tag 'timer' [2]. It MUST do so even if the UAC is > not requesting usage of the session timer for this session. > > But it never explicitly mentions that proxies have to make a decision on > this. > > Dushyant > > Pandurangan R S wrote: > > That essentially means neither UAC nor UAS supports RFC 4028 but P1 and P2 > run the session expiration timers as a result when the timer times out both > P1 and P2 release their calls/ resources. > > > This is not expected to occur as per RFC 4028. May be you should just > elaborate how you think situation occurs if RFC's guidelines are > followed. > > Regards > Pandu > > On Tue, Nov 24, 2009 at 5:24 PM, Dushyant Dhalia > <[email protected]> wrote: > > > ____ _ ______ _____ _____ > | UAC | ______ | P1 | _______ | P2 | _______ | UAS | > |_____| |______| |_____| |_____| > > Consider the above configuration - > > UAC doesn't insert Session-Expires header in Initial INVITE. > RFC 4028 section 8.1 says that "A proxy MAY insert a Session-Expires header > field in the request before forwarding it if none was present in the > request." > P1 inserts Session-Expires header. > P2 receives INVITE with Session-Expires header and forwards it to UAS. > UAS doesn't support Session-Expires so it doen't insert this header in the > response. > The response arrives at P2. Now RFC 4028 section 8.2 says " > > When the final response to the request arrives, it is examined by the > proxy. > > If the response does not contain a Session-Expires header field but > the proxy remembers that it requested a session timer in the request > (by inserting, modifying, or examining and accepting the > Session-Expires header field in the proxied request), this means that > the UAS did not support the session timer. If the proxy remembers > that the UAC did not support the session timer either, the proxy > forwards the response upstream normally. There is no session > expiration for this session. If, however, the proxy remembers that > the UAC did support the session timer, additional processing is > needed. > > Because there is no Session-Expires or Require header field in the > response, the proxy knows that it is the first session-timer-aware > proxy to receive the response. This proxy MUST insert a > Session-Expires header field into the response with the value it > remembered from the forwarded request. It MUST set the value of the > 'refresher' parameter to 'uac'. > > ". > That essentially means neither UAC nor UAS supports RFC 4028 but P1 and P2 > run the session expiration timers as a result when the timer times out both > P1 and P2 release their calls/ resources. In certain cases this could be > potential revenue loss scenario. > > Is it a bug or some gap in understanding? > > Dushyant P S Dhalia > Rancore Technologies, > Gurgaon, INDIA > > -- > "When work is a pleasure, life is a joy! When work is duty, life is > slavery." > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > -- > "When work is a pleasure, life is a joy! When work is duty, life is > slavery." > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
