I’m using SIP phones all set to uLaw on a closed LAN. All calls are extension to extension for this application and there are no cards or external PSTN, etc.
When a call is placed direct from phone to phone, or from phone to asterisk to phone the call setups and there’s very little latency or delay in the audio coming to/from each end of the call.
However, when one extension calls a queue, it’s placed in the queue and then the queue rings one of the logged in extensions (again this is all extension to extension). The extension picks up the call.
At this point, the RTP sets up and the queue member (recieving end) can hear the caller, but the caller cannot hear the queue member right away. it takes maybe 3-5 seconds, then the both sides work well.
I have tried this with various phones, soft phones, etc. They’re all using the same codec. I’ve seen other posts similar to this situation, but many are going through firewalls, etc. I don’t have any of that here (all LAN, in fact same switch for all devices).
I’ve tried AsteriskNOW 1.0.2 (latest) and 1.4.6 and 1.4.16. I have not tried 1.4.23 yet.
Yes. For example one of my queue command look like this (I have 4 queues)…
[quote]exten = 2001,1,Answer()
exten = 2001,2,Queue(Out Lanes|r)
exten = 2001,3,Hangup() [/quote]
In case it matters, I have the “r” option defined as I want ringing to the calling phone NOT moh or announcements.
Should I consider something else? I do know if I take Answer away it screws up the “ringing” it should get, but I’m open to ideas and other options.
I should note, that after a bit more testing we’ve seen the delay in audio be erratic varying from only a second to 5 seconds where the caller doesn’t hear the recipient of the call. That variance in behavior seems strange to me.
rhyshaden.com/qos.htm section 1.4 has a great description of places where delay might occur. If you’re getting varied delay of between 1~5 seconds then it sounds like an underlying network issue rather than an Asterisk problem.
Understood, but the problem here is that this delay is only occuring when using queues. When we makea direct call either station to station (no asterisk) or via extension to extension (via asterisk) then we do not have this start-up delay in the audio.
So I’m not so sure it’s network related given that we cannot reproduce the problems in order scenarios.
I’ve never had a problem with SIP or OOH323 calls being made via Queue() but I’m using 1.6.x
I’m pretty sure that Queue() only calls Dial() anyway on the different channels listed in queue_members, so your problem does seem very odd and I can see why there’s a lack of replies.
I can only suggest going right back to basics… one clean Asterisk install, two phones, try and dial between each other then queue one of them and try to dial through queue(). If you still get the same problem then try ast 1.6 maybe…
[quote=“wimnat”]What other voip hardware/software are you using?
I’ve never had a problem with SIP or OOH323 calls being made via Queue() but I’m using 1.6.x
I’m pretty sure that Queue() only calls Dial() anyway on the different channels listed in queue_members, so your problem does seem very odd and I can see why there’s a lack of replies.
I can only suggest going right back to basics… one clean Asterisk install, two phones, try and dial between each other then queue one of them and try to dial through queue(). If you still get the same problem then try ast 1.6 maybe…
Sorry I can’t be more help.[/quote]
My prod setup will be a VoIP intercom (www.cyberdata.net) and PJSIP softphone rolled in our application. However we’ve tested with XLite as well. I’ll admit I haven’t exhausted every single angle, but we’re on very high quality LAN, etc.
I have not tried 1.6.x and maybe I should give it a whirl. My thought has been that since I’ve configured the “r” option on the queue() directive that possibly that’s influencing it, however I haven’t been able to determine that. Also was wondering if there’s something with bridging where Asterisk effectively has answered the call something is showing this lag in setup as it’s doing the packet bridging.
We plan on doing more testing in the coming week, so I’m going to probably take your suggestion of getting down to the most simple configuration possible and seeing what happens.