Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

VIP Green

TMS Scheduled Conferences don't connect with TC7.0.1

I am experiencing an issue with conferences scheduled from TMS (version 14.1.1) with endpoints running TC7.0.1 software.

The conference is created in TMS correctly, and messages appear on the devices that the scheduled conference is due to start (and end), but the conference fails to connect.

A sample of the conference log from TMS is as follows:

8/01/2014   10:31:42 AM

User

Conference   Created

8/01/2014   10:31:42 AM

network service


Conference   Started

8/01/2014   10:31:42 AM

network service

POLYCOM

Meeting   allocated on port: 1

8/01/2014   10:31:42 AM

network service

POLYCOM

Sent message to   participant POLYCOM: Scheduled call being connected

8/01/2014   10:31:43 AM

network service

EX90

Allocation   failed: hostAddress: 10.108.134.33, description: GetDocument Failed. URL: https://10.108.134.33/putxml, base   exception: The underlying connection was closed: An unexpected error occurred   on a send.

8/01/2014   10:31:43 AM

network service

EX90

Sent message to   participant EX90: Scheduled call being connected

8/01/2014   10:31:44 AM

network service

EX90

Allocation   failed: hostAddress: 10.108.134.33, description: GetDocument Failed. URL: https://10.108.134.33/putxml, base   exception: The underlying connection was closed: An unexpected error occurred   on a send.

8/01/2014   10:31:44 AM

network service

EX90

Allocation   failed: hostAddress: 10.108.134.33, description: GetDocument Failed. URL: http://10.108.134.33/putxml, base   exception: The remote server returned an error: (500) Internal Server Error.

8/01/2014   10:31:45 AM

network service

EX90

Allocation   failed: hostAddress: 10.108.134.33, description: GetDocument Failed. URL: https://10.108.134.33/putxml, base   exception: The underlying connection was closed: An unexpected error occurred   on a send.

8/01/2014   10:31:45 AM

network service

EX90

Allocate failed,   conference is not automatically connected

8/01/2014   10:32:19 AM

User

Conference end   time changed from 01/08/2014 11:25:24 to 01/08/2014 10:33:00

8/01/2014   10:32:19 AM

network service

EX90

Sent message to   participant EX90: New end time: 10:33 AM

8/01/2014   10:32:19 AM

network service

POLYCOM

Sent message to   participant POLYCOM: New end time: 10:33 AM

8/01/2014   10:32:51 AM

network service

EX90

Meeting released   on port 1

Note 10.108.134.33 is the IP address of the EX90.

If I downgrade the endpoint(s) back to TC6.3.0 (or earlier), the conference connects correctly and the error mesages from the EX90 are not in the log.

Edit: If I get TMS to schedule the call in the opposite direction (ie, the Polycom, or non TC software endpoint, to the EX90) the call also connects properly.  It's only an issue if the TC7.0.1 device is set to initiate the call.

Wayne

--

Please remember to rate responses and to mark your question as answered if appropriate.

Wayne
--
Please remember to rate responses and to mark your question as answered if appropriate.
Everyone's tags (4)
1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

TMS Scheduled Conferences don't connect with TC7.0.1

Hi Kjetil,

That is correct, I also opened up a defect on the endpoint as it was in TC6 allowing unsupported XML API commands and the goal is to get this documented to point everyone to CSCum50651. The TC defect is CSCum50686.

Thanks,

Chad

17 REPLIES

TMS Scheduled Conferences don't connect with TC7.0.1

Hi Wayne,

I'm just wondering - can you initiate a call from Systems Navigator?

E.g. find the TC7 endpoint in Systems > Navigator, click on the "call status" tab and dial from there?

This could help isolate the issue - i.e. can TMS not control the endpoint at all, or is the issue limited to scheduled conferences.

Also, 14.1.1 is pretty old now and there could possibly be some incompatibilities managing TC7 systems?

VIP Green

TMS Scheduled Conferences don't connect with TC7.0.1

Thanks Nick,

Yes, TMS can dial from the Call Status tab in System Navigator fine.

