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

From: Macchi Richard-E12538 <[email-masked]>
Date: Tue, 12 Jul 2005 19:19:15 -0500

Greetings,

While examining the R2 country-specific variants I noticed that the
variants contain subscriber categories which do not exist in Q.441
(and are consequently not in H.248.29).  These are:

    Local Payphone,
    Long Distance Payphone,
    Subscriber with Special Rates,
    Subscriber Trunk Dialing (STD) Coin Box,
    Incoming International Service,
    Subscriber with Forward Transfer Facility, and
    Collect Call

Is there a way to amend H.248.29 to include these categories?

Thanks,
-- 
Rich Macchi

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

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 13 Jul 2005 09:38:29 -0400

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.

In Annex B, the appropriate MF digits for the subscriber are passed to
the MGC for interpretation as per the national variant.

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Macchi Richard-E12538
Sent: Tuesday, July 12, 2005 8:19 PM
To: [email-masked]
Subject: [Megaco] R2 Subscriber Categories in H.248.29

Greetings,

While examining the R2 country-specific variants I noticed that the
variants contain subscriber categories which do not exist in Q.441 (and
are consequently not in H.248.29).  These are:

    Local Payphone,
    Long Distance Payphone,

Thanks,
--
Rich Macchi

---

From: Macchi Richard-E12538 <[email-masked]>
Date: Wed, 13 Jul 2005 14:47:41 -0500

## 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

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 13 Jul 2005 16:17:03 -0400

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

---

From: Ryabin Aleksandr-A19776 <[email-masked]>
Date: Wed, 13 Jul 2005 17:29:40 -0500

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

---

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 14 Jul 2005 10:58:39 -0400

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-----
Of Kevin Boyle

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

---

From: Ryabin Aleksandr-A19776 <[email-masked]>
Date: Sun, 17 Jul 2005 23:25:45 -0500

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.

	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

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

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 20 Jul 2005 10:16:08 -0400

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

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

---

From: Ryabin Aleksandr-A19776 <[email-masked]>
Date: Wed, 20 Jul 2005 09:55:55 -0500

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

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-----
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

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

---

From: Ryabin Aleksandr-A19776 <[email-masked]>
Date: Wed, 20 Jul 2005 16:52:18 -0500

If the intention was to have single base package, then ICASC Annex A should have defined 
These directly as II[1-15] for SC and B[1-15] for CPRS instead of meanings. 
Then an extension ITU-T Q.441 package should have been defined which overwrites 
the base ICASC SC and CPRS meanings.

Please see more inline [AR].
	Aleks

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

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? 

[AR] MGC implements a full set of values/meanings from start.
MG would implement variants as needed and when needed.
Again, the main point is the set of meanings stay the same, but the way they are mapped to a particular signal is up to MG.

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.

[AR] Vanilla ITU-T R2 hardly ever used, while there are MANY national variants out there.
The fact that there were no proposals so far on extension packages to support any national 
variants leads me to believe vendors ether:
A. Use vanilla ICASC Annex A to implement national variants support (trying make it generic)
B. Annex A is not used at all. 
Since Annex A is based on old r2 package and has been out there (at least as proposal) for a while
I tend to think vendors do use it and gone through route A.

[AR] It might be more streamlined from H.248/MEGACO point of view to introduce extension packages 
for each national variant, but IMHO it is highly unpractical to have MANY (at least dozens) packages 
which only define one, or two extra values. What about variants that do not need extra values,
but differ mapping, or procedures? Why would we need separate package for those if base can handle it.
In my evaluation the number of variants greatly exceeds the number of new values/meanings they collectively contain.

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!
[AR] Yes, I agree on that, but it can be supported in base ICASC by defining property which lists supported variants.

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,

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).

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-----
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

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

---

From: Ryabin Aleksandr-A19776 <[email-masked]>
Date: Fri, 22 Jul 2005 10:12:48 -0500

Albecht,

Yes, we have considered both.
Annex B does offer "MGC centric" solution and *does* work for national variants *without* any extensions.
That is to add new national variant support only MGC has to be changed.
Thank you for your offer.

The point I'm rising is the "MG centric" solution (Annex A) does *not* work for national variants *without* extensions.
That is to add new national variant support both MGC and MG have to be changed.
It might have been by design, but for practical reasons we suggested to amend it to enable support for national variants *without* extensions.
That is to add new national variant support only MG has to be changed.

Regards,
	Aleks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 20, 2005 4:08 PM
To: Ryabin Aleksandr-A19776; Kevin Boyle
Cc: [email-masked]; [email-masked]
Subject: RE: [Megaco] R2 Subscriber Categories in H.248.29

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-----
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

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