[sr-dev] Log from outbound chat today

[Iñaki Baz Castillo]

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 at 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 :-) )...
>
> 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
>
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev



-- 
Iñaki Baz Castillo
<ibc at aliax.net>