2

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).
}
Nathan Woodhouse
  • 21
  • 1

2 Answers2

0

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 ?

jeand
  • 2,325
  • 14
  • 12
  • Thanks for the response. Using latest tomcat version of mobicents sip servlets (3.0.564). Behaviour varies from Avaya session manager, ubiquity sip app server, thrupoint FAS, and I think also another that I can't recall the name of. Error response received is a 486, but I don't believe this matters (any non success response that results in the app creating new tranaction targets should cause the server to not propagate the response upstream while the new targets are evaluated). Don't have a log handy to post atm as on a tablet right now. Hth, and thanks again for a response. – Nathan Woodhouse Jun 01 '15 at 23:57
  • See rfc3261, 16.7 for context concerning response handling, what responses should be immediately propagated upstream, what 'best' responses should go upstream from the server's response context etc. – Nathan Woodhouse Jun 02 '15 at 00:33
  • Thanks. Can you retry from one the SNAPSHOT builds here https://mobicents.ci.cloudbees.com/job/MobicentsSipServlets-Release/lastSuccessfulBuild/artifact/ to see if you still face the same behavior. If you do please open an issue on https://github.com/Mobicents/RestComm/issues/new. – jeand Jun 02 '15 at 20:39
0

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.

Rajesh
  • 660
  • 4
  • 12
  • Thanks for the response. I understand your point that the server is seemingly behaving correctly from the point of view that it seems reasonable for a proxy to proxy what it receives. However it is incorrect to say that the server is behaving correctly in doing so in this case. A proxy ought not to proxy every message, and this is one example (as the app supervising the transaction has given the container new transaction targets to attempt). – Nathan Woodhouse Jun 02 '15 at 00:15
  • The container behaviour is erroneous since it both attempts the new target(s) by proxying the invite out, but also prevents the possibility of those targets from successfully establishing a session since it allows the called to receive the 1st error response received.As you point out, running as a B2bua would enable finer control over the sip sessions, but should not be necessary if the proxying behaviour were fixed. Thanks for that suggestion though, and indeed for the response :-) – Nathan Woodhouse Jun 02 '15 at 00:15