If someone else found my previous post, the problem was in my reply route (which perform nathelper rtpproxing) where I was fixing the contact even for packet coming back from the registar. It caused the contact to be changed from the phone to the registrar IP, and then cause the ACK packet loop issue.
Thomas
Thomas Mangin wrote:
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
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users