7 thoughts on - Various Extensions Ring Once And Go To Voicemail

• Thats a while back, I think it tended to use zaptel or dahdi hardware as a timer, you may need to find a timing source as perhaps the clock in the VM is just going too fast

• Duncan:

  You may have it right-I took one phone and set the ring time to 60 seconds. I now get about 4 rings on that one.

  I wonder how I can change the timing source.

  Thomas M. Peters | Sr. Systems Administrator | tpeters@mcts.org
  Desk: 414.343.1720 | Helpdesk: x3400 or helpdesk@mcts.org
  Milwaukee County Transit System <http://www.ridemcts.com/>

  1942 N 17th Street | Milwaukee, WI 53205
  Check us out on Facebook<https://www.facebook.com/mcts> & Twitter <https://twitter.com/RideMCTS>

  From: asterisk-users We have an old Asterisk 1.8.7.0 system desperately need to keep alive for another 6 months or so. We had all kinds of hardware problems, so we virtualized it.

  Thats a while back, I think it tended to use zaptel or dahdi hardware as a timer, you may need to find a timing source as perhaps the clock in the VM is just going too fast

  Now, random extensions ring once and go straight to voicemail.

  I went to one of the affected extensions and changed the ring time from the default (20) to 26. Still one ring. I changed it to 30. Now I get two rings. Other extensions ring once or twice. After some time has gone by since this was first reported, all phones in my random sample ring only twice.

  As I trace a call to that extension through the log, I notice it setting the ring timer properly (I think) and then I see app_dial.c – SIP/1234-00001111 is ringing Then eventually
  app_dial.c: — Nobody picked up in 30000 ms

  But according to the timestamps, the time from the one event to the other is ten seconds!

  Here’s another example- call starts:
  [2019-01-14 08:17:33] VERBOSE[13311] pbx.c: — Executing [3327@cc-long-distance:1] ExecIf(“SIP/4704-00001265”, “0?Set(__RINGTIMER=0)”) in new stack
  . . .
  [2019-01-14 08:17:33] VERBOSE[13311] app_dial.c: — SIP/3327-00001266 is ringing
  . . .
  [2019-01-14 08:17:41] VERBOSE[13311] app_dial.c: — Nobody picked up in 20000 ms So again, the elapsed time is nowhere near 20 seconds.

  Another: This time the ring time has been set to 30 seconds (and I still get only 2 rings)
  [2019-01-14 08:41:54] VERBOSE[16008] pbx.c: — Executing [3327@cc-long-distance:1] ExecIf(“SIP/4704-00001304”, “1?Set(__RINGTIMER=30)”) in new stack
  . . .
  [2019-01-14 08:41:54] VERBOSE[16008] pbx.c: — Executing [s@macro-exten-vm:5] Set(“SIP/4704-00001304”, “RT=30”) in new stack
  . . .
  [2019-01-14 08:41:54] VERBOSE[16008] pbx.c: — Executing [s@macro-dial-one:30] Set(“SIP/4704-00001304”, “D_OPTIONS=trWw”) in new stack
  . . .
  [2019-01-14 08:41:54] VERBOSE[16008] app_dial.c: — SIP/3327-00001305 is ringing
  . . .
  [2019-01-14 08:42:05] VERBOSE[16008] app_dial.c: — Nobody picked up in 30000 ms

  So, after 9 seconds, it says “Nobody picked up after 30000 ms”???

  Is this some weirdness of Oracle VMs? Anybody have any advice for me?

  Additional information:
  FreePBX version 2.9.0.7
  PBX in a Flash Version 1.2 Daemon Status
  ********************************************************************
  * Asterisk * ONLINE * Dahdi * ONLINE * MySQL * ONLINE *
  * SSH * ONLINE * Apache * ONLINE * Iptables * OFFLINE *
  * Fail2ban * OFFLINE * IP Connect* ONLINE * Ip6tables * OFFLINE *
  * BlueTooth * ONLINE * Hidd * ONLINE * NTPD * ONLINE *
  * Sendmail * ONLINE * Samba * OFFLINE * Webmin * LOADING *
  * Ethernet0 * ONLINE * Ethernet1 * ONLINE * Wlan0 * N/A *
  ********************************************************************
  * Running Asterisk Version : Asterisk 1.8.7.0
  * Asterisk Source Version : 1.8.7.0
  * Dahdi Source Version : 2.5.0.1+2.5.0.1
  * Libpri Source Version : 1.4.12
  * Addons Source Version : 1.4.7
  ********************************************************************
  Voipserver on 10.10.141.251 – eth0
  Red Hat Enterprise Linux Server release 4.5 (Tikanga) :32 Bit Kernel: 2.6.18-92.1.6.el5

  Thomas M. Peters | Sr. Systems Administrator | tpeters@mcts.org
  Desk: 414.343.1720 | Helpdesk: x3400 or helpdesk@mcts.org
  Milwaukee County Transit System <http://www.ridemcts.com/>

  1942 N 17th Street | Milwaukee, WI 53205
  Check us out on Facebook<https://www.facebook.com/mcts> & Twitter <https://twitter.com/RideMCTS>

