[AusNOG] IPv6 -"Nope, we're not at the edge" - Cisco...

[Mark Smith]

----- Original Message -----
> From: Mark Newton <newton at atdot.dotat.org>
> To: Reuben Farrelly <reuben-ausnog at reub.net>
> Cc: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net>
> Sent: Wednesday, 6 March 2013 6:46 PM
> Subject: Re: [AusNOG] IPv6 -"Nope, we're not at the edge" - Cisco...
> 
> 
> On 06/03/2013, at 6:03 PM, Reuben Farrelly <reuben-ausnog at reub.net> wrote:
> 
>>  Although having said that, it's only marginally more functional than an 
> IPv4 only phone if it doesn't have an IPv6 SIP server to talk to.  The head 
> end is the one thing Internode don't seem to have yet released in their 
> rollout...  This leads me to believe that perhaps SIP is one of the more tricky 
> things to get to work (which is ironic given it is probably one of the things 
> that most hates IPv4 NAT).
> 
> Might have changed since I left, but at the time it was because SIP to an ACME 

> Packet
> SBC works fine through lots of layers of NATv4, and Broadworks was dragging 
> their 
> feet as a vendor (I think they've rectified now) so there wasn't a huge 
> impetus to move
> on it.
> 

While I was at Internode in 2010/2011, one of the things that one of the Internode Voice engineers and I did was played with a beta IPv6 version of the ACME software, using Linphone as the SIP client. IIRC, there was a minor bug, but most unimpressively it just worked. There was a Linphone issue because it was choosing the it's ULA address as it's media stream end point, and of course the ACME couldn't reach it. I've been meaning to get around to fixing the Linphone code so that it used the same address for it's local media stream end point as it used as the source for the SIP messages, which would then both be global addresses.

The reason then, and perhaps now, not to switch on IPv6 is that this service/devices support 000 calls, so it is necessary to be extremely conservative.

> Remember that Internode controls the entire path between the customer's CPE 
> and the
> SBC, and can (does) take responsibility for it continuing to work.  Makes it a 
> bit
> different from most other applications, where either the server or the client is 
> in
> someone else's ASN.
> 
>   - mark
> 
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>