Clipping at start of outbound calls on CME

[edwardforgacs]

The first second (or part of) of outbound calls seems to be getting clipped on our CME system. This is particularly noticeable when dialling a number which is immediately answered by an automated attendant. In some cases there is no ringback at all, the auto attendant at the other end answers so quickly.

I have also verified on several different numbers and also tried dialling those numbers from a mobile to verify that there is no clipping at the start of the call.

The command voice rtp send-recv is already there. We also have disable-early-media 180 but this made no difference. Is there anything else which can be checked? Which debugs would help with this?

The problem occurs on both an ISDN PRI and SIP trunk and is reproducible every time, but the duration of the clipping occasionally varies. For example, if the remote AA answers "Welcome to xyz company..." sometimes you hear "...come to xyz company", sometimes "to xyz company" and sometimes just "xyz company".

[paolo bevilacqua]

I can believe about SIP, but I never seen this to happen with PRI, and I have many, many installations.

Which exact IOS and phone firmware are you running ?

[moataz_mamdouh]

Hello

did you bind the SIP signalling to one of the router interfaces ?

[edwardforgacs]

IOS version is Version 15.2(2)T, CME 9.0.

Phone firmware on the 7975 the problem occurs reliably on is SCCP75.9-2-3S. It is worth noting that the problem has been occurring for some time, since at least CME 8.6 and the associated compatible phone firmware and IOS versions.

I am not sure what you mean by binding the SIP signalling to one of the router interfaces, do you mean the sip-server command? Currently that is not applied but SIP is not involved at all in the ISDN PRI scenario because the call goes from an SCCP phone to the router to the PRI.

[paolo bevilacqua]

Have you tried reloading router and phone?

You can also try another firmware on the phone, eg 8.5.4

[edwardforgacs]

Yes, both have been reloaded lots of times. I did try again for the sake of it but immediately after doing a full reload the problem is still there, even on the ISDN PRI.

The 8.5.4. firmware caused all sorts of issues on the 7975 with the G.722 codec and we are running the current 9.2.3 on on the advice of the Cisco TAC.

[paolo bevilacqua]

If you can indentify that the problem depends on phone firmware (quite possible), you will have to avoid that version.

[edwardforgacs]

I very much doubt this issue is to do with the phone firmware - if it is, it has existed in nearly every version of the firmware we have used as the issue has been there fore quite some time.

[paolo bevilacqua]

Ok, but in anycase you will have to reconstruct the condition under which it does not happen, to pinpoint the problem.

Since you have a support contract, you can also seek help from the TAC.

[edwardforgacs]

Yes, I understand - but it happens every time, there is no condition I have seen where the clipping doesn't occur.

[paolo bevilacqua]

Try capturing the RTP stream. Youl will be able to listen to it with Wireshark.

That will at least confirm if it comes clipped to the phone, or not.

[edwardforgacs]

I have tried without success to capture the RTP stream. I tried both using service phone spanToPCPort 0 and setting up session monitor on the switch.

In both cases, the RTP stream was easily captured for an internal SIP call (to voicemail system) but the RTP stream was blank in Wireshark for an outbound SCCP call over the ISDN PRI. It would seem that for some reason wireshark could not decode it at all. The streams in Wireshark seemed to be incredibly mixed up with the hold music tangled up on the same stream as the calls but nothing I tried discovered the actual call audio I was after.

I wonder if this could be related to the original problem?

[paolo bevilacqua]

That is strange but I would know if has to do with the problem.

Have you tried with an IPCP, do it happens with it too ?

[edwardforgacs]

The clipping problem still occurs with IP communicator, and the Wireshark trace still can't be decoded properly.

[paolo bevilacqua]

I'm at a loss with this. Hope the TAC can help you better.

Request escalation and be prepared to supply a lot of traces.

Good luck.