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!
 
assuming you are using IP trunking check the COS options of those trunks.

NO GOOD DEED GOES UNPUNISHED!
 
comparing the PRI trunk w/ the IP trunk COS's, everything matches. I am at a loss at the moment as to what it could be.

Any additional insight would be appreciated...
 
Have you configured the Feature DN's in the Cluster Assignment form?

Each system needs a feature DN much like the Cluster ID. Cluster Dialing works without it but Feature access across the cluster does not.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
Feature DN's are configured in this form. However, the feature DN's are of our "desktop monitor" (ex: 7*29) instead of the extension (ex: 7299). could that be the problem?
 
I do not understand your response.

- From the help Files said:
For the local element ("Local" is set to "Yes") enter a feature directory number. For a remote element, enter the feature directory number that corresponds to the local feature directory number of the remote element within the cluster.

[highlight]The local and remote feature directory numbers must be unique within the cluster and can be 1 to 7 digits in length. The directory number length must match the extension number length.[/highlight]



*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
the cluster element assignment form on DE is configured as follows:

Name, PBX#, CLEID, Local, Comments, Feature DN
NY, 2, 7999, N, newyork, 7*99
FL, 3, 7299, N, flor, 7*29
DE, 1, 7199, Y, Del, 7*19
 
OK,

The feature DN's may need to change. Before doing so I would run a little test. Try to set Call Forward I'm Here against a phone at a remote site. This should forward the remote phone to the local phone on an always basis. If it does not, then we need to consider changing the Feature DN's.

Specifically I am concerned with:
- from the help files said:
[highlight]Do not use # or * in the Feature DN number because they can cause networking problems between the elements.[/highlight]

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
ok, performed the call forward - i'm here on a phone at a remote site and it forwarded to the phone at the local site.
 
OK, That tells us the feature activation is good to go. No need to change the codes.

Next test would be to try and isolate which party on the conference is causing the issue. Instead of mapping out all the steps, I'll try to help you 1 step at a time. I've turned on email notification of posts to this thread to expedite my responses.

You've tried
Local set - Local Set - Local Set - Success

Now try
Local Set - Local Set - Remote Set - ???




*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
I appreciate your timely responses....
You've tried
Local set - Local Set - Local Set - Success

Now try
Local Set - Local Set - Remote Set - ???

.........Success.........

Here are additional steps and the results
Local set - Local PRI - Local PRI - Success
Local set - Local PRI - Remote PRI - Failure
Local set - Remote set - Local PRI - Success

- conferencing is functional on the 5330's until i use the remote controllers PRI circuit.
 
Ok, the Local Set - Remote Set Local PRI success tells us we are not having a problem with IP Trunking locally

The issue appears to be connecting the IP trunk on the remote system to the remote PRI.

Can a set on the remote system set up a conference in the way you are trying locally.

To remove confusion I will substitute Sys-A for Local and Sys-B for remote.

Sys-A PRI, Sys-A Stn, Sys-B Stn = Success when initiated from Sys-A Stn

How About

Sys-B PRI, Sys-B Stn, Sys-A Stn = ?????? when initiated from Sys-B Stn


*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
Can a set on the remote system set up a conference in the way you are trying locally

YES

How About

Sys-B PRI, Sys-B Stn, Sys-A Stn = ?????? when initiated from Sys-B Stn

YES

It appears that whenever I utilize the IP trunk w/ the remote systems PRI, conferencing fails.

Another test I just performed was a Sys-B Stn hotdesked into Sys-A. Stn-B could not conference when dialing out the Sys-B PRI from login location Sys-A. Stn-B also could not conference when utilizing Sys-A pri
 
Try giving the Sys-A Stn the same COS and COR as the IP Trunk on Sys-A and try a local conference again.

So far the COS of the IP trunks is the leading candidate.

Does the IP trunk have heve the option Public Trunk - Enabled? And if so, Why?

Can you export your COS and post it using Yousendit.com or some other easier method if it's available to you.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
Try giving the Sys-A Stn the same COS and COR as the IP Trunk on Sys-A and try a local conference again.

So far the COS of the IP trunks is the leading candidate.

Does the IP trunk have heve the option Public Trunk - Enabled? And if so, Why?
Sys-A Stn assigned COS/COR of IP Trunk. Local conference successful

under cos -- public trunk = NO

COS of PUBLIC TRUNK, LOCAL PRI, AND Sys-A Stn follows:
<let me know when downloaded so I may remove these files from the hosting site - thank you>



 
Got them.

Would have prefered .csv as I have Macro's in Excel for comparison purposes.

I'll skim and see if anything jumps out.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
CSV files worked much better thanks.

Bad news though, nothing really jumps out at me related to conferencing.

A couple of other things though.
ACD Silent Monitor Accept Enabled on PRI?
COV/ONS/E&M Voice Mail Port Enabled on IP Trunk?
Public Trunk Not Enabled On PRI?
Ringing Line Select Not Enabled on Station


One thought occurs to me. You might not be getting Proper Answer Supervision passed thru. To prove this theory, make the call out the remote system and don't try conferencing until 30-40 seconds have elapsed.




*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
BTW - I'm nearing my end of work day so I may be off line for a while.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
no worries... I had to leave for the day myself and just performing some catch-up here. We can definitely touch base tomorrow. I appreciate your help on this; I am stumped.

ACD Silent Monitor Accept Enabled on PRI?
This is set to NO on the PRI COS

COV/ONS/E&M Voice Mail Port Enabled on IP Trunk?
This is set to YES on the IP COS

Public Trunk Not Enabled On PRI?
This is set to NO on the PRI COS
I assume this should be set to YES

Ringing Line Select Not Enabled on Station
This is set to YES on the station COS

One thought occurs to me. You might not be getting Proper Answer Supervision passed thru. To prove this theory, make the call out the remote system and don't try conferencing until 30-40 seconds have elapsed.
Tried this.... still no conferencing. Also, the red HOLD button does not function when going out the remote PRI

(hope I don't confuse matters here, but...)Teleworker station (Sys-A Stn) assigned to Sys-A, logged in via hotdesk can conference and hold except when utilizing the remote PRI
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top