September 2005 - NZNOG - lists.nznog.org

Re: [nznog] Vodafone dial pattern - another change ?
by Gavin Legge 22 Sep '05

22 Sep '05

I used to work for a telco and on many occasions observed overlap sending on ISDN's working fine. This while watching test instruments across live lines. - so yeah - it's used out there for sure... Go for it. -----Original Message----- From: Ian Batterbee [mailto:ian.batterbee(a)aut.ac.nz] Sent: Friday, 23 September 2005 1:16 p.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Vodafone dial pattern - another change ? >Surely the delay thing is why most VoIP type systems accept something >such as "#" as an "I've finished inputting my number, please dial it" >indicator ? > > Although we do operate a VoIP system, that's largely irrelevant, because our previous PBX (Ericsson MD110) had all the patterns configured into it as well, so we would have been in the same situation. Users don't expect to have to dial a # at the end of their number, and we shouldn't expect them to have to do so. >Is the 5 seconds tuneable ? "wait 5 seconds till the 5th digit has been >entered then change this to 3 seconds till the 7th digit then change >this to 1 second" > The 5-second delay is coming from TelstraClear.. so no, we can't tune it. They're waiting for another digit, and when I posted about last month, it was because TCL's pattern was actually incorrect, and was waiting for extra digits that would never come, resulting in an unncessary 5 second setup delay to a large number of 021 numbers. This has since been corrected. A number of PBX systems validate the numbers so that they can match and therefore route them down the most appropriate route. Our (Cisco) PBX comes with patterns for most countries, which simplifies the task of setting up a new system. While I agree NZ's plan is relatively simple, other countries are not, and that's probably the reason they do it that way. There is the possibilty that we could enable overlap sending.. which I believe means that you send each digit as it is dialled, rather than all at once in an ISDN SETUP message - as it gives the telco the option to send back 'more needed', or 'that's enough digits'.. but.. I'm reluctant to turn it on without some proper testing first. Thanks to Barry who found the info I needed, and finally, to those of you who do validate the numbers locally, and who were forced into silence before posting anything by Steve's helpful comments, here are the new patterns: 021 0221 XXXX 021 0222 XXXX I believe there may be more coming. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. MailScanner Supplied by ITS-HelpDesk. ext 4001 or email helpdesk(a)irl.cri.nz-- This electronic transmission and any documents accompanying this electronic transmission contain confidential information belonging to the sender. This information may be legally privileged. The information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on or regarding the contents of this electronically transmitted information is strictly prohibited.

2 1

Re: [nznog] Vodafone dial pattern - another change ?
by Ian Batterbee 22 Sep '05

22 Sep '05

>Surely the delay thing is why most VoIP type systems accept something >such as "#" as an "I've finished inputting my number, please dial it" >indicator ? > > Although we do operate a VoIP system, that's largely irrelevant, because our previous PBX (Ericsson MD110) had all the patterns configured into it as well, so we would have been in the same situation. Users don't expect to have to dial a # at the end of their number, and we shouldn't expect them to have to do so. >Is the 5 seconds tuneable ? "wait 5 seconds till the 5th digit has been >entered then change this to 3 seconds till the 7th digit then change >this to 1 second" > The 5-second delay is coming from TelstraClear.. so no, we can't tune it. They're waiting for another digit, and when I posted about last month, it was because TCL's pattern was actually incorrect, and was waiting for extra digits that would never come, resulting in an unncessary 5 second setup delay to a large number of 021 numbers. This has since been corrected. A number of PBX systems validate the numbers so that they can match and therefore route them down the most appropriate route. Our (Cisco) PBX comes with patterns for most countries, which simplifies the task of setting up a new system. While I agree NZ's plan is relatively simple, other countries are not, and that's probably the reason they do it that way. There is the possibilty that we could enable overlap sending.. which I believe means that you send each digit as it is dialled, rather than all at once in an ISDN SETUP message - as it gives the telco the option to send back 'more needed', or 'that's enough digits'.. but.. I'm reluctant to turn it on without some proper testing first. Thanks to Barry who found the info I needed, and finally, to those of you who do validate the numbers locally, and who were forced into silence before posting anything by Steve's helpful comments, here are the new patterns: 021 0221 XXXX 021 0222 XXXX I believe there may be more coming.

1 0

Vodafone dial pattern - another change ?
by Ian Batterbee 22 Sep '05

22 Sep '05

