Subject: RE: [Megaco] CAS Metering Pulse support

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 3 Oct 2003 11:28:17 -0400

I have no problem with producing an amendment to H.248.26.  There really is
no need for us to produce 1000 recommendations with 1 package each.

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]] 
Sent: Friday, October 03, 2003 11:21 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked]
Cc: Christian Groves
Subject: RE: [Megaco] CAS Metering Pulse support

Hi,

Sounds reasonable. Except that it probably should not be an extension since
an application might be needing detection only and no generation. That is it
should be then a standalone metd ("Metering Detection Package").

Since amet and metd are complimentary I think it would be reasonable to keep
them together, that is to a amend H.248.26 to include it.

Would you as the editor of H.248.26 recommend amending it to include new
metd or rather have new H.248.metd, or something else?

I can provide a baseline text, if necessary.

Regards,
         Aleks

At 09:34 AM 10/3/2003, Kevin Boyle wrote:
>The amet package was never designed to do pulse detection.  The pr 
>event is meant to allow the MGC to stay updated with the actual number 
>of pulses applied -- it has nothing to do with pulses detected.  This 
>allows the MGC to have an accurate view of the number of pulses 
>applied, rather than guessing -- and possibly being wrong due to 
>network latency, message loss, retransmission, etc., etc., etc.  I 
>think shoehorning detection in here isn't really appropriate.
>
>Further, are we sure that ALL pulse generation applications will be 
>required to detect pulses?  In the analog line case, the MG has no 
>reason to detect pulses -- pulses are being sent to the CPE for the 
>end-user's benefit.  I think that it would be far wiser to define an 
>extension package to handle detection, and not subject applications 
>that only want to do generation to doing detection as well.
>
>Kevin
>
>-----Original Message-----
>From: Christian Groves [mailto:[email-masked]]
>Sent: Thursday, October 02, 2003 11:38 PM
>To: Aleksandr Ryabin
>Cc: [email-masked]; Boyle, Kevin [NCRTP:3Z40:EXCH]
>Subject: Re: [Megaco] CAS Metering Pulse support
>
>
>Hello Aleksandr,
>
>I'm happy enough to have the your proposed amendment if the editor 
>agrees.
>
>Regards, Christian
>
>Aleksandr Ryabin wrote:
> > Hi Christian,
> >
> > No description of the event does say how to use it for detection 
> > incoming metering pulse. More over it explicitly limits to 
> > generation: "This event is used in conjunction with the "enable 
> > metering" and "metering pulse burst" signals defined in this 
> > package..."
> >
> > My point being that descriptions of amet events and statistics are 
> > siting that event pr is generated and statistics are changed only 
> > based on previously applied em, or mbp signal.
> >
> > The wording needs to be amended to cover the cases when event is 
> > generated and statistics are changed as a result *detection* of 
> > incoming metering pulse.
> >
> > That is, for example, the text you have referenced should be changed 
> > to something like this (I've placed the changes in [] for 
> > visibility):
> >
> > "If following the application [or detection] of any metering pulse 
> > (regardless of [whether it was detected, or] whether it was 
> > generated as a result of the signal em or as a result of the signal 
> > mbp), the EventsDescriptor contains the event pr, and if the value 
> > of pcslr is equal to the value of the
> > EventsDescriptor parameter rp, then the pr event shall be notified, and
> > the value of the statistic pcslr shall be reset to zero.  The detection
of
> > the event pr shall not cause the termination of the signal em or the
> > signal mbp, [if currently active,] even if the KeepActive flag is not
> > set for the pr event."
> >
> > Regards,
> >         Aleks
> >
> > At 07:46 PM 10/2/2003, Christian Groves wrote:
> >
> >> Hello Aleksandr,
> >>
> >> I agree that no new package is needed for the detection of metering 
> >> pulse functionality. From the description of the event it seems 
> >> that it clear how it to be used.
> >>
> >> The package also contains the procedural text:
> >> "If following the application of any metering pulse (regardless of 
> >> whether it was generated as a result of the signal em or as a 
> >> result of the signal mbp), the EventsDescriptor contains the event 
> >> pr, and if the value of pcslr is equal to the value of the 
> >> EventsDescriptor parameter rp, then the pr event shall be notified, 
> >> and the value of the statistic pcslr shall be reset to zero.  The 
> >> detection of the event pr shall not cause the termination of the 
> >> signal em or the signal mbp, even if the KeepActive flag is not set 
> >> for the pr event."
> >>
> >> Is this text sufficient?
> >>
> >> Regards, Christian
> >>
> >> Aleksandr Ryabin wrote:
> >>
> >>> Hi,
> >>> In continuation to this metering pulse support.
> >>> I've looked through amet package and it does not seem to define 
> >>> procedure to detect metering pulses, it only has a procedure to 
> >>> generate metering pulses. I see no reason of defining a new 
> >>> package for detecting incoming metering pulses and I propose to 
> >>> reuse amet and amend it to define procedure for detecting incoming 
> >>> metering pulses. Here is the summary of a proposed metering pulse 
> >>> detection procedure using amet package: The detection of metering 
> >>> pulse on a termination could be enabled by MGC when no amet 
> >>> signals are played on a termination by requesting detection 
> >>> amet/pr event with a required repetition period. MG would Notify 
> >>> MGC with amet/pr event when number of metering pulses is detected 
> >>> according to repetition period parameter set. On Subtract, or 
> >>> explicit AuditValue MG would send amet/cpc and amet/pcslr 
> >>> statistics similar to as described in the package provided their 
> >>> description extended to detection as well. Comments?
> >>> Thanks
> >>>         Aleks
> >>> BTW IANA MEGACO page is still not updated.
> >>> At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote:
> >>>
> >>>> It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 
> >>>> while all of them are dated in ITU the same. Strange.
> >>>>         Aleks
> >>>>
> >>>> At 10:46 AM 9/16/2003, Kevin Boyle wrote:
> >>>>
> >>>>> If it is NOT updated, that is. (Apparently, it's going to be one 
> >>>>> of those days!)
> >>>>>
> >>>>> Kevin
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Boyle, Kevin [NCRTP:3Z40:EXCH]
> >>>>> Sent: Tuesday, September 16, 2003 10:39 AM
> >>>>> To: Aleksandr Ryabin; [email-masked]
> >>>>> Subject: RE: [Megaco] CAS Metering Pulse support
> >>>>>
> >>>>> Ummm... yeah.  That's what I get for not looking it up before 
> >>>>> sending the message. :)  While amet is defined in the "Extended 
> >>>>> Analog Lines Packages" doc, there is nothing in the amet package 
> >>>>> that actually limits it to analog lines.
> >>>>>
> >>>>>
> >>>>> The updates for all the new (as of May) H.248 Sub-series 
> >>>>> Recommendations have already been requested of IANA.  If it is 
> >>>>> updated by the end of the month, I'll ping them again.
> >>>>>
> >>>>>
> >>>>> Kevin
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Aleksandr Ryabin [mailto:[email-masked]]
> >>>>> Sent: Tuesday, September 16, 2003 10:32 AM
> >>>>> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked]
> >>>>> Subject: RE: [Megaco] CAS Metering Pulse support
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I guess you meant H.248.26.
> >>>>> Yes it seem to address the needs assuming it is extended to 
> >>>>> digital lines as well.
> >>>>>
> >>>>> BTW IANA registry should be updated with H.248.26 and H.248.27 
> >>>>> http://www.iana.org/assignments/megaco-h248
> >>>>> <http://www.iana.org/assignments/megaco-h248>
> >>>>>
> >>>>> Thanks,
> >>>>>         Aleks
> >>>>>
> >>>>> At 10:00 AM 9/16/2003, Kevin Boyle wrote:
> >>>>>
> >>>>>
> >>>>> H.248.27 has a metering package (automatic metering package or 
> >>>>> amet).  This package may address your needs.
> >>>>>
> >>>>> Kevin
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Aleksandr Ryabin [mailto:[email-masked] 
> >>>>> <mailto:[email-masked]> ]
> >>>>> Sent: Tuesday, September 16, 2003 9:34 AM
> >>>>> To: [email-masked]
> >>>>> Subject: [Megaco] CAS Metering Pulse support
> >>>>>
> >>>>> Hi all,
> >>>>>
> >>>>> Below are excerpts from a previous exchange related to defining 
> >>>>> of CAS Metering Pulse procedures in MEGACO.
> >>>>>
> >>>>> Now that CAS packages related work has been moved to ITU has 
> >>>>> anyone done and/or planned anything in the direction to define 
> >>>>> CAS Metering Pulse procedures/package for MEGACO?
> >>>>>
> >>>>> Thanks
> >>>>>          Aleks
> >>>>>
> >>>>> >From: [email-masked]
> >>>>> >To: Aleksandr Ryabin <[email-masked]>
> >>>>> >cc: [email-masked], [email-masked], [email-masked]
> >>>>> >Date: Tue, 4 Mar 2003 12:47:37 +0530
> >>>>> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt :
> >>>>> Difference
> >>>>> >         from previous revision
> >>>>> ...
> >>>>> >Aleksandr Ryabin <[email-masked]> on 03/03/2003 10:43:20 
> >>>>> >PM
> >>>>> ...
> >>>>> >3. I can't seem to find a way to implement "Metering Pulse" 
> >>>>> >procedure defined for some R2 variants using ether bcas or R2 
> >>>>> >packages? For example, one of the definitions of such a pulse 
> >>>>> >is a "seizure ack" pulse from a terminating end on a circuit in 
> >>>>> >connected/answer state.
> >>>>> >
> >>>>> >[Kushanava] Metering is not specific to R2. It may be present 
> >>>>> >in any CAS signaling. Moreover not all flavours of R2 permit 
> >>>>> >metering to be mandatory. There should be therefore a general 
> >>>>> >philosophy of
> >>>>> attacking
> >>>>> >this problem common to all CAS signaling. The solution should 
> >>>>> >be sensitive to
> >>>>> >a) Realizing that MGC is the master for collecting and 
> >>>>> >generating
> >>>>> charging
> >>>>> >information
> >>>>> >b) Interworking of the CAS "metering pulse" signals with other
> >>>>> signaling
> >>>>> >(both PDN and PSTN)
> >>>>> >c) Optimizing the network traffic if metering information is
> >>>>> transported to
> >>>>>
> >>>>> >and fro between MGC and MG
> >>>>> >d) Latency, if metering information is transported to and fro
> >>>>> between MGC
> >>>>> >and MG
> >>>>> >We are working towards a separate package that addresses this 
> >>>>> >issue. Any suggestions?
> >>>>> ...
> >>>>>
> >>>>> _______________________________________________
> >>>>> Megaco mailing list
> >>>>> [email-masked] https://www1.ietf.org/mailman/listinfo/megaco
> >>>>> <https://www1.ietf.org/mailman/listinfo/megaco>
> >>>>> _______________________________________________
> >>>>> Megaco mailing list
> >>>>> [email-masked] https://www1.ietf.org/mailman/listinfo/megaco
> >
> >

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Christian Groves <[email-masked]>
Date: Mon, 06 Oct 2003 10:57:35 +1000

G'Day Kevin,

If we do have an amendment then I think some text needs to be changed in the 
original to make it very clear that it does not detect pulses. I think as the 
current text stands one could be forgiven for misinterpereting whether this is 
possible or not.

Cheers, Christian

---

From: Christian Groves <[email-masked]>
Date: Mon, 06 Oct 2003 10:57:35 +1000

G'Day Kevin,

Cheers, Christian