cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6620
Views
24
Helpful
11
Replies

Registering TC endpoints to CUCM but keeping provisioning by TMS

Paulo Souza
VIP Alumni
VIP Alumni

Hi folks!

It is my time to ask for help. =)

My problem

Well, I have an enviroment with many TC endpoints registered to CUCM 9.1. I also have VCSc, VCSe, 8710, 8510, TCS, Conductor, TMS with webex enabled, CUBE and etc. Although Cisco is improving the support for TC endpoints in CUCM, there is some blind points yet. These blind points are causing a great impact in this project!

These are the blind points I am talking about:

  1. When TC endpoints are being provisioned by CUCM, TMS is not able to generate reports to the endpoints, once TMS is not able to collect CDR from CUCM and the endpoints don't post CDR to TMS because CUCM is configured as provisioning server
  2. When TC endpoints are being provisioned by CUCM, TMS is not able to publish phonebook to the endpoints, once CUCM is configured as phonebook server. CUCM's global directory is not helpfull here, once we don't have an option to create groups and the customer needs to have phonebooks groups (just like TMS does) because there are many different companies using the same infrastructure, so we cannot have one single phonebook. Local phonebook is not helpfull as well, because there are more than 300 endpoints and the environment is growing up fastly, it is impossible to manage local phonebooks!

I cannot use a full VCS-based deployment, because this project was designed by Cisco BU, and Cisco designed the project having CUCM as the main Call Control to provisioning all the endpoints, including imersive telepresences (few) and TC endpoints (too many). I didn't even have oportunity to suggest anything, I simply received an already placed PO and a time to implement the project.

My workaround

I am using what I call "partial provisioning". I register TC endpoints to CUCM but I configure the endpoints to be provisioning by TMS. I configured SIP options pointing to CUCM, but I configure provisioning and phonebook options pointing to TMS. I set a wrong password in CUCM device configuration in or der to avoid CUCM rebuild all the configuration when somebody click "apply config". =)

By using this workaround,  I have phonebook groups and reports sucessfull working with TMS and call features working fine with CUCM as well.

Of course it does not work for imersive telepresences. I have no idea what to do regarding CTS/TX endpoints!

My doubts


  • I am aware my workaround is not some kind of "Cisco recomendation" (I know documentation very well), but I tested it over and over again and I have not found any limitation with TC endpoints. And it works! Could anybody point me if there is any limitation(s) to my workaround?
  • Does Cisco have plan to overcome those two limitations? Is there any roadmap?

I would really appreciate any help.

Sorry for the long description, it is necessary to avoid misunderstanding.  =)

Thanks in advance.

Paulo Souza

Please rate replies and mark question as "answered" if applicable.       

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".
1 Accepted Solution

Accepted Solutions

Paulo Souza wrote:

This is what I need, I need an answer from Cisco telling me that I can register Tandberg endpoints to CUCM but keeping the phonebook and provisioning configuration poiting to another server, so that I can have it working without using CUCM. I already have it working, but Cisco does not tell me "Paulo, you can do that, there is no restriction for your workaround." or at least "Paulo, you can do that, but there will be limitation..." or anything.

Paulo, do can do that, but…

I work on the TMS team, so I can only give you a TMS perspective on what you are doing. In a TMS perspective, you are using the UCM as what the TMS documentation refers to as an "unsupported third party gatekeeper". Then you'll get a full feature set for the endpoints when it comes to reporting, system management, software upgrades, etc, and the solution is supported in a "legacy TMS perspective". The only obvious problem I see in TMS is conference routing; when you use third party gatekeeper, you lose TMS's "can these endpoints call each other, and if so, on which protocols" logic. TMS will just assume that everyone can dial everyone. Worst case: You let your users schedule a conference that cannot be connected, and the calls fail.

I don't think I surprise anyone when I say that we are focusing more and more on our "UCM registered" deployment model, and less on the traditional "TMS controlled" deployment model (see page 54 of our admin guide for definitions). You can expect a richer feature set for the UCM registered model, and a smaller feature set for the TMS controlled model (as we only have a finite set of testing and code maintenance resources; if we are to do more of one thing, we have to do less of another). At some point, the roles will be reversed, and you'll get a better feature set when you go for the "UCM registered" deployment model in TMS. You would then want to migrate to the other deployment model, and migrating is a highly manual and painful process when we are talking about a production environment. For this reason alone, I cannot recommend your "partial provisioning" model.

How my endpoint and UCM colleagues will react to "partial provisioning" I cannot say for sure, but I can imagine some raised eyebrows from the UCM guys. The TC software team is focused more or less 100% on the UCM these days, and just like for TMS, you shouldn't be shocked if the "TMS controlled" provisioning model is de-emphasized or even discontinued (eventually; this won't happen overnight of course). I think this is another strong reason for sticking with what we test and officially support.

You could also get into problems if something breaks. I don't work in the TAC and don't know their policies 100%, but I would not be surprised if they told you to move to a supported deployment before they would pass any defects you might encounter "up the chain". And if such bug reports eventually reached me, I would probably have to give them lower priorities than bug reports from customers that are on the deployments we test and support.

