vicidial.org

Hi team,

i am facing an issue that sometime zoiper didnt ring while agent attempt login, agent have to retry 4 to 5 times to get call on zoiper. it is happening randomly with random agents almost twice a day. Any Help related to this issue will be highly appreciated.

1) Welcome to the Party!

2) As you are obviously new here, I have some suggestions to help us all help you:

When you post, please post your entire configuration including (but not limited to) your installation method (7.X.X?) and vicidial version with build (VERSION: 2.X-XXXx ... BUILD: #####-####).

This IS a requirement for posting along with reading the stickies (at the top of each forum) and the manager's manual (available on EFLO.net, both free and paid versions)

You should also post: Asterisk version, telephony hardware (model number is helpful here), cluster information if you have one, and whether any other software is installed in the box. If your installation method is "manual/from scratch" you must post your operating system with version (and the .iso version from which you installed your original operating system) plus a link to the installation instructions you used. If your installation is "Hosted" list the site name of the host.

If this is a "Cloud" or "Virtual" server, please note the technology involved along with the version of that techology (ie: VMware Server Version 2.0.2). If it is not, merely stating the Motherboard model # and CPU would be helpful.

Similar to This:

Vicibox X.X from .iso | Vicidial X.X.X-XXX Build XXXXXX-XXXX | Asterisk X.X.X | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Intel DG35EC | Core2Quad Q6600

3) Ringing requires valid, active, registration. Registration expires/renews at timed intervals based on settings in Asterisk and in the VOIP phone. But the firewall between the agent and the server will require activity on the "registration port" to keep that port open. If there is no activity for too long, the port will close. If the firewall/router setting for "how long do I keep rports open" is lower than the "registration time": The port will close before the re-registration occurs. Asterisk, however, will be blissfully unaware of this and send the call to that closed port. The router will discard the ring packet ... and the VOIP phone will not ring.

Test the theory: Have any agent whose phone does not ring UNregister and REregister (NOT just close the phone window and reopen it, UNregister!), then log in again. If that ALWAYS fixes the ring problem, then this is your issue.

