the call was disconnected after transfer. ABNORMALLY ENDING - SIP code [488]

michal_madejowski · ‎12-15-2017

Hi
I have a problem that when an agent transferred inbound call to another, the call was disconnected. It will better show from TCD table belew:

RecoveryKey MRDomainID AgentSkillTargetID SkillGroupSkillTargetID ServiceSkillTargetID PeripheralID RouteID RouterCallKeyDay RouterCallKey DateTime PeripheralCallType DigitsDialed PeripheralCallKey CallDisposition NetworkTime Duration RingTime DelayTime TimeToAband HoldTime TalkTime WorkTime LocalQTime BillRate CallSegmentTime ConferenceTime Variable1 Variable2 Variable3 Variable4 Variable5 UserToUser NewTransaction RecoveryDay TimeZone NetworkTargetID TrunkGroupID DNIS InstrumentPortNumber AgentPeripheralNumber ICRCallKey ICRCallKeyParent ICRCallKeyChild Variable6 Variable7 Variable8 Variable9 Variable10 ANI AnsweredWithinServiceLevel Priority Trunk WrapupData SourceAgentPeripheralNumber SourceAgentSkillTargetID CallDispositionFlag RouterCallKeySequenceNumber CED CallTypeID BadCallTag ApplicationTaskDisposition ApplicationData NetQTime DbDateTime ECCPayloadID CallTypeReportingDateTime RoutedSkillGroupSkillTargetID RoutedServiceSkillTargetID RoutedAgentSkillTargetID Originated CallReferenceID CallGUID LocationParamPKID LocationParamName PstnTrunkGroupID PstnTrunkGroupChannelNumber NetworkSkillGroupQTime EnterpriseQueueTime StartDateTimeUTC ProtocolID PrecisionQueueID PrecisionQueueStepOrder Attributes
8320291102294 1 5834 6736 NULL 5000 5371 152288 18588 2017-12-14 12:36:43.330 2 65500 NULL 1 0 0 0 0 0 0 0 0 0 NULL NULL 0 NEW-IVR/ctb/PL_IVR_CTB_SME_12.wav 1858815228850022054.44 NULL NULL NOT_HOLIDAY NULL N 83962704 -60 NULL NULL NULL NULL NULL 5169093 NULL NULL PL NULL WORK CC_IVR_PRIVATE_AGENT MIKRO op 2 8848XXXXX N 0 NULL NULL NULL NULL 7 6 65500 5358 N 0 NULL 0 NULL NULL 2017-12-14 12:30:00.000 6736 -1 5834 NULL 070BE5800001000000046A5110B7DD0A NULL NULL NULL NULL 0 0 2017-12-14 11:36:43.330 12665 NULL 0 NULL.

As You can see the PeripheralCallKey is NULL and talk time = 0 as well

The DN number 65500 is fine.
In rtr logs I have:

DEVICE_TARGET_ABORT_IND message received from Peripheral CRSCallID(Date 152288 ,ID 18588), NetworkTarget(0),MRDomain(1), AgentSkillTargetID(-1)

in CVP Logs I have:
10526999: 10.221.183.20: gru 14 2017 12:36:36.194 +0100: %CVP_9_0_SIP-3-SIP_CALL_ERROR: CALLGUID = 070BE5800001000000046A5110B7DD0A LEGID = 70be580-a3216240-b6b80-10b7dd0a - [INBOUND] - ABNORMALLY ENDING - SIP code [488], Reason Hdr [SIP;cause=488] Not Acceptable Here, GW call using SURV TCL flag [false], NON NORMAL flag [true], DNIS [888888888911504], ANI [8848XXXXX] with AGE (msecs) 4078 and Call History : 888888888811505|-1;85463|1; [id:5004]
(all logs in attachement)

I have configured route pointon CUCM
Furthermore I have Match Result = RouteThisPattern in DNA analysis so the call comes to script and skill group.

It can be the an agent phone issue?

Please help, Thank You

geoff · ‎12-15-2017

This is a codec issue.

From rtr.txt, it looks like Agent 1 does a transfer through the route point 65500, we see the two stage transfer (first to CVP on label 8888888889 and then to the gwy on label 8888888888) and then it locates the second agent, sends the pre-route indicator but cannot stand up the RTP stream.

Regards,

Geoff

Chintan Gajjar · ‎12-15-2017

Most of the time 488 means that there is media negotiation failing between the parties.

