Skip to main content

Re: Sip Outbound - generation of Path header

  • From: Binod < >
  • To:
  • Subject: Re: Sip Outbound - generation of Path header
  • Date: Fri, 15 Feb 2013 10:25:19 +0530

Hi Keith,

<snip>
In 5.1 it says that it is mandatory to place the flow token somewhere in the Path header but it is up to the developer to choose where - use of the user part is a MAY not a SHOULD or MUST.
</snip>

I agree that If the RFC allows the flow token to be placed somewhere, then we need to make sure
that our design should accommodate that.

And if I understand your design correctly, request.getFlow returns a non-encoded string and the
specification will not explain what would constitute that string. Right?

However, I still like to make it easy for those developers who might be fine with the encoding
that the application server can provide. So, at a minimum, we could also allow the application to
obtain an encoded flow token from the request.

thanks,
Binod.

On Thursday 14 February 2013 07:11 PM, Lewis, Keith wrote:
" type="cite">Hi all,

From yesterday's discussion we agreed on using the flow token to identify the flow - that sounds fine.
I assume this will be a java String.

We also talked briefly about using the same mechanisms for both the edge proxy and local registrar i.e. getFlow() and useFlow (a.k.a useConnection).

I would like to return to the question of how much control the edge proxy application is given in generating the Path header.
We did not have time to discuss this.

I still think that it would be good for the application to choose whether to place the flow token in the user part or a parameter.
When processing a route header containing a flow token we were expecting the developer to extract the flow token using existing methods.
By symmetry it would seem good to have the developer add the flow to the Path header using just the existing methods (except for the addition of setObParam).

Here is my suggestion for the doRegister() method at the edge proxy.

doRegister(SipServletRequest request) {
  Proxy proxy = request.getProxy();
  ProxyBranch proxyBranch = proxy.createBranch(
req.getRequestURI());
  proxyBranch.setAddToPath(true);

  // add the flow token and an ob param to the Path header
  String flow = request.getFlow();
  SipURI pathURI = p.getPathURI();
  pathURI.setUser(flow);
  pathURI.setObParam(true);

  proxyBranch.start();
}

This can be compared with the code in Jean wrote up from the F2F in the email below.

The code above would put the flow into the user part of the URI - which is what is suggested by RFC.
If there are multiple apps running on the same machine the URI will often to be used by the application router to select the application to run.
It might use the user part to identify the app e.g. if the user is "edge" run the edge proxy but if it is "app2" run that.
It this environment it might be convenient to use a Path header of the form " ">sip: ;flow=XYZ"

Here is the code that would do that.

doRegister(SipServletRequest request) {
  Proxy proxy = request.getProxy();
  ProxyBranch proxyBranch = proxy.createBranch(
req.getRequestURI());
  proxyBranch.setAddToPath(true);

  // add a user, the flow parameter and an ob param to the Path header
  String flow = request.getFlow();
  SipURI pathURI = p.getPathURI();
  pathURI.setUser("edge");
  pathURI.setParameter("flow", flow);
  pathURI.setObParam(true);

  proxyBranch.start();
}

Although the F2F code is shorter it would restrict us to a single method of encoding the Path header.
There seems to be no standard encoding that will suit all users so I am suggesting that we allow the application developer to decide.
This would be consistent with the rest of the SipServlet spec which makes no assumptions about how the URI will be used (except for the standard parameters - transport, maddr etc).
The RFC has many examples showing the flow in the user part but the text only makes this as a suggestion.
In 5.1 it says that it is mandatory to place the flow token somewhere in the Path header but it is up to the developer to choose where - use of the user part is a MAY not a SHOULD or MUST.

The doInvite() method would be coded based on the URI layout chosen by the developer.
The same app would typically add the Path Header and decode the Route header so there should be no difficulty in having the method used be a decision taken by the developer of that app.
The code Jean shows below would be appropriate if the flow token is in the user part.
The only change might be the name of the method - perhaps useFlow() is better.

I suggest that we should not have a "reuseConnection" method.

The resulting set of methods would be
  • String getFlow() - get the flow token for a message.
  • void useFlow(String flow) - select the flow for a session, proxyBranch or Proxy.
  • a method to allow a UAC to indicate that a flow should kept alive.
  • a method that can be used by either a UAC or an edge proxy to request a callback on flow disconnection.
Keith

