[OpenSER-Users] Problem using path module - sr-users

30 May 2008

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