Solution(s): Modify the VOIP phone registration timeout to a lower number (In Zoiper's settings) so re-registration occurs before the router's port timeout closes the port OR increase the amount of time the router keeps those rports open. Often the VOIP phone's registration timeout can be done in the Asterisk configuration file instead of the soft phone.

In all cases, however, this is an Asterisk question more than it is a Vicidial question (much larger community there). Also note that Zoiper speaks both SIP and IAX2, and it makes a difference which one is in use as the settings are different. Zoiper also has many versions and there are lots of videos/instruction sets online to alter settings.

Happy Hunting

Make sure phone is Register and rechable by Asterisk.

Run sip show peers and status must be OK , assuming qualify is set to yes.

Also verify the error on the console when this happen if agent device is not rechable by Asterisk you will get this messagew 'SIP' (cause 20 - Subscriber absent)

Thanks William for your precious time. PFB the installation method and cluster information.

Scratch installation
version 2.14b0.5
SVN 2975
DB schema 1520
Debian 8
Asterisk 11.22.0-vici
Cluster yes
DB Server Dell R630 E5-2678 v3 48 GB RAM (no virtualization dedicated to DB only)
web server x 1
Telephony servers are Virtual Machines on Proxmox
Total 10 Telephony servers.

Note : this issue is not from day 1. we have almost 800 concurrent agents on our system and it occurs with only 10-15 agents randomly and its resolved after asterisk reload for the time being but occurs again after sometime. i have tried unregister and registered trick but failed also the peers status shows up in sip show peers. we are using SIP with zoiper version 3.

ambiorixg12 wrote:Make sure phone is Register and rechable by Asterisk.

Run sip show peers and status must be OK , assuming qualify is set to yes.

Also verify the error on the console when this happen if agent device is not rechable by Asterisk you will get this messagew 'SIP' (cause 20 - Subscriber absent)

per ambiorixg12 : Please verify "OK" as opposed to "UNREACHABLE" when you "show peers" (DURING this problem, no other moment counts) and also see if there are log entries in asterisk that coincide with your problem.

aterminator wrote:i have tried unregister and registered trick but failed also the peers status shows up in sip show peers. we are using SIP with zoiper version 3.

Does this mean registration fails? Or does this mean they re-register and their phone still does not ring?

Does the asterisk CLI show an attempt to call them when they log in?

Does this happen on a single server or only on certain agents? Or on all servers and randomly on any agents? (A log of events at this stage is often required: If you decide this from memory, you're likely to lead yourself astray!)

williamconley wrote:per ambiorixg12 : Please verify "OK" as opposed to "UNREACHABLE" when you "show peers" (DURING this problem, no other moment counts) and also see if there are log entries in asterisk that coincide with your problem.

yes i have verified the status of peer and it was OK but softphone didnt ring on login attempt.

williamconley wrote:Does this mean registration fails? Or does this mean they re-register and their phone still does not ring?

they re-register their softphone and their phone still not ring.

williamconley wrote:Does the asterisk CLI show an attempt to call them when they log in?

No

williamconley wrote:Does this happen on a single server or only on certain agents? Or on all servers and randomly on any agents? (A log of events at this stage is often required: If you decide this from memory, you're likely to lead yourself astray!)

this is happening on random server and random agents.

i have checked in astguiclient logs listen.2018-12-21 and found that when this occurs it shows cause 18 but the zoiper is registered at that time because its status is showing OK in sip show peers.

aterminator wrote:

williamconley wrote:Does the asterisk CLI show an attempt to call them when they log in?

No

This is now your main focus.

aterminator wrote:

williamconley wrote:Does this happen on a single server or only on certain agents? Or on all servers and randomly on any agents? (A log of events at this stage is often required: If you decide this from memory, you're likely to lead yourself astray!)

this is happening on random server and random agents.

i have checked in astguiclient logs listen.2018-12-21 and found that when this occurs it shows cause 18 but the zoiper is registered at that time because its status is showing OK in sip show peers.

It shows cause 18 on ... the call it did not generate?

Please provide an example ... consider sip debug to get a more clear picture of what's going on.

And to be clear: You are using a SIP connection and not an IAX2 connection from zoiper (which speaks both, so I have to ask)?

How's your Average Server Load during these happenings? Does it ONLY happen when all your agents are online? Is it possible that this occurs during a "reload" since you have so many phones registered?

williamconley wrote:It shows cause 18 on ... the call it did not generate?

yes when the call did not generate the listen logs shows me cause 18 (user not responding)

williamconley wrote:How's your Average Server Load during these happenings? Does it ONLY happen when all your agents are online? Is it possible that this occurs during a "reload" since you have so many phones registered?

server load is normal at that time when issue arrives.

williamconley wrote:And to be clear: You are using a SIP connection and not an IAX2 connection from zoiper (which speaks both, so I have to ask)?

should i try some users on IAX2 ?

aterminator wrote:server load is normal

No such thing. Core count and average server load is a number (well ,average server load is three numbers actually). It's never "normal".

consider sip debug

just gonna skip that? it's the actual path to success. i'd recommend following that road.

williamconley wrote:No such thing. Core count and average server load is a number (well ,average server load is three numbers actually). It's never "normal".

Here is the load average
Load Average : 0.80 1.20 2.14

williamconley wrote:just gonna skip that? it's the actual path to success. i'd recommend following that road.

i am not gonna skip sip debugging. working to collect logs and share with you in a while .

aterminator wrote:Here is the load average
Load Average : 0.80 1.20 2.14

Progress. Now for the drill down that makes this information useful by being "in context".

The Load average is the "number of cores busy in 1/5/10 minutes of history". Thus Core Count is required to understand the load average. If you have Four Cores, the server was over 50% load 10 minutes ago. If you have two cores, it was in overload. But if you have eight cores ... it was still fairly busy 10 minutes ago, but not sweating.

Next stage: When did you check this load average? Was this WHILE there were agents experiencing the problem? Or was it ... 15 minutes later, when things died down a bit and one of them called in to complain (or you got the IM)? If it was 15 minutes later, and 10 minutes ago the server had literally double the load it had when you took the reading (2.14 10 minutes ago, 0.8 now), then 15 minutes ago it could have been at 4 or 8 and could have been in overload. NOT an exaggeration, it's not ordinarily a straight-line acceleration. The closer to overload it gets, the faster it rises and after overload it gets crazy, lol (I've seen Average Server Load in the high hundreds just a couple minutes after being at 50%).

Not giving you a hard time, seriously, merely pointing out how important the context for these number can be to determine their usefulness. We've had to (on several occasions) create a log of this value and have agents send in a screen shot so we could compare the time on their screen shot to the logged time values to determine that there was, indeed, a spike at that moment or NOT any spike at all (different problem, obviously).

A way to find out whether this is a red herring, or valuable piece of information.

williamconley wrote:The Load average is the "number of cores busy in 1/5/10 minutes of history". Thus Core Count is required to understand the load average. If you have Four Cores, the server was over 50% load 10 minutes ago. If you have two cores, it was in overload. But if you have eight cores ... it was still fairly busy 10 minutes ago, but not sweating.

I have 24 cores on this machine and my server never goes above 10 in load average either it is in 1/5/10 min load average.

I dont think this could be caused by a system high load, but it is well know that vicidial as any other system have an odd behaviour when there is a high load on the system.

Based on your hangup cause 18, this cause is returned when a called party does not respond to a call establishment message with either an alerting or connect indication within the prescribed period of time allocated. it is equivalent to a SiP 408-Reqeust Timeout reponse. which seems to be more some kind of networking issue, where the ZOIPER is not respopnding back to the Asterisk INViTE request to establish the call

ambiorixg12 wrote:I dont think this could be caused by a system high load, but it is well know that vicidial as any other system have an odd behaviour when there is a high load on the system.

Based on your hangup cause 18, this cause is returned when a called party does not respond to a call establishment message with either an alerting or connect indication within the prescribed period of time allocated. it is equivalent to a SiP 408-Reqeust Timeout reponse. which seems to be more some kind of networking issue, where the ZOIPER is not respopnding back to the Asterisk INViTE request to establish the call

Yes @ambiorixg12 you are right in this case i have detailed troubleshooting this error and find AMI logs as well as asterisk logs. PFB the logs of AMI listen and asterisk logs.
AMI Listen :
2019-01-10 13:15:34|Event: NewAccountCode
Privilege: call,all
Channel: SIP/cc101-00000004
Uniqueid: 1547108140.12
AccountCode:
OldAccountCode: cc101

Event: NewCallerid
Privilege: call,all
Channel: SIP/cc101-00000004
CallerIDNum: 0000000000
CallerIDName: ACagcW1547108100cc101cc101cc101cc101
Uniqueid: 1547108140.12
CID-CallingPres: 0 (Presentation Allowed, Not Screened)

|
2019-01-10 13:15:34|Event: PeerStatus
Privilege: system,all
ChannelType: SIP
Peer: SIP/cc101
PeerStatus: Registered
Address: 192.168.226.4:57079

|
2019-01-10 13:15:34|Event: SIP-Response
--
Cause: Registration Refused

|
2019-01-10 13:15:34|Event: HangupRequest
Privilege: call,all
Channel: SIP/cc101-00000004
Uniqueid: 1547108140.12
Cause: 18

Event: Hangup
Privilege: call,all
Channel: SIP/cc101-00000004
Uniqueid: 1547108140.12
CallerIDNum: 0000000000
CallerIDName: ACagcW1547108100cc101cc101cc101cc101
ConnectedLineNum: 0000000000
ConnectedLineName: ACagcW1547108100cc101cc101cc101cc101
AccountCode:
Cause: 18
Cause-txt: No user responding



########### PFB the Asterisk logs as well
WARNING[1181]: chan_sip.c:4038 retrans_pkt: Retransmission timeout reached on transmission 57220d780c18914a2abf60d96d713c43@10.200.73.23:5060 for seqno 102 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/ ... nsmissions
Packet timed out after 6399ms with no response
[Jan 10 13:30:32] WARNING[1181]: chan_sip.c:4067 retrans_pkt: Hanging up call 57220d780c18914a2abf60d96d713c43@10.200.73.23:5060 - no reply to our critical packet (see https://wiki.asterisk.org/wiki/display/ ... nsmissions).
[Jan 10 13:30:33] Really destroying SIP dialog '57220d780c18914a2abf60d96d713c43@10.200.73.23:5060' Method: INVITE

If the router at the zoiper location closes the port, the ring will fail. Set a keepalive value lower than what you presently have in Zoiper or increase the port timeout in the router to test.

williamconley wrote:If the router at the zoiper location closes the port, the ring will fail. Set a keepalive value lower than what you presently have in Zoiper or increase the port timeout in the router to test.

Thank you william for your precious time . will test on lower keepalive at zoiper end and get back to you shortly. Thanks