Re: SIP outbound proposal.
- From: "Lewis, Keith" <
- Subject: Re: SIP outbound proposal.
- Date: Fri, 1 Feb 2013 16:46:29 +0000
I agree that we will need to support the use case you mention and the methods you describe would do that.
I also think it is good that you are proposing generic methods to allow applications to interact with flows.
Applications can then use these enablers to not only
implement the requirements of RFC 5626 but also can satisfy other use cases not covered by that RFC.
I would like to suggest a change in method names and the types used.
It seems that new mechanism we need for selecting a flow to use for an outbound request is not very different from the applications point of view to what we already have described in section 14.2 of the 289 spec. I expect that we will want to update that section to describe the selection of a flow to use for an outbound request. The behaviour described in 14.2.1 regarding application composition would also apply I think to flows.
I wonder whether it would be good to make the link with 14.2 explicit by using the setOutboundInterface() method to specify which flow to use. I notice that in JIRA SIP_SERVLETSPEC-16
Jean suggests adding an override to setOutboundInterface() to allow it to take a SIP URI. Under this proposal it would be possible to specify that outbound request should use a network card with IP address 192.168.8.102 by using a URI sip:192.168.8.102
If we could represent a flow as a SIP URI we would have a unified way of representing both flows and interfaces. RFC 5626 already defines a way of representing a flow in Path and Route headers - it places the flow token in the user part and adds an "ob" parameter e.g.
or if encoding is not used the flow token might be (using the formatting as remote-addr,remote-port/local-addr,local-port)
The SipServletRequest.getFlow() method could return a SipUri suitable for passing to the setOutboundInterface() methods of Proxy, BranchProxy and SipSession The ob parameter would indicate that the URI represents a flow and the user part would contain the flow token, the host part of this URI (example.com
) would be ignored.
The format used for the flow token part of the URI would be container specific, some containers may want to have a configurable option to select whether to encode the flow token or not.
In the scenario with no edge proxy this would result in the following example code at the Registrar/Home proxy. It is very similar to Binod's but using SipURI instead of the new "Flow" type.
SipURI flow = request.getFlow(); // called by the registrar and stored
proxy.setOutboundInterface(flow) // used later when processing an INVITE
At the F2F we discussed the case of an edge proxy. Here the sequence is
- A flow token will be placed into the PATH header by the edge proxy when the registration is passed on to the registrar.
- The registrar remembers the path.
- When a INVITE is processed by the home proxy it will retrieve the path from the registrar and use it to add a route containing the same URI as it found in the path.
- When the invite arrives at the edge proxy the route is popped then the flow token is retrieved and used to select the flow to be used to pass on the INVITE.
At the F2F there was a suggestion of using reuseConnection() in step (1) . We could use the following instead
SipUri flow = req.getFlow();
Proxy p = req.getProxy();
SipURI pathURI = p.getPathURI();
this is slightly more long winded but does not rely on any container magic add the flow token to the PATH header. It would require us to add the setObParam method and to allow setUser() to be called on the pathURI.
We had a sketched out a method for step (4) at the F2F. It is in the notes at the bottom left of the photo of the complete board but is not very readable. Here is what I think it said
SipURI routeUri = (SipURI) req.getPoppedRoute().getURI();
String m = routeUri.getUser();
Proxy p = req.getProxy();
I suggest that we use the following instead SipURI routeUri = (SipURI) req.getPoppedRoute().getURI();
Proxy p = req.getProxy();
Here I am exploiting the fact that the URI scheme used for flows is compatible with the form used in Path and Route headers in RFC 5626. Other secenarios may need explict manipulation of the URIs.
The reuseConnection() method would still be needed at a UA to indicate that keep-alives should be sent on the connection over which the request is sent. It may be good to wait for the response to the REGISTER before issuing this method - that is when we know that we need the connection to be persisted.
On Wed, Jan 30, 2013 at 10:24 AM, Binod <
At the F2F, we were leaning towards an API in the SipServletRequest to enable
SIP Outbound specification.
This would enable different capabilities.
1. For a UAC, it would do necessary client side procedure as per RFC 5626.
2. For an edge proxy, for register requests, it would add a path header with a flow token.
3. For an edge proxy, for a non-register request, it would instruct the container to locate
the flow as specified in the route header.
However, RFC 5626 does not prevent prevent Registrar/Proxy to directly handle the
flow logic completely, without having an edge proxy in between. For example,
section 6 of 5626 says
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.
So, I am wondering, if we should also allow a way for application to handle this usecase.
Flow flow = SipServletRequest.getFlow() //Application retrieve the flow for later use.
ProxyBranch.useFlow(flow); //so that, application can choose flow without depending on a
SipServletRequest.send(flow); //For a server side UA to send a request on a flow.
Let me know what you think.
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.