All in all: I think there are compelling reasons for not going for "partial provisioning" in your customer's environment. I understand that the lack of TMS phone books and endpoint CDRs in our "UCM registered" model makes it tempting, but I don't think these reasons are strong enough. How these features work might also change in releases in the not too distant future.

Regards,

Kjetil

View solution in original post

11 Replies 11

Paulo Souza
VIP Alumni
VIP Alumni

And yes, I have already asked help to TAC, but I have been informed my problem is a limitation and not a bug. I agree.

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

Hi Paulo - I've been hassling my Cisco representative about TMS phonebooks on CUCM managed endpoints for almost 2 years now - it's great to see you've found a workaround, I'll definitely try it out!

Hi Nick,

My purpose with this thread is not to suggest my workaround as solution to anybody, that's why I am asking about possible limitations. However, you are free to test it. But be aware is not a Cisco solution, therefore, I cannot give any guarantee it will work without restriction.

Thanks for your comments.

Regards

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

Any help?

Paulo Souza


Please rate replies and mark question as "answered" if applicable.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

CUCM is CUCM and TMS/VCS is TMS VCS.

I do not like such a deployment as they most likely will bring in more problems at the end,

espeically after software upgrades or when additional features are used, ...

Make a feature request for better phone books in CUCM and or phone book integration

in between CUCM and TMS.

Not sure about TAPI capabilities with TC and CUCM and 3rd party phone book software,

maybe that could help you as well.

And one additional FR to have better CDRs and/or reports.

Yes, currently its not really easy. There are  features which require an opposite deployment

as an other feature, ...

Please remember to rate helpful responses and identify

Hi Martin, thank you very much for your reply! I really appreciate it.

CUCM is CUCM and TMS/VCS is TMS VCS.

I do not like such a deployment as they most likely will bring in more problems at the end,

espeically after software upgrades or when additional features are used, ...

I agree. Normally, when I have many TC endpoints, I prefer to use a full VCS-based deployment. But in this case, I wasn't the responsable to design the project, it was designed by Cisco, I just received the whole thing ready to deploy. But CUCM is really need here because we have imersive telepresences.

Not sure about TAPI capabilities with TC and CUCM and 3rd party phone book software,

maybe that could help you as well..

I know I could use another phonebook servers different than CUCM, and I am already doing it. But if I follow the document "Administering TC endpoints on CUCM", the result will be having CUCM directory as phonebook server. This is the problem! There is no Cisco doc saying you can register your TC endpoints to CUCM but you can keep the phonebook URL pointing to another server, or pointing the external manager address to another server other than CUCM.

This is what I need, I need an answer from Cisco telling me that I can register Tandberg endpoints to CUCM but keeping the phonebook and provisioning configuration poiting to another server, so that I can have it working without using CUCM. I already have it working, but Cisco does not tell me "Paulo, you can do that, there is no restriction for your workaround." or at least "Paulo, you can do that, but there will be limitation..." or anything.

And one additional FR to have better CDRs and/or reports.

Yes, currently its not really easy. There are  features which require an opposite deployment

as an other feature, ...

It is really not easy, mainly regarding reports, because we need reports of CUCM's endpoints, of Jabber for Telepresences, of external endpoints from internet, of external endpoints coming from CUBE, of all MCUs. I can generate all reports I need by using TMS, except CUCM's endpoints.

That's why it is hard to think about an external report software, because this software should be able to collect CDR from all components, and it also should be able to identify the scheduled conferences in TMS and generate a report per scheduled conference, also a report per user scheduled conference, so it more than only a simple report about calls made by an endpoint alone.

Regarding reporting, we are looking for developing our own custom report tool, once we didn't find any external software able to achieve our need.

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

Paulo Souza wrote:

This is what I need, I need an answer from Cisco telling me that I can register Tandberg endpoints to CUCM but keeping the phonebook and provisioning configuration poiting to another server, so that I can have it working without using CUCM. I already have it working, but Cisco does not tell me "Paulo, you can do that, there is no restriction for your workaround." or at least "Paulo, you can do that, but there will be limitation..." or anything.

Paulo, do can do that, but…

I work on the TMS team, so I can only give you a TMS perspective on what you are doing. In a TMS perspective, you are using the UCM as what the TMS documentation refers to as an "unsupported third party gatekeeper". Then you'll get a full feature set for the endpoints when it comes to reporting, system management, software upgrades, etc, and the solution is supported in a "legacy TMS perspective". The only obvious problem I see in TMS is conference routing; when you use third party gatekeeper, you lose TMS's "can these endpoints call each other, and if so, on which protocols" logic. TMS will just assume that everyone can dial everyone. Worst case: You let your users schedule a conference that cannot be connected, and the calls fail.

I don't think I surprise anyone when I say that we are focusing more and more on our "UCM registered" deployment model, and less on the traditional "TMS controlled" deployment model (see page 54 of our admin guide for definitions). You can expect a richer feature set for the UCM registered model, and a smaller feature set for the TMS controlled model (as we only have a finite set of testing and code maintenance resources; if we are to do more of one thing, we have to do less of another). At some point, the roles will be reversed, and you'll get a better feature set when you go for the "UCM registered" deployment model in TMS. You would then want to migrate to the other deployment model, and migrating is a highly manual and painful process when we are talking about a production environment. For this reason alone, I cannot recommend your "partial provisioning" model.