We are aware that TMS 14.1.1 is old, and we do have plans in place to migrate in the near future to 14.3.x, but can't quite do so yet (we're still working on getting a new 2008 VM configured and ready so we can get off the old physical 2003 server).  We originally couldn't migrate to a more rencet version due to the old Tandberg Scheduler disappearing in TMS 14.2 (and being replaced by the "not so" Smart Scheduler).  All our users were using the old scheuduler, but we've done some extensive re-training over the last few months to get around that issue.

Wayne

--

Please remember to rate responses and to mark your question as answered if appropriate.

Wayne
--
Please remember to rate responses and to mark your question as answered if appropriate.

TMS Scheduled Conferences don't connect with TC7.0.1

The other thing that may be worth trying is to restart the TMS services on the Windows server.  While I haven't experienced the exact issue you are facing, a while ago I had some issues that resulted in similar "Allocate Failed" messages to what you are getting that were resolved by restarting the services.

VIP Green

Re: TMS Scheduled Conferences don't connect with TC7.0.1

Thanks Nick.  I've tried that, and that didn't help either.  I've logged a job with the TAC no: SR 628725167.

Update: 1 hour WebEX session - Logs captured.  It doesn't matter if the call is H.323, SIP, or IP - the call doesn't get connected - the call never hits the VCS-Control - the TC7.0.1 endpoint doesn't even appear to dial.

Wayne

--

Please remember to rate responses and to mark your question as answered if appropriate.

Wayne
--
Please remember to rate responses and to mark your question as answered if appropriate.
Cisco Employee

Re: TMS Scheduled Conferences don't connect with TC7.0.1

Hi,

The endpoint replies with: "The remote server returned an error: (500) Internal Server Error" - is there anything about it in the endpoint log?

TMS dialing out from TC 7.0.1 units works fine in my TMS 14.1.1 by the way. Could be something specific to your endpoints then.

-Kjetil

VIP Green

TMS Scheduled Conferences don't connect with TC7.0.1

Thanks Kjetil,

I just tried another one (call scheduled from 09:30 to 09:37), and I do see some 'failed' errors in the endpoint all.log::

Jan  9 09:30:00.615 ppc appl[2553]: 1467679.56 CuilApp   User admin(1001) about to execute command '/Video/PictureLayoutSet LayoutFamily: Speaker Target: local' from 10.108.129.99.
Jan  9 09:30:00.617 ppc appl[2553]: 1467679.56 CuilApp   User admin(1001) failed to execute command '/Video/PictureLayoutSet LayoutFamily: Speaker Target: local' from 10.108.129.99.
Jan  9 09:30:01.587 ppc appl[2553]: 1467680.53 CuilApp   User admin(1001) about to execute command '/Message/Alert/Display Duration: 10 Text: Scheduled call being connected' from 10.108.129.99.
Jan  9 09:30:02.030 ppc appl[2553]: 1467680.97 CuilApp   User admin(1001) about to execute command '/Video/PictureLayoutSet LayoutFamily: Speaker Target: local' from 10.108.129.99.
Jan  9 09:30:02.031 ppc appl[2553]: 1467680.98 CuilApp   User admin(1001) failed to execute command '/Video/PictureLayoutSet LayoutFamily: Speaker Target: local' from 10.108.129.99.
Jan  9 09:30:02.490 ppc appl[2553]: 1467681.43 CuilApp   User admin(1001) about to execute command '/Video/PictureLayoutSet LayoutFamily: Speaker Target: local' from 10.108.129.99.
Jan  9 09:30:02.493 ppc appl[2553]: 1467681.44 CuilApp   User admin(1001) failed to execute command '/Video/PictureLayoutSet LayoutFamily: Speaker Target: local' from 10.108.129.99.
Jan  9 09:30:03.046 ppc appl[2553]: 1467681.99 CuilApp   User admin(1001) about to execute command '/Video/PictureLayoutSet LayoutFamily: Speaker Target: local' from 10.108.129.99.
Jan  9 09:30:03.050 ppc appl[2553]: 1467681.99 CuilApp   User admin(1001) failed to execute command '/Video/PictureLayoutSet LayoutFamily: Speaker Target: local' from 10.108.129.99.
Jan  9 09:32:00.830 ppc appl[2553]: 1467799.77 CuilApp   User admin(1001) about to execute command '/Message/Prompt/Display Option.1: Yes Option.2: No Text: Scheduled meeting ends in 5 minutes. Do you want to extend the meeting for 15 minutes? Title: Extend meeting' from 10.108.129.99.
Jan  9 09:36:51.698 ppc appl[2553]: 1468090.64 CuilApp   User admin(1001) about to execute command '/Message/Prompt/Clear' from 10.108.129.99.
Jan  9 09:36:52.106 ppc appl[2553]: 1468091.05 CuilApp   User admin(1001) about to execute command '/Call/DisconnectAll' from 10.108.129.99.

