>I think, that each re-INVITE should contain the SIP session timer >parameters and, as Paul said, each of these re-INVITE's is a "session >refresh". If you don't do this, you'll end up sending more re-INVITE's >than is necessary
Antilla, I agree totally on this. I am just talking about reinvites which are just intended for session refresh. I just mentioned that an identifier for this refresh invites will make the processing light weight. It will be independent of session descriptor type. For ex for SDP one might use 'o' field to reduce media descr processing. But as Paul mentioned, the draft is not going to change on this, may be we have to live with the little extra processing and handle inherent complexities in other ways. One comment inline... Attila Sipos <[EMAIL PROTECTED]> wrote: Hello, > > 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. I'm a little concerned about the above idea for usage of the session timer. The SIP session timer, I think, is designed for checking that sessions are still active. So isn't trying to use it for something else unadvised? I mean, if you're using the presence of a re-INVITE to indicate that someone has put in some more money into the phone then you are overloading the INVITE to make it show something that it wasn't designed to show. For some "coin pay phone" application, wouldn't it be preferable to send the coin insertion events using either some kind of INFO message or some kind of NOTIFY (or maybe even some kind of RFC2833). Manish: BTW, I dint mean using reinvite for event notification. That could be done through any internal means. Refresh invite will be just used to revive the session when that event is detected. As mentioned, I agree this may not be the perfect example. Moreover, as I interpret, an important purpose of session timer along with checking if session is active, is also to 'bring down' the session just based on time expiry. These are two different things and in example above, latter is precisely what i intended. Regards, Manish I know that the above coin pay phone scenario was only being used as an example to make a point but I don't think it's realistic to use SIP session timers in this way. I think, that each re-INVITE should contain the SIP session timer parameters and, as Paul said, each of these re-INVITE's is a "session refresh". If you don't do this, you'll end up sending more re-INVITE's than is necessary. Regards, Attila Attila Sipos Software Engineer www.vegastream.com > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Paul > Kyzivat > Sent: 26 October 2004 19:48 > To: Manish > Cc: [EMAIL PROTECTED] > Subject: Re: [Sip-implementors] How to determine a Session Refresh > Request(re-INVITE)? > > > > > Manish wrote: > > */Paul Kyzivat /* 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 > --------------------------------- Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