On Wed, Feb 13, 2013 at 2:09 PM, Jean Deruelle < " target="_blank"> > wrote:
Hi Keith,

Sorry for the late reply here :
The F2F proposal that was agreed upon IIRC and from the pictures in https://docs.google.com/document/d/1_XG3HWf5bqWVDP3ZRY6NdJG_gTDXxqMd9ErwIqpBlMk/edit?usp=sharing :

To use the following for REGISTER

doRegister(SipServletRequest request) {
  Proxy proxy = request.getProxy();
  ProxyBranch proxyBranch = proxy.createBranch(<URI to proxy to>)
  proxyBranch.getRequest().reuseConnection();
  proxyBranch.setAddToPath(true); // generate the Path header containing the flow token on start() below since reuseConnection was called
  proxyBranch.start();
}

On receiving a request (let's assume INVITE) with the flow token in the Route Header the application would do the following :

doInvite(SipServletRequest request) {
  Address route = request.getPoppedRoute();
  String user = ((SipURI)route.getURI()).getUser();
  Proxy proxy = request.getProxy();  
  ProxyBranch proxyBranch = proxy.createBranch(<URI to proxy to>)
  proxyBranch.useConnection(user); // container decodes the flow token and use that flow for all subsequent requests
  proxyBranch.start();
}


Jean


On Thu, Feb 7, 2013 at 10:46 AM, Lewis, Keith < " target="_blank"> > wrote:
Binod,

Sorry that I was late joining the meeting.
As a result I probably missed a discussion of the edge proxy use cases for Sip Outbound.

Later in the discussion we talked about providing a set of API methods and letting the application make the decisions. I was therefore surprised to see the summary saying that the container will do most things automatically.

We seemed to have no problem with the local registrar case - just need to decide the method names and data types to use. Your notes give an indication of the direction we are taking for this.

Could someone (perhaps Jean) write up the code samples for what the edge proxy will do to (a) generate the Path header containing a flow token and (b) process a Route header containing a flow token, these are the cases where it is less obvious how responsibilities will be split between the container and the application and what the API should be. It may be very similar to what was proposed at the F2F but having it written down will help to crystallise where we are in the discussion.

At a future meeting it would be good to discuss SIP_SERVLETSPEC-16 and decide whether we will implement it. There may be some linkage with the naming and types used for the "setFlow" method.

Keith


On Thu, Feb 7, 2013 at 4:49 AM, Binod < " target="_blank"> > wrote:
Attendees:   Tom, Eric, Keith, Brian, Jonas, Nitzan, Jean, Binod (Sorry, if I missed anyone).

SIP Outbound.
-------------------
- Here is what I think we had consensus on.
- Use a simple form of api, where container do most of the work on the same lines
  as we decided on F2F. We will augment that with an API that allow application (registrar)
  to directly handle the flow.
- So, application will call SipServletRequest.setReuseConnection (feel free to suggest name changes)
  to indicate to the container that it handle RFC 5626 for various kind of sip entities.
- Application can use methods like SipServletRequest.getInitialRemoteSipURI and getLocalSipURI
  to obtain an identity of the flow as per Jean's proposal.
- Application can later on use session/proxy/proxybranch.setFlow(initialRemoteSipuri, localSipURI)
  to elect that flow and we will not use setOutboundInterface for the same.
- From an application composition perspective, it is similar to 14.2.1 of the spec.
     o The settings of the last proxy application in a chain that used the outbound apis will be used
        by the container and that will override any previous settings.
     o If the chain contains a UAS, then the previous settings will not be relevant anymore to the remaining
        applications.
- The FlowEventListener (may be name it a callback?) can be set on the register request by the application.
- The FlowEvent will only return SipURIs.

SIP Servlet POJO.
-----------------------
- We did not conclude the discussion on this topic.
- There is one suggestion from EG to use a Matcher sort of mechanism to match the requests based
  on request uri etc (similar to the mechanism used in servlet mapping).
- Binod to continue incorporate Matcher to the design.

thanks,
Binod.



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






Sip Outbound - generation of Path header

Lewis, Keith 02/14/2013

Re: Sip Outbound - generation of Path header

Binod 02/15/2013

Re: Sip Outbound - generation of Path header

Lewis, Keith 02/15/2013

Re: Sip Outbound - generation of Path header

Binod 02/15/2013

Re: Sip Outbound - generation of Path header

Lewis, Keith 02/15/2013
 
 
Close
loading
Please Confirm
Close