On Wed, Mar 10, 2010 at 8:19 AM, Burden, Mike <m...@lynk.com> wrote:
> Polycom IP550 and Polycom IP650 phones
> Bootrom: 4.2.0.0310
> Firmware: 3.1.3.0439
>
> sipXecs: 4.0.4
>
> Phones are on the same subnet as the sipXecs server. Calls are placed
> through a SIP Trunk via an ITSP.
> The ITSP "is a CLEC with Class 4/5 switches (i.e. we can provide dial-tone
> just like the LEC).
> We don't interface at the FXO/FXS level, we have many hundreds of DS3
> level SS7 trunks into the PSTN."
>
> Wireshark traces taken outside the firewall show normal looking DTMF
> packets (to the best that I can tell)
> I've obfuscated the IP addresses in the trace. 192.168.1.1 is us, and
> 172.16.1.1 is the ITSP.
>
> No. Time Source Destination Protocol
> Info
> 177 12:44:07.305097 192.168.1.1 172.16.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0x61520DE1, Seq=44802, Time=3427727744
> 178 12:44:07.321504 172.16.1.1 192.168.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0xB7FD9F32, Seq=1449, Time=1042988751
> 179 12:44:07.324745 192.168.1.1 172.16.1.1 RTP EVENT
> Payload type=RTP Event, DTMF Nine 9
> 180 12:44:07.341535 172.16.1.1 192.168.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0xB7FD9F32, Seq=1450, Time=1042988911
> 181 12:44:07.344742 192.168.1.1 172.16.1.1 RTP EVENT
> Payload type=RTP Event, DTMF Nine 9
> 182 12:44:07.361505 172.16.1.1 192.168.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0xB7FD9F32, Seq=1451, Time=1042989071
> 183 12:44:07.364797 192.168.1.1 172.16.1.1 RTP EVENT
> Payload type=RTP Event, DTMF Nine 9
> 184 12:44:07.381571 172.16.1.1 192.168.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0xB7FD9F32, Seq=1452, Time=1042989231
> 185 12:44:07.384723 192.168.1.1 172.16.1.1 RTP EVENT
> Payload type=RTP Event, DTMF Nine 9
> 186 12:44:07.401583 172.16.1.1 192.168.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0xB7FD9F32, Seq=1453, Time=1042989391
> 187 12:44:07.404729 192.168.1.1 172.16.1.1 RTP EVENT
> Payload type=RTP Event, DTMF Nine 9
> 188 12:44:07.421565 172.16.1.1 192.168.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0xB7FD9F32, Seq=1454, Time=1042989551
> 189 12:44:07.424735 192.168.1.1 172.16.1.1 RTP EVENT
> Payload type=RTP Event, DTMF Nine 9
> 190 12:44:07.445174 192.168.1.1 172.16.1.1 RTP EVENT
> Payload type=RTP Event, DTMF Nine 9
> 191 12:44:07.450102 172.16.1.1 192.168.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0xB7FD9F32, Seq=1455, Time=1042989711
> 192 12:44:07.461546 172.16.1.1 192.168.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0xB7FD9F32, Seq=1456, Time=1042989871
> 193 12:44:07.464748 192.168.1.1 172.16.1.1 RTP EVENT
> Payload type=RTP Event, DTMF Nine 9
> 194 12:44:07.481501 172.16.1.1 192.168.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0xB7FD9F32, Seq=1457, Time=1042990031
> 195 12:44:07.484732 192.168.1.1 172.16.1.1 RTP EVENT
> Payload type=RTP Event, DTMF Nine 9
> 196 12:44:07.501554 172.16.1.1 192.168.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0xB7FD9F32, Seq=1458, Time=1042990191
> 197 12:44:07.504746 192.168.1.1 172.16.1.1 RTP EVENT
> Payload type=RTP Event, DTMF Nine 9
> 198 12:44:07.521734 172.16.1.1 192.168.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0xB7FD9F32, Seq=1459, Time=1042990351
> 199 12:44:07.524742 192.168.1.1 172.16.1.1 RTP EVENT
> Payload type=RTP Event, DTMF Nine 9
> 200 12:44:07.541784 172.16.1.1 192.168.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0xB7FD9F32, Seq=1460, Time=1042990511
> 201 12:44:07.544767 192.168.1.1 172.16.1.1 RTP EVENT
> Payload type=RTP Event, DTMF Nine 9
> 202 12:44:07.561713 172.16.1.1 192.168.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0xB7FD9F32, Seq=1461, Time=1042990671
> 203 12:44:07.564786 192.168.1.1 172.16.1.1 RTP EVENT
> Payload type=RTP Event, DTMF Nine 9
> 204 12:44:07.581647 172.16.1.1 192.168.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0xB7FD9F32, Seq=1462, Time=1042990831
> 205 12:44:07.584744 192.168.1.1 172.16.1.1 RTP EVENT
> Payload type=RTP Event, DTMF Nine 9
> 206 12:44:07.599711 172.16.1.1 192.168.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0xB7FD9F32, Seq=1463, Time=1042990991
> 207 12:44:07.604724 192.168.1.1 172.16.1.1 RTP EVENT
> Payload type=RTP Event, DTMF Nine 9 (end)
> 208 12:44:07.619888 172.16.1.1 192.168.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0xB7FD9F32, Seq=1464, Time=1042991151
> 209 12:44:07.624860 192.168.1.1 172.16.1.1 RTP EVENT
> Payload type=RTP Event, DTMF Nine 9 (end)
> 210 12:44:07.639953 172.16.1.1 192.168.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0xB7FD9F32, Seq=1465, Time=1042991311
> 211 12:44:07.644716 192.168.1.1 172.16.1.1 RTP EVENT
> Payload type=RTP Event, DTMF Nine 9 (end)
> 212 12:44:07.659935 172.16.1.1 192.168.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0xB7FD9F32, Seq=1466, Time=1042991471
> 213 12:44:07.665032 192.168.1.1 172.16.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0x61520DE1, Seq=44820, Time=3427730624, Mark
> 214 12:44:07.679882 172.16.1.1 192.168.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0xB7FD9F32, Seq=1467, Time=1042991631
> 215 12:44:07.684951 192.168.1.1 172.16.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0x61520DE1, Seq=44821, Time=3427730784
> 216 12:44:07.699905 172.16.1.1 192.168.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0xB7FD9F32, Seq=1468, Time=1042991791
> 217 12:44:07.704979 192.168.1.1 172.16.1.1 RTP
> PT=ITU-T G.711 PCMU, SSRC=0x61520DE1, Seq=44822, Time=3427730944
>
>
> Mike Burden
> Lynk Systems, Inc
> e-mail: m...@lynk.com
> Phone: 616-532-4985
>
>
>
>
> -----Original Message-----
> From: Scott Lawrence [mailto:scottlawr...@avaya.com]
> Sent: Tuesday, March 09, 2010 6:24 PM
> To: Burden, Mike
> Cc: sipx-users@list.sipfoundry.org
> Subject: Re: [sipx-users] DTMF Issues Revisited
>
> On Tue, 2010-03-09 at 17:05 -0500, Burden, Mike wrote:
> > OK, it looks like my understanding was way off base.
> >
> >
> >
> > On the advice of Dave D., Eric V. and Dave W., I’ve tried:
> >
> > - Locking the phones into G.711
> >
> > - Increasing the DTMF On/Off times from 50 to 150 (tested at 25ms
> > increments)
> >
> > - Increased the DTMF level from -15db to -7db
> >
> > - Verified that RFC2833Control is enabled
> >
> > - Verified that ViaRTP is enabled
> >
> > - Verified that RFC2833Payload is set to 101
>
> I've just gone back and looked through all of this thread and I don't
> see any message in which you describe what the configuration is.
>
> What phones are you using? What version?
> What is your interface to the PSTN?
> Is there anything between sipXecs and that PSTN interface?
>
> Network debugging based on trial and error is rarely successful.
> Trace the packets - looking at what is actually on the wire during your
> experimental calls will isolate where your DTMF is being lost.
>
>
>
> _______________________________________________
> sipx-users mailing list sipx-users@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users
> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
> sipXecs IP PBX -- http://www.sipfoundry.org/
>
A real siptrace of a call that DTMF did not work properly on with a
description indicating what was pressed might actually be helpful.
Version of sipxecs?
Polycom Bootrom?
Polycom Firmware?
What ITSP?
I used to have this problem with my cellphone (independent if sipx) and I
had to enabled a function on my cellphone to allow me to control the
duration of a key press. The default setting for this in sipx 4.0.4 are:
<DTMF
tone.dtmf.level="-15"
tone.dtmf.onTime="50"
tone.dtmf.offTime="50"
tone.dtmf.chassis.masking="0"
tone.dtmf.stim.pac.offHookOnly="0"
tone.dtmf.viaRtp="1"
tone.dtmf.rfc2833Control="1"
tone.dtmf.rfc2833Payload="127"
/>
I am somewhat doubtful that the DTMF setting are at issue here. I say that
because whether through an Ingate, PRI or sipxbridge I have never seen this.
All the above does is indicate someone pressed a key a bunch of times.
Is a siptrace available?
Tony
_______________________________________________
sipx-users mailing list sipx-users@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
sipXecs IP PBX -- http://www.sipfoundry.org/
