Christina Zhao wrote:
Hi, I have another question regarding Session Timer:
If the refresher is uac, how can the uas determine the re-INVITE is for the purpose of session refresh? (assuming uas needs to tell the difference between a Session Refresh re-INVITE and other purpose re-INVITEs so that it can pursue different process. )
There could be re-INVITEs that are Target Refresh Request (RFC3261 12.2), and re-INVITEs that change SDP.
The refreshee *can't* tell if the reinvite is for the purpose of session refresh. The question is meaningless.
In fact, *every* reinvite (or update) acts either to refresh the session timer, or to cancel it. It doesn't matter to the UAS whether the UAC initiated it to conform to the rules of session timers or for some other reason.
Conversely, a refresher sending a reinvite solely for the purpose of session timer refresh has no guarantee that the refreshee will treat it that way. The refreshee is free to revise its answer.
My idea is to determine by checking if the header part contains "Supported: timer", but I am not sure this condition is good enough.
There is some question (at least to me) about whether Supported (and Required) options need to be repeated in every message within a dialog, or if they become part of dialog state. I think they probably should be repeated.
If the "Supported: timer" is *not* present in a reinvite but was present in the original invite, then the recipient should either assume it is still supported, or else that it is no longer supported. Neither assumption would serve your purpose. Either way the absence of a Session-Expires would mean to cancel the timer. And the presence of a Session-Expires header would either mean to refresh, or would be an error.
Paul
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
