[SR-Users] why use received as RURI for nathelper OPTIONS ping?

[Peter Dunkley]

Hello,

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.

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:

      * 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).
      * 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.
      * 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.


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.

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.

Regards,

Peter


On Mon, 2013-01-07 at 18:32 +0100, Andrew Pogrebennyk wrote:

> 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
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20130108/3d0039be/attachment-0001.htm>