Subject: RE: [Megaco] RE: [Fwd: Fwd: Uploaded files to Incoming]

From: "Kevin Boyle"<[email-masked]>
Date: Tue, 29 Jan 2002 23:26:51 -0500

Oops.. my bad.  I misunderstood the report.  OK, how about we take my
original email, and figure out which items are IG-able, and which are not.
This forum is, I think, the best place to do that!

Any comments, anyone?

Kevin

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Tuesday, January 29, 2002 4:27 PM
To: Boyle, Kevin [NCRTP:3Z30:EXCH]
Cc: megaco ietf
Subject: Re: [Megaco] RE: [Fwd: Fwd: Uploaded files to Incoming]

No changes for IG or V2 were approved at the Dublin meeting.  Here is
the item from the Q.3 meeting report:

> 1.3.2.6 AVD-2141a: H.248 Digit Collection Corrections and Enhancements
[Nortel]
>
> There was concern that some of the proposed changes (such as the matching
rules) would not
> be compatible with V1 implementations. The proposal as a whole is complex,
so removal of
> individual features in the proposal that are not backwards compatible may
break entire
> proposal.
>
> In TD-40, the proposal was restructured to identify parts that would not
be backward
> compatible. There was a lack of time to adequately review this
contribution, but we recognize
> that many of the items in the proposal need attention. We will proceed as
follows:
> · Separately identify items for the implementers guide and post these to
the megaco and SG16
> lists
> · Separately identify items intended for V2 and post these to the megaco
and SG16 lists
> · The proposed extended DTMF detection package is accepted as a new annex
on the condition
> that the related material for V2 is accepted
>
> Understanding that sufficient time is needed to review the entire
proposal, the material is
> accepted in principle, subject to further review and open to contributions
or
> counter-proposals.

I have not seen a list of proposed items (extracted from TD-40) intended
for the IG or for V2 posted to the mailing list for discussion and so
have not included any of these items in my IG draft.

Kevin Boyle wrote:

