Posts
I often see that people are very quick to add new wireless components such as WiFi and Bluetooth components to their existing systems.
I think that most users are unaware of the dangers in using such devices and perhaps should adopt an attitude of "less is better". If you look at the average modern home you may find WiFi, Bluetooth, wireless video, cordless phones, and more, and when someone wants a new component they always look to those that support wireless. Although it may sound sexy and keep you free of wire clutter, one of the most important considerations is your family's health. With every new wireless component you increase the Electromagnetic radiation in your home. With that increase you increase the probability that it will affect your health.
I do not want a cell phone with a bluetooth headset on my body. The effects of the cell phone alone are dangerous. Now with that add the radiation of the bluetooth and you have a new risk.
In your home network you may think that that new wireless NAS is sexy, but did you know that that NAS can be anywhere on your network including, a wired segment , and still pass the contents of that NAS over EXISTING wireless infrastructure, such as your router? You need not use a wireless NAS.
I have been asked by some as to adding such components, who do not clearly understand this and "think wireless" for all components. The physical location of a NAS probably has little importance, so why do you need wireless? Aside from that you will most probably get far better performance from wired components.
next time think about how that new wireless gadget may have on your health or longevity. keep in M ind that the manufacturers have little regard for your health, nor dpoes the salesman that will try to up-sell you to that costlier wireless model, even though it may offer zero benefit in your installation in the end.
In my opinion I do not want my computers emanating WiFi and bluetooth RF radiation as I sit by my cell phone that also emanates electromagnetic radiation. I am not talking about just for you, as perhaps you have small children in your home, who may be even more gravely affec ted by sjuch RF energey.
Jul 1, 2009
Feb 12, 2009
The Bleeding Edge
As time goes on, I come to realize more and more, that I always seem to look for solutions on the bleeding edge.
I am currently looking for the following solutions that do not seem to yet exist!
I am currently looking for the following solutions that do not seem to yet exist!
- A USB device that allows me to take a Single USB drive and share it with the USB ports on two computers. I am NOT looking to network the machines, over USB or otherwise. It seems re4asonable that in this day and age such a solution would already exist, but it does not. Why would I want this? Well Imagine a USB drive connected simultaneously to your computer and to the USB port of a DIVX compatible DVD player. As you write a file from the computer, you may stream audio to your stero from the same USB hard drive. Alternately you may connect to a USB network device such as the Linksys SLUG , while connected to your DVD player.This may also be incorporated to a USB hard disk case to allow simultaneous access from two host controllers. This may be easier if one device is tagged as "read only" as in the case of the DIVX compatible DVD.
- A "Smart" USB to Ethernet adapter. What this Ethernet adapter does is emulates a hard disk from a Windows or NFS network. It is reasonable that it would need some kind of a programming interface such as a mini web server to configure network parameters; Workgroup and shares to connect to, or perhaps with a utility through the USB port. This would also be useful on one of those DIVX compatible DVD players to stream DIVX video to your TV or MP3s to your stereo system via a DVD players USB port (which works only with a USB Disk)
- Accessible HDTV modulator / Encoder. I mean a simple device that can take a HDMI or similar signal and produce a HD modulated "TV Channel" that can be used with the built in tuner on an HD TV. Ideally this would allow several to be used on different channels. There are many CCTV systems that will be undergoing upgrades in the years to come.
Feb 7, 2009
Fun with DIVX and XVID, and torrents
I am a big fan of DIVX , in fact I paid for the full DIVX encoder. About a year ago, I acquired some Hard Disk Media Players that I just love. They play back DIVX files, and XVID as it is a clone of DIVX. These devices have allowed me to keep my original DVDs stored away, where they do not get touched. With DIVX, I can compress the videos down to a reasonable size and maintain video quality. My dabbling with this and other devices has led me to this Post.
Lately I have downloaded some TV series and movies and I see the same issues arise. (See my feelings on legality below).
Frame Rates and Program Length
Consistently, I see that programs that should be about 44 minutes in length with commercials cut out, often play back at 40 minutes in length. I pondered this problem a lot, and as a former television technician, I reasonably sure that 44 minutes or so constitutes 1 hour with commercial breaks.
Here is what I finally concluded.... There is a process called 3/2 pull down, where a 24 FPS film is converted to roughly 30 FPS (by inserting an occasional "extra" frame) when transferred to video in North America (NTSC). There is a similar process used in PAL however I have not done all the math exactly, but I did do enough math to identify the problem. Some software, or the users of software, are removing these extra frames. This is not unusual and is a good idea to reduce file size. The problem lies in that the file still is playing back at 25 FPS, not the 24 that it should play back at. Most of these files originated from PAL systems I can tell due to the PAL video sizes. The most annoying part of this problem is that sometimes it is noticeable that the dialog, and motion, on such ripped programs seems hurried. I remember the advent and discussions of a device called the Lexicon in the 80s which performed a similar function for broadcasters and allowed them to pack more commercials in a 1 hour program. I can not emphasize to all of you DVD rippers enough that you need to keep the proper frame rate, which should reflect whether the pulldown was removed or not. If so, the resulting video is 24 FPS , not 25 FPS, and definitely not 30 FPS, as this affects the playback duration and presents the content in a hurried format.
Aspect Ratio and Cropping
I know there are given aspect ratio "standards" but I have seen some home rippers making some serious mistakes. I do not worry about "proper" resolutions so much, as long as the aspect is correct. I recently downloaded some files for testing via torrents. Now in the case of one film in particular , every copy I found had the same butchering to it when it came to aspect ratio. That file which you can find easily is the 1994 film "The Little Rascals" . It was butchered because when downloaded from a torrent, it is in a 16x9 aspect ratio. Hhowever, the DVD that it was ripped from apparently was 4x3, so it was cropped when ripped. The bad part about that is that it was already cropped when presented in 4x3 and cropping it again yields only a fraction of the original frame. When I downloaded and viewed this file it looked very odd to me, although the quality was good tops of heads were frequently cut off, so I connected the old VHS and started comparing my old 4x3 aspect VHS tape of this movie with the downloaded 16x9 version. I should see more on the sides of the 16x9 from , however in this case I see less of the top and bottom. Clearly that file on the torrents (700.18 Meg) was from a 4x3 aspect DVD then cropped to 16x9. This is a horrible mistake for anyone ripping DVDs!
Comments about my downloads
I want to clarify that my downloads were for testing purposes, and all downloads were of movies that I already own original media. Since I do own original media, I do not feel that I am infringing on copyrights by downloading a back - up copy.
Lately I have downloaded some TV series and movies and I see the same issues arise. (See my feelings on legality below).
Frame Rates and Program Length
Consistently, I see that programs that should be about 44 minutes in length with commercials cut out, often play back at 40 minutes in length. I pondered this problem a lot, and as a former television technician, I reasonably sure that 44 minutes or so constitutes 1 hour with commercial breaks.
Here is what I finally concluded.... There is a process called 3/2 pull down, where a 24 FPS film is converted to roughly 30 FPS (by inserting an occasional "extra" frame) when transferred to video in North America (NTSC). There is a similar process used in PAL however I have not done all the math exactly, but I did do enough math to identify the problem. Some software, or the users of software, are removing these extra frames. This is not unusual and is a good idea to reduce file size. The problem lies in that the file still is playing back at 25 FPS, not the 24 that it should play back at. Most of these files originated from PAL systems I can tell due to the PAL video sizes. The most annoying part of this problem is that sometimes it is noticeable that the dialog, and motion, on such ripped programs seems hurried. I remember the advent and discussions of a device called the Lexicon in the 80s which performed a similar function for broadcasters and allowed them to pack more commercials in a 1 hour program. I can not emphasize to all of you DVD rippers enough that you need to keep the proper frame rate, which should reflect whether the pulldown was removed or not. If so, the resulting video is 24 FPS , not 25 FPS, and definitely not 30 FPS, as this affects the playback duration and presents the content in a hurried format.
Aspect Ratio and Cropping
I know there are given aspect ratio "standards" but I have seen some home rippers making some serious mistakes. I do not worry about "proper" resolutions so much, as long as the aspect is correct. I recently downloaded some files for testing via torrents. Now in the case of one film in particular , every copy I found had the same butchering to it when it came to aspect ratio. That file which you can find easily is the 1994 film "The Little Rascals" . It was butchered because when downloaded from a torrent, it is in a 16x9 aspect ratio. Hhowever, the DVD that it was ripped from apparently was 4x3, so it was cropped when ripped. The bad part about that is that it was already cropped when presented in 4x3 and cropping it again yields only a fraction of the original frame. When I downloaded and viewed this file it looked very odd to me, although the quality was good tops of heads were frequently cut off, so I connected the old VHS and started comparing my old 4x3 aspect VHS tape of this movie with the downloaded 16x9 version. I should see more on the sides of the 16x9 from , however in this case I see less of the top and bottom. Clearly that file on the torrents (700.18 Meg) was from a 4x3 aspect DVD then cropped to 16x9. This is a horrible mistake for anyone ripping DVDs!
Comments about my downloads
I want to clarify that my downloads were for testing purposes, and all downloads were of movies that I already own original media. Since I do own original media, I do not feel that I am infringing on copyrights by downloading a back - up copy.
Jan 15, 2009
Internet Peering in Mexico - What happens in Mexico should stay in Mexico!
Well after having written the previous post a year ago about Internet peering in Mexico, even more bad news has come to light.
After having tried to use Telecable in Puerto Vallarta, and Telecable in Zapopan for a specific use that would connect two locations together, we see the following
ping -t 201.130.248.XXX
Pinging 201.130.248.XXX with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 201.130.248.XX: bytes=32 time=344ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=338ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=343ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=413ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=303ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=299ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=309ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=337ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=353ms TTL=49
First Packet Loss! Second We see that there is EXCESSIVE latency caused by Protel who chose to ignore the issue because I was not their client directly! Not to mention this example all data goes from Mexico to USA TWICE! First to Level3 then to McAllen Texas via Protel. There is also 200ms of Latency between Laredo and Monterrey!
1 8 ms 7 ms 7 ms 200-56-193-1-cable.cybercable.net.mx [200.56.193.1]
2 43 ms 69 ms 79 ms 148.243.116.10
3 71 ms 84 ms 98 ms dial-200-57-215-25.zone-3.dial.net.mx [200.57.215.25]
4 101 ms 89 ms 63 ms 148.245.252.217
5 84 ms 68 ms 69 ms dial-200-39-230-53.zone-1.dial.net.mx [200.39.230.53]
6 118 ms * 68 ms 200.33.208.129
7 116 ms 108 ms 107 ms pos6/0.rr1.torixt.avantel.net.mx [200.33.208.201]
8 117 ms 93 ms 102 ms 200.33.208.150
9 100 ms 119 ms 99 ms na-224-21.na.avantel.net.mx [148.245.224.21]
10 128 ms 133 ms * so-8-1.car2.Houston1.Level3.net [4.79.90.97]
11 116 ms 118 ms 131 ms ae-2-5.bar2.Houston1.Level3.net [4.69.132.238]
12 130 ms 102 ms 96 ms ae-0-11.bar1.Houston1.Level3.net [4.69.137.133]
13 72 ms 50 ms 76 ms ae-13-13.ebr1.Dallas1.Level3.net [4.69.137.138]
14 117 ms 141 ms 113 ms ae-71-71.csw2.Dallas1.Level3.net [4.69.136.126]
15 123 ms 104 ms 137 ms ae-2-79.edge2.Dallas3.Level3.net [4.68.19.76]
16 128 ms 134 ms 137 ms Tiscali-Level3.Dallas3.Level3.net [4.68.110.158]
17 109 ms * 91 ms protel-inext-gw.ip.tiscali.net [77.67.68.146]
18 91 ms 106 ms 121 ms ge-0-0-0.core01-lar.redip.inext.net.mx [200.52.143.45]
19 293 ms 309 ms 300 ms as-1.core01-mty.redip.inext.net.mx [200.52.143.109]
20 354 ms * 343 ms po-5-0.inext01-slp.redip.inext.net.mx [200.52.143.230]
21 346 ms 328 ms * po-4-0.core01-ira.redip.inext.net.mx [200.52.143.237]
22 334 ms 327 ms 352 ms po-1-0.core01-mcallen.redip.inext.net.mx [200.52.143.225]
23 * 341 ms 365 ms po-2-1.core01-gdl.redip.inext.net.mx [200.52.143.90]
24 348 ms 313 ms 287 ms 134.142.52.200.static.redip.inext.net.mx [200.52.142.134]
25 * * * Request timed out.
26 * * * Request timed out.
27 * 319 ms * 201-130-248-XX-cable.cybercable.net.mx [201.130.248.XX]
28 310 ms 311 ms 296 ms 201-130-248-XX-cable.cybercable.net.mx [201.130.248.XX]
Trace complete.
What an embarrassment!
___________________________________________
UPDATE JAN 17, 2009
Here is the biggest lie that LACNIC could make
http://www.lacnic.net/documentos/lacnicxi/presentaciones/peeringmexico.ppt
GO ahead check it out. Then see the traceroute above and know that Inext refers to Protel that supposedly does peering with Telmex IN MEXICO according to that document. Furthermore here is more proof, and know that this traceroute is from Guadalajara TO Guadalajara.
traceroute to 187.140.21.XXX (187.140.21.XXX), 30 hops max, 40 byte packets
1 10.206.0.1 (10.206.0.1) 10.468 ms 10.491 ms 10.483 ms
2 10.255.255.1 (10.255.255.1) 183.849 ms 184.379 ms 184.971 ms
3 router.cybercable.net.mx (200.53.250.10) 184.142 ms 184.734 ms 184.402 ms
4 45.142.52.200.static.redip.inext.net.mx (200.52.142.45) 185.121 ms 186.734 ms 186.383 ms
5 * * *
6 ge-0-0.core02-lar.redip.inext.net.mx (200.52.143.46) 221.606 ms 260.877 ms 276.338 ms
7 xe-3-1-0-102.dal11.ip.tiscali.net (77.67.68.145) 284.812 ms 284.631 ms 28 5.410 ms
8 xe-2-0-0.sjc10.ip.tiscali.net (89.149.187.189) 310.528 ms 310.724 ms 311. 439 ms
9 xe-0.equinix.snjsca04.us.bb.gin.ntt.net (206.223.116.12) 311.433 ms 311.43 5 ms 311.118 ms
10 as-0.r20.lsanca03.us.bb.gin.ntt.net (129.250.4.97) 321.067 ms 321.714 ms 321.788 ms
11 * * *
12 xe-7-1.r01.lsanca03.us.ce.gin.ntt.net (204.1.253.70) 267.349 ms 267.482 ms 268.159 ms
13 dsl-187-140-21-XXX.prod-infinitum.com.mx (187.140.21.167) 314.538 ms 323.7 40 ms 311.758 ms
Why does LACNIC think we are so stupid? This problem is getting WORSE, NOT BETTER, and it has only been one year since my last post on this topic.
Here is one last bit of proof that there is really no peering IN MEXICO regardless of what the lie of the day is at LACNIC
1 9 ms 7 ms 8 ms 200-56-193-1-cable.cybercable.net.mx [200.56.193.1]
2 9 ms 8 ms 8 ms 148.243.116.10
3 79 ms 72 ms 62 ms dial-200-57-215-25.zone-3.dial.net.mx [200.57.215.25]
4 13 ms 13 ms 16 ms 148.245.252.217
5 26 ms 23 ms 38 ms dial-200-39-230-53.zone-1.dial.net.mx [200.39.230.53]
6 55 ms 60 ms 101 ms 200.33.208.129
7 46 ms 46 ms 46 ms SAT1.ALTER.NET [63.65.121.165]
8 44 ms 45 ms 46 ms 0.so-4-1-0.XL4.SAT1.ALTER.NET [152.63.97.194]
9 104 ms 112 ms * 0.so-7-0-0.XT2.LAX7.ALTER.NET [152.63.115.237]
10 82 ms 82 ms 80 ms GigabitEthernet7-0-0.GW7.LAX7.ALTER.NET [152.63.118.53]
11 75 ms 73 ms 76 ms telmex-gw.customer.alter.net [157.130.246.70]
12 76 ms 77 ms 74 ms iadsl-jal-bandera-16-ge7-0-0.uninet.net.mx [201.125.11.240]
13 126 ms 135 ms 109 ms dsl-187-140-21-XXX.prod-infinitum.com.mx [187.140.21.XXX]
The peering here again also seems to be in USA.'
I welcome a reply from LACNIC on this subject.
_________________________________________________
UPDATE January 29, 1009
LACNIC replied and the complete response is in the comments section, as well as my follow up. The short version is that apparently the powerpoint document referenced is not an official LACNIC document. I must then ask, why then is it posted on the LACNIC web site?
Secondly, The document refers to "ISP Peering in Mexico", not "Mexican ISP Peering in the USA" The difference again is the latency and at least one of the traceroutes shows that data is apparently being handed off in the USA between Mexican ISPs. It does therefore NOT qualify as "ISP Peering in Mexico", although may involve Mexican ISPs peering in the USA.
Thirdly, the peering diagram on page 6 also does not involve PURELY ISP peering. A closer look at those companies indicates that most, if not all are involved in telephone traffic. Now that more providers are using VoIP those "private connections" are more suitable for telephone traffic as they are more direct than sending the traffic to the internet. ^The latency involved , and unknown variables of the internet (via other connections) are less desirable, so naturally those ISPS (really meaning telcos) are filling those private connections to full capacity with telephone calls, and leaving little or no capacity for real dedicated internet peering.
I think a good possible solution is that some neutral organization needs to be created and ANY Licensed internet provider should be REQUIRED to interconnect through this independent third party in a major city such as Guadalajara or Mexico DF. Monterrey is too far to the north for most users in Mexico in my opinion. These mandatory internet connections should NOT BE USED FOR INTRA-CARRIER TELEPHONE TRAFFIC! Instead, they should be pure internet peering, and may be used for intra-carrier telephone traffic, only when saturated less than 50% to BOTH carriers involved. For example, if the bestel connection was at 80% average and the Avantel was at 40% Avantel should not send traffic to Bestel through this new peering route. If BOTH however were at 30% , then they may saturate it with internet and telephone traffic up to 70% however giving priority to INTERNET traffic, and use their own direct interconnections for telephone peering.
The example of these "peering" connections, is a perfect example of the types of conflicts of interests that hold Mexico back , and are ridden with the anti-competitive attitudes. This backward thinking should not hold back the evolution of the internet in Mexico and we should take steps to ensure that internet growth and performance in Mexico is more controlled. To do this the assistance of COFETEL and/or SCT will be necessary to make new requirements to ensure proper growth of the internet IN MEXICO as internet demand increases IN MEXICO. AT the same time, this new independent organization should also begin to interconnect internationally where necessary, specifically making more direct international connections that do not rely on sending traffic destined to Argentina via the USA. With this new philosophy we can give Mexico its own internet backbone, and Mexico can begin to lead the way in offering internet solutions such as hosting FROM MEXICO for all of Latin America, as well as serve as a robust gateway for traffic destined for the USA. Mexico makes an appropriate "internet gateway" to the USA from the rest of Latin America for it's physical proximity to the USA.
This all goes along with another one of my beliefs : WE AS MEXICANS, should not look to go where life is better, but to make MEXICO a better place to live!
________________________________________________________________________________
UPDATE February 1, 2009
After making this post and ranting about these problems with Protel, LACNIC, Telecable, and many others this page as received visits from many of those organizations, and I am happy to report that the situation has improved. By my most recent tests on the Telecable Puerto Vallarta / Telecable Guadalajara connection show an average of about 150ms. Previously it was twice that! I can say however I have not performed a single traceroute that showed domestic peering to date. I have seen Mexican providers peering, but those connections appear to be in the USA, which is not "Mexico Peering" .
I also want to point out that a part of this Telecable issue stems from the fact that they use one provider in Guadalajara and another in Puerto Vallarta and have none of their own infrastructure between those two cities, to keep data from Telecable to Telecable on their own network. Instead they route it to the respective providers in each city, who route it to the USA and back to Mexico again. EVERY licensed provider that operates in multiple cities should be required to have their own infrastructure for data from their network to their network, or they are only contributing to the problem.
After having tried to use Telecable in Puerto Vallarta, and Telecable in Zapopan for a specific use that would connect two locations together, we see the following
ping -t 201.130.248.XXX
Pinging 201.130.248.XXX with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 201.130.248.XX: bytes=32 time=344ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=338ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=343ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=413ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=303ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=299ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=309ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=337ms TTL=49
Reply from 201.130.248.XX: bytes=32 time=353ms TTL=49
First Packet Loss! Second We see that there is EXCESSIVE latency caused by Protel who chose to ignore the issue because I was not their client directly! Not to mention this example all data goes from Mexico to USA TWICE! First to Level3 then to McAllen Texas via Protel. There is also 200ms of Latency between Laredo and Monterrey!
1 8 ms 7 ms 7 ms 200-56-193-1-cable.cybercable.net.mx [200.56.193.1]
2 43 ms 69 ms 79 ms 148.243.116.10
3 71 ms 84 ms 98 ms dial-200-57-215-25.zone-3.dial.net.mx [200.57.215.25]
4 101 ms 89 ms 63 ms 148.245.252.217
5 84 ms 68 ms 69 ms dial-200-39-230-53.zone-1.dial.net.mx [200.39.230.53]
6 118 ms * 68 ms 200.33.208.129
7 116 ms 108 ms 107 ms pos6/0.rr1.torixt.avantel.net.mx [200.33.208.201]
8 117 ms 93 ms 102 ms 200.33.208.150
9 100 ms 119 ms 99 ms na-224-21.na.avantel.net.mx [148.245.224.21]
10 128 ms 133 ms * so-8-1.car2.Houston1.Level3.net [4.79.90.97]
11 116 ms 118 ms 131 ms ae-2-5.bar2.Houston1.Level3.net [4.69.132.238]
12 130 ms 102 ms 96 ms ae-0-11.bar1.Houston1.Level3.net [4.69.137.133]
13 72 ms 50 ms 76 ms ae-13-13.ebr1.Dallas1.Level3.net [4.69.137.138]
14 117 ms 141 ms 113 ms ae-71-71.csw2.Dallas1.Level3.net [4.69.136.126]
15 123 ms 104 ms 137 ms ae-2-79.edge2.Dallas3.Level3.net [4.68.19.76]
16 128 ms 134 ms 137 ms Tiscali-Level3.Dallas3.Level3.net [4.68.110.158]
17 109 ms * 91 ms protel-inext-gw.ip.tiscali.net [77.67.68.146]
18 91 ms 106 ms 121 ms ge-0-0-0.core01-lar.redip.inext.net.mx [200.52.143.45]
19 293 ms 309 ms 300 ms as-1.core01-mty.redip.inext.net.mx [200.52.143.109]
20 354 ms * 343 ms po-5-0.inext01-slp.redip.inext.net.mx [200.52.143.230]
21 346 ms 328 ms * po-4-0.core01-ira.redip.inext.net.mx [200.52.143.237]
22 334 ms 327 ms 352 ms po-1-0.core01-mcallen.redip.inext.net.mx [200.52.143.225]
23 * 341 ms 365 ms po-2-1.core01-gdl.redip.inext.net.mx [200.52.143.90]
24 348 ms 313 ms 287 ms 134.142.52.200.static.redip.inext.net.mx [200.52.142.134]
25 * * * Request timed out.
26 * * * Request timed out.
27 * 319 ms * 201-130-248-XX-cable.cybercable.net.mx [201.130.248.XX]
28 310 ms 311 ms 296 ms 201-130-248-XX-cable.cybercable.net.mx [201.130.248.XX]
Trace complete.
What an embarrassment!
___________________________________________
UPDATE JAN 17, 2009
Here is the biggest lie that LACNIC could make
http://www.lacnic.net/documentos/lacnicxi/presentaciones/peeringmexico.ppt
GO ahead check it out. Then see the traceroute above and know that Inext refers to Protel that supposedly does peering with Telmex IN MEXICO according to that document. Furthermore here is more proof, and know that this traceroute is from Guadalajara TO Guadalajara.
traceroute to 187.140.21.XXX (187.140.21.XXX), 30 hops max, 40 byte packets
1 10.206.0.1 (10.206.0.1) 10.468 ms 10.491 ms 10.483 ms
2 10.255.255.1 (10.255.255.1) 183.849 ms 184.379 ms 184.971 ms
3 router.cybercable.net.mx (200.53.250.10) 184.142 ms 184.734 ms 184.402 ms
4 45.142.52.200.static.redip.inext.net.mx (200.52.142.45) 185.121 ms 186.734 ms 186.383 ms
5 * * *
6 ge-0-0.core02-lar.redip.inext.net.mx (200.52.143.46) 221.606 ms 260.877 ms 276.338 ms
7 xe-3-1-0-102.dal11.ip.tiscali.net (77.67.68.145) 284.812 ms 284.631 ms 28 5.410 ms
8 xe-2-0-0.sjc10.ip.tiscali.net (89.149.187.189) 310.528 ms 310.724 ms 311. 439 ms
9 xe-0.equinix.snjsca04.us.bb.gin.ntt.net (206.223.116.12) 311.433 ms 311.43 5 ms 311.118 ms
10 as-0.r20.lsanca03.us.bb.gin.ntt.net (129.250.4.97) 321.067 ms 321.714 ms 321.788 ms
11 * * *
12 xe-7-1.r01.lsanca03.us.ce.gin.ntt.net (204.1.253.70) 267.349 ms 267.482 ms 268.159 ms
13 dsl-187-140-21-XXX.prod-infinitum.com.mx (187.140.21.167) 314.538 ms 323.7 40 ms 311.758 ms
Why does LACNIC think we are so stupid? This problem is getting WORSE, NOT BETTER, and it has only been one year since my last post on this topic.
Here is one last bit of proof that there is really no peering IN MEXICO regardless of what the lie of the day is at LACNIC
1 9 ms 7 ms 8 ms 200-56-193-1-cable.cybercable.net.mx [200.56.193.1]
2 9 ms 8 ms 8 ms 148.243.116.10
3 79 ms 72 ms 62 ms dial-200-57-215-25.zone-3.dial.net.mx [200.57.215.25]
4 13 ms 13 ms 16 ms 148.245.252.217
5 26 ms 23 ms 38 ms dial-200-39-230-53.zone-1.dial.net.mx [200.39.230.53]
6 55 ms 60 ms 101 ms 200.33.208.129
7 46 ms 46 ms 46 ms SAT1.ALTER.NET [63.65.121.165]
8 44 ms 45 ms 46 ms 0.so-4-1-0.XL4.SAT1.ALTER.NET [152.63.97.194]
9 104 ms 112 ms * 0.so-7-0-0.XT2.LAX7.ALTER.NET [152.63.115.237]
10 82 ms 82 ms 80 ms GigabitEthernet7-0-0.GW7.LAX7.ALTER.NET [152.63.118.53]
11 75 ms 73 ms 76 ms telmex-gw.customer.alter.net [157.130.246.70]
12 76 ms 77 ms 74 ms iadsl-jal-bandera-16-ge7-0-0.uninet.net.mx [201.125.11.240]
13 126 ms 135 ms 109 ms dsl-187-140-21-XXX.prod-infinitum.com.mx [187.140.21.XXX]
The peering here again also seems to be in USA.'
I welcome a reply from LACNIC on this subject.
_________________________________________________
UPDATE January 29, 1009
LACNIC replied and the complete response is in the comments section, as well as my follow up. The short version is that apparently the powerpoint document referenced is not an official LACNIC document. I must then ask, why then is it posted on the LACNIC web site?
Secondly, The document refers to "ISP Peering in Mexico", not "Mexican ISP Peering in the USA" The difference again is the latency and at least one of the traceroutes shows that data is apparently being handed off in the USA between Mexican ISPs. It does therefore NOT qualify as "ISP Peering in Mexico", although may involve Mexican ISPs peering in the USA.
Thirdly, the peering diagram on page 6 also does not involve PURELY ISP peering. A closer look at those companies indicates that most, if not all are involved in telephone traffic. Now that more providers are using VoIP those "private connections" are more suitable for telephone traffic as they are more direct than sending the traffic to the internet. ^The latency involved , and unknown variables of the internet (via other connections) are less desirable, so naturally those ISPS (really meaning telcos) are filling those private connections to full capacity with telephone calls, and leaving little or no capacity for real dedicated internet peering.
I think a good possible solution is that some neutral organization needs to be created and ANY Licensed internet provider should be REQUIRED to interconnect through this independent third party in a major city such as Guadalajara or Mexico DF. Monterrey is too far to the north for most users in Mexico in my opinion. These mandatory internet connections should NOT BE USED FOR INTRA-CARRIER TELEPHONE TRAFFIC! Instead, they should be pure internet peering, and may be used for intra-carrier telephone traffic, only when saturated less than 50% to BOTH carriers involved. For example, if the bestel connection was at 80% average and the Avantel was at 40% Avantel should not send traffic to Bestel through this new peering route. If BOTH however were at 30% , then they may saturate it with internet and telephone traffic up to 70% however giving priority to INTERNET traffic, and use their own direct interconnections for telephone peering.
The example of these "peering" connections, is a perfect example of the types of conflicts of interests that hold Mexico back , and are ridden with the anti-competitive attitudes. This backward thinking should not hold back the evolution of the internet in Mexico and we should take steps to ensure that internet growth and performance in Mexico is more controlled. To do this the assistance of COFETEL and/or SCT will be necessary to make new requirements to ensure proper growth of the internet IN MEXICO as internet demand increases IN MEXICO. AT the same time, this new independent organization should also begin to interconnect internationally where necessary, specifically making more direct international connections that do not rely on sending traffic destined to Argentina via the USA. With this new philosophy we can give Mexico its own internet backbone, and Mexico can begin to lead the way in offering internet solutions such as hosting FROM MEXICO for all of Latin America, as well as serve as a robust gateway for traffic destined for the USA. Mexico makes an appropriate "internet gateway" to the USA from the rest of Latin America for it's physical proximity to the USA.
This all goes along with another one of my beliefs : WE AS MEXICANS, should not look to go where life is better, but to make MEXICO a better place to live!
________________________________________________________________________________
UPDATE February 1, 2009
After making this post and ranting about these problems with Protel, LACNIC, Telecable, and many others this page as received visits from many of those organizations, and I am happy to report that the situation has improved. By my most recent tests on the Telecable Puerto Vallarta / Telecable Guadalajara connection show an average of about 150ms. Previously it was twice that! I can say however I have not performed a single traceroute that showed domestic peering to date. I have seen Mexican providers peering, but those connections appear to be in the USA, which is not "Mexico Peering" .
I also want to point out that a part of this Telecable issue stems from the fact that they use one provider in Guadalajara and another in Puerto Vallarta and have none of their own infrastructure between those two cities, to keep data from Telecable to Telecable on their own network. Instead they route it to the respective providers in each city, who route it to the USA and back to Mexico again. EVERY licensed provider that operates in multiple cities should be required to have their own infrastructure for data from their network to their network, or they are only contributing to the problem.
Jan 2, 2009
VoLAN and WiFi Can create some exciting possibilities
Recently I had the opportunity to devise a sysyem for VoLAN (Voice over LAN) to offer a very unique solution.
The details of the project can be found at:
http://www.teknogeekz.com/RemoteDoorWifiSIP.htm , however I have posted a basic diagram below.
The project employed a unique device from Cyberdata which is a doorbell intercom. The wireless router shown is an over-simplification of the extensive Wireless Network that was already on site. Clearly the applications for SIP are growing when we begin to see devices available that have such limited, although useful applications such as the CyberData Intercom. What impressed me more however was the QuickPhones WiFI Handset , specifically it's Peer to Peer mode.
Part of the reason why this was such a good solution was the existing WiFi infrastructure that gave us better coverage than any long range cordless phone would have.
Since these devices were not relying on a server, we used P2P mode. The QuickPhones offers a P2P mode that allows IP address dialing via it's Phone book feature. This allowed us to set up multiple destinations instead of a "hotline" from the WiFi phone. This gave us the unexpected but much appreciated possibility of having more than one destination accessible from the WiFi handset. With a system like this one can easily establish intercom and possible PBX like functionality with no server, even with the functionality of PSTN lines via a device like an SPA 3102.
In the coming months I hope to have more time to explore such possibilities, and if any readers have any comments on the P2P functionality of the Quickphones , I would like to hear comments.
The details of the project can be found at:
http://www.teknogeekz.com/RemoteDoorWifiSIP.htm , however I have posted a basic diagram below.
The project employed a unique device from Cyberdata which is a doorbell intercom. The wireless router shown is an over-simplification of the extensive Wireless Network that was already on site. Clearly the applications for SIP are growing when we begin to see devices available that have such limited, although useful applications such as the CyberData Intercom. What impressed me more however was the QuickPhones WiFI Handset , specifically it's Peer to Peer mode.Part of the reason why this was such a good solution was the existing WiFi infrastructure that gave us better coverage than any long range cordless phone would have.
Since these devices were not relying on a server, we used P2P mode. The QuickPhones offers a P2P mode that allows IP address dialing via it's Phone book feature. This allowed us to set up multiple destinations instead of a "hotline" from the WiFi phone. This gave us the unexpected but much appreciated possibility of having more than one destination accessible from the WiFi handset. With a system like this one can easily establish intercom and possible PBX like functionality with no server, even with the functionality of PSTN lines via a device like an SPA 3102.
In the coming months I hope to have more time to explore such possibilities, and if any readers have any comments on the P2P functionality of the Quickphones , I would like to hear comments.
Sep 21, 2008
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.
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.
Sep 19, 2008
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
Aug 24, 2008
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.
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.
Jun 22, 2008
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.
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.
May 8, 2008
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
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
Subscribe to:
Posts (Atom)