Subsequent proxyTo() calls cause missbehaviour

[horacimacias]

Using restcomm sipservlets 4.0.125 and proxying multiple times, for example proxyTo(Bob) then wait (e.g. timeout or non-200 final response) then proxyTo(Alice) causes INVITE to be proxied correctly but responses are not presented to servlet.

I believe the issue is with finalBranchForSubsequentRequests which is not cleared on startProxy calls.
The first time proxyTo is called, startProxy is invoked and the response handling will 'see' finalBranchForSubsequentRequests being null.
The second time proxyTo is called, I believe finalBranchForSubsequentRequests should be set to null again so that the responses for that second proxy operation are routed correctly and presented correctly to the servlet.

I added the following on ProxyImpl and my application started behaving as it should:

public void startProxy() {
if(finalBranchForSubsequentRequests != null)
{
logger.info("Looks like proxy is started more than once? finalBranchForSubsequentRequests was " + finalBranchForSubsequentRequests + " but is now being set to null");
finalBranchForSubsequentRequests = null;
}

it would be good for somebody to actually re-think how proxying is handled and whether this has other side effects.

Log Time

[jaimecasero]

thanks @horacimacias for this reporting. Let me check what the Spec defiens in terms of subsequent proxyTo invocations.
Regarding the PR we need to run TCK and testsuite to check if something is broken

[horacimacias]

sounds good thanks.
In case this helps, from the JSR289 spec, section 10.2 Operation:

Until a final response is forwarded upstream, the application may invoke the proxyTo method any number of times to add additional addresses to the set of destinations the container should proxy to.

also on 10.2.4 Receiving Responses:

When an application is invoked to handle the best final response received and it is not a 2xx or 6xx, the application may add addresses for further destinations through the Proxy.proxyTo method or by creating additional proxy branches and re-starting the proxy. The effect is that a new branch is created for each additional destination, as if the method had been invoked before a (tentative) best answer had been passed to the application. If, in the upcall informing a servlet of the best response received, the servlet proxies to one or more additional destinations, the container does not immediately forward the best response received so far as the new branch may result in a “better” response. The ability to call proxyTo in the callback for best response received is useful, for example, for writing call-forward-no-answer type services.