Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Avaya Session Manager/Exchange 2013 UM/VM

Status
Not open for further replies.

jmbailey

Technical User
Jul 9, 2007
70
US
Has anyone hooked Avaya Session Manager up to MS Exchange 2013 for Unified Messaging/Voice Mail and have it working?

We had Exchange 2010 UM working just fine, and our Network Group went and upgraded to Exchange 2013 and broke everything. Our Network Group, consultant and Microsoft have been ineffective in trying to get 2013 working again. We finally were able to get calls routed to the right mailbox, but now the MWI and Play from Phone feature (where Exchange calls the desk phone to play the message).

Can anyone provide any details or suggestions on what it is Session Manager is looking for when calls are placed to it from Exchange 2013? Again, 2010 was working but once again, Microsoft has apparently changed the way 2013 talks back to the Session Manager.

And yes, we have been searching for some type of documentation about this type of setup and haven't been able to really find anything that helps.

Thanks in advance!!!
 
Whoops....forgot this.....

We have CM 6.0.x, Session Manager 6.1.x
 
traceSM is your friend here. From Session Manager's CLI it'll show you SIP message processing. You can filter -u 1234 to see SIP messages for user 1234, or -i 10.10.10.10 to see SIP to/from that IP (like MS UM...)

You can trace call processing on it, but I wouldn't advise it when things are busy. Leave yourself a message and watch MS try to send MWI.

In System Manager, in "Routing" you define how Session Manager routes SIP. So, for example, if MS UMs extension is 5555, there'd be a SIP domain, SIP entity and entity link and dial pattern and routing policy and it would work something like:

If CM sends a SIP INVITE for 5555@MSUM.yourcompany.com, then SM should select the routing policy that points to the SIP entity of MS UM and use the entity link defined between SM and UM to get there.

You would want to see what MS is sending back for SIP NOTIFY for MWI and for outcalling to play on your phone and make sure extension ranges MS is dialing and domains in SM are all configured correctly to track that call flow.
 

Sounds good, except for the fact that traceSM shows nothing for calls being placed to SM from Exchange. Outbound to Exchange is working, but calls from Exchange to SM (MWI/Play from Phone) don't ever appear to reach SM. Traces from Exchange show destination unreachable or blocked. Without getting info from the SM side, kind of shooting in the dark on the issue.

It may be a certificate issue on secured ports, but according to the Exchange side of the house, those aren't being used. Needless to say, I don't believe them. I'm going to try and grab the certs tonight and fire up the secured ports on SM to see what happens.

 
Yeah, so, a pcap on MS Exchange or Session Manager (tshark from the CLI) will prove that a connection is attempting to be established - TLS, port 5061, and a failure to handshake.

 
I can address the Play on Phone issue - it broke for us too along the way. Our PBX vendor went back to Microsoft and Avaya and found in traces that the header info was now incorrect (how, don't know) but UM is looking for SIP.uri instead of an extension. We plan to change the UM dial plan to accommodate this as our vendor has already tested in their lab successfully. Once this is done, I'll post an update.
 
demanding - Did you ever get this to work. I am having the same problem and need to know what changes you made for it to work? Thank you.
 
We are scheduled to make the change tomorrow morning between 9-10 AM ET - hope to have positive results then.
 
What changes are you looking at making? I have this set up in a test environment. I could make the changes and let you know if it works. Thank you for your help.
 
If it helps anyone, this is the last email I got from our vendor.

"In UM 2010, when making a Play on Phone call, the UM sends the P-asserted-Identity as a SIP URI. For some reason in 2013, UM is sending it over as a TEL URI.

The .11 service pack for SM actually fixed this issue in the History info header, but not the PIA."
 
It is about the URI - we have to change our dialplan in UM so it sends the SIP uri and not the TEL URI. I don't know the details...
 
That worked. I changed it to a SIP Dial Plan. I had problems with the auto attendant, I ended up having to change the way I was routing that from CM. Everything is working now. Thank you for your help.
 
Great - I was just about to report back our findings. All good. We did have to set up the auto attendants in UM again. One was missed and I could not transfer calls to voicemail so that is in the works to be re-added.
 
One thing I am noticing is the caller ID from outside phone numbers is showing up with "@ourdomainname". Is that how yours are showing up?
 
I saw your post about MS Exchange 2010. You said everything was working good prior to the move to 2013. We began using the 2010 about 3 months ago, we have one issue. If an IP station answers the main school number on a bridged appearance of the main station, then transfers it away, the unanswered call ends up in the main stations UM box. Not the UM box of the station it was transferred station.
If the main station answers the call and transfers it, it will work fine. Did you experience anything like this?
I know this has nothing to do with your present issue, but any insight would be helpful. Plus I am sure our IT will move to the 2013 platform sooner or later.
 
With Exchange UM 2013 play on phone and a SIP dial plan, we were able to get invites from EUM to Session Manager then to Communication Manager. Now we're getting a 500 internal error from CM (application cleared call). This happens after UM sends a prack. We're thinking this is because of invalid SDP info. The media contact offered in SDP in the invite from UM is its un-routable management address. Any experience with this piece of the puzzle?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top