2008 The Year We Peer II

On January 2, 2008 , I posted here in this BLOG entry "2008 The Year We Peer"

Although I had thought little about this over the last several months, I now see that it is a vision that almost immediately began to come true. The truth is I had a very strong sensation that I needed to write that entry and quickly, even though I was involved in a move. Now I can say that rather than being embarrassed when the end of 2008 arrives, I can now proudly say that I hit the nail squarely on the head. SKOOKUM!

Sometime later in January , apparently Gizmo / SIPPhone announced Gizmo5 , and Gizmo5 "Backdoor Dialing". I did not think too much about this , nor look into it too deeply. In fact, I figured it was just more hype. However what I have found is that truly SIPPhone is offering FREE calls via Peering, and not just to VoIP providers. This even seems to include for example any Qwest number in Portland, Oregon. Unfortunately they play a "Free Call" recording on these calls, but the calls seem to connect with high quality.

Also since publishing that Blog entry, I originally took the announcement of an annual charge from Freeworlddialup.com to be bad news. As it turns out is WONDERFUL news for peering. They have apparently come to realize the value of their association with Ipeerx, also a Pulver Company. A year ago I was "backdooring" into FWD to get access to all Packet8 and Broadvoice numbers. I even asked the question of Jeff Pulver about people exploiting available services on FWD which could potentially break FWD. I did not tell him about backdooring these calls into the FWD network, as I did not want to ruin a good thing. In fact I wrote a BLOG entry in December 2007 and the tests I referred to there were done through FWD. Jeff, do you read my BLOG? If so you now know what I was talking about in my message about "disruptive technology".

If you build it, they will come!

I think in the case of both of these services, they seem to lack a "lookup" service to find out easily if a number is in the database, much like ENUM. In Fact users of Asterisk could use this same kind of lookup to easily interface these wonderful service offerings into their products.

Presenting Colonel or Kernel Panic

Well, I must say who can spend months working with linux without the opportunity to be presented to "Kernel Panic"?

For those interested I present the world with what appears to be the first and only Colonel Panic

Mark

Linux; Unbuntu, OpenSUSE, CentOS

It has been a frustrating week!

My previous attempts at Linux installs have all been met with failure for one reason or another.

Although this week, I have succeeded at a few different distros, the remaining problem is then getting the application one needs to work. For instance in my Cent OS on i386 I had no problem with hamachi, it was the GUI I could not get to work. I also dis a PPC install of Ubuntu and found that NO VERSION HAMACHI WOULD INSTALL SUCCESSFULLY, until I gave up! In each case there was always something else I needed installed to install the program I needed to use. The package managers were of Little Help, such as when I looked for gtk+ 2.0 In the Synaptic Package manager for Ubuntu, I had to sort through over 100 results and most seemed irrelevant. Keep in mind I had to do this several times to even attempt the installation of hamachi!

OpenSUSE on the PPC platform from the mini ISO was a complete failure despite many, many attempts.

I think someone should make some standards for Linux Distros to ensure programs will install without installing 10 dependencies along the way! In that way a user can download a program with the full knowledge that they will not be relying on a post on a forum to hopefully get a geek to answer their question a week later.

Although I can say that Ubuntu seems to have won my heart for the included packages that can be easily installed, it is a far cry from Windows or any Mac OS, and fails with advanced applications like Hamachi, or any third party program that supposedly runs on linux.

My opinion on Linux, it is great for getting an OS on an older machine, but so is Windows 2000, and there is no nightmare with the installation of Java, and All of the necessary web browser plug ins. I suppose it is a matter of the value of ones' time however I can say Linux in general for me has been one of the biggest time wasters I have seen. I need to employ cutting edge applications and I can not identify and install 10 different packages to install the program I need. Let alone whatever problems arise after the installation of said program.

Linux is good for playing, or a dedicated server, with, but I see it as little competition for Microsoft or Apple in the desktop OS market, as it is still Kludgeware. If you can not install the programs you need, forget it.

CODECs , Micro-CODECs , and still more CODECs

