Re: [sr-dev] Log from outbound chat today

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