In the web.log, there's a whole pile of these errors:

2014-01-09 09:30:00,629 ERROR - vega.wsgi.exception:52: Request to /putxml crashed, returning 500
2014-01-09 09:30:02,043 ERROR - vega.wsgi.exception:52: Request to /putxml crashed, returning 500
2014-01-09 09:30:02,504 ERROR - vega.wsgi.exception:52: Request to /putxml crashed, returning 500
2014-01-09 09:30:03,061 ERROR - vega.wsgi.exception:52: Request to /putxml crashed, returning 500

And web.err.log:

Error at 2014-01-09 09:30:00.631961
Traceback (most recent call last):
  File "/web/vega/vega/wsgi/exception.py", line 23, in __call__
    return self.app(environ, start_response)
  File "/web/vega/vega/wsgi/antiproxy.py", line 14, in __call__
    return self.app(environ, start_response)
  File "/web/vega/vega/wsgi/cookie.py", line 12, in __call__
    return self.app(environ, start_response)
  File "/web/vega/vega/routes/middleware.py", line 51, in __call__
    return self.app(environ, start_response)
  File "/web/vega/vega/auth/authmiddleware.py", line 72, in __call__
    return self.apps[method](environ, start_response)
  File "/web/vega/vega/auth/basic.py", line 21, in __call__
    return self.app(environ, start_response)
  File "/web/vega/vega/wsgi/controller_dispatcher.py", line 36, in __call__
    app_iter = controller(environ, start_response)
  File "/web/vega/vega/controllers/web2tsh.py", line 22, in __call__
    return Web2TshHandler(s)(environ, start_response)
  File "/web/vega/vega/web2tsh/wsgi.py", line 40, in __call__
    return handler(request)(environ, start_response)
  File "/web/vega/vega/web2tsh/wsgi.py", line 180, in putxml_handler
    if self.should_remove_from_response(child):
  File "/web/vega/vega/web2tsh/wsgi.py", line 127, in should_remove_from_response
    or node.attrib['status'] == 'Error'
  File "lxml.etree.pyx", line 2275, in lxml.etree._Attrib.__getitem__ (src/lxml/lxml.etree.c:54623)
KeyError: 'status'
{'ACTUAL_SERVER_PROTOCOL': 'HTTP/1.1',
 'AUTH_METHOD': 'basic',
 'CONTENT_LENGTH': '144',
 'CONTENT_TYPE': 'text/xml; charset=utf-8',
 'HTTP_AUTHORIZATION': 'Basic YWRtaW46VEFOREJFUkc=',
 'HTTP_HOST': '10.108.134.33',
 'HTTP_PRAGMA': 'no-cache',
 'HTTP_USER_AGENT': 'TMS Http User Agent (compatible; MSIE 5.5; Windows NT 5.0)',
 'HTTP_X_FORWARDED_FOR': '10.108.129.99',
 'HTTP_X_FORWARDED_PROTO': 'http',
 'HTTP_X_HOST': '10.108.134.33',
 'PATH_INFO': '/putxml',
 'QUERY_STRING': '',
 'REMOTE_ADDR': '10.108.129.99',
 'REMOTE_PORT': '54672',
 'REQUEST_METHOD': 'POST',
 'REQUEST_URI': '/putxml',
 'SCRIPT_NAME': '',
 'SERVER_NAME': 'CAA-SUPPORT2',
 'SERVER_PORT': '3000',
 'SERVER_PROTOCOL': 'HTTP/1.0',
 'SERVER_SOFTWARE': 'CherryPy/3.2.4 Server',
 'session-flash': {},
 'sessions': ,
 'users': ,
 'vega.user': ,
 'webob._body_file': (<_io.BufferedReader>,
                      ),
 'webob.is_body_seekable': True,
 'wsgi.errors': ', mode 'w' at 0x480580d0>,
 'wsgi.input': <_io.BytesIO object at 0x49c6cae0>,
 'wsgi.multiprocess': False,
 'wsgi.multithread': True,
 'wsgi.run_once': False,
 'wsgi.url_scheme': 'http',
 'wsgi.version': (1, 0),
 'wsgiorg.routing_args': (None,
                          {'action': 'index',
                           'auth': 'basic',
                           'controller': 'web2tsh',
                           'methods': 'GET POST'})}
