Queue and Ring Group SIP handling / delays

Tags: #<Tag:0x00007f702575af20>

(Jeremy Schaeffer) #1

Not sure how to ask this, my basic question is for Ring Groups and Queues, if set to Ring All, when a call comes in asterisk sends out a invite to all the phones, but does it send out and connect to each one before moving to the next? For example if a call comes in, it first sends the invite to the fist one, waits for it to give a ack , then sends the invite to the next one, etc… or is it threaded where each phone is independently handled? If I have 16 phones in the queue/ring group, does asterisk first get all 16 ringing, then wait for one to pickup, then take down the other phones, then connect the call? It seems like for at least a Queue, when a call comes in it rings the phones (you can hear the delay in ringing because it sounds like a wave of ringing) but if you pickup the phone on one of them, it can take a ring cycle or so before all the phones (including the one you picked up) to stop ringing, and not until all the phones stop and a few seconds later does the call actually connect. Is this different between a ring group and a queue? Is this a resource issue where the system does not have enough resources to efficiently handle taking care of that many phones at the same time or because of network delays or possibly QoS as the system is not getting the SIP messages to/from the phone and it will not proceed the call until all 16 phones have acknowledged the SIP bye message (except for the answering phone)? At the core, is there a more efficient way of doing this to minimize the delay of the phones reacting to the incoming call?


Since nobody has chimed in with a more informed response…

I believe that it is threaded to an extent, but involves a message queue handler that while not waiting for responses for individual endpoints, is not parallel either. There is some processing time between the first device and last device being informed about any operation. Minimizing the number of devices in a queue/ring group/paging group will definitely improve subjective performance, and moving to a more powerful host platform may result in better performance.

Overall I’ve made a better experience on my uc60 for end users (including ring delays in queues/groups) by severely reducing the system load

  • Abandoning timed pages via module, and instead leveraging cron, ffmpeg, and multicast (why does a page consume 100% of one cpu core when ffmpeg can do the same with 3%?)
  • Limiting the number of users that use ucp (populating the call history or call events modules is ridiculously intensive and slow. Moving voicemail to email delivery)
  • Making strategies for ring groups/queues to limit the number of devices I’m ringing by splitting ring groups into a primary and secondary group, failing from one to the other on no answer. (This could likely be done in a single queue with predetermined penalties, but I’ve not experimented with this)

(Jeremy Schaeffer) #3

Thanks for your reply, in this case I am not using any timed pages, no UCP or Zulu, the only thing is they want the entire system of uses to be able to take incoming calls at any time. They run promotions where they have a large influx of calls at times and they want every employee to be able to log in and take a call. That is about 80 some users, but at any given time normally only about 15 of them are logged in to the ACD to take a call and they want it ring all, no tiers. But when a call comes in, it can take up to 11 seconds once they pickup the handset to before the audio is connected (and the phones to stop tinging), so that leads me to the question, if it runs in threads where each call to each phone is sequentially handled where a network delay or missed packet is causing it to delay as its getting to connecting the call or is there just no a enough processing to handle the threads as each of them is sending the CANCEL and one is proceeding the call. If the process is serial then I need to look at networking and QoS, but if the processing is parallel then its a server issue, or possibly both. I do see the system load spiking when a call comes in, so I assume its a VM issue where I need more cores rather than a networking issue as this is a hosted system that has multiple locations, but all locations have the same issue… Thanks!