Re: [asterisk-users] Terrible dahdi_test results
On Thu, May 15, 2014 at 12:28:44PM -0300, Mike Leddy wrote: > Hi Russ, > > I rebooted the machine loading dahdi_dummy in /etc/modules before > the /etc/init.d/dahdi. Unless you're using a relatively old version of dahdi, there's no separate module called dahdi_dummy. It is an alias to the main dahdi module (which you must have loaded, as all the card drivers depend on). -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Terrible dahdi_test results
Thanks for the suggestion Gareth, The span line I'm using is: span=1,1,0,ccs,hdb3,crc4 Its the same as used with the TE12xP that is normally used on this E1 line in production which is extremely stable. I did as you suggested using: span=1,0,0,ccs,hdb3,crc4 After a dahdi_cfg pretty much the same results: [May 15 17:35:24] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 17:35:24] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 17:35:32] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 17:35:36] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 17:36:01] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 17:36:05] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 17:36:12] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 17:36:13] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 17:36:21] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 17:36:21] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 17:36:25] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 Best regards, Mike On Thu, 2014-05-15 at 17:53 +0100, Gareth Blades wrote: > On 15/05/14 16:28, Mike Leddy wrote: > > Hi Russ, > > > > I rebooted the machine loading dahdi_dummy in /etc/modules before > > the /etc/init.d/dahdi. > > > > Now dahdi_test shows a nearly perfect score: > > > > # dahdi_test > > Opened pseudo dahdi interface, measuring accuracy... > > 99.998% 99.990% 99.998% 99.996% 99.998% 99.998% 99.997% 99.997% > > 99.998% 99.997% 99.998% 99.997% 99.998% 99.998% 99.997% 99.998% > > 99.997% 99.997% 99.997% 99.998% 99.997% 99.998% 99.998% 99.997% ^C > > --- Results after 24 passes --- > > Best: 99.998% -- Worst: 99.990% -- Average: 99.997188% > > Cummulative Accuracy (not per pass): 99.997 > > > > When I connect a live E1 to the card it does work but I get a fair > > number of: > > > > [May 15 15:10:39] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS > > (8) on D-channel of span 1 > > [May 15 15:10:42] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS > > (8) on D-channel of span 1 > > [May 15 15:10:43] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS > > (8) on D-channel of span 1 > > [May 15 15:10:43] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS > > (8) on D-channel of span 1 > > [May 15 15:10:43] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS > > (8) on D-channel of span 1 > > [May 15 15:10:45] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS > > (8) on D-channel of span 1 > > [May 15 15:11:01] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS > > (8) on D-channel of span 1 > > [May 15 15:11:01] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS > > (8) on D-channel of span 1 > > [May 15 15:11:06] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS > > (8) on D-channel of span 1 > > [May 15 15:11:12] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS > > (8) on D-channel of span 1 > > [May 15 15:11:12] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS > > (8) on D-channel of span 1 > > [May 15 15:11:12] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS > > (8) on D-channel of span 1 > > [May 15 15:11:13] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS > > (8) on D-channel of span 1 > > > > Resulting in: > > > > [May 15 15:10:34] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on > > D-channel of span 1 > > [May 15 15:10:39] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on > > D-channel of span 1 > > [May 15 15:10:43] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on > > D-channel of span 1 > > [May 15 15:10:44] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on > > D-channel of span 1 > > [May 15 15:10:45] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on > > D-channel of span 1 > > [May 15 15:11:13] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on > > D-channel of span 1 > > [May 15 15:11:17] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on > > D-channel of span 1 > > [May 15 15:11:22] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on > > D-channel of span 1 > > > > Not usable in production but getting a lot closer. > > > > Is there anything else that can be done to improve this ? > > > > Best regards, > > > > Mike > > > > > > Check your span= line in you configuration. If your telco is providing > clocking and you are set to generate it yourself then they go out of > sync which generally causes errors like these. If you are set to be the > clock master try changing it to see if it improves. It should either > improve or not work at all. > -- _ -- Bandwidth
Re: [asterisk-users] Terrible dahdi_test results
On 15/05/14 16:28, Mike Leddy wrote: Hi Russ, I rebooted the machine loading dahdi_dummy in /etc/modules before the /etc/init.d/dahdi. Now dahdi_test shows a nearly perfect score: # dahdi_test Opened pseudo dahdi interface, measuring accuracy... 99.998% 99.990% 99.998% 99.996% 99.998% 99.998% 99.997% 99.997% 99.998% 99.997% 99.998% 99.997% 99.998% 99.998% 99.997% 99.998% 99.997% 99.997% 99.997% 99.998% 99.997% 99.998% 99.998% 99.997% ^C --- Results after 24 passes --- Best: 99.998% -- Worst: 99.990% -- Average: 99.997188% Cummulative Accuracy (not per pass): 99.997 When I connect a live E1 to the card it does work but I get a fair number of: [May 15 15:10:39] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:10:42] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:10:43] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:10:43] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:10:43] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:10:45] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:11:01] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:11:01] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:11:06] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:11:12] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:11:12] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:11:12] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:11:13] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 Resulting in: [May 15 15:10:34] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 15:10:39] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 15:10:43] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 15:10:44] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 15:10:45] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 15:11:13] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 15:11:17] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 15:11:22] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 Not usable in production but getting a lot closer. Is there anything else that can be done to improve this ? Best regards, Mike Check your span= line in you configuration. If your telco is providing clocking and you are set to generate it yourself then they go out of sync which generally causes errors like these. If you are set to be the clock master try changing it to see if it improves. It should either improve or not work at all. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Terrible dahdi_test results
Hi Russ, Sorry I didn't send that... Here's a few runs: # cat /proc/interrupts | grep wc && sleep 1 && cat /proc/interrupts | grep wc 28:1682906 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi wcte11xp 28:1683913 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi wcte11xp = 1007 # cat /proc/interrupts | grep wc && sleep 1 && cat /proc/interrupts | grep wc 28:1690587 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi wcte11xp 28:1691594 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi wcte11xp = 1007 # cat /proc/interrupts | grep wc && sleep 1 && cat /proc/interrupts | grep wc 28:1695091 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi wcte11xp 28:1696100 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi wcte11xp = 1009 # cat /proc/interrupts | grep wc && sleep 1 && cat /proc/interrupts | grep wc 28:1700363 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi wcte11xp 28:1701370 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi wcte11xp = 1007 Best regards, Mike On Thu, 2014-05-15 at 10:13 -0500, Russ Meyerriecks wrote: > On Thu, May 15, 2014 at 9:10 AM, Mike Leddy wrote: > --- Results after 72 passes --- > Best: 99.401% -- Worst: 69.357% -- Average: 90.260025% > Cummulative Accuracy (not per pass): 92.402 > > I suspect it may not be good enough yet for production but a > step in the right direction :-) > > > What was the result of the /proc/interrupt test? How many interrupts did the > te110 fire in 1 second? > What happens if you rmmod the wct1xxp driver and ran dahdi_test against just > dahdi & dahdi_dummy modules? > > -- > Russ Meyerriecks > Digium, Inc. | Linux Kernel Developer > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > direct: +1 256-428-6025 > Check us out at: www.digium.com & www.asterisk.org > On Thu, 2014-05-15 at 10:13 -0500, Russ Meyerriecks wrote: > > On Thu, May 15, 2014 at 9:10 AM, Mike Leddy wrote: > --- Results after 72 passes --- > Best: 99.401% -- Worst: 69.357% -- Average: 90.260025% > Cummulative Accuracy (not per pass): 92.402 > > I suspect it may not be good enough yet for production but a > step in the right direction :-) > > > What was the result of the /proc/interrupt test? How many interrupts did the > te110 fire in 1 second? > What happens if you rmmod the wct1xxp driver and ran dahdi_test against just > dahdi & dahdi_dummy modules? > > -- > Russ Meyerriecks > Digium, Inc. | Linux Kernel Developer > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > direct: +1 256-428-6025 > Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Terrible dahdi_test results
Hi Russ, I rebooted the machine loading dahdi_dummy in /etc/modules before the /etc/init.d/dahdi. Now dahdi_test shows a nearly perfect score: # dahdi_test Opened pseudo dahdi interface, measuring accuracy... 99.998% 99.990% 99.998% 99.996% 99.998% 99.998% 99.997% 99.997% 99.998% 99.997% 99.998% 99.997% 99.998% 99.998% 99.997% 99.998% 99.997% 99.997% 99.997% 99.998% 99.997% 99.998% 99.998% 99.997% ^C --- Results after 24 passes --- Best: 99.998% -- Worst: 99.990% -- Average: 99.997188% Cummulative Accuracy (not per pass): 99.997 When I connect a live E1 to the card it does work but I get a fair number of: [May 15 15:10:39] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:10:42] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:10:43] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:10:43] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:10:43] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:10:45] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:11:01] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:11:01] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:11:06] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:11:12] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:11:12] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:11:12] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 [May 15 15:11:13] NOTICE[4017] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1 Resulting in: [May 15 15:10:34] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 15:10:39] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 15:10:43] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 15:10:44] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 15:10:45] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 15:11:13] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 15:11:17] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 [May 15 15:11:22] NOTICE[4017] chan_dahdi.c: PRI got event: Alarm (4) on D-channel of span 1 Not usable in production but getting a lot closer. Is there anything else that can be done to improve this ? Best regards, Mike -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Realtime integration: Unregistered clients showing as registered?
Hello,
Thank you for your response.
Actually, I managed to solve a part of the problem; as I use Kamailio to
handle authentication, problem was that even though authentication went ok
through Kamailio, Asterisk refused to accept messages from Kamailio. That's
why Asterisk sent the 401. I think I had incorrect values in the realtime
sippeers table rows, and also I had to add values to deny and permit
fields, which in fact were in the wrong order. So no wonder I was having
problems with authentication! (and yes, I do know how digest authentication
works ;))
I fixed the deny values to 0.0.0.0/0.0.0.0 and permit value to Kamailio ip.
Even after this I had problems having Asterisk accept the authentications.
Asterisk cli was saying:
ERROR[20605]: chan_sip.c:30790 build_peer: Bad ACL entry in configuration
line 0 : kamailioip:5060
... that was because I had tried to define kamailio ip with port, as
Kamailio and Asterisk are on the same machine, but removing the port solved
that (not sure but I guess it is good I use 5060 for Kamailio and 5070 for
Asterisk instead of vice versa, perhaps this solution wouldn't work then).
Then I found that I had to add values to fields: nat (to force_rport) and
defaultip (to 0.0.0.0), and only after that I got Asterisk to see the
registered peers. So now everything looks ok from both Asterisk and
Kamailio when it comes to authentication.
I still can't get calls going though, in the asterisk cli I get 'Everyone
is busy/congested at this time', so I'm going to continue investigating
that. If you guys have good advice for me at this time I'll be most happy
to take them.
cheers,
Olli
2014-05-15 17:17 GMT+03:00 Leandro Dardini :
> It is the way it works. First the phone sends a REGISTER without any
> password. Asterisk answers with a "Unauthorized" and provide a nonce to be
> used for the next registration attempt, using it to encrypt the password.
>
> Leandro
>
>
> 2014-05-14 13:12 GMT+02:00 Olli Heiskanen
> :
>
>>
>> Hello,
>>
>> After a small break from working on this, I got the idea of tcpdumping
>> the correct ports. What I see is REGISTER messages from Kamailio port to
>> Asterisk, which are replied with 401 Unauthorized. Why is this happening?
>> In my sippeers table the secret field has no value (tried both NULL and
>> empty string) and the added field sippasswd has the correct password for
>> the user.
>>
>> The above might be the cause of my problem, would anyone be able to
>> advice me to get to correct behaviour? Now Kamailio sees the clients as
>> registered, which would be wrong if Asterisk doesn't.
>>
>> cheers,
>> Olli
>>
>>
>>
>> 2014-04-24 11:27 GMT+03:00 Olli Heiskanen > >:
>>
>>
>>> Hello all,
>>>
>>> I've been testing a Kamailio Asterisk Realtime integration, and found a
>>> strange situation.
>>>
>>> My problem is that when using the integration, everything seems ok but
>>> Asterisk does not see the clients as registered. Kamailio and the clients
>>> report registered clients. Also calls fail.
>>>
>>> In Asterisk cli sip show peers shows nothing but for example realtime
>>> load sipusers name 660 shows the user data. Field regseconds has a value
>>> and fullcontact has value 'sip:660@127.0.0.1:5060' (kamailio ip:port as
>>> they are on the same machine).
>>>
>>> I have a very simple dialplan:
>>>
>>> [general]
>>>
>>> [default]
>>> exten => _XXX,1,NoOp(general : Dialed ${EXTEN})
>>> same => n,Dial(SIP/${EXTEN},3600,rt)
>>> same => n,Hangup
>>>
>>>
>>> Here's more on my problem and background to it, guys on the Kamailio
>>> list helped out but looks like I need to check my Asterisk configuration.
>>> https://www.mail-archive.com/sr-users@lists.sip-router.org/msg18555.html
>>>
>>> My goal is to have all clients in the asterisk database, asterisk (one
>>> at this point, several later) handling the calls and Kamailio as proxy. In
>>> Kamailio I have the WITH_MULTIDOMAIN directive on but I'm using only one
>>> domain 'testers.com'.
>>>
>>> I have Asterisk 11.8.1 and Kamailio 4.2.0-dev4 on CentOS 6.5, all are on
>>> the same rental virtual server. Clients are in my home network behind nat.
>>> In MySQL I have database asterisk with table sippeers, where I have
>>> clients added like this:
>>> INSERT INTO sippeers
>>> (name,defaultuser,host,sippasswd,fromuser,fromdomain,callbackextension,type)
>>> VALUES ('660', '660', 'dynamic', 'password', '660', 'testers.com
>>> ','660','friend');
>>>
>>> In this message there are some outputs and a sip trace of a register:
>>> https://www.mail-archive.com/sr-users@lists.sip-router.org/msg18558.html
>>>
>>> What I don't know is how to configure sip.conf, so far I've just been
>>> making guesses based on online examples and documentation.
>>> My current sip.conf looks like this:
>>>
>>> [general]
>>> bindport = 5070
>>> bindaddr = 127.0.0.1
>>> tcpbindaddr = 127.0.0.1:5070
>>> tcpenable = no
>>> limitonpeers = yes
>>> ;rtcachefriends = yes
>>> tos_sip=cs3
>>> tos_audio=ef
>>> realm = testers.com
>>>
>>> I've tried defini
Re: [asterisk-users] Call file problem, DelayedRetry/retrying spite MaxRetries: 0
Forgot to mention some important things.
Asterisk versions I have tried this one and got the error: 1.8.16 and
1.8.27.
"core show channels" will show 0-10 channels when this happens (the true
count), but the "core show calls" and the call counter for active calls
after "core show channels" will show a very high amount of calls
(150-250+), this during times when we'd not expect to have close to that
amount.
Googling a bit gives people with the same problem but no solutions, one
with asterisk 1.4 who also reports weird call/channel counts.
On 15 May 2014 13:34, Mikael Fredin wrote:
> I am using Realtime extensions as well, in case that would matter.
>
> Following problem arises from time to time, a call will successfully
> terminate:
>
> [May 14 14:31:41] VERBOSE[3274] pbx_realtime.c: -- Executing
> [t@project_init:1] Hangup("SIP/peer-2-2f7e", "")
> [May 14 14:31:41] VERBOSE[3274] pbx.c: == Spawn extension (project_init,
> t, 1) exited non-zero on 'SIP/peer-2-2f7e'
>
>
>
> This is the call file:
>
> Channel: SIP/peer-2/00numberhere
> CallerID: "" <+calleridhere>
> Extension: 123
> SetVar: someid=123
> Context: setup
> WaitTime: 30
> MaxRetries: 0
> RetryTime: 300
> Account: 123
> Priority: 1
>
>
> Some time after the call has hung up, the call file is still there and
> this is appended to the file:
> StartRetry: 20354 1 (1400070906) (My note: Wed May 14 14:35:06 CEST 2014)
>
> DelayedRetry: 20354 0 (1400070906) same time...
>
> DelayedRetry: 20354 0 (1400071206) five minutes...
>
> DelayedRetry: 20354 0 (1400071506) and so on...
>
> DelayedRetry: 20354 0 (1400071806) never deleting this file
>
> DelayedRetry: 20354 0 (1400072106) are we?
>
> DelayedRetry: 20354 0 (1400072406) nope
>
> DelayedRetry: 20354 0 (1400072706) waiting for someone
>
> DelayedRetry: 20354 0 (1400073006) to do manual work
>
>
>
>
> Asterisk log:
> [May 14 14:35:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're
> currently running '/var/spool/asterisk/outgoing/callfile'
> [May 14 14:40:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're
> currently running '/var/spool/asterisk/outgoing/callfile'
> [May 14 14:45:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're
> currently running '/var/spool/asterisk/outgoing/callfile'
> [May 14 14:50:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're
> currently running '/var/spool/asterisk/outgoing/callfile'
> [May 14 14:55:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're
> currently running '/var/spool/asterisk/outgoing/callfile'
> [May 14 15:00:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're
> currently running '/var/spool/asterisk/outgoing/callfile'
> [May 14 15:05:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're
> currently running '/var/spool/asterisk/outgoing/callfile'
> [May 14 15:10:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're
> currently running '/var/spool/asterisk/outgoing/callfile'
>
>
>
>
> Asterisk code:
>
>if (o->retries <= o->maxretries) {
> now += o->retrytime;
> if (o->callingpid && (o->callingpid == ast_mainpid)) {
> safe_append(o, time(NULL), "DelayedRetry");
> ast_log(LOG_DEBUG, "Delaying retry since we're
> currently running '%s'\n", o->fn);
> free_outgoing(o);
> } else {
> /* Increment retries */
> o->retries++;
> /* If someone else was calling, they're presumably
> gone now
>so abort their retry and continue as we were...
> */
> if (o->callingpid)
> safe_append(o, time(NULL), "AbortRetry");
>
> safe_append(o, now, "StartRetry");
> launch_service(o);
> }
> return now;
> }
>
>
>
>
> Sure, I could just disable the retry check and add :
> if (FALSE) {
> And it will always expire should this occur...
>
> But I'm not sure if this is a good idea or not, and it would be nice not
> having to do that on every upgrade.
>
>
> Anyone have experience with what's going on?
>
> The file can be written to, since safe_append seems to be able to write to
> the file.
>
> This only happens once in a while, which makes it hard to track down.
>
>
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Terrible dahdi_test results
On Thu, May 15, 2014 at 9:10 AM, Mike Leddy wrote: > > --- Results after 72 passes --- > Best: 99.401% -- Worst: 69.357% -- Average: 90.260025% > Cummulative Accuracy (not per pass): 92.402 > > I suspect it may not be good enough yet for production but a > step in the right direction :-) > What was the result of the /proc/interrupt test? How many interrupts did the te110 fire in 1 second? What happens if you rmmod the wct1xxp driver and ran dahdi_test against just dahdi & dahdi_dummy modules? -- Russ Meyerriecks Digium, Inc. | Linux Kernel Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA direct: +1 256-428-6025 Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk 1.8 and calendar intergration
On 15 May 2014 16:03, Ishfaq Malik wrote: > Hi > > I'm using asterisk 1.8.25.0 on CentOS 6. > > I have compiled it with all the calendar modules: > *CLI> module show like calendar > Module Description > Use Count > res_calendar.soAsterisk Calendar integration4 > > res_calendar_ews.soAsterisk MS Exchange Web Service Calenda 0 > > res_calendar_caldav.so Asterisk CalDAV Calendar Integration 0 > > res_calendar_exchange.so Asterisk MS Exchange Calendar Integratio 0 > > res_calendar_icalendar.so Asterisk iCalendar .ics file integration 0 > > 5 modules loaded > > I'm trying to integrate this with a new calendar I've created on an > existing Google account but can't get it to work. > > I've tried ical with the ical url from the calendar settings and I've > tried caldav using > https://www.google.com/calendar/dav//events/ as the url but it > just won't work. > > I've added events in the next couple of hours with reminders on the > calendar that I'm referencing but the asterisk just wont pick up the events: > *CLI> calendar show calendar ishcal > Name : ishcal > Notify channel: SIP/ > Notify context: > Notify extension : > Notify applicatio : Playback > Notify appdata: tt-weasels > Refresh time : 1 > Timeframe : 3600 > Autoreminder : 10 > Events > -- > *CLI> > > > The firewall on this machine is pretty permissive but I even turned that > off for a while to see if that was the problem but it had no effect. > > I've reconfirmed the Google credentials and I've also tried making the > calendar public but I never see any events that I have added. I have set > reminders on the events themselves as I know they wont show without this. > > > > Can anyone give me any pointers on where to look to debug as I'm > struggling a touch right now. > > Thanks in Advance > > Ish > > Additionally, I've done a tcpdump on the server and can see 2 way traffic to 173.194.66.105 -- Ishfaq Malik Department: VOIP Support Company: Packnet Limited t: +44 (0)845 004 4994 f: +44 (0)161 660 9825 e: i...@pack-net.co.uk w: http://www.pack-net.co.uk Registered Address: PACKNET LIMITED, Duplex 2, Ducie House 37 Ducie Street Manchester, M1 2JW COMPANY REG NO. 04920552 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Asterisk 1.8 and calendar intergration
Hi I'm using asterisk 1.8.25.0 on CentOS 6. I have compiled it with all the calendar modules: *CLI> module show like calendar Module Description Use Count res_calendar.soAsterisk Calendar integration4 res_calendar_ews.soAsterisk MS Exchange Web Service Calenda 0 res_calendar_caldav.so Asterisk CalDAV Calendar Integration 0 res_calendar_exchange.so Asterisk MS Exchange Calendar Integratio 0 res_calendar_icalendar.so Asterisk iCalendar .ics file integration 0 5 modules loaded I'm trying to integrate this with a new calendar I've created on an existing Google account but can't get it to work. I've tried ical with the ical url from the calendar settings and I've tried caldav using https://www.google.com/calendar/dav//events/ as the url but it just won't work. I've added events in the next couple of hours with reminders on the calendar that I'm referencing but the asterisk just wont pick up the events: *CLI> calendar show calendar ishcal Name : ishcal Notify channel: SIP/ Notify context: Notify extension : Notify applicatio : Playback Notify appdata: tt-weasels Refresh time : 1 Timeframe : 3600 Autoreminder : 10 Events -- *CLI> The firewall on this machine is pretty permissive but I even turned that off for a while to see if that was the problem but it had no effect. I've reconfirmed the Google credentials and I've also tried making the calendar public but I never see any events that I have added. I have set reminders on the events themselves as I know they wont show without this. Can anyone give me any pointers on where to look to debug as I'm struggling a touch right now. Thanks in Advance Ish -- Ishfaq Malik Department: VOIP Support Company: Packnet Limited t: +44 (0)845 004 4994 f: +44 (0)161 660 9825 e: i...@pack-net.co.uk w: http://www.pack-net.co.uk Registered Address: PACKNET LIMITED, Duplex 2, Ducie House 37 Ducie Street Manchester, M1 2JW COMPANY REG NO. 04920552 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk 1.8.22
It's very likely someone scanning your asterisk for extensions to use for dialing out through your asterisk. Secure your asterisk and maybe create extensions that aren't practically possible to find through scanning. Save logs from your asterisk of whenever an extension is called (if that is an option) and you will probably see them scanning from 1-1000 or more. This is very common unfortunately, because too many asterisks are waiting to be hacked by automated scripts.. /Mikael On 12 May 2014 23:43, motty cruz wrote: > Hello, > recently I have seen spike in attacks on my asterisk server, this is what > I get on the LCD of my phone: 201@76.220.5.205 > > or calls from 1000 sip1000@76.2230.5.205, > > have any idea on how to stop this calls? > > Thanks, > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: >http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-users > -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Realtime integration: Unregistered clients showing as registered?
It is the way it works. First the phone sends a REGISTER without any
password. Asterisk answers with a "Unauthorized" and provide a nonce to be
used for the next registration attempt, using it to encrypt the password.
Leandro
2014-05-14 13:12 GMT+02:00 Olli Heiskanen :
>
> Hello,
>
> After a small break from working on this, I got the idea of tcpdumping the
> correct ports. What I see is REGISTER messages from Kamailio port to
> Asterisk, which are replied with 401 Unauthorized. Why is this happening?
> In my sippeers table the secret field has no value (tried both NULL and
> empty string) and the added field sippasswd has the correct password for
> the user.
>
> The above might be the cause of my problem, would anyone be able to advice
> me to get to correct behaviour? Now Kamailio sees the clients as
> registered, which would be wrong if Asterisk doesn't.
>
> cheers,
> Olli
>
>
>
> 2014-04-24 11:27 GMT+03:00 Olli Heiskanen
> :
>
>
>> Hello all,
>>
>> I've been testing a Kamailio Asterisk Realtime integration, and found a
>> strange situation.
>>
>> My problem is that when using the integration, everything seems ok but
>> Asterisk does not see the clients as registered. Kamailio and the clients
>> report registered clients. Also calls fail.
>>
>> In Asterisk cli sip show peers shows nothing but for example realtime
>> load sipusers name 660 shows the user data. Field regseconds has a value
>> and fullcontact has value 'sip:660@127.0.0.1:5060' (kamailio ip:port as
>> they are on the same machine).
>>
>> I have a very simple dialplan:
>>
>> [general]
>>
>> [default]
>> exten => _XXX,1,NoOp(general : Dialed ${EXTEN})
>> same => n,Dial(SIP/${EXTEN},3600,rt)
>> same => n,Hangup
>>
>>
>> Here's more on my problem and background to it, guys on the Kamailio list
>> helped out but looks like I need to check my Asterisk configuration.
>> https://www.mail-archive.com/sr-users@lists.sip-router.org/msg18555.html
>>
>> My goal is to have all clients in the asterisk database, asterisk (one at
>> this point, several later) handling the calls and Kamailio as proxy. In
>> Kamailio I have the WITH_MULTIDOMAIN directive on but I'm using only one
>> domain 'testers.com'.
>>
>> I have Asterisk 11.8.1 and Kamailio 4.2.0-dev4 on CentOS 6.5, all are on
>> the same rental virtual server. Clients are in my home network behind nat.
>> In MySQL I have database asterisk with table sippeers, where I have
>> clients added like this:
>> INSERT INTO sippeers
>> (name,defaultuser,host,sippasswd,fromuser,fromdomain,callbackextension,type)
>> VALUES ('660', '660', 'dynamic', 'password', '660', 'testers.com
>> ','660','friend');
>>
>> In this message there are some outputs and a sip trace of a register:
>> https://www.mail-archive.com/sr-users@lists.sip-router.org/msg18558.html
>>
>> What I don't know is how to configure sip.conf, so far I've just been
>> making guesses based on online examples and documentation.
>> My current sip.conf looks like this:
>>
>> [general]
>> bindport = 5070
>> bindaddr = 127.0.0.1
>> tcpbindaddr = 127.0.0.1:5070
>> tcpenable = no
>> limitonpeers = yes
>> ;rtcachefriends = yes
>> tos_sip=cs3
>> tos_audio=ef
>> realm = testers.com
>>
>> I've tried defining realm and domain values, but I lack proper
>> understanding of those. Can you guys help me out? Are there any other
>> configurations I need to check?
>>
>> Respectfully,
>> Olli
>>
>>
>>
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users
>
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Terrible dahdi_test results
Thanks again Russ, I did as you described: [ 1777.393179] dahdi: Version: 2.7.0.1 [ 1777.393995] dahdi: Telephony Interface Registered on major 196 [ 1789.943167] dahdi: Warning: Span DAHDI_DUMMY/1 didn't specify a spantype. Please fix driver! [ 1789.943865] dahdi_dummy: Trying to load High Resolution Timer [ 1789.943869] dahdi_dummy: Initialized High Resolution Timer [ 1789.943872] dahdi_dummy: Starting High Resolution Timer [ 1789.943876] dahdi_dummy: High Resolution Timer started, good to go [ 2816.078038] Setting up DMA (write/read = 2000/2200) [ 2816.078054] Controller version: 24 [ 2816.07] FALC version: [ 2816.080284] TE110P: Setting up global serial parameters for E1 FALC V1.2 [ 2816.080775] TE110P: Successfully initialized serial bus for card [ 2816.084698] Found a Wildcard: Digium Wildcard TE110P T1/E1 There is a significant improvement: # dahdi_test Opened pseudo dahdi interface, measuring accuracy... 79.256% 99.401% 86.288% 95.736% 77.951% 94.636% 87.010% 97.638% 90.234% 97.651% 97.648% 91.744% 90.541% 92.671% 91.090% 91.118% 95.832% 96.503% 83.753% 97.642% 98.419% 81.845% 92.441% 99.142% 96.645% 88.332% 77.918% 97.651% 87.029% 69.357% 98.153% 89.980% 93.939% 86.579% 78.785% 98.497% 77.916% 82.414% 96.838% 97.061% 99.392% 94.414% 97.094% 99.095% 90.329% 97.678% 90.087% 93.631% 99.130% 97.379% 94.361% 97.653% 97.670% 77.946% 78.312% 95.465% 84.429% 97.640% 78.185% 97.910% 77.938% 78.314% 89.535% 83.030% 85.246% 84.128% 74.614% 87.055% 90.382% 79.477% 97.096% 90.822% ^C --- Results after 72 passes --- Best: 99.401% -- Worst: 69.357% -- Average: 90.260025% Cummulative Accuracy (not per pass): 92.402 I suspect it may not be good enough yet for production but a step in the right direction :-) Timer Stats Version: v0.2 Sample period: 10.013 s 10014, 9027 modprobe init_module (dahdi_dummy_hr_int) I will test it on a live E1 soon. Best regards, Mike On Wed, 2014-05-14 at 16:53 -0500, Russ Meyerriecks wrote: > On Wed, May 14, 2014 at 3:41 PM, Mike Leddy wrote: > Hi Eric, > > I plugged an E1 into the card and it doesn't make any > difference. > > > Check to see if the card is interrupting 1000 times per second with > something like: > cat /proc/interrupts | grep wc && sleep 1 && cat /proc/interrupts | > grep wc > > > You could also try manually compiling dahdi_dummy by commenting it > back in, in the file: > drivers/dahdi/Kbuild > Then modprobe dahdi_dummy > This module forces the use of the high res timers > > > -- > Russ Meyerriecks > Digium, Inc. | Linux Kernel Developer > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > direct: +1 256-428-6025 > Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Call file problem, DelayedRetry/retrying spite MaxRetries: 0
I am using Realtime extensions as well, in case that would matter.
Following problem arises from time to time, a call will successfully
terminate:
[May 14 14:31:41] VERBOSE[3274] pbx_realtime.c: -- Executing
[t@project_init:1] Hangup("SIP/peer-2-2f7e", "")
[May 14 14:31:41] VERBOSE[3274] pbx.c: == Spawn extension (project_init,
t, 1) exited non-zero on 'SIP/peer-2-2f7e'
This is the call file:
Channel: SIP/peer-2/00numberhere
CallerID: "" <+calleridhere>
Extension: 123
SetVar: someid=123
Context: setup
WaitTime: 30
MaxRetries: 0
RetryTime: 300
Account: 123
Priority: 1
Some time after the call has hung up, the call file is still there and this
is appended to the file:
StartRetry: 20354 1 (1400070906) (My note: Wed May 14 14:35:06 CEST 2014)
DelayedRetry: 20354 0 (1400070906) same time...
DelayedRetry: 20354 0 (1400071206) five minutes...
DelayedRetry: 20354 0 (1400071506) and so on...
DelayedRetry: 20354 0 (1400071806) never deleting this file
DelayedRetry: 20354 0 (1400072106) are we?
DelayedRetry: 20354 0 (1400072406) nope
DelayedRetry: 20354 0 (1400072706) waiting for someone
DelayedRetry: 20354 0 (1400073006) to do manual work
Asterisk log:
[May 14 14:35:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're
currently running '/var/spool/asterisk/outgoing/callfile'
[May 14 14:40:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're
currently running '/var/spool/asterisk/outgoing/callfile'
[May 14 14:45:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're
currently running '/var/spool/asterisk/outgoing/callfile'
[May 14 14:50:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're
currently running '/var/spool/asterisk/outgoing/callfile'
[May 14 14:55:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're
currently running '/var/spool/asterisk/outgoing/callfile'
[May 14 15:00:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're
currently running '/var/spool/asterisk/outgoing/callfile'
[May 14 15:05:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're
currently running '/var/spool/asterisk/outgoing/callfile'
[May 14 15:10:06] DEBUG[20421] pbx_spool.c: Delaying retry since we're
currently running '/var/spool/asterisk/outgoing/callfile'
Asterisk code:
if (o->retries <= o->maxretries) {
now += o->retrytime;
if (o->callingpid && (o->callingpid == ast_mainpid)) {
safe_append(o, time(NULL), "DelayedRetry");
ast_log(LOG_DEBUG, "Delaying retry since we're
currently running '%s'\n", o->fn);
free_outgoing(o);
} else {
/* Increment retries */
o->retries++;
/* If someone else was calling, they're presumably
gone now
so abort their retry and continue as we were...
*/
if (o->callingpid)
safe_append(o, time(NULL), "AbortRetry");
safe_append(o, now, "StartRetry");
launch_service(o);
}
return now;
}
Sure, I could just disable the retry check and add :
if (FALSE) {
And it will always expire should this occur...
But I'm not sure if this is a good idea or not, and it would be nice not
having to do that on every upgrade.
Anyone have experience with what's going on?
The file can be written to, since safe_append seems to be able to write to
the file.
This only happens once in a while, which makes it hard to track down.
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
