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. 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. 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 ;) So what we're left with is "assisted" v4-v6 interworking, being performed by intermediaries. 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, 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. 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. 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. I think that can be rectified, maybe, but only if an alternative proposed is actually usable in practice. -hadriel p.s. I'm not saying this draft's proposal is the right solution - just answering your questions. :) > -----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
