G.729 Concerns about limited licensing.

[FGCUHank]

Some internal events have raised concerns about Digium's licensing policy on the g.729 codec. We are running *Now under vmware and had to move the virtual machine to new hardware a couple of times due to load on the host machine and some hardware issues.

I called support and was able to get the license count reset but was advised that should something happen again we would have to purchase a new codec license.

Now granted our in house needs are for only 7 copies so you can argue that 70.00 bucks is not a big deal. But let's talk real world here, machines move, hardware changes, nic's get updated and replaced, etc.

I am looking at putting in *Now, Asterisk, or Switchvox in at one of our customer sites. We're talking 300+ users, 9 locations, etc. I'm going to need a hell of a lot more than 7 codecs and with that many boxes running I know machines, nic's and codecs are going to be changing all the time.

So Digium, what do we do here? I can't have a 300+ user operation not be able to make calls because a NIC changed?

[ianplain]

Hi

I know machines, nic's and codecs are going to be changing all the time.

Why?

Ian

[FGCUHank]

While your question was short it is a good one and obviously well thought out.

Several factors in a large operation can cause a MAC address change like I describe.

VMWare, with VMVision, supports transfer of guest operating systems on the fly or in a static condition to other VMWare servers so you can balance the load across machines. This works great but causes a MAC address change.

All our data and guest VMWare machines are located on a SAN. The head units are simple blade machines and or simple 1HU rackmount units. Machines die. We stock pre-imaged machines and can swap out a blade or a rack unit is a few minutes. But again this forces a MAC address change.

Now obviously I won't be changing things daily or hourly but we are a 24/7 365 operation. If I loose am machine and am out of re-activations on a Saturday when Digium support is closed, which is exactly what happened in our little development office, I am screwed.


Digium's model of killing codec is just bad and not well thought out. Time-bombing would be a much more respectable solution.

[ianplain]

Ok.

Firstly I wouldn't run a production server handling more than a handful of users on VMware, But then again I run systems that are 5 9s and handing 100s of concurrent calls each.

Hardware wise failures as you describe are very rare and have never been an issue.

But that being said.

- A G.729 key must be re-registered if any of the Ethernet devices in your Asterisk
server are changed, added, or removed. The unique G.729 license file which is
located in your /var/lib/asterisk/licenses directory is tied to the MAC address of
all the Ethernet devices installed in your system. A G.729 key can only be
re-registered once without authorization from Digium. Digium must be contacted by
phone in order to request authorization to have your G.729 key incremented. Digium
reserves the right to deny authorization for having a G.729 key incremented.

Is Digiums line on it and to be honest, I think its fair, They dont say they wont they say they reserve the right to say no.

Ian

[FGCUHank]

Ian, we are getting off-topic here.

I have big machines running vmware guests with lots of users and no issues. We are probably going to move off vmware to a big IBM box running VM in the near future, which BTW would force yet another MAC address change.

Hardware failures can happen at any given time and you have to be prepared for them in advance. If I have to do maint on a big VM box and migrate the guest O/S to another VMWare machine the MAC address changes.

My issue here is not discussion of if or how machines break, it is me expressing my concern about the fact that Digium hard kills the codec on a MAC address change.

This is a destructive behavior and in my opinion just tacky. I can respect and support Digium protecting their codec but do so in a non immediate destructive manner.

[ianplain]

Ok.

Digium hard kills the codec on a MAC address change

But they don't and having for a customer moved licences 3 times I know that from first hand. This is no different to many other software companies I deal with, lumenvox, Mitel and prairiefyre do exactly this same method of licensing.

Ian

[bkruse]

The point is....you could be re-distributing the g729 codec to other people, and then requesting a reset.

We do it to prevent fraud, as we have to pay for the licenses ourselves, and it's on our backs if someone mis-uses it.

I would really recommend not using vmware for a pbx.....ever. Why not just set it to bridged mode, and keep it on one box?

-bk

[FGCUHank]

Actually Ian after 2 or 3 mac changes they do:

"I have incremented your key, however this will be the last time that we are able to do so for this particular key. Please let me know if you have any problems registering. Thank you,"

Support was very kind and responsive but they were not available on Saturday afternoon when I needed a replacement key. My fallback was to change the codec used to my service provider.

Please don't get focused on the fact I am using VMWare other than the fact that upgrades to VMWare versions and sometimes the VMWare Tools updaates on the clients both cause a MAC address changes.

I have BIG VMWare servers and we are moving to IBM VM. Things run just fine on a properly sized piece of hardware.


BKRUSE: I understand and respect the fact you have to protect the codec but there must be a better way than just killing the codec.

You should be able to tell how many moves are left for the codec so I can check that before making system changes, moves, VM upgrades or maintenance.

The codec checks in with you guys for authorization, you should be able to determine what systems are checking in and prompt for activating or deactivating based on reported system parameters.

The codec should not just stop. You should timebomb the stop to at least 3-5 days and warn the admin. This will prevent a catastrophic failure as in the case Saturday.

[bkruse]

You can prevent catastrophic failures with allowing more than one codec, and preferring g729, though I definitely understand your concern.

I cannot answer directly for Digium, and the best I can do would be to tell you to voice your opinion (as you did here) to Customer Support.

I will try to find the answer myself, as well.

-bk

[FGCUHank]

I wanted to post back on this as I found another way to prevent this. Should have noticed it earlier.

Server versions of VMWare, not sure about desktop as not running it anymore, allow you to manually set the MAC address of the virtual machine in a predefined range.

Doing this versus the default behavior of VMWare auto assigning a MAC address will let the machine be "portable" between VMWare host machines and avoid the codec license issue.

Just be sure to note the MAC address you chose and remember to set it on the new host machine.

We change hardware a lot here...

[Sean Hatfield]

The MAC shouldn't change during a vmotion, but regardless manually specifying one in the vmx will keep it from changing. Just keep records of the MACs you've hard coded in case you have to recreate those vmx entries.

*Now is well behaved on ESX, provided you can keep your CPU ready values <100ms. Single digits would be better. High CPU ready can cause audio dropouts while *Now is in the audio path. Enable reinvites whenever possible.

[khawkins]

Food for thought (to Digium):

Why not create a (slightly more expensive) separate license type that allows for unlimited re-registrations? It could maybe be limited to 1 re-registration per day for example. The added cost for the license would be to help offset the leg work you have to do to ensure licenses are being registered legitimately. For individuals who cannot work around the license limitations, this could be a working solution for all parties involved.