See inline. Cheers Med -----Message d'origine----- De : Dan Wing [mailto:dwing@xxxxxxxxx] Envoyé : jeudi 5 mars 2009 18:30 À : BOUCADAIR Mohamed RD-CORE-CAE; HKaplan@xxxxxxxxxxxxxx; sipping@xxxxxxxx Objet : RE: TR: I-DAction:draft-boucadair-sipping-ipv6-atypes-00.txt > -----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. Med: I don't get the point Dan. 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
