TMS 14.3 - Bug CSCui90143 versus Polycom endpoints

[Paulo Souza]

Hi folks,

I am aware that TMS doesn't recognize SIP options for Polycom HDX endpoints. Therefore, I cannot manage or booking SIP parameters for polycom endpoints. According to this documment, although it is a little old.

Actually, I have a scenario with Conductor XC2.2 and TMS 14.3, and I am hitting this bug CSCui90143 (Read this thread). Because of this deffect and because of the limitation above, everytime a schedule a conference in TMS with type "Automatic Connect" and select Conductor + Polycom endpoints, TMS sets the connection setting to be "Conductor SIP--->H323 Polycom", therefore, multiple calls attempts are made from Conductor to the endpoints when the conference starts because of this bug CSCui90143, and that causes so many issues.

I need some suggestion on how to fix this issue, at least some workaround, while Cisco doesn't provide a fix to the bug CSCui90143.

I am aware that I can set H323 ID to be a SIP URI and then force TMS to use H323 ID instead of E164 alias when scheduling, however, that is not an option for me, because this configuration in TMS is global, so it would bring so many another issues.

Any suggestion? I would really appreciate any help.

Thanks in advance.

Paulo Souza

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

[Nick Halbert-Lillyman]

What if you deleted the E164 alias from Polycom TMS endpoints, so that TMS's only option was to use the H323 ID for scheduling? You could then use search rules or transforms so that manuallly dialled E164's mapped to the correct H323 ID.

It wouldn't be pretty, but it might get you out of trouble while you wait for a "cleaner" solution.

[Paulo Souza]

Hi Nick,

Thank you very much for your reply.

Well, I did consider this possibility as well. But the customer didn't like that "solution", because the result of this method would be the same like I descrive above:

Paulo Souza wrote:
I am aware that I can set H323 ID to be a SIP URI and then force TMS to use H323 ID instead of E164 alias when scheduling, however, that is not an option for me, because this configuration in TMS is global, so it would bring so many another issues.

To apply your suggestion, I would have to configure H323 ID to be a SIP URI, something like 55554444@domain, otherwise I would hit the same bug condition. And the result is, using H323 ID as URI, the display name of the endpoint would be a URI format and not a name indeed, because the H323 protocol doesn't have a field to inform the display name, like SIP has, so that the display name in the conference will be 55554444@domain.

That is bad for the customer, because they have too many sites, therefore, I need to use a name as "display name" indeed, otherwise the users won't be able to identify each other in the conference, I cant use number or URI.

Do you see? I cannot simply dial H323 ID (mapping H323 ID to E164 alias), I need to set a URI format in TMS to be dialed from Conductor when scheduling, otherwise the bug will happen.

It seems I'm in a dead end. 

Thanks again!

Paulo Souza

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

[Alok Jaiswal]

Hi Paulo,

as per my testing this bug should not hit the H.323 auto dial. we need more logs to verify behavior in your enviornment.

Rgds

Alok

[Paulo Souza]

Hi Alok,

Thanks for your reply.

Based upon what I have seen, the problem occurs whenever TMS sets Conductor do dialout a non-URI destination, either SIP or H323. For exemple, if I schedule a conference and add an external participant using dialout using H323 with destination a URI, then the problem does not occur, but if the same destination is not a URI format, the problem does occur. That's why I came to conclusion that it is not related to the protocol being used, but to the non-URI destination.

I will perform further tests today and collect some logs. I will keep you posted.

I really apreciate your help. Thanks.

Paulo Souza

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

[t.svatek]

Hi Paulo

You could register the HDX via SIP instead of H.323 and add it as a room type endpoint. TMS isnt a 3rd Party VC mgmt System anymore, which your customer will understand and a SIP- only deployment makes things easier especually with conductor.

Thanks
Tino

Sent from Cisco Technical Support iPhone App

[Paulo Souza]

Hi Tino, thanks for your reply.

I understand your point and I already have some old Polycom endpoints registered to TMS as room. For those endpoints, the problem does not occur indeed, since TMS uses SIP URI to dialout from Conductor.

But I need to have another Polycom endpoints being managed by TMS anyway, because the customer needs some features that only works when the system is managed by TMS. Unfortunately, I cannot simply take those features away and say "Hey guys, it doesn't work anymore, sorry."

I am aware that Conductor deployment is based upon SIP and I already have all the environment set to use SIP instead of H323. That is not the matter. Even if TMS sets Conductor to dialout using "SIP to H323 e164 alias", the call will be made SIP to SIP, because VCS will suffix "@domain" to the e164 alias and it will match the SIP URI used by the Polycom endpoints.

Therefore, the protocols and possible convertions are not the problem. The issue is, TMS is unable to correctly set Conductor to dialout a non-URI destination, everytime I have this going on, I hit the bug and multiple call attempts are made from Conductor to the endpoints.

Thanks again.

Paulo Souza

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

[t.svatek]

Not sure which features are used - there are not too much available with hdx, but you could add the room based endpoint in addition to the native polycom endpoint for booking only

Sent from Cisco Technical Support iPhone App

[Paulo Souza]

Yeah! I could do that, however it would require additional licenses in TMS. We have about 50 polycom endpoints in TMS. It is very hard to suggest the customer to buy additional TMS licenses just because of bug on the product.

Well, it is a complicated situation. Now I need some workaround that doesn't take features away from the customer and doesn't demand them to buy additional things.

With regards the features available in TMS for Polycom HDX endpoints, there are many, you can check some of them in this documment: http://www.cisco.com/en/US/docs/telepresence/infrastructure/tms/interoperability/Cisco_TMS_Feature_Support_Matrix.xls

But for them, the main feature that they need is, when you schedule a conference in TMS including Polycom HDX endpoints, the endpoints shows a message on the screen informing that the system is scheduled to a Meeting and also inform when the Meeting is being connected (it looks like OBTP).

This may not be so important in most cases, but for this customer, in particular, it is extremely important.

Thanks again.

Paulo Souza

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

[Paulo Souza]

Any another suggestion?

Paulo Souza

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

[Patrick Sparkman]

Hello Paulo -

Were you able to figure out a fix for this?  I'm running into a similar issue with H323 only systems, where Conductor appends it's SIP trunk address to anything dialed without a domain causing multiple calls being created.  This is occuring for me with a TCS that is clustered, since a clustered TCS can't only work using H323.

[Paulo Souza]

Hi Patrick,

This behavior is a bug indeed and has Cisco already fixed it. The version TMS 14.3.2 has the fix for this issue.

I have not installed the version yet, but according to Cisco TAC, this version of TMS does not run this bug, although the Release Notes of the version 14.3.2 says nothing with regards this matter.

Try version 14.3.2 and tell me the result. Our customer is plainning to apply the upgrade only in February, I think. I can give you a feedback only after this.

Regards

Paulo Souza

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

[Patrick Sparkman]

Paulo -

I updated our TMS this morning and just did a test, when TMS dialed out it created a duplicate entry as before with the Conductor SIP trunk address appended at the end.  No change.

If Conductor could be made to send requests through the SIP trunk, but not append it to every alias that doesn't contain a domain would easily fix the issue for H323 addresses without domain.  I don't how hard that would be, but it "seems" like a solution if it's possible.

[Alok Jaiswal]

Patrick,

are you using 14.3.2 software version ?

Regards

Alok

[Patrick Sparkman]

Alok -

Yes, I am, just upgraded this morning.  The person that has my TAC case knows of the BUG, and I'll let him know about this and the other discussions here in the forums tomorrow when we have a call.