Specific questions about usage, parameters, context, and scope of the Active Meeting Management (AMM) API http://developer.cisco.com/c/message_boards/find_category?p_l_id=&mbCategoryId=5885522 2013-05-21T03:13:18Z 2013-05-21T03:13:18Z John Yontz http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=14863625 2013-05-01T22:54:44Z 2013-05-01T22:54:44Z

Hi Mike, The AMM requests to drop, redial, mute/unmute, and send endpoint text return with success when the operation is initiated to the bridge resource.  The request does not wait for the operation to complete (either from bridge resource response or telephony signaling).  It looks like our documentation needs to be clearer about that. For the scenario that you describe, you have two options:  You can provide a safe delay between the previous drop and the redial attempt.  It looks like 5 seconds works for you, but perhaps you could increase to 10 seconds to be absolutely certain.  The other option is to always retrieve the list of active participants prior to doing the redial. If the participant to be redialed still shows as active, you can delay and re-retrieve the status until it is not active. By the way, in 1.3 the GetCurrentMeetingStatus result will also include the previous participants (in addition to the active participants). - John

John Yontz 2013-05-01T22:54:44Z John Yontz http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=13953158 2013-04-06T01:20:45Z 2013-04-06T01:20:45Z

Hi Mike, Sorry for the late reply on this.  I had discussed this with my team, and we are not aware of this type of failure.  We searched the open defect and could not find anything on this either.  The error is coming directly from the CTMS, and CTX is relaying it via the API.  My guess is that if you tried the same operation using the CTX Admin Meeting Diagnostics Page, you would see the same result.  That is, when it fails, it should fail in both.  Perhaps this is related to a specific version of the CTMS software?  I would recommend that you open a defect and include in the defect the CTMS version, the type of endpoint(s) that fail, endpoint versions, and how reproduceable it is. Thanks - John

John Yontz 2013-04-06T01:20:45Z Michael Nelson http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=13946209 2013-04-05T22:00:24Z 2013-04-05T22:00:24Z

Anything on this question?

Michael Nelson 2013-04-05T22:00:24Z Michael Nelson http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=13676338 2013-03-29T21:56:48Z 2013-03-29T21:56:48Z

We are getting a error.amm.callControlException.muteFailed exception when issuing a muteParticipant. The message in the exception is "Error muting participants:   Error muting/unmuting participant(s): Not able to mute/unmute participant". Can you provide some additional guidence on this return code and where we might find more information to help determine the issue. This has been reported for a meeting on a CTMS bridge with CTS endpoints.

Michael Nelson 2013-03-29T21:56:48Z John Yontz http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=12170192 2013-02-20T18:10:40Z 2013-02-20T17:47:26Z

Hi Mike, This issue has also been reported by another partner and a defect has been raised for it: CSCue57886.  Unfortunately, there is no workaround.  We are planning for a patch to fix this, but I am not clear on the delivery date. - John

John Yontz 2013-02-20T17:47:26Z Michael Nelson http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=12161050 2013-02-20T14:31:36Z 2013-02-20T14:31:36Z

It appears that the isMuted is always returning false in the participantsInCurrentMeeting item in the getCurrentMeetingStatus response. We are seeing false for both CTMS and TPS (8710) bridges. Is there an issue with this or is there something we need to do differently to receive the mute status?

Michael Nelson 2013-02-20T14:31:36Z John Yontz http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=11901590 2013-02-13T19:10:40Z 2013-02-13T19:10:40Z

Hi Mike, I've verified that the following is a defect: > Case 3: Endpoint added at the 14-minute mark >> 2 15-minute extensions (1 extra extension) And I trust that the others that you reported are variations on this.  Please open a defect for this (using your normal channels), attach all of your findings to that defect, and mention that the CTX development team has specifically confirmed the failure in case 3.  You can mention my name in the defect if you wish. Thanks for your research on this. - John

John Yontz 2013-02-13T19:10:40Z Michael Nelson http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=11898534 2013-02-13T17:15:22Z 2013-02-13T17:15:22Z

