Skip to main content

Re: SIP outbound proposal.

  • From: "Lewis, Keith" < >
  • To:
  • Subject: Re: SIP outbound proposal.
  • Date: Tue, 5 Feb 2013 13:41:24 +0000

The difference is between whether the flow token is encoded or not.
In this example the Route header is using the encoded form which is then transformed into the internal (non encoded) form.

Keith

On Mon, Feb 4, 2013 at 6:10 PM, Binod < " target="_blank"> > wrote:
In Step (4) (where is 2 and 3?), you have

        SipURI routeUri = (SipURI) req.getPoppedRoute().getURI();
        SipURI flow = sipFactory.createFlow(routeUri.getUser(), true);
        Proxy p = req.getProxy();
        p.setOutboundInterface(flow);
        p.proxyTo(req.getRequestURI());

Assuming this is a non-Register request coming from authoritative proxy to
edge proxy,

what will be the difference between

req.getPoppedRoute().getURI() and the URI returned by sipFactory.createFlow?

I thought the the top route will anyway contain the flow token in this case.

thanks,
Binod.

On Monday 04 February 2013 07:49 PM, Lewis, Keith wrote:
Binod,

Yes the formatting I show for the non-encoded case was just an example.
It would not be described in the spec.

I can see the attraction of having a new type called "Flow" but I can also see the argument advanced in SIP_SERVLETSPEC-16 for having a single type that can represent all preferences for outgoing interfaces/connections.

The main thing for me is (1) reuse the method name "setOutboundInterface()" and to allow it on Session, ProxyBranch and Proxy and (2) provide flexibility by allowing the application to control what is placed in the Path header.

Thinking further about the representation of flows I suppose that it would be good to always use a readable format internally so that it can be used in log messages etc.

This would result in the following code fragments.

Step (1):

        SipURI flow = req.getFlow();
        Proxy p = req.getProxy();
        p.setAddToPath(true);
        SipURI pathURI = p.getPathURI();
        pathURI.setObParam(true);
        pathURI.setUser(flow.toFlowToken(true));
        p.proxyTo(req.getRequestURI());


where the method toFlowToken(boolean encoded) can return the token either encoded or not.

Step (4):
        SipURI routeUri = (SipURI) req.getPoppedRoute().getURI();
        SipURI flow = sipFactory.createFlow(routeUri.getUser(), true);
        Proxy p = req.getProxy();
        p.setOutboundInterface(flow);
        p.proxyTo(req.getRequestURI());


where the method createFlow(String token, boolean encoded) can take either an encoded or un-encoded token. The flow variables above could be of type Flow if we prefer.

I haven't considered the callback at the UA but as you say it would use either Flow or SIpURI in line with what we choose for the other methods.

Keith

On Mon, Feb 4, 2013 at 10:08 AM, Binod < " target="_blank"> > wrote:
Keith,

I was hoping to have better typing there
with an explicit Flow interface, though it is not a strong
opinion in this case. Lets see what other EG members
say.

Some questions.

<snip>

or if encoding is not used the flow token might be (using the formatting as remote-addr,remote-port/local-addr,local-port)

sip:192.168.2.78,12345/192.168.8.102, " target="_blank"> ;ob
</snip>

I doubt you mean to put this in the spec, right? We will simply point
to a flow token in RFC 5626.

Just so that we are in the same page, the UAC FlowListener also would take
SipURI as parameter?

interface FlowListener extends java.util.EventListener{
    void flowFailed(FlowEvent event);
}

interface FlowEvent extends EventObject {

    SipURI/Flow? getFlow();

    SipApplicationSession getSipApplicationSession() ;
}

thanks,
Binod.

On Friday 01 February 2013 10:16 PM, Lewis, Keith wrote:
Binod,

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.

sip:VskztcQ/ " target="_blank"> ;ob


or if encoding is not used the flow token might be (using the formatting as remote-addr,remote-port/local-addr,local-port)

sip:192.168.2.78,12345/192.168.8.102, " target="_blank"> ;ob

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
  1. A flow token will be placed into the PATH header by the edge proxy when the registration is passed on to the registrar.
  2. The registrar remembers the path.
  3. 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.
  4. 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();
        p.setAddToPath(true);
        SipURI pathURI = p.getPathURI();
        pathURI.setObParam(true);
        pathURI.setUser(flow.getUser());
        p.proxyTo(req.getRequestURI());


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();
        p.useConn(m);
        p.proxyTo(req.getRequestURI());

I suggest that we use the following instead

        SipURI routeUri = (SipURI) req.getPoppedRoute().getURI();
        Proxy p = req.getProxy();
        p.setOutboundInterface(routeUri);
        p.proxyTo(req.getRequestURI());


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.

Keith

On Wed, Jan 30, 2013 at 10:24 AM, Binod < " target="_blank"> > wrote:
Hi,

At the F2F, we were leaning towards an API in the SipServletRequest to enable
SIP Outbound specification.

i.e. SipServletRequest.reuseConnection();

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

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


So, I am wondering, if we should also allow a way for application to handle this usecase.

Eg:
Flow flow = SipServletRequest.getFlow() //Application retrieve the flow for later use.
ProxyBranch.useFlow(flow); //so that, application can choose flow without depending on a
path/route header.
SipServletRequest.send(flow); //For a server side UA to send a request on a flow.

Let me know what you think.

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.





 
--------------------
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: SIP outbound proposal.

Lewis, Keith 02/01/2013

Re: SIP outbound proposal.

Binod 02/04/2013

Re: SIP outbound proposal.

Lewis, Keith 02/04/2013

Re: SIP outbound proposal.

Binod 02/04/2013

Re: SIP outbound proposal.

Lewis, Keith 02/05/2013

Re: SIP outbound proposal.

Jean Deruelle 02/06/2013
 
 
Close
loading
Please Confirm
Close