I frequently find myself in discussions about CODECs and call quality. It seems that many people have little understanding of CODECs , and even fewer have a good understanding of CODEC translation or what may REALLY be happening when they send out a micro-CODEC such as GSM or ilbc from their asterisk box, softphone or ATA.

This is mostly a translation from an old post that I made in Spanish on the subject.

The majority of carries support some flavor of g711 and g729. Therefore , when a person sends a call in a CODEC such as g723, GSM or ilbc, it is more probably they will have CODEC translation occur in the chain of that call.

Does not matter? You think so? Really huh....

Your provider offers g723, g729 and g711 for example. You want to use ilbc. Your asterisk can translate CODECS, because you are thinking more of saving bandwidth, you send calls to your provider via g723. Perhaps what you do not understand is that your provider is going to translate that call from the G723 that you send to g729 or g711 before sending it to the PSTN.

In the example above , you can see that the call will have a couple of different stages of CODEC translation. One very important thing to understand is always to use the most common CODECs. You must think of each stage of CODEC translation in the ENTIRE chain, not just on your end. If your call happens to be to a GSM cell phone you call will later also be CODEC translated again to some flavor of GSM, adding yet another step of CODEC translation.

It is better to use CODECs that your provider can support up to the gateway, with no translation, but when that is not possible, you should NEVER translate from a micro-CODEC to a micro-CODEC, unless you are sure that your privider is not translating again later in the chain. The only CODECs that are not micro-CODECs are g711 u (ulaw , or PCMU) and g711a (alaw or PCMA). Also Micro-CODECs have an inherent higher level of latency, are more greatly affected by packet loss and jitter, and every CODEC translation in the chain adds more latency still.

If a person or company tells you they offer "Carrier Class Services" , they should offer g711a or g711u, or it is simply not carrier class. They are the only CODECs that offer the same quality as the PSTN.

Keep in mind, each micro-CODEC adds its own unique set of distortions, artifacts, and errors in the voice quality. If you go through two micro-CODECs , the call may have such poor quality it can be unintelligible.

E.164 numbering plan, what about E.164 dial tone?

First I will say, for those that do not know, E.164 dialing is non – country specific dialing. On traditional systems, to place an international call from the UK you dial 00, whereas from the USA you dial 011. Of course each country has its’ own set of dial and call progress tones. E.164 dialing can begin with + such as on a GSM cell phone, but when dialing from traditional equipment the + is not an option so it s dropped, and dialing begins with the country code

Dial tone not only tells us the phone is ready to dial, but reminds us how to dial 011 or 00 as well as a unique set of call progress tones for busy, ringing, reorder, etc., by country.

It only makes sense. You go to England, or any other country, and you hear the country specific dial tone.

Now we have non-country specific E.164 dialing, so why not a dial tone that tells us that is the expected dial plan?

It makes perfect sense. The caller knows by the dial tone how he/she needs to dial “001” or simply “1” to start.

I therefore propose (assuming it does not yet exist) …….

E.164 dial tone , and all call progress tones that are uniquely identifiable be established and integrated into all new VoIP devices. . This will allow all E.164 systems to “remind” the user that they should use E.164 dialing, not UK, not USA, and not Mexico.

Internet peering in Mexico- You got a long way to go baby

Here it is, I am about to go off on another mindless rant. This time about Internet peering. This is not about VoIP peering, however international Internet peering. Specific case in point, Mexico.

Recently I started evaluating ISPs in Mexico. I have looked at many aspects of Business and residential ISPs, however with a close eye on latency and peering.

What I have discovered should be considered an embarrassment for ANY country. In the case of Mexico There is very little (if any at all) internet peering in Mexico. What this means is that when Juan who uses Telecable (which appears to really uses Bestel) in Guadalajara pings Maria who uses Telmex infinitum, ALL traffic travels ALL THE WAY TO THE USA AND BACK AGAIN! This is a completely ridiculous situation.

Firstly, I do not believe Telmex, nor Bestel are internet Backbone providers in the USA. This means that each of them pays to get their traffic into the USA or from the USA.

Secondly, this represent money leaving Mexico to terminate traffic back to Mexico! Not only that but in the aforementioned case, both Bestel and Telmex are paying for US backbone access for traffic originating and terminating in Mexico!