In the last 24 hours I've heard from multiple sources that Vodafone is now using 8 digit prepay numbers - the numbers I was given that were reported 'not working' (because our PBX didn't match all the digits) were both 021-0222xxxx, ie, 8 digits after the 021. I know I asked about this only one month ago, but back then 021[012] only appeared to require 6 further digits, and not 7. I've just tried calling both 0222xxxx numbers from my vodafone mobile, and they they both rang. I tried leaving the last digit off, and they both failed, so it does suggest that things have changed. Does anyone know what's going on, and/or what the correct prefix for this number pattern is ? If I change my end to match 0210 plus 7, it will introduce a 5 second delay into any numbers that only have 6 digits after the 0210 -- Ian Batterbee, CCNP Senior Network/Comms Technician Auckland University of Technology

6 8

Want to sell the syntax S648 motherboard
by Kevn Wong 21 Sep '05

21 Sep '05

Dear sir, Now we have some syntax Syntax S648 motherboard in stock, they are all new original retail box unopen products. our offer is US$25.00/Pcs, if you are interesting in them, please feel free to contact me, thanks. Have a nice day Best Regards Kevin http://www.syntaxusa.com/catalog/product_info.php?cPath=44_46&products_id=68 Description ・ Intel Motherboard S648 Special Features ・ Socket 478 board that supports Intel Pentium 4 processor up to 533Mhz FSB ・ Integrated with the most advanced technologies - SiS MuTIOL media I/O Magic Setting, USB 2.0 (SiS 963) ・ USB 2.0 ・ Supports Ultra DMA 133/100 Specifications - Processors ・ Socket 478 for Intel Pentium 4 processor ・ FSB 533/400 MHz ・ Supports Hyper-Threading Technology - Chipset ・ North Bridge: SiS 648 ・ South Bridge: SiS 963 - Memory ・ 3 DDR DIMM sockets Support ・ 3 x 2.5V DDR SDRAMs (DDR266/DDR200) or ・ 2 x 2.5V DDR SDRAMs (DDR333) ・ Max. 3GB (2GB only for DDR333) - Graphics ・ 8X AGP - Sound ・ Compliant with AC97 2.2 specification - LAN ・ RealTek RTL8100/B 10/100 Mbps Fast Ethernet Controller - IDE ・ 2 UltraDMA 133/100/66/33 - USB ・ 6 USB 2.0 - Expansion Slots ・ 1 AGP 8X ・ 5 PCI ・ 1 CNR - Back Panel I/O Ports ・ 1 PS/2 Mouse ・ 1 PS/2 Keyboard ・ 1 Parallel ・ 2 Seria ・ Game port ・ 1 LAN ・ 2 USB ・ 1 Line-in ・ 1 Line-out ・ 1 Mic-in - Internal I/O Connectors ・ 2 USB 2.0 headers support additional 4 USB ports ・ Front Panel MIC/Line out header ・ SIR header ・ HDD LED, Reset switch, Power switch headers ・ ATX power connector ・ CPU/Power/Case fan Connectors - BIOS ・ Award 2MB flash EEPROM ・ Supports Plug and Play 1.0A, AMP 1.2, multi boot, DMI ・ Support ACPI V1.0 specification - Form Factor ・ ATX - Board Size ・ 12" x 9.6" (305mm x 244mm) - RTC & Battery ・ SiS 963 built-in 256 bytes of CMOS SRAM ・ With CMOS hardware clear jumper

1 0

Re: [nznog] Further Analysis of Election Night
by Regan Murphy 21 Sep '05

21 Sep '05

I'm with xtra for DSL at home. I don't seem to transit via the US to get content from the r2 servers. -----Original Message----- From: Dan Clark [mailto:dan(a)synaptic.net.nz] Sent: Thursday, 22 September 2005 6:59 p.m. To: Richard Naylor Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Further Analysis of Election Night mostly Xtra customers connecting to the US server no doubt? Dan

4 3

Further Analysis of Election Night
by Richard Naylor 21 Sep '05

21 Sep '05

Further analysis of the Election period webcast ----------------------------------------------- We have now had some time to analyse log files from the election period. The following observations are made. It should be understood that there were 4 servers, USA - 1 AKL - 2 (CityLink and TVNZ) WLG - 1 We have not had access to the TVNZ log files and so the following comments are based on analysis of 3 servers only. These servers were carrying 62% of the load (by traffic) It also needs to be understood that these servers were not set up solely for the election event and carried on handling day to day 24x7 streaming. So in looking at log files, there are many streams and services (such as on demand video or audio files) which were operating regardless of the election. Equally many of the stations which we stream had no particular coverage of the election and carried on their usual Saturday night programmes. As a result some analysis requires a little local knowledge to make sense. In addition, R2 was providing on-demand services to 3 political parties involved in the election. Several parties had closing video clips or focussed their multi-media assets for the closing stages of the campaign. This produced extra traffic on election day. In some cases a surprising number of hits. We also carried a number of election related events such as The Labour Party Election Campaign launch The InternetNZ ICT Candidates debate Election Fiscal Update (access via Scooop.co.nz) Several Press Briefings by the PM (access via Scoop.co.nz) Candidate debates (access via RadioNZ.co.nz) As a result a very rough estimate is that the last month has seen server traffic double. On election night, over 40 countries accessed the 3 CityLink servers. They were NZ 36% Australia 12% US 8% UK 2.5% France 1.5% Canada Japan Netherlands Singapore Switzerland Germany Czech Republic Italy Brazil Thailand Poland Malaysia Austria Saudi Arabia Israel India Hungary Taiwan Turkey Spain Slovakia Belgium Sweden Denmark Norway Fiji Azerbaijan United Arab Emirates Russia Philippines The top 15 countries all accessed over 1GBytes of data Of great interest to us is the access to the USA server as its usage is designed to handle international interest under a strategy of locating servers as close to the clients as possible, so that over time, higher quality material (audio or video) can be delivered. The USA server received connections from NZ 30% Australia 20% USA 10% UK 3.7% Japan 1.5% Singapore 1.3% With 3 servers located in NZ, there was no need for traffic from the US server to NZ. This is caused solely by poor peering by NZ ISPs. It represents some 10Mbps of traffic.

