Where Are Messages Actually Streamed From

[mwadam]

In a Unity configuration with Exchange off-box, regardless of VM or UM, when a subscriber plays a message where is the .wav file actually streamed from? I would assume directly from Exchange. Does Unity do something under the covers to pull the .wav file down to itself and then stream from itself? Also, based on responses could you point to a written reference?

Thanks!!!

Adam

[Tommer Catlin]

It is streaming it from Exchange to the Unity server then out the TSP ports or Switch integration method.

[mwadam]

Thanks for the reply!

So as the message is actually playing, even though it is transitioning thru the TSP the stream actually comes from Exchange, Unity does not pull it down in any fashion then stream it itself?

Anything you can point me to document wise that I can show the customer questioning this?

Thanks!!!

Adam

[lindborg]

The Architecture Overview doc on www.CiscoUnityTools.com brushes the topic but does not explicitly show the streaming path.

I assure you, the stream is pulled directly from the mailstore. Ask our competition! This is how we can start playing the message right away when you select it either from the desktop or over the phone - unlike a few of our competitors that have to do exactly what you mention (copy the entire WAV file attachment to their local box, dress it up and _then_ start playing it which can result in annoying delays in playback) we grab a handle and start chunking it across and playing it in one step - streaming in other words. There's not other way to go about this reasonably without caching every message from ever user locally which we certainly don't do or waiting for the full file copy to complete first which we obviously also don't do. Imagine a 30 minute message - you'd have a _huge_ delay before we could play it back if we had to copy it first. Not to mention the nasty hit to your network load...

Unsure how to make your customer believe, but trust me - this is how it works.

[mwadam]

Jeff,

Thanks for jumping in on this one. I have unfortunately been placed in a situation where Cisco is telling the customer the messages are not streamed from Exchange but from Unity, and I have been disagreeing with them. The customer has a firewall between their Exchange server and the location where they want to deploy Unity UM, and I have been trying to see if we can come up with a method to get around this. Although it does not place Unity and the message store across a WAN, the firewall will add some delay and affect QOS for the message traffic. Your response I am sure will be convincing enough to at least make them listen to me instead of their local sales team. Any view you may have on the firewall in the middle would be appreciated also. I have offered the option that if the firewall were QOS capable (i.e., a PIX with 7.x), then problems may not be as noticeable, but have yet to confirm what firewall they will be using.

Thanks!!!

Adam

[Tommer Catlin · Accepted solution]

The book you want to get is this: Cisco Unity Deployment and Solutions Guide.

On Page 174, you will find how this works exactly.

When a Unity subscriber makes a call to the voice-mail system to retrieve messages, Unity logs into the inbox for that subscriber on the email system. The mesages in that inbox are filted and counted based on message type, quantity, etc. The email system does not deliver voicemail messages destine for the Unity subscribers to Unity. Instead, it delivers the message to the portion of the email systems database dedicated to that user.

Taken from the book)

Unity is streaming the wav file from the Exchange database and out the TSP port to CallManager that connects to the IP phone or gateway.

[mwadam]

I have the book. I will dig it up and use it as a reference for the customer also. I really appreciate your responses, and as you stated, since Jeff chimed in, the customer will have to be more receptive to what we are stating.

Thanks!!

Adam

[Tommer Catlin]

And there is best answer you can get is from Jeff.... who wrote the book...

Thanks Jeff!