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 derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Conference Call button not functional 1

Status
Not open for further replies.

TecknowJoe

IS-IT--Management
Mar 16, 2010
32
US
Our site information:
3 locations (de, ny, fl)
3300's in each location

Our issue:
conference call button on 5330's do not function when trying to 3-way/4-way callers on a line. This only happens when we place an outbound call that is sent over the remote controller's PRI. If a call is made on the "home" controller, we can perform the conference function

I have verified under system options our max trunks/co in a conference (7 max at the moment). I have set the interconnect checking to "no". I even played with the COS options that allow conference calls and Public to Public transfers to no avail

can we get the conference button to work when dialing out the remote controller? any insight would be appreciated. thanks!
 
I must have been comparing your COS with a different Rev level.

IP Trunk should not be set to COV VM port
PRI Trunk should be set to public trunk.
Forget the others.

Considering your hold revelation I think we're on the right track with Answer Supervision. I don't remember if Pseudo-Timers can be engaged on PRI or if they only apply to analog trunks. Will check tomorrow.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
IP Trunk should not be set to COV VM port

Why wouldn't we set COV VM port to YES for the IP Trunk? Don't we want the VM system to uniquely identify the party receiving a message?

PRI Trunk should be set to public trunk

This I agree with and is easy enough to change.
 
With respect to the COV VM option. The IP trunk is not a COV VM Port. I'm intrigued by your assertion that it somehow changes the way it is displayed between phones. Please elaborate.

With respect to the Answer Supervision theory. I cannot find a way that a Pseudo Timer can be applied to either PRI or IP trunking.

I only know of 2 things that will prevent a call from being placed on hold. Answer Supervision and Record a Call. Do you have automatic record a call enabled?

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
With respect to the COV VM option. The IP trunk is not a COV VM Port. I'm intrigued by your assertion that it somehow changes the way it is displayed between phones. Please elaborate.

I am somewhat new to Mitel, so some of the knowledge i have is what I have read through help files and various other documentation. My understanding of the COS option was to display that information between VM systems (we do have resiliency and a backup VM system in Sys-B)

I only know of 2 things that will prevent a call from being placed on hold. Answer Supervision and Record a Call. Do you have automatic record a call enabled?
Record a call is set to NO in the COS for all sys-A, sys-A stn, and PRI/IP Trunks
 
I cannot think of a single reason why the COV option on IP trunks would help. I think it might be worthwhile to turn it off and see if it is somehow the source of the current issue. If not, turn it back on as it does not seem to be harming anything and I cannot guarantee it is not necessary for some purpose.

Time to get creative. I'm not sure if the following test will tell us anything but any data is useful at this point.

Add an entry in Sys-A ARS (digits don't matter. e.g. 9*9*9)
Point the digits at a route that goes to SYS-B.
on SYS-B Add ARS Digits that match and point them back at Sys-A but strip the digits and substitute an actual outbound number.

This will create a call that loops thru Sys-B but uses Sys-A PRI. I expect this call to fail due to Answer supervision issues but you never know.

If this type of programming is beyond your capabilities. Don't go there.



*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
maybe we are on to something here... When adding an entry to Sys-A or Sys-B, is the termination type ROUTE, LIST, or PLAN? What determines the appropriate setting? My assumption is:
ROUTE = will follow route assignment form
LIST = will follow route list assignment (optional) form
PLAN = will follow route plan assignment (optional) form

Under Sys-A's ARS, everything is set to ROUTE except...... those numbers that are dialed which are forced out of the remote system. These numbers are set to LIST

When I go to Sys-B's Route List Assignment, nothing is configured.

Could this be the cause?
 
False Lead, or False Hope IMO

A route is a single choice - Sys-A or Sys-B

A route List is multiple choice - Sys-A then Sys-B

A route Plan is a list based on time of day.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
Ok. I am holding off on doing the ARS only because I get lost once I reach the digit absorption part.
 
Might be a good time to engage Mitel tech support.

Sorry I couldn't help more. I would be very interested to know of the solution if/when you discover it.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
ok. thank you for the time. I will certainly post the resolution if we get one
 
Yes, you notice the discussion there regarding Supervision as well. In fact I was looking for that exact post as I remembered it but I was unsuccessful in finding it.

The main difference however is your scenario fails under conditions fully in the control of the Mitel. The Mitel is designed to use PRI trunks on a second controller via IP trunks. In fact, with a MCD Server you have no choice but to access remote trunks over IP Trunking.

I really think there is something wrong with your setup. Finding it could take quite a while.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
Here is the resolution:
Following the lead on this discussion:
I decided to change the following setting in COS of the IP Trunk: suppress simulated ccm after isdn progress

This setting was changed from YES to NO.

Conferencing and hold now works once the timer of the call starts on the IP phone.
 
I looked at that option as it was one that differed in your COS vs. mine. It didn't seem likely based on the description. Next time, I think I'll provide mine to test with as a proof of concept.

Thanks for letting me/us know.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
Hello

I had this a little while back and after an upgrade to MCD it
started to work

regards

glenn



CCNA,CCNP,CCVP
HP AIS
Full Mitel
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top