Subject: [Megaco] Packages extension (question 2)

From: Fhuval Hittay <[email-masked]>
Date: Wed, 4 Sep 2002 08:23:41 +0400 (MSD)

Thanks for answer, but there is one more question. "tonedet" package has "std" 
event with "tl" parameter, and that parameter has only one possible value "*". 
Suppose such a situation: MG received following Events descriptor
  Events = 1 { tonedet/std {tl = *} }
and it detects "d2" start tone. Which ObservedEvents descriptor MG has to notify
  ObservedEvents = 1 { tonedet/std {tid = *} }
or something different? But there is said "Extensions to this package would add 
additional possible values for tone id". Does it mean that instead of "*" we 
could use "dd" package's tones?

 And what about "tonegen" package? In section E.3.3 is said:
"No tone ids are specified in this package. Packages that extend this package 
can add possible values for tone id as well as adding individual tone signals".
 Does it mean, that if "dd" package extends "tonegen" package, we can use 
"tonegen/pt {tl = [d0, d1]}" form?

Thanks in advance.

-----------------------------

From:  Aleksandr Ryabin <[email-masked]>
Subject:  Re: [Megaco] Packages extension

>Hi,
>
>         Usage of signal/event IDs apply only in the scope of the package
>which defines them, or packages that extends that package.
>Thus you can not use d0 in tonegen, it does not know what d0 is.
>
>To clarify, let say there is another packages dgx which also extends
>tonegen and also defines d0, like dg package, but it means something 
>different.
>If you were to use base package to access d0 then you would get the same
>tonegen/pt {tl = [d0, d1]}  As you can see there is no way to distinguish
>which package is being used: dg or dgx.
>
>The answers to your questions below are:
>dg/pt {tl = [d0, d1]}
>dd/std {tl = [d2, d3, d4]}
>Events = 1 { dd/std {tl = [d2, d3, d4]}}
>ObservedEvents = 1 { dd/std {tid = d2} }
>
>Cheers.
>         Aleks
>
>At 01:19 AM 9/3/2002, Fhuval Hittay wrote:
>>  Hello all!
>>In RFC there is said that "dg" package extends "tonegen" package, and does 
>it
>>mean that I can use:
>>    dg/pt {tl = [d0, d1]}
>>instead of:
>>    tonegen/pt {tl = [d0, d1]} ?
>>
>>Also "dd" package extends "tonedet" package. And instead of:
>>    tonedet/std {tl = [d2, d3, d4]}
>>I can use:
>>    dd/std {tl = [d2, d3, d4]} ?
>>
>>Question is: What is the difference between theese two forms of usage? 
>Which
>>ObservedEvents descriptor MG has to return if it has following 
>>EventsDescriptor:
>>   Events = 1 { dd/std {tl = [d2, d3, d4]}, tonedet/std {tl = [d2, d3, 
>d4]}}
>>and it detects f.e. "d2" stat tone:
>>  ObservedEvents = 1 { dd/std {tid = d2} },
>>or
>>  ObservedEvents = 1 { tonedet/std {tid = d2} } ?
>>
>>Please, answer ASAP. Thanks in advance.
>>_______________________________________________
>>Megaco mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/megaco
>
----
  http://www.rambler.ru
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 04 Sep 2002 09:58:36 -0400

Please see answers below inline.

At 12:23 AM 9/4/2002, Fhuval Hittay wrote:

>or something different?

Events descriptor above would match no events as tonedet itself has no 
individual
events ids. The only reason * is defined in tonedet is such that it does 
not have to
be defined in all the packages that extents it, since the meaning of * is 
exactly the
same no matter what package it is defined in. So you should really use this:
Events = 1 { dd/std {tl = *} }
and then on d2 start detect MG will send
ObservedEvents = 1 { dd/std {tid = d2} }

>But there is said "Extensions to this package would add

Not instead, but in addition to, and only in scope of dd package (see above).

>"tonegen/pt {tl = [d0, d1]}" form?

No, other way around, that means that dd package can use tonegen's signals
and its params, that is:
"dd/pt {tl = [d0, d1]}"

Cheers.
         Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 04 Sep 2002 09:58:36 -0400

Cheers.
         Aleks

---

From: Troy Cauble <[email-masked]>
Date: Wed, 04 Sep 2002 10:27:31 -0400

About 20 months ago, following some similar discusions, I made the following
notes for myself.  Unfortunately, I can't cite portions of the document or even
the e-mails.

/* NOTES:
  * Given packges A with event a1 and B with event b1 where B extends A:
  *
  *      A/a1, B/b1, & B/a1 are legal.
  *      A/b1 is not.
  *
  * Note that we're searching DOWN the extension chain from B to verify a1.
  *
  * Packages may also define new parameter VALUES for the packages they extend.
  * So if A/a1 has a parameter ap1, B may define a value bv1 making
  *
  *      A/a1 { ap1=bv1 } legal, and
  *      B/a1 { ap1=bv1 } legal.
  *
  * Note that we're searching UP the extension chain (tree) to verify v1!
  */

