Cool, now let's see the sdp for the failing invite and ok.
On Thu, May 3, 2018, 1:07 PM Dominic <address@hidden> wrote:
Hi Russell,
Here is the SDP from the invite and ok of a call that worked (no
codecs with frequency greater than 8000 Hz enabled):
INVITE
--------
v=0
o=1004 3003 1159 IN IP4 192.168.1.10
s=Talk
c=IN IP4 192.168.1.10
t=0 0
a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL
voip-metrics m=audio 7076 RTP/SAVP 96 0 8 18 101 a=rtpmap:96
speex/8000 a=fmtp:96 vbr=on a=fmtp:18 annexb=yes a=rtpmap:101
telephone-event/8000 a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:Yl6b4HKe7GanfgObzlZmCS3TX1iZLmOMW57JJjJ2 a=crypto:2
AES_CM_128_HMAC_SHA1_32
inline:gkfj8LHaB1PZyV8LLdGVDnMu88YT1FxZPwcgcwL8 a=crypto:3
AES_256_CM_HMAC_SHA1_80
inline:kE1BFsEgifzQw9LAyyD80aaIMeFrOlwf1vA4T44PsKS7tlEAHLF552MJ5uGPKg==
a=crypto:4 AES_256_CM_HMAC_SHA1_32
inline:rXGPaoCCvjC0KuwA0aG3HgmHFCGMd5qGeTfGZKYf2WPxhHWKbRYc7MVlrYOsug==
a=rtcp-fb:* ccm tmmbr
200 OK
----------
v=0
o=- 3003 1161 IN IP4 192.168.1.5
s=Asterisk
c=IN IP4 192.168.1.5
t=0 0
m=audio 12880 RTP/SAVP 0 8 18 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:k7d54Fzm1HMFS2WU3xr0zyepyrShTeTIqa03aofs a=rtpmap:0
PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18
annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16
a=ptime:20 a=maxptime:150 a=sendrecv
Here is the SDP from the invite and ok of a call that failed
(speex 16000 Hz enabled):
INVITE
--------
v=0
o=1004 1441 2486 IN IP4 192.168.1.10
s=Talk
c=IN IP4 192.168.1.10
t=0 0
a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL
voip-metrics m=audio 7076 RTP/SAVP 96 97 0 8 18 101 98
a=rtpmap:96 speex/16000 a=fmtp:96 vbr=on a=rtpmap:97 speex/8000
a=fmtp:97 vbr=on a=fmtp:18 annexb=yes a=rtpmap:101
telephone-event/16000 a=rtpmap:98 telephone-event/8000 a=crypto:1
AES_CM_128_HMAC_SHA1_80
inline:SlMxT019CunqOGrAXwXreRhm6kJ9dw8X3Gh6/LhV a=crypto:2
AES_CM_128_HMAC_SHA1_32
inline:pWWTCwxlIGi20WcvZCAJC0Jo29dIrJ/9VmDuk0Ig a=crypto:3
AES_256_CM_HMAC_SHA1_80
inline:PkYK/oG2F8U53pE6Y/1gu05TqqxgqsfFmEegunUOyMsTpNPA8gAEE7QXULB16Q==
a=crypto:4 AES_256_CM_HMAC_SHA1_32
inline:US4TIkQ3sl1XK28C7LZPBMGzJBaCGJqxMVt3sg2PBZFIcwv3KomV8ZWZ3DyvRw==
a=rtcp-fb:* ccm tmmbr
200 OK
----------
v=0
o=- 1441 2488 IN IP4 192.168.1.5
s=Asterisk
c=IN IP4 192.168.1.5
t=0 0
m=audio 16570 RTP/SAVP 0 8 18 98
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:oVH9HZ2j56kvQFRcwOdlEi550fdfu7fBr9RhTHRN a=rtpmap:0
PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18
annexb=no a=ptime:20 a=maxptime:150 a=sendrecv a=rtpmap:98
telephone-event/8000 a=fmtp:98 0-16
Let me know if I can provide any more information or logs.
>On Wed, 02 May 2018 23:20:20 +0000 Russell Treleaven
<address@hidden> wrote:
>
>Please post the sdp in the invite and the 200 ok.
>
>On Wed, May 2, 2018, 6:53 PM Dominic <address@hidden> wrote:
>
>> Hello,
>>
>> I posted this on linphone-users, but I thought it might make more
>> sense to post here. I'm having trouble sending DTMFs from
>> linphone Android and Windows through a FreePBX/Asterisk based
>> PBX.
>>
>> I posted a detailed description of the problem with logs here:
>> https://community.freepbx.org/t/help-...
>>
>> Basically, if I enable any codecs in linphone that uses a
>> frequency greater than 8000 Hz (e.g. speex, opus, etc.) even if
>> that codec is not negotiated, DTMF fails.
>>
>> I'm not sure if the problem lies with Linphone or FreePBX, but I
>> was hoping someone familiar with RFC2833 DTMF could take a quick
>> look at the logs and see if anything looks wrong. My only guess
>> is that the the payload number for telephone-event channel was
>> over 100 when it worked and under when it didn't.
>>
>> Any help is greatly appreciated.
>>
>> --
>> Thank you,
>> Dominic
--
Thank you,
Dominic
_______________________________________________
Linphone-developers mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/linphone-developers