Allow me to make a case for giving IPv6 high development priority! We're a company with 100 phones distributed across 3 sites in Europe, Asia and the US and a couple of dozen home users using the same phones. Our users love their Cisco 7965 phones, but we don't like CCM/CUCM, and are evaluating several IP PBXs, including sipXecs.
Our phones do IPv6, our WAN links have native IPv6, our ITSP supports IPv6, many of our remote users cable modem links do IPv6 natively, and several IP PBXs support IPv6 (pbxnsip, CCM 4.3, CUCM 7.1.1, asterisk), but sadly not our favorite one (sipXecs). If there was ever an IP application crying out for IPv6, it has to be SIP/RTP, given the importance of end-to-end device reachability, and the large amounts of code (NAT traversal, sipXbridge) that needs to be written, maintained and understood by users to overcome all the various nasty NAT implementations out there. To illustrate this, 80% of the time we have spent configuring and testing sipXecs has been related to the NAT-kludge workaround features, and we still can't get SIP URL calling working reliably. I know 3.11 isn't completely finished, and a major enhancement to it was the NAT handling technology (which is great), but NAT workaround technologies never seem to work 100%, and always seem to suck up so much admin time, (e.g. a home user suddenly calls up complaining about one-way audio). There is a decent description of some of the reasons we'd love to see IPv6 in sipXecs here: http://www.viagenie.ca/publications/2007-03-ipv6asterisk-vpf-miami-blanchet.pdf It's already 2009 and for us to deploy on our network a new major application that doesn't support IPv6 seems a bit shortsighted, even if we ignore all the benefits we can get right now from SIP over IPv6 today. In short, it's about reducing deployment, configuration and maintenance complexity and effort, and eliminating a whole class of things that most often go wrong (I feel that complexity is a big turn-off for many people when it comes to SIP, and dealing with NAT is a huge part of that). On Tue, Mar 3, 2009 at 7:10 AM, Scott Lawrence <[email protected]> wrote: > On Tue, 2009-03-03 at 21:38 +0800, sipxuser sipx wrote: > > >> Is the IPv6 support in planning? > > We're not planning not to do v6 support. :-) > > Like any priority decision, this one depends mostly on the opportunity > cost - what we can't do because we're doing IPv6 instead. Feedback on > _why_ IPv6 is important - most especially on what opportunities it > creates that we could not exploit otherwise - is what will drive those > priority decisions. > > I'd be surprised if IPv6 made it to the high-priority list for 4.2, but > the geek in me would love to have an excuse... > >> > And is it troublesome to add IPv6 support by myself? Anyone has any >> > tips? > > I expect that it's going to be one of those very large jobs that > consists of hundreds (no, I am not exaggerating) of little jobs. > > There will be many many places where v4 is implicitly assumed. > Certainly we'll need the OsSocket (and derivative) classes to be worked > over, and URL parsing, and lots of host comparisons. Very likely the > right thing to do is to create a new abstract IpAddress class and > concrete IPv4Address and IPv6Address classes from those for starters. > > The hardest part by far is going to be to come up with a regression test > infrastructure that supports IPv6, and expanding the interoperability > testing of clients to include IPv6. > > > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users > _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
