<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hello,<br>
<br>
I traced the SIP packets and saw that the only difference was that
the DAHDI channel returns 183 Session progress ( besides the obvious
differences such as the To and from tags in sip , session id and rtp
ports in the SDP ).<br>
<br>
I updated my dialplan on asterisk-pri as follows :<br>
<br>
exten => 6,1,Progress<br>
exten => 6,n,Wait(5)<br>
exten => 6,n,Answer<br>
exten => 6,n,Wait(30)<br>
<br>
This makes the local channel behave the same as the DAHDI channel.
With this in place, the SIP packets for both test calls are
identical ( excluding the To header, To Tag, From Tag, SDP ports,
SDP session Id and SDP version.<br>
<br>
Everything else is identical. So the problem appears to be caused in
the RTP and not in the SIP. So something about the RTP packets
coming from the DAHDI channel on asterisk-pri makes asterisk server
send invalid DTMF.<br>
<br>
David<br>
<br>
On 11-04-24 11:42 AM, David wrote:
<blockquote cite="mid:4DB444DD.2000801@spam.lublink.net" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
I did more testing.<br>
<br>
Here is a portion of extensions.conf on asterisk-pri:<br>
<br>
exten => 5,1,Dial(DAHDI/g1/14186939930,30)<br>
exten => 6,1,Answer<br>
exten => 6,2,Wait(30)<br>
exten => 7,1,Dial(DAHDI/g1/14186939930,30,D(132412983#))<br>
<br>
Here is an expert from asterisk :<br>
<br>
exten => 22,1,Dial(SIP/6@pri,30,D(132412983#))<br>
exten => 24,1,Dial(SIP/5@pri,30,D(132412983#))<br>
<br>
If I type "console dial 24", the DTMFs work poorly, and I see
messages like :<br>
<br>
[Apr 24 11:26:20] DTMF[2691]: channel.c:2907 __ast_read: DTMF end
emulation of '1' queued on DAHDI/1-1<br>
[Apr 24 11:26:20] DTMF[2691]: channel.c:2802 __ast_read: DTMF end
'1' received on SIP/omnity-00000004, duration 60120 ms<br>
[Apr 24 11:26:20] DTMF[2691]: channel.c:2842 __ast_read: DTMF end
accepted with begin '1' on SIP/omnity-00000004<br>
[Apr 24 11:26:20] DTMF[2691]: channel.c:2858 __ast_read: DTMF end
passthrough '1' on SIP/omnity-00000004<br>
[Apr 24 11:26:20] DTMF[2691]: channel.c:2874 __ast_read: DTMF
begin '1' received on DAHDI/1-1<br>
[Apr 24 11:26:20] DTMF[2691]: channel.c:2884 __ast_read: DTMF
begin passthrough '1' on DAHDI/1-1<br>
[Apr 24 11:26:20] DTMF[2691]: channel.c:2802 __ast_read: DTMF end
'1' received on DAHDI/1-1, duration 39 ms<br>
[Apr 24 11:26:20] DTMF[2691]: channel.c:2842 __ast_read: DTMF end
accepted with begin '1' on DAHDI/1-1<br>
[Apr 24 11:26:20] DTMF[2691]: channel.c:2851 __ast_read: DTMF end
'1' has duration 39 but want minimum 80, emulating on DAHDI/1-1<br>
<br>
If I type console dial 22 on asterisk, all the DTMFs are 60ms in
length and I get no unusually long DTMFs.<br>
<br>
If I type console dial 7 on asterisk-pri, all the DTMFs are
properly sent, and the remote party sees my DTMFs perfectly.<br>
<br>
So it would seem that the bug occurs when one asterisk calls the
second asterisk which bridges to a DAHDI channel.<br>
<br>
My next step is too compare the SIP signalling between the two
calls. Maybe something is different.<br>
<br>
What I find really weird is that the DTMF is incorrectly sent from
the first asterisk only when the second asterisk bridges to DAHDI.<br>
<br>
Any ideas?<br>
<br>
David<br>
<br>
On 11-04-23 11:48 AM, David wrote:
<blockquote
cite="mid:894B79E6605240599556083D9D91B566@lublinklaptop"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<meta name="GENERATOR" content="MSHTML 8.00.6001.18828">
<style></style>
<div><font size="2" face="Arial">
<div><font size="2" face="Arial">Hello,</font></div>
<div> </div>
<div><font size="2" face="Arial">I installed Asterisk
1.6.2.17.3 ( latest as of yesterday ) and had multiple
problems with DTMF.</font></div>
<div> </div>
<div><font size="2" face="Arial">I have two machines, we'll
call them asterisk and asterisk-pri. Asterisk does IVR
and asterisk-pri has a PRI card in it and connects to
the PSTN. The two servers communicate via SIP with
RFC2833.</font></div>
<div> </div>
<div><font size="2" face="Arial">I setup logger.conf on both
machines to display DTMF to the console. Both are built
from source.</font></div>
<div><font size="2" face="Arial">Asterisk : spandsp, dahdi,
asterisk.</font></div>
<div><font size="2" face="Arial">Asterisk-pri : spandsp,
libpri, dahdi, asterisk wanpipe</font></div>
<div> </div>
<div><font size="2" face="Arial">I eliminated AGI, hard
phones, network et al by setting up this extension :</font></div>
<div> </div>
<div><font size="2" face="Arial">exten => 22,1,Dial(<a
moz-do-not-send="true"
href="mailto:SIP/114186939930@pri1.omnity.net,30,D%28132412983">SIP/114186939930@pri1.omnity.net,30,D(132412983</a>#))</font></div>
<div> </div>
<div><font size="2" face="Arial">in default.</font></div>
<div> </div>
<div><font size="2" face="Arial">The only other non default
setting is in sip.conf I added a outboundproxy ( which
does NOT do RTP, only SIP ).</font></div>
<div> </div>
<div><font size="2" face="Arial">I called asterisk from my
hard phone ( gxp2000 ) by dialing 22.</font></div>
<div> </div>
<div><font size="2" face="Arial">I see the console DTMF
messages indicating the DTMF was sent or received. ( I
forgot to keep this output ).</font></div>
<div> </div>
<div><font size="2" face="Arial">I than watch the console
DTMF output on asterisk-pri and it showed about half the
DTMFs. The pager that was called showed the DTMFs that
appeared on the asterisk-pri console.</font></div>
<div> </div>
<div><font size="2" face="Arial">So somewhere between the
two machines, the DTMFs have disappeared. So I ran
TCPDump on asterisk and saw that close to half of the
DTMF events were never sent.</font></div>
<div> </div>
<div><font size="2" face="Arial">tcpdump -i eth0 -n -s 0
dst asterisk-pri-ip -vvv -w ~/dtmf.pcap<br>
</font></div>
<div><font size="2" face="Arial">I imported the file into
wireshark on my local machine and confirmed that the
dump almost matches what I saw on asterisk-pri.</font></div>
<div> </div>
<div><font size="2" face="Arial">So, problem 1 : Asterisk is
not sending all the DTMFs to asterisk-pri.</font></div>
<div> </div>
<div><font size="2" face="Arial">I compared the packet scan
to what I saw on asterisk-pri and noticed that between 1
and 3 dtmfs were missing.</font></div>
<div> </div>
<div><font size="2" face="Arial">Problem 2 : Asterisk-pri
loses some received DTMFs.</font></div>
<div> </div>
<div><font size="2" face="Arial">I also noticed that some of
the DTMFs coming out of asterisk had the wrong Event
Duration. I had one DTMF with a duration of about 58000
( I believe that's 58 seconds ) but I only pressed the
button for like 1/3 of a second.</font></div>
<div> </div>
<div><font size="2" face="Arial">What I do not understand is
that I in my final test last night was using asterisk
1.6 current with centos ( os that asterisk is developed
on from my understanding ) with all default settings (
excluding logger.conf, dialplan and outboundproxy ) and
I am having problems with the DTMF.</font></div>
<div> </div>
<div><font size="2" face="Arial">Both servers were installed
with CentOS 5.5 and were updated last night, after which
I reinstalled asterisk. This did not resolve the issue.</font></div>
<div> </div>
<div><font size="2" face="Arial">I am at wit's end and do
not know where to go from here. I would really
appreciate it if someone could give me some pointers on
where to go next, what additionnal debugging steps I
should perform. I would also really appreciate if
someone could propose a solution.</font></div>
<div> </div>
<div><font size="2" face="Arial">Please help!</font></div>
<div> </div>
<div><font size="2" face="Arial">David</font></div>
<div> </div>
<div><font size="2" face="Arial">Never give up, never
surrender</font></div>
</font></div>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a> --
New to Asterisk? Join us for a live introductory webinar every Thurs:
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.asterisk.org/hello">http://www.asterisk.org/hello</a>
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a></pre>
</blockquote>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a> --
New to Asterisk? Join us for a live introductory webinar every Thurs:
<a class="moz-txt-link-freetext" href="http://www.asterisk.org/hello">http://www.asterisk.org/hello</a>
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a></pre>
</blockquote>
</body>
</html>