Hi, our popular CLEC told us that a service they offer called 2-B channel transfer would let us receive a call on PRI into our PBX, flash their CO switch, dtmf an external number, flash, disconnect. The CO transfers the call to the external number after the call is released from our PBX.
Therefore we could front-end calls for another destination without using up two trunks on PRI's.
Now that we have a proposal into a client to do just this the CLEC tells us that this is false, 2-B channel only works between trunks in the same trunk group, not to external phone #'s.
Is there any product generally offered by a CLEC over PRI that does a transfer in the CO switch such that customer doesn't use up multiple trunks?
What service would one purchase to take calls, transfer elsewhere, and not use two trunks?
I learned recently that you can't do this with a PRI.
Centrex with POTS lines or T-1 Centrex will work depending on the CO Switch. I had a similar application. The common question I got was " what's the problem using 2 channels from the PRI"? There is no loop loss.
Mark
I am in agreement with MarkK here. Our resident CO gurus may want to kick in, but so far, the Lucent 5ESS does not offer this capability. If your CLEC is using a Nortel DMS switch, they might have another way to make this happen.
Do you have an area code and exchange for this customer availble (NXX-NXX)? We can at least take a stab at finding out what CO switch is being used so that you are headed in a better direction.
This sounds like a job for AnthonyH or Dexman. If they don't chime in soon, send them a PM.
Thanks Ed, Anthonyh, I couldn't remember who you got to help me out on this one, he's the man.
I'm out of brain cells. My dad would say "it's no disgrace to get old, just damn inconvenient".
Mark
2 B-Channel transfer is a 5ESS supported feature on ISDN PRI. The feature allows the customer pbx to request the CO to replace the talk path of a given call so that the call doesn't tie up 2 channels on the PRI (in fact it releases both channels).
refer to Telecordia document GR-2865 for details
Pete, this i done on a PRI with dids, not with BRI's? It may just not be something we offer, I ahve never come across it...thanks for the document info I will try to pull it
Correct, GR-2865 refers to ISDN PRI, Basic Rate circuits have a similar feature covered under GR-858.
23.5.6 Feature Operation
Initially there are at least two calls over the PRI between end-users and the controller. Each call uses a B-channel on the PRI. To be eligible for TBCT transfer, at least one of the calls must be in an answered state; it may have been initiated by the end-user or by the controller. The other call may be in an answered state, or, if initiated by the controller, it may be in a ringing state.
If the controller determines that two of the calls are to be transferred to each other, the controller sends a request for two B-channel transfer to the 5ESS® switch.
When the 5ESS® switch receives the request from the controller, it checks the validity of the message containing the request, the states of the calls to be transferred, the compatibility of the bearer capabilities of the calls, whether the PRI groups associated with the B-channels in the request are provisioned for the feature, whether the PRI groups are members of the same PRI serving group (see below for explanation of PRI serving group), whether interactions with other services or features should prohibit execution of the transfer, and other criteria. If any of the checks fail, an error message is sent to the controller, and the calls remain connected to the controller. If the checks pass, the 5ESS® switch performs the TBCT transfer operations. The two users' calls are then connected together at the switch, and the two B-channels, which were previously occupied on the PRI by the users' calls to the controller, are released. After the transfer, the two B-channels are available for new calls to the controller.
The multiple interface capability allows transfers between B-channels that are on different PRI groups, that is, B-channels that are associated with different D-channels. A PRI serving group is introduced with this feature. A PRI serving group consists of members, each of which is a PRI group. All members of a PRI serving group must be on the same SM.
This feature also provides two counters that are available to control requests and usage of the feature on a per PRI group basis. If the two B-channels are from different PRI groups, one counter is incremented -- that of the PRI group with the B-channel that requests the transfer. One counter records the number of TBCT requests per 10-second interval. If the number of TBCT requests reaches a provisionable limit within the time interval, all additional requests are denied in the current time interval. The second counter records the number of active transfers, that is, the number of transferred calls that are currently active. If the number of active transfers reaches a provisionable limit, all subsequent TBCT requests are denied. (It is also possible for the number of active transfers to exceed the limit, for example if the limit is lowered while there are active transfers on the interface.) When a sufficient number of transferred calls are cleared, such that the number of active transfers no longer equals or exceeds the limit, new TBCT requests will be allowed. An audit is provided to ensure the integrity of the active transfers counter.
Traffic measurements are provided to record feature usage on a requesting PRI group basis. The number of valid TBCT requests, the number of successful TBCT transfers, the number of overflows of the active transfers counter, and the number of overflows of the transfer requests per current interval counter are measured.
As an enhancement to Feature 99-5E-3261 (Two B-Channel Transfer [TBCT] on PRI), the TBCT Notification to Controller feature, 99-5E-7268, sends notification to the controller when the transferred call is cleared. A non-call associated NOTIFY message is used. When the Notification to Controller feature is active, the switch assigns a Call Tag to the TBCT call at the time of the transfer. This Call Tag is unique at the PRI interface serving the controller. If the multiple PRI option is subscribed, the Call Tag is unique across the PRI serving group. The switch retains an association between the Call Tag, the transferred call, and the controller's interface throughout the duration of the transferred call.
The base TBCT feature, 99-5E-3621, passed the number of active and available transfers to the controller in the DISCONNECT message at the time of the transfer. When the TBCT NTC feature, 99-5E-7268, is active on the PRI group, the DISCONNECT message will also include the Call Tag assigned to the transferred call. The switch sends a NOTIFY message to the controller, when the TBCT transferred call clears. The NOTIFY message contains two notifications. One notification contains the Call Tag value to alert the controller that the TBCT call associated with the Call Tag has cleared and a second notification provides the updated number of active and available transfers on that PRI group.
The Notification to Controller feature is provided on a per PRI GROUP basis.
NOTE: Notification to Controller can be subscribed only if TBCT is active.
sorry for the messy post above, it didn't copy and paste well from the 5ESS manual (I have an older 'DynaText' copy of the manual) but it does a pretty thorough job of explaining the feature from a Lucent 5E perspective
We have a DMS-500 in the office so I've never seen something like that done.
in the office?
DMS-500 supports it too
That's odd. I've never actually run across anyone using, or even mentioning that feature in any of the installs I've done in that switch. :confused:
(I'm a CO tech, not a CPE vendor)
From my copy (pdf) of 'Translations 10 of 25'
DMS-100 Family
North American DMS-100
Translations Guide Volume 10 of 25
Data, ISDN, and Internet Services Part 3 of 3
7-20 Datafilling NI0 NI-2 PRI 7-20 7-20
PRI two B-channel transfer
Ordering codes
Functional group ordering code: NI000015
Functionality ordering code: NI000018
Release applicability
NA009 and up for Notification to controller and TBCT across D-channels.
NA008 and up for base TBCT feature.
Prerequisites
PRI two B-channel transfer has no prerequisites.
Description
PRI two B-channel transfer (TBCT) capability on National ISDN 2 (NI-2)
primary rate interface (PRI) trunks gives customer premises equipment
(CPE) more efficient use of trunk connections for calling traffic. With a
private branch exchange (PBX), or a network of PBXs, multiple call forward
and transfers are typical. When a forwarded or transferred call is set up
using two B-channels in a PRI trunk, the original channels can be released
and made available for future calls. The controller can be an intelligent
peripheral (IP), a private branch exchange (PBX), or other customer premise
equipment (CPE).
The CPE requests TBCT by sending a Facility message with a TBCT invoke
component in it to the Service Switching Point (SSP). If the SSP determines
that all validation criteria pass (for example, bearer capabilities and feature
interactions), then the SSP performs TBCT. The SSP responds with a
facility message that acknowledges the TBCT request.
All billing, including AMA billing, proceeds as if the TBCT transfer never
occurred.
Note: For per trunk signaling (PTS) trunks, the system denies TBCT during
the alerting phase. PTS trunks outpulse digits to the far end. TBCT disrupts
digit outpulsing, and the call cannot be completed.
Operation
PRI TBCT provides the capability to connect two indenpendent calls (the
calls may be on the same or different NI-2 interfaces between the controller
and the DMS) at the request of a controller. The system sends this request to
the SSP in the form of a Q.931 FACILITY message containing an invoke
component coded with a TBCT operation identifer.
Translations table flow
The PRI two B-channel transfer tables are described in the following list:
• Table SVPRIGRP defines Serving PRI Groups. All PRIs that belong to
the same Serving PRI Group are viewed as terminating at the same
destination. When requesting TBCT across D-channels, (that is, across
PRI interfaces), the two PRIs must be in the same Service PRI Group for
the request to be accepted. Through table SVPRIGRP, the operating
company can create up to 1022 serving PRI groups. A serving PRI group
is identified through the key PGRPID in table SVPRIGRP. This key is
referenced in table LTDEF to identify logical terminal identifiers (LTID)
that belong to a serving PRI group.
• Table LTDEF defines the service profile of an ISDN logical terminal
(LTID). The key to this table is an LTID. An LTID consists of a logical
terminal group (LTGRP) from table LTGRP and a logical terminal
number (LTNUM) in a range of 1 to 1022. This table must be datafilled
to provision primary rate interface (PRI) and basic rate interface (BRI)
services. The type of service requested is distinguished by the
LTCLASS field, for example, BRAFS, PRA, and BRAMFT. Based on
the type of service, logical terminal specific options can be datafilled
against a particular LTID. The PGRPID field in table LTDEF associates
the LTID with a Serving PRI Group.
• Table LTDATA (Logical Terminal Data) stores service-related data
associated with the logical terminal identifier (LTID [field LTDKEY]),
which is the key to this table. Field LTDKEY consists of three parts: the
logical terminal group (subfield LTGRP), logical terminal number
(subfield LTNUM), and logical terminal data type (subfield
DATATYPE). The TBCT option must be datafilled in table LTDATA for
the TBCT request to be accepted. In the case of TBCT across
D-channels, TBCT must be datafilled on both PRIs involved in the
transfer.
• Table BCCOMPAT (Bearer Capability Compatibility) defines the bearer
capability (BC) pairs that are compatible with one another. For example,
a terminal with a 300-baud modem BC can communicate with a terminal
with a 300- to 1200-baud modem BC. TBCT calls are accepted only if
the two calls involved in the transfer have compatible bearer capabilities.
hope that helps. it seems like if you didn't build out the switch you wouldn't need to know about TBCT because it is automatically included (?)
Where have you been hiding, Pete? We sure could have used you several times this year. Don't be a stranger.
Nope.
Switch provisioning is done by other departments. I'm the person who does the final turn-up with CPE vendors.
My co-worker said that we had a customer about 2 years ago who used that feature.
Ed, I've been hiding in the phone room
Have client in NJ. opening office next week US lec vender. will have split t1,120 did, trunk transfer listed above. 11 channels pri, B-channel. Same client uses identical setup in Del. office. Headaches during setup but makes client happy.------------John
I think this used to be called take back and transfer or transfer connect. A star and a number would be dialed and the call could be transferred to anouther destination.
Hi, thanks a lot for this information, I got too busy to reply. But it was useful. Our vendor, XO, initially told us this would not work because a centrex-style transfer would only work between PRI trunks in the same trunk group. But then they discovered a new feature they had just released where this WOULD work and we could do a trunkless centrex style transfer to any DID, anywhere.
Unfortunately by the time we worked this out with XO, our client decided the solution involved too much technical risk so they changed their plans. >
Anyway, it's nice to know that XO now offers this feature for future times when we want to front end calls for someone else and not tie up two trunks.
dhostteller, what does XO call the feature. It would be nice to tell them when their order dept says they don't have that feature available. I know they call it "call transfer" on their normal lines coming out of a channelbank to pots lines, but I don't know if they call it something else on PRI service. (It allows you to route call to anouther destination without tying up lines and having to remain on the call like 3 way does). thanks
I just posted a question on the Nortel Board with the same scenario because my client has a Nortel MICS. This post helped greatly. I have tried to get our Net Ops guys to tell me this will work for one of my clients but they won't commit.
We have a DMS 500 but they have told me that they believe TCBT will not work on the OC-3 Interface.
Can anyone shed light on this? Pete?
Wsabee
Welcome to the board, Jason!
I can't understand how a PRI being transported across an OC ring can have any impact on the PRI (or the PRI Group's) features. Even though I work with 5ESS, and haven't used the Two B-Channel Transfer feature, I've never experienced any impacts on PRIs (or PRI Groups) that were simply caused by the PRI being transported across an optical carrier.
Even though your question is on-topic, this is an older thread. Since your question is associated with DMS-500, and you've also mentioned this in your similar thread over in the Nortel forum, I advise that we continue this discussion in
your other thread that is already in progress over in the Nortel forum. :thumb: