Mobicents SIP error response handling - what's the proper way to re-proxy?

Question

The Mobicents SIP servlet container appears to handle error responses differently to other SIP containers I've used. The situation is that:

• On receipt of an INVITE, app handles and proxies (supervised) downstream (so it may receive the responses to the invite).

• On receipt of an error response from the initial target, app proxies to a new destination (in a non-supervised way).

This should prevent the initial error response from propagating upstream (since the transaction has a new target). However, with the Mobicents container, even though the INVITE is indeed proxied out to the new destination, the initially received error response still propagates upstream. I believe that this is a bug in the Mobicents implementation - but how does one work around this?

Code:

public void doInvite(SipServletRequest req) {
  req.getProxy().proxyTo(req.getRequestURI());
}

public void doError(SipServletResponse res) {
    Proxy p = res.getProxy();
    p.setSupervised(false);
    p.proxyTo(...);
    // request is proxied, but the error response still passes
    // upstream - the retargeting of the transaction (through
    // proxying to a new destination ought to prevent that).
}

Answer 1

Which other SIP Containers are you migrating your application from ? Are you doing sequential or parallel proxying ? Which error response do you receive ? Which version of the Mobicents SIP Servlets container are you using ? Do you have a full log available on gist.github.com or pastebin.com ?

Answer 2

As a pure proxying solution the Mobicents is doing the right behavior of forwarding the Error response back to the call initiator and hence the logic of sequential forking [based on the error code] has to be dealt on the caller side.

But if you want this behavior by the mobicents, you need to run the B2BUA mode for the mobicents that should give you more granular control of deciding the behavior independent on the 2 calls legs [ ingress / egress ].

Originator gets a 183 Call Progress for the INVITE [ingress leg], while the sequential retries can be handled on the egress leg with no risk of the initial timeouts happening on the Ingress.