Subject: Comments on draft-boyle-megaco-tonepkgs-04.txt

From: Bill Foster <[email-masked]>
Date: Thu, 07 Jun 2001 13:53:18 -0700

Is there a plan to provide further definitions of tones in later updates? 
Many of the tones in this document are presently not defined or have no 
references to public documents. Where a tone is not defined but is 
associated with a feature, a reference to a public document that describes 
the feature would help (but obviously a real tone definition would be 
best). With no reference or definition of any kind, these would appear to 
be proprietary tones. In some cases, with no definition, interoperability 
problems may occur. So  "low tone" and "high tone" in the diagnostics 
package may refer to the same "low tone" and "high tone" as described in 
GR-529-CORE or maybe they are something completely different.

Tones in section 4 are evidently from E.180 and E.182 - but that should be 
stated.
Tones in sections 5-6 seem to all have definitions.
Tones in other sections should have references or better definitions: 
Section 7: xferdt, srdt and tones in Sections 8-12.

-----------------------------
Bill Foster
Phone: (250) 758-9418
Fax:     (781) 998-6492

---

From: "Michael Brown" <[email-masked]>
Date: Fri, 8 Jun 2001 16:26:59 -0400

Sorry for not having responded earlier to your initial post with this
question.

The short answer is that there is no plan to provide further definitions of
the tones particularly those other than in section 4. In the case of Section
4, it should have the exact same reference as provided in the Call Progress
tones package in Annex E and that will be added.

Regarding the other tones, they are definitely NOT proprietary, but they are
tones which have many possible physical definitions based on market/national
and/or enterprise implementation variations. The current tones definitions
were derived based on analysis of the mapping of existing market variant
tonesets to one another from a functional perspective. It is our belief that
since these tones are defined for support of Legacy telephony/services, the
functional definitions and the inclusion of the Legacy variant naming used
for the tones provides sufficient guidance for the use of them. It was
considered inappropriate to try to have these packages attempt to provide
exhaustive documentation of all of the possible physical tone variations.
This has been corroborated by the feedback we have received over the last
year on this draft.

I don't agree that this is an interoperability problem issue. The reason is
that the tones in these packages should be defined using a MIB. We have
submitted a draft proposing such a MIB. The definition of the values
contained within it is where the potential variations will be resolved. This
does allow the possibility that there could be "non-standard" definitions of
the tones, but this would be by the choice of the service provider within
the context of their deployment based on guidance provided by the vendor
providing the MGC. The MG is irrelevant since it will be provisioned with
the tone definitions and will play whatever it's told to play and it is up
to the MGC to direct the MG actions appropriately.

Regards,

Michael Brown

-----Original Message-----
From: Bill Foster [mailto:[email-masked]]
Sent: Thursday, June 07, 2001 4:53 PM
To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Brown, Michael [NC1:GW10:EXCH];
Cornel, Sarah [NCRTP:3J08:EXCH]; Doyle, Stacy [NC1:GW23:EXCH]; Kumar,
Mehala [MDN05:SR02:EXCH]
Cc: megaco
Subject: Comments on draft-boyle-megaco-tonepkgs-04.txt

---

From: Bill Foster <[email-masked]>
Date: Sun, 10 Jun 2001 10:02:06 -0700

Fair enough, but  a clearer definition of what the tone is used for
in some cases would help. Some of us may be able to nod our heads
knowingly when we see a tone called "faint tone" in a package
called "diagnostics package" but many others will be left
scratching their heads. Given that you can re-define the tone as anything
you want, I can see your point - but it's always possible to carry that
idea too far.

At 04:26 PM 6/8/2001 -0400, Michael Brown wrote:

Sorry for not having responded
earlier to your initial post with this question.

The short answer is that there is no plan to provide further
definitions of the tones particularly those other than in section 4. In
the case of Section 4, it should have the exact same reference as
provided in the Call Progress tones package in Annex E and that will be
added.

Regarding the other tones, they are definitely NOT
proprietary, but they are tones which have many possible physical
definitions based on market/national and/or enterprise implementation
variations. The current tones definitions were derived based on analysis
of the mapping of existing market variant tonesets to one another from a
functional perspective. It is our belief that since these tones are
defined for support of Legacy telephony/services, the functional
definitions and the inclusion of the Legacy variant naming used for the
tones provides sufficient guidance for the use of them. It was considered
inappropriate to try to have these packages attempt to provide exhaustive
documentation of all of the possible physical tone variations. This has
been corroborated by the feedback we have received over the last year on
this draft.

I don't agree that this is an interoperability problem
issue. The reason is that the tones in these packages should be defined
using a MIB. We have submitted a draft proposing such a MIB. The
definition of the values contained within it is where the potential
variations will be resolved. This does allow the possibility that there
could be "non-standard" definitions of the tones, but this
would be by the choice of the service provider within the context of
their deployment based on guidance provided by the vendor providing the
MGC. The MG is irrelevant since it will be provisioned with the tone
definitions and will play whatever it's told to play and it is up to the
MGC to direct the MG actions appropriately.

Regards,

Michael Brown

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

From: Bill Foster
[mailto:[email-masked]]

To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Brown, Michael
[NC1:GW10:EXCH];

Cornel, Sarah [NCRTP:3J08:EXCH]; Doyle, Stacy
[NC1:GW23:EXCH]; Kumar,

Mehala [MDN05:SR02:EXCH]

Cc: megaco

Subject: Comments on
draft-boyle-megaco-tonepkgs-04.txt

Is there a plan to provide further definitions of tones in
later updates?

Many of the tones in this document are presently not defined
or have no

references to public documents. Where a tone is not defined
but is

associated with a feature, a reference to a public document
that describes

