RE: on NAT-PT

[Erik Nordmark <Erik.Nordmark@sun.com>]

> It could also involve transport protocols other than RTP/UDP.
> Wouldn't it be just a NAT-PT having the translator part and ALG part
> separated? The ALG would be in the SIP proxy and would return
> addresses to the ipv6 host of the form PREFIX::v4_addr where the
> PREFIX belongs to the chosen translator box. So you could load share
> over multiple translator boxes. The translator would still keep state.

I don't think (but again I'm not sure) that this is sufficient for
SIP signalled media.

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.

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