Technically this can be done, but practically its not necessary.
This would save some overhead on the CPU, however under load testing the conversion from 711 (MuLaw) to 729a (and back) took up around 5% of the total CPU on the box (keeping in mind this was a lot of ports doing a lot of work). Thats pretty efficient by any standard.
Technically we could record all our prompts in 729a, switch the codec over to 729a for messages/greetings and you could use 729a enabled phones which would negate the need for any conversion on the server during record/playback, but you wouldnt be buying yourself much and the prompts effort would be pretty big (and they wouldnt sound as good). That and youd have to do the same exercise for the next codec that comes out (and there are more on the way).
In general, Id say the conversion is a blip on the performance radar and can effectively be ignored as a serious issue.
Unity Product Architect
Jeff, the main reasons we need G.729a auto-sensing in Unity is to:
1. Preserve WAN bandwidth when IP Phone are located remotely
2. Eliminate need for Cisco DSP Transcoding resources (expensive).
3. Reduce storage requirements on Exchange server.
If Unity could auto-sense the codec (part of Skinny message), it could give us the benefits listed above.
I am not sure what you mean by "auto-sensing". I think the current implementation already handles your requirements.
When G.729 for the AvCiscoTsp is enabled, Unity can handle both G.711 and G.729 calls. It just uses the codec the CallManager tells it to use for the call. If the client does not support G.729 then it will use G.711.
(Note: Enabling G.729 for the AvCiscoTsp, does not affect audio streamed to outlook over a WAN.)
You can also change the default record format to G.729. This will reduce the WAN bandwidth needed for remote Outlook users. It will also reduce the storage requirements on the Exchange server.
Aaron & Jeff
Aaron states that you can change the default record format to g729. I had assumed that the message would be stored in whichever codec the voice stream was carried over in. But what I'm reading here, is that Unity stores messages in one codec or the other (711 or 729) regardless of the message stream format? Is this correct? That's a bit confusing, because it would mean that Unity is doing transcoding.
I think you might have misunderstood.
We DO store the voice message in the format indicated... if you set Unity's record format in G711, that's what it's stored in. If you change it to ADPCM, that's what it's stored in.
We were talking about playing prompts (which are studio recorded files added by our setup and cannot be changed in the field) always being in G711 since that's what they were recorded in. This is where the change over comes. When you call in on a phone that's using G729, we need to convert it from 711... not much choice in the matter, but the hit to the CPU is very low, even under load.
Unity Product Architect
Here's an excerpt from the release notes on the G729a installation:
How do I select G.729a as the recording format for Unity?
1) Make sure the version of VMO that ships with Unity 2.4.5 is installed.on all client machines.
2) Stop Unity.
3) Run the sl_g729a_setup.exe application, which is located.in the Utilities folder of Unity 2.45.
4) When prompted, restart the operating system so thatthe G.729a driver will be loaded.
5) Run the SetRecordFormat.exe application, which is located.in the Utilities folder of Unity 2.45.
6) Choose "ITU G.729a by Sipro Lab" from the list of audio formats,then press OK.
7) Restart Unity.
How do I restore u-Law as the recording format for Unity?
1) Run the SetRecordFormat.exe application, which is located.in the Utilities folder of Unity 2.45.
2) Choose "CCITT u-Law" from the list of audio formats, then press OK.
3) Restart Unity.
If you switch to 729a folks without VMO will not be able to play the WAV attachments, by the way. Just be aware... it's not supported by Windows at all and we can't distribute an installable codec for clients not using VMO at this point (something the legal folks are working on I'm told).
Unity Product Architect
OK, so, if the system reg setting for storing messages is configured as 711, and a caller comes in on a 729 voice stream, and leaves a message, then Unity converts the message to 711 for storage.
And when the subscriber calls in to listen to the message, from a 729 endpoint, the message is converted again, back to 729, for playback over the 729 voice stream. If the subscriber calls in from a 711 endpoint, then no conversion takes place.
Also, the converse would be true: if the system is storing messages as 729, and callers come in as 711, Unity must do the conversion.
In addition, prompts are 711 only, so, for callers from 729 endpoints, Unity must perform a conversion from 711 to 729.