Hi Dan, Thank you for your comments. Please see inline. -----Message d'origine----- De : Dan Wing [mailto:dwing@xxxxxxxxx] Envoyé : jeudi 5 mars 2009 02:29 À : BOUCADAIR Mohamed RD-CORE-CAE; sipping@xxxxxxxx Objet : 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. Med: Not only SBCs, but to assist SIP proxy servers in their logic of invoking adaptation functions (i.e. NAT64/ALGS) when heterogeneous (i.e. IPv4 and IPv6) UAs are involved in a session. Currently, there is no standardised procedure to implement this. 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. Med: atypes is not to be positioned vs. ICE or ANAT because these attributes *** do not solve the same problem ***. Atypes is a means for proxies to invoke ALGs/NAT64 to prevent session failure. The support of ANAT/ICE is not sufficient to guarantee the establishment of a session between heterogeneous UA. 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? Med: This is one of the issues which atypes solves. If you assume that an UA which issued its signalling messages with IPv4 is IPv4-only and a remote UA which issued its signalling messages with IPv6 is IPv6-only, then the intermediary proxies server will invoke its ALG/NAT64 to adapt the received SDP offers even if one of the participant may a DS. atypes avoids also redundant inclusion of ALG/ NAT-PT nodes in the path, especially in the context of inter-provider communications. 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. Med: ANAT is only used as an example to illustrate that several network address types may be embedded in an SDP offers. The atypes proposal works also with ICE, even if I personally believe that for this IPv4/IPv6 issues, we don't need to deploy a heavy machine such as ICE and only the support of ANAT would be required. -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
