Subject: RE: [Megaco] CAS Metering Pulse support

From: Aleksandr Ryabin <[email-masked]>
Date: Tue, 23 Dec 2003 09:47:15 -0500

Hi all,

Per this email thread I've put together the following document

http://[email-masked]/av-arch/avc-site/0401_Gen/Working/DC-xxx_H.248.26.metd.zip

Summary

This temporary document proposes an amendment to H.248.26
Enhanced Analog Line Packages to include new Metering Pulse
Detection Package and to extend Automatic Metering Package
to be used for digital lines.

This document will be presented to ITU-T in next meeting in Jan 2004
Please review and send comments.

Thanks
         Aleks

At 09:05 AM 10/6/2003, Kevin Boyle wrote:
>There is a 2833-bis draft out now that proposes some extensions to the set
>of detectable events under RFC2833.  If we want CAS metering included (and
>from reading all this, I think we do), then someone needs to contact the
>authors of the 2833-bis document and get the CAS metering stuff added.
>
>The 2833-bis draft can be found at
>http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bis-03.txt.
>
>Kevin
>
>-----Original Message-----
>From: Christian Groves [mailto:[email-masked]]
>Sent: Sunday, October 05, 2003 8:38 PM
>To: [email-masked]
>Cc: Aleksandr Ryabin; Soncodi, Adrian; [email-masked]; Boyle, Kevin
>[NCRTP:3Z40:EXCH]
>Subject: Re: [Megaco] CAS Metering Pulse support
>
>
>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,
> >>
> >>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
> >
> > === message truncated ===
> >
> >
> > =====
> > Kushanava Laha
> > Hughes Software Systems
> >
> > __________________________________
> > Do you Yahoo!?
> > The New Yahoo! Shopping - with improved product search
> > http://shopping.yahoo.com
> >

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

---

From: Aleksandr Ryabin <[email-masked]>
Date: Tue, 23 Dec 2003 09:47:15 -0500

Hi all,

Summary

Thanks
         Aleks

---

From: [email-masked]
Date: Wed, 24 Dec 2003 13:27:27 +0530

Hi Aleks,

I feel that following should also be taken care in the package procedures.

(A) If the new events descriptor only contains one of these events
         (pr/ric), then the existing events, different from pr/ric, should
         not be effected. As per the protocol rules they will get
         disabled.
(B) Not much clarity on the following statement
"It is noted that care should be taken to specify desired KeepActive flag
         ............"
Are there possible scenarios where the use of KA flag may not be required.
         If not, then should MG report some error and what would be the
         error code?
similarly for the EventBufferControl property.

Regards
Sachin Gupta

Aleksandr Ryabin <[email-masked]>@ietf.org on 12/23/2003 08:17:15 PM

Sent by:    [email-masked]

To:    [email-masked]
cc:    Christian Groves <[email-masked]>, Kushanava
       Laha/HSS@HSS, "Soncodi, Adrian" <[email-masked]>, "Kevin
       Boyle" <[email-masked]>

Hi all,

Summary

Thanks
         Aleks