issue with SIP Servlet 0.5
Michael Yuan
I just upgraded to mobicents 1.2.0 CR1 w/ Sip Servlet 0.5 and my app
stopped working ... It was working in Sip Servlet 0.4.1.
What happens is that mobicents invalidates my Sip Session when it
receives the 200/OK message back. The flow is like this:
1. I send out an INVITE and gets several 183 responses until the user
picks up the phone. The 183 responses are routed correctly.
18:45:05,791 INFO [ResponseDispatcher] route response on following
session (sip:5731...@sip.future-nine.com,
3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com
,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
18:45:05,792 INFO [MessageDispatcher] Dispatching response SIP/2.0
183 Session Progress
2. Then, the 200/OK comes and the server suddenly decides the
invalidate the application session. My SipServlet methods are not
executed here.
18:45:09,082 INFO [SipApplicationDispatcherImpl] Dialog Terminated => f898bc4e6851f6c9...@10.251.210.195
18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session (sip:5731...@sip.future-nine.com
,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com
,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session (sip:5731...@sip.future-nine.com
,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com
,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
18:45:09,082 INFO [SipApplicationSessionImpl] Invalidating the
following sip application session (f898bc4e6851f6c9...@10.251.210.195
,RingfulSip)
18:45:22,163 INFO [SIP-Servlet-Tomcat-Server] <message
from="64.251.23.244:5060"
to="10.251.210.195:5080"
time="1219362322163"
isSender="false"
transactionId="z9hg4bk76481606673f62da64458f6ed809ebb7"
callId="f898bc4e6851f6c9...@10.251.210.195"
firstLine="SIP/2.0 200 OK"
... ...
3. The remote server keeps sending 200/OK since it did not get ACK,
and mobicents just drops them due to lack of active session.
18:45:22,168 ERROR [ResponseDispatcher] Dropping the response since no
active sip session has been found for it : SIP/2.0 200 OK
Any ideas what I did wrong? Thanks a lot!
cheers
Michael
Vladimir Ralev
Folks,
I just upgraded to mobicents 1.2.0 CR1 w/ Sip Servlet 0.5 and my app stopped working ... It was working in Sip Servlet 0.4.1.
What happens is that mobicents invalidates my Sip Session when it receives the 200/OK message back. The flow is like this:
1. I send out an INVITE and gets several 183 responses until the user picks up the phone. The 183 responses are routed correctly.
18:45:05,791 INFO [ResponseDispatcher] route response on following session (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
18:45:05,792 INFO [MessageDispatcher] Dispatching response SIP/2.0 183 Session Progress
2. Then, the 200/OK comes and the server suddenly decides the invalidate the application session. My SipServlet methods are not executed here.
18:45:09,082 INFO [SipApplicationDispatcherImpl] Dialog Terminated => f898bc4e6851f6c9...@10.251.210.195
18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
Michael Yuan
The 183 and 200 responses are right next to each other ... I notice
that there is a "Dialog Terminated" message right before the
invalidation. That message is also present in 0.4.1. Could that be the
cause? Thanks.
cheers
Michael
Vladimir Ralev
The 183 and 200 responses are right next to each other ... I notice that there is a "Dialog Terminated" message right before the invalidation. That message is also present in 0.4.1. Could that be the cause? Thanks.
cheers
Michael
On Aug 21, 2008, at 10:51 PM, Vladimir Ralev wrote:
Are you sure there hasn't been a negative response other than the subsequient 200 OK? May be a full log would show the cause. The new session invalidation in 0.5 tries to remove unused sessions asap, but i dont see how it can invalidate an active session like this. As a workaround you should be able to override this behaviour by doing setInvalidateWhenReady(false) on your sip and app sessions (this mode is similar to the behaviour in 0.4)
On Fri, Aug 22, 2008 at 3:14 AM, Michael Yuan <mic...@michaelyuan.com> wrote:
Folks,
I just upgraded to mobicents 1.2.0 CR1 w/ Sip Servlet 0.5 and my app stopped working ... It was working in Sip Servlet 0.4.1.
What happens is that mobicents invalidates my Sip Session when it receives the 200/OK message back. The flow is like this:
1. I send out an INVITE and gets several 183 responses until the user picks up the phone. The 183 responses are routed correctly.
18:45:05,791 INFO [ResponseDispatcher] route response on following session (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
18:45:05,792 INFO [MessageDispatcher] Dispatching response SIP/2.0 183 Session Progress
2. Then, the 200/OK comes and the server suddenly decides the invalidate the application session. My SipServlet methods are not executed here.
18:45:09,082 INFO [SipApplicationDispatcherImpl] Dialog Terminated => f898bc4e6851f6c9...@10.251.210.195
18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
Michael Yuan
I attached the log here. As you can see the Sip response right before
the invalidation is simply a 183 response. Without attaching a very
lengthy log, the flow is like this:
1. INVITE
2. 407 Proxy Authentication Required
3. 100 Trying
4. 183 Session in Progress
5. session invalidation
6. 200 OK
Is the 407 an issue here? thanks
cheers
Michael
18:45:05,786 INFO [SIP-Servlet-Tomcat-Server] <message
from="64.251.23.244:5060"
to="10.251.210.195:5080"
time="1219362305786"
isSender="false"
transactionId="z9hg4bk76481606673f62da64458f6ed809ebb7"
callId="f898bc4e6851f6c9...@10.251.210.195"
firstLine="SIP/2.0 183 Session Progress"
>
<![CDATA[SIP/2.0 183 Session Progress^M
Via: SIP/2.0/UDP
10.251.210.195
:
5080
;received
=
75.101.145.243
;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
From: <sip:5731...@sip.future-
nine
.com>;tag=3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7^M
To: <sip:15123...@sip.future-nine.com>;tag=as503e3bd2^M
Call-ID: f898bc4e6851f6c9...@10.251.210.195^M
CSeq: 2 INVITE^M
User-Agent: Asterisk PBX^M
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY^M
Supported: replaces^M
Contact: <sip:15123...@64.251.23.244>^M
Content-Type: application/sdp^M
Content-Length: 318^M
^M
v=0^M
o=root 2850 2850 IN IP4 64.251.23.244^M
s=session^M
c=IN IP4 64.251.23.244^M
t=0 0^M
m=audio 10806 RTP/AVP 0 18 111 101^M
a=rtpmap:0 PCMU/8000^M
a=rtpmap:18 G729/8000^M
a=fmtp:18 annexb=no^M
a=rtpmap:111 G726-32/8000^M
a=rtpmap:101 telephone-event/8000^M
a=fmtp:101 0-16^M
a=silenceSupp:off - - - -^M
a=ptime:20^M
a=sendrecv^M
]]>
</message>
18:45:05,791 INFO [SipApplicationDispatcherImpl] Response SIP/2.0 183
Session Progress^M
Via: SIP/2.0/UDP
10.251.210.195
:
5080
;received
=
75.101.145.243
;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
From: <sip:5731...@sip.future-
nine
.com>;tag=3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7^M
To: <sip:15123...@sip.future-nine.com>;tag=as503e3bd2^M
Call-ID: f898bc4e6851f6c9...@10.251.210.195^M
CSeq: 2 INVITE^M
User-Agent: Asterisk PBX^M
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY^M
Supported: replaces^M
Contact: <sip:15123...@64.251.23.244>^M
Content-Type: application/sdp^M
Content-Length: 318^M
^M
v=0^M
o=root 2850 2850 IN IP4 64.251.23.244^M
s=session^M
c=IN IP4 64.251.23.244^M
t=0 0^M
m=audio 10806 RTP/AVP 0 18 111 101^M
a=rtpmap:0 PCMU/8000^M
a=rtpmap:18 G729/8000^M
a=fmtp:18 annexb=no^M
a=rtpmap:111 G726-32/8000^M
a=rtpmap:101 telephone-event/8000^M
a=fmtp:101 0-16^M
a=silenceSupp:off - - - -^M
a=ptime:20^M
a=sendrecv^M
18:45:05,791 INFO [ResponseDispatcher] viaHeader = Via: SIP/2.0/UDP
10.251.210.195
:
5080
;received
=
75.101.145.243
;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
18:45:05,791 INFO [ResponseDispatcher] route response on following
session (sip:5731...@sip.future-nine.com,
3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com
,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
18:45:05,792 INFO [MessageDispatcher] Dispatching response SIP/2.0
183 Session Progress^M
Via: SIP/2.0/UDP
10.251.210.195
:
5080
;received
=
75.101.145.243
;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
From: <sip:5731...@sip.future-
nine
.com>;tag=3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7^M
To: <sip:15123...@sip.future-nine.com>;tag=as503e3bd2^M
Call-ID: f898bc4e6851f6c9...@10.251.210.195^M
CSeq: 2 INVITE^M
User-Agent: Asterisk PBX^M
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY^M
Supported: replaces^M
Contact: <sip:15123...@64.251.23.244>^M
Content-Type: application/sdp^M
Content-Length: 318^M
^M
v=0^M
o=root 2850 2850 IN IP4 64.251.23.244^M
s=session^M
c=IN IP4 64.251.23.244^M
t=0 0^M
m=audio 10806 RTP/AVP 0 18 111 101^M
a=rtpmap:0 PCMU/8000^M
a=rtpmap:18 G729/8000^M
a=fmtp:18 annexb=no^M
a=rtpmap:111 G726-32/8000^M
a=rtpmap:101 telephone-event/8000^M
a=fmtp:101 0-16^M
a=silenceSupp:off - - - -^M
a=ptime:20^M
a=sendrecv^M
to following App/servlet => RingfulSip/ConfCallSipServlet
18:45:09,082 INFO [SipApplicationDispatcherImpl] Dialog Terminated => f898bc4e6851f6c9...@10.251.210.195
18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session (sip:5731...@sip.future-nine.com
,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com
,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session (sip:5731...@sip.future-nine.com
,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com
,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
Vladimir Ralev
1. INVITE (Creates new dialog)
2. 407 Proxy Authentication Required (Fails and destroys the dialog from 1)
2.5 ANOTHER INVITE MUST BE SENT HERE (Here another invite and dialog must be created)
3. 100 Trying ( Without the invite from 2.5 this shouldn't be here)
4. 183 Session in Progress
5. session invalidation
6. 200 OK
Hi Vladimir,
I attached the log here. As you can see the Sip response right before the invalidation is simply a 183 response. Without attaching a very lengthy log, the flow is like this:
1. INVITE
2. 407 Proxy Authentication Required
3. 100 Trying
4. 183 Session in Progress
5. session invalidation
6. 200 OK
Is the 407 an issue here? thanks
cheers
Michael
18:45:05,786 INFO [SIP-Servlet-Tomcat-Server] <message time="1219362305786"firstLine="SIP/2.0 183 Session Progress"
isSender="false"
transactionId="z9hg4bk76481606673f62da64458f6ed809ebb7"
callId="f898bc4e6851f6c9...@10.251.210.195"
>
<![CDATA[SIP/2.0 183 Session Progress^M
Via: SIP/2.0/UDP 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
From: <sip:5731...@sip.future-nine.com>;tag=3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7^M
From: <sip:5731...@sip.future-nine.com>;tag=3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7^M
18:45:05,791 INFO [ResponseDispatcher] viaHeader = Via: SIP/2.0/UDP 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
18:45:05,792 INFO [MessageDispatcher] Dispatching response SIP/2.0 183 Session Progress^M
18:45:05,791 INFO [ResponseDispatcher] route response on following session (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
Via: SIP/2.0/UDP 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
From: <sip:5731...@sip.future-nine.com>;tag=3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7^M
On Aug 21, 2008, at 11:02 PM, Vladimir Ralev wrote:
Yes, dialog termination triggers the session invalidation.
On Fri, Aug 22, 2008 at 7:00 AM, Michael Yuan <mic...@michaelyuan.com> wrote:
The 183 and 200 responses are right next to each other ... I notice that there is a "Dialog Terminated" message right before the invalidation. That message is also present in 0.4.1. Could that be the cause? Thanks.
cheers
Michael
On Aug 21, 2008, at 10:51 PM, Vladimir Ralev wrote:
Are you sure there hasn't been a negative response other than the subsequient 200 OK? May be a full log would show the cause. The new session invalidation in 0.5 tries to remove unused sessions asap, but i dont see how it can invalidate an active session like this. As a workaround you should be able to override this behaviour by doing setInvalidateWhenReady(false) on your sip and app sessions (this mode is similar to the behaviour in 0.4)
On Fri, Aug 22, 2008 at 3:14 AM, Michael Yuan <mic...@michaelyuan.com> wrote:
Folks,
I just upgraded to mobicents 1.2.0 CR1 w/ Sip Servlet 0.5 and my app stopped working ... It was working in Sip Servlet 0.4.1.
What happens is that mobicents invalidates my Sip Session when it receives the 200/OK message back. The flow is like this:
1. I send out an INVITE and gets several 183 responses until the user picks up the phone. The 183 responses are routed correctly.
18:45:05,791 INFO [ResponseDispatcher] route response on following session (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
18:45:05,792 INFO [MessageDispatcher] Dispatching response SIP/2.0 183 Session Progress
2. Then, the 200/OK comes and the server suddenly decides the invalidate the application session. My SipServlet methods are not executed here.
18:45:09,082 INFO [SipApplicationDispatcherImpl] Dialog Terminated => f898bc4e6851f6c9...@10.251.210.195
18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
Michael Yuan
Sorry, I mis-spoke. I did have an INVITE in 2.5. :) Here is how I
created it in doErrorResponse():
SipServletRequest challengeRequest
=response.getSession().createRequest(response.getRequest().getMethod());
challengeRequest.addAuthHeader(response, authInfo);
It is in the same session as the original INVITE. Do I need to create
a new session for this second INVITE?
cheers
Michael
> ;received
> =
> 75.101.145.243
> ;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
> From: <sip:5731...@sip.future-
> nine
> .com
> ;received
> =
> 75.101.145.243
> ;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
> From: <sip:5731...@sip.future-
> nine
> .com
> ;received
> =
> 75.101.145.243
> ;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
> From: <sip:5731...@sip.future-
> nine
> .com
> 18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session
> (sip:5731...@sip.future-nine.com,
> 3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com
> ,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
Vladimir Ralev
For now your options are:
1. Use the setInvalidateWhenReady workaround
2. Instead of creating the second invite from the invaludated session, create the new invite through the SipFactory
Via: SIP/2.0/UDP 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
From: <sip:5731...@sip.future-nine.com>;tag=3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7^M
Via: SIP/2.0/UDP 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
From: <sip:5731...@sip.future-nine.com>;tag=3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7^M
18:45:05,791 INFO [ResponseDispatcher] viaHeader = Via: SIP/2.0/UDP 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
18:45:05,791 INFO [ResponseDispatcher] route response on following session (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
18:45:05,792 INFO [MessageDispatcher] Dispatching response SIP/2.0 183 Session Progress^M
Via: SIP/2.0/UDP 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
From: <sip:5731...@sip.future-nine.com>;tag=3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7^M
On Aug 21, 2008, at 11:02 PM, Vladimir Ralev wrote:
Yes, dialog termination triggers the session invalidation.
On Fri, Aug 22, 2008 at 7:00 AM, Michael Yuan <mic...@michaelyuan.com> wrote:
The 183 and 200 responses are right next to each other ... I notice that there is a "Dialog Terminated" message right before the invalidation. That message is also present in 0.4.1. Could that be the cause? Thanks.
cheers
Michael
On Aug 21, 2008, at 10:51 PM, Vladimir Ralev wrote:
Are you sure there hasn't been a negative response other than the subsequient 200 OK? May be a full log would show the cause. The new session invalidation in 0.5 tries to remove unused sessions asap, but i dont see how it can invalidate an active session like this. As a workaround you should be able to override this behaviour by doing setInvalidateWhenReady(false) on your sip and app sessions (this mode is similar to the behaviour in 0.4)
On Fri, Aug 22, 2008 at 3:14 AM, Michael Yuan <mic...@michaelyuan.com> wrote:
Folks,
I just upgraded to mobicents 1.2.0 CR1 w/ Sip Servlet 0.5 and my app stopped working ... It was working in Sip Servlet 0.4.1.
What happens is that mobicents invalidates my Sip Session when it receives the 200/OK message back. The flow is like this:
1. I send out an INVITE and gets several 183 responses until the user picks up the phone. The 183 responses are routed correctly.
18:45:05,791 INFO [ResponseDispatcher] route response on following session (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
18:45:05,792 INFO [MessageDispatcher] Dispatching response SIP/2.0 183 Session Progress
2. Then, the 200/OK comes and the server suddenly decides the invalidate the application session. My SipServlet methods are not executed here.
18:45:09,082 INFO [SipApplicationDispatcherImpl] Dialog Terminated => f898bc4e6851f6c9...@10.251.210.195
18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
Michael Yuan
> 2. Instead of creating the second invite from the invaludated
> session, create the new invite through the SipFactory
Hmm, the issue with this is that I have a lot attributes in the
session, and would hate to port them all over ...
I will investigate how to put the AuthInfo into the original INVITE
request so that the gateway never comes back with a 407 ...
cheers
Michael
> ;received
> =
> 75.101.145.243
> ;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
> From: <sip:5731...@sip.future-
> nine
> .com
> ;received
> =
> 75.101.145.243
> ;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
> From: <sip:5731...@sip.future-
> nine
> .com
> ;received
> =
> 75.101.145.243
> ;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
> From: <sip:5731...@sip.future-
> nine
> .com
> 18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session
> (sip:5731...@sip.future-nine.com,
> 3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com
> ,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
Vladimir Ralev
If you want to keep the session attributes use the setInvalidateWhenReady(false). Or use a "carrier object" to make it easier to copy the session attribs.
Via: SIP/2.0/UDP 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
From: <sip:5731...@sip.future-nine.com>;tag=3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7^M
Via: SIP/2.0/UDP 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
From: <sip:5731...@sip.future-nine.com>;tag=3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7^M
18:45:05,791 INFO [ResponseDispatcher] viaHeader = Via: SIP/2.0/UDP 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
18:45:05,791 INFO [ResponseDispatcher] route response on following session (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
18:45:05,792 INFO [MessageDispatcher] Dispatching response SIP/2.0 183 Session Progress^M
Via: SIP/2.0/UDP 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
From: <sip:5731...@sip.future-nine.com>;tag=3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7^M
On Aug 21, 2008, at 11:02 PM, Vladimir Ralev wrote:
Yes, dialog termination triggers the session invalidation.
On Fri, Aug 22, 2008 at 7:00 AM, Michael Yuan <mic...@michaelyuan.com> wrote:
The 183 and 200 responses are right next to each other ... I notice that there is a "Dialog Terminated" message right before the invalidation. That message is also present in 0.4.1. Could that be the cause? Thanks.
cheers
Michael
On Aug 21, 2008, at 10:51 PM, Vladimir Ralev wrote:
Are you sure there hasn't been a negative response other than the subsequient 200 OK? May be a full log would show the cause. The new session invalidation in 0.5 tries to remove unused sessions asap, but i dont see how it can invalidate an active session like this. As a workaround you should be able to override this behaviour by doing setInvalidateWhenReady(false) on your sip and app sessions (this mode is similar to the behaviour in 0.4)
On Fri, Aug 22, 2008 at 3:14 AM, Michael Yuan <mic...@michaelyuan.com> wrote:
Folks,
I just upgraded to mobicents 1.2.0 CR1 w/ Sip Servlet 0.5 and my app stopped working ... It was working in Sip Servlet 0.4.1.
What happens is that mobicents invalidates my Sip Session when it receives the 200/OK message back. The flow is like this:
1. I send out an INVITE and gets several 183 responses until the user picks up the phone. The 183 responses are routed correctly.
18:45:05,791 INFO [ResponseDispatcher] route response on following session (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
18:45:05,792 INFO [MessageDispatcher] Dispatching response SIP/2.0 183 Session Progress
2. Then, the 200/OK comes and the server suddenly decides the invalidate the application session. My SipServlet methods are not executed here.
18:45:09,082 INFO [SipApplicationDispatcherImpl] Dialog Terminated => f898bc4e6851f6c9...@10.251.210.195
18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
Michael Yuan
Yeah, you are right ... So, for the setInvalidateWhenReady() method,
shall I call it on both the SipSession and the SipApplicationSession?
Or, just the SipSession shall suffice? Thanks
cheers
Michael
> ;received
> =
> 75.101.145.243
> ;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
> From: <sip:5731...@sip.future-
> nine
> .com
> ;received
> =
> 75.101.145.243
> ;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
> From: <sip:5731...@sip.future-
> nine
> .com
> ;received
> =
> 75.101.145.243
> ;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
> From: <sip:5731...@sip.future-
> nine
> .com
> 18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session
> (sip:5731...@sip.future-nine.com,
> 3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com
> ,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
Vladimir Ralev
Via: SIP/2.0/UDP 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
From: <sip:5731...@sip.future-nine.com>;tag=3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7^M
Via: SIP/2.0/UDP 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
From: <sip:5731...@sip.future-nine.com>;tag=3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7^M
18:45:05,791 INFO [ResponseDispatcher] viaHeader = Via: SIP/2.0/UDP 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
18:45:05,791 INFO [ResponseDispatcher] route response on following session (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
18:45:05,792 INFO [MessageDispatcher] Dispatching response SIP/2.0 183 Session Progress^M
Via: SIP/2.0/UDP 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
From: <sip:5731...@sip.future-nine.com>;tag=3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7^M
On Aug 21, 2008, at 11:02 PM, Vladimir Ralev wrote:
Yes, dialog termination triggers the session invalidation.
On Fri, Aug 22, 2008 at 7:00 AM, Michael Yuan <mic...@michaelyuan.com> wrote:
The 183 and 200 responses are right next to each other ... I notice that there is a "Dialog Terminated" message right before the invalidation. That message is also present in 0.4.1. Could that be the cause? Thanks.
cheers
Michael
On Aug 21, 2008, at 10:51 PM, Vladimir Ralev wrote:
Are you sure there hasn't been a negative response other than the subsequient 200 OK? May be a full log would show the cause. The new session invalidation in 0.5 tries to remove unused sessions asap, but i dont see how it can invalidate an active session like this. As a workaround you should be able to override this behaviour by doing setInvalidateWhenReady(false) on your sip and app sessions (this mode is similar to the behaviour in 0.4)
On Fri, Aug 22, 2008 at 3:14 AM, Michael Yuan <mic...@michaelyuan.com> wrote:
Folks,
I just upgraded to mobicents 1.2.0 CR1 w/ Sip Servlet 0.5 and my app stopped working ... It was working in Sip Servlet 0.4.1.
What happens is that mobicents invalidates my Sip Session when it receives the 200/OK message back. The flow is like this:
1. I send out an INVITE and gets several 183 responses until the user picks up the phone. The 183 responses are routed correctly.
18:45:05,791 INFO [ResponseDispatcher] route response on following session (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
18:45:05,792 INFO [MessageDispatcher] Dispatching response SIP/2.0 183 Session Progress
2. Then, the 200/OK comes and the server suddenly decides the invalidate the application session. My SipServlet methods are not executed here.
18:45:09,082 INFO [SipApplicationDispatcherImpl] Dialog Terminated => f898bc4e6851f6c9...@10.251.210.195
18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
Michael Yuan
Hmm, I did setInvalidateWhenReady(false) but it still invalidates the
session ... In fact, the log even says that the property is "true"
after I explicitly set it to false:
// Create app session and request
SipApplicationSession appSession =
sipFactory.createApplicationSession();
SipServletRequest sipreq = sipFactory.createRequest(appSession,
"INVITE", providerAddr.getURI(), callerAddr.getURI());
SipSession session = sipreq.getSession ();
// Set handler servlet for the caller session
session.setHandler("ConnectCallSipServlet");
// Bug #332
session.setInvalidateWhenReady(false);
... ...
sipreq.send ();
10:57:46,750 INFO [SipApplicationDispatcherImpl] Invalidating sip
session (sip:5731...@sip.future-nine.com,
2030641343701261531_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com
,67a8cb144169f32c...@10.251.195.132,RingfulSip) if ready
to invalidate true
Any ideas? Thanks.
cheers
Michael
> ;received
> =
> 75.101.145.243
> ;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
> From: <sip:5731...@sip.future-
> nine
> .com
> ;received
> =
> 75.101.145.243
> ;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
> From: <sip:5731...@sip.future-
> nine
> .com
> ;received
> =
> 75.101.145.243
> ;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
> From: <sip:5731...@sip.future-
> nine
> .com
> 18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session
> (sip:5731...@sip.future-nine.com,
> 3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com
> ,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
Jean Deruelle
has been changed).
Can you confirm that it works for you from the trunk ?
Thanks in advance
Best regards
Jean
Jean Deruelle
As mentionned in JSR 289 Section 6.2.4.1.2 Invalidate When Ready Mechanism
"setInvalidateWhenReady(boolean flag) - allows applications to
indicate to the container to notify it when the SipSession is in the
ready-to-invalidate state. The container notifies the application
using the SipSessionListener.sessionReadyToInvalidate(SipSessionEvent
se) callback."
And
"If the application does not explicitly invalidate the session in the
callback or has not defined a listener, the container will invalidate
the session. "
So Issue 332 was clearly a blocking bug. However I commited a fix for
it, can you try it out from the trunk or from the nightly builds
http://hudson.jboss.org/hudson/job/MobicentsSipServletsRelease/ and
kindly revert back to us ?
Thanks in advance
Best regards
Jean
>> 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
>> From:
>> <sip:5731...@sip.future-nine.com>;tag=3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7^M
>> 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
>> From:
>> <sip:5731...@sip.future-nine.com>;tag=3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7^M
>> 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
>>
>>
>> 18:45:05,791 INFO [ResponseDispatcher] route response on following
>> session
>> (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
>> 18:45:05,792 INFO [MessageDispatcher] Dispatching response SIP/2.0 183
>> Session Progress^M
>> Via: SIP/2.0/UDP
>> 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
>> From:
>> <sip:5731...@sip.future-nine.com>;tag=3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7^M
>> 18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session
>> (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
Michael Yuan
I tried again with the latest nightly build
(MobicentsSipServletsRelease #49) and I had the following problems:
1. It throws the following exception when I tried to create an ACK
from a 200 response:
java.lang.NullPointerException
at
org
.mobicents
.servlet
.sip
.message.SipServletResponseImpl.createAck(SipServletResponseImpl.java:
152)
at
com
.ringful
.restserver
.callrecord
.CallRecordSipServlet.doSuccessResponse(CallRecordSipServlet.java:102)
====================
2. It then tries to invalidate the current session. But I guess
message shows that the session is not invalidated.
13:00:47,476 INFO [SipApplicationDispatcherImpl] Invalidating sip
session (sip:5731...@sip.future-nine.com,
2794831112133467189_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:18004...@sip.future-nine.com
,a7295a6727daff07...@10.251.107.163,RingfulSip) if ready
to invalidate false
======================
3. But later, it invalidates the app session as well as the SipSession
contained within ...
13:03:39,624 INFO [SipApplicationSessionImpl] Invalidating the
following sip application session (a7295a6727daff07...@10.251.107.163
,RingfulSip)
13:03:39,624 INFO [SipSessionImpl] Invalidating the sip session (sip:5731...@sip.future-nine.com
,2794831112133467189_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:18004...@sip.future-nine.com
,a7295a6727daff07...@10.251.107.163,RingfulSip)
13:03:39,624 INFO [SipSessionImpl] Invalidating the sip session (sip:5731...@sip.future-nine.com
,2794831112133467189_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:18004...@sip.future-nine.com
,a7295a6727daff07...@10.251.107.163,RingfulSip)
cheers
Michael
>>>> =RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
>>>> From:
>>>> <sip:5731...@sip.future-
>>>> nine
>>>> .com
>>>> >
>>>> 2.0 183
>>>> Session Progress^M
>>>> Via: SIP/2.0/UDP
>>>> 10.251.210.195
>>>> :
>>>> 5080
>>>> ;received
>>>> =
>>>> 75.101.145.243
>>>> ;appname
>>>> =RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
>>>> From:
>>>> <sip:5731...@sip.future-
>>>> nine
>>>> .com
>>>> >
>>>> 10.251.210.195
>>>> :
>>>> 5080
>>>> ;received
>>>> =
>>>> 75.101.145.243
>>>> ;appname
>>>> =RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
>>>>
>>>>
>>>> 18:45:05,791 INFO [ResponseDispatcher] route response on following
>>>> session
>>>> (sip:5731...@sip.future-nine.com,
>>>> 3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com
>>>> ,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
>>>> 18:45:05,792 INFO [MessageDispatcher] Dispatching response SIP/
>>>> 2.0 183
>>>> Session Progress^M
>>>> Via: SIP/2.0/UDP
>>>> 10.251.210.195
>>>> :
>>>> 5080
>>>> ;received
>>>> =
>>>> 75.101.145.243
>>>> ;appname
>>>> =RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
>>>> From:
>>>> <sip:5731...@sip.future-
>>>> nine
>>>> .com
>>>> >
>>>> 18:45:05,792 INFO [MessageDispatcher] Dispatching response SIP/
>>>> 2.0 183
>>>> Session Progress
>>>>
>>>>
>>>> 2. Then, the 200/OK comes and the server suddenly decides the
>>>> invalidate
>>>> the application session. My SipServlet methods are not executed
>>>> here.
>>>>
>>>> 18:45:09,082 INFO [SipApplicationDispatcherImpl] Dialog
>>>> Terminated =>
>>>> f898bc4e6851f6c9...@10.251.210.195
>>>> 18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session
>>>> (sip:5731...@sip.future-nine.com,
>>>> 3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com
>>>> ,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
>>>> 18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session
>>>> (sip:5731...@sip.future-nine.com,
>>>> 3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com
>>>> ,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
Jean Deruelle
Can you provide the full log file so that I can try to see what's
going on regarding your related problems ?
In the meanwhile can you check out the related test case I committed
to see if you can reproduce the problem in tweaking it or checking
your use case against it ?
(Test is available at
http://code.google.com/p/mobicents/source/browse/trunk/servers/sip-servlets/sip-servlets-test-suite/testsuite/src/test/java/org/mobicents/servlet/sip/testsuite/security/ShootistSipServletAuthTest.java)
Thanks in advance
Best regards
Jean Deruelle
On Mon, Aug 25, 2008 at 7:10 PM, Michael Yuan <mic...@michaelyuan.com> wrote:
>
> Hi Jean,
>
> I tried again with the latest nightly build (MobicentsSipServletsRelease
> #49) and I had the following problems:
>
> 1. It throws the following exception when I tried to create an ACK from a
> 200 response:
>
> java.lang.NullPointerException
> at
> org.mobicents.servlet.sip.message.SipServletResponseImpl.createAck(SipServletResponseImpl.java:152)
> at
> com.ringful.restserver.callrecord.CallRecordSipServlet.doSuccessResponse(CallRecordSipServlet.java:102)
>
> ====================
>
> 2. It then tries to invalidate the current session. But I guess message
> shows that the session is not invalidated.
>
> 13:00:47,476 INFO [SipApplicationDispatcherImpl] Invalidating sip session
> (sip:5731...@sip.future-nine.com,2794831112133467189_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:18004...@sip.future-nine.com,a7295a6727daff07...@10.251.107.163,RingfulSip)
> if ready to invalidate false
>
> ======================
>
> 3. But later, it invalidates the app session as well as the SipSession
> contained within ...
>
> 13:03:39,624 INFO [SipApplicationSessionImpl] Invalidating the following
> sip application session
> (a7295a6727daff07...@10.251.107.163,RingfulSip)
> 13:03:39,624 INFO [SipSessionImpl] Invalidating the sip session
> (sip:5731...@sip.future-nine.com,2794831112133467189_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:18004...@sip.future-nine.com,a7295a6727daff07...@10.251.107.163,RingfulSip)
> 13:03:39,624 INFO [SipSessionImpl] Invalidating the sip session
> (sip:5731...@sip.future-nine.com,2794831112133467189_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:18004...@sip.future-nine.com,a7295a6727daff07...@10.251.107.163,RingfulSip)
>
>
>>>>> 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
>>>>> From:
>>>>>
>>>>> <sip:5731...@sip.future-nine.com>;tag=3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7^M
>>>>> 18:45:05,791 INFO [SipApplicationDispatcherImpl] Response SIP/2.0 183
>>>>> Session Progress^M
>>>>> Via: SIP/2.0/UDP
>>>>>
>>>>> 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
>>>>> From:
>>>>>
>>>>> <sip:5731...@sip.future-nine.com>;tag=3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7^M
>>>>> 18:45:05,791 INFO [ResponseDispatcher] viaHeader = Via: SIP/2.0/UDP
>>>>>
>>>>> 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
>>>>>
>>>>>
>>>>> 18:45:05,791 INFO [ResponseDispatcher] route response on following
>>>>> session
>>>>>
>>>>> (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
>>>>> 18:45:05,792 INFO [MessageDispatcher] Dispatching response SIP/2.0 183
>>>>> Session Progress^M
>>>>> Via: SIP/2.0/UDP
>>>>>
>>>>> 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
>>>>> From:
>>>>>
>>>>> <sip:5731...@sip.future-nine.com>;tag=3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7^M
>>>>> 18:45:05,792 INFO [MessageDispatcher] Dispatching response SIP/2.0 183
>>>>> Session Progress
>>>>>
>>>>>
>>>>> 2. Then, the 200/OK comes and the server suddenly decides the
>>>>> invalidate
>>>>> the application session. My SipServlet methods are not executed here.
>>>>>
>>>>> 18:45:09,082 INFO [SipApplicationDispatcherImpl] Dialog Terminated =>
>>>>> f898bc4e6851f6c9...@10.251.210.195
>>>>> 18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session
>>>>>
>>>>> (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
>>>>> 18:45:09,082 INFO [SipSessionImpl] Invalidating the sip session
>>>>>
>>>>> (sip:5731...@sip.future-nine.com,3768469970740092511_1a3d29c159d40db45c2e73015609b93236c2b7c7,sip:15123...@sip.future-nine.com,f898bc4e6851f6c9...@10.251.210.195,RingfulSip)
Jean Deruelle
Could you retry again with the latest snapshot (should be #51), I
succeeded to reproduce the problem and I committed another fix for it,
should be OK now (famous last words) ?
Thanks in advance
Best regards
Jean
narfice
Was issue #3 from Michael Yuan resolved in the end? I'm experiencing
the same thing - my SIP sessions get invalidated during normal
operation. I don't know why, and haven't been able to run 'smaller'
tests to replicate the problem yet, so the logs are huge. I'll do that
soon, but if there is a solution in the meantime...
I'm using version 0.5.1 - I upgraded before posting, in case the fix
was included. The INFO I get coming out in the log are the same as
Michaels':
2008-09-23 16:17:14,179 INFO pool-1-thread-7
org.mobicents.servlet.sip.core.session.SipApplicationSessionImpl.invalidate(SipApplicationSessionImpl.java:
450) - Invalidating the following sip application session
(1-2...@127.0.1.1,SignalServlet)
2008-09-23 16:17:14,181 INFO pool-1-thread-7
org.mobicents.servlet.sip.core.session.SipSessionImpl.invalidate(SipSessionImpl.java:
570) - Invalidating the sip session
(sip:su...@127.0.1.1:5060,1,sip:subs...@127.0.0.1:5080,1-2...@127.0.1.1,SignalServlet)
...etc
Please let me know. Thanks!
mike
On Aug 27, 11:14 am, "Jean Deruelle" <jean.derue...@gmail.com> wrote:
> Hi Michael,
>
> Could you retry again with the latest snapshot (should be #51), I
> succeeded to reproduce the problem and I committed another fix for it,
> should be OK now (famous last words) ?
>
> Thanks in advance
> Best regards
> Jean
>
> > Hi Michael
>
> > Can you provide the full log file so that I can try to see what's
> > going on regarding your related problems ?
> > In the meanwhile can you check out the related test case I committed
> > to see if you can reproduce the problem in tweaking it or checking
> > your use case against it ?
> > (Test is available at
> > Thanks in advance
> > Best regards
> > Jean Deruelle
>
>
> >> Hi Jean,
>
> >> I tried again with the latest nightly build (MobicentsSipServletsRelease
> >> #49) and I had the following problems:
>
> >> 1. It throws the following exception when I tried to create an ACK from a
> >> 200 response:
>
> >> java.lang.NullPointerException
> >> at
> >> org.mobicents.servlet.sip.message.SipServletResponseImpl.createAck(SipServletResponseImpl.java:152)
> >> at
> >> com.ringful.restserver.callrecord.CallRecordSipServlet.doSuccessResponse(CallRecordSipServlet.java:102)
>
> >> ====================
>
> >> 2. It then tries to invalidate the current session. But I guess message
> >> shows that the session is not invalidated.
>
> >> 13:00:47,476 INFO [SipApplicationDispatcherImpl] Invalidating sip session
>
> >> ======================
>
> >> 3. But later, it invalidates the app session as well as the SipSession
> >> contained within ...
>
> >> 13:03:39,624 INFO [SipApplicationSessionImpl] Invalidating the following
> >> sip application session
> >> cheers
> >> Michael
>
> >> On Aug 22, 2008, at 11:43 AM, Jean Deruelle wrote:
>
> >>> I just committed a fix for it in the trunk. (only SipSessionImpl class
> >>> has been changed).
> >>> Can you confirm that it works for you from the trunk ?
>
> >>> Thanks in advance
> >>> Best regards
> >>> Jean
>
> >>> On Fri, Aug 22, 2008 at 10:58 AM, Vladimir Ralev
> >>> <vladimir.ra...@gmail.com> wrote:
>
> >>>> Just SipSession should suffice. BTW, it turned out to be a bug in sip
> >>>> servlets, it's not right to invalidate that session.
> >>>> 0.5.1 to be released by the end of the month.
>
>
> >>>>> Yeah, you are right ... So, for the setInvalidateWhenReady() method,
> >>>>> shall
> >>>>> I call it on both the SipSession and the SipApplicationSession? Or, just
> >>>>> the
> >>>>> SipSession shall suffice? Thanks
>
> >>>>> cheers
> >>>>> Michael
>
> >>>>> On Aug 22, 2008, at 12:54 AM, Vladimir Ralev wrote:
>
> >>>>>> You can't put the auth in the first invite, because the server sends a
> >>>>>> challenge in the 407 response.
> >>>>>> If you want to keep the session attributes use the
> >>>>>> setInvalidateWhenReady(false). Or use a "carrier object" to make it
> >>>>>> easier
> >>>>>> to copy the session attribs.
>
>
> >>>>>> 2. Instead of creating the second invite from the invaludated session,
> >>>>>> create the new invite through the SipFactory
>
> >>>>>> Hmm, the issue with this is that I have a lot attributes in the
> >>>>>> session,
> >>>>>> and would hate to port them all over ...
>
> >>>>>> I will investigate how to put the AuthInfo into the original INVITE
> >>>>>> request so that the gateway never comes back with a 407 ...
>
> >>>>>> cheers
> >>>>>> Michael
>
> >>>>>> On Aug 22, 2008, at 12:18 AM, Vladimir Ralev wrote:
>
> >>>>>> Yep, that's the problem. Although I am not sure if it's a bug on our
> >>>>>> side
> >>>>>> or that's how it should be. It will take a deeper look from our side.
>
> >>>>>> For now your options are:
> >>>>>> 1. Use the setInvalidateWhenReady workaround
> >>>>>> 2. Instead of creating the second invite from the invaludated session,
> >>>>>> create the new invite through the SipFactory
>
>
> >>>>>> Hi Vladimir,
>
> >>>>>> I attached the log here. As you can see the Sip response right before
> >>>>>> the
> >>>>>> invalidation is simply a 183 response. Without attaching a very lengthy
> >>>>>> log,
> >>>>>> the flow is like this:
>
> >>>>>> 1. INVITE
> >>>>>> 2. 407 Proxy Authentication Required
> >>>>>> 3. 100 Trying
> >>>>>> 4. 183 Session in Progress
> >>>>>> 5. session invalidation
> >>>>>> 6. 200 OK
>
> >>>>>> Is the 407 an issue here? thanks
>
> >>>>>> cheers
> >>>>>> Michael
>
> >>>>>> 18:45:05,786 INFO [SIP-Servlet-Tomcat-Server] <message
>
> >>>>>> from="64.251.23.244:5060"
> >>>>>> to="10.251.210.195:5080"
> >>>>>> time="1219362305786"
>
> >>>>>> isSender="false"
> >>>>>> transactionId="z9hg4bk76481606673f62da64458f6ed809ebb7"
>
> >>>>>> <![CDATA[SIP/2.0 183 Session Progress^M
> >>>>>> Via: SIP/2.0/UDP
>
> >>>>>> 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
> >>>>>> From:
>
> >>>>>> To: <sip:15123006...@sip.future-nine.com>;tag=as503e3bd2^M
> >>>>>> Call-ID: f898bc4e6851f6c905ade42828f15...@10.251.210.195^M
> >>>>>> User-Agent: Asterisk PBX^M
> >>>>>> Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY^M
> >>>>>> Supported: replaces^M
> >>>>>> Content-Length: 318^M
> >>>>>> ^M
> >>>>>> v=0^M
> >>>>>> o=root 2850 2850 IN IP4 64.251.23.244^M
> >>>>>> s=session^M
> >>>>>> c=IN IP4 64.251.23.244^M
> >>>>>> t=0 0^M
> >>>>>> m=audio 10806 RTP/AVP 0 18 111 101^M
> >>>>>> a=rtpmap:0 PCMU/8000^M
> >>>>>> a=rtpmap:18 G729/8000^M
> >>>>>> a=fmtp:18 annexb=no^M
> >>>>>> a=rtpmap:111 G726-32/8000^M
> >>>>>> a=rtpmap:101 telephone-event/8000^M
> >>>>>> a=fmtp:101 0-16^M
> >>>>>> a=silenceSupp:off - - - -^M
> >>>>>> a=ptime:20^M
> >>>>>> a=sendrecv^M
> >>>>>> ]]>
> >>>>>> </message>
>
> >>>>>> 18:45:05,791 INFO [SipApplicationDispatcherImpl] Response SIP/2.0 183
> >>>>>> Session Progress^M
> >>>>>> Via: SIP/2.0/UDP
>
> >>>>>> 10.251.210.195:5080;received=75.101.145.243;appname=RingfulSip;branch=z9hG4bK76481606673f62da64458f6ed809ebb7^M
> >>>>>> From:
>
> >>>>>> To: <sip:15123006...@sip.future-nine.com>;tag=as503e3bd2^M
> >>>>>> Call-ID: f898bc4e6851f6c905ade42828f15...@10.251.210.195^M
> >>>>>> User-Agent: Asterisk PBX^M
> >>>>>> Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY^M
> >>>>>> Supported: replaces^M
> >>>>>> Content-Length: 318^M
> >>>>>> ^M
> >>>>>> v=0^M
> >>>>>> o=root 2850 2850 IN IP4 64.251.23.244^M
> >>>>>> s=session^M
> >>>>>> c=IN IP4 64.251.23.244^M
> >>>>>> t=0 0^M
> >>>>>> m=audio 10806 RTP/AVP 0 18 111 101^M
> >>>>>> a=rtpmap:0 PCMU/8000^M
> >>>>>> a=rtpmap:18 G729/8000^M
> >>>>>> a=fmtp:18 annexb=no^M
> >>>>>> a=rtpmap:111 G726-32/8000^M
> >>>>>> a=rtpmap:101 telephone-event/8000^M
> >>>>>> a=fmtp:101 0-16^M
> >>>>>> a=silenceSupp:off - - - -^M
> >>>>>> a=ptime:20^M
> >>>>>> a=sendrecv^M
>
>
> read more »
Jean Deruelle
or cut from it a complete call flow that displays the problem.
Thanks in advance.
Best regards
Jean Deruelle
narfice
I have managed to cut down the logs drastically, and still show the
same result.
I've emailed it with this thread title as the subject.
The first session is invalidated at 11:36:48,080, and the other open
sessions invalidated at around 11:36:58,349. The "Cannot find the
corresponding sip application session to this subsequent request
NOTIFY" error occurs at 11:37:06,973, which generates the 500 Server
Internal Error for the NOTIFY message.
Thanks in advance!
mike
On Sep 25, 3:37 pm, "Jean Deruelle" <jean.derue...@gmail.com> wrote:
> Yeah Issue 332 was included in 0.5.1. Could you provide the logs still
> or cut from it a complete call flow that displays the problem.
> Thanks in advance.
>
> Best regards
> Jean Deruelle
>
> On Tue, Sep 23, 2008 at 5:53 PM, narfice
>
>
> > Hi
>
> > Was issue #3 from Michael Yuan resolved in the end? I'm experiencing
> > the same thing - my SIP sessions get invalidated during normal
> > operation. I don't know why, and haven't been able to run 'smaller'
> > tests to replicate the problem yet, so the logs are huge. I'll do that
> > soon, but if there is a solution in the meantime...
> > I'm using version 0.5.1 - I upgraded before posting, in case the fix
> > was included. The INFO I get coming out in the log are the same as
> > Michaels':
>
> > 2008-09-23 16:17:14,179 INFO pool-1-thread-7
> > org.mobicents.servlet.sip.core.session.SipApplicationSessionImpl.invalidate(SipApplicationSessionImpl.java:
> > 450) - Invalidating the following sip application session
> > org.mobicents.servlet.sip.core.session.SipSessionImpl.invalidate(SipSessionImpl.java:
> > 570) - Invalidating the sip session
>
> read more »
Jean Deruelle
Jean Deruelle
An issue has been created
http://code.google.com/p/mobicents/issues/detail?id=362 to track this.
Here is the explanation
"The sip sessions are invalidated when the 200 OK to a NOTIFY comes back but
and so when all sip sessions have been invalidated the sip app session is
also invalidated, thus if a NOTIFY comes back after that the sip app
session cannot be found leading to the error described in the following
thread (start to read from narfice's message)
http://groups.google.com/group/mobicents-public/browse_thread/thread/aecd3553e5d9183c/
But from the RFC 3265 :
A subscription is destroyed when a notifier sends a NOTIFY request with a
"Subscription-State" of "terminated". If a subscription's destruction
leaves no other application state associated with the dialog, the dialog
terminates.
which means that sip sessions should keep track of the Subscription-State
and only be invalidated when it is "terminated". Thus the invalidation
process should be ok."
jean.d...@gmail.com
the application session timeout default value which is 3 minutes. And
it seems to correspond to the log date of the different messages.
You may want to override the default timeout as is defined per section
6.1.2 SipApplicationSession Lifetime of JSR 289 : "Servlets can
register for application session timeout notifications using the
SipApplicationSessionListener interface. 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."
You can also set the Expires through setExpires() method to 0 or a
negative number to make the SipApplicationSession immortal.
The issue is still valid though to add tests to check the behavior of
the container on the session invalidation in SUBSCRIBE/NOTIFY cases
but I figured this would help you faster.
Jean
On Sep 26, 1:31 pm, "Michael Pitman"
> Attached is the log file - apologies for delay, been battling to send the
> email.
>
> 4567KViewDownload
Jean Deruelle
Note that this will affect only the SipSession lifetime : it should now behave in accordance to the RFC 3265 wrt dialog termination. A few tests have been added and some modified as noted in the issue to test the behavior.
Note that this won't correct your SipApplicationSession default timeout problem that still need to be changed by you as described in the previous mail.
Can you revert back to us regarding this ?
Thanks in advance
Best regards
narfice
I implemented your suggestion of overriding the default Application
Session timeout of 3 minutes, using finite expiration times, and
extending them as required using the SipApplicationSessionListener -
this now works fine, and I've run it for almost 90 minutes, with
sessions being extended as required. Some of the sessions occasionally
were invalidated after setting them to never expire (setExpires(0)),
but I implemented the listener after that - it's not ideal to have
them last forever, I guess.
I will look at the fix as soon as I can. Thank you for doing it, and
uploading it. Basically, Sip Sessions now remain valid until the
"Subscription-State" changes to terminated - doesn't that mean that
the Application Sessions will remain valid while the contained sip
session remains valid? From what I understand in "6.1.2.2.2 Invalidate
When Ready Mechanism", as long as the contained Sip Sessions are
active, the Application Session cannot be invalidated by the
container, unless done explicitly by the servlet. Is that assumption
correct?
I will however continue to explicitly set and check the Application
Session expiration, as I've already added it. Thanks, though!
Regards, mike
On Oct 8, 1:15 pm, "Jean Deruelle" <jean.derue...@gmail.com> wrote:
> Issue 362 (http://code.google.com/p/mobicents/issues/detail?id=362) has been
> fixed. It is either available from the trunk or from the nightly snapshot
> release from here (http://hudson.jboss.org/hudson/job/MobicentsSipServletsRelease/94)
> Note that this will affect only the SipSession lifetime : it should now
> behave in accordance to the RFC 3265 wrt dialog termination. A few tests
> have been added and some modified as noted in the issue to test the
> behavior.
> Note that this won't correct your SipApplicationSession default timeout
> problem that still need to be changed by you as described in the previous
> mail.
> Can you revert back to us regarding this ?
>
> Thanks in advance
> Best regards
> Jean Deruelle
>
Jean Deruelle
It just means that now the Sip Sessions are not expiring even when a NOTIFY with Subscription-State to terminated comes in and that could lead to some memory leaks.
So if you take those fix that should remove those potential memory leaks but the override of the default Application Session timeout is still needed because in 6.1.2 SipApplicationSession Lifetime.
"An application session becomes invalidated in one of three ways:
1.The SipApplicationSession expires and the container subsequently invalidates it.
2.A servlet explicitly invalidates it by invoking the invalidate() method.
3.A servlet marks the SipApplicationSession to be invalidated and the container invalidates it when the SipApplicationSession is in the ready-to-invalidate state as described in 6.1.2.2.2 Invalidate When Ready Mechanism."
We took this as priority order so 1. has precedence over all the other mechanisms for sip app session invalidation.
You may want to check when extending the lifetime of the SipApplicationSession if the SipApplicationSession has still SipSessions in it if not you can discard the lifetime extension and let the SipApplicationSession be invalidated by the container.
Thanks to you
Jean