Subject: [Megaco] AW: ITU-T WP 2/16 - H.248.ICASCGEN

From: "VOITH, Thomas" <[email-masked]>
Date: Mon, 22 Mar 2004 13:05:49 +0100

Mr. McClure,

Your comments are welcome.

First, this structure of R2 Events Map in one string has been taken to
backwards compatible with the existing digitmap syntax.
The <.> has been taken as separator and in case not using any alternative,
this is easy to separate.
The R2 Events Map is also the result for easier handling of alternatives.
So you need to indicate, which of the alternative you have taken.
My feeling is that the decision tree is more comprehensible in this one
string structure.
Since it relates directly to the interface events/signals.

Depending on the control logic in the MGC, you could also use the R2 Events
Map 
section-by-section basis, so you could get the called PN just partially.
Also in case just next section is specified. 
Using one string syntax does not add too much overhead and you can escape
the scenario without
specifying whether the parameter maps fully, partially on a parameter basis.
I think it is sufficient to do it on the one string basis.

In respect your example in Q.462 5.1.2.2 i):
In this case you referring to an incoming scenario. 
In case the to be generated backward signal is depending on received digits
, 
you have to define a first section until the MGC can make the decision,
since only the MGC
have the knowledge of routing data.
Alternatively the decision upon a dedicated number range is fix, then you
can use the 
alternatives in ICASCGEN (decision branches).

I can understand that the it is desirable to separate the parts in multiple
parameters, but
in this case it has been preferred the easier one, since it does not burden
the MG to make
the "bin"-tree parameter separation.

Thank you for your comments, any further comments are welcome.

Kind regards

Thomas Voith

-----Ursprüngliche Nachricht-----
Von: McClure, Dan [mailto:[email-masked]]
Gesendet am: Freitag, 19. März 2004 22:23
An: [email-masked]
Cc: McClure, Dan
Betreff: ITU-T WP 2/16 - H.248.ICASCGEN

Mr. Voith,

I am Dan McClure, a systems engineer with Santera, a softswitch and
media gateway switching system manufacturer based in the U.S.

Congratulations on the H.248.ICASCGEN Generic CAS Register Signalling
Package proposal recently contributed in ITU-T WP 2/16. As compared
with H.248.ICASC, I found the ICASCGEN proposal is more flexible for
the implementation of various R2 country variants. With ICASCO, I
found a number of R2 country variants that could not be implemented
because of the limitation that a digit map can only be applied for a
destination number (in the "seq" parameter). ICASCGEN does not have
this limitation due to the clever R2 Events Map approach.

I've noted the following comments in the Draft Report of WP 2/16:
- D.397 needs more knowledge in the MGC
- No agreement could be made on the placement of the knowledge for CAS
   Register Signalling.

I have a few thoughts on the above points that I wanted to mention to
you:

An implementation using ICASGEN is required to parse the incoming
register signals twice, once in the MG to perform the collection, then
again in the MGC. This suggests an implementation with two digit
trees, one in the MG and another in the MGC. It is desirable that the
MGC not have to parse the digit string again.

I'm wondering if the digit tree (R2 Events Map) in the MG could be
constructed so that the MG could sort the incoming signals into
"bins", where each bin was assigned the logical meaning for the item
of data that the MGC digit tree would otherwise have to determine. I
believe this could also be done in a generic manner, where the MG did
not need to have knowledge of the actual logical meanings, only
knowledge that a particular signal in a sequence should be put into a
particular bin.

For example:

Assume that the MGC requires the following logical data for an
incoming R2 call:

- destination number
- calling subscriber category
- calling line identity

Assume that the MG supports up to 16 generic digit bins, and can sort
a received register signal into any one of the 16 bins as instructed
by the R2 Events Map.

In the logic of the MGC, and in the R2 Events Map, each data item
required for the incoming call is associated with a generic digit bin,
for example:

  bin1 is used to accumulate the destination number
  bin2 is used for the calling subscriber category
  bin3 is used for the calling line identity

When the incoming register signaling sequence is complete, rather than
reporting the raw signals in the order they occurred, the MG would report
the signals in a manner that indicated which generic digit bin the signal
was sorted to, rather than just the order that the signals were collected.

call example:
destination number is 77980123
calling subscriber category is Subscriber with priority ("2")
calling line identity is 82140293

MG collects two digits of the destination number, then collects the
calling party category, then collects the calling line identity, then
collects the remainder of the destination number.

Assuming backward signal A-6 is used to request both calling party
category and calling line identity, the order in which the signals
occurred might be expressed as "77<6>282130293F<1>980123F" in the
current ICASCGEN syntax. Rather than reporting the signals this way,
the MG reports them according to the digit bins.

Observed Events =<requestID> { icasgen/gdi{bin1="77980123F", bin2="2",
bin3="82140293F"}

The above syntax may not be the best, but illustrates the principle
I'm trying to explain. Upon receiving a Notify with the above, the MGC
can easily distinguish the destination number, calling subscriber
category, and calling line identity without having to re-parse the
digits using a digit tree.

Obviously this approach would require a syntax change in the R2 Events
Map to allow the MGC to specify the digit bin that a signal should be
stored to. My first thought was that the digit bin could be specified
whenever the backward request signal changed, however that approach
has a problem. For example, in Q.462 5.1.2.2 i), I find that where
an incoming international exchange is equipped to apply an incoming
half-echo control device and echo control signaling is to be used
rather than data fill, the incoming exchange sends the A-14 signal in
acknowledgement of the discriminating or language digit to determine
if it should include an incoming half-echo control device. The
response to A-14 will be either I-14 indicating that an incoming
half-echo control device is required, or the first digit of the
national number indicating that no incoming half-echo control device
is required. For this case, the digit bin for the received signal
cannot be specified when the backward signal is specified.

In other words, for the above case, a digit bin change must be
specified when a "branch" of the digit tree occurs, which can be
determined with certainty only when the response to the A-14 is
received, and cannot be determined when A-14 is specified as the
backward request. It may be that this is an unusual case. I think in
most cases the digit bin could be specified whenever the backward
request signal changes.

I do not have syntax details worked out for the R2 Events Map that
would support the suggested capability. I expect you can do a better
job of that than I could.

I hope these comments are useful to you.

Regards,

Dan McClure
Systems Engineer
Santera, a Tekelec company
www.santera.com
[email-masked]

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "VOITH, Thomas" <[email-masked]>
Date: Mon, 22 Mar 2004 13:05:49 +0100

Mr. McClure,

Kind regards

Thomas Voith

-----Ursprüngliche Nachricht-----
Von: McClure, Dan [mailto:[email-masked]]
Gesendet am: Freitag, 19. März 2004 22:23
An: [email-masked]
Cc: McClure, Dan
Betreff: ITU-T WP 2/16 - H.248.ICASCGEN

Mr. Voith,

For example:

- destination number

call example:

Regards,

Dan McClure
Systems Engineer