> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Sri Gundavelli > Sent: Sunday, December 06, 2009 8:30 AM > To: Hui Deng > Cc: [email protected] > Subject: Re: [Softwires] Host based translation: v4-v6 > > Hi Hui, > > > On 12/6/09 2:18 AM, "Hui Deng" <[email protected]> wrote: > > > It's quite clear same as you said here, there are binary > codes and codec codes > > which need additioinal payment for updating, it's a > existing scenario. > > > > I do not understand this response. I'm not a codec or a DSP > expert, but I > don't see how when you change an application to use IPv6 > socket from an IPv4 > socket, the codec has to change. I assume the SDP protocol > can handle both > the versions in media description. I'm sure, some RTP, SDP or > media experts > in the list can comment on this.
Interworking IPv4 and IPv6 is most often handled, on deployed networks, using the network's SBC. Acme Packet, for example, supports interworking IPv4 endpoints with IPv6 endpoints. The IETF standard is to use ICE which allows SDP to express both IPv4 address (in the m= and c= lines) and IPv6 address (in a= lines) which provides the ideal backwards-compatibility with IPv4-only endpoints (because SDP requires that unrecognized a= lines be ignored by the endpoint). Details are in draft-ietf-sipping-v6-transition-07 (which is approved by the IESG and in the RFC editor's queue) and Section 2.1 of draft-wing-behave-nat64-referrals-01. -d > > What I don't understand is that there is the problem quite > clear need > > to be solved by someone, > > but other people don't want to solve those problem just because his > > solution doesn't support it, , > > and then they strongly prevent other people from solveing > the problem > > I don't think it is good way in IETF. > > > > No. You have to convince the WG, not me. You started the > thread, I disagreed > with this use-case and I don't believe this is a valid > requirement. But, to > take your stand for a second, even if this is real and some > how we are not > appreciating that requirement, this should be one of those > rare applications > that have to be retired. You don't change the whole host > architecture for > these one of a kind rare applications and bring all the host > change baggage. > In migration, there is a cost as well. > > Regarding your comment that I agreed offline that it is > difficult to change > legacy deployed applications. *Yes*. I'm talking about *deployed* > applications, not about future applications dealing with > future scenarios. > Please give the context along with the comment. All you need > is one line > requirement for your application developers to use both IPv4 and IPv6 > sockets for the future applications that they write, that's > all. Note, this > is not a legacy deployed application requirement, its about a future > application unable to use IPv6 transport, compiled for an IPv6-only > platform. > > Lets allow others to comment. We made our points and we are > not converging. > > > Regards > Sri > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
