CME on 152-4.M6a - DSP Crash (SCCP to SIP)

Gert Plessers · ‎11-08-2014

Hello,

Customer of ours is running IOS 15.2-4.M6a (c2900-universalk9-mz.SPA.152-4.M6a.bin) on 2901. Problem is that incoming calls that the receptionist need to transfer to other phones drop regularly (multiple times per day, sometimes per hour). DSP crash-info below. Call scenario: incoming call to 7965 (SCCP) - transfer to 9971 (SIP). Don't ask me why all of their users have 9971 phones (really bad w/ CME), but that's the situation we are in today (initial sale was done by another partner). The receptionist has a 7965 phone for alpha-tagging as she receives all incoming calls.

We replaced the PVDM3 with a new module, then the chassis was replaced - no luck, problems remains. Is this a known bug or issue ?

DSP-crash logging:

Oct 17 08:56:00.305: %DSPRM-2-DSPALARM: Received alarm indication from dsp (0/1). Resetting the DSP.

Oct 17 08:56:00.305: %DSPRM-3-DSPALARMINFO: 001E 0000 0080 0000 0005 0050 686F 7374 6472 7672 5F6E 6677 2832 3936 2900 0000 0000 0000 0000

Oct 17 08:56:00.305: %DSPRM-3-DSPALARMINFO: hostdrvr_nfw(296)

Oct 17 08:56:00.305:

DSP trace buffer dump for DSP 0/1

DSP version: 32.1.5

Trace buffer size: 1392 bytes

===== Begining of DSP tracebuffer dump=====

DSPTB0:00078340 10178057 10178056 000765AB 00076596 000C65C7 000C65C2

DSPTB1:00076591 00076590 1017804F 10178040 000553A5 000553A2 00055369

DSPTB2:00055310 0005D75B 0005D74E 000765E7 000765E6 000C65DB 000C65C8

DSPTB3:000765DF 000765C0 0005D747 0005D746 0005D71B 0005D700 0005D6DB

DSPTB4:0005D6B8 000765AB 00076596 000C65C7 000C65C2 00076591 00076590

DSPTB5:0005D6AD 0005D6A0 00055301 00055300 000552ED 000552E0 000552B3

DSPTB6:00055280 000551F9 000551D2 00055199 00055180 0005500D 00054FE0

DSPTB7:00054FB9 00054FAC 00057F79 00057F50 00054FA7 00054F88 00057FAB

DSPTB8:00057F80 00054F83 00054F7A 00057F79 00057F50 00054F75 00054F74

DSPTB9:00054F63 00054F30 00054ED9 00054E70 00053BAB 00053BAA 000610DB

DSPTB10:000610D0 000608D3 000608C0 00060865 00060862 00060815 00060810

DSPTB11:000607AD 000607A0 00060793 00060730 00060707 000606D0 000610CD

DSPTB12:000610CC 00060985 00060972 00060911 000608E0 000610E1 000610E0

DSPTB13:00053BA1 00053B90 00053B51 00053B10 0001FCFF 0001FCE2 0001FB81

DSPTB14:0001FAE0 00053B09 00053ABE 00078101 000780E0 00077FFB 00077FF0

DSPTB15:000780D5 000780BA 0007801B 00077FA6 00077F81 00077F80 00077F61

DSPTB16:00077F40 00077F2B 00077F10 00053AB3 00053A80 00053A59 00053A30

DSPTB17:00053293 00053292 000531CF 000531B0 000610DB 000610D0 000608D3

DSPTB18:000608C0 00060865 00060862 00060815 00060810 000607AD 000607A0

DSPTB19:00060793 00060730 00060707 000606D0 000610CD 000610CC 00060985

DSPTB20:00060972 00060911 000608E0 00061161 00061160 000531A1 00053180

DSPTB21:00053137 00053020 000773A1 00077372 0001FADB 0001FAD8 0001FACD

DSPTB22:0001FAB8 0001FACF 0001FAB8 0001FACF 0001FAB8 0001FACF 0001FAB8

DSPTB23:0001FACF 0001FAB8 0001FACF 0001FAB0 00077367 000772F0 000BC939

DSPTB24:000BC86A 000BC839 000BC770 000BC753 000BC752 000BC751 000BC730

DSPTB25:000BC61D 000BC550 000BC517 000BC50C 000BC4E5 000BC4C0 000BC49F

DSPTB26:000BC480 000BC44F 000BC440 000C642F 000C641C 000C09E1 000C09DE

DSPTB27:000C098F 000C0984 000C0971 000C0950 000C6419 000C63FC 00030457

DSPTB28:00030420 000C63ED 000C633E 00030467 00030458 000C6339 000C6280

