Paul, One inline... Paul Kyzivat <[EMAIL PROTECTED]> wrote:
Nils Ohlmeier wrote: > Counter question: why should a re-INVITE do not update the session timer? > E.g. your receive a re-INVITE with a change SDP 2 seconds before the Session > expires. Now you do not update the session but terminate the session 2 > seconds later!? > Is their some higher goal which you are trying to reach by not updating the > Session Timer, which I currently do not see? See my comments elsewhere in this thread. Its been awhile, but I spent a lot of time understanding this seeming simple but deceptively complex draft and helping clarify it. I think it probably should have been rewritten to avoid giving the wrong impression (which obviously it does give) that reinvites used for session timer refresh are distinct from those used for other purposes. A reinvite two seconds before the session expires *will* act as a refresh. If you want, when sending that, you may be able to adjust the expiration time so that it will still expire at the previously expected time, but that would be a really stupid thing to do. Presumably each reinvite, regardless of why it is sent, will reset the expiration time to a suitable time in the future. Manish : Agreed this does seem a good thing to do, but it just might not work for certain applications. For example on media gateway an admin wants to limit every call to 3 mins until and unless some event occurs ( for ex : app like coin pay phones ). So one would want only an invite after three mins ( which actually is triggered by an event ) acts as a refresh invite. If just any invite could refresh the session, user may just put call on hold just before three mins and in turn get an extra time. This is just an example which hit me and might not really be acute. Similar can be other applications where identification of refresher invite may help. Also with an identification, refresh can be made real light weight. For ex no SDP processing etc for those reinvites. Some times with lot of call features, for example tranfer( if you like to see my earlier mail on this forum) it might really not be possible to identify/mark ORIGIN field in SDP as earlier. A session/SIP level identification might really help. My two cents, Manish Paul > Regards > Nils > > On Tuesday 26 October 2004 00:00, 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. >> >>My idea is to determine by checking if the header part contains >>"Supported: timer", but I am not sure this condition is good enough. >> >>I will appreciate very much for any convincing opinion. >> >>Christina >>_______________________________________________ >>Sip-implementors mailing list >>[EMAIL PROTECTED] >>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors --------------------------------- Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
