Topic
  • 2 replies
  • Latest Post - ‏2011-04-13T14:08:37Z by Y436_Henry_Chin
Y436_Henry_Chin
Y436_Henry_Chin
6 Posts

Pinned topic Send outbound INVITE uses loopback

‏2011-04-13T04:01:57Z |
Hi,
We have standalone WAS7 (7.0.0.15) install (no server proxy define). Our application acts as B2BUA between two user agents (caller and callee). In the DefaultSIPApplicationRouter we are using "Basic application startup order". When inbound invite arrives this is routed to our application doInvite() method. We basically create an outbound INVITE to the callee. However, for some reason the INVITE request is being routed back to my application and not sent to callee. We enabled traces and notice in trace.log file:
OutgoingSipServletRequest: checkIsLoopback application composition is true
OutgoingSipServletRequest: checkIsLoopback Is loopback: true

Why is loopback being used?
We checked all the SIP headers of my outbound INVITE request and they all look correct, with exception to following header:
IBM-Client-Address: 192.168.1.2:5060;local-address=192.168.1.2:5060;initial-remote=192.168.1.2:5060;udp
We believe this header was added by WAS SIP container. Why is this?

We do not understand why the request is looping back and not sent to callee. Is there a configuration we need to do on WAS console or should there be specific code to set SipSession.setOutboundInterface()?

Appreciate any advice.
Regards,
Henry.
Updated on 2011-04-13T14:08:37Z at 2011-04-13T14:08:37Z by Y436_Henry_Chin
  • SystemAdmin
    SystemAdmin
    45 Posts

    Re: Send outbound INVITE uses loopback

    ‏2011-04-13T09:42:56Z  
    Hi,
    Is it possible that you have more than one SIP application installed in your env? what is the address that you are sending the request to?

    IBM-Client-Address is added by Websphere SIP container and in your case I can see that SIP container identify the request as a loopback

    BTW - the setOutboundInterface feature is not supported in a standalone environment yet, currently Websphere sip container support this feature only in a proxied environment.

    If you cannot solve the problem with the above tips, I suggest that you will open a PMR and post the traces.

    Asaf,
  • Y436_Henry_Chin
    Y436_Henry_Chin
    6 Posts

    Re: Send outbound INVITE uses loopback

    ‏2011-04-13T14:08:37Z  
    Hi,
    Is it possible that you have more than one SIP application installed in your env? what is the address that you are sending the request to?

    IBM-Client-Address is added by Websphere SIP container and in your case I can see that SIP container identify the request as a loopback

    BTW - the setOutboundInterface feature is not supported in a standalone environment yet, currently Websphere sip container support this feature only in a proxied environment.

    If you cannot solve the problem with the above tips, I suggest that you will open a PMR and post the traces.

    Asaf,
    Hi,
    I finally figured out the problem. The problem was that all inbound calls (to WAS) were being redirected back to originator and not the callee. Basically, DMC (our servlet) acts as B2BUA between caller and callee. As part of JSR289 specification section 15.2 (Application Routing Behaviour) applications that act as B2BUA must tell sip container how the process any new outbound INVITE request. The reason this is needed is because every time a outbound request is sent, the sip container calls ApplicationRouter to determine the next application to route the request. In the case of RoutingDirective.NEW which is the default when creating a new request from SipFactory, this causes the ApplicationRouter to process the request as if it is an initial request into the system. Therefore, DMC would be the next available application to process the request. This is not what we want, we want the new outbound INVITE to effectively continue on to the destination callee.

    There a couple of ways of fixing this, one alternative is to use B2BUAHelper class, I believe this implicitly sets the RoutingDirective to CONTINUE. Another way, is by manually creating a new request and copying/setting the appropriate headers for the callee destination and then finally setting the RoutingDirective to CONTINUE. The later case is being used and is working fine in our tests.
    Regards,
    HC.