> -----Original Message----- > From: mohamed.boucadair@xxxxxxxxxxxxxxxxxx > [mailto:mohamed.boucadair@xxxxxxxxxxxxxxxxxx] > Sent: Thursday, March 05, 2009 10:13 AM > To: dwing@xxxxxxxxx; HKaplan@xxxxxxxxxxxxxx; sipping@xxxxxxxx > Subject: RE: TR: > I-DAction:draft-boucadair-sipping-ipv6-atypes-00.txt > > > 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. Let me explain my point. If I am operating a network that is 100% IPv4, how do I indicate to other networks that some of my users now support IPv6? That is, if the other service provider is doing that adaptation function, how does the adaptation function get involked for my some of my users that support IPv6? -d > 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
