H.323/H.225.0 V3 has been decided

Dale L. Skran dskran at ASCEND.COM
Thu Sep 30 10:15:43 EDT 1999


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 at nortelnetworks.com).

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



More information about the sg16-avd mailing list