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

[Juha Heinanen]

Peter Dunkley writes:

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

according to my tests, i don't see any need to add the path header.

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

same here, i don't see a need to update registrar module.

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

again, i don't see the need.

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

there is no need to do contact aliasing or store the info in r-r header
if the outbound capable ua also supports gruu.

-- juha