CUCM did not send the SIP BYE through the SIP Trunk at the end of a recording session

[tpjnair84]

We are having 3 CUCM servers and a Voice logger server( call recording server ). SIP trunk is using for connecting CUCM and Voice logger Server.

What we found was that occasionally CUCM did not send the SIP BYE through the SIP Trunk at the end of a recording session. Rather, CUCM will keep the session alive by sending multiple SIP re-INVITES.

We have found that the Call Manager is not terminating expired call sessions properly. Rather, it is keeping existing call recording session open for an undetermined amount of time.

When call recording sessions are not terminated, voice logger recognizes them as ongoing recordings and reserves recording resources for these calls until all resources are exhausted.

The Call Manager would keep the call recording sessions alive indefinitely until the Call Manager SIP Trunk was restarted. This caused a tie up of call recording sessions.

I would like to know that  why the Call Manager is behaving like this ?

I have attached my SIP trunk  screen shots. kindly please assist me .Thanks

[Manish Prasad]

Hi Dear,

Can you share call manager traces with calling and called party details and timestamp.

Thanks

Manish

[tpjnair84]

Hi All , 

Thank you for your response . 

we are using third party SMART Logger application for call recording ( using JTAPI integration Vr.8.5)

3 months back we had an issue that SIP trunk to the Call Recording server tied up with so many recording sessions and no recording was working. Issue was resolved after restart the SIP trunk.

From recording server logs, what they found that occasionally CUCM did not send the SIP BYE through the SIP Trunk at the end of a recording session. Rather, CUCM will keep the session alive by sending multiple SIP reINVITES.

Also we can see this CUCM behaviour from RTMT logs ( SDI and SDL logs ).

For your reference , i have mentioned call details below:

Call ID : 7d67b500-58d135bb-1faa3a-b0f010a@10.1.15.11

Near End Device: SEP442B0355E6F7-(Ext: 30186)

Far End Device :SEPA4563040A109- (Ext :30842)

Call started time :  2015/06/26 19:25:01 ( As per voice logger logs )

I have checked Sdi traces with TranslatorX. In subscriber traces  (10.1.15.11 ) I can see that call started June 26^th 19:21:31 ( there is time delay between voice logger server and CUCM ) and CUCM were sending SIP INVITE messages to voice logger server (10.1.10.26) until June 26^th 18:56:27.

if you need Call manager logs please download from below dropbox link.

https://www.dropbox.com/s/myy2cljvqnxnb1i/RTMT%20logs%20June%2026th%206PM%20to%20June%2027%207%20PM.zip?oref=e 

I would like to know that :

1) Were CUCM keeping above mentioned call session even after actual call terminated by user ?

2) If CUCM already terminated the actual call session , why didn’t send SIP BYE messages to Voice logger ?

[Nadeem Ahmed]

Please share the traces for non-working scenario .

Br,

Nadeem

[tpjnair84]

Hi Nadeem , 

After restarted the SIP trunk , the recording has been working fine . But still CUCM sending Re-Invite messages to recording server continuously. In future this will route to the same issue.

we can see this CUCM behaviour from attached SDI logs.

Thanks

Jaya

[Nadeem Ahmed]

As re-Invites being used for multiple methods in SIP, as an example it may be used to change the characteristics of the media session, if uses press on hold etc..its could be wage to suggest anything now until we see the message and method of that re-invites being sent from CUCM to your recording server.

Please do attached the traces whenever see this problem re-surface again.

Br,

Nadeem Ahmed

[tpjnair84]

Call ID : 7d67b500-58d135bb-1faa3a-b0f010a@10.1.15.11

Near End Device: SEP442B0355E6F7-(Ext: 30186)

Far End Device :SEPA4563040A109- (Ext :30842)

Call started time :  2015/06/26 19:25:01 ( As per voice logger logs )

All logs in below link :

https://www.dropbox.com/s/myy2cljvqnxnb1i/RTMT%20logs%20June%2026th%206PM%20to%20June%2027%207%20PM.zip?oref=e

[Manish Prasad]

Hi TP,

Sorry for delay  i have been out for a week.

What i found from the traces is that call remain in preservation state by BIB (of phone) and which causes the SIP periodic Re-Invite time to kick in and keep on sending re-invites to call logger.

19:24:05.594 |BuiltInBridgeControl(0061914)DChangeNotifyReq (callPreservation) CI=43424916, refCI=43424896, node=2|2,100,13,3045834.92^10.1.220.198^SEP442B0355E6F7
19:24:05.594 |BuiltInBridgeControl(0061914)DChangeNotifyReq (callPreservation) CI=43424922, refCI=43424896, node=2|2,100,13,3045834.92^10.1.220.198^SEP442B0355E6F7

CI=43424896 is the callleg between 30842 and CUCM.

19:48:11.625 |//SIP/SIPCdpc(2,74,1975368)/ci=43424917/ccbId=4559828/scbId=0/star_SIPPeriodicReINVITETimer: SIPPeriodicReINVITETimer pops up at [callPreservation]|2,100,230,1.10530977^10.1.10.26^*
19:48:11.765 |//SIP/SIPCdpc(2,74,1975370)/ci=43424923/ccbId=4559830/scbId=0/star_SIPPeriodicReINVITETimer: SIPPeriodicReINVITETimer pops up at [callPreservation]|2,100,230,1.10530981^10.1.10.26^*

Thanks

Manish

[Nadeem Ahmed]

How did notice that CUCM is not terminating by sending BYE message to voice logger side? Do you have any trace for non-working scenario? can  you please post the same.

also as you mention it happened occasionally is there any difference in the call or any difference between working and non-working.?

Br,

Nadeem Ahmed

[Andrew West]

What is the call recording server? 

Even though you are integrated by SIP are you starting your call recording with TAPI and had to configure a TSP?

[david.alfaro]

I have exactly the same problem; after that CUCM rejects the call, the sip trunk is unable to send the BYE to the NICE recorder, and the NICE logger just re-sen INVITE, the session can remain until weeks without the CUCM send the BYE to the logger. Mean while, logger send re-INVITE each 15 minutes. I attach excel file about this behaviour.

CUCM v8,6

[arian.mares]

I have the same problem. The only solution I've found was to stop the call after a certain time (a maximum call duration) and not replying OK to re-INVITES.

Arian

[marcio]

Two years passed and no solution at all from Cisco ?

It's clearly that's a CUCM problem, as many different recorders have this same issue.

We have this exactly same problem from CUCM 8.5 to 11 (at least). We detected ~10% of calls without the SIP BYE, so it's really a BIG problem.

nadeeahm did you found anything in the logs tpjnair84 has uploaded ? Because as we have about 10% problematic calls, we can easily send tons of daily log files, SIP dumps or CUCM traces to help solving this major problem.