• Sent from my iPad

  In one version (and I can’t recall which) asterisk moved to an internal timing system, to avoid the hardware need.

  There should be quite a lot of discussion of it in the archives or perhaps voipinfo

  I don’t know if you can slow the VM processor speed? I am guessing it is counting something much faster than it used to

  Cheers Duncan

• *CLI> module show like timing Module Description                              Use Count  Status Support Level res_timing_dahdi.so            DAHDI Timing Interface                  
  0          Running              core res_timing_pthread.so          pthread Timing Interface                
  0          Running          extended res_timing_timerfd.so          Timerfd Timing Interface                
  1          Running              core
  3 modules loaded

      This will show you what module Asterisk is using for timing. You can try doing a noload on the two you do not need.

• SGVyZeKAmXMgd2hhdCBJIGdldDoNCg0KYXBieCpDTEk+IG1vZHVsZSBzaG93IGxpa2UgdGltaW5n DQpNb2R1bGUgICAgICAgICAgICAgICAgICAgICAgICAgRGVzY3JpcHRpb24gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBVc2UgQ291bnQNCnJlc190aW1pbmdfcHRocmVhZC5zbyAgICAgICAg ICBwdGhyZWFkIFRpbWluZyBJbnRlcmZhY2UgICAgICAgICAgICAgICAgIDANCnJlc190aW1pbmdf ZGFoZGkuc28gICAgICAgICAgICBEQUhESSBUaW1pbmcgSW50ZXJmYWNlICAgICAgICAgICAgICAg ICAgIDQNCjIgbW9kdWxlcyBsb2FkZWQNCg0KU28gd2hhdCB3b3VsZCB5b3Ugc3VnZ2VzdD8gKEFu ZCB0aGFua3MgaW4gYWR2YW5jZS4pDQoNCg0KVGhvbWFzIE0uIFBldGVycyB8IFNyLiBTeXN0ZW1z IEFkbWluaXN0cmF0b3IgfCAgdHBldGVyc0BtY3RzLm9yZzxtYWlsdG86dHBldGVyc0BtY3RzLm9y Zz4NCkRlc2s6IDQxNC4zNDMuMTcyMCB8IEhlbHBkZXNrOiB4MzQwMCBvciAgaGVscGRlc2tAbWN0
  cy5vcmc8bWFpbHRvOmhlbHBkZXNrQG1jdHMub3JnPg0KTWlsd2F1a2VlIENvdW50eSBUcmFuc2l0
  IFN5c3RlbSA8aHR0cDovL3d3dy5yaWRlbWN0cy5jb20vPg0KDQoxOTQyIE4gMTd0aCBTdHJlZXQg fCBNaWx3YXVrZWUsIFdJICA1MzIwNQ0KQ2hlY2sgdXMgb3V0IG9uIEZhY2Vib29rPGh0dHBzOi8v d3d3LmZhY2Vib29rLmNvbS9tY3RzPiAmIFR3aXR0ZXIgPGh0dHBzOi8vdHdpdHRlci5jb20vUmlk ZU1DVFM+DQoNCkZyb206IGFzdGVyaXNrLXVzZXJzIDxhc3Rlcmlzay11c2Vycy1ib3VuY2VzQGxp c3RzLmRpZ2l1bS5jb20+IE9uIEJlaGFsZiBPZiBDYXJsb3MgQ2hhdmV6DQpTZW50OiBNb25kYXks IEphbnVhcnkgMTQsIDIwMTkgNDowOCBQTQ0KVG86IGFzdGVyaXNrLXVzZXJzQGxpc3RzLmRpZ2l1
  bS5jb20NClN1YmplY3Q6IFJlOiBbYXN0ZXJpc2stdXNlcnNdIFZhcmlvdXMgZXh0ZW5zaW9ucyBy aW5nIG9uY2UgYW5kIGdvIHRvIHZvaWNlbWFpbA0KDQoNCk9uIDEvMTQvMTkgNDowMiBQTSwgRHVu Y2FuIFR1cm5idWxsIHdyb3RlOg0KDQpTZW50IGZyb20gbXkgaVBhZA0KDQpPbiAxNS8wMS8yMDE5
  LCBhdCAxMDozNCBBTSwgVGhvbWFzIFBldGVycyA8VFBldGVyc0BtY3RzLm9yZzxtYWlsdG86VFBl dGVyc0BtY3RzLm9yZz4+IHdyb3RlOg0KRHVuY2FuOg0KDQpZb3UgbWF5IGhhdmUgaXQgcmlnaHTi gJRJIHRvb2sgb25lIHBob25lIGFuZCBzZXQgdGhlIHJpbmcgdGltZSB0byA2MCBzZWNvbmRzLiBJ
  IG5vdyBnZXQgYWJvdXQgNCByaW5ncyBvbiB0aGF0IG9uZS4NCg0KSSB3b25kZXIgaG93IEkgY2Fu IGNoYW5nZSB0aGUgdGltaW5nIHNvdXJjZS4NCg0KSW4gb25lIHZlcnNpb24gKGFuZCBJIGNhbuKA
  mXQgcmVjYWxsIHdoaWNoKSBhc3RlcmlzayBtb3ZlZCB0byBhbiBpbnRlcm5hbCB0aW1pbmcgc3lz dGVtLCB0byBhdm9pZCB0aGUgaGFyZHdhcmUgbmVlZC4NCg0KVGhlcmUgc2hvdWxkIGJlIHF1aXRl IGEgbG90IG9mIGRpc2N1c3Npb24gb2YgaXQgaW4gdGhlIGFyY2hpdmVzIG9yIHBlcmhhcHMgdm9p cGluZm8NCg0KSSBkb27igJl0IGtub3cgaWYgeW91IGNhbiBzbG93IHRoZSBWTSBwcm9jZXNzb3Ig c3BlZWQ/IEkgYW0gZ3Vlc3NpbmcgaXQgaXMgY291bnRpbmcgc29tZXRoaW5nIG11Y2ggZmFzdGVy IHRoYW4gaXQgdXNlZCB0bw0KDQpDaGVlcnMgRHVuY2FuDQoNCg0KDQoqQ0xJPiBtb2R1bGUgc2hv dyBsaWtlIHRpbWluZw0KTW9kdWxlICAgICAgICAgICAgICAgICAgICAgICAgIERlc2NyaXB0aW9u ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVXNlIENvdW50ICBTdGF0dXMgICAgICBTdXBw b3J0IExldmVsDQpyZXNfdGltaW5nX2RhaGRpLnNvICAgICAgICAgICAgREFIREkgVGltaW5nIElu dGVyZmFjZSAgICAgICAgICAgICAgICAgICAwICAgICAgICAgIFJ1bm5pbmcgICAgICAgICAgICAg IGNvcmUNCnJlc190aW1pbmdfcHRocmVhZC5zbyAgICAgICAgICBwdGhyZWFkIFRpbWluZyBJbnRl cmZhY2UgICAgICAgICAgICAgICAgIDAgICAgICAgICAgUnVubmluZyAgICAgICAgICBleHRlbmRl ZA0KcmVzX3RpbWluZ190aW1lcmZkLnNvICAgICAgICAgIFRpbWVyZmQgVGltaW5nIEludGVyZmFj ZSAgICAgICAgICAgICAgICAgMSAgICAgICAgICBSdW5uaW5nICAgICAgICAgICAgICBjb3JlDQoz IG1vZHVsZXMgbG9hZGVkDQoNCiAgICBUaGlzIHdpbGwgc2hvdyB5b3Ugd2hhdCBtb2R1bGUgQXN0
  ZXJpc2sgaXMgdXNpbmcgZm9yIHRpbWluZy4gIFlvdSBjYW4gdHJ5IGRvaW5nIGEgbm9sb2FkIG9u IHRoZSB0d28geW91IGRvIG5vdCBuZWVkLg0KDQoNCg0KLS0NCg0KVGVsZWNvbXVuaWNhY2lvbmVz IEFiaWVydGFzIGRlIE3DqXhpY28gUy5BLiBkZSBDLlYuDQoNCkNhcmxvcyBDaMOhdmV6DQoNCis1
  MiAoNTUpODExNi05MTYxDQo

