> -----Original Message----- > From: sipping-bounces@xxxxxxxx > [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Hadriel Kaplan > Sent: Monday, March 09, 2009 9:32 PM > To: Dan Wing; mohamed.boucadair@xxxxxxxxxxxxxxxxxx; sipping@xxxxxxxx > Subject: Re: TR: > I-DAction:draft-boucadair-sipping-ipv6-atypes-00.txt > > > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > Sent: Monday, March 09, 2009 11:44 PM > > > > If there are other SIP or SIPPING documents which describe the > > IPv4/IPv6 transition, please share. > > Oh, I didn't know we had to have a separate RFC X to state > how to use another RFC Y, and that without X there was no way > to use Y. > Should we have an sdp-cap-neg-transition document too? ;) If we need one, sure. Recall the original plan for v6 was 'just install it, and everything works'. That failed. The industry has figured that out, and IETF is trying to do its part to correct that failure. > > > It turns out we have a means of detecting that already: the > > > human will hang up if they don't hear anything. But more > > > seriously, it's not like you need ICE to detect which one is > > > working either. You can use RTCP, for example. > > > > RTCP isn't sent too often or reliably, though (how is a=rtcp and > > even/odd port support working out in practice?). > > My comment was a trap actually: if you argue RTCP can't be > used for such a check because it isn't supported too often, I > can turn that argument around on ICE very easily. In fact > I'd wager there're more devices doing RTCP than ICE, by a big margin. > (How is a=candidate working out in practice? :) Not well. But a=candidate has semantics. a=rtcp in an answer doesn't indicate an RTCP is going to be sent soon or immediately. > [BTW, a=rtcp is broken and should be deprecated, as you know, > but you don't need it to use RTCP obviously] RTP/RTCP multiplexing is what all the cool kids do in 2009. > > Contrary to everyone's hopes and desires, IPv6 endpoints are not > > universally deployed. > > So getting v6 endpoints to include > > features that are necessary for a successful IPv4/IPv6 transition > > is exactly aligned with the the needs of vendors implementing > > IPv6 endpoints. > > Sure, we need to put the burden of interworking with IPv4 > legacy devices squarely on the shoulders of IPv6, no doubt. > (whether it'll be solely handled by IPv6 endpoints in all > cases is debatable, but that's orthogonal) > > But I fail to see how ICE is necessary or sufficient to fit > that bill. Either way, we need to provide IPv6 devices with > as *many* tools as possible, so that your failed-session > example does not occur. I acknowledge that SIP / SIPPING have not had a discussion of how to best accomplish the v4/v6 transition, especially in light of the failure of dual-stack hosts and in light of the emergence of IPv6+NAT44 ("dual-stack lite") and NAT64. These are all relatively 'new', of course, but we are somewhat running out of time to navel gaze. V4 addresses continue to be used up, even "due to this economic climate" (I mention that solely because I'm sure someone would tell me that the consumption of IPv4 addresses has slowed "due to the current economic climate"). > > Of course, if they just grin and expect the SBC solves the > > problem, we can all sleep easier at night. > > I didn't say that, and I don't even believe it. There are > many SIP domains which have no SBC's, and shouldn't. For > them, ICE is great. For others, not so much. We should let > the two communicate. Yes, we need the two to communicate. It sounds a lunch or bar-BoF is in order? -d > -hadriel > _______________________________________________ > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip > Use sip@xxxxxxxx for new developments of core SIP _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
