> -----Original Message----- > From: mohamed.boucadair@xxxxxxxxxxxxxxxxxx > [mailto:mohamed.boucadair@xxxxxxxxxxxxxxxxxx] > Sent: Wednesday, March 04, 2009 11:09 PM > To: HKaplan@xxxxxxxxxxxxxx; dwing@xxxxxxxxx; sipping@xxxxxxxx > Subject: RE: TR: > I-DAction:draft-boucadair-sipping-ipv6-atypes-00.txt > > > Thanks Hadriel for this clarification. > > Please see inline. > > Cheers, > Med > > -----Message d'origine----- > De : Hadriel Kaplan [mailto:HKaplan@xxxxxxxxxxxxxx] > Envoyé : jeudi 5 mars 2009 08:01 > À : BOUCADAIR Mohamed RD-CORE-CAE; dwing@xxxxxxxxx; sipping@xxxxxxxx > Objet : RE: TR: > I-DAction:draft-boucadair-sipping-ipv6-atypes-00.txt > > > > > -----Original Message----- > > From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On > > Behalf Of mohamed.boucadair@xxxxxxxxxxxxxxxxxx > > Sent: Thursday, March 05, 2009 1:34 AM > > > > Med: ... atypes > > avoids also redundant inclusion of ALG/ NAT-PT nodes in the path, > > especially in the context of inter-provider communications. > > Not to disagree with your other points, but this one in > particular is not solved by atypes, afaict. The atypes info > is known only to the domain the UA registered with. When you > send a call from your domain to another provider, your proxy > won't know the final target UA's atype in advance. > > > Med: I assume that interconnection agreements are already in > place and the capabilities of the adjacent/interconnection > nodes are known to the proxy server. The invocation process > of the adaptation functions will be based on that information > and the atypes. But that means all users, belonging to another entity, would have to use the same IP address family. This prevents a graceful upgrade from IPv4 to IPv6 as the handsets/SIP UAs/etc. become IPv6-capable, as there will be unnecessary translation to the old address family (IPv4) even though IPv6 could be done end-to-end. Who would flip that configuration switch on Tuesday at 3am to declare 'most of my users are IPv6'? That's risky because it will now exercise code paths that have never been exercised. -d > In theory, if you use ANAT then your IBCF/SBC/whatever could > keep the original address family as the first ANAT group and > insert the alternate address family of the > IBGF/SBC/NAT-PT/whatever as the second ANAT group. That way > you're preferring to keep the same IP Address family, but > also offering the other one at a lower preference. That way > you can avoid doing v4-v6 unless you really have to. > > I agree with you that ICE won't be the answer, but ANAT has > some serious issues too, which RFC 4092 does not solve. I > think we may just need to define a new SDP attribute to handle this. > > -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