Error at 2014-01-09 09:30:02.045299
Traceback (most recent call last):
  File "/web/vega/vega/wsgi/exception.py", line 23, in __call__
    return self.app(environ, start_response)
  File "/web/vega/vega/wsgi/antiproxy.py", line 14, in __call__
    return self.app(environ, start_response)
  File "/web/vega/vega/wsgi/cookie.py", line 12, in __call__
    return self.app(environ, start_response)
  File "/web/vega/vega/routes/middleware.py", line 51, in __call__
    return self.app(environ, start_response)
  File "/web/vega/vega/auth/authmiddleware.py", line 72, in __call__
    return self.apps[method](environ, start_response)
  File "/web/vega/vega/auth/basic.py", line 21, in __call__
    return self.app(environ, start_response)
  File "/web/vega/vega/wsgi/controller_dispatcher.py", line 36, in __call__
    app_iter = controller(environ, start_response)
  File "/web/vega/vega/controllers/web2tsh.py", line 22, in __call__
    return Web2TshHandler(s)(environ, start_response)
  File "/web/vega/vega/web2tsh/wsgi.py", line 40, in __call__
    return handler(request)(environ, start_response)
  File "/web/vega/vega/web2tsh/wsgi.py", line 180, in putxml_handler
    if self.should_remove_from_response(child):
  File "/web/vega/vega/web2tsh/wsgi.py", line 127, in should_remove_from_response
    or node.attrib['status'] == 'Error'
  File "lxml.etree.pyx", line 2275, in lxml.etree._Attrib.__getitem__ (src/lxml/lxml.etree.c:54623)
KeyError: 'status'
{'ACTUAL_SERVER_PROTOCOL': 'HTTP/1.1',
 'AUTH_METHOD': 'basic',
 'CONTENT_LENGTH': '144',
 'CONTENT_TYPE': 'text/xml; charset=utf-8',
 'HTTP_AUTHORIZATION': 'Basic YWRtaW46VEFOREJFUkc=',
 'HTTP_HOST': '10.108.134.33',
 'HTTP_PRAGMA': 'no-cache',
 'HTTP_USER_AGENT': 'TMS Http User Agent (compatible; MSIE 5.5; Windows NT 5.0)',
 'HTTP_X_FORWARDED_FOR': '10.108.129.99',
 'HTTP_X_FORWARDED_PROTO': 'http',
 'HTTP_X_HOST': '10.108.134.33',
 'PATH_INFO': '/putxml',
 'QUERY_STRING': '',
 'REMOTE_ADDR': '10.108.129.99',
 'REMOTE_PORT': '54680',
 'REQUEST_METHOD': 'POST',
 'REQUEST_URI': '/putxml',
 'SCRIPT_NAME': '',
 'SERVER_NAME': 'CAA-SUPPORT2',
 'SERVER_PORT': '3000',
 'SERVER_PROTOCOL': 'HTTP/1.0',
 'SERVER_SOFTWARE': 'CherryPy/3.2.4 Server',
 'session-flash': {},
 'sessions': ,
 'users': ,
 'vega.user': ,
 'webob._body_file': (<_io.BufferedReader>,
                      ),
 'webob.is_body_seekable': True,
 'wsgi.errors': ', mode 'w' at 0x480580d0>,
 'wsgi.input': <_io.BytesIO object at 0x49c2c810>,
 'wsgi.multiprocess': False,
 'wsgi.multithread': True,
 'wsgi.run_once': False,
 'wsgi.url_scheme': 'http',
 'wsgi.version': (1, 0),
 'wsgiorg.routing_args': (None,
                          {'action': 'index',
                           'auth': 'basic',
                           'controller': 'web2tsh',
                           'methods': 'GET POST'})}
