Issue with call forward on Ring No Answer

[Aseem Asthana]

Hi Folks,
I am using mobicents release mss-1.0-jboss-4.2.3 . I am trying to implement Callforward to Voice mail on Ring No Answer.
Things work fine till the endpoint sends a BYE. I get an Internal Error on BYE. I need some help in fixing this issue.

***********************************************************************************************************************************************

Below is the call flow.

Endpoint A         Mobicent        Endpoint P          VoiceMail server
                        (SipProxy)
   |---- INVITE---------->|--------INVITE ---->|
   |<- 100 -----------------|
   |< --180 ----------------|-------------------------|
                (RNA timer of 10 sec.
                  started in my app )
                On timeout  -  proxy.cancel()
                               | ------ CANCEL-->|
                               |<-------- 487 --------|
                               |--------- ACK ----->|
                start a new branch to forward to voice mail
                              |--------------INVITE ------------------------>|    ( sip uri is mailbox@voice-mail ip adress: port )
                              |<----------------180 Ringing----------------|
   |<----------------------- |----------------200 OK -----------------------|
   |---------ACK----------|-------------------------------------------------->|
  
              (10 SEC delay for speech )
   |--------BYE -------->|

      I see a 500 internal server error for the BYE.

******************************************************************************************************************************************
I have attached the following files:
1. bye-issue.log - portion of the mobicent server.log file
2. uac-orig.log (sipp uac log message file for originating end point -Endpoint A in the callflow )
3. uas-cancel-term.log (sipp uas log message for the terminating endpoint -Endpoint B in the callflow )
4. uas-voice-mail.og (sipp uas voice mail log  for the voice mail server shown in callflow)
5.code-snippet.txt - the application code snippet that is used for callforward on RNA

*****************************************************************************************************************************************

While debugging remotely from Eclipse - I see the error generated from the file: SubsequentRequestDispatcher.java
method: dispatchMessage
public void dispatchMessage(final SipProvider sipProvider, SipServletMessageImpl sipServletMessage) throws DispatcherException {
    .....
   ......
                    } else {
                        throw new DispatcherException(Response.SERVER_INTERNAL_ERROR, "cannot find the application to handle this subsequent request " + request +
                                "in this popped routed header " + poppedRouteHeader);
                    }

applicationId is null
*************************************************************************************************************************************************

thanks
Aseem

[Vladimir Ralev]

That's an excellent report. I think it its a bug in our server and we
should not invalidate app sessions too quickly when proxying, on the
other hand we should clean up asap. Will try to figure a good way to
solve it. Thanks for the report.

[Jean Deruelle]

Hi Aseem,

Could you open an issue in the google code issue tracker for that ? http://code.google.com/p/mobicents/issues/entry

Thanks a lot for the thorough reporting

Jean

[Vladimir Ralev]

Here is the issue http://code.google.com/p/mobicents/issues/detail?id=1024
Fixed in trunk.

Good catch Aseem. I will give you a link to the snapshot when the next
nightly build is ready. Or you can build from trunk if you want.

[aseem]

Thanks a lot for the quick turn around Vladimir. I would be great if
you could send me the link to the snapshot when the next nightly build
is ready.
thanks
Aseem

On Oct 28, 2:54 pm, Vladimir Ralev <vladimir.ra...@gmail.com> wrote:
> Here is the issuehttp://code.google.com/p/mobicents/issues/detail?id=1024

> Fixed in trunk.
>
> Good catch Aseem. I will give you a link to the snapshot when the next
> nightly build is ready. Or you can build from trunk if you want.
>

> On Wed, Oct 28, 2009 at 5:23 PM, Jean Deruelle <jean.derue...@gmail.com> wrote:
> > Hi Aseem,
> > Could you open an issue in the google code issue tracker for that
> > ? http://code.google.com/p/mobicents/issues/entry
> > Thanks a lot for the thorough reporting
> > Jean
>

> > On Wed, Oct 28, 2009 at 2:10 AM, Vladimir Ralev <vladimir.ra...@gmail.com>

> > wrote:
>
> >> That's an excellent report. I think it its a bug in our server and we
> >> should not invalidate app sessions too quickly when proxying, on the
> >> other hand we should clean up asap. Will try to figure a good way to
> >> solve it. Thanks for the report.
>

> >> On Wed, Oct 28, 2009 at 2:33 AM, Aseem Asthana <aseembasth...@gmail.com>

[Vladimir Ralev]

Well, we had some problem with the builds. It should be fine now. Try
this binary http://hudson.qa.jboss.com/hudson/job/MobicentsSipServletsRelease/583/artifact/mss-1.1-SNAPSHOT-jboss-4.2.3.GA-0910301211.zip

Thanks

[Vladimir Ralev]

Sorry, this is the correct link
http://hudson.jboss.org/hudson/job/MobicentsSipServletsRelease/583/artifact/mss-1.1-SNAPSHOT-jboss-4.2.3.GA-0910301211.zip

[Vladimir Ralev]

Some proxy tests regressed in that build. It is possible they do not
affect you, but just to be safe you can use the new spin with fixes
here http://hudson.jboss.org/hudson/view/Mobicents/job/MobicentsSipServletsRelease/584/artifact/mss-1.1-SNAPSHOT-jboss-4.2.3.GA-0910301625.zip

I still don't have all test results, but so far seems good.

On Fri, Oct 30, 2009 at 7:23 PM, Vladimir Ralev

[aseem]

