One of the things that was requested at the start of the outbound work in Kamailio was the ability to "force" outbound even when a UA does not support it and to be able to use the outbound flow tokens for NAT traversal instead of contact aliasing on "single server" configurations.

The use-case I have for outbound involves having the edge proxies and registrars as separate devices. I don't have a need for "single server" myself at the moment. I don't mind putting a bit of extra work in to support it - but only if there is a genuine need for it and someone available to test it.

My understanding of outbound NAT traversal is that in the forward direction of the dialog the first edge proxy adds the flow token to the first Record-Route (the RR it adds) to indicate where the request came from, and the last edge proxy copies the flow token from the last Route header (as added by the registrar supporting Path) into the last Record-Route (the RR it adds). This means that the route-set for the dialog now contains two flow tokens with covers all of the information that would previously have been encoded in the Contact-URIs in the initial request and the final response to that request.

To my mind this means we need to double-RR when there is just a single proxy/registrar in use. It also means that, when there is a single proxy/registrar and the Path extension would not normally be used, we still need to do something to get the flow tokens (userinfo part of the Path-URI) into the location table so that they can be used for NAT traversal.

This means additional work will be needed for the edge proxy (in the RR module) which is the part I am working on, and the registrar which is the part others have been working on.

Regards,

Peter

what comes to single server, i.e., when edge proxy and registrar are co-located, it seems to me that nothings needs to be done. if you have two such co-located entities, they do not need to be aware of each other at all.

...

One of the things that was requested at the start of the outbound work in Kamailio was the ability to "force" outbound even when a UA does not support it and to be able to use the outbound flow tokens for NAT traversal instead of contact aliasing on "single server" configurations.

fine IF there is some advantage in putting the information in rr header instead of contact header.

The argument that was presented was that putting the information in the rr header is more aligned with published standards.

I have come across a number of devices at interconnects that incorrectly strip parameters that they do not recognise from the Contact-URI. While this is clearly incorrect behaviour on their part getting operators and vendors to fix their equipment is not always possible.

As I said, I do not have a need for this myself as I plan to use separate edge proxies and registrars - but I can see where the requirement came from.

...

To my mind this means we need to double-RR when there is just a single proxy/registrar in use. It also means that, when there is a single proxy/registrar and the Path extension would not normally be used, we still need to do something to get the flow tokens (userinfo part of the Path-URI) into the location table so that they can be used for NAT traversal.

sounds much more complicated than contact aliasing.

Indeed. But I can see where it is sometimes needed.

Peter

Peter Dunkley writes:

Just to confirm, I have no requirement at the moment for single-server outbound (I will be using separate edge proxies and registrars) so I will not be doing any work for this right now.

I plan to merge my outbound branch back into trunk in time for the code freeze. If anyone does need single-server outbound it'd be good if they could test the code then and let me know what (if anything) more is needed to support this.

i can try what happens when i register an outbound ua to a co-located outbound proxy/registrar and let you know if i see some problems.

-- juha