[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: on NAT-PT
>
> The SIP proxy gets a request which contains some IP addresses and port numbers
> for the media. It needs to pass that along - perhaps replacing the IP addresses
> and port numbers in the process. This happens long before the media stream
> starts. This the SIP proxy needs to know what the IP address and port number
> mapping will be in the "NAT" before the SIP handshake completes.
>
> Thus this is not a NAT that creates state with IP/port mappings
> based on observing data packets - it is a box which creates this state based
> on interaction with the SIP proxy. In essence it becomes a slave of
> the SIP proxy.
My understanding is that if you have to seperate the SIP ALG functionality
from the translator, the seperated box with the ALG will translate the SIP
control messages as well the header. All the control messages will be
directed to the translator which has the SIP ALG intelligence and all the
media will go through the stateless translator, because the SIP ALG would
have translated the media address in the payload with a different prefix
which is the prefix of the translator.
Senthil
>
> Does anybody on the list know enough about SIP to say whether the above
> makes or does not make sense?
>
> Of course, folks could build a single box with this functionality
> - NAT(-PT)
> - SIP proxy
> - SIP proxy controlled IP/port mapper
> but you can't just have an independent SIP proxy and NAT(-PT) box do this;
> significant interfaces would be needed between the SIP and NAT functionality.
>
> Hence NAT-PT by itself isn't useful here.
>
> Erik
>
>
>