Subject: RE: [Megaco] CAS Metering Pulse support

From: Aleksandr Ryabin <[email-masked]>
Date: Fri, 03 Oct 2003 15:16:17 -0400

Hi,

How the pulse information is relayed between MGC is out of scope MEGACO.
Whatever MGCs use for inter MGC communication will need to support this 
information.

Regards,
         Aleks

At 02:44 PM 10/3/2003, Soncodi, Adrian wrote:
>The pulse rate can change during the call. This is done by the switch 
>downstream, which is the TAX office, and which changes the rate based on 
>time-of-day and provisioned charge rates. This means that the receiving MG 
>would also neeed an event for pulse rate change. A little more overhead 
>will occur, but I guess it is acceptable. However, it becomes delicate 
>when the pulse rate decreases: by the time the receiving MG detects the 
>lower pulse rate, the generating MG has already generated a number of 
>extra pulses, based on the higher rate. With some effort though, one could 
>make this work.
>
>But I don't understand how the meter pulse rate can be relayed between 2 
>MGCs that talk SIP, for example in the following tandem-replacement solution:
>
>   Local office - R2 - (MG1, MGC1) - SIP - (MGC2, MG2) - R2 - TAX office
>
>I think an RFC2833-based solution causes less headache. But registering a 
>new RFC2833 event is outside the scope of the MEGACO working group anyway. 
>For registered events, the ability to negotiate the 'telephone-event' 
>codec is already available via MEGACO/SDP.
>
>Adrian Soncodi
>
>
>-----Original Message-----
>From: Aleksandr Ryabin [mailto:[email-masked]]
>Sent: Friday, October 03, 2003 12:56 PM
>To: Soncodi, Adrian; [email-masked]
>Cc: Kevin Boyle; Christian Groves
>Subject: RE: [Megaco] CAS Metering Pulse support
>
>
>Proposed new metd package will have functionality described in 1).
>
>However I have a slightly different proposal for relaying.
>In order to relay pulses all needed to be known is a repetition interval,
>changes to it, if any, and when to start, and stop metering pulses.
>
>If "receiving" MGC (the one that controls MG which receives
>metering pulses) gets notified with this information using new
>metd package then it can relay this information to "generating"
>MGC (the one that controls MG which generates metering pulses).
>Then "generating" MGC can use amet to start/stop, or modify
>generation of metering pulses.
>
>That is in reality, if repetition interval does not change during
>the call, "receiving" MGC will get only two notifies per call:
>first pulse detected,
>repetition interval calculated (e.g. second pulse detected)
>
>"Generating" MGC will need to send tree modifies:
>pulse once (when first pulse detected event is relayed)
>pulse forever (when repetition interval received)
>stop pulse generation (when call terminates)
>
>Regards,
>          Aleks
>
>At 01:12 PM 10/3/2003, Soncodi, Adrian wrote:
> >In some countries a tandem switch is required to propagate meter pulses
> >(backwards) from the outgoing R2 trunk to the incoming R2 trunk. These
> >pulses are used for billing. A potential problem is that the pulse rate
> >may be very high, sometimes it can be a sub-second interval. Therefore, a
> >tandem MGC which has a considerable number of R2 trunks will have a big
> >overhead for propagating meter pulses, which will affect its call
> >processing rate.
> >
> >So I'm wondering if anything can be done about this. Here are two
> >possibilities:
> >
> >1) Allow the MG to detect meter pulses but report them in chunks of N. By
> >default, N=1 (report every pulse), but the MGC could also select, say,
> >N=10, in which case the MG reports once every 10 pulses. (A residual pulse
> >count could be reported on Subtract). This method saves a lot of NTFY
> >messages. However, on the other side, the MGC would be forced to propagate
> >the pulses as bursts-of-N, and I am not sure a switch is allowed to
> >transform constant-rate pulsing into bursts. (On the other hand why not?
> >because it's only the total pulse count that is relevant for charging.
> >Time-of-day periods with higher charging rates actually result in more
> >meter pulses.)
> >
> >2) Define a mode which allows the meter pulses to be propagated directly
> >between MGs, without MGC involvement, i.e. by a method similar to RFC2833.
> >RFC2833 does not currently have an event defined for meter pulses, but it
> >could be extended, since it defines a lot of signaling-related tones
> >anyway. In addition to solving the NTFY messaging overhead, this method
> >would have the side benefit that it would also work between two MGCs that
> >use SIP or BICC between them. Currently, there is no way to transport
> >meter pulse information in SIP or BICC, and this would have a terrible
> >overhead anyway.
> >Of course, the ability to detect meter pulses is still required, because
> >there is always the possibility that the MGC must perform the
> >meter-pulse-based charging itself (rather than propagate).
> >
> >Any other ideas or comments?
> >
> >Adrian Soncodi
> >
> >
> >
> >-----Original Message-----
> >From: Christian Groves [mailto:[email-masked]]
> >Sent: Thursday, October 02, 2003 10:38 PM
> >To: Aleksandr Ryabin
> >Cc: [email-masked]; Kevin Boyle
> >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
> >
> >This email and any files transmitted with it are confidential and intended
> >solely for the use of the individual or entity to whom they are
> >addressed.  If you are not the intended recipient you are notified that
> >disclosing, copying, distributing or taking any action in reliance on the
> >contents of this information is strictly prohibited.  If you have received
> >this email in error please notify the sender and delete the email.
> >
> >Santera, a Tekelec Company
> >http://www.santera.com
> >972-461-4100
>
>
>This email and any files transmitted with it are confidential and intended 
>solely for the use of the individual or entity to whom they are 
>addressed.  If you are not the intended recipient you are notified that 
>disclosing, copying, distributing or taking any action in reliance on the 
>contents of this information is strictly prohibited.  If you have received 
>this email in error please notify the sender and delete the email.
>
>Santera, a Tekelec Company
>http://www.santera.com
>972-461-4100

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

---

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

Hello,

As Aleks said RTP is not in the scope of this working group. I believe the 
correct way to move this forward is to write a IETF draft of the carriage of 
metering pulses over RTP and submit it to the AVT WG for comment.

Regards, Christian

Kushanava Laha wrote:

> Is it possible for this WG to convey this (metering
> pulse via RTP) as a requirement to the relevant WG?
> 
> 
> --- Aleksandr Ryabin <[email-masked]> wrote:
> 
>>Hi,
>>
>>>The pulse rate can change during the call. This is
>>
>>done by the switch 
>>
>>>downstream, which is the TAX office, and which
>>
>>changes the rate based on 
>>
>>>time-of-day and provisioned charge rates. This
>>
>>means that the receiving MG 
>>
>>>would also neeed an event for pulse rate change. A
>>
>>little more overhead 
>>
>>>will occur, but I guess it is acceptable. However,
>>
>>it becomes delicate 
>>
>>>when the pulse rate decreases: by the time the
>>
>>receiving MG detects the 
>>
>>>lower pulse rate, the generating MG has already
>>
>>generated a number of 
>>
>>>extra pulses, based on the higher rate. With some
>>
>>effort though, one could 
>>
>>>make this work.
>>>
>>>But I don't understand how the meter pulse rate can
>>
>>be relayed between 2 
>>
>>>MGCs that talk SIP, for example in the following
>>
>>tandem-replacement solution:
>>
>>>  Local office - R2 - (MG1, MGC1) - SIP - (MGC2,
>>
>>MG2) - R2 - TAX office
>>
>>>I think an RFC2833-based solution causes less
>>
>>headache. But registering a 
>>
>>>new RFC2833 event is outside the scope of the
>>
>>MEGACO working group anyway. 
>>
>>>For registered events, the ability to negotiate the
>>
>>'telephone-event' 
>>
>>>Proposed new metd package will have functionality
>>
>>described in 1).
>>
>>>However I have a slightly different proposal for
>>
>>relaying.
>>
>>>In order to relay pulses all needed to be known is
>>
>>a repetition interval,
>>
>>>changes to it, if any, and when to start, and stop
>>
>>metering pulses.
>>
>>>If "receiving" MGC (the one that controls MG which
>>
>>receives
>>
>>>metering pulses) gets notified with this
>>
>>information using new
>>
>>>metd package then it can relay this information to
>>
>>"generating"
>>
>>>MGC (the one that controls MG which generates
>>
>>metering pulses).
>>
>>>Then "generating" MGC can use amet to start/stop,
>>
>>or modify
>>
>>>That is in reality, if repetition interval does not
>>
>>change during
>>
>>>the call, "receiving" MGC will get only two
>>
>>notifies per call:
>>
>>>first pulse detected,
>>>repetition interval calculated (e.g. second pulse
>>
>>detected)
>>
>>>pulse once (when first pulse detected event is
>>
>>relayed)
>>
>>>>In some countries a tandem switch is required to
>>
>>propagate meter pulses
>>
>>>>(backwards) from the outgoing R2 trunk to the
>>
>>incoming R2 trunk. These
>>
>>>>pulses are used for billing. A potential problem
>>
>>is that the pulse rate
>>
>>>>may be very high, sometimes it can be a
>>
>>sub-second interval. Therefore, a
>>
>>>>tandem MGC which has a considerable number of R2
>>
>>trunks will have a big
>>
>>>>overhead for propagating meter pulses, which will
>>
>>affect its call
>>
>>>>processing rate.
>>>>
>>>>So I'm wondering if anything can be done about
>>
>>this. Here are two
>>
>>>>possibilities:
>>>>
>>>>1) Allow the MG to detect meter pulses but report
>>
>>them in chunks of N. By
>>
>>>>default, N=1 (report every pulse), but the MGC
>>
>>could also select, say,
>>
>>>>N=10, in which case the MG reports once every 10
>>
>>pulses. (A residual pulse
>>
>>>>count could be reported on Subtract). This method
>>
>>saves a lot of NTFY
>>
>>>>messages. However, on the other side, the MGC
>>
>>would be forced to propagate
>>
>>>>the pulses as bursts-of-N, and I am not sure a
>>
>>switch is allowed to
>>
>>>>transform constant-rate pulsing into bursts. (On
>>
>>the other hand why not?
>>
>>>>because it's only the total pulse count that is
>>
>>relevant for charging.
>>
>>>>Time-of-day periods with higher charging rates
>>
>>actually result in more
>>
>>>>meter pulses.)
>>>>
>>>>2) Define a mode which allows the meter pulses to
>>
>>be propagated directly
>>
>>>>between MGs, without MGC involvement, i.e. by a
>>
>>method similar to RFC2833.
>>
>>>>RFC2833 does not currently have an event defined
>>
>>for meter pulses, but it
>>
>>>>could be extended, since it defines a lot of
>>
>>signaling-related tones
>>
>>>>anyway. In addition to solving the NTFY messaging
>>
>>overhead, this method
>>
>>>>would have the side benefit that it would also
>>
>>work between two MGCs that
>>
>>>>use SIP or BICC between them. Currently, there is
>>
>>no way to transport
>>
>>>>meter pulse information in SIP or BICC, and this
>>
>>would have a terrible
>>
>>>>overhead anyway.
>>>>Of course, the ability to detect meter pulses is
>>
>>still required, because
>>
>>>>there is always the possibility that the MGC must
>>
>>perform the
>>
>>>>meter-pulse-based charging itself (rather than
>>
>>propagate).
>>
>>>>From: Christian Groves
>>[mailto:[email-masked]]
>>
>>>>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 
> 
> === message truncated ===
> 
> 
> =====
> Kushanava Laha
> Hughes Software Systems
> 
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Shopping - with improved product search
> http://shopping.yahoo.com
>

---

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

Hello,

Regards, Christian

---

From: Kushanava Laha <[email-masked]>
Date: Fri, 3 Oct 2003 12:28:47 -0700 (PDT)

=====
Kushanava Laha
Hughes Software Systems

---

From: Kushanava Laha <[email-masked]>
Date: Fri, 3 Oct 2003 12:28:47 -0700 (PDT)

=====
Kushanava Laha
Hughes Software Systems