DSPTB29:400004E7 400004E0 0005F9DD 0005F9D4 0005F905 0005F8F8 10158455

DSPTB30:10158446 1015840F 101583F4 10158343 10158332 00026FF7 00026FF6

DSPTB31:00026F67 00026F40 10158321 10158320 10158403 101583F4 10158343

DSPTB32:10158332 00026FF7 00026FF6 00026F67 00026F40 10158321 10158320

DSPTB33:10158403 101583F4 10158343 10158332 00026FF7 00026FF6 00026F67

DSPTB34:00026F40 10158321 10158320 10158403 101583F4 10158343 10158332

DSPTB35:00026FF7 00026FF6 00026F67 00026F40 10158321 10158320 10158403

DSPTB36:101583F4 10158343 10158332 00026FF7 00026FF6 00026F67 00026F40

DSPTB37:10158321 10158320 10158403 101583F4 10158343 10158332 00026FF7

DSPTB38:00026FF6 00026F67 00026F40 10158321 10158320 10158403 101583F4

DSPTB39:10158343 10158332 00026FF7 00026FF6 00026F67 00026F40 10158321

DSPTB40:10158320 10158403 101583F4 10158343 10158332 00026FF7 00026FF6

DSPTB41:00026F67 00026F40 10158321 10158320 10158403 101583F4 10158343

DSPTB42:10158332 00026FF7 00026FF6 00026F85 00026F40 10158321 10158320

DSPTB43:10158403 101583F4 10158343 10158332 00026FF7 00026FF6 00026F85

DSPTB44:00026F40 10158321 10158320 10158403 101583F4 10158343 10158332

DSPTB45:00026FF7 00026FF6 00026F85 00026F40 10158321 10158320 10158403

DSPTB46:101583F4 10158343 10158332 00026FF7 00026FF6 00026F85 00026F40

DSPTB47:10158321 10158320 10158403 101583F4 10158343 10158332 00026FF7

DSPTB48:00026FF6 00026F85 00026F40 10158321 10158320 10158403 101583F4

DSPTB49:10158343 10158332 00026FF7 00026FF6 00026F85

===== End of DSP tracebuffer dump=====

Oct 17 08:56:00.321: %DSPRM-5-UPDOWN: DSP 1 in slot 0, changed state to up

Oct 17 08:56:09.747: ISDN BR0/0/0 Q931: RX <- DISCONNECT pd = 8 callref = 0x52

Cause i = 0x8490 - Normal call clearing

Any pointers appreciated.

Thanks !
GP

Tagir Temirgaliyev · ‎11-08-2014

I had problem like this. dspfarm profile was wrong.

share your config

Gert Plessers · ‎11-09-2014

Hello Tagir,

Attached is the config. Thanks for looking into this.

GP

Tagir Temirgaliyev · ‎11-09-2014

you have 
 
dspfarm profile 1 conference

but you do not have profile for transcoding

Gert Plessers · ‎11-10-2014

Hello Tagir,

That is correct - but why I need a profile for transcoding ? It is a simple transfer from ip phone to ip phone (albeit sccp to sip - 7965 to 9971) that is making the DSP crash (and the customer call drop).

I don't really understand how a transcoder would fix that ?

Thanks,
GP

Francisco Granados · ‎11-10-2014

The only thing that I can think about is perhaps CME to the SIP phone is negotiating a codec like G.722 and that's not accepted on your 796X. Either way it may be a good idea to setup the transcoder.

Another question, does the issue happen when cold and warm transfering? I once had a situation where my receptionist needed to wait for the other party to answer and then transfer, otherwise the transfer would fail. I'm excited to hear what others have to say about this.

Frank

Tagir Temirgaliyev · ‎11-10-2014

transcoding should be to connect sccp and sip call legs

Gert Plessers · ‎11-11-2014

Thanks Frank/Tagir, I'm going to setup that transcoder. But why is it happening not all the time in this case ? Let's say for 10 calls it goes well 7 - 8 times, 2 or 3 times out of 10 it fails. But as said - more then happy to setupthe transcoder to give it a try.

@ Frank - warm/cold transfer does not really change the situation ...

GP

Gert Plessers · ‎11-27-2014

The problem persists - have added a PVDM3-32 and configured a transcoder, but still calls keeps dropping during transfer.

Any other thoughts - the only thing that comes to mind is the phones itself right now ....

GP

Gert Plessers · ‎02-25-2015

Quick update if other's are facing this too - I finally upgrade to the latest IOS about a month ago and that fixed the problem. Albeit I'm not in favor of upgrading without a good indication of an existing bug, it seems to have fixed the issue.

GP