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. 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