Error at 2014-01-09 09:30:02.506544
Traceback (most recent call last):
  File "/web/vega/vega/wsgi/exception.py", line 23, in __call__
    return self.app(environ, start_response)
  File "/web/vega/vega/wsgi/antiproxy.py", line 14, in __call__
    return self.app(environ, start_response)
  File "/web/vega/vega/wsgi/cookie.py", line 12, in __call__
    return self.app(environ, start_response)
  File "/web/vega/vega/routes/middleware.py", line 51, in __call__
    return self.app(environ, start_response)
  File "/web/vega/vega/auth/authmiddleware.py", line 72, in __call__
    return self.apps[method](environ, start_response)
  File "/web/vega/vega/auth/basic.py", line 21, in __call__
    return self.app(environ, start_response)
  File "/web/vega/vega/wsgi/controller_dispatcher.py", line 36, in __call__
    app_iter = controller(environ, start_response)
  File "/web/vega/vega/controllers/web2tsh.py", line 22, in __call__
    return Web2TshHandler(s)(environ, start_response)
  File "/web/vega/vega/web2tsh/wsgi.py", line 40, in __call__
    return handler(request)(environ, start_response)
  File "/web/vega/vega/web2tsh/wsgi.py", line 180, in putxml_handler
    if self.should_remove_from_response(child):
  File "/web/vega/vega/web2tsh/wsgi.py", line 127, in should_remove_from_response
    or node.attrib['status'] == 'Error'
  File "lxml.etree.pyx", line 2275, in lxml.etree._Attrib.__getitem__ (src/lxml/lxml.etree.c:54623)
KeyError: 'status'
{'ACTUAL_SERVER_PROTOCOL': 'HTTP/1.1',
 'AUTH_METHOD': 'basic',
 'CONTENT_LENGTH': '144',
 'CONTENT_TYPE': 'text/xml; charset=utf-8',
 'HTTP_AUTHORIZATION': 'Basic YWRtaW46VEFOREJFUkc=',
 'HTTP_HOST': '10.108.134.33',
 'HTTP_PRAGMA': 'no-cache',
 'HTTP_USER_AGENT': 'TMS Http User Agent (compatible; MSIE 5.5; Windows NT 5.0)',
 'HTTP_X_FORWARDED_FOR': '10.108.129.99',
 'HTTP_X_FORWARDED_PROTO': 'http',
 'HTTP_X_HOST': '10.108.134.33',
 'PATH_INFO': '/putxml',
 'QUERY_STRING': '',
 'REMOTE_ADDR': '10.108.129.99',
 'REMOTE_PORT': '54682',
 'REQUEST_METHOD': 'POST',
 'REQUEST_URI': '/putxml',
 'SCRIPT_NAME': '',
 'SERVER_NAME': 'CAA-SUPPORT2',
 'SERVER_PORT': '3000',
 'SERVER_PROTOCOL': 'HTTP/1.0',
 'SERVER_SOFTWARE': 'CherryPy/3.2.4 Server',
 'session-flash': {},
 'sessions': ,
 'users': ,
 'vega.user': ,
 'webob._body_file': (<_io.BufferedReader>,
                      ),
 'webob.is_body_seekable': True,
 'wsgi.errors': ', mode 'w' at 0x480580d0>,
 'wsgi.input': <_io.BytesIO object at 0x49c2cc30>,
 'wsgi.multiprocess': False,
 'wsgi.multithread': True,
 'wsgi.run_once': False,
 'wsgi.url_scheme': 'http',
 'wsgi.version': (1, 0),
 'wsgiorg.routing_args': (None,
                          {'action': 'index',
                           'auth': 'basic',
                           'controller': 'web2tsh',
                           'methods': 'GET POST'})}
