Subject: RE: [Megaco] CAS Metering Pulse support

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 3 Oct 2003 09:34:33 -0400

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: "Kevin Boyle" <[email-masked]>
Date: Fri, 3 Oct 2003 09:34:33 -0400

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,

Regards, Christian

---

From: Aleksandr Ryabin <[email-masked]>
Date: Fri, 03 Oct 2003 11:21:26 -0400

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

---

From: Aleksandr Ryabin <[email-masked]>
Date: Fri, 03 Oct 2003 11:21:26 -0400

Hi,

Regards,
         Aleks

---

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?

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
>
> > 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..."
> >
> > (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
> >> pulse functionality. From the description of the event it seems 
> >> that it clear how it to be used.
> >>
> >> 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,
> >>> 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
> >>>>> of those days!)
> >>>>> digital lines as well.
> >>>>> Below are excerpts from a previous exchange related to defining 
> >>>>> of CAS Metering Pulse procedures in MEGACO.
> >>>>>
> >>>>> anyone done and/or planned anything in the direction to define 
> >>>>> CAS Metering Pulse procedures/package for MEGACO?
> >>>>>
> >>>>> Thanks
> >>>>>          Aleks
> >>>>>
> >>>>> >From: [email-masked]
> >>>>> >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 
> >>>>> >this problem common to all CAS signaling. The solution should 
> >>>>> >be sensitive to

---

From: "Soncodi, Adrian" <[email-masked]>
Date: Fri, 3 Oct 2003 12:12:15 -0500

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,

Regards, Christian

Aleksandr Ryabin wrote:
> 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.
> 
>>> 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
>>>>> If it is NOT updated, that is. (Apparently, it's going to be one of 
>>>>> those days!)
>>>>>
>>>>> Kevin
>>>>>
>>>>> Yes it seem to address the needs assuming it is extended to digital 
>>>>> lines as well.
>>>>>
>>>>> Now that CAS packages related work has been moved to ITU has anyone 
>>>>> >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
>>>>> >We are working towards a separate package that addresses this issue.
>>>>> >Any suggestions?
>>>>> ...
>>>>>

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

---

From: Aleksandr Ryabin <[email-masked]>
Date: Fri, 03 Oct 2003 13:56:27 -0400

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.
>
>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).
>
>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.
>

---

From: Aleksandr Ryabin <[email-masked]>
Date: Fri, 03 Oct 2003 13:56:27 -0400

Regards,
         Aleks

---

From: "Soncodi, Adrian" <[email-masked]>
Date: Fri, 3 Oct 2003 13:44:20 -0500

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

Regards,
         Aleks

---

From: "Soncodi, Adrian" <[email-masked]>
Date: Fri, 3 Oct 2003 13:44:20 -0500

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

Regards,
         Aleks

---

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:
>
>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
>
>
> procedure

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 6 Oct 2003 10:05:11 -0400

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]

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: "Kevin Boyle" <[email-masked]>
Date: Mon, 6 Oct 2003 10:05:11 -0400

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]

Hello,

Regards, Christian