[sr-dev] Log from outbound chat today

[Daniel-Constantin Mierla]

Hello,

couldn't make it to irc, having other meeting to attend, but here are 
some comments (and hopefully some clarifications regarding some existing 
mechanisms, if I am not the confused one :-) )...

1) There is a confusion induced by the mechanisms of [contact] aliasing 
and adding 'received' to Path

In fact it is quite the same mechanism, or at least serving the same 
purpose, but developers took different namings (iirc, Andreas did Path 
and Juha contact aliasing). What these two things mean:

- contact aliasing: add source ip/port/proto as alisas parameter to 
contact header URI in an 'encoded' format
- add path received: add source ip/port/proto as received parameters to 
Path header (stored in sip uri format)

These IP/port/proto are carried in next requests either in r-uri or in 
route headers and they are used to decide where and how to forward the 
requests:

- by using handle_ruri_alias() to decode ip/port/proto and set as 
outbound proxy address
- by using loose route which puts priority on received parameter as next 
hop as opposite to r-uri or next route

Then, if it is TCP/TLS they (ip/port/proto) are used to search in open 
connections lists to see if there is one matching in order to reuse it 
-- opening a new connection is a matter of config (global options or 
function calls).

If it is UDP/SCTP will be simply used as outbound proxy address (next 
hop to send to).

2) 3.3.x can store the contact based on +sip.instance and reg-id, so 
registering via multiple flows is possible -- haven't tried, lack of 
such clients, but it was coded and worked with one flow

3) lookup location is always retrieving all the contacts, even if (the 
classic) q is different and implicitly does parallel forking. To turn it 
in serial forking, addition load_contact() have to be used, followed by 
next_contacts() in failure route:

http://kamailio.org/docs/modules/3.3.x/modules/tm.html#id2550969

I think the mechanism can be reused for flows, maybe adding a parameter 
to this functions to say we look for next q or next flow.

4) What is named as flow token in Outbound, seems to be the value for 
'alias' or 'received'. It can be an opaque value hiding these attributes 
in an internal storage or just set there in a specific format. The 
solutions we have now came based on needs, before outbound rfc was 
released (2009 vs path module in 2006).

But I think we should update to standard param names, if they are 
defined now by IETF.

I would _not_ go for an opaque value, because that will require storage 
(and replication for shared IP deployment) on edge proxy. Eventually 
mask it with a key not to reveal it in clear.

As I see it right now, for the edge proxy the mechanism is pretty much 
implemented -- it may require some adjustments with parameters and the 
value.

5) TCP connections have an internal unique ID (integer), but I still 
think ip/port/proto is still the best (reliable) to use, because the 
client can reconnect using the same local socket in its side upon broken 
connection and it may get different ID in kamailio.

I understand that in Outbound specs is required to re-register in such 
case, which is great IMO, but I do not want two mechanisms to search the 
connection, provided that we still need to support devices that do not 
do Outbound (like we are able to do it right now).

Also, the ip/port/proto is universal solution, even for UDP and SCTP 
which don't do connections.

Cheers,
Daniel

Cheers,
Daniel

On 8/8/12 3:06 PM, Olle E. Johansson wrote:
> 8 aug 2012 kl. 14:56 skrev Iñaki Baz Castillo:
>
>> 2012/8/8 Victor Seva <linuxmaniac at torreviejawireless.org>:
>>> 2012/8/8 Olle E. Johansson <oej at edvina.net>:
>>>> This is for documentation, copied from my chat client as raw text. A bit messy, but it's all there.
>>> Attached my irclog. I think it's more clear to read.
>> irclog published in my web server:
>>
>> http://public.aliax.net/irc-sr-dev-outbound.txt
> Ok, we now have it in all possible formats. We're open for questions, corrections and additional opinions on the content discussed!
>
> /O
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

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