Immediate hangup incoming call

I have problem with KE1020A. Hardphone is properly loged in to the freepbx and i can make outgoing and i have two way voice communication. Problem is when i want to receive connection from other hardphone or softphone. KE1020A is ringing, but when i pick up the phone, connection is close immediatelly and i have unavailable signal.
Problem occured only on KE1020A.

At the Asterisk command prompt, type
pjsip set logger on
if it’s a pjsip extension, or
sip set debug on
for chan_sip.

From a working extension, call the KE1020A and answer it. Paste the Asterisk log for the call at and post the link here. If you are too new to post links, just post the last 8 hex characters of the URL.

Hi Stewart.
Thanks for reply.
Link to results of my debuging below.

100 - Extension worked properly (IP:
200 - Extension KE1020A (IP:
My freepbx ip:

from line 285 it looks like you have a codec mismatch.

It’s a bit more than that. The peer is broken and is giving the wrong type code in the rtpmap line, so the 101, which is presumably intended to be telephony events (RFC2833) is undefined, so Asterisk does not know what to do with it, and the 160 is irrelevant, because it isn’t one of the ones mentioned in the m line.

You need to fix the UAS to send valid SDP in the OK.

m=audio 6000 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:160 telephone-event/8000

should be

m=audio 6000 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000


m=audio 6000 RTP/AVP 0 160
a=rtpmap:0 PCMU/8000
a=rtpmap:160 telephone-event/8000

would have been half right, although it still breaks the rule that the same number should be used in the response if the details match the request.

As the error message says, 101 is a dynamic code, and dynamic codes must always have an associated rtpmap line.

Is it possible to chenge this code anywhere?
Client has over 200 KE1020 hardphones and he doesn’t want to replace them with new ones

How to explain to the client that the current pbx was working properly with KE1020 and freepbx will not be :slight_smile:

The relevant code is open source, so it can be changed. You will need to specify in exactly what circumstances it will implement workarounds and the exact nature of those workarounds, but my guess is that it would be a low to medium-low complexity change, and wouldn’t require any real time programming considerations. You will no longer be able to use the packaged Asterisk, but would have to build from source, and re-apply the changes for each update.

I don’t know my way around chan_pjsip, but you may well find that the relevant code is in the pjsip code that Asterisk imports, rather than in Asterisk.

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