On Sun, 17 Oct 2004, Jan Janak wrote:

This is necessary for phones behind NAT. They often put IP and port which is not accessible from the public internet -- the phone is typically reachable only through the NAT-binding that was created during the registration process, that's the reason why SER rewrites the contact with the IP and port assigned by the NAT device.

according to rfc 3581, rport is specified per transaction. I understand that this magic might be useful sometimes, but in this case it actually breaks stuff since the phone doesn't receive a response on this port after the transacation has ended.

You can fine-tune this behaviour in the configuration file. SER will rewrite the Contact header field only if it detects that the phone is behind NAT (either src IP and IP in via do not match or there is a RFC1918-style IP address).

so why did it rewrite the contact header? the via and the contact was the same and no addresses used was rfc1918. can this feature be turned off?

when reading the docs, one might get the impression that this is what fix_contact() is used for but it seems (from your description above) it is performed anyway.

jakob

Here is a snippet of the configuration file:

# Special handling for NATed clients; first, NAT test is # executed: it looks for via!=received and RFC1918 addresses # in Contact (may fail if line-folding is used); also, # the received test should, if completed, should check all # vias for rpesence of received if (nat_uac_test("3")) { # Allow RR-ed requests, as these may indicate that # a NAT-enabled proxy takes care of it; unless it is # a REGISTER if (method == "REGISTER" || ! search("^Record-Route:")) { log("LOG: Someone trying to register from private IP, rewriting\n"); # This will work only for user agents that support symmetric # communication. We tested quite many of them and majority is # smart enough to be symmetric. In some phones it takes a configuration # option. With Cisco 7960, it is called NAT_Enable=Yes, with kphone it is # called "symmetric media" and "symmetric signalling". fix_nated_contact(); # Rewrite contact with source IP of signalling if (method == "INVITE") { fix_nated_sdp("1"); # Add direction=active to SDP }; force_rport(); # Add rport parameter to topmost Via setflag(6); # Mark as NATed }; };

The snippet applies fix_nated_contact only if nat_uac_test returns true. The parameter 3 tells nat_uac_test to do both -- RFC198 and via!=src IP tests.

Jan.

On 17-10 16:34, Jan Janak wrote:

On 17-10 16:27, Jakob Schlyter wrote:

...

On Sun, 17 Oct 2004, Jan Janak wrote:

...

This is necessary for phones behind NAT. They often put IP and port which is not accessible from the public internet -- the phone is typically reachable only through the NAT-binding that was created during the registration process, that's the reason why SER rewrites the contact with the IP and port assigned by the NAT device.

according to rfc 3581, rport is specified per transaction. I understand that this magic might be useful sometimes, but in this case it actually breaks stuff since the phone doesn't receive a response on this port after the transacation has ended.

Do you know any other way how to get INVITE messages to the phones behind NAT without port forwarding or similar magic ? If so please share it with me.

...

...

You can fine-tune this behaviour in the configuration file. SER will rewrite the Contact header field only if it detects that the phone is behind NAT (either src IP and IP in via do not match or there is a RFC1918-style IP address).

so why did it rewrite the contact header? the via and the contact was the same and no addresses used was rfc1918. can this feature be turned off?

Then you probably have an error in your configuration file. fix_nated_contact should be only called when one of the conditions above is true.

...

when reading the docs, one might get the impression that this is what fix_contact() is used for but it seems (from your description above) it is performed anyway.

No, this is what fix_nated_contact does. Contact will not be rewritten unless you call that function.

Jan.

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers