If an INVITE is forwarded in B2BUA mode, the call is forked by some proxy, and the UAS that answers the call is not the UAS that sent the first provisional response, then forwarding the 200 OK to the UAC fails

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Send an INVITE to a servlet that forwards it using 
B2buaHelper.createRequest()
2. Have some downstream proxy fork the call to UAS1 and UAS2
3. Have UAS1 send a provisional responses with a To tag
4. Have the servlet forward both provisional responses using 
B2buaHelper.createResponseToOriginalRequest()
4. Answer the call with UAS2
5. Have the servlet forward the 200 OK response with 
B2buaHelper.createResponseToOriginalRequest()

I tested this by routing to an instance of the reSIProcate proxy where two 
phones had registered using the same account details.

What is the expected output? What do you see instead?
The expected behaviour is that the 200 OK from UAS2 is forwarded, with the To 
tag being different to the To tag of the forwarded provisional response from 
UAS1 (but the same as the To tag in any provisional responses forwarded from 
UAS2). Instead, a SipException occurs:

org.mobicents.servlet.sip.core.DispatcherException: Unexpected exception while 
processing response
        at org.mobicents.servlet.sip.core.dispatchers.ResponseDispatcher$1.dispatch(ResponseDispatcher.java:493)
        at org.mobicents.servlet.sip.core.dispatchers.DispatchTask.dispatchAndHandleExceptions(DispatchTask.java:61)
        at org.mobicents.servlet.sip.core.dispatchers.ResponseDispatcher.dispatchMessage(ResponseDispatcher.java:514)
        at org.mobicents.servlet.sip.core.SipApplicationDispatcherImpl.processResponse(SipApplicationDispatcherImpl.java:1002)
        at gov.nist.javax.sip.EventScanner.deliverEvent(EventScanner.java:296)
        at gov.nist.javax.sip.SipProviderImpl.handleEvent(SipProviderImpl.java:185)
        at gov.nist.javax.sip.DialogFilter.processResponse(DialogFilter.java:1498)
        at gov.nist.javax.sip.stack.SIPClientTransaction.inviteClientTransaction(SIPClientTransaction.java:906)
        at gov.nist.javax.sip.stack.SIPClientTransaction.processResponse(SIPClientTransaction.java:548)
        at gov.nist.javax.sip.stack.SIPClientTransaction.processResponse(SIPClientTransaction.java:1582)
        at gov.nist.javax.sip.stack.UDPMessageChannel.processMessage(UDPMessageChannel.java:602)
        at gov.nist.javax.sip.stack.UDPMessageChannel.processIncomingDataPacket(UDPMessageChannel.java:511)
        at gov.nist.javax.sip.stack.UDPMessageChannel.run(UDPMessageChannel.java:316)
        at java.lang.Thread.run(Thread.java:679)
Caused by: java.lang.IllegalStateException: an exception occured when sending 
the response SIP/2.0 200 OK
        at org.mobicents.servlet.sip.message.SipServletResponseImpl.send(SipServletResponseImpl.java:656)
        at org.mobicents.servlet.sip.message.SipServletResponseImpl.send(SipServletResponseImpl.java:458)
        ... (internal com.telsis calls removed)
        at com.telsis.tasp.OceanServlet.doSuccessResponse()
        at javax.servlet.sip.SipServlet.doResponse(SipServlet.java:274)
        at javax.servlet.sip.SipServlet.service(SipServlet.java:334)
        at org.mobicents.servlet.sip.core.dispatchers.MessageDispatcher.callServlet(MessageDispatcher.java:457)
        at org.mobicents.servlet.sip.core.dispatchers.ResponseDispatcher$1.dispatch(ResponseDispatcher.java:481)
        ... 13 more
Caused by: javax.sip.SipException: Tag mismatch dialogTag is 
42363132_09ba9498_60e91531-46a6-4bc3-98c1-dd4ed264574a responseTag is 
58801370_09ba9498_60e91531-46a6-4bc3-98c1-dd4ed264574a
        at gov.nist.javax.sip.stack.SIPServerTransaction.sendResponse(SIPServerTransaction.java:1487)
        at org.mobicents.servlet.sip.message.SipServletResponseImpl.send(SipServletResponseImpl.java:637)
        ... 23 more

42363132_09ba9498_60e91531-46a6-4bc3-98c1-dd4ed264574a is the To tag on the 
forwarded response from UAS1 (i.e. the response that Mobicents sent to the 
UAC), while 58801370_09ba9498_60e91531-46a6-4bc3-98c1-dd4ed264574a is the To 
tag on the forwarded response from UAS2.

What version of the product are you using? On what operating system?
MSS-2.0.0.Final on Tomcat7 on CentOS 5.10

Please provide any additional information below.
I think this is caused by the NIST SIPServerTransaction. It appears to create a 
SIPDialog object when it first receives a provisional response with a To tag 
(which is correct - the presence of a To tag in a provisional response 
establishes an early dialog). When a successful response is sent the stack 
"make[s] sure that the response being sent makes sense" and checks that the To 
tag in its saved SIPDialog matches that of the response. If they don't match 
then it refuses to send the response. It's this check that is wrong, as there's 
no requirement in RFC3261 that the To tag in a final response matches the To 
tag from *any* provisional responses (while section 8.2.6.2 says "The same tag 
MUST be used for all responses to that request", this can't be relied on for 
forked calls as multiple UAS instances are involved).

Note that this bug could occur even for calls that aren't forked by a proxy if 
the UAS uses fake forking (one real-world UAS does this to provide different 
SDP answers in provisional and final responses).

Original issue reported on code.google.com by Thomas.M...@telsis.com on 13 Nov 2013 at 3:32

[GoogleCodeExporter]

Did you set the SIP Stack property gov.nist.javax.sip.MAX_FORK_TIME_SECONDS to 
a value greater than 0 (10 by example) ?
If so can you provide the logs with org.mobicents category at DEBUG level 
against the latest from 
https://mobicents.ci.cloudbees.com/job/Mobicents-SipServlets-Release/lastSuccess
fulBuild/artifact/ ?

Original comment by jean.deruelle on 2 May 2014 at 8:11

[GoogleCodeExporter]

Original comment by jean.deruelle on 2 May 2014 at 8:12

• Changed state: Pending

[GoogleCodeExporter]

No Update closing. Feel free to reopen on 
https://github.com/Mobicents/sip-servlets/issues/new

Original comment by jean.deruelle on 17 Dec 2014 at 9:35

• Changed state: Invalid