Closed bettercalljason closed 4 years ago
I have the same error.
1) in incoming calls i can allways receive DTMF. 2) in outgoing calls i receive trm0xb4f0b2cc Bad RTP pt 101 (expecting 0) 3) sometimes, if a dial an outgoing call, after have received an incoming call, i am able to receive DTMF
i am using an asterisk pbx on an armbian linux
I can see that when the DTMF are received i have this log after the connection > 20:32:37.516 udp0x836488 !Remote RTP address switched to 192.168.178.119:15072 20:32:37.516 udp0x836488 Remote RTCP address switched to predicted address 192.168.178.119:15073 20:32:37.953 strm0xb4f1d624 !VAD re-enabled 20:32:38.274 sound_port.c EC activated 20:32:39.574 APP .Incoming DTMF on call 3: 5
Instead when the DTMF are not received the 2 rows about remote RTP and RTCP address are missing
[SOLVED] for me. i have set in asterisk sip extension configuration the parameter directmedia=no and now it works great!
user.conf [6001] port=5061 host=dynamic type=friend fullname = Sip Tsa secret = 1234 hassip = yes context = users callwaiting = yes username=6001 cid_number=6001 qualify=yes directmedia=no
[SOLVED] for me. i have set in asterisk sip extension configuration the parameter directmedia=no and now it works great!
user.conf [6001] port=5061 host=dynamic type=friend fullname = Sip Tsa secret = 1234 hassip = yes context = users callwaiting = yes username=6001 cid_number=6001 qualify=yes directmedia=no
great to hear that. Unfortunately for me I have no control over the PBX so I can‘t change these settings.
It seems that the bug is on the remote side for incorrectly choosing the telephone events with the desired clock rate.
It seems that the bug is on the remote side for incorrectly choosing the telephone events with the desired clock rate.
Remote side offered a=rtpmap:101 telephone-event/8000
Shouldn't we accept what remote side offers instead?
We are the offerer, and remote is the answerer.
It seems that the bug is on the remote side for incorrectly choosing the telephone events with the desired clock rate.
You're right. It's a bug of the remote Innovaphone: http://wiki.innovaphone.com/index.php?title=Reference12r2:Release_Notes_Firmware#68020_-_Media:_Fix_for_channels_offers_with_multiple_DTMF_payload_types
I've got the same issue with another provider.
I send multiple offers, remote answers with a=rtpmap:101 telephone-event/8000
. Is there really no way to accept this or get the old behaviour back?
I've got the same issue with another provider. I send multiple offers, remote answers with
a=rtpmap:101 telephone-event/8000
. Is there really no way to accept this or get the old behaviour back?
https://github.com/pjsip/pjproject/pull/2427 makes this possible. Thanks!
I just hit the same problem with CUCM. Clearly, it's CUCM that is doing the wrong thing, but it would nonetheless be really nice if pjsip parsed the reply and re-ID'ed the codecs properly the way other endpoints do.
Describe the bug On outgoing call, DTMF inputs from callee are not received. Instead, pjsip reports
Bad RTP pt 101 (expecting 8)
The bug is related to commit b48fd40. With its previous commit I have no issues, all commits afterwards don't fix it.
To Reproduce It seems to be something server-related, since the bug appears with the PBX innovaphone but not with the server Netstream.
I use PJSUA2 in the application.
Steps to reproduce the behavior:
Bad RTP pt 101 (expecting 8)
)Expected behavior I receive the DTMF digit through the onDtmfDigit callback as before b48fd40.
Logs/Screenshots
When I now press a DTMF digit on my phone I get the following log in pjsip:
Bad RTP pt 101 (expecting 8)
Desktop/Smartphone (please complete the following information):
configure
script params: --disable-sound --disable-video --disable-ssluser.mak
contents:export CFLAGS += -msse4.1
Additional context