<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffff99" text="#000000">
<pre wrap="">I appreciate your report (below), but it's a strange and disturbing coincidence for me. DTMF out through Vitelity was not working for me until 1-2 days ago when I changed it from rfc2833 to inband!
Maybe I just missed the change date and I should change it back?
----
Date: Tue, 22 Jul 2008 12:23:39 -0400
From: "Mark G. Thomas" <a class="moz-txt-link-rfc2396E"
href="mailto:Mark@Misty.com"><Mark@Misty.com></a>
Subject: [asterisk-users] Vitelity dtmfmode=rfc2833 started working!
To: <a class="moz-txt-link-abbreviated"
href="mailto:asterisk-users@lists.digium.com">asterisk-users@lists.digium.com</a>
Message-ID: <a class="moz-txt-link-rfc2396E"
href="mailto:20080722162339.GA12794@lucky.misty.com"><20080722162339.GA12794@lucky.misty.com></a>
Content-Type: text/plain; charset=us-ascii
Hi,
Last week my outbound (dtmfmode=inband) DTMF via Vitelity started acting
more weird than usual, and for outbound calls, incoming DTMF tones would
consistenly get stuck, breaking a call screen macro I had set up.
I checked "sip show peer" and saw that Vitelity for inbound was
now reporting "DTMFmode : rfc2833" (it didn't used to), so switched
my ountbound dtmfmode to rfc2833 and my problems went away! Yay!
It looks like Vitelity now supports rfc2833 on SIP channels.
I thought others might be interested in knowing this, as at least in my
case it broke things until I changed my settings, and I see this has been
a prior source of frustration for many others.
</pre>
</body>
</html>