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