cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

MOC - UC Mobility Remote Destination

2118
Views
0
Helpful
5
Comments
Cisco Employee

As the role of Mobility gets increased in the UC mix, many users may (or may not) be aware of the fact that Microsoft Office Communicator (MOC) can also be used as another type of remote destination. Office Communication Server (OCS) with Front End and Mediation Server talking to CUCM via SIP trunk (see below) can be setup to leverage this functionality. On the CUCM side, Mobility/Remote destination configuration remains the same as usual having MOC associated as one of the remote destinations. SIP dial rules in CUCM needs to be configured so to streamline the call routing aspcect.

OCS Setup:

OCS Front-End server ←→ Mediation Server ← → SIP Trunk ← → CUCM
                                                        |                                              |
                                                        |                                              |
                                                    MOC                                      IP Phones

This new type of Remote destination provides ability to leverage MOC client's features (including click to dial, CallFwd, Transfer) also.

Some other features are also developed adding more support to UC Mobility & MS OCS/MOC integration i.e SIP DualForking, SimRing and etc. Will touch base on them in coming days.

5 Comments
Advisor

True but I don't see much of a value advocating this design if you have cucimoc as one of the solutions. One of the biggest issues with these designs including dual call forking is managing and maintaining potentially 2 call control solutions. CAC, CDR all become an issue eventually once OCS voice and cucm voice run in parallel. Also I am sure from a competitive standpoint CUCIMOC solves the issues by ensuring 1 call control and all the features mentioned above and more on the UC/Telephony side remains with Cisco. Also I am not sure these designs help anyone but MSFT to install OCS not just for IM/Presence but eventually Voice and then the entire UC stack. Other than Nortel no vendor I have seen ever certify officially on MSFT site for true dual forking and it remains to be seen how well that continues with OCS 2010/Wave 14 moving into to supplant the PBX http://technet.microsoft.com/en-us/office/ocs/bb735838.aspx...just my 2 cents.

Cisco Employee

First, no doubt CUCIMOC is great from an end-to-end solution stand point. However, don't miss the point that this OCS/MOC integration with UC Mobility is just a small piece of the bigger picture -

Advisor

The point I was trying to make is that some architectures may just fall by the way side since every vendor whether it be Cisco/MSFT wants a bigger piece of the UC pie otherwise it always leaves a door open for the competition. The architectures you mention are documented here http://www.cisco.com/en/US/solutions/ns340/ns414/ns728/networking_solutions_products_genericcontent0900aecd805b561d.html

but the point I make is I see no vendor including Cisco embracing dual forking since it only helps MSFT more than the incumbent vendor and with CUCIMOC I see no further news anywhere in that space.I see the point you make above but that assumes 2 numbers now one for OCS and one for your Cisco desk phone which only causes more headache for dial plan mgt, dual call control mgmt and so eventually the goal will be to standardize on 1 call control whether it be Cisco or MSFT and hence I don't see the value in this design. RCC already has been deprecated in Wave 14 so I am not so sure either vendor will even advocate this design in late 2010

Cisco Employee

I understand where you are coming from but I am sure it will be a pleasant surprise for everyone to see how Cisco will address the complexity of implementing and managing this "dual call control system" and come up with an easier-to-manage single call control architecture with MOC integration.....just wait and see a little more...

When a customer mandates Microsoft desktops Cisco will integrate tightly and lead in user experience.

Now, getting back to the original topic of this blog, nothing can change the fact that MOC's Remote destination capability has already been tested and verified!

Beginner

this is interresting reading, as it touches onto scenarios customers are facing running the various integrations beetween MS and cisco. Our experience from a nordic customer is that the integrations are almost good enough, but not all there. There are always something missing, and this is annoying the customer ( which may not see that this is 2 vendors integrating and not one system).

Some examples, "dual forking from MS side" which( i think) is only supported by nortel, Forward settings in RCC mode, different call behavior in cisco to ms vs ocs to ocs calls etc.

When using the OCS as remote destination as mention in the orginal post, i think there are 2 ways of doing this, either as a remote endpoint reachable at a number via the sip trunk  or as part of the RDP (remote destination profile) connected to a end user.

The last  can give some more options in cucm ( busy state, foa etc) but still will leave the customer with different behavior in the call scenarios cisco -ms and ms- ms, which the customer sees as a flaw.

It may be that the best way for the customer of getting a solution with a unitary behavior is to choose one solution of cisco or ms, or maybe use the cucimoc to collect the telephony /vide fetaures in cisco

Content for Community-Ad