Canon Driver Issues: Installation, Usage

For a Canon MG series printer (specifically, the MG5320, but probably applicable to all MG printers), the following issues may arise when trying to install and use the printer software on Windows 8 (and perhaps Windows 7):

 
 

Issues:

1. The three most-used and most useful pieces of software to download from Canon are:
   
   1. Mast-win-mg5300-xxx.exe
      
      1. The main driver installation. Can print after this is installed.
         
   2. Mpnx_xxx-win-mg5300-xxx.exe
      
      1. The Navigator EX software. This application is used for scanning and to manage the printer, etc.
         
   3. Xp68-win-mg5300-xxx.exe
      
      1. The XPS printer driver, if you want to print using the higher-resolution XPS format.
         
2. Installation problem: “Administrator Account needed”
   
   1. The mast-win installation program may complain that the installation can not proceed unless you are logged in as an administrator. You may get this message even if you ARE logged in as an administrator. You have to be logged into a local administrator account….a domain administrator account will not work. Go figure!
      
3. Trying to start a scan from the printer itself results in a “set the pc to start scanning” message on the printer’s LCD.
   
   1. This happens if the Navigator EX software is not running first on the PC. Navigator EX can be started first by the user, or if the Canon “My printer” software is installed (“Program Files\Canon\MyPrinter”, which is a link to BJMYPRT.exe /mn), then the My Printer monitor software will start Navigator EX automatically.
      

Inexpensive Replacement Part for Munchkin Residential Boiler.

I have a Munchkin (Heat Transfer Products, www.htproducts.com) high efficiency boiler that heats the water for the hot water radiant heating system in my home. The system works great and seems to be very efficient. The boiler system includes an outdoor temperature sensor: when the weather is colder, the system heats the water hotter, when the weather is warmer, it doesn’t heat the water as much, saving gas.
Recently (after about a year and half of use), the outdoor temperature sensor malfunctioned. The sensor was telling the boiler that it was very warm outside (when it wasn’t). The reading was high enough that the boiler decided it didn’t make sense to heat the water anymore. The house grew cold.
The Munchkin boiler includes a diagnostic LED panel that made it possible to quickly determine the outdoor sensor was providing erroneous readings.
I checked with the local dealer about a replacement outdoor sensor (Munchkin part number MUP-7205P-319). The cost was $60. Online distributors were charging a similar amount.
The outdoor sensor is nothing more than a plastic housing over a thermistor that is soldered to a wire-connector. In other words, the only thing inside the housing is a $0.45 thermistor. I ordered a NTC 12Kohm (at 25 degrees centigrade) thermistor from Digikey.com, removed the old thermistor, and soldered the new thermistor to the wire connector. The new thermistor, in the old outdoor sensor housing, is working just fine. The boiler is getting the correct outdoor temperature and the house is being heated. An easy replacement that costs only 45 cents as opposed to 60 dollars.
The specific thermistor looks like this:

It’s Vishay part NTCLE100E3123HB0. I ordered the part from online retailer digikey.com, where it’s Digikey Part number BC2400-ND.

Windows Live Mesh (and Skydrive) and Shared/Synced Folders

Windows Live Mesh allows you to keep files/folders in sync across multiple computers you own and even with other people.

 

 

Overview.

1. Decide on a folder to share.
2. Run Windows Live Mesh app on the pc containing the folder.
3. Tell Windows Live Mesh app to sync the folder.
4. It is possible to tell live.com to share the folder with other people
   1. Either directly from the “skydrive/synced folders” area of live.com,
   2. Or from the live mesh app, to share the folder with other users (by editing permissions).

    

Characteristics:

1. Last write wins (with protection for loser).
   1. If a file, say myfile.txt, is modified by two people at the same time and then each file syncs, then the last written file becomes the official version.
   2. However, the loser (who wrote the modified first, but the modification was not picked up by the winner before the winner started their edit), does not lose his version of the file. The loser’s version of the file will be named “myfile (live-id@live.com).txt”. In other words, the login name of the loser will be appended to the main part of the file name and that version of the file will now be part of the sync folder.
   3. Both people will see the two files, the official version ( “myfile.txt”)and the loser’s version (“myfile (live-id@live.com).txt”).
2. In general, it appears that “saving” a file (e.g. the save command in Excel) will not cause a sync event to happen, however, closing the file (e.g. closing the excel file in Excel) will cause a sync event to happen.
3. It is possible to see the synced files on live.com website, but need to manually refresh to see the latest files if a sync has happened since the page was last loaded.
4. The shared, synced folder will appear in “Synced folders” area of each user’s skydrive.
5. Each user’s skydrive synced folder can be synced with multiple, different devices. (Or no devices and only stay on skydrive.)
   1. E.g. User Betty can share the folder “family photos” with user Fred.
      1. User Better can sync “family photos” with the devices called “betty computer1” and “betty computer2”.
      2. User Fred can sync “family photos” with devices called “fred computer1” and “fred computer2”.

 

Bugs

1. There seems to be a bug with Windows Live Mesh Version 2011 (Build 15.4.3502.0922). If you have Outlook connected to Windows Live (with Outlook Connector) and have a contact with more than 1 email. And if you try to share a sync folder with that contact, the invite will get set only to the first email address for the contact, regardless of which email address you put into the share with field on live.com.

 

IPv6, 6RD, and a DD-WRT router with a 6to4 tunnel

I have repeated the 6to4/6RD interop experiment, this time using a DD-WRT router instead of a Windows 7 host. (The specific router was a Linksys WRT160n running DD-WRT v24-sp2 (01/02/10) std-nokaid-small, build 13575.) The outcome was positive for the DD-WRT router: it performed as theory would suggest: only minor configuration changes were necessary to turn the DD-WRT router into a working 6RD customer equipment host.

 
 

With two different IPv6 6to4 tunnel implementations we have had apparent success configuring the routers with only minor changes to enable deployment in a 6RD domain. It’s nice to actually see the expected behavior.

Further Ruminations on Comcast’s 6rd: a small experiment

I previously discussed the possibility of participating in a 6RD-based IPv6 deployment using only a router with a generic 6to4 implementation.

 
 

Since 6RD is based on 6to4, with a few enhancements for ISP configuration and management, there was some speculation that it would be possible to use a router with only a 6to4 implementation as part of a 6RD deployment. The details of that thought experiment are available here: https://tuketu.wordpress.com/2010/04/20/ruminations-on-comcasts-ipv6-trials-6rd-at-comcast/.

 
 

I have since performed an experiment to validate this thinking. The experiment, while not definitive, suggests that the thesis may be correct: it may be possible to use a generic 6to4 router as a participant in a 6RD-based IPv6 deployment. Certain experimental limitations prevent a more definitive answer.

 
 

In the experiment, a generic Windows 7 PC is used as the customer premises router. Windows 7 includes a 6to4 tunnel implementation. Indeed, by default, a Windows 7 PC with a public IPv4 address will automatically configure a 6to4 IPv6 tunnel based on the public IPv4 address.

 
 

In the experiment test-bed the Windows 7 PC is the 6RD customer equipment host (the 6RD host). The 6RD host is connected, over an IPv4-only network of routers, to a router that represents the ISP’s 6RD relay router. The 6RD relay router is connected over an IPv6-only network, to a host we call the IPv6 destination. The object is to successfully ping from the 6RD host to the IPv6 destination.

 
 

The following figure depicts the experiment test-bed:

 
 

 
 

 
 

 
 

The information necessary to configure a 6RD host for participation in a 6RD domain deployment is contained in the DHCPv4 option_6RD extension, and consists of:

1. IPv4MaskLen The number of high-order bits that are identical
   across all CE IPv4 addresses within a given 6rd
   domain. This may be any value between 0 and 32.
   Any value greater than 32 is invalid.
   
2. 6rdPrefixLen The IPv6 Prefix length of the SP’s 6rd IPv6
   prefix in number of bits. For the purpose of
   bounds checking by DHCP option processing, the
   sum of (32 – IPv4MaskLen) + 6rdPrefixLen MUST be
   less than or equal to 128.
   
3. 6rdBRIPv4Address One or more IPv4 addresses of the 6rd Border
   Relay(s) for a given 6rd domain.
   
4. 6rdPrefix The Service Provider’s 6rd IPv6 prefix
   represented as a 16 octet IPv6 address. The bits
   after the 6rdPrefixlen number of bits in the
   prefix SHOULD be set to zero.
   

   Using the following values for the 6RD domain, we obtain the tunnel configurations specified in the figure. 

5. 6rdPrefix: 2001:558:: (this is Comcast’s actual IPv6 prefix).
   
