Within any environment where Nortel PBX's will be used to trunk to another vendors PBX, a Q.SIG trunk is usually used. Once there becomes a need to add multiple facilites, there also becomes a need to network them together. For this, there are several options within the Q.SIG standard that allow for call pruning and path replacement. Nortel does this internally using a feature called TRO-CM (Trunk Route Optimization - Call Modification). This feature was part of an enhancement to Release 25.40.
In a Q.SIG scenario, there is a prompt within the D-Channel that controls if this is available, and how it is used. The options are CTR1 and CTR2 within the PR-TRIGS field of the D-Channel. (If you want to read the Feature Doc, search for Document Release Note MSC-0603-021 within the Helmsman web site)
A D-Channel configured would look like this
In a nutshell, CTR1 and CTR2 tell the PBX which system in a Transfer process is responsible for triggering a Path Replacement request. CTR1 states the PBX from which the call originally started is responsible for the request; CTR2 defines the final destination as the responsible party. The transfer notification is handeled in the out-of-band signaling provided by the D-Channel.
Think of it like you have three sites: A, B, and C. If A calls B, and B then transfers the call to C, route optimization would need to take place to prune the unecessary call path. This is especially important in VoIP applications, where a call that is not optimized will take up unnecessary bandwidth, talk paths, as well as add additional encodings to the call, thereby reducing the quality of the call.
With CTR1 defined in the above scenario, as soon as Site C answers, Site A would send a path replacement request to Site C. This process would then create a seperate talk path between Site A and C. Call processing would then shift the talk path from the inital path thru B to the direct talk path between A and C. As soon as the shift occurs, the old call path thru B is torn down. CTR2 does the same thing, only C is responsible for making the request. Nortel states in Documentation that CTR2 is the default when setting this type of D-Channel. I have had personal experience where the option does not even populate when you build the D-Channel, but can be added during the programming or as a change.
CTR1 and CTR2 are mutually exclusive, and MUST be configured consistent across your entire network. If in the same scenario above Site A was configued as CTR2 and Site C was configured as CTR1, path replacement would never happen. I have asked Nortel which is better, and have yet to get a response that makes sense. Since CTR2 is the default, one would assume that is the better way to go.
NOTE: Path replacement is only true when a transfer key is used. Using a conference key to make the transfer will not trigger any type of path replacment, since the PBX requests and uses a conference resource on the PBX where the key was pressed. Even if that caller releases themselves from the call, the conference resource in the middle is still being used to connect the other two callers. This is especially important if users are not sure what happens when they transfer a call, or you tried to save space on a 2008 set and only programmed a conference key.
Hope this is helpful to someone out there,
Scott M.
In a Q.SIG scenario, there is a prompt within the D-Channel that controls if this is available, and how it is used. The options are CTR1 and CTR2 within the PR-TRIGS field of the D-Channel. (If you want to read the Feature Doc, search for Document Release Note MSC-0603-021 within the Helmsman web site)
A D-Channel configured would look like this
Code:
PR_TRIGS DIV 2 3
CNG 2 3
[b]CTR2 2 3[/b]In a nutshell, CTR1 and CTR2 tell the PBX which system in a Transfer process is responsible for triggering a Path Replacement request. CTR1 states the PBX from which the call originally started is responsible for the request; CTR2 defines the final destination as the responsible party. The transfer notification is handeled in the out-of-band signaling provided by the D-Channel.
Think of it like you have three sites: A, B, and C. If A calls B, and B then transfers the call to C, route optimization would need to take place to prune the unecessary call path. This is especially important in VoIP applications, where a call that is not optimized will take up unnecessary bandwidth, talk paths, as well as add additional encodings to the call, thereby reducing the quality of the call.
With CTR1 defined in the above scenario, as soon as Site C answers, Site A would send a path replacement request to Site C. This process would then create a seperate talk path between Site A and C. Call processing would then shift the talk path from the inital path thru B to the direct talk path between A and C. As soon as the shift occurs, the old call path thru B is torn down. CTR2 does the same thing, only C is responsible for making the request. Nortel states in Documentation that CTR2 is the default when setting this type of D-Channel. I have had personal experience where the option does not even populate when you build the D-Channel, but can be added during the programming or as a change.
CTR1 and CTR2 are mutually exclusive, and MUST be configured consistent across your entire network. If in the same scenario above Site A was configued as CTR2 and Site C was configured as CTR1, path replacement would never happen. I have asked Nortel which is better, and have yet to get a response that makes sense. Since CTR2 is the default, one would assume that is the better way to go.
NOTE: Path replacement is only true when a transfer key is used. Using a conference key to make the transfer will not trigger any type of path replacment, since the PBX requests and uses a conference resource on the PBX where the key was pressed. Even if that caller releases themselves from the call, the conference resource in the middle is still being used to connect the other two callers. This is especially important if users are not sure what happens when they transfer a call, or you tried to save space on a 2008 set and only programmed a conference key.
Hope this is helpful to someone out there,
Scott M.
