<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/4.4.4">
</HEAD>
<BODY>
Hello,<BR>
<BR>
When outbound is fully supported the use of received parameters on URIs and the received column in the location table will (in theory at least) be able to be deprecated. This is because all of the information that would previously have been stored in these is now in the flow-tokens in Record-Route:/Route: and Path: headers.<BR>
<BR>
The biggest thing in the way of this right now is that the current outbound on Kamailio does not contain everything it requires for single-server proxy/registrar support. What is required is:
<UL>
<LI>In configuration you must use add_path() even if you are a single-server. add_path() works on lumps so this needs to be applied before the registrar:save() function is called (I think msg_apply_changes() should do this).
<LI>The registrar module needs to be updated so that lookup(), when running as a single-server with outbound, it adds the Path: header from the location table as a Record-Route:. If there are multiple matching contacts (that is parallel forking is in use) then a different Record-Route: must be added for each parallel branch. registrar must also set $du for each branch based on the flow-token from the Path: header stored for that contact. The t_*_contacts() functions in the tm module probably require changes for this too.
<LI>This also means that, even though there is a single proxy/registrar here, there will be two Record-Routes:. The first will have been added to the dialog forming request when it arrived and will contain a flow-token pointing to the originator of the request. The second is the one added by the registrar:lookup() function which contains a flow-token pointing to the destination of the call. This means that the dialog will use a form of double-RR which the rr:loose_route() function needs to be modified to handle.
</UL>
<BR>
There are some distinct advantages to the above over contact aliasing, mainly that it should help with interoperability issues (especially with SBCs which strip and do no restore parameters they do not recognise) and it should be easier for non-Kamailio users to understand as it is standards based.<BR>
<BR>
If/when the above changes have been made I would also like to see nat_uac_test() moved out of the nathelper module and into another (perhaps siputils). This makes it easier for people to have a clear choice of NAT traversal mechanisms, SIP outbound or contact aliasing.<BR>
<BR>
Regards,<BR>
<BR>
Peter<BR>
<BR>
<BR>
On Mon, 2013-01-07 at 18:32 +0100, Andrew Pogrebennyk wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On 01/07/2013 01:29 PM, Andrew Pogrebennyk wrote:
> What I don't understand is why kamailio sets RURI of the OPTIONS message
> to value of "received" instead of the contact. I suspect a bug in the
> parser somewhere along these lines:
>
>> > rval = ul.get_all_ucontacts(buf,cblen,(ping_nated_only?ul.nat_flag:0),
This needs some overhaul. The get_all_mem_ucontacts prefers received
over contact. So what nathelper does is set Path as $du and Received as
$ru, then send it. But in case home proxy which generated the NAT ping
is sitting behind the edge proxy and the user is behind NAT, we need to
pass both Contact and Received to the edge proxy.
It looks like we (Sipwise) need to introduce a few modparams so the user
choose what to put into $ru and $du (like 1 - Contact, 2 - Received, 3 -
Path). I'm just wondering if there is anything speaking against that or
missing in the light of SIP-Outbound implementation.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<A HREF="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</A>
<A HREF="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</A>
</PRE>
</BLOCKQUOTE>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<PRE>
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
</PRE>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>