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. > 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
