Subject: RE: [Megaco] R2 Subscriber Categories in H.248.29

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 20 Jul 2005 11:18:18 -0400

Upon reflection, you are right -- the off-hook example was a bad one.
The concern I have is that we are going to end up with hundreds of
additional values to be added.  This will make implementation very
unwieldy. The main argument from the Annex B proponents was exactly this
ballooning of values or packages.

I debate that there would be effort on only one side.  If you implement
a package or value in the MG, it MUST be recognized by the MGC and MUST
have the call processing updated in the MGC to handle it, otherwise why
bother? 

I will not oppose work to introduce additional values for the variants,
but I do oppose lumping them into what is intended to be a
variant-independent package.  If the values are to be added, then we
should have extension packages for each variant.  This will prevent
generating 120 versions of the ICASC package in a relatively short time,
and segment the national variants so vendors can implement the variants
they choose. I am not terribly inclined to introduce this to the ITU,
though I will be more than happy to help edit any proposals so as to fit
with ICASC.

Of course, the obvious advantage to having new packages for each variant
is that a package audit can reveal what variants are supported by the
MG!

Kevin

-----Original Message-----
From: Ryabin Aleksandr-A19776 [mailto:[email-masked]] 
Sent: Wednesday, July 20, 2005 10:56 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked]
Cc: Macchi Richard-E12538
Subject: RE: [Megaco] R2 Subscriber Categories in H.248.29

Kevin,

I'm sorry, but I'm failing to follow your logic in your first paragraph
as it conflicts with the second paragraph.

In the second paragraph below you say "MGC does not care" - "off-hook is
off-hook"
and I completely agree and this is exactly my point. 

But in the first you say MGC needs to interpret II-7. Why does it care
if it is II-7, or any other signal?
"Long Distance Payphone" is a "Long Distance Payphone" regardless of the
variant.
The fact it is mapped to II-7 in one, or to something else to another
should be transparent to MGC (like it is in case of "off-hook")

Bottom line it is our observation that for all national variants we have
examined so far we can hide all the variant differences using ICASC in
MG, if we can have all meanings defined for Subscriber Category and
Calling Party Reachability Status.

I agree that amount of work can be large if we are to examine all the
national variants out there, but in practice:

1. The number of possible meanings (vocabulary) for two values above is
limited 2. This does not have to be one time deal. It can be an ongoing
collaboration effort by different vendors going through amendments to
add new meanings as companies implement variants.
Another way is to consider having new meanings registered/added through
IANA.

IMHO it will dramatically increase portability and compatibility as in
many cases MGC and MG come from different vendors.

If a system needs support for a new national variant the effort is MUCH
less if this can be one side effort only (that is in case of ICASC MG
only, and in case of ICASGEN MGC only).

I'm sure there are companies out there who hit the same problem while
implementing using ICASC.
and have already compiled list of meanings for large chunk of national
variants.
Please speak up if you think this effort is beneficial, otherwise I hold
my silence.

Regards,
	Aleks

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Wednesday, July 20, 2005 10:16 AM
To: Ryabin Aleksandr-A19776; [email-masked]
Cc: Macchi Richard-E12538
Subject: RE: [Megaco] R2 Subscriber Categories in H.248.29

I don't think I agree with you here.  The MGC will still have to have
knowledge of what the particular value means, whether we explicitly
define it in the spec or not.  Because the MGC has to know the call
processing impacts of each value, whether it gets a translated value or
not in this instance becomes largely irrelevant.  II-7 is II-7, and the
call processing impact of that value is known to the MGC performing the
call processing -- not the MG which is detecting and reporting it.

This is similar to the difference between ground-start and loop-start
circuits.  Off-hook is off-hook, regardless of what you call it or the
actual physical process used to detect it.  While the MG can tell the
difference between the two, the MGC is only worried about the fact that
off-hook was detected and the call processing impact of that occurrence.
The meaning of off-hook in the MGC is based upon local requirements and
the current state of the circuit. The MGC must be aware that in a
particular state local requirements demand a particular behavior.  A
good example of this would be a glare condition.  Some localities demand
that the origination take precedence and some require the termination
take precedence.  The determination of this is made by the MGC.

