cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1641
Views
11
Helpful
12
Replies

TMS 14.3 - Automatic connect issue - Multiple call attempts

Paulo Souza
VIP Alumni
VIP Alumni

Hi folks,

I have a customer with an environment with TMS 14.3, Conductor XC 2.2, VCS 7.2.2, TP Server 3.1 and CUCM 8.6.2. They have many Cisco and Polycom endpoints registered to VCS and many CTS/TX endpoints registered to CUCM. There is a SIP trunk between CUCM and VCS. Conductor is integrated with VCS using B2BUA deployment model. TP Server is behind Conductor being used as multipoint resource only for scheduled conferences via TMS.

We are having problems when scheduling a conference in TMS using type "Automatic Connect" and setting Conductor to dial out to the selected participants. For certain endpoints, when the meeting starts, Conductor makes more than one call attempt towards the participants, even after the participants answer the call. For example, Conductor dials out to a CTS 3000 endpoint, CTS answers the call and get connected to the meeting, but some seconds later, Conductor makes another call attempt to the endpoint, then the endpoint answers the second call and put the first call on hold.

This issue is occuring for the following endpoints:

  • Polycom HDX Series endpoints
  • CTS/TX endpoints registered to CUCM
  • External dial out participants (those selected using the "External" tab in the scheduling page)

The issue does not occur for any TC endpoint registered to VCS.

As a troubleshooting step, the customer tried to configure TMS to attempt to connect the participants once (using the parameter "Connection Attempts for Scheduled Calls" set to 1), but the issue keep happening.

Tomorrow I will be on customer's site to check if this strange behavior is generated by TMS or by Conductor itself. I really think this is some kind of bug. I am sure that their environment was configured correctly following the Cisco documentation, because I was the person who implemented the project.

I would really appreciate any suggestion.   =)

Thanks in advance.

Paulo Souza

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

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

Accepted Solutions

Hi Paulo,

some days back we had seen this issue and i filed the bug "CSCui90143".

currently we expect that this issue is occurring because TMS is not able to understand feedback message from the conductor.

i hope this clarifies. i don't if you would be able to access the bug or no.

Rgds

Alok

View solution in original post

12 Replies 12

I've had a very similar issue some time ago, but it was TMS 13.2/TP Server 2.2/VCS.  H323 and SIP endpoints, no CUCM in the mix.  It was like either TMS or the TP server didn't register that the first call had been answered, and kept trying anyway.

I don't remember the exact details, but I ended up having to use CPL to limit the maximum ringing time for each connection attempt, so that it was for less time than the period between each attempt.

The thread detailing everything is on this forum somewhere - I'm not at work at the moment but if you search my posts you'll find it

EDIT: It shouls also be noted that there was an additional VCS-C "hop" in our call path, which would align with your issue - i.e. it's not happening to your locally registered endpoints.  Our call path was TP Server > VCS-C > Neighbour zone > VCS-C > TC endpoints.

Hi Nick,

Thanks for your reply.

I understand that you have found a workaround to your issue, however, as the customer is running a different software version and the issue appears to be a bit different than yours, I will try to figure out if this is really some kind of bug related to TMS or Conductor, and if I find that it is, I will have to open a TAC case.

But of course, I will try your workaround just in case. Can you give me the link to your post? I didn't find it searching on the community.

Regards

Paulo Souza

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

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

Hi Paulo,

some days back we had seen this issue and i filed the bug "CSCui90143".

currently we expect that this issue is occurring because TMS is not able to understand feedback message from the conductor.

i hope this clarifies. i don't if you would be able to access the bug or no.

Rgds

Alok

Just to give you more info regarding the issue whenever there is a transform involves you will see this problem when you dial out the participant as "sip". if the dial-out is H.323 it should not occur.

the workaround should be when you dial the any extension on cucm you need to use a full uri format like 6000@.

Rgds

Alok

Great Alok! =)

This bug describes exactly the problem I am facing. I just made some tests and I realized that the problem occurs when dialing out SIP participant without placing a domain to the destination address. If I put the domain, the problem does not occur, at least for External participants.

With regards endpoints registered to CUCM, I missed an important point, I forgot to configure top level domain in CUCM, then TMS schedules a call using the address without @domain for CTS/TX endpoints, only the extension, but that works, however, the redial problem occurs, because it matches the same bug condition.

With regards Polycom endpoints, I guess it matches the same bug condition, however, Polycom endpoints are only using H323, so TMS schedules the call using the Connection: Conductor SIP-->H323 Endpoint, thus the problem occurs as well. As you said that for H323 it should work just fine, am I missing something or there is issue related to H323 as well?

Thank you very much for your help. I really appreciate it.

Regards

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

Sent from Cisco Technical Support iPad App

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

Hi Paulo,

from the logs what we have observed is that whenever your destination uri or extension changes because of interworking or transform the issue will get triggered.

i hope it clarifies.

Rgds

Alok

Hi Alok,

When Conductor calls Polycom endpoint, the call does match a transform in VCS, maybe this is the reason why we are facing the same issue for those H323 endpoints, for SIP there is no tranformation of the destination number through out the call path.

Are you saying that if there is any tranformation or interwoking in VCS, then the issue may occus? Really?

Thanks again.

Regards

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

Sent from Cisco Technical Support iPad App

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

It sounds like this is indeed a bug and not related to my issue, but for reference I found the thread anyway, it's here: https://supportforums.cisco.com/message/3729337#3729337

Hi Nick, thanks for your help anyway, I really appreciate it.   =)

Paulo Souza

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

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

Hi Alok.

With regards Polycom endpoints, I guess it matches the same bug condition, because TMS only recognizes H323 options for Polycom HDX endpoints, so TMS schedules the call using the Connection: Conductor SIP-->H323 Endpoint, then it matches the bug condition and the issue does occur.

What can I do in this case? Why doesn't TMS recognize SIP options for Polycom HDX endpoints and also set connection to H323?

As the connection defined by TMS is Conductor SIP-->H323 Polycom, then there is no way to avoin translation and/or interworking in VCS, thus I always match the bug condition for Polycom endpoints.

I would appreciate any suggestion.

Paulo Souza

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

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

Hi Folks,

According to Cisco, this behavior has been fixed in TMS 14.3.2. I have not tested the version yet, but Cisco TAC has.

If another people here have the same issue, try to upgrade TMS to the version 14.3.2.

Regards

Paulo Souza

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

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

Hi Paulo,

i had multiple cases with simillar behaviour and before xmas leave one of the customer upgraded the TMS version and confirmed that the issue doesn't not occur any more in there scenario and they are about to put the box in production.

I can see the status of the BUG as closed now.

Regards

Alok

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: