Re: On SIP Outbound and app composition (Re: Meeting Notes.)
- From: Eric Cheung <
- Subject: Re: On SIP Outbound and app composition (Re: Meeting Notes.)
- Date: Wed, 13 Feb 2013 14:40:56 -0500
To summarize today's discussion, I think we agreed that:
- the RFC-5626-aware app can retrieve the flow information (whether
opaque token, transport information in the clear, or other is TBD) from
either a location server or in the Route header. The latter can be
retrieved by getInitialPoppedRoute().
- when this app sets the flow and sends or proxies the request (exact
API is TBD), the flow information will be visible in the request itself.
The 2 mechanisms suggested on the call was Route header (Keith) or
something in the Request-URI (I assume a parameter?) (Jonas)
- Because the flow information is reflected in the request itself, the
AR can detect that a flow is set and select app accordingly.
- If there are intervening apps, they may propagate the flow information
If I understand the agreement correctly, then I want to point out the
Note that if the flow information is added as the top Route header,
which likely points to the container itself, it will be popped by the
container before invoking the AR and next app. (see JSR 289 section
5.6.3 and 15.8) Therefore, the regular B2BUA behavior of copying extant
Route headers will not preserve the flow information. It must call
oldreq.getPoppedRoute() then newreq.pushRoute(). The same applies to
proxies. It is workable but seems clumsy.
For this reason, using the Request-URI as the way to convey the flow
information seems attractive. The Request-URI typically survives
through proxies and b2buas, unless they change the Request-URI, in which
case the flow is no longer appropriate anyway.