Some additional scenarios: [color=#1f497d]****[/color] [color=#1f497d]Scheduled Meeting Duration: 15 mins[/color] [color=#1f497d]Scheduled Meeting extension enabled type: ENABLE[/color] [color=#1f497d]Scheduled Extension period: 15 mins[/color] [color=#1f497d]Scheduled Number of extensions: 2[/color] [color=#1f497d]Active meeting new Duration: null[/color] [color=#1f497d]Active meeting extension enabled type: null if within first 13 mins else DISABLE[/color] [color=#1f497d]Active meeting Extension period: null[/color] [color=#1f497d]Active meeting Number of extensions: null[/color] [color=#1f497d]>> [/color]Tried adding endpoint in the first meeting extension at 20mins mark, request fails with message “Cannot change the meeting extension enabled setting for active meeting.” [color=#1f497d]>>   [/color][color=#1f497d]Tried adding endpoint in the second meeting extension at 40 mins mark, request fails with message “Cannot change the meeting extension enabled setting for active meeting.”[/color] [color=#1f497d]****[/color] [color=#1f497d]Scheduled Meeting Duration: 15 mins[/color] [color=#1f497d]Scheduled Meeting extension enabled type: ENABLE[/color] [color=#1f497d]Scheduled Extension period: 15 mins[/color] [color=#1f497d]Scheduled Number of extensions: 1[/color] [color=#1f497d]Active meeting new Duration: null[/color] [color=#1f497d]Active meeting extension enabled type: null if within first 13 mins else DISABLE[/color] [color=#1f497d]Active meeting Extension period: null[/color] [color=#1f497d]Active meeting Number of extensions: null[/color] >>[color=#1f497d]       [/color][color=#1f497d]Tried adding endpoint in the meeting extension at 20mins mark, request fails with message “Cannot change the meeting extension enabled setting for active meeting.”[/color] [color=#1f497d][/color] [color=#1f497d]****[/color]

Michael Nelson 2013-02-13T17:15:22Z John Yontz http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=11868035 2013-02-12T23:22:22Z 2013-02-12T23:22:22Z

Hi Mike, Thank you for the detailed analysis.  With this information, we will attempt to reproduce and diagnose here.  I will aim to respond within the next day or so. - John

John Yontz 2013-02-12T23:22:22Z Michael Nelson http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=11867094 2013-02-12T23:17:43Z 2013-02-12T23:17:43Z

Some additional testing has provided the following: Scenario: Meet-me meeting, scheduled duration = 15 minutes, Meeting Extension Enabled Type = ENABLED, Meeting Extension Period = 15 minutes, Number of Extensions = 1 Active Meeting Management API Modify Meeting parameters: Duration = null, Meeting Extension Enabled Type = null, Meeting Extension Period = null, Number of Extensions = null   Case 1: No endpoints added during the meeting >> 1 15-minute extension (as expected) Case 2: Endpoint added at the 10-minute mark >> 1 15-minute extension (as expected) Case 3: Endpoint added at the 14-minute mark >> 2 15-minute extensions (1 extra extension) Case 4: Endpoint added at the 20-minute mark (5 minutes into 1st extension) >> 2 15-minute extensions (1 extra extension) Case 5:  Endpoint added at the 10-minute mark and at the 20-minute mark (5 minutes into 1st extension) >> 2 15-minute extensions (1 extra extension) Case 6: Endpoint added at the 10-minute mark and at the 12-minute mark >> 1 15-minute extensions (as expected) Case 7: Endpoint added at the 20-minute mark (5 minutes into 1st extension) and the 22-minute mark (7 minutes into 1st extension) >> 2 15-minute extensions (1 extra extension)   Another group reported: Meeting extension is added if another endpoint is dialed out to after the notice of meeting extension is seen. For example with 2 minutes left in the scheduled meeting the text saying "your meeting has been extended 15 minutes" is displayed. If an endpoint is dialed out after that, the meeting is extended 15 minutes as expected but then again for a second 15 minutes. If you dial out another endpoint after you are in the first meeting extension you get a third extension. Dropping the endpoint that was dialed out does not cause the meeting extension to be taken away.   Can you advise us if when we add an endpoint within the "meeting extension period" (see definition that follows) and specify DISABLE for the Meeting Extension Enabled Type will that stop any further meeting extensions? We observed that once the meeting is at the 2 minute warning the CTX shows the extension being added so for the purposes of this question consider the "meeting extension period" to be any time within 2-minutes of the meeting ending or in meeting extension time.

Michael Nelson 2013-02-12T23:17:43Z Michael Nelson http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=11855271 2013-02-12T17:48:49Z 2013-02-12T17:48:49Z

In the modifyActiveMeeting method we are always passing null for the duration (we do not allow the duration to be changed). We are also passing the three meeting extension parameters as null. We are seeing in at least the case when an unprovisioned endpoint is added to a meeting after the 2-minute warning that the meeting gets an additional extension.  

Michael Nelson 2013-02-12T17:48:49Z John Yontz http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=11827320 2013-02-12T00:20:55Z 2013-02-12T00:20:55Z

Hi Mike, From looking at the code, the logic seems correct.  While a meeting is active, the only way to allow additional extensions (i.e. reset the current number of extensions to 0) is to (a) modify the extension attributes (which you are clearly not doing by your usage of null parameters), or (b) modify the meeting to explicitly lengthen it (i.e. setting the duration to a larger number).  I cannot see any way how the adding of an endpoint could result in this behavior.  Is it possible that you are doing (b) inadvertently?  Using soapUI on an active meeting, you can easily verify this by setting the duration to null during the modify operation. Let us know what you discover on this.  Thanks. - John

John Yontz 2013-02-12T00:20:55Z Michael Nelson http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=11822553 2013-02-11T21:00:57Z 2013-02-11T21:00:57Z

We are seeing that when an endpoint is added using the AMM API to a meeting that is currently in meeting extension, the meeting gets extended again. Each time an endpoint is added another extension is added. We are sending null in the meetingExtensionEnabledType, meetingExtensionPeriod and maxMeetingExtensionsAllowed fields. We were expecting that adding an endpoint with these meeting extension parameter settings would not effect the number of meeting extensions. The meeting is originally scheduled with 1 extension of 15 minutes. Can you explain how the meeting extension works with the AMM API and the 3 meeting extension parameters?

Michael Nelson 2013-02-11T21:00:57Z John Yontz http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=11757164 2013-02-09T01:44:56Z 2013-02-09T01:44:56Z

Hi Mike, Up through CTX 1.2, here is what you can expect:  For the TS 8710 and MSE 8510 bridge resources, the values of num screens and required capacity will be the same.  For the CTMS, the required capacity will always be one more than the number of screens because of the 30 FPS presentation data.  In later releases, the required capacity will likely have different unit representations driven by new TS capabilities. - John

John Yontz 2013-02-09T01:44:56Z Michael Nelson http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=11756260 2013-02-08T23:28:58Z 2013-02-08T23:28:58Z

In the participantsInCurrentMeeting element there is the numScreens field and the requiredCapacity field. What is the difference between the two fields?

Michael Nelson 2013-02-08T23:28:58Z John Yontz http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=7878203 2012-10-19T23:59:41Z 2012-10-19T23:59:41Z

This has already been reported as a defect, which is entered as CSCuc51707.  It is marked as high priority to fix for CTX 1.2.  We will keep you informed on this. - John

John Yontz 2012-10-19T23:59:41Z John Yontz http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=7873585 2012-10-19T22:10:32Z 2012-10-19T22:10:32Z

Hi Mike, In the AMM API, the value returned for isDialout in participantsInCurrentMeeting will always be set to true or false, never null.  I do see, however, that if our service layer sets the value to null, the API will falsely report isDialout to be true.  Given that you see "Unknown" in the display, it means that CTX may have a null value that is falsely reported.  Can you provide more details for this scenario?  Meanwhile, I will discuss with others on the team. Thanks - John

John Yontz 2012-10-19T22:10:32Z John Yontz http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=7873431 2012-10-19T21:46:55Z 2012-10-19T21:46:55Z

Hi Gonzalo, Unfortunately, we will not have the event subscription and notification feature generally available in CTX 1.2.  We are starting to put in some hooks for that, and it will likely appear in a future release.  I would encourage you to raise this issue with the CTX product management team so they can set the priority of this feature appropriately. Thanks - John

John Yontz 2012-10-19T21:46:55Z Gonzalo Gasca Meza http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=7853686 2012-10-19T17:42:48Z 2012-10-19T17:42:48Z

Hi CTX team, We are working in an application that will be monitoring a specific Rendevouz Meeting using AMM API. This Rendevouz Meeting will have always 2 active participants (1 single screen endpoint + 1 triple screen endpoint), the application will check if new participants join and based on that collect bridge media statistics. Is there any functionality in AMM API so that we can subscribe to events? In this specific case a Rendevouz meeting and recieve notifications only if there is a change in this Meeting? (Example: Participant join, participant drop, meeting ended, etc). We are trying to avoid sending API requests to monitor this meeting every specific X seconds. Thanks Gonzalo  

Gonzalo Gasca Meza 2012-10-19T17:42:48Z John Yontz http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=7569892 2012-10-12T18:23:17Z 2012-10-12T18:23:17Z

I have confirmation that this will be added to 1.2.  Thanks for raising this issue. - John

John Yontz 2012-10-12T18:23:17Z