[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty fo r 3GPP]
> > - we document a higher level solution and refer to
> SIP(PING) wg to make a generic solution
> >
> > "This section presents higher level details of a
> solution based on
> > the use of a translator and SIP ALG. [3GPPtr] provides
> additional
> > information and presents a bit different solution
> proposal based on
> > SIP Edge Proxy and IP Address/Port Mapper. The authors
> recommend to
> > solve the general SIP/SDP IPv4/IPv6 transition problem
> in the IETF
> > SIP wg(s)."
>
> Consider a slight rewording here.
>
> s/"general SIP/SDP IPv4/IPv6 transition"/"SIP/SDP signalling"/
Makes little sense since the SIP WG already has SIP/SDP signalling
specs! I think it should stay since the SIP work will be on IPv6/v4
translation.
>
> And add:
>
> NAT-PT header translation mechanism may be used in conjunction with
> the [3GPPtr] mechanism. NAT(P)T-PT will perform header translation,
> using the binding supplied by [3GPPtr].
Disagree as I explained in past emails.
>
> >
> > - because NAT-PT is the closest possible (=PS RFC)
> solution to be used in this "Interworking Unit" as a
> translator, we state:
> >
> > " We call the combined network element on
> > the edge of the IPv6-only IMS an "Interworking Unit" in this
> > document. A SIP-specific translation mechanism, which
> could e.g.
> > re-use limited subsets of NAT-PT [RFC2766], needs to
> be specified.
> > The problems related to NAT-PT are discussed in appendix A. "
>
> Replace
>
> A SIP-specific translation mechanism, which could e.g.
> re-use limited subsets of NAT-PT [RFC2766], needs to be
> specified.
>
> with
>
> A SIP-specific mechanism to handle signalling traffic,
> that would
> work in conjunction with NAT-PT [RFC2766], needs to be
> specified.
Again disagree.
The analysis draft IMO is fine as is.
/Karim