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

[Gert Plessers]

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]

I had problem like this. dspfarm profile was wrong.

share your config

[Gert Plessers]

Hello Tagir,

Attached is the config. Thanks for looking into this.

GP

[Tagir Temirgaliyev]

you have 
 
dspfarm profile 1 conference 

but you do not have profile for transcoding

[Gert Plessers]

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]

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]

transcoding should be to connect sccp and sip call legs

[Gert Plessers]

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]

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]

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