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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users