I believe that the amount of work required to gather all the national
variant spares and include them in H.248.29 will be tremendously large,
not to mention the fact that there would be the question of package
segmentation, since we wouldn't want to mix national variants inside a
particular package.  This would lead to a large number of packages, all
defining what is, essentially, the same exact values with different
names. 

I disagree with the idea that this is "hacking" the package.  While I
agree that the ideal would be to have a unified set of signals/events to
represent the world-wide system, the fact that different countries have
defined different variants makes that ideal nigh upon impossible to
achieve. In fact, if the national variants all defined the same
occurrences as meaning the same things, then we might still have a
chance at making this work.  Unfortunately, every variant defines very
different things based upon the differing requirements from country to
country. Because of this, there are greatly diminishing returns in
breaking these out as separate, distinct values.  The state machines
from one variant to the next can and do vary, so the MGC will have to be
programmed with this knowledge.  Therefore, it seems like going out of
our way to provide transparent variant mappings is of dubious value.

Kevin

-----Original Message-----
From: Ryabin Aleksandr-A19776 [mailto:[email-masked]]
Sent: Monday, July 18, 2005 12:26 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked]
Cc: Macchi Richard-E12538
Subject: RE: [Megaco] R2 Subscriber Categories in H.248.29

It might be a problem with this (and other) national variants, but in no
way it is going to change for this, or any other variant.
We can "declare" it (and some other variants) H.248.29 annex A
incompatible, but the fact is vendors will have to support it and
"hacking" H.248.29 to do this does not seem right to me.

Also this is not only about reusing existing value, but also about how
"spares" are defined in Annex A. The way they are defined precludes that
MGC must know the meaning of each NATL SC value to be used for each
variant. The intent was to make MGC transparent, as such NATL (spares)
are should not be defined, instead all (at least we can come up with)
meanings should be defined by Annex A explicitly.

H.248.29 is fairly young and IMHO we should go by practical route.
Defining all possible SC meanings for different variants will make
implementations from different vendors compatible without sacrificing
the major difference of Annex A from Annex B to make MGC variant
transparent.

Opinions?
	Aleks

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Thursday, July 14, 2005 10:59 AM
To: Ryabin Aleksandr-A19776; [email-masked]
Cc: Macchi Richard-E12538
Subject: RE: [Megaco] R2 Subscriber Categories in H.248.29

It is hard to make things transparent when local requirements redefine
things set by international standard.  The package was written with the
international standard in mind (Q.441 in this case) and under the
assumption that the national variants would use the "spare" values.
Because the Brazilian implementation redefined a value that was reserved
for international working, there is a conflict.  In this instance, the
MGC has to know that the value transmitted by the MG has a different
meaning.

I will note that this problem is not reserved to H.248 -- this is a
definition problem within the national variant.

Kevin

-----Original Message-----
From: Ryabin Aleksandr-A19776 [mailto:[email-masked]]
Sent: Wednesday, July 13, 2005 6:30 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked]
Cc: Macchi Richard-E12538
Subject: RE: [Megaco] R2 Subscriber Categories in H.248.29

My understanding the goal of Annex A is to make variants transparent to
MGC, while if Annex B is used it will make variants transparent to MG.

If my understanding is correct then when SC sent/received using H.248.29
Annex A, MGC must use "meaning" and must not make any assumptions on how
it is mapped to/from register MF signal.

How else, other then amending Annex A to add the missing SC "meaning"
values, MGC transparency can be achieved?

	Aleks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Kevin Boyle
Sent: Wednesday, July 13, 2005 4:17 PM
To: Macchi Richard-E12538; [email-masked]
Subject: RE: [Megaco] R2 Subscriber Categories in H.248.29

It appears to be that by reusing defined values and not the defined
spares, the Brazilian variant has made a problem for itself that goes
beyond H.248.29 encoding.  The controlling switch will always have to
know that those signals are different in brazil than the rest of the
world.  I would send the appropriately mapped value from the package,
and let the MGC worry about the definition overlap.

Kevin

