Annotation property "sessionTimeout" not working?

[Noodle]

Hi All,

I'm trying to extend application session timeout to 1 hour (3 minutes
is too short), so I add "sessionTimeout = 3600" into @SipApplication
annotation. But it not working. I double checked, @SipApplication
itself is working, I defined application name, main servlet, they all
fine. But sessionTimeout still default 3 minutes. So I checked code
and found that in "ClassFileScanner" it using session timeout from
annotation to set to
sipContext.setSesstionTimeout(appData.sessionTimeout()). However,
SipContext defined another api "setSipApplicationSessionTimeout" and
SipStandardContext didn't override "setSessionTimeout", and in
SipApplicationSessionImpl it getting application session timeout, not
session timeout. That looks like not using sessionTimeout from
@SipApplication at all to me.

Bug?

Thanks

Noodle

[Noodle]

BTW, I think use timeout only isn't so good. Is that possible to set a
timer in appSession to issue some kind of dummy request to another end
to keep session alive? If so, which request should be a good
candidate?

If we use timeout only, once application session timed out, it will
never forward future request/response, and log will not work too.

Thanks

Noodle

[Vladimir Ralev]

Yep, that looks like a bug. 

No need for keepalive just for that. You can use the method setExipires() periodically or onAppSessionExpired callback.

http://download.oracle.com/docs/cd/E13153_01/wlcp/wlss40/javadoc/jsr289/javax/servlet/sip/SipApplicationSession.html

[Vladimir Ralev]

Can you open an issue for this bug? http://code.google.com/p/mobicents/issues/entry

[Noodle]

Here it is:

http://code.google.com/p/mobicents/issues/detail?id=2054&colspec=ID%20Priority%20Component%20Milestone%20MSPS%20SLEE%20SubComponent%20Version%20Release%20Type%20Status%20Owner%20Summary&start=300

On Nov 2, 8:06 am, Vladimir Ralev <vladimir.ra...@gmail.com> wrote:
> Can you open an issue for this bug?http://code.google.com/p/mobicents/issues/entry

>
> On Tue, Nov 2, 2010 at 5:03 PM, Vladimir Ralev <vladimir.ra...@gmail.com>wrote:
>
>
>
> > Yep, that looks like a bug.
>
> > No need for keepalive just for that. You can use the method setExipires()
> > periodically or onAppSessionExpired callback.
>

> >http://download.oracle.com/docs/cd/E13153_01/wlcp/wlss40/javadoc/jsr2...

[Noodle]

Not sure what you mean. I want to check if session still alive, not
set expires to very big number. onAppSessionExpired callback means app
session already expired, right? What I want is: check if each sip
session still alive, if so, don't expire app session, if sip session
gone, set expire on app session. Use a fixed expires on all app
sessions may not a good idea.

On Nov 2, 8:03 am, Vladimir Ralev <vladimir.ra...@gmail.com> wrote:
> Yep, that looks like a bug.
>
> No need for keepalive just for that. You can use the method setExipires()
> periodically or onAppSessionExpired callback.
>

> http://download.oracle.com/docs/cd/E13153_01/wlcp/wlss40/javadoc/jsr2...

[Jean Deruelle]

no SipApplicationSessionListener.sessionExpired callback, you can call setExpires to extend the lifetime of the SipApplicationSession

See JSR 289, section 6.1.2 SipApplicationSession Lifetime:

"In the sessionExpired() callback method, the application may request an extension of the application session lifetime by invoking setExpires() on the timed out SipApplicationSession giving as an argument the number of minutes until the session expires again"

Jean

[Noodle]

Thanks for advice. But this looks like not what I'm looking for. When
application session expired reach, even I'm still on the phone, Sip
Session state is terminated? I thought Sip Session state terminated
only after BYE or CANCEL? really don't understand. :(

[Jean Deruelle]

No, SipSession and SipApplicationSession are different.

a SipSession correspond do a SIP Dialog or a call basically.

a SipApplicationSession is a meta session that can hold multiple sip sessions and http session as well.

You can read the Sip Servlets 1.1 spec, sessions lifecycle are explained pretty well there.

Jean

[Noodle]

I understand that no problem. And I'm doing exactly what you suggested
in another topic (How to handle application session expired), But as I
said, I have Application Session Listener, and when sessionExpired
been called, I go though all Sip Sessions within this application
session and check if state is NOT TERMINATED to extend application
session. The problem is: they are all terminated even I'm still on the
phone. (no BYE, CANCEL at all)

Anyway, instead of checking state (which is not so reliable to me, or
I didn't understand sip session life cycle correctly), I check
isReadyToInvalidate() like Sip Servlets 1.1 spec recommended in
6-2-4-1. That works fine in most cases as long as I invalid Sip
Session correctly (For example: for Register, OPTIONS request. for
INVITE request, it looks like system handling that). Only one issue
now: Sometime when I get Cancel from one leg, and try to forward to
another leg, "final response already sent" exception which cause
SipSession not invalidate correctly and cause application session
leak. I'm sure I'm not getting/sending any final response on that leg
yet. I'm trying to get a very detail log and may open another topic on
that issue later.

Thanks for your advice.

Noodle

[Jean Deruelle]

See inline

On Thu, Nov 4, 2010 at 5:34 PM, Noodle <wei....@gmail.com> wrote:

I understand that no problem. And I'm doing exactly what you suggested
in another topic (How to handle application session expired), But as I
said, I have Application Session Listener, and when sessionExpired
been called, I go though all Sip Sessions within this application
session and check if state is NOT TERMINATED to extend application
session. The problem is: they are all terminated even I'm still on the
phone. (no BYE, CANCEL at all)

that would seem like a bug then. If you can attach a simple application reproducing the problem, or the logs in DEBUG log and point us to the sipapplicationsession id showcasing the problem we could try to see if it's a bug.

 

Anyway, instead of checking state (which is not so reliable to me, or
I didn't understand sip session life cycle correctly), I check
isReadyToInvalidate() like Sip Servlets 1.1 spec recommended in
6-2-4-1. That works fine in most cases as long as I invalid Sip
Session correctly (For example: for Register, OPTIONS request. for
INVITE request, it looks like system handling that). Only one issue
now: Sometime when I get Cancel from one leg, and try to forward to
another leg, "final response already sent" exception which cause
SipSession not invalidate correctly and cause application session
leak. I'm sure I'm not getting/sending any final response on that leg
yet. I'm trying to get a very detail log and may open another topic on
that issue later.

Please note that the container handles CANCEL request and send the final response to it and to the INVITE by itself so if you try to forward the 487 Terminated from the INVITE you cancelled, you will get that exception. Logs in DEBUG mode will tell

[Soto Man]

Hi,

Has this problem with sessionTimeout been fixed?  I am using the conference-demo-jsr309 example and I notice that timeout occurs every time 5 minutes into the conference even after setting a large sessionTimeout = 10000.  I found issue 2054 indicating that it was fixed back in Nov 2010.  Wondering if this problem is still around in MSS v2.0.0.FINAL?

Regards,

[Jean Deruelle]

Can you create a new issue at http://code.google.com/p/sipservlets/issues/entry with your app or sample app reproducing the issue and the logs at DEBUG Level from th server ?

Thanks

Jean