the feature would help (but obviously a real tone definition
would be

best). With no reference or definition of any kind, these
would appear to

be proprietary tones. In some cases, with no definition,
interoperability

problems may occur. So  "low tone" and
"high tone" in the diagnostics

package may refer to the same "low tone" and
"high tone" as described in

GR-529-CORE or maybe they are something completely
different.

Tones in section 4 are evidently from E.180 and E.182 - but
that should be

stated.

Bill Foster

Phone: (250) 758-9418

Fax:     (781) 998-6492

Bill Foster

Phone: (250) 758-9418

Fax:     (781) 998-6492

---

From: Bill Foster <[email-masked]>
Date: Tue, 12 Jun 2001 02:42:15 -0700

I apologize for not providing feedback earlier. I'm not sure what is meant 
by "mapping of existing market variant tonesets to one another from a 
functional perspective means". Many of the tones in sections 7 to 12 as 
presently undefined are generally useless to the community at large. The 
fact that any tone can be re-mapped to anything else using a MIB, does not 
absolve you from providing default tone definitions with some reasonable 
description of tone usage. References to existing definitions and usage 
only help. If in order for a service provider to unplug MGC A and replace 
it with MGC B, they have to completely re-provision all their tone 
definitions, then there is something wrong. If you carry this idea to the 
extreme then there is no point in providing package and tone names at all - 
just have available a collection of package ID's and tone ID's for anyone 
to use as they will.

My case in point was the "low" and "high" tones in the "diagnostic" 
package. Either this refers to "low" tone and high "tone" in GR-729-CORE - 
or it refers to some other tones described somewhere else, or these tones 
are totally undefined. As far as I can tell "low" and "high" tones in 
GR-729-CORE are not diagnostic tones unless the definition of "diagnostic" 
is so broad as to be totally meaningless. In that case the package name 
does nothing to clarify the other tone names like "faint" tone and "loud" 
tone in that package.

Exhaustive documentation may not be required, but some reasonable amount of 
documentation is.

At 04:26 PM 6/8/2001 -0400, Michael Brown wrote:

>The short answer is that there is no plan to provide further definitions 
>of the tones particularly those other than in section 4. In the case of 
>Section 4, it should have the exact same reference as provided in the Call 
>Progress tones package in Annex E and that will be added.
>
>Regarding the other tones, they are definitely NOT proprietary, but they 
>are tones which have many possible physical definitions based on 
>market/national and/or enterprise implementation variations. The current 
>tones definitions were derived based on analysis of the mapping of 
>existing market variant tonesets to one another from a functional 
>perspective. It is our belief that since these tones are defined for 
>support of Legacy telephony/services, the functional definitions and the 
>inclusion of the Legacy variant naming used for the tones provides 
>sufficient guidance for the use of them. It was considered inappropriate 
>to try to have these packages attempt to provide exhaustive documentation 
>of all of the possible physical tone variations. This has been 
>corroborated by the feedback we have received over the last year on this draft.
>
>I don't agree that this is an interoperability problem issue. The reason 
>is that the tones in these packages should be defined using a MIB. We have 
>contained within it is where the potential variations will be resolved. 
>This does allow the possibility that there could be "non-standard" 
>definitions of the tones, but this would be by the choice of the service 
>provider within the context of their deployment based on guidance provided 
>by the vendor providing the MGC. The MG is irrelevant since it will be 
>provisioned with the tone definitions and will play whatever it's told to 
>play and it is up to the MGC to direct the MG actions appropriately.
>
>Regards,
>
>Michael Brown
>
>[<mailto:[email-masked]>mailto:bfoster@cisco<mailto:[email-masked]>.com]

---

From: Bill Foster <[email-masked]>
Date: Tue, 12 Jun 2001 02:51:10 -0700

That if course is GR-529-CORE.

>Date: Tue, 12 Jun 2001 02:42:15 -0700
>To: "Michael Brown" <[email-masked]>
>From: Bill Foster <[email-masked]>
>Subject: RE: Comments on draft-boyle-megaco-tonepkgs-04.txt
>Cc: "[email-masked]'" <[email-masked]>
>
>extreme then there is no point in providing package and tone names at all 
>- just have available a collection of package ID's and tone ID's for 
>anyone to use as they will.
>
>Exhaustive documentation may not be required, but some reasonable amount 
>of documentation is.
>
>
>>Section 4, it should have the exact same reference as provided in the 
>>Call Progress tones package in Annex E and that will be added.
>>
>>is that the tones in these packages should be defined using a MIB. We 
>>have submitted a draft proposing such a MIB. The definition of the values 
>>provider within the context of their deployment based on guidance 
>>provided by the vendor providing the MGC. The MG is irrelevant since it 
>>will be provisioned with the tone definitions and will play whatever it's 
>>told to play and it is up to the MGC to direct the MG actions appropriately.
>>
>>Regards,
>>
>>Michael Brown
>>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 12 Jun 2001 06:43:03 -0400

I wonder if there was a misunderstanding here.  Michael may have been saying
they don't want to provide a physical definition of each tone, while Bill is
asking for a functional definition.  I think the latter is a very reasonable
request -- otherwise every MG could support tones 1-100 but the meaning of
tone 50 would be locally defined.

---

From: [email-masked]
Date: Wed, 13 Jun 2001 08:52:48 +0530

Hi,
       I second Bill's thoughts. The more explicit packages are, lesser would be
 the interoperability problems.

Rgds,

Vikas Bajaj
Hughes Software Systems Ltd.

Bill Foster <[email-masked]> on 06/12/2001 03:12:15 PM

To:   "Michael Brown" <[email-masked]>
cc:   "[email-masked]'" <[email-masked]> (bcc: Vikas Bajaj/HSS)