ira kadin wrote:
Hi All,
I have a question regarding supporting the session timer (draft from July 18, 2004).From one side it's written that
"A UAC that supports the session timer extension defined here MUST include a Supported header field in each request (except ACK)"
From other side on page 18 there is a table, indicating the UAS behavior
UAC supports? refresher parameter refresher parameter in request in response ------------------------------------------------------- N none uas N uac NA N uas NA Y none uas or uac Y uac uac Y uas uas
From line N1 we can see that if "timer" supported header doesn't exist in INVITE, the UASmay include it in 200 response.
And visa versa. It is
possible that the UAC requested session timer (and thus included a
Session-Expires header field in the request), but there was no
Require or Session-Expires header field in the 2xx response. This
will happen when the UAS doesn't support the session timer extension,
and only the UAC has asked for a session timer (no proxies have
requested it). In this case, if the UAC still wishes to use the
session timer (they are purely for its benefit alone), it has to
perform them.
Does it mean, that UAS or UAC has to send UPDATE/RE-INVITE to the non-supported timer side and "cut" the session if 200 reply is not received (why should it be received if other side doesn't support it) ?
Fundamentally, the Session Timer feature is of benefit to servers on the route between the UAC and UAS. (The UAC and UAS can initiate the equivalent signaling anytime they want, so they don't need it.)
The rules for carrying on when only one of UAC or UAS support is again for the benefit of those other servers. One end supporting is enough to achieve that.
In the case you describe, the lack of Session-Expires in the response means (I think, without going back to read all the details) means that there is no server in the middle that desires the session timer. In this case there would be no real reason for the UAC to do it anyway, except for its own interest. I can see no reason to re-signal that isn't going to carry on - nobody is there who understands or cares.
Paul _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