6. 6rdPrefixLen: 31 (Comcast is assigned a /31. The actual value used in their 6RD deployment may be larger.
   
7. IPv4MaskLen: 32
   
8. 6rdBRIPv4Address: 1.0.0.1
   

    
    

   The actual values for these parameters don’t particularly matter. However, the use of a prefix other than 6to4’s prefix of 2002::, and a prefix length different (longer) than 6to4’s prefix length of 16 is really what we want to test with the experiment. It would also be useful to test with a IPv4MaskLen less than 32, but the experiment did not test this configuration.

    
    

   In the first experiment we do the following:

9. First we configure the 6RD host according to the 6RD domain configuration.
   
   1. Configure the default gateway of the 6to4 tunnel according to the IPv4 address of the 6RD relay router (1.0.0.1).
      1. c:\> netsh interface ipv6 6to4 set relay 1.0.0.1 enabled
   2. Add an address to the 6to4 tunnel corresponding to the 6RD prefix, prefix length, and the 6RD host’s public IPv4 (1.0.1.2)
      1. c:\> netsh interface ipv4 add address interface=”6to4 Adapter” address=1001:558:200:204::100:102
         1. Note: we use the convention that the network interface portion of the IPv6 address for a tunnel is the IPv4 address.
   3. These are the only two changes necessary from the default 6to4 configuration.
10. We ping from the 6RD host to the IPv6 destination:
    
    1. c:\> ping 2001:558::3
11. By packet sniffing on the 6RD relay router, we observe the following:
    
    1. A packet leaves the 6RD host, goes over the 6to4 tunnel (over IPv4) to the 6RD pseudo relay router.
       1. This packet, when decapsulated from the tunnel, has a source address of 2001:558:200:204::100:102. The destination address is 2001:558::3. This is a correctly functioning configuration.
    2. The IPv6 destination sends back an ICMPv6 echo reply packet (normal behavior).
       1. This packet has a source address of 2001:558::3 and a destination address of 2001:558:200:204::100:102.
    3. The 6RD pseudo relay router doesn’t know how to route to 2001:558:200:204::100:102 and thus sends back to the IPv6 destination an ICMPv6 destination unreachable packet. Given the limitations of the test environment, in which we are using a 6to4 relay router to simulate the ISP’s 6RD relay router, this is expected behavior. The 6RD pseudo relay router in the experiment is just a configured 6to4 relay router, and as such it doesn’t properly deal with a packet addressed to 2001:558:200:204::100:102. It doesn’t know the proper bit boundaries to extract the IPv4 address of the 6RD host. In an actual 6RD deployment, the ISP’s 6RD relay router would know the proper bit boundaries to be able to determine the IPv4 address of the 6RD host from the IPv6 destination address of the echo reply packet.

        
        

    To better simulate the complete round-trip, we ran a second experiment in which we fudge things a bit by using an different 6RD domain specification. In the second experiment, we use a 6rdPrefixLength of 16, creating a bit-boundary at the same position as a normal 6to4 configuration. We continue to use 2001-based prefix. Therefore we do 2 things:

12. We use a 6RD domain specification of
    
    1. 6RD prefix of 2001::
    2. 6RD prefix length of 16
    3. IPv4 address of 1.0.1.2
    4. IPv4 mask length of 32
13. We add a new router table entry on the 6to4/pseudo 6rd relay router. This /128 route (for the 6rd host) specifies a next hop of the 6rd host’s 6to4 tunnel endpoint, over the 6to4 relay router’s 6to4 tunnel interface. This is just an experiment hack to tell the 6to4 relay router how to deal with incoming IPv6 packets that are addressed to the 6rd host: send them over the 6rd tunnel to the 6rd host.
    

     
     

    This 6rd domain specification results in an IPv6 address of 2001:100:102::100:102 on the 6rd host.

    We add this address to the 6to4 tunnel on the 6rd host.

     
     

    We now, from the 6rd host, ping the IPv6 destination.

     
     

14. c:\> : ping 2001:558::3
    
15. By packet sniffing on the 6RD relay router, we observe the following:
    
    1. The 6to4 relay router decapsulates an IPv6 packet, source address 2001:100:102::100:102, destination address 2001:558::3 from the 6to4 tunnel. The relay router forward this on to the IPv6 destination, which sends back an ICMPv6 echo reply, addressed to 2001:100:102::100:102.
    2. The 6to4 relay router encapsulates the ICMPv6 echo reply into an IPv4 packet and forwards it to the 6RD host using a tunnel over the IPv4 network. The packet in the tunnel has a destination address of 2001:100:102::100:102 and a source address of 2001:558::3.
    3. The 6rd host’s 6to4 tunnel decapsulates the IPv6 packet and delivers it to the ping process, which reports the ping reply. Everything works.

     
     

    Conclusion

    The experiments demonstrate that there is a good chance that a generic 6to4 IPv6 implementation may be able to participate in a 6RD-based IPv6 deployment.

     
     

    Possibilities for further research:

16. Replace the 6RD Pseudo relay router with an actual 6RD relay router implementation. This should provide a more-or-less definitive answer and allow testing with an IPv4MaskLen less than 32.
    
17. Experiment with other 6to4 router implementations, to determine if they function in a like manner. In particular, a consumer router device, say a DD-WRT equipped router, would be a good choice.
    

     
     

     
     

     
     

Comcast and 6rd: Ruminations.

Ok, a little thought experiment. 

Comcast’s IPv6 assignment is 2001:558::/31. (Meaningless juvenile comment: “Ha, those scalawags at Verizon only snagged a /32!”) This gives Comcast north of 8 billion /64’s to hand out. If Comcast decided to dedicate a full 32 bit IPv4 address in their 6rd addressing scheme, that would consume half of their address space, leaving a little north of 4 billion /64’s to use outside of their 6rd deployment. They would be dividing their IPv6 space into two categories, “6rd”, and “other”. Of course, at some point the 6rd address space would be reclaimed, but trying to think of when makes my head hurt. Comcast would, in this scenario, be limited to handing out a /64 (no subnets) to their 6rd customers.

 Free, the French ISP, had the luxury of a /26 IPv6 address space. They used 2 bits to divide their address space into 4 categories, assigned 1 category to their 6rd deployment, and managed to pass out a /60 to their 6rd customers (nice!).

 I suspect Comcast may try to aggregate their IPv4 space, thus using less than a full 32 bits of IPv4 address in the 6rd addresses. This would conserve their IPv6 space for use outside 6rd and would potentially make it possible to hand out subnet-able prefixes to their 6rd customers. However, I haven’t really thought about how feasible this aggregation would be.

Ruminations on Comcast’s IPv6 Trials (6rd at Comcast)

Comcast has announced upcoming IPv6 trials, and has provided some helpful information at their www.comcast6.net web site (which, encouraging enough, is accessible via IPv6). They are undertaking a multi-pronged approach to IPv6, but it appears that a major focus for residential IPv6 access will be via the 6rd mechanism.

 
 

The French ISP, Free, was able to roll out IPv6 access in a rapid manner using 6rd. They had the advantage of control over the customer equipment (CE), and it is my understanding that they used their ability to modify the CE firmware to facilitate their support of 6rd.

 
 

I suspect that Comcast, in the initial 6rd trials, may also rely on a custom CE to support their IPv6 trial. Note that to support 6rd a special cable modem is not required…any functioning cable modem in the Comcast environment should work , unless I’m overlooking something. Certainly 6to4 works fine without any special cable modem support, and thus, 6rd, as an extension of 6to4, should work without any special modem requirement.

 
 

A question that arises is: what special requirements are necessary at the CE to support Comcast’s 6rd trials? And is it possible to configure, possibly manually, a generic router (say, for example something as generic as a computer running windows) to operate within Comcast’s 6rd environment? We don’t know the exact details of Comcast’s 6rd environment, so what follows is speculative.

 
 

For 6rd support, each CE must be configured with the following configuration elements. (Presumably this configuration information will be provisioned by the “option_6rd” extension to DHCPv4, but that’s just a guess.):

1. 6rdPrefix
   1. The IPv6 prefix for a given 6rd domain.
2. 6rdPrefixLen
   1. The length of the 6rd IPv6 prefix for a given 6rd domain.
3. IPv4MaskLen
   1. The number of high-order bits that are identical (aggregateable) across all CE IPv4 addresses within a given 6rd domain.
4. 6rdBRIPv4Address
   1. The IPv4 address for the 6rd Border Relay (BR) for a given 6rd domain.

    
    

Armed with this information, a CE would configure a 6to4 (6rd) tunnel with the following characteristics:

1. The tunnel address:
   [6rdPrefix/6rdPrefixLen]:[IPv4 public address of the CE/IPv4MaskLen]:[subnet id, if any/64-(6rdPrefixLen + IPv4MaskLen)]:[32-bits of zeros]:[IPv4 public address of CE]
   Note we are assuming the interface ID of the tunnel would be [32-bits of zeros]:[full IPv4 public address of CE]. This assumption is not central to the discussion.
2. A default gateway for the tunnel (and default route in the routing table) of
   [6rdPrefx/6rdPrefixLen]:[6rd BR IPv4 public address (possibly an IPv4 anycast address)]::[6rd BR IPv4 public address]

 
 

Given this configuration, would a generic 6to4 Tunnel implementation, such as is supported in Vista, Windows 7, and DD-WRT equipped routers, among others, function in this 6rd environment? If such was the case, participation in the IPv6 trial would not require anything special other than the knowledge of how to properly configure a 6to4 Tunnel. Note that the 6rd configuration elements are all long-lived. Once manually configured, it would be rare that a change was necessary.

 
 

Two possible problems are immediately apparent:

1. 6to4 Tunneling mechanisms expect their tunnels to have an IPv6 address of the following form:
   2002: [IPv4 public address of the Tunnel host]
   1. In particular standard 6to4 tunnels expect a “2002” initial prefix and a full 32 bit IPv4 address.
   2. Will they be confused by an initial prefix other than “2002” and potentially greater than 16 bits in length?
   3. Will they be confused by an IPv4 component in their IPv6 address that is less than 32 bits?
   4. The speculative answer to these questions is, possibly not. The CE tunnel doesn’t do any special processing with it’s own IPv6 address. That is, it doesn’t have to parse its IPv6 address into its constituent parts. It is up to the 6RD BR to parse the address, which it does to tunnel IPv6 packets coming from outside the ISP and destined to the CE. As far as the CE is concerned, its IPv6 tunnel address is just a source IPv6 that it needs to place in outgoing protocol 41 encapsulated packets.
2. 6to4 tunneling mechanisms do need to parse the default gateway address.
   1. In particular, they expect a 16 bit prefix (2002), followed by a full 32-bit public IPv4 address of the BR. If the 6rdPrefixLen is different than 16 bits, then the generic 6to4 tunnel mechanism will be looking in the wrong place for the public IPv4 address of the BR.
   2. This problem probably means that a generic 6to4 tunnel implementation would not work with a standard 6rd configuration in Comcast’s 6rd environment.
   3. This problem could potentially be mitigated if the Comcast 6rd BR also advertised and responded to the 6to4 equivalent IPv6 address: [2002]:[IPv4 public address of the BR]::[IPv4 public address of the BR]. In actuality, it may be enough to just configure the CE tunnel with the standard 6to4 address ([2002]:[IPv4 public address of the BR]) of the 6rd BR.

 
 

Comments?

 
 

 
 

Google Voice: a game changer?

I’ve argued previously that Google Voice is potentially a game changer in the world of telecommunications. I’d like to extract some conversations on that issue that expound on these thoughts. Nothing is certain. It’s just as likely that 2 years from now Google Voice will be a ghost town, blowing in the wind. But there is a possible alignment of technology, motivations, and capabilities (money and reach) that may make Google Voice into a game changer.

I think Google Voice has the potential to be a game changer. They come at this problem from a different point of view than the traditional telecom companies. I think they can envision a future where calls cost no more to deliever than a piece of email. How does google monetize gmail? I think they believe that GV can be monetized in the same way…in fact as part of the same communications hub. As PSTN termination drops out of the picture, then the need to pay AT&T/Verizon, etc. drops away.

 
 

In the future, a telephone number will be a quaint anachronism. You’ll reach people via some sort of domain name type address: for email, for IM, for voice, for video conferencing.

 

Con Argument [from nitzan on dslreports.com forums]:

The only way you can deliver a call at the cost of an email is if it never leaves your network. A VoIP provider can provide free calling between it’s own subscribers – but the minute a 3rd party phone company is involved, you get back to paying for the call.

 Mind you- this is still not the price of an email. A typical email is something like 1KB in size. A 10 minute phone call is more like 100MB. While a banner ad that brings in $0.0001 can possibly subsidize an email – it won’t be enough to subsidize a phone call.

 But to get back to topic- essentially the only way voice will become email-like without interconnection fees is if either:

 1. Phone companies waive interconnection fees (yeah right).

2. One VoIP provider becomes so huge that their subscriber base spans across the majority of US households (yeah right).

3. A group of VoIP providers waive interconnection fees between each other, and together span across the majority of US households. (unlikely at best)

 
 

 Are there interconnection fees on email? Are phone companies involved in a DNS lookup? In the future, the current dominate role played by phone companies will fade away. My voice device will do some sort of DNS-like lookup to find your voice device. My voice device will use this location information to signal your voice device directly, opening a “channel” to send digitized voice data. No point in paying for “interconnect” in this scenario.

 
 

The “size” point is interesting. But with the increasing capabilities in processor speed, link speed, data storage, etc., the size of voice traffic in the current world is looking smaller and smaller…and is already comparable to the relative size of email of a decade ago.

 
 

Con Argument [again from nitzan on dslreports.com forums]:

Here’s the million dollar question:

 Aside from a few volunteers with a lot of good will – who will put work into adopting stuff like ENUM? phone companies obviously have zero interest in adopting it because a no-pay model will essentially end their business. From a business perspective I really can’t think of why any phone company including VoIP providers would want to create a scenario where users no longer depend on them to deliver calls. For this reason alone ENUM is doomed to fail on the mainstream level.

 Sure- it can and probably will be done in a limited scenario between small companies as a niche market. But in the big picture do you really see Sprint/Verizon/T-mo/etc. opening their networks up to ENUM anytime soon?

 
 

Nitzan again makes a good argument. Yes, the million dollar question is who can pull off such a fundamental change. And that’s why Google can be a game changer. Because Google has the money, the reach, and, possibly, the motivation, to make something like ENUM take off. And there will be demand for something like ENUM, because it saves the end-user money. People are always motivated to save money, once they know how.

Google Voice, Gizmo, Mysipswitch, Linksys and Call Waiting

Call waiting with a voip service can be problematic to configure. There are a lot of different variables at work: the voip service provider, the hardware used, the Internet connection. Call waiting is really a concept from the PSTN world, and not the VoIP world. The Sip protocol can support the concept, but it can be implemented in different ways. Some Sip implementations use REFER messages, some use re-INVITEs to effect the switching.

 
 

With proper call waiting configured, I have the following capabilities:

1. When in a call, a new call causes 1 call waiting beep (I need to see if this can be configured) and the caller ID number of the new call is displayed.
2. Hitting flash will switch to the new call. Google Voice gives me the option of adding the new call to the existing call (conference it in), or just answering it (as separate call).
3. When answered as a separate call, I can use the flash switch to toggle back and forth between the two calls, as many times as I wish.

 
 

Here’s how I got call waiting on a Google Voice line that feeds, via sip, Gizmo, then mysipswitch, and finally a Linksys PAP2T ATA device.

1. I did not have to make any particular changes at either Google Voice, Gizmo, or mysipswitch. Some people seem to find call waiting signaling only works if you configure Google Voice’s Call Presentation feature to be disabled. I found it worked with Call Presentation either on or off.
2. There are 4 settings, all under the “Line” tabs on the PAP2T that I had to play with:
   1. Call Waiting Serv: enable
   2. Three Way Conf Serv: disable
   3. Three Way Call Serv: disable
   4. Set Hook Flash Tx Method to AVT (RFC2833) or INFO (whatever works). (Sends out of band digital signal for hook flash.) For Google Voice, Gizmo, and Mysipswitch, I use AVT.

    
    

   A good discussion of using call waiting and hook-flash with voip services and the linksys pap2t:

   http://forums.linksysbycisco.com/linksys/board/message?board.id=VoIP_Adapters&message.id=5782#M5782

    
    

Panama Law on VoIP

Wednesday, May 06, 2009

11:41

With my article on VoIP and Vacation Homes (specifically using a home in Panama as an example), there has been some discussion on the state of Panama Law as it relates to VoIP. I’m not a legal expert, so I don’t know the exact state of the law in Panama. Panama did outlaw VoIP in 2002, a move some people attributed to pressure from the incumbent telecom, Cable and Wireless. As part of this ruling, Panama tried to force ISPs and Internet cafes in the country to block certain UDP/TCP ports which are typically associated with VoIP applications. Of course, this effort was both misdirected and doomed to failure.  

In 2004 Panama reversed course and legalized VoIP, saying that the government would impose a 12% tax on VoIP calls, similar to what it leveled against PSTN calls. I am not sure what the state of this taxing regulation is. I do know that some Internet cafes still block common VoIP ports, but this might be a result of their efforts to limit bandwidth costs, and not a hold-over from the 2002 legislation. Of course a 12% tax on zero is still zero, so if your VoIP solution includes free calls, there’s really nothing to tax.