I think we may be talking about different cases. The case I am referring to is an app acting as the registrar and routing proxy or B2BUA with a direct flow with the UA, without edge proxies, i.e. the use case in RFC 5626 sec 3.2 and 6.
This app, when routing for example an INVITE request to the UA, calls SipSession/Proxy/ProxyBranch.setFlow(), and proxies or sends the request. This request will not have a Route header, or any other indication in the SIP request itself to indicate the flow to use.
If the AR then selects one or more apps before the request eventually leaves the container. Using the rules in 14.2.1, the flow information will persist through the chain if all apps are proxy apps. But if the AR selects a B2BUA in between then using those rules, the flow information will be removed. The container will not send the request using the flow, thus likely will not get to the UA.
Under my proposal, the flow selection is preserved across a B2BUA, so can be sent out of the container eventually on the flow.
On 2/9/13 4:33 AM, Lewis, Keith wrote:
It is not clear that we need the extra rule that you suggest. Route
headers would normally be used to propagate a flow token up to the point
where the last app is reached. This app then calls setFlow. There should
not be any applications between the one that is flow aware and the flow
This would mean that the behaviour we need at a B2B app is that it
propagates the route headers from its incoming leg to the outgoing one.
If the flow aware app is a SipServlet the added consideration is the
fact that it is the app router that pops the Route header and not the
application itself. The header containing the flow token will be
available either as the poppedRoute or the initialPoppedRoute. As long
as the intervening apps use a CONTINUE or REVERSE directive the
poppedRoute will be preserved.
We could continue to impose the current rules in 14.2.1 to flows but it
is not clear that they are important in practice.
-------------------- Note: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Thrupoint, Inc.
Re: On SIP Outbound and app composition (Re: Meeting Notes.)