Subject: RE: on NAT-PT

From: "Karim El-Malki (EAB)" <[email-masked]>
Date: Thu, 23 Jan 2003 14:58:28 +0100

> > The SIP proxy can handle SIP translation. However there 
 > also needs to
 > > be a translator to handle traffic (e.g. video streaming on 
 > UDP) translation.
 > 
 > But as far as I understand this space (not very far at all)
 > the box that handle the media streams need to be instructed 
 > by the SIP proxy
 > for what mappings to create - it can't just be a plain old 
 > NAT-PT box.
 > Thus it starts looking more like an UDP proxy for the 
 > purposes of carrying
 > RTP which is controlled by the SIP proxy - not a NAT-PT which creates
 > state based on the packets that fly by.

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.

/Karim

---

From: Erik Nordmark <[email-masked]>
Date: Sat, 25 Jan 2003 05:23:29 +0100 (CET)

> 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

---

From: Senthil Sivakumar <[email-masked]>
Date: Sat, 25 Jan 2003 09:39:49 -0800 (PST)

> on interaction with the SIP proxy. In essence it becomes a slave of

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

---

From: Alain Durand <[email-masked]>
Date: Mon, 27 Jan 2003 09:50:06 -0800

>>on interaction with the SIP proxy. In essence it becomes a slave of

Yes.

>>significant interfaces would be needed between the SIP and NAT functionality.

You can do that, but as Christian pointed out, this has severe limitations.

>>Hence NAT-PT by itself isn't useful here.
I would say that differently. NAT-PT by itself is not sufficient.
If we want to go that route, we need a protocol
to enable dialog between the SIP proxy and the NAT-PT boxes.
Is there something in the MIDCOM space that could be used?

    - Alain.