> 1) The ICE model fundamentally doesn't work for certain SIP > deployment types. The problem is that in some call > scenarios, a UA cannot get usable IP:port candidates which > can reach or be reached from another UA. This was one of the > missing pieces of TURN: SBC's don't always assign the UA > public IP:ports on the other side of their relay. They > assign IP:ports based on where the SIP call *goes*, which > often is in fact a private IP:port pair on the other side of > the relay, or a whole *chain* of them. For example, the call > may well go into a VPN/tunnel/LSP/private-net, and it may > have even started in another VPN/tunnel/LSP/private-net. In > such cases, the ports allocated for relaying are not knowable > in advance of the call routing decision. What's worse is > that they are likely to be overlapping address spaces, or > require transcoding, or need to be RHOC'ed, or whatever. I agree that ICE uses a 'get addresses, then route the SIP message' model, whereas SBCs use a 'figure out where the SIP message is going to be routed, and choose an address suitable for that destination'. > Add on top of that, that the UA's have to support ICE to > begin with, which as I'm sure you know is still uncommon. I agree ICE is uncommon with UA's that are deployed with SBCs, and ICE is uncommon with many IP PBX vendors UAs (Cisco, Nortel, Avaya, Siemens, etc.). ICE is common with SIP UAs deployed elsewhere, though -- Yahoo/MSN Chat/Google Chat all use ICE, for example. > Draft-ietf-sipping-v6-transition can recommend whatever it > wants, but that has no correlation to what may actually > occur. (not that the IETF has a bad history of v6-transition > plans or anything ;) Sure. Draft-ietf-sipping-v6-transition is in the RFC editor's queue and I agree it is already out of date. > So what we're left with is "assisted" v4-v6 interworking, > being performed by intermediaries. Yes -- either TURN-IPv6 servers, NAT64 devices, or SBCs. draft-wing-behave-nat64-referrals-00.txt describes the first two, and I have been considering adding SBCs to it. That is where I started wondering how much of draft-boucadair-sipping-ipv6-atypes is required for an SBC to perform the v4/v6 interworking. > In some cases this > function is virtually for free, because the intermediary was > relaying the media anyway for numerous other reasons; in > other cases they want to avoid relaying, or can only do v4-v6 > in a subset of intermediaries. Most SBC's have schemes to > release the media (not relay it), if it's possible and their > operators want them to, even if it crosses many SBCs; but not > all SBC's/intermediaries can do that. > > 2) Yes SBC's often assume that signaling and media have a > common address family for registered endpoints, and that > should work in most cases. The tricky part is how to deal > with dual-stack UA's, Yes, that is very tricky -- especially when they really aren't "really" dual stack (e.g., an IPv6-only endpoint with access to a NAT64; a dual-stack endpoint with IPv4-only Internet connectivity and 6to4 or Teredo). > or when a call gets routed to a proxy, > which can then route it on to gateways, media servers or > other UA's which themselves may be either IPv4 or IPv6 > capable for media. Today the SBC's typically do one of two > things: either (a) assume that signaling and media are the > same address family, or (b) offer both address families and > wait for the answer to decide which to use, and whether they > can release the media or not (if they can release media). > Option (b) is basically similar to how some devices make > transcoding decisions today, and is how one would best avoid > relaying media. The problem with (b) is that the UA has to > do ANAT, and there's a performance penalty for decomposed > system types to do this trick. > > So anyway, to accomplish (b), they can either implement ICE, > or they can use ANAT. Some day, after SDP Capability Negotiation is published and becomes available in endpoints, it can be another way of accomplishing that same result. > Honestly neither of them are very good > options currently. ICE support is minimal, and has the > problems I noted earlier (plus others). ANAT has > backwards-compatibility issues due to its syntax, or worse > call failures if the Require tag is used. Yep. > Unfortunately, > ANAT has a head-start for v4-v6 and is in fact mandated not > only by some SDO's but also by certain US Government > organizations. Yes. But that is mostly due to ICE not being an RFC at the time those standards and requirements were written. It wasn't because ANAT is superior. > I think that can be rectified, maybe, I worry we are too late to rectify it. > but > only if an alternative proposed is actually usable in practice. So -- you need a way to do v6/v4 address selection that isn't ANAT and isn't ICE. > -hadriel > p.s. I'm not saying this draft's proposal is the right > solution - just answering your questions. :) draft-boucadair-sipping-ipv6-atypes does seem to solve several problems. -d > > > -----Original Message----- > > From: sipping-bounces@xxxxxxxx > [mailto:sipping-bounces@xxxxxxxx] On Behalf > > Of Dan Wing > > Sent: Wednesday, March 04, 2009 8:29 PM > > To: mohamed.boucadair@xxxxxxxxxxxxxxxxxx; sipping@xxxxxxxx > > Subject: Re: TR: I-D > Action:draft-boucadair-sipping-ipv6-atypes- > > 00.txt > > > > > Comments are more than welcome. > > > > Hi. > > > > This draft appears to describe how SBCs can assist > IPv4-/IPv6-only nodes > > in > > communicating with each other by modifying SDP offers and > SDP answers. I > > presume this is done to avoid doing ICE on the endpoints, > even though > > draft-ietf-sipping-v6-transition says IPv6 endpoints SHOULD > implement ICE > > to > > assist with the IPv6 transition -- but I'm not sure; the > document doesn't > > discuss why the atypes is superior to ICE. I think I > understand why the > > sip.atypes media feature tag is useful (because the SBC can > only really > > know > > about the endpoint's ability to handle signaling, not > media). But is > > there > > harm in the SBC assuming the obvious -- namely, that an > incoming IPv4 SIP > > signaling connection from an endpoint means the endpoint > supports IPv4 > > media, > > and that an incoming IPv6 signaling connection from an > endpoint means the > > the > > endpoint supports IPv6 media? > > > > draft-boucadair-sipping-ipv6-atypes also uses ANAT > (RFC4091/RFC4092) which > > has > > two deficiencies: (a) an ANAT offer is confusing to SDP > receivers that are > > ANAT-unaware (because of the multiple m= lines some SIP endpoints > > supposedly > > reject the invitation) and (b) ANAT will be deprecated when ICE is > > published. > > > > -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
