Skip to main content

Re: On SIP Outbound and app composition (Re: Meeting Notes.)

  • From: "Lewis, Keith" < >
  • To:
  • Subject: Re: On SIP Outbound and app composition (Re: Meeting Notes.)
  • Date: Fri, 15 Feb 2013 10:53:37 +0000

Eric,

Some comments.

The edge proxy would normally use getPoppedRoute() rather than getInitialPoppedRoute() to get the Route header containing the flow.

In the context of a location server implemented using the procedures of RFC 5626 and a home proxy using the procedures of RFC 3327 the flow will be in the Route header.  The option of using the Request URI to pass the flow only exists in environments that have chosen not to use those RFCs.

Applications should not re-push popped routes doing so will usually cause the call to loop.

There are 2 reasons why an extra application (call it app2) is invoked ahead of the edge proxy (1) the home proxy added a route to the route set identifying app2 or (2) the local AR decided to sequence in app2.

For (1) there will be 2 route headers the first for app2 (proxy or B2B) and the second for the edge proxy - RFC 3327 section 5.4 says that a home proxy should normally add its routes ahead of the ones retrieved from the location server. By the time the call arrives at the edge proxy app its route header containing the flow wiill be the most recently popped route available via getPoppedRoute().

For (2) it is the AR that should add the popped route back into the route set. Again once app2 has propagated the request the AR will pop this route and so the edge proxy will see it using getPoppedRoute().

If the AR does not add back the route in (2) the edge proxy could still retrieve it but would need to use getInitialPoppedRoute() to do so, this is available as long as the application composition chain has been maintained by app2 by means of the CONTINUE directive (or an implicit equivalent).

Keith

On Wed, Feb 13, 2013 at 7:40 PM, Eric Cheung < " target="_blank"> > wrote:
Hi everyone

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 desired.


If I understand the agreement correctly, then I want to point out the following:

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.

Thanks
Eric


 
--------------------
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.)

(continued)

Re: On SIP Outbound and app composition (Re: Meeting Notes.)

Eric Cheung 02/11/2013

Re: On SIP Outbound and app composition (Re: Meeting Notes.)

Lewis, Keith 02/12/2013

Re: On SIP Outbound and app composition (Re: Meeting Notes.)

Eric Cheung 02/13/2013

Re: On SIP Outbound and app composition (Re: Meeting Notes.)

Lewis, Keith 02/13/2013

Re: On SIP Outbound and app composition (Re: Meeting Notes.)

Eric Cheung 02/13/2013

Re: On SIP Outbound and app composition (Re: Meeting Notes.)

Lewis, Keith 02/13/2013

Re: On SIP Outbound and app composition (Re: Meeting Notes.)

Jean Deruelle 02/13/2013

Re: On SIP Outbound and app composition (Re: Meeting Notes.)

Eric Cheung 02/13/2013

Re: On SIP Outbound and app composition (Re: Meeting Notes.)

Jonas Borjesson 02/13/2013

Re: On SIP Outbound and app composition (Re: Meeting Notes.)

Eric Cheung 02/13/2013

Re: On SIP Outbound and app composition (Re: Meeting Notes.)

Lewis, Keith 02/15/2013

Re: On SIP Outbound and app composition (Re: Meeting Notes.)

Eric Cheung 02/15/2013

Meeting Notes.

Binod 02/14/2013
 
 
Close
loading
Please Confirm
Close