Process INVITES when recording is enabled on both parties phones in Cisco CUCM

Question

I am using jain-sip to implement a sip server to process call events and then record the calls in Cisco CUCM. It works fine when a call is made from a recording-enabled phone to a recording-disabled phone or vice versa. I receive two INVITES one for each far-end and near-end phone.

But when a call is made between two phones where recording is enabled on both phones (think internal call), I receive four invites and there is no way of differentiating between far-end and near-end and no way of knowing which invites to process and which to ignore. Both phones send two invites, one for itself and one for the other phone. When call is ended, four BYEs are sent.

What is the proper way of handling this situation?

below are the four invites;

INVITE sip:88888@192.168.1.x.x:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168..x.x:5060;branch=z9hG4bK2095e06f3b8;rport=58747
From: <sip:2400@192.168..x.x;x-nearend;x-refci=27425142;x-nearendclusterid=BR-Cluster2;x-nearenddevice=SEPD0C282D15AAF;x-nearendaddr=2400;x-farendrefci=27425141;x-farendclusterid=BR-Cluster2;x-farenddevice=sikander1;x-farendaddr=2701>;tag=519~00d3be95-408b-41c6-90cf-01ef66258892-27425149
To: <sip:88888@192.168.1.124>
Date: Mon, 09 Nov 2020 07:13:13 GMT
Call-ID: 6649000-fa81ec09-1f6-3001a8c0@192.168..x.x
Supported: timer,resource-priority,replaces,X-cisco-srtp-fallback,Geolocation
Min-SE: 120
User-Agent: Cisco-CUCM11.5
Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence,kpml
Call-Info: <sip:192.168..x.x:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Session-ID: 00000000000000000000000000000000;remote=00000000000000000000000000000000
Cisco-Guid: 0107253760-0000065536-0000000011-0805415104
Session-Expires: 120
P-Asserted-Identity: <sip:2400@192.168..x.x>
Remote-Party-ID: <sip:2400@192.168..x.x>;party=calling;screen=yes;privacy=off
Contact: <sip:2400@192.168..x.x:5060;transport=tcp>;isFocus
Max-Forwards: 70
Content-Length: 0

-----------------------------------------

INVITE sip:88888@192.168.x.x:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.x.x:5060;branch=z9hG4bK20a2071bec;rport=58747
From: <sip:2701@192.168.x.x;x-nearend;x-refci=27425141;x-nearendclusterid=BR-Cluster2;x-nearenddevice=sikander1;x-nearendaddr=2701;x-farendrefci=27425142;x-farendclusterid=BR-Cluster2;x-farenddevice=SEPD0C282D15AAF;x-farendaddr=2400>;tag=520~00d3be95-408b-41c6-90cf-01ef66258892-27425150
To: <sip:88888@192.168..x.x>
Date: Mon, 09 Nov 2020 07:13:13 GMT
Call-ID: 6649000-fa81ec09-1f7-3001a8c0@192.168..x.x
Supported: timer,resource-priority,replaces,X-cisco-srtp-fallback,Geolocation
Min-SE: 120
User-Agent: Cisco-CUCM11.5
Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence,kpml
Call-Info: <sip:192.168..x.x:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Session-ID: 00000000000000000000000000000000;remote=00000000000000000000000000000000
Cisco-Guid: 0107253760-0000065536-0000000012-0805415104
Session-Expires: 120
P-Asserted-Identity: <sip:2701@192.168..x.x>
Remote-Party-ID: <sip:2701@192.168.1.x.x>;party=calling;screen=yes;privacy=off
Contact: <sip:2701@192.168.x.x:5060;transport=tcp>;isFocus
Max-Forwards: 70
Content-Length: 0

-------------------------

INVITE sip:88888@192.168..x.x:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168..x.x:5060;branch=z9hG4bK20b5eb383e9;rport=58747
From: <sip:2400@192.168..x.x;x-farend;x-refci=27425142;x-nearendclusterid=BR-Cluster2;x-nearenddevice=SEPD0C282D15AAF;x-nearendaddr=2400;x-farendrefci=27425141;x-farendclusterid=BR-Cluster2;x-farenddevice=sikander1;x-farendaddr=2701>;tag=521~00d3be95-408b-41c6-90cf-01ef66258892-27425155
To: <sip:88888@192.168..x.x>
Date: Mon, 09 Nov 2020 07:13:13 GMT
Call-ID: 6649000-fa81ec09-1f8-3001a8c0@192.168..x.x
Supported: timer,resource-priority,replaces,X-cisco-srtp-fallback,Geolocation
Min-SE: 120
User-Agent: Cisco-CUCM11.5
Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence,kpml
Call-Info: <sip:192.168..x.x:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Session-ID: 00000000000000000000000000000000;remote=00000000000000000000000000000000
Cisco-Guid: 0107253760-0000065536-0000000013-0805415104
Session-Expires: 120
P-Asserted-Identity: <sip:2400@192.168.x.x>
Remote-Party-ID: <sip:2400@192.168..x.x>;party=calling;screen=yes;privacy=off
Contact: <sip:2400@192.168..x.x:5060;transport=tcp>;isFocus
Max-Forwards: 70
Content-Length: 0



-------------------------

INVITE sip:88888@192.168.1.124:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168..x.x:5060;branch=z9hG4bK20c2f880eb2;rport=58747
From: <sip:2701@192.168..x.x;x-farend;x-refci=27425141;x-nearendclusterid=BR-Cluster2;x-nearenddevice=sikander1;x-nearendaddr=2701;x-farendrefci=27425142;x-farendclusterid=BR-Cluster2;x-farenddevice=SEPD0C282D15AAF;x-farendaddr=2400>;tag=522~00d3be95-408b-41c6-90cf-01ef66258892-27425156
To: <sip:88888@192.168.1.124>
Date: Mon, 09 Nov 2020 07:13:13 GMT
Call-ID: 6649000-fa81ec09-1f9-3001a8c0@192.168..x.x
Supported: timer,resource-priority,replaces,X-cisco-srtp-fallback,Geolocation
Min-SE: 120
User-Agent: Cisco-CUCM11.5
Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence,kpml
Call-Info: <sip:192.168..x.x:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Session-ID: 00000000000000000000000000000000;remote=00000000000000000000000000000000
Cisco-Guid: 0107253760-0000065536-0000000014-0805415104
Session-Expires: 120
P-Asserted-Identity: <sip:2701@192.168..x.x>
Remote-Party-ID: <sip:2701@192.168..x.x>;party=calling;screen=yes;privacy=off
Contact: <sip:2701@192.168..x.x:5060;transport=tcp>;isFocus
Max-Forwards: 70
Content-Length: 0

score 1 · Answer 1 · answered Nov 18 '20 at 01:50

I guess in general the idea would be to potentially record all 4 call legs - i.e. both sides of the 'same' call. An example might be software that analyzes the voice quality experienced by each party when both are recorded, in case one experiences RTP flow issues or other anomalies. Codec differences or transcoding may cause one 'version' of the same 2-party call to sound better/worse (or have larger storage requirements). If you don't care about the RTP data at that level, you may need to check the x-refci and other From: fields, so you can 'de-dupe' them during or after the fact...

Good suggestion. I tried to ignore the duplicate INVITES but that doesn't look like a good idea. I am now recording all four legs and selecting two of them one from each side to pass them to the audio player based on x-refci. I might, future, add an audio quality analyzer to select the best quality audios as final recording. — Sikander, Nov 19 '20 at 03:29

Process INVITES when recording is enabled on both parties phones in Cisco CUCM

1 Answers1