You can develop a web service to subscribe specifically for Tag events from MediaSense.  Your service will then receive an event whenever any session gets tagged by anybody, including by CCX.  Most likely there's no other tagging going on in your environment, but it would be prudent to write some kind of code in your web service to make sure the event you receive is a CCX tag event. Then given the information in the tag event, your web service can turn around and issue an addSessionTag event to MediaSense.  No getSessions query required (until later of course, when you want to search for your tags). ... View more

I would recommend the "MediaSense Client Tool and Sample Application".  It's up to date as of MediaSense 10.5. ... View more

The SessionId is a MediaSense internally generated identifier for each recording session, and is the primary key by which recordings are identified. It is guaranteed to be permanently unique within the scope of a MediaSense cluster.  It is not from the UCM CDR, nor is it stored there, but there are other UCM CDR fields that are stored in MediaSense's database. If your MediaSense API client application wants to play or download a MediaSense recording, it needs to know the SessionId.  There are various ways to find it, and this is one of the major responsibilities of an API client.  It could for example issue a MediaSense getSessions API request (or one of the simplified wrapper APIs), to retrieve recording session information based on data that it does know – such as the UCM CallId that it retrieves from the UCM CDR. It could also subscribe for MediaSense session events, and receive a notification whenever a recording starts or ends. Such notifications contain the SessionId as well as other metadata that the client itself can use to match the recording with events it is receiving from other sources such as JTAPI, or one of the contact center event streams.  The client could even turn around and tag the MediaSense session with an identifier of its own, so that it can easily find that recording in MediaSense at a later time. Note that a single SessionId usually corresponds to the recording of a single call, but not always.  Various call flows such as transfers and conferences, and some mid-call codec changes, can result in multiple successive recording sessions, with different SessionIds, for the same call.  There's a lot more detail about this in the product documentation, but I encourage you to check out the getAssociatedSessions API, which can do most of the multi-session call association work for you. ... View more

Bilal, If you are using MediaSense version 10.0 or later, then you can call the launchMediaPlayer API, which takes the RTSP URL as a parameter.  launchMediaPlayer returns a body of content-type JNLP, which specifies a web start application.  You save that body as a file on disk with extension .jnlp, and then call Desktop.getDesktop().open(jnlpFile).  Assuming your desktop machine is properly configured to run Java web start applications (which it most likely is already), the MediaSense built-in player will be automatically downloaded from MediaSense and started, and it will then open and begin playing the RTSP streams.  However, as the player is a Java application, you will likely have to click through a couple of security warnings until you get to the point of installing trusted signed certificates into the MediaSense nodes.  But don't worry about that for now. Be sure to check the SRND to make sure your particular combination of desktop operating system and codec (G.722) is supported by the media player.  But generally, MediaSense's media player covers many more cases with fewer caveats than any of the off-the-shelf media players such as VLC, all of which are really designed to play music, not telephone conversations. ... View more

It looks like you are trying to play a G.722 audio stream in VLC.  live555 warning: RTP subsession 'audio/G722' failed (RTP payload format unknown or not supported) VLC doesn't support G.722.  Try forcing your call to G.711, then it will record as G.711 and VLC should  be able to play it back.  As I think you already discovered, VLC also can only play one track at a time, so you have to add "-TRACK0" or "-TRACK1" to the end of the RTSP URL when you try to play it in VLC. I have never used Java Media Framework, so can't help you there. ... View more

I did some investigation and found that my above comment about automatic unsubscription after 30 minutes is incorrect.  There is no automatic unsubscription except in failure cases.  I've edited my earlier notes on this thread accordingly. ... View more

MediaSense offers a verifyEventSubscription API which you should call periodically.  Actually you could just as well re-issue the subscribeToEvents instead, since that's what you'd have to do anyway if the subscription turns out to have been terminated – and there's no harm in subscribing again when it hasn't been terminated. You should do this more often than every 30 minutes.  If a MediaSense node crashes and reboots, you could miss events until you re-subscribe, because you don't know that there has been a restart, and because subscriptions are not persistent across restarts. [EDIT] My above comment about automatic unsubscription after 30 minutes is incorrect.  There is no automatic unsubscription except in failure cases. ... View more

For #1, have you checked the BOTTOM of the JSON body?  The JSON spec does not require that individual named properties be presented in any particular order.  The properties may not come in the same order as you see in the documented examples. For #2, your client program should unsubscribe from events before it exits.  If your client program exits and then restarts, the subscription could still be in place, and you may start receiving events even before you re-subscribe. That said, MediaSense will automatically unsubscribe you if 30 minutes pass between events that match your subscription's filter criteria, or if MediaSense is unable to deliver events to your client several times in a row. [EDIT] My above comment about automatic unsubscription after 30 minutes is incorrect.  There is no automatic unsubscription except in failure cases. ... View more

Yes, rtspUrl is similarly protected. It also requires HTTP-BASIC style authentication.  VLC doesn't have a way that I know of for you to preconfigure a set of user credentials.  However, it does have the ability to pop up a "Please enter username and password" dialog box when it receives the 401-Unauthorized error .  If you manually enter the credentials, VLC will resend its request to MediaSense and include the authentication header this time.  Are you not seeing the popup dialog?  Are you using the standalone version of VLC, or do you have it embedded into an application or web page? Have you tried using the MediaSense built-in media player?  Take a look at the documentation for launchMediaPlayer, which is new in MediaSense 10.0.  It works better than VLC.  As described in the SRND, all off-the-shelf media players have various limitations.  VLC for example is only able to play one of the two audio streams at a time. Come to think of it, that could be your problem.  Try this URL instead of the one in your example above: rtsp://192.168.200.204/30145b69671b11-TRACK0 - Jeff W. ... View more

The convertSession API is deprecated but not deleted, so you can still use it, at least for the next couple of releases.  However, we recommend you start using the single-step download instead.  This the mp4Url URL that you receive in the JSON data for the session.  The advantage of using the mp4Url of convertSession is that it only takes one HTTP request to fetch the converted recording.  That means you can actually enter it directly into a browser, or into a media player such as VLC.  With convertSession, you had to issue the convertSession request using Poster or using your own MediaSense API client program, then receive the URL for the converted MP4 file, and only then can you supply it to your web browser or your media player. URLs that fetch actual recordings have to be password protected, for obvious security reasons.  These URLs therefore require that you make your HTTP request using standard HTTP-BASIC authentication headers, as described in RFC-2617 (http://www.ietf.org/rfc/rfc2617.txt).  This RFC defines an HTTP header where you insert the username and password, encoded as base 64.  If you are using any standard 3rd party HTTP client library for your coding, it probably already has the ability to pass credentials in this way; it's very common.  Since you are receiving a 401-Unauthorized error,  it means you haven't sent credentials. ... View more

Bilal, Please take another look at the SignIn API example in the developer's guide, and copy that.  Username and password should not be set as parameters in httpClient.  They should be sent in the JSON body of that HTTP POST request.  Thereafter, you don't have to concern yourself at all with JSESSIONID.  HttpClient (as well as Poster) will receive the set-cookie from MediaSense, keep track of it, and send it back to MediaSense as a cookie automatically for you.  - Jeff W. ... View more