Thirdly, BOTH of these providers might save a bundle on USA backbone access if they only peered with one to another.

Fourthly, VoIP is beginning to become far more common in Mexico with Major carriers jumping on the bandwagon. However, it is a whole different game in Mexico because of the distance involved to the backbone of the internet and (lack of Mexico) peering. With latency, comes a higher probability of jitter. These issues result in lower call quality for users, making VoIP less attractive, unless of course your broadband provider is your VoIP provider. In some cases, VoIP users may be better off connecting to USA based servers than Mexico based servers if their Mexico based VoIP provider and broadband Provider are not the same company.

I think it is time that countries like Mexico begin improving their own infrastructure in order to improve service to their customers. At the same time they may also keep more money in Mexico instead of paying it in the USA.

COFETEL has an interest in supporting Mexico based VoIP, and they have the power to regulate Internet in Mexico. So let me ask, can they not see the writing on the wall?

Pings From Zapopan
Ping from Telecable Zapopan (Suburb of Guadalajara) to Telmex DSL Guadalajara: Average = 106ms
Ping from Telecable Zapopan to Telmex DSL Zapopan, literally the next door neighbor!: Average = 96ms

Compare those above with a ping from Telecable Zapopan to Dallas TX US Average = 53ms


Next, we compare the pings from Dallas TX to two of the same IPs that we used before
From Dallas TX to Telecable Zapopan: Average = 49ms
From Dallas TX to Telmex Infinitum Guadalajara: Average = 68ms

As you can see from the examples above, the Internet has a long way to go in Mexico. Mexico should immediately instigate better peering, so that neighbors' traffic between them is not routing out of the country first! I suspect this will have to be done by force with a Mandate from COFETEL.

As always, I welcome any reader comments.

2008 the Year we Peer!

I am calling 2008 , the year we peer for a couple of reasons. I am not referring to the large VoIP providers, I am referring to the small and medium VoIP providers. I also believe that with the peering of the small to medium VoIP providers, the larger ones will follow suit to whatever peering the smaller providers use, as there is strength in numbers. I envision that small to medium providers do not want to pay a high start up cost, nor collocate facilities, which both seem to be the case with the existing peering offerings.

2008 will also be the year that more VoIP providers dry up and blow away. Why? Well the answer goes like this… If you do not peer you will be paying to terminate calls that you may otherwise terminate for free. Your competitors may be doing this already, and those not peering are left at a disadvantage. Also, there is just the standard attrition rate. VoIP is nor easy to make money in , but it can also be a low investment start up, that can support a family on. Of course it does not happen overnight, and it takes a lot of work. So while building that VoIP business you need to save every possible fraction of a penny. Remember the movie, “Office Space”? Those guys pilfered fractions of pennies off of accounts, and it all added up. Now compare that with a small VoIP company. If they could terminate just 2% of calls through peering with millions of minutes annually, that might make it worth a small monthly fee for peering. Not to mention that peering is the kind of thing that as more and more companies begin to do, it becomes more attractive for non–participants to get involved in, as every new peering partner adds their destinations to the pool. Some technologies are destined to fail once a certain saturation level is reached, however I believe the opposite is true with peering.

A small to medium VoIP provider can begin to make this happen now by doing the following.

1) Open their networks to receive anonymous inbound SIP/H.323/IAX traffic.

2) Take advantage of existing ENUM and/or DUNDI offerings.

3) Contact us to offer to peer with us. We are currently expanding our peering relationships and will soon offer all available peering available to us to our peering partners, thereby making it a complete traffic exchange for all peers. Our goal is to make transparent peering a reality, so that any peer is automatically a peer with all other peers on the network, but we are not quite there yet.

Of course appropriate action needs to be taken to ensure that you are only terminating calls that truly terminate on their network. It is safe and easy to allow both anonymous SIP inbounds and DUNDI if one uses Asterisk as a front end for your DIDs. I am sure there are other ways that are not yet imagined as well.

I think in the next year we will begin to see exciting new peering offerings emerge.

Make 2008 the Year we Peer!

Follow Up to this article is here