Calls disconnected due to audio being interpreted as Speex codec

Asterisk Asterisk SIP
1

We have a customer that has started to experience calls being disconnected when they perform an outbound - call for no apparent reason. The error it is not persistent. It fails around 15 times per day, but all other calls works perfectly.

When an Agent performs an outbound call then we first send an INVITE to the agent, which is accepted immediately. We then invite the intended receiver and bridge the audio within Asterisk, with no updates to the media path.

The log messages claim that the call is dropped because Asterisk isn’t able to translate media between A-law and Speex - but the only codec ever mentioned for both SIP sessions is A-law. I assume that Asterisk receives initial media packets that wrongly are interpreted as Speex audio.

Is it possible to have Asterisk simple discard these packages and wait for A-law to appear?

We are currently using Asterisk 13 at the customer - is there a known fix for this behavior in a later Asterisk versions?

When the error happens then we see these warnings in the log:

[Aug 11 11:35:08] WARNING[11114][C-000972fa] codec_builtin.c: Encountered corrupt speex frame; too many wideband frames in a row.
[Aug 11 11:35:08] WARNING[11114][C-000972fa] codec_builtin.c: Had error while reading wideband frames for speex samples
[Aug 11 11:35:08] VERBOSE[11114][C-000972fa] app_dial.c: PJSIP/1_SIPBTrunk-0011cc56 requested media update control 26, passing it to PJSIP/1_SIPBTrunk-0011cc57
[Aug 11 11:35:08] WARNING[11114][C-000972fa] channel.c: Unable to find a codec translation path: (speex) → (alaw)
[Aug 11 11:35:08] WARNING[11114][C-000972fa] app_dial.c: Unable to forward frametype: 2
[Aug 11 11:35:08] WARNING[6974] channel.c: Unable to find a codec translation path: (alaw) → (speex)
[Aug 11 11:35:08] VERBOSE[11114][C-000972fa] app_dial.c: PJSIP/1_SIPBTrunk-0011cc56 requested media update control 26, passing it to PJSIP/1_SIPBTrunk-0011cc57
[Aug 11 11:35:08] WARNING[11114][C-000972fa] app_dial.c: Unable to forward frametype: 2
[Aug 11 11:35:09] WARNING[11114][C-000972fa] app_dial.c: Unable to forward frametype: 2
[Aug 11 11:35:09] WARNING[11114][C-000972fa] app_dial.c: Unable to forward frametype: 2
[Aug 11 11:35:09] WARNING[11114][C-000972fa] app_dial.c: Unable to forward frametype: 2
[Aug 11 11:35:09] WARNING[11114][C-000972fa] app_dial.c: Unable to forward frametype: 2
[Aug 11 11:35:09] WARNING[11114][C-000972fa] app_dial.c: Unable to forward frametype: 2

I have attached the SIP communication and parts of the diaplan execution in case you need it.

Any kind of hit for trouble shooting this will be greatly apprecciated.

Sip.txt (15.4 KB)

2

The current version is Asterisk 22, so unless someone immediately remembers you’re unlikely to get an answer to this without researching yourself unless someone takes an interest and digs themselves. I can say, though, that I haven’t heard of this in any recent versions.

3

Good point, and I kind of expected that answer.

I just hoped that someone knew of a configuration that would force Asterisk to disregard audio packets in cannot process.

4

I thought that was what it did! You haven’t provided any evidence that the call is dropped because of excessive rejected packets. It might be rejected if no valid packets were received.

5

Caught a call with tcp-dump enabled, and yes, it’s true that no audio frames has been received. Asterisk send a CANCEL before the remote side has sent the SDP with the audio information.

I assume that Asterisk is handling everything ok, because the error only happens for call towards a specific phone type - and it seems to be consistent. I however cannot create Ericsson case before I can explain why Asterisk sends the CANCEL request.

I have attached the SIP communication and warnings from the full log and the tcp dump (zipped)

The first Call towards the agent is setup fine. When we initiate the call to the receiver, then we immediately receive a Re-INVITE for the call towards the agent, and it seems that it is this call that is causing Asterisk to CANCEL the call towards the receiver.

I really hope that you can me a clue to what is happening. For the customer it is becoming extremely critical, because it happens to all the agents that is working from home.

As said, Asterisk is probably fine, but I need to be able to explain why the CANCEL is sent.

SIP.txt (17.6 KB)

tcpdump.zip (3.6 KB)

6

I compared the tcp dump to a call that did not have this problem, and I did find one difference.

The frame number 31 is a RTP packet with Dynamic RTP Type 110.

It is followed by 5 normal A-law packages, but the the CANCEL is sent.

I would assume that it is this packet that Asterisk assumes is speex.

Could this be the culprit, and is there something I can do on Asterisk to avoid the CANCEL?

CallOK.zip (111.0 KB)

7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.