• If your Asterisk server is a VM it should not be using DAHDI as a timing source. The res_timing_timerfd.so module would probably be the best candidate. Make sure your /etc/asterisk/modules.conf loads the timerfd module (and make sure it was built or installed by your package).

• Subject: Re: [asterisk-users] Various extensions ring once and go to voicemail – Thomas Peters

  Ouch. Sounds like you’re maybe sitting with a hybrid package install setup and a partial source based install – did you setup this box yourself?

  It appears that the binaries of asterisk were compiled, then the source was deleted or the binaries that comprise your instance were installed from a package…

  You can probably build only timerfd, but it does imply running menuconfig (I think) and for that you need a properly configured Asterisk source tree, of the correct version you want.

  AFAIK it is a default, but as default, again AFAIK, res_timing_dahdi.so won’t get loaded, the pthread timer or timerfd will be used. Since you don’t even have the timerfd module, you are running by implication on timerfd.

  Ok… well scratch that theory then.

  As I said earlier, we have had very strange misbehaviour with Asterisk in virtually hosted environments, and after bitter experience resolved to run it only in real physical boxes as it seems to perform best there and be the most stable and reliable.

  All I might suggest is getting the latest asterisk source in the 1.8 series (1.8.32.2 if I’m not mistaken – we ran it for years) and compile it from scratch. But do not install it, e. g. if you do make install it will overwrite your current setup irretrivably.

  Rather, compile it, and then make actual physical copies of your current asterisk binary (/usr/sbin/asterisk, I think) and of your /usr/lib/asterisk/modules folder, -then- make install it. Start it up and see if it works better. If it is a success, great. If not, simply copy back your copied asterisk binary and copy back all the files in /usr/lib/asterisk/modules, and restart your old version which at least is working partially.

  Again, no guarantees, the fact that you apparently already have a disjointed setup (at least three asterisk versions?) might mitigate against this – your milage may vary and doing what I describe might also destroy your entire current setup.

  The reader must beware. It sounds as if you will need to recompile Asterisk from a known clean source to begin troubleshooting it anyway?

  Kind regards,

  Stefan

  —