Subject: RE: NAT-PT Applicabilty for 3GPP

From: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Tue, 18 Nov 2003 13:49:03 +0100

> >My point is that if we say NAT-PT is applicable for SIP then people
 > >will expect to read RFC 2766 and implement it. If they do that
 > >they are likely to implement a local pool of v4 addresses and a
 > >SIP ALG (that does SIP editing). Since SIP folks are not in favour
 > >of SIP editing I don't think we should say that NAT-PT is applicable
 > >to the SIP case. It is much cleaner to create a SIP 
 > specific solution
 > >for this case that is not related to generic NAT-PT and its 
 > problems.
 > 
 > NAT-PT RFC does not specify anything about how SIP ALG/Proxy 
 > should be 
 > implemented.
 > That could be a seperate document, if one needs it. If you 
 > want a SIP 
 > ALG/Proxy, you
 > could implement as per the SIP protocol specification and 
 > make use of the 
 > NAT-PT
 > header translator functionality to let the media pass through the 
 > translator.

The applicability draft says:

   NA(P)T-PT may be used for header translation of IMS
   media traffic...

That is different IMO from saying that a SIP specific solution may
"make use of NAT-PT header translation functionality" as you have
above which I could agree with. Also I do not think it is as simple
as implementing an external SIP Proxy according to SIP specs as you
say above, since some changes to the binding mechanism is needed in
the translator and some interactions with other e2e protocols may be
needed. Given the discussions so far I would replace the statement
in the applicability with:

   The SIPPING WG will be working on a solution to the 3GPP IMS
   translation problem which may reuse some functionality from NAT-PT.

 > So NAT-PT
 > is applicable there and that is what is noted in the applicability 
 > statement. Re-inventing
 > something that has already been done seems to be a waste of time.

Comments above. The issue is that there are NAT-PT problems that the
SIP solution should not be inheriting. But as above, let's solve this
with the SIP folks.

/Karim

---

From: Suresh Satapati <[email-masked]>
Date: Tue, 18 Nov 2003 08:17:21 -0800 (PST)

Karim,

> needed. Given the discussions so far I would replace the statement

Please spell out "some changes to the binding mechanism", and the
"interactions needed with other e2e protocols". Then we can debate.
Until then, my stance doesn't change as far as Applicability is concerned.

> SIP solution should not be inheriting. But as above, let's solve this

See above.

--
Suresh