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."
|
<<attachment: dushyant_dhalia.vcf>>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
