Frankly, I think using ICE has more changes of working than the alternatives. Go ahead and try to use ANAT with a device that supports both Audio and Video. It makes a pretty horrible SDP. On Mar09 2009 20:43 , "Dan WING" <dwing@xxxxxxxxx> wrote: >>> -----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 _______________________________________________ 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
