Gateway-based Recording and JTAPI Integration - Matching Calls?

[varunr]

We are currently using gateway-based call recording - this bypasses built-in bridge and makes the gateway forward SIP calls directly to our recorder.

We are also using JTAPI to receive events as the call transitions between different states. Is it possible to match up the JTAPI events to the SIP sessions from the gateway? For example, is it possible to get the Cisco GUID or SIP Call ID from JTAPI?

[dstaudt]

JTAPI provides the CiscoCall.getCallId().getGlobalCallID() method to get the "Global Call Id".

The SIP call legs sent towards the recorder should include far-end or near-end "xrefci" call IDs:

I am not 100% sure if those numbers map to each other, but AFAIK that's the intended situation; if not, you will have the device name and DNs that should provide a reasonably reliable match.

Also not 100% sure if that behaviour/mapping changes for BiB vs gateway recording...

[varunr]

Currently, the SIP invites I'm receiving don't have x-refci fields. I'm wondering if this is a limitation of gateway recording, or if maybe I can configure something in CUCM to send this? I was hoping that there would be something in JTAPI that can match with the "Cisco-Guid" field.

INVITE sip:XXXX@XXX.XXX.XXX.XXX:5060 SIP/2.0
Via: SIP/2.0/TCP XXX.XXX.XXX.XXX:5060;branch=xxxxxxxxxxxxxx
From: <sip:XXX.XXX.XXX.XXX>;tag=xxxxxxxx-xxx
To: <sip:XXXX@XXX.XXX.XXX.XXX>
Date: Mon, 31 Jul 2023 19:09:18 GMT
Call-ID: XXXXXXXX-XXXXXXXX-XXXXXXXX-XXXXXXXX@XXX.XXX.XXX.XXX
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Require: siprec
Min-SE: 1800
Cisco-Guid: XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX
User-Agent: Cisco-SIPGateway/IOS-16.12.4
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1690830558
Contact: <sip:XXX.XXX.XXX.XXX:5060;transport=tcp>;+sip.src
Expires: 60
Allow-Events: telephone-event
P-Asserted-Identity: <sip:XXX.XXX.XXX.XXX>
Session-ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx;remote=00000000000000000000000000000000
Session-Expires: 1800

[dstaudt]

Hmm...I assume if you do it via BiB in this same scenario that you do get the x-refci?

I suspect you are right about the change in behaviour when the recording leg originates from the gateway instead of the phone - unfortunately not aware of any configs, and I strongly suspect its more or less working as designed.  You may need to ball back to device/DN/time-window matching.

[dstaudt · Accepted solution]

Just (re)-discovered this method, which seems to return a unique UUID for a call leg (GCI's tend to be unique only within a cluster) - would be curious to see if this ID matches what you're seeing: End to End Session ID for Calls

[KevinLQ]

Hello Dstaudt,

As Varunr mentioned, I was also able to confirm that the local/peer UUIDs returned in JTAPI matches the "Session-ID" field in the SIP header. Because Session-ID can change, for example, during call transfers or call media changes (audio to video), we're noticing that this may cause additional matching issues down the road.

Is there a field in JTAPI that returns the SIP header field "Call-ID", which is static across the whole call?

[dstaudt]

Pretty sure there is not an extension for exposing the SIP Call-ID.  JTAPI should provide sufficient events modeling any such changes/transitions, along with media start/stop events that should help with keeping up with moving calls.

[varunr]

Thanks for the pointer. CiscoConnection.getLocalUUID and CiscoConnection.getPeerUUID do appear to match the UUIDs that we get in the SIPREC metadata.

There appear to be some quirks regarding outgoing calls (getLocalUUID and getPeerUUID start out as null in this case), but I think this can be solved by waiting for an external phone number to connect before fetching the IDs. There also might be issues with transfers (local ID might change?) but this could also be solved by just looking at getPeerUUID/remote only.