Call leg correlation in Skinny

[moto_modx]

Hi,

I want to correlate the calls before and after the Cisco call manager. The limitations are that I do not have access to the call manager i.e. I am tapping the points before and after it. I have tried common parameters but they did not work as these parameters changes after each call leg (eg - callId, ip addresses).

Can you people suggest me call parameters for this ? Even single answer will help me.

Thanks.

[stephan.steiner]

IIRC there is no global call identifier that remains the same during the entire lifetime of a call. E.g. if you transfer a call, the call gets a new callid. so that means that you either have to monitor everything from ingress to egress and your CTI application needs to be aware of all transfer/forward/park/unpark/hold scenarios and you basically follow the call the hard way, or you try to do something after the fact by looking at the CDRs.

[ckatene]

actually, there is a unique call identifier. It is a combination of globalcallid.callmanagerid and globalcallid.callid, both of which are present in cdrs and skinny. from the Cisco JTAPI API documentation " In CallManager terms, every Call object comprises a set of call legs that share a common identifier: the global call handle. Connection objects represent call legs in JTAPI, and the Call object that relates a set of Connections contains the global call handle that the underlying call legs share.

The global call handle within a CiscoCall is accessible via its CallManagerID and CallID properties. Taken together, the CallManagerID and CallID form the global call handle maintained by the CallManager. This pair of properties is guaranteed to be unique among all ACTIVE Call objects, but when an ACTIVE call becomes INACTIVE, its CallManagerID and CallID may be reused to identify a newly-created Call object. Therefore, it is possible for an INACTIVE Call to have identical CallManagerID and CallID properties to those of a currently ACTIVE Call object. "

So the globalcallid combination is guaranteed to be unique for the life of the call, although that same globallcallid combination may be reused in the future.

In my experience, this happens after a CallManager restarted, when the CallID allocation starts again at 1.

c