[Serusers] Where does SER get the public IP of a NATed uac from for sending as STATUS message?
11 Dec
2005
11 Dec
'05
3:34 p.m.
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
12 Dec
12 Dec
12:30 p.m.
New subject: [Serusers] Where does SER get the public IP of a NATed uac from for sending as STATUS message?
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
11:19 p.m.
New subject: [Serusers] Where does SER get the public IP of a NATed uac from for sending as STATUS message?
Hi Jan
Hi all
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 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. 
13 Dec
13 Dec
1:34 a.m.
New subject: [Serusers] Where does SER get the public IP of a NATed uac from for sending as STATUS message?
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(a)digitalnomads.ch> wrote:
Hi Jan
Hi all
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
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.
1:56 p.m.
New subject: [Serusers] Where does SER get the public IP of a NATed uac from for sending as STATUS message?
On 12-12-2005 21:19, Frank Fischer wrote:
Hi Jan
Hi all
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 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. 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.
6906
days inactive
6908
days old
4 comments
4 participants
participants (4)
-
'Jan Janak' -
Frank Fischer -
Jan Janak
-
Voipers Portugal