Showing results for 
Search instead for 
Did you mean: 

mediasense sessionID semnification


I have only seen MediaSense in the lab environement from cisco dcloud and I saw that , in Search and Play page , I get the field with sessionID . My question is where does that ID come from ? how is it formed ? does it mean anything or it's just random ? I have read something aboud it beeing from CUCM CDR , but I do not know which field from CDRs generates this ID in MediaSense.

Thank you

1 Reply 1

Cisco Employee
Cisco Employee

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.