[OpenSER-Users] Problem using path module

[Thomas Mangin]

Hello,

I am trying to configure a number of openser servers.

I have the following testbed:

Phone1 + Proxy - Registrar - out proxy
Phone2/

The Proxy acts as outbound proxy for customers and uses ienum to route 
messages to the right registrar (using user at domain), the registrar then 
figures out where the destination is and sends the packet out to 
ENUM/PSTN or in my case back to the same proxy.

The proxy is running nathelper (and redirects rtp to an rtp proxy) and 
performs route-recording.

The proxy configuration has:

modparam("path", "use_received", 0)

and the registrar configuration contains:

modparam("registrar", "use_path", 1)
modparam("registrar", "path_mode", 0)
modparam("registrar", "path_use_received", 1)

When registering all is fine and well and the packet flows like:

Phone<X> -> Proxy -> Registrar (storing in DB) -> Proxy -> Phone<X>

and the DB contains in path:
<sip:ProxyIP;lr;received=sip:PhoneIP:PhonePort>

However, when performing an invite the ACK packet (INVITE/OK/ACK) can 
not be routed properly as it is not part of the transaction, which 
causes the call to be cancelled after a few seconds (as it should be 
given the constance).

The ACK packet starts as
URI:     <sip:user@<Registrar IP>:5060;rinstance=xxxxxx>
Contact: <sip:user at PhoneIP:PhonePort>

with the IP and Port correctly translated from the internal to the 
firewall external.

It then travels like this:

Phone1 -> Proxy -> Registrar > Proxy <stop here>

When leaving Registrar the ACK URI has been changed to the one stored in 
the DB path field ie: <sip:ProxyIP;lr;ftag=yyyyyy>

at that point the Proxy is not able to figure out where to forward the 
packet even if the Contact field of the packet is still correctly set to 
the IP:Port of the phone to be reached.

I was wondering if I am missing some understanding of how RFC3327 is 
working.

I can see a few possible solutions:
- generate a first Path header with the Phone information on the proxy 
before the current one.
- try to catch those 'out of transaction ACK' and set the URI to the contact

But before doing anything I would appreciate if someone could let me 
know if I am attempting something idiotic from a design point of view 
and tell me why what I expected to 'just work' does not behave as expected.

Thank you very much your your time and help.

Thomas