pjsip / pjproject

PJSIP project
http://www.pjsip.org
GNU General Public License v2.0
2.07k stars 783 forks source link

No DTMF: Bad RTP pt 101 (expecting 8) #2369

Closed bettercalljason closed 4 years ago

bettercalljason commented 4 years ago

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:

  1. Make an outgoing call to your phone
  2. Enter a DTMF digit
  3. DTMF digit is not received! (Bad RTP pt 101 (expecting 8))

Expected behavior I receive the DTMF digit through the onDtmfDigit callback as before b48fd40.

Logs/Screenshots

TX 1231 bytes Request msg INVITE/cseq=24981 (tdta0xb4607ab4) to UDP 10.130.10.200:5060:
INVITE sip:00791234567@10.130.10.200 SIP/2.0
Via: SIP/2.0/UDP 10.130.10.199:48085;rport;branch=z9hG4bKPj1R8uwsrnCQSar30VHOiRq7asgPzzeeHf
Max-Forwards: 70
From: sip:99@10.130.10.200;tag=.LiCqRcHqbLZGDYGVHJcnbZf-EHn8DPm
To: sip:00791234567@10.130.10.200
Contact: <sip:99@10.130.10.199:48085;ob>
Call-ID: vhKc4lOuq7Iu6biSFSrWJ4SJHZhBl-aT
CSeq: 24981 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
Content-Type: application/sdp
Content-Length:   632
v=0
o=- 3794751935 3794751935 IN IP4 10.130.10.200
s=pjmedia
b=AS:84
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 98 97 99 104 3 0 8 9 96 100 101
c=IN IP4 10.130.10.200
b=TIAS:64000
a=rtcp:4001 IN IP4 10.130.10.200
a=sendrecv
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:99 speex/32000
a=rtpmap:104 iLBC/8000
a=fmtp:104 mode=30
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:96 telephone-event/16000
a=fmtp:96 0-16
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-16
a=rtpmap:101 telephone-event/32000
a=fmtp:101 0-16
a=ssrc:1153781585 cname:3c8b1023376e2ba1
RX 453 bytes Response msg 407/INVITE/cseq=24981 (rdata0x269cc4c) from UDP 10.130.10.200:5060:
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 10.130.10.199:48085;rport;branch=z9hG4bKPj1R8uwsrnCQSar30VHOiRq7asgPzzeeHf
From: sip:99@10.130.10.200;tag=.LiCqRcHqbLZGDYGVHJcnbZf-EHn8DPm
To: <sip:00791234567@10.130.10.200>;tag=3880185572
Call-ID: vhKc4lOuq7Iu6biSFSrWJ4SJHZhBl-aT
CSeq: 24981 INVITE
Content-Length: 0
Proxy-Authenticate: Digest realm="10.130.10.200",nonce="9d6aa4ffd2845e01c694009033410811",qop="auth",algorithm=MD5
TX 351 bytes Request msg ACK/cseq=24981 (tdta0x26a0ddc) to UDP 10.130.10.200:5060:
ACK sip:00791234567@10.130.10.200 SIP/2.0
Via: SIP/2.0/UDP 10.130.10.199:48085;rport;branch=z9hG4bKPj1R8uwsrnCQSar30VHOiRq7asgPzzeeHf
Max-Forwards: 70
From: sip:99@10.130.10.200;tag=.LiCqRcHqbLZGDYGVHJcnbZf-EHn8DPm
To: sip:00791234567@10.130.10.200;tag=3880185572
Call-ID: vhKc4lOuq7Iu6biSFSrWJ4SJHZhBl-aT
CSeq: 24981 ACK
Content-Length:  0
Temporary failure in sending Request msg INVITE/cseq=24982 (tdta0xb4607ab4), will try next server: Unsupported transport (PJSIP_EUNSUPTRANSPORT)
TX 1501 bytes Request msg INVITE/cseq=24982 (tdta0xb4607ab4) to UDP 10.130.10.200:5060:
INVITE sip:00791234567@10.130.10.200 SIP/2.0
Via: SIP/2.0/UDP 10.130.10.199:48085;rport;branch=z9hG4bKPj18QOjdfILreaNfpzInR.PZzryVL4CZBB
Max-Forwards: 70
From: sip:99@10.130.10.200;tag=.LiCqRcHqbLZGDYGVHJcnbZf-EHn8DPm
To: sip:00791234567@10.130.10.200
Contact: <sip:99@10.130.10.199:48085;ob>
Call-ID: vhKc4lOuq7Iu6biSFSrWJ4SJHZhBl-aT
CSeq: 24982 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
Proxy-Authorization: Digest username="99", realm="10.130.10.200", nonce="9d6aa4ffd2845e01c694009033410811", uri="sip:00791234567@10.130.10.200", response="10ccff02aca817c3f04e505771360c2f", algorithm=MD5, cnonce="xSSqKFIoVdju6JU2NomgYaP5.h3reVY", qop=auth, nc=00000001
Content-Type: application/sdp
Content-Length:   632
v=0
o=- 3794751935 3794751935 IN IP4 10.130.10.200
s=pjmedia
b=AS:84
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 98 97 99 104 3 0 8 9 96 100 101
c=IN IP4 10.130.10.200
b=TIAS:64000
a=rtcp:4001 IN IP4 10.130.10.200
a=sendrecv
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:99 speex/32000
a=rtpmap:104 iLBC/8000
a=fmtp:104 mode=30
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:96 telephone-event/16000
a=fmtp:96 0-16
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-16
a=rtpmap:101 telephone-event/32000
a=fmtp:101 0-16
a=ssrc:1153781585 cname:3c8b1023376e2ba1
RX 509 bytes Response msg 100/INVITE/cseq=24982 (rdata0x269cc4c) from UDP 10.130.10.200:5060:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.130.10.199:48085;rport;branch=z9hG4bKPj18QOjdfILreaNfpzInR.PZzryVL4CZBB;received=10.130.10.199
From: sip:99@10.130.10.200;tag=.LiCqRcHqbLZGDYGVHJcnbZf-EHn8DPm
To: <sip:00791234567@10.130.10.200>;tag=3880185573
Call-ID: vhKc4lOuq7Iu6biSFSrWJ4SJHZhBl-aT
CSeq: 24982 INVITE
Allow: REGISTER,SUBSCRIBE,NOTIFY,INVITE,ACK,PRACK,OPTIONS,BYE,CANCEL,REFER,INFO,UPDATE,PUBLISH
Content-Length: 0
Server: (innovaphone IP811/12r2 sr7 [12.5256/125256/400])
Recv-Info: dtmf
RX 980 bytes Response msg 183/INVITE/cseq=24982 (rdata0x269cc4c) from UDP 10.130.10.200:5060:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 10.130.10.199:48085;rport;branch=z9hG4bKPj18QOjdfILreaNfpzInR.PZzryVL4CZBB
From: sip:99@10.130.10.200;tag=.LiCqRcHqbLZGDYGVHJcnbZf-EHn8DPm
To: <sip:00791234567@10.130.10.200>;tag=3880185573
Call-ID: vhKc4lOuq7Iu6biSFSrWJ4SJHZhBl-aT
CSeq: 24982 INVITE
Contact: <sip:00791234567@10.130.10.200:5060;user=phone;transport=UDP>
Allow: REGISTER,SUBSCRIBE,NOTIFY,INVITE,ACK,PRACK,OPTIONS,BYE,CANCEL,REFER,INFO,UPDATE,PUBLISH
Content-Length: 258
Content-Type: application/sdp
Server: (innovaphone IP811/12r2 sr7 [12.5256/125256/400])
Supported: replaces,privacy,answermode,from-change,100rel,timer,histinfo
Allow-Events: talk,conference
P-Sig-Options: Sending-Complete
v=0
o=- 3316 1 IN IP4 10.130.10.200
s=pjmedia
t=0 0
m=audio 30148 RTP/AVP 8 101 13
c=IN IP4 10.130.10.200
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=rtpmap:13 CN/8000
a=fmtp:101 0-15
a=ptime:20
a=silenceSupp:off - - - -
a=sendrecv
RX 1007 bytes Response msg 200/INVITE/cseq=24982 (rdata0x269cc4c) from UDP 10.130.10.200:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.130.10.199:48085;rport;branch=z9hG4bKPj18QOjdfILreaNfpzInR.PZzryVL4CZBB;received=10.130.10.199
From: sip:99@10.130.10.200;tag=.LiCqRcHqbLZGDYGVHJcnbZf-EHn8DPm
To: <sip:00791234567@10.130.10.200>;tag=3880185573
Call-ID: vhKc4lOuq7Iu6biSFSrWJ4SJHZhBl-aT
CSeq: 24982 INVITE
Contact: <sip:00791234567@10.130.10.200:5060;user=phone;transport=UDP>
Allow: REGISTER,SUBSCRIBE,NOTIFY,INVITE,ACK,PRACK,OPTIONS,BYE,CANCEL,REFER,INFO,UPDATE,PUBLISH
Content-Length: 258
Content-Type: application/sdp
Require: timer
Server: (innovaphone IP811/12r2 sr7 [12.5256/125256/400])
Supported: 100rel,replaces,privacy,timer,from-change,histinfo,tdialog,answermode,uui
Session-Expires: 1800;refresher=uac
Recv-Info: dtmf
v=0
o=- 3316 1 IN IP4 10.130.10.200
s=pjmedia
t=0 0
m=audio 30148 RTP/AVP 8 101 13
c=IN IP4 10.130.10.200
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=rtpmap:13 CN/8000
a=fmtp:101 0-15
a=ptime:20
a=silenceSupp:off - - - -
a=sendrecv
TX 381 bytes Request msg ACK/cseq=24982 (tdta0x2827e1c) to UDP 10.130.10.200:5060:
ACK sip:00791234567@10.130.10.200:5060;user=phone;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 10.130.10.199:48085;rport;branch=z9hG4bKPjnVRSuWaEsuvYZj7jj.f14jtxdSLTfs3Q
Max-Forwards: 70
From: sip:99@10.130.10.200;tag=.LiCqRcHqbLZGDYGVHJcnbZf-EHn8DPm
To: sip:00791234567@10.130.10.200;tag=3880185573
Call-ID: vhKc4lOuq7Iu6biSFSrWJ4SJHZhBl-aT
CSeq: 24982 ACK
Content-Length:  0

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):

Additional context

ptrenta commented 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

ptrenta commented 4 years ago

[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

bettercalljason commented 4 years ago

[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.

sauwming commented 4 years ago

It seems that the bug is on the remote side for incorrectly choosing the telephone events with the desired clock rate.

bettercalljason commented 4 years ago

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?

sauwming commented 4 years ago

We are the offerer, and remote is the answerer.

bettercalljason commented 4 years ago

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

bettercalljason commented 4 years ago

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?

bettercalljason commented 4 years ago

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!

nwhitehorn commented 3 years ago

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.