Hi Vladimir,
I am still seeing the issue. I downloaded the trunk code and tried to
add a temp patch to the code to see if the issue is fixed.
I added the following code in the
file SipSessionImpl.java
package org.mobicents.servlet.sip.core.session;
method:
public void updateStateOnResponse(SipServletResponseImpl response,
boolean receive) {

.......
.......

if(!hasOngoingSubscriptions) {
//TODO - ASEEM ADDED TEMP remove after final fix
if (response.getStatus() == 487){
if(logger.isDebugEnabled()) {
logger.debug("Not changing state or invalidating");
}
} else {
if(logger.isDebugEnabled()) {
logger.debug("Changing state to terminated and also
invalidating");
}

setState(State.TERMINATED);
setReadyToInvalidate(true);
}
}


This change has fixed the issue, however I think it is not the proper
fix. Basically in this case after 487 the app session not invalidated,
and the BYE that comes eventually from the other branch invalidates
the session.However this will interfere with the regular CANCEL
scenario if feel i.e.

Endpoint A Mobicent Endpoint P

(SipProxy)
|---- INVITE---------->|--------INVITE ---->|
|<- 100 -----------------|
|< --180 ----------------|-------------------------|

(default container timer of 180 sec. )

On timeout - proxy.cancel()
| ------ CANCEL-->|
|<-------- 487 --------|
|--------- ACK ----->|

The appsession will not be invalidated. I tired verifying this test
case - but it was not working.
I see the following the above case

2009-11-04 00:07:03,931 DEBUG
[org.mobicents.servlet.sip.message.SipServletRequestImpl] The found
transport for sending request is 'udp'
2009-11-04 00:07:03,931 ERROR
[org.mobicents.servlet.sip.proxy.ProxyBranchTimerTask] Problem in
timeout task
java.lang.IllegalStateException: Failed canceling proxy branch
at org.mobicents.servlet.sip.proxy.ProxyBranchImpl.cancel
(ProxyBranchImpl.java:188)
at org.mobicents.servlet.sip.proxy.ProxyBranchImpl.cancel
(ProxyBranchImpl.java:136)
at org.mobicents.servlet.sip.proxy.ProxyBranchImpl.onTimeout
(ProxyBranchImpl.java:618)
at org.mobicents.servlet.sip.proxy.ProxyBranchTimerTask.run
(ProxyBranchTimerTask.java:35)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Caused by: java.lang.IllegalStateException: Error sending request
at org.mobicents.servlet.sip.message.SipServletRequestImpl.send
(SipServletRequestImpl.java:1094)
at org.mobicents.servlet.sip.proxy.ProxyBranchImpl.cancel
(ProxyBranchImpl.java:159)
... 5 more
Caused by: java.lang.NullPointerException
at org.mobicents.servlet.sip.message.SipServletRequestImpl.send
(SipServletRequestImpl.java:939)
... 6 more

I will file a seperate report for that after testing with latest trunk
with out any of my changes to be sure. Let me know your thought on
this.

thanks
Aseem

On Oct 30, 1:35 pm, Vladimir Ralev <vladimir.ra...@gmail.com> wrote:
> Some proxy tests regressed in that build. It is possible they do not
> affect you, but just to be safe you can use the new spin with fixes

> herehttp://hudson.jboss.org/hudson/view/Mobicents/job/MobicentsSipServlet...

>
> I still don't have all test results, but so far seems good.
>
> On Fri, Oct 30, 2009 at 7:23 PM, Vladimir Ralev
>

> <vladimir.ra...@gmail.com> wrote:
> > Sorry, this is the correct link

> >http://hudson.jboss.org/hudson/job/MobicentsSipServletsRelease/583/ar...

>
> > On Fri, Oct 30, 2009 at 6:49 PM, Vladimir Ralev
> > <vladimir.ra...@gmail.com> wrote:
> >> Well, we had some problem with the builds. It should be fine now. Try

> >> this binaryhttp://hudson.qa.jboss.com/hudson/job/MobicentsSipServletsRelease/583...
>
> >> Thanks

[Vladimir Ralev]

By looking at the code, it seems you are right. Some change is
required in SipSessionImpl. I am trying to figure out why it works in
my test.

[Vladimir Ralev]

OK, my test case was just too short, when I increase the time between
ACK and BYE I see what you see. I updated the issue
http://code.google.com/p/mobicents/issues/detail?id=1024

I added some conditions to your fix to handle the other cases and it
works now. I couldn't reproduce the other exception you reported. I
wonder if that's just a race where our container cleaned up the
session already (due to the container reap task) and you additionally
try to cancel it on the invalid session. I did test that case and the
session is cleaned up now as long as your app doesnt add more branches
before the 487 response, otherwise the regular rules kick in.

So you could test the trunk code again or the next snapshot.

[aseem]

Hi Vladimir,
The Issue of call forward with Ring No Answer is solved. I re-ran my
scripts and it works fine.
thanks for the fix.
Aseem

On Nov 4, 6:19 pm, Vladimir Ralev <vladimir.ra...@gmail.com> wrote:
> OK, my test case was just too short, when I increase the time between

> ACK and BYE I see what you see.  I updated the issuehttp://code.google.com/p/mobicents/issues/detail?id=1024

>
> I added some conditions to your fix to handle the other cases and it
> works now. I couldn't reproduce the other exception you reported. I
> wonder if that's just a race where our container cleaned up the
> session already (due to the container reap task) and you additionally
> try to cancel it on the invalid session. I did test that case and the
> session is cleaned up now as long as your app doesnt add more branches
> before the 487 response, otherwise the regular rules kick in.
>
> So you could test the trunk code again or the next snapshot.
>

> On Wed, Nov 4, 2009 at 9:54 PM, Vladimir Ralev <vladimir.ra...@gmail.com> wrote:
> > By looking at the code, it seems you are right. Some change is
> > required in SipSessionImpl. I am trying to figure out why it works in
> > my test.
>

> ...
>
> read more »