Impossible to hear subscribers with 20-subscribers in queue

Dears,

We faced to issue when in our Asterisk many peoples waiting in Queue our agents randomly cant hear callers. We read a lot so Asterisk does not have any restriction and mainly performance depend of server configuration but as we seen from experience more then 20 onetime call can affect to performance.

Please advice how we should fix this issue. Our configuration also very easy it is Answer and sending to Queue, in queue we using ringall.

Regards,
Komil

Maybe someone knew some standard configuration of Asterisk for good performance because as I see from experience mainly after 10 onetime calls system losing voice.

You need to work out what resource you are overrunning.

Assuming you are using sensible codecs, and real hardware, CPU and memory should not impose limits that low.

Hi David,

I am using VM and regarding codec parts I am using standard config like:

disallow=all
allow=alaw
allow=ulaw

After googling I see in my server I dont have codec.conf because it is standard installation with less customization. Please advise better performance configuration.

Thanks in advance.

A VM means you can’t assume you have adequate CPU, disk or network bandwidth.

This is likely to be a question of either addressing network issues, or tuning the VM to give an adequate share of the necessary resources, rather than how you configure Asterisk.

I am using ESXi and all my infrastructure based on it and never hopefully not faced to performance issue, can give more CPU to VM if needed, but strange for me is resources not loaded too much it more looks like some of my configs restricting the voice.

For example my dialplan very simple:
=> Answer ()
=> Playback(myfile)
=> Queue

Queue also very simple with rrmemory strategy but mainly silent became in start of Playback and Queue announce. When I am starting system out of working hours and doing many tests its always ok, after connecting many agents and receiving more then 10 onetime calls problem is starting.
On same time randomly all agents reconnecting

If the agents are being disconnected, you need to look at the logging to see which side is disconnecting, and if Asterisk, why. If Asterisk is crashing and restarting, you need the relevant back traces, but, if you system is straightforward, it won’t crash very often.

Generally, on a dedicated local network, and with a five year old, dedicated, blade server, the system will handle a lot more than 20 connections, and the failure mode, on overloading it, will likely be choppy voice, rather than disconnections. In fact, with what I believe t have only been mid-range blade servers, we had no trouble handling a lot more agents even though we built Asterisk with thread debugging enabled, which is known to give quite a large CPU hit.

I assume Asterisk can obtain more connections and agents but seems its not easy. I will tell you interesting thing in same physical server where working VMs we have Elastix which is working perfectly but I am expecting its tuned somehow. I read a lot about single CPU usage from Asterisk and now looking how to customize Asterisk to use all CPUs and memory. Would be nice to hear you experience

I did some test and find some difference between call where I haer subscriber and not hear.
Below three calls from user 202 to 101 in first one I can hear but on two others not. I see difference in RTP messages please pay attention to it. How to fix whats the reason?

