[sr-dev] [SR-Users] Outbound and Registrar. No binding update

[Daniel-Constantin Mierla]

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 at 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 at aliax.net>
>>
>

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw