> > -----Original Message----- > > From: sipping-bounces@xxxxxxxx > [mailto:sipping-bounces@xxxxxxxx] On Behalf > > Of Dan Wing > > Sent: Monday, March 09, 2009 2:17 PM > > > > Yes, that is because SIP and SIPPING documents all require ICE > > for IPv4/IPv6 interworking. Your document is a departure from > > requiring ICE, and puts the onus on the SBC to perform the > > interworking. I'm not saying that is wrong; rather, it is > > different. > > I don't believe all SIP/SIPPING docs require ICE for > IPv4/IPv6. I am only familiar with draft-ietf-sipping-v6-transition (which requires ICE) and Section 6.2 of draft-ietf-sipping-nat-scenarios which has the IPv6 host go through a NAT (a NAT64, I believe) to obtain an IPv4 address for media from a TURN server. If there are other SIP or SIPPING documents which describe the IPv4/IPv6 transition, please share. > There are two current RFC's for ANAT, which are > not deprecated (yet). I know and you know it's broken, but > the alternative for some of us is that media will simply > always be the same address family as signaling. (which is not > optimal, and it doesn't have to be that way - we can fix it methinks) > > > But for the rest of the Internet, where those assumptions > > cannot be made, I do like the *idea* of atypes, > > I'm not sure the idea of atypes is necessary or sufficient to > solve the problem. We need a form of ANAT which works with > legacy devices cleanly. Agreed. An in that regard it would be something more akin to ICE or SDP Capability Negotiation (which both work with legacy devices cleanly because they use SDP "a=" and are designed to fall back cleanly). > > but I would > > suggest some changes to it (e.g., don't use multiple m-lines > > because they cause harm. > > Yes I agree with that requirement a lot. > > > > e.g., provide a way to detect if > > a IPv4 or IPv6 path is working -- as we all know with the > > difficulties in keeping www.ietf.org working over IPv6, > > IPv6 connectivity is not yet as reliable as IPv4 connectivity.) > > 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?). You can probably more likely expect to receive either RTP _or_ RTCP pretty soon after it feels like the call is 'established', though -- very much like the 'latching' described in the Middlebox document (draft-sipping-stucker-media-path-middleboxes). And the user reaction to installing IPv6 and suddenly receiving (or initiating) phone calls with no audio is going to be blamed squarely on IPv6. That is not appealing for the successful deployment of IPv6. Here is the conversation which we all know would occur: Bob, I just tried to call you and got no audio. Adam, I'm sorry. I recently installed IPv6. Bob, All my friends that installed IPv6 have that problem. IPv6 causes one-way audio. Can you remove it so we can use SIP? Adam, Sure thing! > It would be one thing if ICE was universally usable, but it's > not. Not for many of us. We can't force all UA's to > implement it, and many haven't; and it doesn't work for some > scenarios some people need. 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. Of course, if they just grin and expect the SBC solves the problem, we can all sleep easier at night. Well, except SBC vendors, I guess? > The IETF has never succeeded in *dictating* market forces. > We can either stick our heads in the sand and claim our > engineering principles require us to follow a specific model > we believe is right, or we can be real engineers and > incorporate customer feedback and real-world limitations into > pragmatic solutions. <cough>NAT</cough>. :-) -d _______________________________________________ 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
