Hi Daniel, please let me some time to properly reply to your mail. I will come back soon with a response.
Cheers.
2012/8/8 Daniel-Constantin Mierla miconda@gmail.com:
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 :-) )...
- 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).
- 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
- 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.
- 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.
- 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@torreviejawireless.org:
2012/8/8 Olle E. Johansson oej@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:
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@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
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev