Skip to main content

SailFin: Record-Route issues with SIP

Posted by binod on December 18, 2008 at 9:06 AM PST

Let me explain this issue, step by step.

What is Record-Route?

A SIP proxy is a SIP application/server that proxies the SIP messages to another SIP client or Server. If such a proxy want to receive subsequent requests, it is supposed to add a Record-Route header to the SIP Message. Record-Route header contains the SIP URI representing the proxy.

Eg:
Record-Route: <sip:server10.biloxi.com;lr>,
                    <ip:bigbox3.site3.atlanta.com;lr>

A SIP Proxy in SailFin is another SIP Servlet application. The complexity of adding the Record-Route header is handled by the container. Sip Servlet Just need to do the following.

 protected void doInvite(SipServletRequest request)
        throws ServletException, IOException {

        if (request.isInitial()) {

           Proxy proxy = request.getProxy();
           proxy.setRecordRoute(true);
           proxy.setSupervised(true);
           proxy.proxyTo(request.getRequestURI()); // bobs uri          
        }

    }

What is the issue with Record-Route?

There are multiple issues with Record-Route and I am explaining the most obvious one here.

UAC (TCP) -------- Proxy (sailfin) ----------- UAS (UDP)

Lets take the above example, where one end of the proxy is using TCP transport and the other end is using UDP. Now, when a SIP server inserts a Record-Route, it can be a problem because, the transport used by the server in the Record-Route will be UDP by default. That will cause problems in connectivity with TCP endpoint. If the SIP Server uses TCP as the default, then the connectivity with UDP endpoint could create problems.

More issues regarding Record-Route and some solutions are explained in the draft RFC here.

Here is the solution...

SailFin allows the developer to add a property to sun-sip.xml to indicate a policy to resolve the Record-Route. It can be either "tcp", "udp" or "rewrite". First two are straight forward. It will use the transport as what is specified. When user specifies "rewrite", the container will intercept all the messages (both requests and responses) going to either side of the proxy, resolve the user agent's transport and rewrite the Record-Route with that transport. Following is an example sun-sip.xml snippet that shows the configuration.

<sun-sip-app>
     <property name="record-route-policy" value="rewrite"/>
</sun-sip-app>

In a future release, SailFin will also add a policy to support "double-record-route" mechanism specified in the RFC draft here.

Related Topics >>

Comments

&nbsp;Hi, I have some issue with one of the record routes ...

Hi, I have some issue with one of the record routes added to invite request by Sailfin:

Record-Route: <sips:x.x.x.x:5071;fid=server_1;lr;>

Record-Route: <sip:0DMw6pN0+BEtW2BriG3PZMLPsHN0bHM6MTk1LjExMC40MC43OjQwODkyOjg1LjIzNi4xNzQuMjY6NTA5MQ==@x.x.x.x:5070;lr>

I'm not sure but I think it's a bug, since my client uses only tls and connects only to port 5071. OK response from callee never reaches the caller, I suppose the Proxy tries to send to 5070.

Please advise.

This was done quite early in V2. I guess, any V2 build in 2009 would have it. Yes, at some point of time we will have double RR. V2 gates are closing. So, not sure, if it will make it into V2. I will try to get it in for V2.next. Hope people will be able to work with "rewrite" policy until then.

It is quite good since it is annoying for mobiles not to be able to stick to only one transport. What build of sailfin is this implemented in? It would be good if it is also possible to set this as a policy on the entire container. I guess that rewrite is more of a hack but since most people do not sign their messages it is good enough for a while. The double RR is much cleaner but I guess that it will come in 2.0?