Hi Dan, Please see inline. Cheers Med -----Message d'origine----- De : Dan Wing [mailto:dwing@xxxxxxxxx] Envoyé : lundi 9 mars 2009 19:17 À : BOUCADAIR Mohamed RD-CORE-CAE; sipping@xxxxxxxx Objet : RE: TR: I-D Action:draft-boucadair-sipping-ipv6-atypes-00.txt > But ANAT doesn't work well. And it is being deprecated. If > we need some light-weight way of offering both v4 and v6, and > want it to be a standard, we need something different. Either > lighter weight ICE (e.g., without connectivity checks maybe?) > or SDP Capability Negotiation, or something. > > > Med: I definitely vote for something more lightweight than > ICE to ease IPv4-IPv6 interworking. atypes does solve some of > the IPv4-IPv6 interworking. A NAT64 is involved in the path > (by the proxy server) based on the atypes value. But, if we > need to have other means to prioritise/promote IPv6, we need > something else more lightweight than ICE. I agree that atypes proposes a different solution which is more lightweight for the SIP UAs. Med: Yes. However, it does require the SIP UAs depend on the SBC to work in a different address family. Med: SBC is not mandatory. But I understand you are referring to an intermediary server (e.g. proxy server). Then, the answer is yes. In some environments, where there is always an SBC involved with the call, that is probably a reasonable requirement and atypes would be a good solution in those networks -- similarly, perhaps on those networks one can assume support for Grouping. Med: Ok. But for the rest of the Internet, where those assumptions cannot be made, I do like the *idea* of atypes, but I would suggest some changes to it (e.g., don't use multiple m-lines because they cause harm. e.g., provide a way to detect if a IPv4 or IPv6 path is working -- as we all know with the difficulties in keeping www.ietf.org working over IPv6, IPv6 connectivity is not yet as reliable as IPv4 connectivity.) Med: In fact, the ***only*** scenario which requires the support of ANAT (or multiple media line) is when a DS is the initiator of the call. For this scenario, I suggest the following: DS UA issues its INVITE with a atypes set to "ipv4,ipv6" and an empty SDP. When the request is received by the proxy server or by the remote UA, then it uses atypes is used to determine which offer to enclose in its SDP offer part of 200 OK message. But, I admit that I'm in favour of simplifying the ANAT syntax than using this "empty SDP". -d > > -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
