On 05.01.2017 19:01, Anthony Minessale wrote:
The 4733 is just an update to 2833 and its basically the same in terms of our usage so you can consider the names interchangeable. There is no way to negotiate SIP INFO DTMF so you can enable it as needed. If you want to send INFO DTMF you can set the variable dtmf_type=info in the outbound dial string.
INFO is the most reliable when used with TCP, 2833 is more reliable over UDP. INFO traverses the signaling patch where 2833 traverses the media so there are considerations to make. There is no best.
Oh, my project does not allow to flow rtp directly between clients, so SIP info is ok, also I use UDP so rfc2833 is needed. As I understand FS will catch SIP info and rfc2833 in same leg using that option. Well, found some interesting info: http://sip-implementors.cs.columbia.narkive.com/0VSY8gy9/is-rfc-2833-a-must-...
Remember that SIP and RTP sometimes travels different paths. For many applications, it is important that DTMF is timed with the rest of the audio. Sending DTMF without timestamps and in a different signalling path totally removes the relation to the audio stream.
My experience is that very few carriers now support SIP Info.
Well, arguably not much relation to audio stream is really needed for DTMF applications. Relative events ordering, not absolute timestamps, is what important here and it is provided reliably by the CSeq in SIP INFO.
I think technically SIP INFO delivery method is superior to RFC2833 (DTMF is a signaling, not media after all, so that it should take signaling path), however, as it has been correctly mentioned here, there is no common standard and much weaker support across different implementations.
The only upside I see is that it's easier to debug DTMF in the SIP channel than deep down in RTP. Otherwise, RFC2833 is the way to go.
I think info from the post should be reflected at https://freeswitch.org/confluence/display/FREESWITCH/DTMF -- Mimiko desu.