[SIPSERVLET_SPEC-36] Clarification on how proxy branch response(s) to subsequent requests should be handled. Created: 20/Sep/13  Updated: 24/Nov/14  Resolved: 24/Nov/14

Status: Resolved
Project: sipservlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-pfd

Type: New Feature Priority: Major
Reporter: abahl Assignee: binod
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


JSR289 is pretty clear on how to handle the virtual branch responses for Initial requests where it specifies
10.2.3 Sending Responses
From the container perspective when a response from the virtual branch is sent upstream, a derived SipSession is created for the virtual branch as per Derived SipSessions. The original SipSession associated with the incoming request corresponds to the Proxy while the derived one represents the virtual UAS..
It even discreetly defines how virtual branch response can be one of candidate for choosing best Final response , application callback and how applications can get a handle to the proxy branch associated with response

It makes sense .

But JSR289 doesn't say much about the proxy branch response created for subsequent request. usecase can be when application (proxy) wants to handle authentication for BYE request and challenge it by sending 407/BYE.

In that case it is not clear
– whether we need to create a proxy branch response or act more like a UAS?
– what getProxyBranch() api call should return for that response?
– should application get a callback for that response before sending upstream?
– should a new session be created to handle this proxy branch response or primary dialog session be used?

This is very confusing and needs some clarification.

Comment by binod [ 24/Nov/14 ]


Section 12.2.3 has been updated to clarify that virtual proxy branch only applies to initial requests. Since the specification already say that application should not proxy a subsequent proxy and that would result in an IllegalStateException, the intention of the specification is pretty clear in general.

Generated at Tue Mar 28 01:45:51 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.