i also saw 491 request pending in your logs, which could also be because of some bug(don't exactly remember the number) in CVP where the SIP requests are not answered by one of the parties.

Can you enable SIP debugs on the CVP and attach the full logs here for us to review?

also if you could explain how exactly the transfers are happening? i have seen cases when the blind transfer was invoked by an agent to a CVP number and it had failed because the SIP trunk to CVP on CUCM was not configured to use DTMF RFC2833.

michal_madejowski · ‎12-18-2017

I have SIP logs on CVP enabled on DEBUG Level.

Itwas tranfer by consult as you can see in Peripheral Call type = 12.
Route point goes to VGW via sip trunk, I am not sure which one, we have several. If this is codec issue what I must check and where?
I attach some logs from Gateway also

Chintan Gajjar · ‎12-18-2017

In gateway logs i see no occurrence or did not find SIP 488, you have to collect the logs covering the issue.

and if you have CVP logs enabled with SIP debugs and covers the call GUID which had an issue, please post them here. the one you posted above i guess were more looked filtrated, we need raw one.

michal_madejowski · ‎12-18-2017

I do not have more logs from VGW :(
I attached full logs from CVP.

geoff · ‎12-18-2017

What we wanted to see was the SIP conversation for the 488 failed call. You need to enable DEBUG on the Dynasoft library. This will make a huge trace file even larger (10MB in 12 minutes) and you may struggle to catch the error in 1 file. You should do this test when the contact center is under the lowest call volume.

What we can see for GUID 070BE5800001000000046A5110B7DD0A that the 488 error is preceded by a 404 error at 12:36:34.194

Refer failed with 404 - Not Found. May be a problem with Routing Configuration or Gateway Dial-Peer. [id:5004]

Regards,

Geoff

michal_madejowski · ‎12-19-2017

Thank you for your analysis but I found something in gateway logs (gateway2.txt):

Dec 14 12:36:39 10.221.183.5 2989473499: Received:
Dec 14 12:36:39 10.221.183.5 2989473500: ACK sip:91919191@10.221.183.5:5060;transport=tcp SIP/2.0#015
Dec 14 12:36:39 10.221.183.5 2989473501: Via: SIP/2.0/TCP 10.221.183.20:5060;branch=z9hG4bKJdpzEfyGXek6YdRGGGHWyQ~~2106174#015
Dec 14 12:36:39 10.221.183.5 2989473502: Max-Forwards: 70#015
Dec 14 12:36:39 10.221.183.5 2989473503: To: <sip:91919191@bnp.gw.local;transport=tcp>;tag=DD7D6060-19D2#015
Dec 14 12:36:39 10.221.183.5 2989473504: From: 8848XXXXX <sip:8848XXXXX@10.221.183.20:5060>;tag=dsc2bf20e3#015
Dec 14 12:36:39 10.221.183.5 2989473505: Call-ID: 070BE5800001000000046A5110B7DD0A-151325139219498713@10.221.183.20#015
Dec 14 12:36:39 10.221.183.5 2989473506: CSeq: 1 ACK#015
Dec 14 12:36:39 10.221.183.5 2989473507: Content-Length: 0#015
Dec 14 12:36:39 10.221.183.5 2989473508: Contact: <sip:8848XXXXX@10.221.183.20:5060;transport=tcp>#015
Dec 14 12:36:39 10.221.183.5 2989473509: #015
Dec 14 12:36:39 10.221.183.5 2989473510: 713373643: Dec 14 12:36:34.210: //23869857/DDFA6BED87DA/CCAPI/cc_api_call_disconnected:
Dec 14 12:36:39 10.221.183.5 2989473511:
Dec 14 12:36:39 10.221.183.5 2989473512: Cause Value=96, Interface=0x26C053D8, Call Id=23869857

that is mean Gateway does not sent ringback tone because of lack of something in ACK message from CVP side. Do I should proceed this problem to cisco tac ?

Chintan Gajjar · ‎12-19-2017

while i still don't see the complete stack of SIP messages in any of the log file you attached, but i did see ReInvite getting rejected with "REJECTED WITH 491 - Request Pending" as first error of the call failure.

Which as i said earlier on thread and what you found matches with the statement that there is some bug with CVP which causes CVP/gateway to fail to answer important messages in SIP call (like ACK).

have a look at below bug and see if it helps:

https://quickview.cloudapps.cisco.com/quickview/bug/CSCuq35574

and i would say do contact Cisco TAC as they will have more pointers on this.