John, How can you tell the duration on tcpdump? Yajie Sent from my BlackBerry device
-----Original Message----- From: John Van Ostrand <[email protected]> Date: Thu, 9 Jun 2011 16:55:37 To: <[email protected]> Subject: Re: [on-asterisk] Callers getting wrong extension I debugged more. Some callers get it all the time while others have no issue. I ran a tcpdump on a call and found that the DTMF tone was limited to about 50ms for one caller who had problems. That seems too short to me, when from my cell phone (which works) it's 200ms. On the 50ms tone I'm seeing several RTP Event packets and end-event packets. There are exactly 3 end packets for each digit, so it doesn't match your double-digit problem. Will the DMTF duration be a problem? ----- Original Message ----- > Hi John, > > Have you fixed your problem? I am curious to know. > as i mentioned in my previous email, this how i used tshark (command > line > of wireshark on linux) to troubleshoot the gateway > > > This what i captured when a user press a single digits "7" key > > > [root@elastix ~]# tshark -i any -R "rtpevent.end_of_event == true" > Running as user "root" and group "root". This could be dangerous. > Capturing on Pseudo-device that captures on all interfaces > tshark: Promiscuous mode not supported on the "any" device. > > 72.536647 x.x.x.x -> 192.168.1.100 RTP EVENT Payload type=RTP Event, > DTMF > Seven 7 (end) > 72.541644 x.x.x.x -> 192.168.1.100 RTP EVENT Payload type=RTP Event, > DTMF > Seven 7 (end) > 72.546863 x.x.x.x -> 192.168.1.100 RTP EVENT Payload type=RTP Event, > DTMF > Seven 7 (end) > > -------------------------the above three lines indicated the dtmf "7" > is > translated correctly into 1 digit 7 by my audiocodes gateway -------- > > 89.185885 x.x.x.x -> 192.168.1.100 RTP EVENT Payload type=RTP Event, > DTMF > Seven 7 (end) > 89.190908 x.x.x.x -> 192.168.1.100 RTP EVENT Payload type=RTP Event, > DTMF > Seven 7 (end) > 89.195740 x.x.x.x -> 192.168.1.100 RTP EVENT Payload type=RTP Event, > DTMF > Seven 7 (end) > 89.195xxx x.x.x.x -> 192.168.1.100 RTP EVENT Payload type=RTP Event, > DTMF > Seven 7 (end) > > -------------------------the above FOUR lines means the dtmf "7" is > NOT > translated correctly by my audiocodes gateway, it was translated into > two 7s > -------- > > Then the Ast will tell user invalid options. > > > > > > On Fri, May 20, 2011 at 1:47 PM, Douglas Pickett > <[email protected] > > wrote: > > > John, > > I've found that this can sometimes be an issue of the receive gain > > setting > > on your interface for the analog lines - too low or too high can > > reduce the > > accuracy of digit detection. Of course you also want to keep the > > transmit > > gain in line as well - too high and it seems to cause grief with the > > incoming tones, too low and people can't hear you. > > Regards, > > Doug. > > > > > > > > On 19/05/2011 3:56 PM, John Van Ostrand wrote: > > > >> Hi, > >> > >> We have a problem where *some* callers who dial an extension too > >> soon have > >> their digits ignored. For example, when the caller first hears the > >> voice > >> menu and dials 5102 right away, the system may only recognize the > >> 102, the > >> 02 or even just the 2. We think if they wait a few seconds longer > >> before > >> keying an extension they don't see the problem as often. > >> > >> This happens on incoming calls from analog lines. We had this issue > >> with > >> our past asterisk system but it seems worse now. In the past we > >> used a > >> Digium 4 port card, now we use a Cisco (Sipura) 8800 ATA. Asterisk > >> is > >> 1.6.0.26-FONCORE-r78 (yup, Trixbox.) > >> > >> Any ideas? > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > -- > Yajie -- John Van Ostrand CTO, co-CEO Net Direct Inc. 564 Weber St. N. Unit 12, Waterloo, ON N2L 5C6 Ph: 866-883-1172 x5102 Fx: 519-883-8533 Linux Solutions / IBM Hardware --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
