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: Tue, 12 Feb 2013 10:28:37 +0000

Eric,

I am thinking about the same cases as you are but proposing a different solution.

We would normally want an application composition chain to have the same effect whether the applications were on a single host or run on separate hosts. I am arguing that the situation where the registrar is on the same machine as the flow should result in the same chain of applications to handle the INVITE as when the registrar is located on a different machine.

We can imagine 3 apps running on 3 different machines.
  1. A Home (routing) proxy that runs on machine "a.com"
  2. A b2b app that runs on machine "b.com"
  3. A flow aware edge proxy that runs on "c.com".
When the REGISTER message from user "> arrives at c.com it passes it on to the Registrar including a Path of " "> " or " "> ;flow=XYZ" to indicate that calls to alice should pass through the edge proxy.

When the Home proxy receives an INVITE for alice it queries the registrar it uses the Path header to create a Route header " "> ;flow=XYZ". It may also insert Route headers to sequence the call through the b2b app " "> " and back again.

I am suggesting that the registrar should remember the flow as a Path header even if both the Registrar and Home proxy are both located on the same machine as the edge application. The RFC explicitly allows for this in section 6.

If the UAC has a direct flow with the registrar, the registrar MUST store enough information to uniquely identify the network flow over which the request arrived. ............................
The registrar MAY store this information by adding itself to the Path header field with an appropriate flow token.

On a separate issue - If a SIP container hosting several apps is acting as the edge proxy it may easier for the application router if the URI for selecting the edge proxy app was on the form " "> ;flow=XYZ" rather than " "> ". This is allowed in the RFC since it says that the flow token MAY be placed in the user part of the URI. We should not enforce a single way of encoding the flow token in the URI but leave it up to the application to make the choice.

Keith

On Mon, Feb 11, 2013 at 8:41 PM, Eric Cheung < " target="_blank"> > wrote:
Hi Keith

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.

Thanks
Eric


On 2/9/13 4:33 AM, Lewis, Keith wrote:
Eric,

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

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.

Keith



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






Meeting Notes.

Binod 02/07/2013

Re: Meeting Notes.

Lewis, Keith 02/07/2013

Re: Meeting Notes.

Jean Deruelle 02/13/2013

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

Eric Cheung 02/08/2013

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

Binod 02/08/2013

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

Eric Cheung 02/08/2013

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

Lewis, Keith 02/09/2013

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
 
 
Close
loading
Please Confirm
Close