-----Original Message-----
From: Macchi Richard-E12538 [mailto:[email-masked]]
Sent: Wednesday, July 13, 2005 3:48 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked]
Subject: RE: [Megaco] R2 Subscriber Categories in H.248.29

## In Annex A, there are spare values in the subscriber ## categories
that are for national use.  Send whichever one ## matches the national
variant value.  The equivalence of each ## spare is given for each.

This works for Brazil's "Local Payphone" (II-4) which can be sent as
"NATL1" as per Annex A, but Brazil's "Long Distance Payphone"
(II-7) seems to conflict with with ITUT's "Subscriber (or operator
without forward transfer facility)", and "Collect Call" (II-8) conflicts
with "Data transmission (international)".  How can I differentiate these
to the MGC?

Thanks,
--
Rich Macchi

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

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

---

From: [email-masked]
Date: Wed, 20 Jul 2005 22:07:56 +0200

In theory, an international standard like H.248.29 has only to supported
the referenced international standards concerning the supporting CAS
signalling system (here SS R2 => ITU-T Q.421-Q.442; a potential solution
for national support might be extension packages to Annex A packages ...).
In reality, almost every NGN solution supporting SS R2 interfaces is
confronted with national variants. This historical aspect is sth special in
the context of this H.248 Package(s), and reflected in § 5/H.248.29 and the
then motivation for developing two Annexes A & B.

Aleks, Rich,
Annex B may be an alternative to your problem related to national specifics
or redefined international codepoints.
Did you consider B? (Thomas may answer specific questions to the concept
behind.)

Nevertheless, from Alcatel side we are convinced that one notable criteria
for a NGN solution with H.248.29 capable H.248 systems, - concerning the
decision for Annex A vs B -, is the last sentence in clause § 5.1/H.248.29.
(Meaning, this is primarily a MGC decision. There are then not that type of
questions anymore in a "national deployment scenario".)

BR, Albrecht

                      "Kevin Boyle"                                                                                             
                      <[email-masked]         To:      "Ryabin Aleksandr-A19776" <[email-masked]>, <[email-masked]>       
                      om>                      cc:                                                                              
                      Sent by:                 Subject: RE: [Megaco] R2 Subscriber Categories in H.248.29                       
                      megaco-bounces@i                                                                                          
                      etf.org                                                                                                   

                      20.07.2005 17:18                                                                                          

Kevin

-----Original Message-----
From: Ryabin Aleksandr-A19776 [mailto:[email-masked]]
Sent: Wednesday, July 20, 2005 10:56 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked]
Cc: Macchi Richard-E12538
Subject: RE: [Megaco] R2 Subscriber Categories in H.248.29

Kevin,

Regards,
             Aleks

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Wednesday, July 20, 2005 10:16 AM
To: Ryabin Aleksandr-A19776; [email-masked]
Cc: Macchi Richard-E12538
Subject: RE: [Megaco] R2 Subscriber Categories in H.248.29

Kevin

-----Original Message-----
From: Ryabin Aleksandr-A19776 [mailto:[email-masked]]
Sent: Monday, July 18, 2005 12:26 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked]
Cc: Macchi Richard-E12538
Subject: RE: [Megaco] R2 Subscriber Categories in H.248.29

Opinions?
             Aleks

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Thursday, July 14, 2005 10:59 AM
To: Ryabin Aleksandr-A19776; [email-masked]
Cc: Macchi Richard-E12538
Subject: RE: [Megaco] R2 Subscriber Categories in H.248.29

Kevin

-----Original Message-----
From: Ryabin Aleksandr-A19776 [mailto:[email-masked]]
Sent: Wednesday, July 13, 2005 6:30 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked]
Cc: Macchi Richard-E12538
Subject: RE: [Megaco] R2 Subscriber Categories in H.248.29

             Aleks

-----Original Message-----

Kevin

-----Original Message-----
From: Macchi Richard-E12538 [mailto:[email-masked]]
Sent: Wednesday, July 13, 2005 3:48 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked]
Subject: RE: [Megaco] R2 Subscriber Categories in H.248.29

Thanks,
--
Rich Macchi