Manish wrote:
*/Paul Kyzivat <[EMAIL PROTECTED]>/* wrote:
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.
The session timer only ensures that something happens periodically. And it is really only important to proxies that have record-routed. For them it is a "guarantee" that something will come their way, even though they aren't permitted to originate signaling on their own.
For UAs, including B2BUAs, there is no need for session timer. They can send a reinvite any time they decide it might be a good idea to check the other end.
So, the gateway (presumably a UA) can do what it wants after 3 minutes.
I said earlier that the refresher *could* sometimes reduce the duration of the session timer, so that it would come due at the same time it previously had been scheduled to do so. But this isn't always possible. For instance:
Suppose the initial invite completed at time T1, with a Session-Expires of 180 seconds, and a Min-SE value of 60 seconds.
Then, at time T2= T1+90, a reinvite is performed. This time the Session-Expires is set to 90, and the Min-SE remains 60.
Then, at time T3= T2+45, another reinvite is performed. The desire might be to set Session-Expires to 45, so that the expiration time remains at T1+180. But because the Min-SE is 60, the Session-Expires must not be set any lower than 60.
Also with an identification, refresh can be made real light weight.
Maybe, but it isn't specified that way. The origins of this draft are ancient, and it still hasn't quite made it to RFC. You can be certain that it isn't going to be changed so you can take a couple of instructions out of your code.
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.
I think most people now acknowledge that Session Timer is largely useless. It is only important to proxies, and they can't really count on it either. If they depend on it, then they can be broken by malevolant UAs that refuse to carry out the negotiated refreshes.
If you think you have a *need* for this then you probably ought to rethink it.
Paul
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