How my endpoint and UCM colleagues will react to "partial provisioning" I cannot say for sure, but I can imagine some raised eyebrows from the UCM guys. The TC software team is focused more or less 100% on the UCM these days, and just like for TMS, you shouldn't be shocked if the "TMS controlled" provisioning model is de-emphasized or even discontinued (eventually; this won't happen overnight of course). I think this is another strong reason for sticking with what we test and officially support.

You could also get into problems if something breaks. I don't work in the TAC and don't know their policies 100%, but I would not be surprised if they told you to move to a supported deployment before they would pass any defects you might encounter "up the chain". And if such bug reports eventually reached me, I would probably have to give them lower priorities than bug reports from customers that are on the deployments we test and support.

All in all: I think there are compelling reasons for not going for "partial provisioning" in your customer's environment. I understand that the lack of TMS phone books and endpoint CDRs in our "UCM registered" model makes it tempting, but I don't think these reasons are strong enough. How these features work might also change in releases in the not too distant future.

Regards,

Kjetil

Hi Kjetil,

Thank you very much for your reply, I really appreciate it. This is exactly the answer I was waiting from Cisco! I would give you thousands stars if I could.  =)

From your answer, I can conclude that Cisco is really going to improve TMS and CUCM integration, so that we can have richer features in a next future. Considering that Cisco is leading all the telepresence solution to be CUCM-based, I think it is a good option to keep a CUCM-based deployment for now, even with some limitations, and then upgrade to new versions in the future in order to have new features.

However, for now, I will keep my workaround up, once it is not bringing any limitation at this moment, but I am sure it won't reach our need in a next future, mainly because our enviroment is walking to imersive telepresences solutions, so we will really need some features improvements from Cisco regarding TMS/CUCM integration. But now, I need to have phonebook and reporting working, because this is a TPaaS environment, so I think we do have reasons strong enough to keep this workaround up, mainly regarding reporting.

I agree with you that, in a next future, I may want to migrate provisioning back to CUCM, so I will have a great effort to roll back from my workaround, but this is not a problem for us, because  we have a telepresence team ready to work on that.  =)

With regards having support from TAC, I totally agree with you. But our team only opens service requests with TAC when there is a bug or when we need RMA, otherwise, we work hard to resolve the issue by ourselves. But I agree with you, if TAC's assistance is really necessary in the future, we are aware that we may have problems, once we are not using a supported deployment.

I won't set thread to "answered" (although I think you have answered it) for now, because maybe I have luck and receive some answer from CUCM and TC software teams, that would ne nice!

Thanks again.

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

Massively interesting conversation here, and treads along some lines that have long bothered me (although the following is a little off topic).

We used to utilise Cisco CM way back in the day (version 4 or 5 I think), but only for a few Skinny Phones. Our VC deployment was based on Tandberg thinking (TMS/VCS), then we re-imaged the phones to use SIP and registered them with the VCS (although not managed by anything per se), so had no need for CM at all. However, with the buy out from Cisco and the re-invention of Call Manager to CUCM, one can only wonder as to the direction of CUCM and TMS and if the roadmap lead to a merged technology - Cisco Unified Telepresence and Call Management Suite (CUTCMS) .

hehe, na, I guess that name will not happen :-)

But if you check out Kjetils posting I guess you can guess  that:

* cucm is becoming stronger

* tms or how it will be named is loosing the provisioning and endpoint handling part

* tms will still be used as a booking engine, possible phonebook management, maybe reporting?

* cisco prime will take over the management, provisioning, ...

We have a lot of customers who just wanted to have some video calls. For them the old Tandberg way

was ideal, it was very modular, you could start up with an endpoint, either just place it on a public ip,

get a regstration as a service or start up with the express starter pack.

Then you could grow, vcs-c+vcs-e, tms, movi, mcu, multiway, isdn-gw, content server, ...

Think also these combinations were a great idea

* you have a vcs-c+tms+licensekey *bang* you have movi

* you hava a mcu+vcs+endpoints *bang* you have multiway

Easy understandable combination of existing products =  an easy understandable new feature

Besides that the configuration was simple enough and the documentation ok.

Now for a small deployment it gets even more complicated you need a

vcs-e, vcs-c AND a cucm (ok at least you could bundle it as a be6k, but still its more components to maintain)

So you add more complexity and costs where it was way simpler before and in addition

things like phonebooks and reporting are not as nice as before.

I have high hopes, so lets see what the future will bring! :-)

Please remember to rate helpful responses and identify

Yorick Petey
Level 4
Level 4

Hello,

More than 4 years later, TMS is still not able to generate consistent reports combining Conference occurences and CUCM-controlled endpoints.

Paulo, were you able to find a professional way, like using a third-party software? Or did you develop your own script as suggested?

Thank you.

Yorick

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: