[Serusers] Where does SER get the public IP of a NATed uac from for sending as STATUS message?
Hi all
related to 0.9.1pre.
I have a problem with NATed UACs in my setup. Therefor i would like to know where SER takes the public IP of a NATed UAC from, a request is forwarded to (using the reply handler) if i call fix_nated_contact() to rewrite the NATed UACs contact header. Is it always taken form the received field in the location record?
Just for explanation: It seems that my SER does not rewrite the contact header field in the reply route when i call fix_nated_contact(). The contact header value stays the same, just before and after call to fix_nated_contact(). So i think, it could be SER does not get the correct "NAT"-information for the related enpoint and the reads a value from a request field? Anyone ever encountered a similar situation? Is there a way to get closer information on what's happening when calling fix:nated_contact() during runtime?
Thanks for you help.
Kind regards Frank
On 11-12-2005 13:34, Frank Fischer wrote:
Hi all
related to 0.9.1pre.
I have a problem with NATed UACs in my setup. Therefor i would like to know where SER takes the public IP of a NATed UAC from, a request is forwarded to (using the reply handler) if i call fix_nated_contact() to rewrite the NATed UACs contact header. Is it always taken form the received field in the location record?
From the source IP of the packet.
Just for explanation: It seems that my SER does not rewrite the contact header field in the reply route when i call fix_nated_contact(). The contact header value stays the same, just before and after call to fix_nated_contact(). So i think, it could be SER does not get the correct "NAT"-information for the related enpoint and the reads a value from a request field? Anyone ever encountered a similar situation? Is there a way to get closer information on what's happening when calling fix:nated_contact() during runtime?
Do you mean fix_nated_contact does not rewrite Contact header in 200 OK ? If this is the case then make sure that you have a reply route set and that you call fix_nated_contact from the reply route.
There is a simple example in sip_router/etc/nathelper.cfg
Jan.
Thanks for you help.
Kind regards Frank
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi Jan Hi all
I have a problem with NATed UACs in my setup. Therefor i
would like to know
where SER takes the public IP of a NATed UAC from, a
request is forwarded to
(using the reply handler) if i call fix_nated_contact() to
rewrite the NATed
UACs contact header. Is it always taken form the received
field in the
location record?
From the source IP of the packet.
Maybe my question was not asked clear enough. Just for clarification: SER receives a BYE from the called UAC and has to relay it to the calling UAC. Both UACs are natted. Now, where does SER get the public ip address from for the calling UAC that the BYE has to be relayed too? It sure can't be the source address of the received BYE request since this would be called UAC that sent the BYE. So I guess it would have to be read out from some field in the BYE request?
I'm asking this, because i have a reproducable situation with different UACs (swissvoice ip10s and patton-inalp smartnodes) where SER relays the BYE to the PRIVATE ip address of the calling UAC instead to it's public ip address. With snom100 the BYE is relayed to the correct public ip addresse but to the port of the private address (meaning to port 5060). In the same BYE request i also find that the Request-Line contains the public IP address for the natted UAC (where i expected to find the private ip address) and the contact hf was not rewritten and contains the public ip address of the UAC). This is the second indication that there is something wrong with NAT handling.
The nat-related (and most other too) parts of the script are taken from the onsip getting started document. There is no firewall or SIP ALG anywhere between SER and the natted UACs. I use mediaproxy in combination with nathelper. The call is successfully established and the voice channels work both way. The only effect you get on the phone from this behaviour is, that if the callee ends the phone, the caller doesn't get informed about that (since the BYE never arrives).
Anyone has any idea what's going on in my setup? Anyone ever experience a similar situation?
I'm very thankfull for any advice, hint, whatever....
- Frank
I'm not sure if what I am saying is correct but I think the 200 OK message from the INVITE message tells the IP phone where to send the BYE and ACK messages. So, if the 200 OK message was correctly corrected by fix_nated_contact() it should work fine. But i think that Jan or another expert user could confirm this.
Jose Simoes
On 12/12/05, Frank Fischer frank.fischer@digitalnomads.ch wrote:
Hi Jan Hi all
I have a problem with NATed UACs in my setup. Therefor i
would like to know
where SER takes the public IP of a NATed UAC from, a
request is forwarded to
(using the reply handler) if i call fix_nated_contact() to
rewrite the NATed
UACs contact header. Is it always taken form the received
field in the
location record?
From the source IP of the packet.
Maybe my question was not asked clear enough. Just for clarification: SER receives a BYE from the called UAC and has to relay it to the calling UAC. Both UACs are natted. Now, where does SER get the public ip address from for the calling UAC that the BYE has to be relayed too? It sure can't be the source address of the received BYE request since this would be called UAC that sent the BYE. So I guess it would have to be read out from some field in the BYE request?
I'm asking this, because i have a reproducable situation with different UACs (swissvoice ip10s and patton-inalp smartnodes) where SER relays the BYE to the PRIVATE ip address of the calling UAC instead to it's public ip address. With snom100 the BYE is relayed to the correct public ip addresse but to the port of the private address (meaning to port 5060). In the same BYE request i also find that the Request-Line contains the public IP address for the natted UAC (where i expected to find the private ip address) and the contact hf was not rewritten and contains the public ip address of the UAC). This is the second indication that there is something wrong with NAT handling.
The nat-related (and most other too) parts of the script are taken from the onsip getting started document. There is no firewall or SIP ALG anywhere between SER and the natted UACs. I use mediaproxy in combination with nathelper. The call is successfully established and the voice channels work both way. The only effect you get on the phone from this behaviour is, that if the callee ends the phone, the caller doesn't get informed about that (since the BYE never arrives).
Anyone has any idea what's going on in my setup? Anyone ever experience a similar situation?
I'm very thankfull for any advice, hint, whatever....
- Frank
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On 12-12-2005 21:19, Frank Fischer wrote:
Hi Jan Hi all
I have a problem with NATed UACs in my setup. Therefor i
would like to know
where SER takes the public IP of a NATed UAC from, a
request is forwarded to
(using the reply handler) if i call fix_nated_contact() to
rewrite the NATed
UACs contact header. Is it always taken form the received
field in the
location record?
From the source IP of the packet.
Maybe my question was not asked clear enough. Just for clarification: SER receives a BYE from the called UAC and has to relay it to the calling UAC. Both UACs are natted. Now, where does SER get the public ip address from for the calling UAC that the BYE has to be relayed too? It sure can't be the source address of the received BYE request since this would be called UAC that sent the BYE. So I guess it would have to be read out from some field in the BYE request?
This will be the value of Contact header field from INVITE request, rewritten by fix_nated_contact. Thus you need to rewrite the Contact value of INVITE before forwarding it. The same for 200 OK if the callee is behind NAT too.
I'm asking this, because i have a reproducable situation with different UACs (swissvoice ip10s and patton-inalp smartnodes) where SER relays the BYE to the PRIVATE ip address of the calling UAC instead to it's public ip address. With snom100 the BYE is relayed to the correct public ip addresse but to the port of the private address (meaning to port 5060). In the same BYE request i also find that the Request-Line contains the public IP address for the natted UAC (where i expected to find the private ip address) and the contact hf was not rewritten and contains the public ip address of the UAC). This is the second indication that there is something wrong with NAT handling.
The Request-URI of BYE (or any in-dialog request) usualy contains the URI from Contact header from INVITE or 200 OK (depending on the BYE direction).
The nat-related (and most other too) parts of the script are taken from the onsip getting started document. There is no firewall or SIP ALG anywhere between SER and the natted UACs. I use mediaproxy in combination with nathelper. The call is successfully established and the voice channels work both way. The only effect you get on the phone from this behaviour is, that if the callee ends the phone, the caller doesn't get informed about that (since the BYE never arrives).
You should look at Contact headers of INVITE and 200 OK. This is where user agents take the URIs that will be put in BYE from. SER should rewrite them in both directions properly, otherwise the BYE would not get through, just like you described.
Jan.
-
'Jan Janak' -
Frank Fischer -
Jan Janak
-
Voipers Portugal