cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
517
Views
0
Helpful
9
Replies

CCME & Exchange 2007 UM

johncaston_2
Level 1
Level 1

Hi All,

Just testing Microsoft's Unified Messaging component of Exhange 2007. The issue that I have is that CCME doesn't appear to pass the diversion header, therefore a caller ends up getting the same message as if I've dialled the pilot number instead of being directed to the General Delivery mailbox.

From what I've found on the Internet there's obviously a few people out there having the same issue with CCME.

Does anyone have any suggestions on how to get around this?

Thanks,

John

9 Replies 9

bwilmoth
Level 5
Level 5

Inter operability issue with CME and Exchange. Exchange is not able to parse diversion number if UA is IOS and cc-diversion is not set.

Is it possible to enable cc-diversion in IOS?

Hi,

does anyone know if this issue has been resolved yet - I too am having the well known diversion problems getting CCME to speak to E2k7.

Thanks

Paul Adam

Hi,

i donno what is your setup exactly and what/how are you trying to integrate, but i was on EX2007 training lately and it uses SIP TCP and not UDP implementation. (when talking to voip PBX).

Also not that Micro and Cisco are competitors in the UM field.

I hope this helped.

Good day

Yes Exchange 2007 uses TCP instead of the normal UDP but that's easy enough to configure on the Cisco routers. MS tested Exchange 2K7 against many standard PBX's but CCME was not included, whereas CCM was.

I've been trying to figure out why voicemail works with CUE, as this is also a SIP trunk but obviously there is some Cisco Proprietary communication between them.

I'm going to be upgrading our system to CCM and will test the integration with Exch 2K7 and capture some debug information for comparison, my gut feeling is that Cisco will need to release a "fix" for the IOS so that SIP parses a redirect header.

***Note duplicate post from Technet thread on this same issue: http://forums.microsoft.com/technet/showpost.aspx?postid=704425&siteid=17&sb=0&d=1&at=7&ft=11&tf=0&pageid=0 ***

Unfortunately I am in the same boat as all of you. I have a few thoughts to throw out while we're waiting for either Cisco or Microsoft create an official fix for this.

Could a separate dial peer or auto-attendant be created for each extension that would in turn go straight to a voicemail box? Management of such a solution would be less than ideal but I would appreciate any creative workaround that might possible in the meantime. I've played around with this a bit but I can't get Exchange to in effect transfer to itself with the hopes of getting to a user's mailbox. Any thoughts on this?

If this can't be done could it be possible to use a SIP middleman like SipX or OpenSER. In another thread (http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1270394&SiteID=17) it appears some folks are using this to get Asterisk to work by inserting the following line into the diversion header via a SIP proxy:

exten => s-NOANSWER,1,SIPAddHeader(Diversion: <>\;reason=user-busy\;screen=no\;privacy=off)

If this is possible I'd love to get a virtual machine running a SIP proxy to make this happen!

Am I thinking too far outside the box on this one?

bascheew
Level 1
Level 1

Cisco and MS are going back and forth on this. A TAC engineer told me the MS was not adhering to the standards, but here is what an MS rep is saying:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

According to RFC3261:

8.1.3.4 Processing 3xx Responses

Upon receipt of a redirection response (for example, a 301 response status code), clients SHOULD use the URI(s) in the Contact header field to formulate one or more new requests based on the redirected request.

[snip]

In all other respects, requests sent upon receipt of a redirect response SHOULD re-use the header fields and bodies of the original request.

Based upon this, CCM should re-use the header fields and body of the original request, as you have experienced, this has been addressed in v5.x.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So where does this leave us? Which vendor is going to fix this problem?

If the same issue is noticed with CME 4.1, then I guess a fix for this should be available in CCME 5.x

But it's still unclear who's to blame on this incompatibility. Both Microsoft and Cisco have pointed out RFC compliance snippets to me and, not being an RFC Compliance Officer, I'm not quite sure who to point my finger at. Cisco says they fixed CM 5.x to take Microsoft's non-standard method into account. But at the same time Cisco's gotta hate Exchange 2007 as it's a huge threat to Unity and Unity Express and they may not want the to systems to work together.

I'm not sure what to think, but as a customer stuck in the middle of this it's not a fun position to be in.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: