> -----Original Message----- > From: mohamed.boucadair@xxxxxxxxxxxxxxxxxx > [mailto:mohamed.boucadair@xxxxxxxxxxxxxxxxxx] > Sent: Thursday, March 05, 2009 10:05 AM > To: dwing@xxxxxxxxx; sipping@xxxxxxxx > Subject: RE: TR: I-D > Action:draft-boucadair-sipping-ipv6-atypes-00.txt > > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > De : Dan Wing [mailto:dwing@xxxxxxxxx] > Envoyé : jeudi 5 mars 2009 18:26 > À : BOUCADAIR Mohamed RD-CORE-CAE; sipping@xxxxxxxx > Objet : RE: TR: I-D > Action:draft-boucadair-sipping-ipv6-atypes-00.txt > > > > > -----Original Message----- > > From: mohamed.boucadair@xxxxxxxxxxxxxxxxxx > > [mailto:mohamed.boucadair@xxxxxxxxxxxxxxxxxx] > > Sent: Wednesday, March 04, 2009 10:34 PM > > To: dwing@xxxxxxxxx; sipping@xxxxxxxx > > Subject: RE: TR: I-D > > Action:draft-boucadair-sipping-ipv6-atypes-00.txt > > > > > > 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. > > If there is an ALG involved, it is presumably modifying the > SDP. So, it is performing the same function as an SBC, right? > > > Med: Not only SDP part but also some SIP headers such as > contact. I personally don't like to closely relate a function > and a node. In the context of v4-v6 interworking an SBC may > embed an ALG together with an NAT64 function. > > > > Currently, there is no standardised procedure to > > implement this. > > > Agreed. > > > 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. > > draft-wing-behave-nat64-referrals-00.txt shows how referrals work > between UAs of different IP address families using NAT64 and using > TURN-IPv6 -- using ICE. ICE needs to be on the IPv6 endpoint (it > doesn't need to be on the IPv4 endpoint). > > > Med: I have read the draft. ICE support is required. Yes, that is because SIP and SIPPING documents all require ICE for IPv4/IPv6 interworking. Your document is a departure from requiring ICE, and puts the onus on the SBC to perform the interworking. I'm not saying that is wrong; rather, it is different. > Furthermore, it does not optimise the invocation of NAT64/ALG > function. The intermediary PS needs to have "deterministic" > information. NAT64 and IPv4-IPv6 ALG function should not for > instance be used when a DS is involved in a communication. > > > > 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. > > Ok. > > > 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. > > 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. However, it does require the SIP UAs depend on the SBC to work in a different address family. 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. 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.) -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
