Setting the BACK DIGITS variable
m |
(→Compelled sequence and information exchange) |
||
Line 6: | Line 6: | ||
== Compelled sequence and information exchange == | == Compelled sequence and information exchange == | ||
+ | [[File:Casr2_fwd_bwd_diagram.png]] | ||
In most implementations, the information available from CAS R2 signaling is exchanged through compelled sequences of tones. A compelled sequence consists into the outgoing end first emitting a digit and the incoming end responding with a second digit. The outgoing end confirms reception of the incoming digit by stopping to emit, and waits for the incoming end to do so as well to initiate the next sequence. In a way, the outgoing end is mostly passive: it responds to incoming requests, except when the requests cannot be met, or for the first sequence. | In most implementations, the information available from CAS R2 signaling is exchanged through compelled sequences of tones. A compelled sequence consists into the outgoing end first emitting a digit and the incoming end responding with a second digit. The outgoing end confirms reception of the incoming digit by stopping to emit, and waits for the incoming end to do so as well to initiate the next sequence. In a way, the outgoing end is mostly passive: it responds to incoming requests, except when the requests cannot be met, or for the first sequence. |
Revision as of 15:13, 29 November 2011
The default CAS R2 scripts included with Toolpack present a way to configure the sequence of tone requests sent by the incoming end.
To learn how to set a CAS R2 variable in Toolpack, refer to the Setting CAS R2 variables article.
The digit meanings in this article are the ones defined in the CAS R2 ITU specification. Digit meanings may vary depending on the variant specification.
Compelled sequence and information exchange
In most implementations, the information available from CAS R2 signaling is exchanged through compelled sequences of tones. A compelled sequence consists into the outgoing end first emitting a digit and the incoming end responding with a second digit. The outgoing end confirms reception of the incoming digit by stopping to emit, and waits for the incoming end to do so as well to initiate the next sequence. In a way, the outgoing end is mostly passive: it responds to incoming requests, except when the requests cannot be met, or for the first sequence.
One way of representing such exchanges can be expressed as follows:
Called number: 4506558993 Outgoing: 4 5 0 6 5 5 8 9 9 3 Incoming: 1 1 1 1 1 1 1 1 1 6
In the previous example, the outgoing end first emits the first digit of the called number '4'. The incoming end responds with the '1' digit, which request the next called number digit. The exchanges goes on until the incoming end has received all the digits it needed, and closed the exchange with the '6' digit, which means the call was accepted.
The incoming end may (and will, most of the time) request the calling number and the calling party category as well:
Called number: 4506558993 Calling number: 4506559511 Calling party category: 1 (Subscriber without priority) Outgoing: 4 5 0 6 5 5 8 9 9 3 1 4 5 0 6 5 5 9 5 1 1 Incoming: 1 1 1 1 1 1 1 1 1 5 5 5 5 5 5 5 5 5 5 5 6
In this example, the incoming end requested the calling party category (using digit '5') after having received all the called number digits. Still using digit '5', it then requested the calling number. Once it was fully received, the incoming end accepted the call with digit '6'.
Here is a second example where the incoming send an extra '5' when gathering the calling number (The picture also shows the different CAS R2 concepts and TelcoBridges Cas R2 script BACK_DIGITS variable):
Called number: 4506558993 Calling number: 4506559511 Calling party category: 2 (Subscriber without priority)
Finally, here is a final example:
Called number: 4506558993 Calling number: 12345 Calling party category: 2 (Subscriber with priority) Outgoing: 4 5 0 6 5 5 8 9 9 3 2 1 2 3 4 5 F 2 Incoming: 1 1 1 1 1 1 1 1 1 5 5 5 5 5 5 5 3 6
In this final example, the incoming end sent one '5' too much, and the outgoing end responded with 'F' to mark the end of the calling number. Then, the incoming end sent the '3' digit which did two things: request the category again, and signify to the outgoing end that the next digit belongs to a different grouping (named "Group B"). Once the category was received, the incoming end accepted the call with the '6'.
The BACK_DIGITS variable
In the CAS R2 default scripts found in Toolpack, the BACK_DIGITS variable expresses the digits that must be emitted from the incoming end. A functioning BACK_DIGITS variable that complies with the second example of the last section would be:
BACK_DIGITS = "111111111555555536"
However, such a sequence has many problems. Firsthand, the called number may be invalid and the call should be refused. To let Toolpack handle the decision of accepting or refusing the call when in group B, the 'V' symbol is used. With the aid of tables found in the script, Toolpack will be able to find the appropriate digit to emit considering the acceptation or refusal of the call.
BACK_DIGITS = "11111111155555553V"
To simplify the variable contents, the 'A' symbol may be used. What it does is send the '5' digit until 'F' is received. The variable would be slimmer:
BACK_DIGITS = "1111111115A3V"
With such a string, the only thing to worry about is the length of the called number. If the called number length may vary, the number of '1's must match the longest possible number. In the case where the outgoing end receives a '1' when it has sent all its digits, the conventional way of handling this is for the outgoing end to not emit anything for a while, until the incoming end detects this condition and requests something else. In this case, the default scripts in Toolpack will handle this case gracefully and skip the remaining '1's found in the BACK_DIGITS variable.