We would like to read the Unity voice name stored in AD (msExchRecordedName) and play the audio. I assume the audio is a .wav format (CCITT u-Law). Does anyone know how it is stored in AD? We've tried reading the data into a byte array using various encoding (Unicode, ASCII, UTF8, etc.), but none seems to work - the output cannot be played.
Any info would be appreciated. Thanks!
What version unity are you running, because Unity 4.x stores all wav files in the SQL database, not Exchange or AD. So your recorded name, call handlers, etc are stored in SQL. After the messages is taken, it is stored in Exchange. AD just has the Unity attributes for routing and subscriber identifiers.
From another post...
The current method for storing recorded names in Active Directory is an Octet string converted from the binary wave format. The
format is dependent upon a Microsoft attribute for Exchange called MSExchRecordedName. Binaries cannot be stored in Active Directory.
good catch! opps on my part, for some reason I thought all recorded names, etc were in SQL or a copy of them were in SQL.
Recorded names and greetings are stored on the local Unity servers hard drive in the \Commserver\Stream Files directory. The SQL database also has a path to each local subscribers recorded voice name and greeting.
In addition to this, voice names are also stored in Active Directory so that other Unity servers in the AD can get a copy of non local Unity subscribers voice names. Each Unity server stores its own copy of non local Unity subscribers voice names. They get their copy from the AD object.
We opened a TAC with Cisco and they initially informed us that the recorded name was stored in AD using UUEncode. I tried using a UUDecode algorithm but the output data was still not playable. It's possible that my UUDecode function is not correct. A second response from Cisco indicated that the recorded name was stored as an Octet string. So... still no solution.
Its UniCode base64 and you can extract it using ldifde with the '-u' switch.
Yes, that was the answer we got back from TAC. But we're using .net's DirectoryServices namespace to extract the data from AD. For some reason the directory services class does not return the same data as ldifde. Here's a bit of our test code:
Dim byteVoice() As Byte
myResultPropValueColl = myResultPropColl.Item("msExchRecordedName")
byteVoice = Text.Encoding.Unicode.GetBytes(myResultPropValueColl.Item(0))
If I stream the binary data to a file and compare it to the output from ldifde, the results are not the same. The ldifde file has additional data at the beginning and the end.
Problem solved! Basically, we had to read the Unicode data into a byte array, then convert back into an ASCII string, and then do the Base64 decoding back into a byte array. Here's the code:
Dim byteVoice() As Byte
Dim charVoice() As Char
byteVoice = Text.Encoding.Unicode.GetBytes(dsResultPropValueCol.Item(0))
charVoice = Text.Encoding.ASCII.GetString(byteVoice)
byteVoice = Convert.FromBase64CharArray(charVoice, 0, charVoice.Length)