Problems with trunk to trunk transfers. 1

[Gumpus]

Any one have any pointers on how to touble shoot why I can't get a trunk to trunk transfer. I have an option 11 release 25. I have 6 COT's terminating to a universial trunk card. What I'm questioning is when I programed the first trunk I typed in XCOT vs XUT. Could this help explain why?

Thanks for listening, I'm all ears.

Gumpus

 

[Gumpus]

The RART Tables are all 0 for all routes, and the FTOP - set to FTLY, On the set doing the transfer - cls=FTTU has already been set up.

This site has 5 Loop start COT's and all 5 COT's are in their own individual route because the users want to see what lines are in use and what lines are ringing they are set up as HOT dials.

Any other suguestions?

Gumpus

 

[sureyyaayce]

Trunk-to-trunk calls
Metering of trunk-to-trunk calls using an outgoing CO trunk is not supported
if the trunk access code is a one- or two-digit access code. Otherwise, a meter
corresponding to the trunk access code of the metered trunk route is
incremented. Only three- and four-digit codes are supported for DNs or trunk
access codes.

 

[sureyyaayce]

X11 Features and Services
Operating parameters
Flexible Trunk to Trunk Connections is configured at a set level, by defining
the Class of Service (CLS) prompt in Overlays 10 or 11.
All existing telephone sets default to a Class of Service of Flexible Trunk to
Trunk Connections Unrestricted (FTTU) upon initial software conversion.
When new telephone sets are added and configured, they default to a Class of
Service of Flexible Trunk to Trunk Connections Conditional (FTTC).
In the Customer Data Block, Flexible Trunk to Trunk Connections Options
can be set to Trunk Barring Flexible Trunk to Trunk Connections (TBFT) and
Flexible Trunk to Trunk Connections Trunk Barring (FTTB) only when the
Trunk Barring is configured. Flexible Trunk to Trunk Connections Options
(FTOP) is set to the default, Flexible Trunk to Trunk Connections Restricted
(FRES), to maintain the existing functionality.
A telephone set with a Class of Service of Flexible Trunk to Trunk
Connections Restricted (FTTR) cannot initiate a Conference call to an
outgoing trunk, although it can be included in a conference. If this type of
telephone set is the last set to disconnect from the conference, the call is
ended. The established trunks are released.
If a conference is on hold and an additional telephone set attempts to join the
conference over a barred trunk route and through a telephone set that has
Class of Service set to Flexible Trunk to Trunk Connections Restricted
(FTTR), then Flexible Trunk to Trunk Connections does not permit a
consultation connection. This is as per the existing operation.
If more than two trunks are involved in a call and all internal calls drop from
the conference, Flexible Trunk to Trunk Connections does not affect the
Conference disconnection.
Multiple Appearance, Single Call Arrangement DNs allow a single call to be
active on the DN, regardless of its number of appearances. If the Single Call
Ringing DN is established in a call, another appearance of the DN can enter
into the call, if the Privacy feature is not in effect, by going off hook or by
pressing the Multiple Appearance Single Call DN key. Flexible Trunk to
Trunk Connections restrictions for Conference are applicable in such a case.ഊPage 1542 of 3134 Flexible Trunk to Trunk Connections
As per the existing operation, answer and disconnect supervision is a
requirement for Transfer and Conference.
Flexible Trunk to Trunk Connections does not support Basic Rate Interface
(BRI) telephone sets or Attendant Console operations.
Flexible Trunk to Trunk Connections supports Analog and ISDN trunks.
R2MFC and AC15 signaling is also supported. Flexible Trunk to Trunk
Connections does not support Service trunks, such as Recorded
Announcement (RAN), Paging (PAG), Dictation (DIC), Music (MUS), and
Automatic Wake Up Recorded Announcement (AWR).
Call Redirection features are not supported with Flexible Trunk to Trunk
Connections.
With Flexible Trunk to Trunk Connections, unless the Trunk to Trunk
Connection feature is configured, two outgoing trunk connections are
blocked for Transfer and unsupervised Conference.
Customer Controlled Routing (CCR), Meridian Link, and Application
Module Link (AML) applications are not affected by the Flexible Trunk to
Trunk Connections feature.
Note: When adding a new telephone set, the default Class of Service is
Flexible Trunk to Trunk Connections Conditional (FTTC). This could
impact an application’s ability to conference or transfer a call to an
outgoing trunk. In the case where this functionality is required, the Class
of Service must be changed on the set to Flexible Trunk to Trunk
Connections Unrestricted (FTTU).
Flexible Trunk to Trunk Connections blocks the initiation of Conference.
Applications, such as Break In, Barge In, Bridging, and Overriding, are not
supported.

 

[Gumpus]

As it turns out the root of the issue was the CO's were Loop start, once new GRD start trunks were installed trunk to trunk transferes were a go.

Thanks for all the help.

Gumpus

 

[justiceo]

This is a problem that we ran into also. You have to use ground start trunks on the Meridian PBX. Loop start trunks caused all sorts of problems on our end by not disconnecting calls right away. It would keep the port open for 3 or 4 minutes after the user had hung up on the remote end. Unfortunately Verizon doesn't inquire about this when they are provisioning circuits.

 

[acewarlock]

No phone company is going to inquire how you want your trunks or T1's unless they are the one's that are installing all the equipment in the PBX or Key System and are doing the entire engineering job, other wise you are talking to a clerk type person that just takes orders for phone lines.