30 Jul
2012
30 Jul
'12
8:18 p.m.
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
--
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
2012/7/30 Peter Dunkley
<peter.dunkley(a)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(a)aliax.net>