Skip to main content

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

  • From: Jonas Borjesson < >
  • To:
  • Subject: Re: On SIP Outbound and app composition (Re: Meeting Notes.)
  • Date: Wed, 13 Feb 2013 09:00:16 -0800

I agree with Keith. If you put a B2BUA between the app that knows the
flow then you are essentially breaking the flow and as such, you have
to start over. Also, if you break up the two applications and deploy
them on different containers, you will get a different behavior, which
IMO is a bad thing.

/Jonas

On Wed, Feb 13, 2013 at 8:54 AM, Eric Cheung 
< >
 wrote:
> Hi Jean
>
> Right, if an app further downstream changes the Request-URI, i.e. changes
> the destination of the request, then the flow previously set is no longer
> applicable.
>
> I think the container needs to store which Request-URI a flow is associated
> with for other use cases as well, for example if an app is acting as edge
> proxy and is invoked on an INVITE request by virtual of the Path/Route
> header mechanism, but a SIP entity upstream has modified the Request-URI to
> a different destination.
>
> Thanks
> Eric
>
>
>
> On Wed, 13 Feb 2013, Jean Deruelle wrote:
>
>> Eric,
>>
>> I'm not sure we should actually enforce that rule as the next application
>> in chain (App B) might be a B2BUAor proxy app that redirects to a
>> voicemail
>> application or another service in a different server (by example because
>> the user is unavailable or asked the call to be redirected because he is
>> in
>> a meeting) and as such using the proxied request would not be able to
>> reach
>> the desired service if the flow is used from the first app ?
>>
>> Jean
>>
>>
>> On Wed, Feb 13, 2013 at 1:09 PM, Eric Cheung
>> < >wrote:
>>
>>> Hi Keith
>>>
>>> Got you :)
>>>
>>> I do not believe we should restrict how deployers compose applications.
>>>  Rather we should allow as much flexibility as possible. There are also
>>> existing deployments where the application that queries the registrar and
>>> sends a request, and then the AR selects further applications in the
>>> chain
>>> before the request goes out.  This works perfectly fine before SIP
>>> Outbound.  With my proposal, after the registrar is upgraded to be
>>> flow-aware and the routing app is upgraded to do setFlow(), it should
>>> continue to work.  If we impose the restriction, then it forces a
>>> complete
>>> redesign of the deployment.
>>>
>>> Do you object to the proposal that the setFlow information passes along
>>> the chain, through proxies and b2bua, or do you just feel it is
>>> unimportant
>>> in practice?
>>>
>>> Thanks
>>> Eric
>>>
>>>
>>> On Wed, 13 Feb 2013, Lewis, Keith wrote:
>>>
>>>  Eric,
>>>>
>>>>
>>>> Sorry if I wasn't clear.
>>>>
>>>> What I am saying is that we should not encourage applications to be
>>>> designed that way.
>>>>
>>>> The app that calls setFlow() should always be the last one and it is not
>>>> difficult to arrange the application composition that way.
>>>>
>>>> A route header that includes a flow token can be used to pass the flow
>>>> token from the app that retrieves the flow information (e.g. a home
>>>> proxy)
>>>> to the app that calls setFlow() (e.g. an edge proxy app). Any
>>>> intervening
>>>> apps then just need to obey the normal rules - copy Route headers etc.
>>>>
>>>> This avoids the problem of propagating the results of calling setFlow()
>>>> and
>>>> also allows the apps to be deployed on separate machines without
>>>> affecting
>>>> the behaviour.
>>>>
>>>> Keith
>>>>
>>>>
>>>> On Wed, Feb 13, 2013 at 11:35 AM, Eric Cheung
>>>> < >**
>>>> wrote:
>>>>
>>>>  Hi Keith
>>>>>
>>>>>
>>>>> I still think we are indeed talking about different cases.  The case I
>>>>> am
>>>>> referring to is:
>>>>>
>>>>>                  INVITE           INVITE
>>>>> Flow-Aware App   ----->   (App B) ----->
>>>>> setFlow()
>>>>>
>>>>> The above chain is the same container.  Is the setFlow() information
>>>>> preserved or not when App B sends/proxies the INVITE?
>>>>>
>>>>> My proposal is that it should be, whether app B is a proxy or b2bua,
>>>>> because otherwise the request will not get to the destination UA.
>>>>>
>>>>> Thanks
>>>>> Eric
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, 12 Feb 2013, Lewis, Keith wrote:
>>>>>
>>>>>  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 
>>>>>> <
>>>>>>>
>>>>>>> **
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>> --------------------
>>>> 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/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

Meeting Notes.

Binod 02/14/2013
 
 
Close
loading
Please Confirm
Close