Hello,
On 7/30/12 6:51 PM, Peter Dunkley wrote:
Hi Iñaki,
I'll stop using the mangling and aliasing as soon as Kamailio supports Outbound. But for now... it works :-)
for such scenario, the gruu support is enough -- the problem is selecting the right destination address in case of natted contacts. This gruu extension is implemented in kamailio, but the big problem is client side support -- very few SIP soft/hard phones implement it.
From the outbound, the missing part is automatic failover over multiple streams (i.e., same sip instance but different reg-id values) -- this is related to the situation when same UA registers via multiple paths in order to be reachable when one path is down (say reg-id=1 main one is not working, then try flow with reg-id=2 even for requests within dialog) . It might be possible to be done via config file operations, by serializing branches, although never tried, some pieces might still be needed to be coded. Registering multiple flows is already possible at this time, the key being (sip.instance, reg-id) when gruu is enabled and supported by UA, advertised in the headers.
There is one situation that will not work even with gruu/ob -- in sip a phone can call without registering. A gruu contact is obtained via registration and then used for next requests by UA itself. By calling without registering, there is no gruu contact for it, so adding the src ip and port as alias parameter is still needed. I don't remember I have seen any rfc making registration mandatory before calling.
In other words, just to summarize the gruu versus contact aliasing. Gruu allocates an unique token for a SIP UA, mapping it to location record where source ip and port are stored in memory/database, then looked up when needed based on this token (even for request within dialog the lookup() function has to be executed). Contact aliasing is storing the source ip and port as a parameter to contact header to be processed from the request itself, where it will be part of R-URI for requests within dialog.
Cheers, Daniel
Peter
2012/7/30 Peter Dunkley peter.dunkley@crocodile-rcs.com
With these changes (and a client that supports it) should I now be able to use WebSockets without the aliasing from nathelper?
Hi, there should be no difference with the case of SIP over TCP or TLS. The main benefict of using Outobund and GRUU in clients (with reliable transport such as TCP/TLS/WS) is that when the UA is in an active dialog and its connection is closed, it can re-register (using a GRUU Contact), replace the previous binding in the registrar, and when an incoming request from the dialog peer arrives to the registrar it chooses the last created binding for that GRUU Contact, so the request arrives to the UA even through its new connection.
BTW I *hate* Contact mangling and Contact aliasing, that's an ugly mechanism. Outbound solves that perfectly.
Regards.
-- Iñaki Baz Castillo ibc@aliax.net