CSCtq47019 - AS5400 crosstalk

[Daniele Giordano]

I've found this note about the issue in title:

•CSCtk34885

Symptoms: Crosstalk being heard intermittently on inbound calls.

Conditions: Inbound calls from PSTN to Ingress gateway hearing crosstalk on Rout call leg (DSP to PSTN) on AS5400XM.

Workaround: The following command in IOS can mitigate this for SIP:

voice service voip sip source filter

This eliminates the risk for crosstalk since the gateway blocks all rogue audio out to the PSTN with this command.

The above command only works for SIP, so H323, MGCP, and SCCP are still affected.

The following enhancement requests have been filed:

CSCtq47019 - support on H.323, SCCP, and MGCP. This will allow the command to be used in all VoIP environments.

CSCtq47431 - To get this feature added to IP phones.

PSIRT Evaluation: The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 1.8/1.6:

https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:A/AC:H/Au:N/C:P/I:N/A:N/E:F/RL:W/RC:C

No CVE ID has been assigned to this issue.

Additional information on Cisco's security vulnerability policy can be found at the following URL: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

Do you know if Cisco has already prepared a workaround for MGCP scenario?

Can you give me info about CSCtq47019 case?

Regards.

[Daniele Giordano]

The bug CSCtk34885  (about crosstalk problem in SIP scenario) had the high severity level 2 and was fixed.

Cisco AS5400 is widely used with Cisco PGW 2200 Softswitch.

The gateway is controlled via MGCP.

So I don't understand why the crosstalk issue in the MGCP scenario is not yet solved.

Can anyone help me?

Regards.

[Youssef Aoufi]

Hi Daniele,

We are facing the crosstalk problem in our Voip solution,

I am Using Cisco AS5400 with 12.4(24)T6, RELEASE SOFTWARE (fc2) IOS.

The bug CSCtk34885 shows my IOS 12.4(24)T6 as known fixed release .

The problem is that when i apply the workaroud : voice service voip sip source filer, we have one way audio on  the pstn side.

Finally have you been able to solve this problem.

Thank you in advance

Kind regards

[Daniele Giordano]

Hi Youssef, unfortunately my problem is not fixed.

Actually I've opened a case to TAC.

The first suggestion that I've received is to upgrade the IOS to the latest c5400-is-mz.151-4.M7.bin and check if the problem still exist.

I'll upgrade my hardware in the next weeks and I'll take new test.

What is your signalling protocol? SIP, MGCP or H.323?

Regards.

[Youssef Aoufi]

Hi daniele,

I received the same suggestion from cisco TAC : upgrading to the 15.1 IOS.  I've already did it this morning and now we are monitoring the results.

I am using sip signalling between my cucm 8.6 and the as5400.

In my case the cross talk problem is very intermitent and i cannot reproduce it when i want to.  What about you ?

Regards

[Daniele Giordano]

I use a stack of 4 AS5400 controlled via MGCP from Cisco PGW, but in the past I used also H.323 and SIP protocols.

Crosstalk was always present.

From the bug description, this issue seems fixed in a SIP scenario.

Now I need to fix also in MGCP.

The percentage of calls with the problem is low and is difficult to reproduce the case because is apparently random.

But the problem exist and my customers have reported it to me many times.

Please let me know the result with the latest IOS.

Regards.

[Daniele Giordano]

Another question. I suspect in a DSP fault.

What DSP are installed on your AS? Next Port DSP or PVDM?

C5400-VoiceGW-03#show spe version

IOS-Bundled Default Firmware-Filename      Version        Firmware-Type

=====================================      ============   =============

system:/ucode/spe_firmware-1               0.10.9.0        SPE firmware

On-Flash Firmware-Filename                 Version        Firmware-Type

=====================================      ============   =============

flash:np.0.10.9.0.spe                      0.10.9.0        SPE firmware

  SPE-#   Type   Port-Range           Version   UPG Firmware-Filename

   2/00  CSMV6    0000-0005          0.10.9.0   N/A flash:np.0.10.9.0.spe

   2/01  CSMV6    0006-0011          0.10.9.0   N/A flash:np.0.10.9.0.spe

   2/02  CSMV6    0012-0017          0.10.9.0   N/A flash:np.0.10.9.0.spe

   2/03  CSMV6    0018-0023          0.10.9.0   N/A flash:np.0.10.9.0.spe

   2/04  CSMV6    0024-0029          0.10.9.0   N/A flash:np.0.10.9.0.spe

   2/05  CSMV6    0030-0035          0.10.9.0   N/A flash:np.0.10.9.0.spe

   2/06  CSMV6    0036-0041          0.10.9.0   N/A flash:np.0.10.9.0.spe

   2/07  CSMV6    0042-0047          0.10.9.0   N/A flash:np.0.10.9.0.spe

   2/08  CSMV6    0048-0053          0.10.9.0   N/A flash:np.0.10.9.0.spe

   2/09  CSMV6    0054-0059          0.10.9.0   N/A flash:np.0.10.9.0.spe

BR

[Daniele Giordano]

Hi Youssef, I've upgraded the IOS and this is the boot log after reload:

*Mar  5 13:03:30.886: %NP_EST-6-DIAG_POST_NTF: (NP address  4/0/1/1), Test ID=SPE_POWER_ON_SELF_TEST, Result=SPE_POST_TEST_FAILED, Diag  code=0xFB00F800, Data format=Binary, Data len=4, Data=00 00 F8 00
*Mar  5  13:03:42.886: %NP_EST-6-RUNTIME_ERR_NTF: (NP address 4/0/1/1), SessionID=0xFFFE,  Error=SPE_FAULT_COREDUMP, TStamp=0x59874, Data format=ASCII, Data len=14,  Data=CSM Tx Timeout

c5400#show spe 4

SPE#    Port #       State        Busyout Shut Crash  State        Type
4/00    0000-0005    ACTIVE             0    0     0  ______       ______     
4/01    0006-0011    ACTIVE             0    0      0 __a___       __v___     
4/02    0012-0017    ACTIVE             0     0     0 a_a__a       v_v__v     
4/03    0018-0023    ACTIVE              0    0     0 __a___       __v___     
4/04    0024-0029     ACTIVE             0    0     0 ___a__       ___v__     
4/05     0030-0035    ACTIVE             0    0     0 __a___       __v___      
4/06    0036-0041    ACTIVE             0    0     0 _a___a        _v___v     
4/07    0042-0047    BAD                0    0     0  BBBBBB       ______     
4/08    0048-0053    ACTIVE             0    0      0 _____a       _____v     
4/09    0054-0059    ACTIVE             0     0     0 __aa__       __vv__     
4/10    0060-0065    ACTIVE              0    0     0 _a____       _v____     
4/11    0066-0071     ACTIVE             0    0     0 __a_a_       __v_v_     
4/12     0072-0077    ACTIVE             0    0     0 __a_aa       __v_vv      
4/13    0078-0083    ACTIVE             0    0     0 aaa_a_        vvv_v_     
4/14    0084-0089    ACTIVE             0    0     0  _aaa_a       _vvv_v     
4/15    0090-0095    ACTIVE             0    0      0 aa_aa_       vv_vv_     
4/16    0096-0101    ACTIVE             0     0     0 a_a___       v_v___     
4/17    0102-0107    ACTIVE              0    0     0 __a___       __v___     

You can see a DSP marked as BAD.

This can be explain the issue.

Do you have similar warning in boot log?

Regards.