Glen Freundlich suggested I cross-post this one to the SG 16 list. The conference call will take place Monday morning at 8:00 am PDT (11:00 am EDT, 5:00 pm where I am in Germany). I don't have a decent count of ports needed yet, so I haven't yet arranged a number to call. Please let me know if you want to take part (mailto:taylor@nortelnetworks.com).

-----Original Message----- From: Taylor, Tom-PT [CAR:B904-I:EXCH] Sent: Tuesday, September 28, 1999 10:02 AM To: megaco@standards.nortelnetworks.com 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 Advisor -- IPConnect Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961

Tom Taylor Advisor -- IPConnect Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961