>
>
> Actually, I have some.
>
> The IG posted there is lacking the digit collection changes agreed
> upon in Dublin.  Here are the changes as agreed upon:
>
> Section 7.1.14.2:
> Change: "The timers are configurable parameters to a DigitMap.  The
> Start timer is started at the beginning of every digit map use, but
> can be overridden."
>
> To: "Default values of these timers should be provisioned on the MG,
> but can be overridden by values specified within the DigitMap."
>
> Section 7.1.14.3:
> Change: "Finally, if conflicting timing specifiers are in effect in
> different alternative sequences, the results are undefined."
>
> To: "Finally, if conflicting timing specifiers are in effect in
> different alternative sequences, the long timer shall be used."
>
> Change: "The value of this threshold is assumed to be provisioned in
> the MG."
> To: "The value of this threshold is assumed to be provisioned in the
> MG, but, like the T, L, and S timers, can be overridden by
> specification within the DigitMap."
>
> Section 7.1.14.4:
> Change: "Subsequent events in the package are processed as per the
> currently active event processing mechanisms."
> To: "Subsequent digit events in the package are processed as follows:
>
> ·if EventBufferControl is ON, subsequent digit events are processed in
> the same way as any other events;
>
> ·if EventBufferControl is OFF, if the active EventsDescriptor did not
> change, and if individual digit events are not enabled within that
> descriptor, then digit buffering will be initiated.  Buffering will
> continue until the buffering time specified in the original digit map
> completion event has expired or until the active EventsDescriptor is
> replaced.
>
> The digit buffer shall take the logical form of a dial string which
> includes the digit characters as represented in the digit map,
> possibly preceded by 'Z'.  The threshold value of tone duration used
> to identify long events shall be the same as that used with the most
> recently completed digit map.
>
> Buffering time defaults to zero (no buffering) unless explicitly set
> otherwise within the digit map completion event.  If buffering ceases
> due to buffering timer expiry, the contents of the digit buffer are
> discarded.
>
> If buffering was stopped by a new EventsDescriptor, then if that
> EventsDescriptor contains a new digit map completion event from the
> same package as the previous one, any buffered digits are processed
> against the digit map as described below.  Buffered digits not
> consumed by the new digit map are handled as if they had were observed
> after that map completed.
>
> If instead the new EventsDescriptor enables the reporting of
> individual digit events, the entire set of buffered digits shall
> immediately be processed, the applicable events reported, and the
> buffer cleared.
>
> Finally, if the new EventsDescriptor enables neither a digit map
> completion event nor the reporting of individual digit events from the
> package concerned, the buffer contents are discarded and buffering is
> terminated."
>
> (All of the paragraphs following the second bullet are part of that
> bullet item.)
>
> Section 7.1.14.5:
>
> Change: "2. At each step, a timer is set to wait for the next event,
> based either on the default timing rules given above or on explicit
> timing specified in one or more alternative event sequences. If the
> timer expires and a member of the candidate set of alternatives is
> fully satisfied, a timeout completion with full match is reported.  If
> the timer expires and part or none of any candidate alternative is
> satisfied, a timeout completion with partial match is reported."
>
> To: "2. At each step, if buffered digits are available, the oldest one
> (with possible accompanying long digit (Z) qualifier) is removed from
> the buffer and processing moves to the next step as if the digit event
> had just been observed.  Otherwise a timer is set to wait for the next
> event, based either on the default timing rules given above or on
> explicit timing specified in one or more alternative event sequences.
> If the timer expires and a member of the candidate set of alternatives
> is fully satisfied, a timeout completion with full match is reported.
> If the timer expires and part or none of any candidate alternative is
> satisfied, a timeout completion with partial match is reported.  In
> either case, if the digit map completion event allows for detailed
> timeout reporting, the reported dial string will end with 'L' or 'S'
> as appropriate."
>
> Change (step 5): "The event removed from the current dial string will
> then be reported as per the currently active event processing
> mechanisms."
>
> To: "The event removed from the current dial string will then be
> reported as a separate event, buffered, or discarded according to the
> rules described in the previous section.  This statement is qualified
> as follows:
>
> a) The digit map completion event may specify that the event be
> reported as a parameter of that event.  This occurs independently of
> subsequent processing of the digit event.
>
> b) The digit map completion event may specify that the extra digit
> should be discarded.  In this case, it is discarded immediately.  Any
> buffering or other processing applies only to subsequent events."
>
> Section 6.1.14.7:
>
> Change: "· the events in the package containing the specified digit
> map completion event other than the completion event itself are not
> individually notified, and"
>
> To: "· the events in the package containing the specified digit map
> completion event other than the completion event itself are not
> individually notified and have no side-effects unless separately
> enabled, and"
>
> Change: "· an event that triggers a partial match completion event is
> not recognized and therefore has no side effects until reprocessed
> following the recognition of the digit map completion event."
>
> To: "· an event that triggers a partial match completion event is not
> recognized and therefore has no side effects unless and until
> reprocessed following the recognition of the digit map completion
> event.  Similarly buffered digit events are not recognized and have no
> side effects until processed."
>
> Annex C:
>
> Change:
>
>    digitMapValue        = ["T" COLON Timer COMMA] ["S" COLON Timer
> COMMA]
>                           ["L" COLON Timer COMMA] digitMap
>    Timer                = 1*2DIGIT
>
> To:
>
>    digitMapValue        = ["T" COLON Timer COMMA] ["S" COLON Timer
> COMMA]
>                           ["L" COLON Timer COMMA] ["Z" COLON Timer
> COMMA]
>                            digitMap
>    Timer                = 1*2DIGIT
>    ; Units are seconds for T, S, and L timers, and hundreds of
> milliseconds for Z timer.
>    ; Thus T, S, and L range from 1 to 99 seconds and Z from 100 ms to
> 9.9 s.
>
> Kevin
>
> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Monday, January 28, 2002 7:26 PM
> To: megaco ietf
> Subject: [Megaco] [Fwd: Fwd: Uploaded files to Incoming]
>
> G'Day all,
>
> I have uploaded a number of H.248 editors' contributions and company
> contributions to the PICTEL website.
> http://standard.pictel.com/ftp/avc-site/0202_Gen/
>
> A list of the documents is below. The latest version of H.248 is among
>
> them. Comments?
>
> Regards, Christian
>
> -------- Original Message --------
> Subject: Fwd: Uploaded files to Incoming
> Date: Thu, 24 Jan 2002 16:27:59 +0900
> From: OKUBO Sakae <[email-masked]>
> Reply-To: OKUBO Sakae <[email-masked]>
> To: [email-masked]
>
> Dear SG16 experts,
>
> They are now available at /0202_Gen of the avc-site.
>
> At 16:16 +1100 02/01/24, Christian Groves wrote:
> >I have placed the following files in the incoming directory. Could
> you
> >please move them to the Geneve directory?
> >
> >1. [DC-xxx_Annex_L_amm1] Proposed H.248 Annex L Amendment 1
> >2. [DC-xxx_Annex_M_1] Comments to H.248 Annex M.1 Audio Server
> Package
> >3. [DC-xxx_Annex_M_qac] H.248 Annex M.qac Quality Alert Ceasing
> Package
> >4. [DC-xxx_Annex_N] H.248 Annex N SDP H.248 Package Attribute
> >5. [DC-xxx_Imp_Guide] H.248 Implementors' Guide Additions
> >6. [DC-xxx_MuxDescription] Clarification of H.248 Mux Descriptor
> Usage
> >7. [DC-xxx_Nx64K] Addition of Nx64K Service to the H.248 Mutliplex
> >descriptor
> >8. [DC-xxx_Packages_Guide] Packages Guide
> >9. [DC-xxx_Profile_Pkg] Draft H.248 Annex M.profile Profile Package
> >10. [DC-xxx_H248v2] Draft H.248v2
>
> Best regards,
>
> OKUBO Sakae
> *********************************************************
> Global Information and Telecommunication Institute (GITI)
> Waseda University
> 29-7 Waseda University Bldg.
> 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo
> 169-0051 Japan
>         e-mail: [email-masked]
>         Tel: +81 3 3204 8194
>         Fax: +81 3 5286 3832
> *********************************************************
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco

--

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla