Not really an operational question, but an engineering question non-the-less. This may also not be the most suitable forum, but there is a large brain trust here that can probably answer my questions. We are looking at a business plan to launch a large VOIP carrier globally. My questions are: 1: Does it make sense to scatter nodes around the globe to limit latency on intraregional calls? If so how many? We were thinking about 7 placed at strategic points around the globe. 2: Is a softswitch architecture preferred to a proxy server/Media Gateway (Vonage) only type architecture? 3: What protocols should be used for firmware upgrades to ATA devices? We are thinking HTTPS or SFTP, or HTTP if those aren't available on selected devices. I am trying to stay away from TFTP for security reasons. 4: Anyone have any vendor recommendations? We currently use Metaswitch for our Softswitch, but I'm not sure it would be the best choice for a large scale deployment although I am going to research it. 5: Should I work with large wholesalers (L3, GX, etc) or try to penetrate markets in some other way? 6: Are there any wholesalers (DID Origination) outside of the US that anyone knows of? Sorry to have so many questions. Many of these I already have ideas on the answers however I acknowledge there are far smarter people than myself in the world. So I figure it's a good idea to ask and get opinions from others before I make a final decision. Shane Shaneowens<at>dna-communications.com
Shane Owens wrote:
Not really an operational question, but an engineering question non-the-less. This may also not be the most suitable forum, but there is a large brain trust here that can probably answer my questions.
Oh, it does. It probably is the only way you get all those ip-phones distrubuted all over the globe into working.
We are looking at a business plan to launch a large VOIP carrier globally. My questions are:
1: Does it make sense to scatter nodes around the globe to limit latency on intraregional calls? If so how many? We were thinking about 7 placed at strategic points around the globe.
The atlantic ocean is a problem. May be it is because my ISP throws in an artificial delay of about 80 msec to keep us from P2P or to sell us a more expensive rate. Maybe it is the delay or the contention around the "ferry ports". My forward from http://www.ipkall.com/ stopped working as soon as my ip-phone moved from Newyork to Frankfurt. With traceroute I have seen packets summersalting in London. The third packed arrived before the first. So you would need a node in London and another one in Amsterdam. DTAG.de has routing problems between Amsterdam and Frankfurt or Darmstadt so you might need another node in Frankfurt. I dont know about the rest of Europe. Within germany nobody noticed a difference between my ISDN and my Grandstream ATA-486. Here my traceroute when it routes: traceroute to p54a7f56f.dip.t-dialin.net (84.167.245.111), 30 hops max, 38 byte packets 1 gw1.cyberbunker.net (84.22.100.1) 0.949 ms 0.765 ms 0.639 ms 2 cb-sr1-e0.cb3rob.net (84.22.96.245) 36.322 ms 34.720 ms 37.676 ms 3 ams-tr2-t0.cb3rob.net (84.22.96.249) 9.817 ms 11.200 ms 13.317 ms 4 gate1.deltaland.nl (213.201.229.1) 24.710 ms 15.491 ms 14.228 ms 5 amx-gw2.nl.dtag.de (195.69.145.211) 41.802 ms 12.689 ms 15.209 ms 6 da-ea1.DA.DE.net.DTAG.DE (62.153.179.54) 22.044 ms 19.521 ms 21.177 ms 7 217.0.67.97 (217.0.67.97) 20.324 ms 20.462 ms 30.761 ms 8 p54A7F56F.dip.t-dialin.net (84.167.245.111) 76.950 ms 74.830 ms 73.890 ms and here when it does not: traceroute to p54a7f56f.dip.t-dialin.net (84.167.245.111), 30 hops max, 40 byte packets 1 gw1.cyberbunker.net (84.22.100.1) 0.198 ms 0.186 ms 0.158 ms 2 cb-sr1-e0.cb3rob.net (84.22.96.245) 115.892 ms 117.430 ms 116.859 ms 3 ams-tr2-t0.cb3rob.net (84.22.96.249) 44.379 ms 42.748 ms 41.447 ms 4 gate1.deltaland.nl (213.201.229.1) 40.069 ms 38.394 ms 36.923 ms 5 amx-gw2.nl.dtag.de (195.69.145.211) 37.144 ms 35.848 ms 35.178 ms 6 da-ea1.DA.DE.net.DTAG.DE (62.153.179.54) 40.176 ms 38.547 ms 39.933 ms 7 217.0.67.105 54.372 ms 54.171 ms 52.435 ms 8 * * * The problem is DTAG.DE using ip addresses from 84.xxx.xxx.xxx and at the same time believing them to be bogons.
2: Is a softswitch architecture preferred to a proxy server/Media Gateway (Vonage) only type architecture?
3: What protocols should be used for firmware upgrades to ATA devices? We are thinking HTTPS or SFTP, or HTTP if those aren't available on selected devices. I am trying to stay away from TFTP for security reasons.
TFTP is no problem with linux people running their own server locally. But never let it be seen from the outside. There a TFTP servers for windows too My Grandstream uses TFTP but I have never seen an update. I guess HTTP to get the software to your customers should do. HTTPS is fine. Who knows SFTP?
4: Anyone have any vendor recommendations? We currently use Metaswitch for our Softswitch, but I'm not sure it would be the best choice for a large scale deployment although I am going to research it.
They are very popular in Germany. Dont ask me the other countries: http://www.avm.de/en/
5: Should I work with large wholesalers (L3, GX, etc) or try to penetrate markets in some other way?
There are a lot of VoIP providers in Germany. Many of them have their networks interconnected to offer free calls between the networks. Some providers operate in more than one european countries. It seems like a jungle. Europe is even more complicated: There are things like 110 or 112 or some other funny number for emergency calls. There are geographic phonenumbers that must reflect where your ip-phone is located. Do you really want to know :) DTAG AG wants to move all their pots and isdn phones to VoIP in the long run and without any benefit for their customers. Maybe you should talk to them.
6: Are there any wholesalers (DID Origination) outside of the US that anyone knows of?
Have a look at them: http://www.united-internet.com/ Maybe they are not a wholesaler but they are moderately big. They provide both VoIP and aDSL but they still depend on the DTAG.DE network mostly.
Sorry to have so many questions. Many of these I already have ideas on the answers however I acknowledge there are far smarter people than myself in the world. So I figure it's a good idea to ask and get opinions from others before I make a final decision.
Shane Shaneowens<at>dna-communications.com
Regards, Peter and Karin Dambier -- Peter and Karin Dambier Public-Root Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-179-108-3978 (O2 Genion) +49-6252-750308 (VoIP: sipgate.de) mail: peter@peter-dambier.de http://iason.site.voila.fr http://www.kokoom.com/iason
On Tue, 2 Aug 2005, Shane Owens wrote: > 1: Does it make sense to scatter nodes around the globe to limit latency on intraregional calls? If so how many? We were > thinking about 7 placed at strategic points around the globe. The short answer is "yes". This is a VoIP peering issue, which is basically just like IP peering, but higher up the stack. There will actually be a VoIP Peering BoF here at the IETF later this afternoon, and it's been the subject of a lot of discussion. To give you a concrete example of why local gateways are needed, I have offices in San Francisco, and we tried a VoIP gateway provider, once, which located its _single_ gateway in Florida. So all of our "local" calls to PSTN numbers in California went to Florida across the Internet, before returning to California. The latency isn't that bad by itself, but combined with the carrier's mediocre bandwidth, it made for very serious voice quality problems. We wound up putting up our own PSTN gateway in San Francisco, and we divide calls between that (California calls) and two different VoIP carriers (everything outside California, based on price). If the VoIP carrier had had gateways on both the east coast and the west coast, they'd have all of our business right now, because we could hand traffic off to them at PAIX or 1 Wilshire or the SIX, and all would be good. But they ignored the underlying infrastructure, to their detriment. > 2: Is a softswitch architecture preferred to a proxy server/Media > Gateway (Vonage) only type architecture? You need both. > 3: What protocols should be used for firmware upgrades to ATA > devices? We are thinking HTTPS or SFTP, or HTTP if those aren't > available on selected devices. I am trying to stay away from TFTP > for security reasons. What security risk does TFTP pose that isn't also shared by HTTP? -Bill
On Wed, 3 Aug 2005, Bill Woodcock wrote:
> 3: What protocols should be used for firmware upgrades to ATA > devices? We are thinking HTTPS or SFTP, or HTTP if those aren't > available on selected devices. I am trying to stay away from TFTP > for security reasons.
What security risk does TFTP pose that isn't also shared by HTTP?
beyond security reasons, there are some performance reasons as well to skip tftp. There was a decent article in 'network magazine' (editorial I suppose really) by Louis Mamakos about 6 months ago regarding the challenges of upgrading a few hundred thousand remote tftp-only devices :( (thanks to google for the link) http://tinyurl.com/9e5pd -Chris
On Wed, 3 Aug 2005 02:08:30 -0700 (PDT) Bill Woodcock <woody@pch.net> wrote:
What security risk does TFTP pose that isn't also shared by HTTP?
I find it disappointing that the filtering police rarely stop to think about their decision about what and why protocols are a security risk. Looked at in one way, TFTP could more secure than many alternatives. A TFTP implementation (e.g. the code required) can be much simpler, which is typically an advantage from a security perspective. If file authenticity (or even encryption) is required, simple end system mechanisms can be applied before and after transmitting the file. For applications such as device bootstrapping that deploy some additional checks on the file transferred, TFTP is probably a perfectly reasonable option. If it weren't for the 2 byte block code limit, it might be even more widely used for this purpose. John
What security risk does TFTP pose that isn't also shared by HTTP?
Not security of the protocol necessarily, but you will find that TFTP is filtered by a number of cable modem providers on the CPE side of the cable modem. Not arguing if filtering/not filtering it is better, just thats one roadblock any provider will come across in trying to use TFTP. sam
participants (6)
-
Bill Woodcock -
Christopher L. Morrow -
John Kristoff -
Peter Dambier -
Sam Hayes Merritt, III -
Shane Owens