-troy

---

From: Troy Cauble <[email-masked]>
Date: Wed, 04 Sep 2002 10:27:31 -0400

/* NOTES:

-troy

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 04 Sep 2002 15:17:01 -0400

Hi,

         I've searched through mail archives and found that there has been
numerous discussions related to toneid/signalid usage hierarchy.
Here the ones I found (month: subject):
2000-06: Tonegen Package
2000-06: Packages extension queries
2001-01: ToneGen...CPTGen
2002-02: Doubt on package extension

I was not able to figure out what the consensus is regarding parameter values.
Tom has interpreted same way I did and you had indicated other way around.
It feels inconsistent to me to have different rules for event/signals and
parameter values (e.g UP vs. DOWN). Somebody also pointed out that
it will be very uneasy for parser to parse base package which references
values from extended package. The "uniqueness" problem is also applies
to parameter values (like it does to signal/events), since parameter values
can be defined as signal/events as well, like it is done for signalid/eventid
in tonegen/tonedet and their extensions.

Thus I would strongly advocate to prohibit "searching UP" from base
for parameter values as well. That is making A/a1 { ap1=bv1 } in your
NOTES to be illegal (like A/b1)

Thanks
         Aleks

PS Here is an excerpt from one of the mails:

Date: Wed, 30 Jan 2002 16:44:57 -0500
From: Troy Cauble <[email-masked]>
To: Tom-PT Taylor <[email-masked]>
Original-CC: "[email-masked]'" <[email-masked]>, megaco 
<[email-masked]>
Subject: Re: [Megaco] Doubt on package extension

We've been around on this subject before.

Here are some notes I compiled for my own use.  Too bad
I didn't reference the specific mailing list messages
on which they're based.

Perhaps the language used will stimulate someone's memory.

[see Troy's NOTES block below]

-troy

Tom-PT Taylor wrote:
 >
 > This doesn't feel right to me, and the cases are not exactly the same.  Here
 > we have a parameter value which is unknown in the base package.  Even though
 > toneGen is known there, the parameter value is not.  In my view this means
 > you have to address that value through the extension which defined it (or
 > extensions of that extension).
 >
[clip]

Specifically the last one
At 10:27 AM 9/4/2002, Troy Cauble wrote:

>>  Thanks for answer, but there is one more question. "tonedet" package 
>> has "std" event with "tl" parameter, and that parameter has only one 
>> possible value "*". Suppose such a situation: MG received following 
>> Events descriptor
>>or something different? But there is said "Extensions to this package 
>>would add additional possible values for tone id". Does it mean that 
>>instead of "*" we could use "dd" package's tones?
>>"No tone ids are specified in this package. Packages that extend this 
>>package can add possible values for tone id as well as adding individual 
>>tone signals".
>>  Does it mean, that if "dd" package extends "tonegen" package, we can 
>> use "tonegen/pt {tl = [d0, d1]}" form?
>>Thanks in advance.

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 04 Sep 2002 15:17:01 -0400

Hi,

Thanks
         Aleks

-troy

[clip]

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 04 Sep 2002 15:56:36 -0400

Here some more mail about same I've missed from last month.
I think it is time this issue is taken care of and some wording
appears in IG, or something.
         Aleks

From: "Kevin Boyle" <[email-masked]>
To: Raphael Tryster <[email-masked]>,
         "Tom-PT Taylor" <[email-masked]>,
         "'Usha Iyer'" <[email-masked]>, [email-masked]
Subject: RE: [Megaco] Doubt on package extension
Date: Wed, 14 Aug 2002 16:01:10 -0400

I do not understand how we can allow making base packages understand values
in extension packages.  That means that an implementation must potentially
understand extensions that it doesn't use.
[clip]

From: "Tom-PT Taylor" <[email-masked]>
To: "'Raphael Tryster'" <[email-masked]>,
         "Kevin Boyle" <[email-masked]>,
         Raphael Tryster <[email-masked]>,
         "'Usha Iyer'" <[email-masked]>, [email-masked]
Subject: RE: [Megaco] Doubt on package extension
Date: Mon, 26 Aug 2002 22:21:11 -0400

I am processing my mail backlog in sequence, so maybe this has been
answered.  toneIds are parameter values, not signals, events, properties, or
statistics.  Hence they are used without a preceding package name.  HOWEVER,
if the toneID is defined in package X, then the invocation of playtone is as
a signal in package X (i.e. X/playtone{ <toneId> } ).  Thus the normal
package inheritance rules apply.  It is not that support of the basic tone
package implies support of all toneIDs, but support of a toneID implies
support of the basic tone package as inherited into the package defining the
toneID.
[clip]

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 04 Sep 2002 15:56:36 -0400