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

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

Cheers.


-- 
Iñaki Baz Castillo
<ibc at aliax.net>