eyebeam uses "DTMF Inband"using eyebeam softphone DTMF is working fine on new SIP account
SIP/2.0 200 OK
m=audio 8376 RTP/AVP 18
a=rtpmap:18 G729/8000/1
a=fmtp:18 annexb=no
a=sendrecv
[Answer]
v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49172 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=audio 49174 RTP/AVP 98
a=rtpmap:98 telephone-event/8000
a=recvonly
Also, provide us SIP accounts on those PBXes for testing.Sippy, VOS3000, VoipSwitch & Asterisk
codecs=opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,h264,vp8,flv,mpv
codecs_exclude_sip=mpeg4-generic,flv,mpv
opus,alaw,ulaw,g729,speex16,g722,telephone-event,h264,vp8
codecs=opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,h264,vp8,flv,mpv
codecs_exclude_sip=mpeg4-generic,flv,mpv,opus,alaw,ulaw,speex16,g722,h264
allow_outside_codecs=false
In example above, we enabled G729 codec only. Try to enable more audio codecs. Also, if you do not use video calls at all, you can disable vp8 codec.tried to make call and there is no sound once the call is connected
sip_force_tcp=true
Then comment the settingfurther more Sippy does not support TCP SIP commincation
sip_force_tcp=true
dtmf=INFO
No, it's a kind of network issue. It looks like MTU size on some network hardware (switch, router etc) changes, this leads to SIP SDP fragmentation. In this thread we described all the possible ways to prevent it:why is this happing? is it some sort of magic?