Stream URL SUDDENLY not working (Sept.26) - URGENT

[lushanthan]

Hi All,

The stream url (and also file url) which I got by calling LstRecording have stopped working from today suddenly. Is this issue on the webex side or do we need to do some development changes? It is really urgent. When I access the stream or file url returned from the api it says "Invalid Input or system error. Please try again or contact your site administrator." Please reply it's urgent!!! (image attached)

[kasutton]

Hello,

This behavior has been identified as a defect and we are expecting a fix sometime in the October timeframe. In the meantime, there are two possible workarounds. One is to specify a meeting type in your request. This will ignore any meeting number you provide and return all recordings for that meeting type, so you would need to parse out the results you want. The other option is to pull the links directly from the page, though this would be a manual process, so is unlikely to be a viable workaround. Apologies for the inconvenience.

Kasey

[lushanthan]

Hi Kasey,

Thank you for the response.

Regarding your first work around, are you talking of the serviceType tag inside serviceTypes collection in the LstRecording request? ( as per the api reference guide it can takes values such as MeetingCenter, EventCenter etc.) However currently in my request im not providing any meeting number. I'm just getting all the recordings within a time period (using createTimeStart, createTimeEnd tags inside the createTimeScope container). Yet the streamUrl and the fileUrl are returning different values compared to that seen in the WebEx site portal (in the recording details page). Please assist.

[emerrill999]

Wow this is bad and messy.

Yes, it is the serviceType tag. But you run into a number of problems.

First off, if you use the serviceType tag, it doesn't respect returnSessionDetails, so the response doesn't include a sessionKey, so you can't associate it with a meeting.

And if you compare the results between a request with serviceType and without, you get different URLs, different recordingIDs and different createTime, but the same name, size, duration, and confID. My guess is that data from recordings that aren't yours are being populated into the responses and giving you a jumble of data.

I think the only way to get the proper data (and associate it to a meeting) best I can tell is to:

1. Get the lstRecording with serviceType specified
2. Parse each recording
3. Get the lstRecording without serviceType specified
4. For each recording, look in that recording list (without serviceType) for the matching confID and get the sessionKey

To make matters even worse, URLs you have received in the past are also broken, and the recordingIDs no longer match, which makes me really think that without serviceType is actually the correct data, and with serviceType is "bad" data, but it's broken in the same way as the rest of WebEx, so those are the URLs that work. When they fix this, I assume they will go back to the old URLs and recordingIDs again.

[emerrill999]

Ok, the more I look at this, the more it appears that with serviceType is returning the "wrong" data, including wrong recording times, recordingIDs, etc, but the *.webex.com website has been populated with this incorrect data, so that is the data that it is enforcing. I would say be wary of any changes you make, because it's likely you may have to undo stuff when they have this worked out, and the URLs/ids you get with the workaround may be "wrong" again later.

[nmorrow]

Hello,

     LstRecording with serviceType specified does return different data, but not because it is invalid or incorrect. NBR files are stored on the WebEx server as a set of audio, video, and text data. Collectively, these are a raw recording. The recordings on your WebEx site are service recordings that also include some additional metadata, such as user access password or playback truncation. The raw recording and the service recording do have separate playback links and record ID to keep them separate (I cant comment on the creation date/time as that isn't something I have ever noticed as being different).

     From an end user experience point of view, it is preferable to use the serviceType value so that any updates by the host, especially to playback start and end time, will be honored when viewing the recording.

[emerrill999]

Ok, that more or less makes sense. So the base ID and URL (that we get when not using serviceType) are for the "raw" recording, where as if we include serviceType we get the the service recording, which is in some way an "overlay" of the raw recording, with unique URLs and metadata.

Is there any way to get lstRecording with serviceType to return the sessionKey of the meetings (honor returnSessionDetails)? Right now I have to do a silly cross reference with confID and recording size.

And a few "fix" related questions:

• Are the old URLs going to start working again at some point?
• Will other iterations of lstRecording return the service recordings at some point?
• Will lstRecording be fixed to honor returnSessionDetails?

Thanks!

[emerrill999]

To add another wrinkle - if a user edits a recording in the web interface, the recording loses it's confID (it's set to 0), which makes it pretty impossible to associate it to the original session.

[nmorrow]

Hello,

     The stream URL for lstRecording without serviceType is a known issue and will be addressed in the future. The conf ID resetting to 0 and the create time resetting are new to me and I will need to test on my end and report as a bug if I see the same behavior. Same deal with session details, although it would be more of a feature request for that one.

[lushanthan]

Hi all,

Thank you so much for showing interest in this forum. Our case is very critical. More than 1000 users are effected by this. So, we need to provide a quick solution.

Nathan, as Eric pointed out since the recordings have different links and recording ids, is there a field value returned which is common (and it is returned in both the api calls) in both the api calls? Because we have already stored the recordings' meta data of past one and a half years in our database. We only need to update the stream and download file url fields for those recordings.

The known issue on streamURL and fileURL occured very recently or it was there for a long time? We are facing this issue only from last Saturday (26th Sept 2015). Those links were valid for the past one and a half years.