[sr-dev] RFC 5626 (Outbound) planned?

[Olle E. Johansson]

8 okt 2011 kl. 22:14 skrev Iñaki Baz Castillo:

> Hi, Internet is changing and now devices which are sporadically
> connected (TCP) are very common. I mean, of course, movile devices.
> 
> RFC 5626 (AKA "Outbound) is the solution for those scenarios under SIP
> protocol. Features of RFC 5626:
> 
> - NAT solved (at signaling level) without hacks in the proxy side (no
> more "Contact" replacements, please).
> 
> - Allow re-registration of a client (after loosing the TCP connection)
> by indicating the registrar to replace the previous binding with the
> new one (for this, a Contact param ";+sip.instance" and ";reg-id" are
> used). Avoid mantaining dozens of unreachable registration bindings in
> the registrar.
> 
> - RFC 5626 is for clients, outbound proxies ("edge proxies") and
> registrars (which could be behind the edge(s) proxy). Path support is
> required in both the edge proxy and registrar (already implemented in
> Kamailio!).
> 
> - If the registrar tries to route a request to a client registered
> using RFC 5626 and it gets a connection error or timeout, the
> registrar MUST remove such binding.
> 
> - If the registrar tries to route a request to a client registered
> though an outbound/edge proxy and receives a "430 Flow Failed", the
> registrar MUST remove such binding.
> 
> - The client could mantain two different registrations (by using two
> separate edge proxies that route the REGISTER to the same registrar
> behind them). Both registration have the same ";+sip.instance" value
> but different ";reg-id" value. When the registrar (or inbound proxy)
> has to route a request to that AoR, and in case there are various
> bindings with same ";+sip.instance", it just tries the one with lowest
> ";reg-id" value. If it fails (430 "Flow Failed" replied by the edge
> proxy) it would try the next one. Yeah, failover for incoming calls, a
> cool and *needed* feature now.
> 
> - When a UAC sends a REGISTER announcing support for RFC 5626
> ("Supported: outbound"), the binding matching changes: Now the
> registrar must check for other bindings with same ";+sip.instance"
> rather than matching the Contact URI (which is useless as the client
> is supposed to be natted).
> 
> 
> Some other collateral changes needed for the above to work properly:
> 
> - 430 status code MUST have less priority than any other 4XX response
> since such 430 response can only be replied by edge proxies and means
> "the TCP/TLS connection with the user is closed".
> 
> - We need two new fields in the registration backend for storing the
> ";+sip.instance" and ";reg-id" param.
> 
> - When a TCP connection is made from a client, Kamailio has to create
> a flow token identifier for such connection.
> 
> - We need a new "loose_route_outbound()" function that adds a
> Record-Route whose URI username matches the flow token associated to
> the connection from which the request comes.
> 
> - When a request arrives to Kamailio and contains a Route header
> pointing to us and containing a Route with username, then Kamailio
> must inspect the URI username to know which connection to use for
> routing such request (don't trust the RURI as it would be the private
> URI of a Contact header). Don't mangle the Contact header please, no
> more request/response mangling.
> 
> - Summarizing, RFC 5626 requires additions to:
>  - registrar module
>  - location module
>  - rr module
> 
> 
> So, RFC 5626 is the solution for lot of common problems today and IMHO
> it's a good specification. Many devices are already implementing them.
> Let's forget the "Contact mangling" hacks and other not-so-ellegant
> solutions already present in Kamailio/SIP-Router for this purpose. RFC
> 5626 was published in October 2009, it's not a new and exotic
> specification.
> 
> 
> Is there interest in implementing this? I know the specification and could help.


I agree that SIP outbound solves a lot of issues with NAT and many other things that we've been fighting
with when building SIP solutions on the Internet, outside of private networks.

Today, I think SIP outbound suffers from a chicken-and-egg issue. Since neither Asterisk nor 
Kamailio has implemented it, developers has no available reference implementation.
Open Source has a role to play as reference implementations, available for everyone.
If we start, the customers will require devices to develop this support.

SIP Outbound is intertwined with GRUU. Both of them are part of the GIN PBX registration
for multiple phone numbers that is a basis for SIP Forum's SIPconnect. 

I do hope we can find interest in this and get funding to complete SIP outbound in SIP-router.

/O