3 3

Useful BGP tool
by Gordon Smith 21 Sep '05

21 Sep '05

A little something that's quite useful for looking at route advertisement trends over time. It complements the use of route-servers quite well when looking at BGP path changes internationally. Found the link on NANOG http://bgpinspect.merit.edu/

2 1

Re: [nznog] [afnog] ARIN to allocate from 74/8 & 75/8
by Rob Thomas 20 Sep '05

20 Sep '05

Hi, Randy. ] but, as you seem to understand, that's only half the story. luckily, ] the other, more useful, half is easily testable if arin/cymru would ] just follow the long-discussed path. We couldn't agree more! That's why we stood up the following three pingable IP addresses prior to announcing the test prefixes. 74.63.1.2 75.127.1.2 76.191.1.2 Sorry those weren't announced sooner! Thanks, Rob, for Team Cymru. -- Rob Thomas http://www.cymru.com Shaving with Occam's razor since 1999.

1 0

Woosh prefix update
by Nathan Ward 20 Sep '05

20 Sep '05

We are now advertising an additional prefix to our APE and WIX connected peers, including the route servers for these exchanges. I also ask that anyone not currently accepting up to 24 bit long prefixes in our advertisements, to please do so. We have no need to advertise these now, but we'd like to have the option available if needed, yadda yadda. The new prefix is 203.211.64.0/20. So, in the end it should look something like: ip prefix-list woosh-in seq 5 permit 202.74.192.0/19 le 24 ip prefix-list woosh-in seq 10 permit 203.211.64.0/20 le 24 Other potentially useful details follow: ASN 17412 APE IP 192.203.154.49 WIX IP 202.7.0.50 For those of you who are not currently peering with us and would like to arrange direct peering sessions, please contact me offlist, or on +64-9-522-3699, ext 618. -- Nathan Ward

2 1

Election Night Statistics
by Richard Naylor 20 Sep '05

20 Sep '05

Election Night Webcasting Statistics On Election night, 2005, CityLink/R2 was involved in assisting a number of broadcasters with their streaming requirements. This was in addition to the normal webcasting activites being carried out with other TV and radio stations. Particular focus was placed on TV-One (TVNZ) TV-3 NewstalkZB National Radio The streaming was carried out using servers located in Auckland, Wellington and Palo Alto (USA). Encoding was carried out by TVNZ and CityLink/R2. In terms of number of viewers, the 2003 Lord of the Rings premiere has been regarded as the biggest event webcast to date. The election night figures passed that by approximately 50%. On election night, some servers used anycast routing to spread traffic between servers, so that viewers connected to the server closest to them by Internet topology. Because not all servers used anycasting, we experienced congestion on the link feeding the US based server. As a result, some viewers used the link to NZ servers, further overloading the International capacity. In hindsight, we should have fed the US server via an alternate route to ensure the quality of its streams. In terms of traffic, the average bandwidth being consumed was Auckland (2 servers) = 110 Mbps Wellington (1 server) = 50 Mbps USA (1 server) = 50 Mbps Total average bandwidth = 210 Mbps Peaks were of course much higher. Estimates are that approximately 450Gbytes of data was transferred during the event of 6 hours. 98% of this data was carried by the anycast routing architecture. At 10 cents per megabyte this data represents approximately $45,000. CityLink delivered this event for free as a public service. Lessons Learned Our experience suggests that for large events, anycast routing delivers high performance. However, the source feed to the US servers needs to be isolated from any other traffic into or out of NZ. We could have done this using our satellite capacity or by strictly enforcing anycast routing. This would have meant that NZ ISPs not peering at NZ Internet exchanges would have to bring significant traffic into NZ on their International circuits.

1 0