[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: NAT-PT Applicabilty for 3GPP
> >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