Another reason for IPv6 support would be the simpler and much easier
one... All ATA's and IP phones draw their configuration files from the
server, and their setup details by the MAC address (native IPv6). to use
this as a possible primary detail would drop NAT tranversal into a minor
place as when the Phone/ATA sent the invite it would automatically
register the address via the MAC address, and then could be moved
anywhere in the world, hooked up and it would send the config file
again, therefore not requiring IPv4 NAT traversal, as it would
automatically connect .
I have tried this with Grandstream products using the MAC address, both
on Asterisk and SipX.
When the MAC address is used as a registration device, it is only due to
the requirement of IPv4 that the device needs to have the ports opened
both inward and outward (required for SipX all the time). Whereas with
Asterisk and its clones, once it is set to IPv6, it allows direct
bypassing of the firewall if it is set to allow IPv6 passthrough. As
this protocol has a fairly large address range, a softphone device using
a MAC address on either a wireless card or a LAN card would have less
hassles registering with a server wherever it was as the IPv6 address
would identify the machine directly whenever it was online, once again
bypassing some of the necessary steps in the IPv4 stack (internal IP
address conflicts). Just My opinion of course.
Alan
J Coatline wrote:
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
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
