Attila - I agree with you, except for one point below.
Paul
Attila Sipos 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).
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.
"should" isn't the right word to use here. The application has no choice in this as session timers are defined. Each reinvite either refreshes the timer, or else it cancels the timeer. There is no option for a reinvite the leaves the timer as it was.
Paul
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