– Executing [101@out:1] Dial(“SIP/202-00000000”, “SIP/101”) in new stack
== Using SIP RTP CoS mark 5
– Called SIP/101
– SIP/101-00000001 is ringing
> 0x7f7e7c00a510 – Strict RTP learning after remote address set to: 192.168.43.122:4046
– SIP/101-00000001 answered SIP/202-00000000
– Channel SIP/101-00000001 joined ‘simple_bridge’ basic-bridge
– Channel SIP/202-00000000 joined ‘simple_bridge’ basic-bridge
> Bridge d9a7f376-5fa9-4ba8-ba4c-b28b03260937: switching from simple_bridge technology to native_rtp
> Locally RTP bridged ‘SIP/202-00000000’ and ‘SIP/101-00000001’ in stack
> 0x7f7e7c00a510 – Strict RTP qualifying stream type: audio
> 0x7f7eac00a9c0 – Strict RTP learning after remote address set to: mypublicip:4036
> 0x7f7eac00a9c0 – Strict RTP switching to RTP target address mypublicip:4036 as source
> Locally RTP bridged ‘SIP/202-00000000’ and ‘SIP/101-00000001’ in stack
> 0x7f7e7c00a510 – Strict RTP switching source address to 192.168.15.12:4046
> 0x7f7e7c00a510 – Strict RTP learning complete - Locking on source address 192.168.15.12:4046
> 0x7f7eac00a9c0 – Strict RTP learning complete - Locking on source address mypublicip:4036
> Saved useragent “TсellSIP/3.19.21” for peer 202
– Channel SIP/202-00000000 left ‘native_rtp’ basic-bridge
== Spawn extension (out, 101, 1) exited non-zero on ‘SIP/202-00000000’
– Channel SIP/101-00000001 left ‘native_rtp’ basic-bridge
== Using SIP RTP CoS mark 5
> 0x7f7eac0395c0 – Strict RTP learning after remote address set to:mypublicip:4038
– Executing [101@out:1] Dial(“SIP/202-00000002”, “SIP/101”) in new stack
== Using SIP RTP CoS mark 5
– Called SIP/101
– SIP/101-00000003 is ringing
> 0x7f7e6800a4e0 – Strict RTP learning after remote address set to: 192.168.43.122:4048
– SIP/101-00000003 answered SIP/202-00000002
– Channel SIP/101-00000003 joined ‘simple_bridge’ basic-bridge
– Channel SIP/202-00000002 joined ‘simple_bridge’ basic-bridge
> Bridge f751622d-c9c8-4341-9c3a-3b56dd418794: switching from simple_bridge technology to native_rtp
> Locally RTP bridged ‘SIP/202-00000002’ and ‘SIP/101-00000003’ in stack
> 0x7f7eac0395c0 – Strict RTP learning after remote address set to:mypublicip:4038
> Locally RTP bridged ‘SIP/202-00000002’ and ‘SIP/101-00000003’ in stack
> 0x7f7eac0395c0 – Strict RTP qualifying stream type: audio
> 0x7f7eac0395c0 – Strict RTP switching source address to mypublicip:47764
> 0x7f7eac0395c0 – Strict RTP learning complete - Locking on source address mypublicip:47764
– Channel SIP/202-00000002 left ‘native_rtp’ basic-bridge
== Spawn extension (out, 101, 1) exited non-zero on ‘SIP/202-00000002’
– Channel SIP/101-00000003 left ‘native_rtp’ basic-bridge
== Using SIP RTP CoS mark 5
> 0x7f7eac059c00 – Strict RTP learning after remote address set to: mypublicip:4040
– Executing [101@out:1] Dial(“SIP/202-00000004”, “SIP/101”) in new stack
== Using SIP RTP CoS mark 5
– Called SIP/101
– SIP/101-00000005 is ringing
> 0x7f7e7000acb0 – Strict RTP learning after remote address set to: 192.168.43.122:4050
– SIP/101-00000005 answered SIP/202-00000004
– Channel SIP/101-00000005 joined ‘simple_bridge’ basic-bridge <05e35728-cc8e-48af-91c3-fac5cf4ed96b>
– Channel SIP/202-00000004 joined ‘simple_bridge’ basic-bridge <05e35728-cc8e-48af-91c3-fac5cf4ed96b>
> Bridge 05e35728-cc8e-48af-91c3-fac5cf4ed96b: switching from simple_bridge technology to native_rtp
> Locally RTP bridged ‘SIP/202-00000004’ and ‘SIP/101-00000005’ in stack
> 0x7f7eac059c00 – Strict RTP switching to RTP target address mypublicip:4040 as source
> Locally RTP bridged ‘SIP/202-00000004’ and ‘SIP/101-00000005’ in stack
> 0x7f7eac059c00 – Strict RTP learning complete - Locking on source address mypublicip:4040
– Channel SIP/202-00000004 left ‘native_rtp’ basic-bridge <05e35728-cc8e-48af-91c3-fac5cf4ed96b>
== Spawn extension (out, 101, 1) exited non-zero on ‘SIP/202-00000004’

Dears,

Hope my story will save life to someone in future. So main reason of slow response of console and asterisk was in DNS. Network Administrator assigned local DNS which is not responding and seems in asterisk response timeout (I assume) so after removing DNS system working as before after installation fast responding and good voice quality.
Thanks a lot for community and specially to David for support.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.