<br>Hello<br>I am trying to set up an internet subscriber on Unity 2.45.66, when I send and voice mail to a internet subscriber user outside our firewall to an other exchange server she gets the wav attachment. When I tried to send an voice mail to an other internet subscriber who is using Notes he get a dat file witch is not playable. <br>I also tried to send an voice mail to ActiveVoice in Netherlands via an internet subscriber an they just get en empty e-mail with no attachment. When I send it to an hotmail account you see the file but it is not an wav file.<br><br>Regards<br><br>Ketil Johansen<br><br><br>
Interesting... I created an Internet subscriber on our front system and tried some tests. Going to an Exchange server seemed to work OK (as you saw) and I was able to reproduce the same results going to HotMail. It's weird, it shows it as a non WAV file on interface, yet when you save it locally, it does save it as a wav file. Very odd. Further, I was able to send a regular wav file from my outlook account to HotMail and that worked, which indicates something's not happy somewhere along the line on our side here.
Are you guys running the IVC on your system or are you just going raw?
Just to let you know, we're still looking at this. Turning out to be a really interesting problem.
We are using the IVC here, however by default messages sent out from an Internet Subscriber don't go through it anyway... you have to force the address type to be "VOICE:" instead of "SMTP:" and then the destination would have to handle that type (i.e. it would need to be a site that had Unity installed with it's own IVC). So much for that theory...
Currently it looks like there's an issue with the MIME encoding of the voice message attachment on the Exchange site. It's interesting, though, that I can forward a voice mail from Outlook, it goes out the same gateway to a HotMail account and it's playable. If I forward that same message via the TUI, it arrives in the HotMail account in some sort of raw UUEncode format (i.e. the file is larger than it should be).
I had originally thought this had to do with the weird naming convention on the TUI forwarding... the conversation names the file "Attach3" with no .WAV extension and the desktop has an attacment called "VoiceMail.WAV" (something I'm looking into... "Attach3" is kinda weird). Doing some testing, though, that doesn't appear to be the cause, it just looks odd.
I think the key at this point is the file handling differences from the conversations vs. the desktop. Outlook does some of it's own MIME work at the client side that doesn't happen on the back end when we forward the message directly. I'm working with our IS folks to investigate further next week to see what we can do here. There's lots of similiar problem reports out on various forums (i.e. LotusNet has a bunch of articles about attachments coming across as .DAT and getting jumbled that may be a similiar issue).
I'll post most when we find something interesting... please let me know if you've got any snappy ideas.
Ok the database guys tracked the problem down this week. Tricky one
The deal was Internet Subscribers (custom recipients in Exchange) are setup with the Allow Rich Text Formatting flag set to blank (not 0 or 1). In versions of Exchange prior to SP3, blank meant that it was off by default and things worked fine. With SP3, however, blank was taken to mean on by the server and messages were encoded with TNEF.
TNEF is only recognized (so far as I can tell) by Outlook or Outlook Express. Web based clients and other email clients (Notes, Eudora, etc ) dont handle this attachment encoding method. As such, depending on the client being used by the recipient, it sometimes worked and sometimes didnt.
Weve made a change on our side that forces the Allow Rich Text Formatting flag to 0 for internet subscribers (not for regular subscribers that would break us since this is needed for them). This will be in the 2.4.6 release coming soon.
If you want to make this work now, you can force this value off for the internet subscriber youre working with. Open Exchange in raw mode (use the r command line parameter), go to the custom recipient in question and select file | raw properties. On the Object Attributes list box, select Allow Rich text and stick a 0 in the value field and hit the set button at the bottom. This should allow the WAV file attachments to go out without being enceded with TNEF and it should work to any destination.
I havent tried it on our front system to a Notes client, but testing with my HotMail account this morning this worked fine. Id be interested to hear if the Notes client works OK
You have reached the Cisco Logistics Support Center.. To Check Status of
your RMA, visit Product Returns & Replacements (RMA). Need help? Contact
us by Phone or Email. North Americas Phone: 1800 553 2447 Option 4
Email: email@example.com Europe Phone: +3...
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...