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

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(a)aliax.net>