Error at 2014-01-09 09:30:03.063475
Traceback (most recent call last):
  File "/web/vega/vega/wsgi/exception.py", line 23, in __call__
    return self.app(environ, start_response)
  File "/web/vega/vega/wsgi/antiproxy.py", line 14, in __call__
    return self.app(environ, start_response)
  File "/web/vega/vega/wsgi/cookie.py", line 12, in __call__
    return self.app(environ, start_response)
  File "/web/vega/vega/routes/middleware.py", line 51, in __call__
    return self.app(environ, start_response)
  File "/web/vega/vega/auth/authmiddleware.py", line 72, in __call__
    return self.apps[method](environ, start_response)
  File "/web/vega/vega/auth/basic.py", line 21, in __call__
    return self.app(environ, start_response)
  File "/web/vega/vega/wsgi/controller_dispatcher.py", line 36, in __call__
    app_iter = controller(environ, start_response)
  File "/web/vega/vega/controllers/web2tsh.py", line 22, in __call__
    return Web2TshHandler(s)(environ, start_response)
  File "/web/vega/vega/web2tsh/wsgi.py", line 40, in __call__
    return handler(request)(environ, start_response)
  File "/web/vega/vega/web2tsh/wsgi.py", line 180, in putxml_handler
    if self.should_remove_from_response(child):
  File "/web/vega/vega/web2tsh/wsgi.py", line 127, in should_remove_from_response
    or node.attrib['status'] == 'Error'
  File "lxml.etree.pyx", line 2275, in lxml.etree._Attrib.__getitem__ (src/lxml/lxml.etree.c:54623)
KeyError: 'status'
{'ACTUAL_SERVER_PROTOCOL': 'HTTP/1.1',
 'AUTH_METHOD': 'basic',
 'CONTENT_LENGTH': '144',
 'CONTENT_TYPE': 'text/xml; charset=utf-8',
 'HTTP_AUTHORIZATION': 'Basic YWRtaW46VEFOREJFUkc=',
 'HTTP_HOST': '10.108.134.33',
 'HTTP_PRAGMA': 'no-cache',
 'HTTP_USER_AGENT': 'TMS Http User Agent (compatible; MSIE 5.5; Windows NT 5.0)',
 'HTTP_X_FORWARDED_FOR': '10.108.129.99',
 'HTTP_X_FORWARDED_PROTO': 'http',
 'HTTP_X_HOST': '10.108.134.33',
 'PATH_INFO': '/putxml',
 'QUERY_STRING': '',
 'REMOTE_ADDR': '10.108.129.99',
 'REMOTE_PORT': '54684',
 'REQUEST_METHOD': 'POST',
 'REQUEST_URI': '/putxml',
 'SCRIPT_NAME': '',
 'SERVER_NAME': 'CAA-SUPPORT2',
 'SERVER_PORT': '3000',
 'SERVER_PROTOCOL': 'HTTP/1.0',
 'SERVER_SOFTWARE': 'CherryPy/3.2.4 Server',
 'session-flash': {},
 'sessions': ,
 'users': ,
 'vega.user': ,
 'webob._body_file': (<_io.BufferedReader>,
                      ),
 'webob.is_body_seekable': True,
 'wsgi.errors': ', mode 'w' at 0x480580d0>,
 'wsgi.input': <_io.BytesIO object at 0x4a1455d0>,
 'wsgi.multiprocess': False,
 'wsgi.multithread': True,
 'wsgi.run_once': False,
 'wsgi.url_scheme': 'http',
 'wsgi.version': (1, 0),
 'wsgiorg.routing_args': (None,
                          {'action': 'index',
                           'auth': 'basic',
                           'controller': 'web2tsh',
                           'methods': 'GET POST'})}

Wayne

--

Please remember to rate responses and to mark your question as answered if appropriate.

Wayne
--
Please remember to rate responses and to mark your question as answered if appropriate.
Cisco Employee

Re: TMS Scheduled Conferences don't connect with TC7.0.1

Hi Wayne,

I have been able to duplicate your issue on TMS 14.2.2 and with endpoints on TC7.0.1. The key to this issue is the picture mode used when booking the conference with TMS. If you select Enhanced CP as the picture mode and the master or main participant is running TC7.0.1 then the conference will not connect as the allocation fails.

