Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

IP Office 500 - Latest 7.0.23 - Hunt Group Queue Issue 1

Status
Not open for further replies.

zanewoodfield

IS-IT--Management
Jul 19, 2011
7
NZ
We have upgraded today to 7.0.23, everything appeared to be fine, until the following occurred:

Call comes into huntgroup, user answers fine. Call QUEUES in huntgroup, user gose to answer and there is no voice BOTH ways. I turned off queuing and the issue appears to go away.

We are running a SIP trunk for calls, but the issue only appears to happen for the callcentre who have queuing turned on.

Has anyone experienced this? Direct calls routed to extensions for the same users (without hunt group) all work fine. Is there an issue with the 7.0.23 upgrade I cant find documented, or do you think there is a config issue?
 
DO oyu have faxes attached to the system?
If not then turn off "re-invite"

If you have faxes then this will break the faxing.

You could try to see what happens when you turn off re-invite.
I would love to know what happens, i have the same issue on 7.0


BAZINGA!

I'm not insane, my mother had me tested!
 
Thanks. Long story re faxing, in the end we moved it off the Avaya, so have turned off re-invite. will post findings shortly. From my reading the new codec lockdown tickbox is supposed to help with this, but have disabled and will let you know in a few hours.
 
I am curious :)


BAZINGA!

I'm not insane, my mother had me tested!
 
Ok. Disabled re-invite and everything appears to work without issue. Support team have had many queued calls successfully answered with no silence issues. Am guessing its a 1 way codec change without notification causing the issue?

The only other thing which was changed was turning off the REFER option, but I don't expect that this had any bearing on the result.

Thanks very much for your help! spent all of yesterday under duress trying to figure it out.
 
So it worked :)
Avaya tells me that this is not a bug but that the sip trunk is using NAT twice which is not supported.
I think all of us need to log this as a bug!


BAZINGA!

I'm not insane, my mother had me tested!
 
Interesting as I route direct from sip provider to avaya no natting at all! Experience would tend towards bug in this version, as no issue in 6.5 and no configuration Changes made. Love the fact that source IP is correct now for outgoing sip headers.
 
That was my issue too.
It works fine on 6.1 but not on 7.0


BAZINGA!

I'm not insane, my mother had me tested!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top