Subject: Packages Conference Call

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 28 Sep 1999 10:13:23 -0500

I was a bit hasty in my designation of the editorship of the packages
documentation.  I should have said "Mike Kallas, Bilalis Zacharias, and
collaborators".  Apologies to Bilalis for slighting his role as co-editor.

Tom Taylor
Advisor -- IPConnect Standards
E-mail: [email-masked] (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961

---

From: Peter Blatherwick <[email-masked]>
Date: Wed, 29 Sep 1999 03:48:52 -0400

Count me in for the audio conference.  This is high priority, so other
scheduled items are eminently trashable...

Some comments:

Despite some issues below, I think the first draft is actually fairly close
to needs.  This needs to be completed ASAP.

There are some things missing, most notably a separate basic analog line
package, possibly accompanied by advanced analog line packages for eg CLASS,
FAX and ADSI -- in the real world, analog lines and non-analog telephones
are different beasts.  These would align with MGCP and borrow heavily from
the packages currently defined.  Packages for ancillary input, IVR, and some
others are likely lacking as well.  I see these as oversights given lack of
time as opposed to problems with philosophy or design.  (I hope I'm not
putting too many words in Bilalis' and Mike's mouths by saying this.)  I'm
sure specific proposals would be appreciated!

As a general principal I prefer to have more, smaller, non-overlapping
packages, as this allows for more of an all-or-nothing approach.  MGs either
implement the package or they do not, with little ambiguity to be resolved
by the MGC through AuditCapability.  Packages must be designed to avoid
overlap.  This should improve reuse, reduce AuditCapability discovery
cycles, and improve interoperability.  I believe this approach agrees with
the conclusions we came to at the editing session at the recent TIA meeting
in Ottawa (including Tom, Marku, Bob, Mike, myself).

In particular, the generic audio package should be split into generate
(gaudgen) and detect (gauddet) pieces since not all implementations would do
both generation and detection.  DTMF generate and detect might also be
separate.

The user interface related packages (keys, indicators, display, etc) allow
quite a wide range of telephone handling MGs to be defined, to manage
anything from legacy analog business sets to IP Phones and pretty much
everything in between.  Because analog lines have stand-alone capability, I
think there may be some necessary overlap between line package and the user
interface packages.

I think there are some overlaps between line side and trunk side which could
be collapsed into common packages.  The distinction between line and trunk
sides is vague in the real world with respect to signal/detect functionality
support requirements.

I hope to get out some more detailed comments before the end of the week,
but am on the road so this may be difficult.

-- Peter Blatherwick

> -----Original Message-----
> From: Taylor, Tom-PT [CAR:B904-I:EXCH]
> Sent: Tuesday, September 28, 1999 10:02
> To:   [email-masked]
> Subject:      Packages Conference Call
>
> Today or tomorrow, all going well, Mike Kallas and his collaborators will
> release a draft of the basic packages document which is an essential part
> of
> the Megaco work product.  I am sure this document will need work from the
> list to get it into final shape -- I myself don't agree with it entirely.
> To help us along, I propose that we have an audio conference early next
> week
> to get a feeling for the group's consensus on a number of policy issues.
> This could be followed if necessary by a drafting session next week or the
> week after, open to anyone who wants to take part.
>
> What follows is a proposed agenda for the audio conference.  Advance
> discussion on the list to prepare the way will be most welcome.  Those who
> want to take part in the audio conference please let me know whether
> Monday
> or Tuesday would be better.  I will be in Europe, which will tend to bias
> me
> against starting times later than 3 pm EDT, but you can state preferred
> time
> if you want.
>
> Agenda:
>
> 1. Scope of the Basic Packages Document
>
> Is there any special significance to the packages we choose to put in this
> document as opposed to another one?
> What applications do we cover?
>  - carrier only, or enterprise too?
>  - lines, trunks, data, text?
>  - digital circuit, RTP, ATM AAL1, ATM AAL2, ATM AAL5, FR?
>
> 2. Package and Event Definition Policy
>
> Do we try to define a minimum number of events and signals with broad
> scope
> and a number of parameters, or lots of specialized events and signals with
> fewer parameters?  (Example: a single recvTone event with parameters
> indicating the class(es) of tones to listen for, versus separate events
> for
> DTMF, MF, FAX, data modems, and (maybe) call progress tones.)
>
> Can the same events be defined in different packages?
>
> How do we handle regional variations?
>
> Do we assume the MGC and MG already understand (are mutually provisioned
> with) specific tones beyond a single common basic set (e.g. both units
> understand what PAT023 means), or do we provide for such provisioning in
> Megaco?
>
> Do we define actions which combine signals and events in their behavioural
> description, or do we keep things at the atomic level we have inherited
> from
> MGCP?
> Example: we could define a "collect" signal(?) which has the following
> behavioural specification (not as complete as I'd make it in a real
> specification):
>  -- apply dial tone to the termination (with the regional variant of dial
> tone supplied as a possible parameter)
>  -- discontinue dial tone when the first of two events happens: timeout
> awaiting first digit (in which case dial tone should be replaced with
> reorder tone), or first digit received
>  -- collect and report digits according to the supplied digit map, if any
>  -- buffer additional digits after the initial report pending further
> instructions from the MGC.
>
>
> 4. What Events/Signals And Packages Should We Have?
>
> The specification about to be released has the following packages and
> events
> and signals within them:
>
> Generic audio package
> Events: ToneStartDetected, ToneEndDetected, LongToneDetected
> Signals: PlayTone, StopTone, DefineTone
>
> Generic DTMF package
> Events: ToneDetected, SilenceDetected
> Signals: PlayTone, StopTone
>
> Dialpad package
> Events: DialpadKeyDown, DialpadKeyUp
> Signals: DialpadEcho
>
> Function key package
> Events: FunctionKeyDown, FunctionKeyUp
> Signals: AssignFunctionKeyName
>
> Indicator package
> Events: none
> Signals: SetIndicator, SetName
>
> Monochrome text display package
> Events: none
> Signals: Display, ClearDisplay
>
> Softkey package
> Events: KeyDown, KeyUp
> Signals: SetName, Display
>
> Trunk generic package
> Events: ModemDetected, FAXToneDetected, ReportFailure
> Signals: BusyTone, RingingTone, CongestionTone
>
> Trunk supplementary package
> Events: ContinuityTest
> Signals: ContinuityTone
>
> NAS package
> Events: ReportFailure, AuthorisationSucceeded, AuthorisationDenied,
> CallbackRequest, AAAFail
> Signals: none
>
> RTP package
> Events: ReportFailure, QualityAlert
> Signals: none
> Statistics: the usual
>
> Announcement server package
> Events: AnnouncementFailure, AnnouncementCompleted
> Signals: AnnouncementPlay
>
>
> 5. Miscellaneous Definitional Issues
>
>   Event/signal configuration vs. event reporting.
>
>   Relationship of event reporting to digit maps -- especially the
> inclusion
> of MF events in our present ABNF.
>
>   What has to go into the packages which indicate the network-specific
> characteristics of terminations?
>
>   Meaning of terminationMode: "send" to the exterior or into the context?
>
> Tom Taylor