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