In the packet capture attached to the case the TC7.0.1 endpoint responds with a 500 Internal Server error. I have tested that in TC6.30 selecting enhanced CP as the picture mode works.

This tells me that the API changed in TC7.0.1. I am reaching out to some colleagues to find out if there was a design change for this issue or if a defect should be opened. They will let me know one way or the other and we will either fix it or document the change. For now the workaround is to set the picture mode to either Voice Switched or Continuous presence.

VIP Green

Re: TMS Scheduled Conferences don't connect with TC7.0.1

Thanks Chad,

Great news that can replicate the issue and have found the possible cause.

I can confirm that the workaround of changing the picture type from “Enhanced CP” back to “Continuous Presence” does allow the call to be scheduled in my environment from a TC7.0.1 endpoint.

Look forward to hearing what the API/endpoint software people have to say regarding the change in behaviour (and the lack of any reference to a change that I can see in the release notes if it was “by design”).

Wayne

--

Please remember to rate responses and to mark your question as answered if appropriate.

Wayne
--
Please remember to rate responses and to mark your question as answered if appropriate.
Bronze

TMS Scheduled Conferences don't connect with TC7.0.1

Hi Wayne,

TMS wants to set the PictureLayout parameter to a value which is not acceptable for the endpoint and thus, the web server returns an error. What's new in TC7 is that such errors are now properly handled. Instead of just ignoring the command, the web server now returns an html page with: "The server could not properly process the request".

You can easily reproduce what TMS is doing by pasting this url in your browser (just make sure to enter the correct IP) :

http://IP/formputxml?xmldoc=

The API guide says that LayoutFamily should be configured with one of the  following values:  auto/custom/equal/fullscreen/overlay/presentationlargespeaker/presentationsmallspeaker/prominent/single/speaker_full. In your case,  TMS pushes "Speaker". It's a TMS bug.

VIP Green

TMS Scheduled Conferences don't connect with TC7.0.1

Thanks for the clarification Thomas.

Is there a Bug reference number for this TMS issue that we can track to see when it's fixed?

Wayne

--

Please remember to rate responses and to mark your question as answered if appropriate.

Wayne
--
Please remember to rate responses and to mark your question as answered if appropriate.
Cisco Employee

TMS Scheduled Conferences don't connect with TC7.0.1

Wayne DeNardi wrote:

[...] Is there a Bug reference number for this TMS issue that we can track to see when it's fixed? [...]

I am waiting for Chad to file a bug as he was the first one to duplicate the problem. :-)

Regards,

Kjetil

Cisco Employee

TMS Scheduled Conferences don't connect with TC7.0.1

Hi Kjetil & Wayne,

I will get this filed today and report back the bug ID.

Thank You,

Chad

Cisco Employee

TMS Scheduled Conferences don't connect with TC7.0.1

I will get this filed today and report back the bug ID.

CSCum50651 I presume.

Kjetil

Cisco Employee

TMS Scheduled Conferences don't connect with TC7.0.1

Hi Kjetil,

That is correct, I also opened up a defect on the endpoint as it was in TC6 allowing unsupported XML API commands and the goal is to get this documented to point everyone to CSCum50651. The TC defect is CSCum50686.

Thanks,

Chad

VIP Purple

Chad - Is there an eta when

Chad - Is there an eta when this might be fixed?  I'm hesitant to upgrade our codecs to TC7.x because we have about 100 conferences already scheduled in TMS that the layout would need to be changed to workaround this issue.  The OpenSSL issue that is currently going on right now, will make us have to upgrade the codecs (as that issue has been detected by us and others running C-Series codecs), and I'd hate to upgrade and then find out our conferences fail to connect.

Cisco Employee

Hi Patrik,It has been

Hi Patrik,

It has been resolved in TMS 14.4. We expect to release 14.4 in early May.

Regards,
Kjetil

Cisco Employee

Hi Patrick,Bug CSCum50651 is

Hi Patrick,

Bug CSCum50651 is planned to be fixed in 14.4. I don't have a commitment date on when it will be released. Unfortunately I am not working in the TelePresence group anymore so I am not part of the updates.

Maybe Kjetil will be able to add an ETA in regards to when 14.4 is being released.

Chad

1228
Views
35
Helpful
17
Replies