Subject: MEGACO and Dial Pulse Lines

From: John Donak <[email-masked]>
Date: Wed, 12 Apr 2000 16:29:59 -0400

All Call Flows I have seen use DTMF for digit dialing. The MG collects the
digits from the originator, based on the DigitMap, and then contacts the
MGC.

How about for Dial Pulse (Rotary) phones behind a Residential Gateway? They
still exist.

Is each individual onhook/offhook reported to the MGC, which performs the
timing/collection? This seems very message intensive.

Or is the Gateway expected to perform the timing/collection? If so, how does
it know the required timing characteristics for the market it is in; I have
not seen a "Dial Pulse" Package.

        Regards,

                        John

John Donak
Catena Networks
Voice:  (613) 599-6430 x488     Email: [email-masked]
Fax:    (613) 599-6433          URL:  www.catenanet.com

---

From: "Glasgow, George" <[email-masked]>
Date: Wed, 12 Apr 2000 18:01:23 -0400

Mike,
Typically a class 5 switch will use the same dial plan for rotary and DTMF.
Of course dial-pulse phones can't dial "*" or "#", so their access codes are
typically preceded by "11". There is nothing to prevent a DTMF subscriber
also using "11" instead of the "*" or "#". The main difference between
dial-pulse and DTMF is usually at the line interface, which is programmable.
Also, dial-pulse subscribers pay a lower line rental for some obscure
reason.

So, a dial-pulse subscriber is provisioned as such via MML, and this in turn
leads to the line interface being programmed accordingly.

When a dial-pulse subscriber dials, the line interface circuitry handles the
dial pulse timing and, hence, digit detection. Once a digit has been dialed,
the digit info is then passed on for further processing in the switch.

Note that dial-pulse subscribers can actually connect DTMF phones to their
lines, but if they use them, then the switch will detect that they are using
DTMF on a dial-pulse provisioned port. This is flagged at the switch as a
"DTMF violation". As mentioned, since dial-pulse subscribers typically pay a
lower line rental cost, flagging this allows the switch operator to recover
potential lost revenue.

With respect to the discussion, I agree with the MG handling the dial-pulse
timing, but it must also be able to detect DTMF even though dial-pulse is
provisioned. I expect that we will have to do this to remain transparent
with existing class 5 switches. I hope that we can utilize the same digit
map for both.

Regards,

George Glasgow
Senior Engineer - SRX-3000 Development
Unisphere Solutions,
900 Broken Sound Parkway, B12S,
Boca Raton, FL 33487,
USA
1-561-955-6555 Voice
1-561-955-6477 Fax

[email-masked] <mailto:[email-masked]>

Visit us on the web at: http://www.unispheresolutions.com

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Wednesday, April 12, 2000 5:39 PM
To: [email-masked]
Subject: Re: MEGACO and Dial Pulse Lines

Having the MG do the digit collection even for
pulse seems completely reasonable. If I recall
correctly, the only difference between pulse and
DTMF is that the switch has a different dial plan
for pulse phones vs. DTMF phones. I don't know
whether that's a statically provisioned thing
within the switch's profile for the line, or
whether it dynamically determines whether it's
a rotary phone given the first pulse dial
digit it sees for the call.

If it's the former, I don't think you need any
difference in digit packages at all. If it's the
latter, the MGC would need to differentiate pulse
from DTMF and send down a different digit map
once it can decide.

I hope it's the former. The latter is a whole lot
of work for not much gain.

        Mike

Rosen, Brian writes:
 > Well you are correct that there is no dial pulse package yet.
 > I imagine that if there was:
 >         It would assume the MG does the timing, not the MGC
 >                 This means digitmaps should work, and the call flows
 >                 are really close to what you would see
 >         It would have properties defining the timing with some
 >                 provisioned defaults
 >
 > Why don't you propose one along these lines!
 >
 > Brian
 >
 >
 > > -----Original Message-----
 > > From: John Donak [mailto:[email-masked]]
 > > Sent: Wednesday, April 12, 2000 4:30 PM
 > > To: [email-masked]
 > > Subject: MEGACO and Dial Pulse Lines
 > >
 > >

---

From: John Donak <[email-masked]>
Date: Thu, 13 Apr 2000 09:28:06 -0400

I agree with George, since POTS transparency is key.

It appears that a "Dial pulse" package is needed to inform the MG of the
dial pulse characteristics (PPS, Make/Break Ratio). What else?

What is the process for creating such a package? Can anyone create an IETF
draft?

                John

-----Original Message-----
From: Glasgow, George [mailto:[email-masked]]
Sent: Wednesday, April 12, 2000 6:01 PM
To: [email-masked]
Subject: Re: MEGACO and Dial Pulse Lines

Mike,

Regards,

George Glasgow

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Wednesday, April 12, 2000 5:39 PM
To: [email-masked]
Subject: Re: MEGACO and Dial Pulse Lines

        Mike

---

From: Chip Sharp <[email-masked]>
Date: Thu, 13 Apr 2000 09:44:37 -0400

>with existing class 5 switches. I hope that we can utilize the same digit

While I don't see any reason why megaco couldn't support dial pulse
signaling, carrying over such ancient billing anomalies to the packet voice
world seems ridiculous (I know you don't necessarily approve of this, you
are just stating the facts :-).  I imagine that if everyone in an exchange
called their phone company and changed their line to dial pulse, the price
of DTMF dialing would suddenly and mysteriously drop. ;-)

While we are at it, shouldn't we define an SF signaling package?  We could
name it "cc" in honor of Cap'n Crunch.
;-)

>  > > Fax:    (613) 599-6433          URL:  www.catenanet.com

http://www.netaid.org
-------------------------------------------------------------------------
Chip Sharp                 CTO Consulting Engineering
Cisco Systems
Reality - Love it or Leave it.
------------------------------------------------------------------------

---

From: David K Brown <[email-masked]>
Date: Thu, 13 Apr 2000 11:45:24 -0500

I understand and agree, however, the function is useful and extensively
used - here we may have another opportunity for improvement in MEGACO.

Note that the intent of the extended tone is to allow shared tone detectors
within the servicing switch.  At least that was what was intended when the
idea was originated (by Gunnar Korpinen at DanRay or DSC?).

Dave Brown

Vance Shipley <[email-masked]> on 04/13/2000 11:03:03 AM

Please respond to Vance Shipley <[email-masked]>

To:   [email-masked]
cc:    (bcc: David K Brown/MAIN/MC1)

David K Brown writes:
}  ....  Also, the conventional re-originate code (1 sec of "#"  tone)
}  would probably need to be translated to something else for DP phones.

By who's convention is that?  It's a pet peeve of mine that the practice
of using a prolonged '#' tone during an established call seems to be
acceptable to my collegues.  In my mind it is unnecessary, a '#' sent
when there is no called party connected (i.e. they haven't answered or
they have hung up) is common practice and acceptable.  To monitor a
connected call with tone receivers is expensive.  More importantly
though once you create this sort of escape sequence (it's really akin
to the Hayes modem command '+++') you have decided what is and is not
valid customer payload.  Just think about what happens when you tandem
through several networks with this function!

        -Vance

---

From: "Glasgow, George" <[email-masked]>
Date: Thu, 13 Apr 2000 13:17:26 -0400

Vance,
I agree, but it is not the central office switch that is detecting the '#',
it is the equipment at the debit card company.

I suppose it depends on our perspective of where MEGACO will be used. I am
looking at it from the perspective (at least for this particular discussion
item) that the MG will have residential or business connections and it will
be using megaco to communicate with an MGC. If we then want to replace an
existing class 5 central office, then the key will be transparency.
Operating companies will not accept different operation of features just
because they are getting new technology. To them, the subscriber is king.
Nothing must change in how they use their telephone features.

The same thing happened a number of years ago when the new digital class 5
COs (e.g. Siemens' EWSD, Nortel's DMS100) were first installed. Although we
were compliant with the LSSGR from Bellcore (now Telcordia), we still had to
make our switches compliant with AT&T's 1AESS. This was called "1A
Transparency". We will face the very same pressure when we reach the stage
of replacing the existing COs.

I expect that debit card companies will retain their existing equipment
except that it will be connected to a softswitch. It will still operate the
same way as it does now.

Regards,

George Glasgow

-----Original Message-----
From: Vance Shipley [mailto:[email-masked]]
Sent: Thursday, April 13, 2000 1:00 PM
To: Glasgow, George; [email-masked]
Subject: RE: MEGACO and Dial Pulse Lines

}  I agree with Vance that this re-origination code is not sensible.
}
}  Perhaps David was referring to a PBX feature?

It's something that is commonly used in debit card services.

        -Vance

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 13 Apr 2000 13:31:05 -0400

The protocol provides a mechanism: the digit map, with the ability to
indicate if long tones are expected.  Megaco doesn't really have to concern
itself with whether that feature is used in a given implementation.

> From: Glasgow, George [SMTP:[email-masked]]
> Sent: Thursday, April 13, 2000 12:59 PM
> My experience with CO design (subscriber call processing) is that we
> removed the tone receiver from the connection once we had received all
> of the digits. It could be reconnected during a call, but only in special
> circumstances. We never had any special code for handling this
> re-origination
> scenario.
>
> So I don't see how the prolonged '#' will work under normal circumstances,
> given that there is no tone receiver listening for it and current CO
> design
> does not take it into consideration.
>
> Also, if you are connected to an interactive response-type device such as
> a voicemail system, they very often will respond to '#' by selecting a
> particular option on that system. To have one of these systems connected
> to the subscriber at the same time as a tone receiver could (would) be
> rather
> confusing, to say the least.
>
> I agree with Vance that this re-origination code is not sensible.
>
> Perhaps David was referring to a PBX feature?
>
> Regards,
>
> George Glasgow
> From: Vance Shipley [mailto:[email-masked]]
> Sent: Thursday, April 13, 2000 12:03 PM

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 13 Apr 2000 12:33:54 -0500

It seems to me this is an implementation issue.  I assume someone will write
a DP lines package to enable collection of DP digits.  With this in place,
an MGC can include just the DP events in the eventsDescriptor or can include
both DP and DTMF events.

> From: David K Brown [SMTP:[email-masked]]
> Sent: Thursday, April 13, 2000 11:24 AM
> Based on experience with CO development from years gone by:
>
> It seems to me that there is a general issue here, that being whether the
> MEGACO model is focusing on: 1) replicating current capabilities or 2)
> opening the door to utilize legacy resources to access enhanced services
> in
> an improved fashion.  As I understand, option 2 is the intention, whether
> it is stated or not, I am not sure.
>
> In either case, it is necessary to distinguish the stage or state of the
> call to determine whether detection of DTMF tones on a DP subscriber port
> represents a violation of contract.  Commonly (at least in the CO specs I
> designed to X years ago), tone enabled subscribers could use tone or pulse
> phones, however, if a pulse were received first, DTMF tones that appear
> during the called number digit collection process were ignored.  Older
> switches also switched tone detectors in order to share them between
> subscribers (this is why tone service was allowed to be tariffed higher -
> telcos have been careful to preserve this free profit even though DP
> actually should cost more today since tone detectors are on line cards and
> DP is done in software and is always a pain).
>
> All of the forgoing history has a purpose in my questions vis: will MEGACO
> permit mixed DP and tone dialing? and will MEGACO convert DP after
> connection into tone codes to facilitate use of DP phones in customer
> convenience services such as IVR?  could this actually simplify the
> interaction model?  The question of recognizing flash to support service
> initiation rises up again here.  Also, the conventional re-originate code
> (1 sec of "#"  tone) would probably need to be translated to something
> else
> for DP phones.
>
> Dave Brown
> Systems Engineering, Marconi Communications
> 8616 Freeport Pkwy
> Irving TX 75063
> (972)916-4787
> [email-masked]
>
>
>
>
>
> John Donak <[email-masked]> on 04/13/2000 08:28:06 AM
>
> Please respond to John Donak <[email-masked]>
>

---

From: Peter Blatherwick <[email-masked]>
Date: Thu, 13 Apr 2000 10:22:20 -0500

John, list:

Given preceding discussion, I suggest a pulse dialling package should extend
the existing dtmf detection package, simply adding pulse-specific timing
parameters and the DTMF violation error event.  (Anything else?)  Actual
detection would be hidden in the MG, so the MGC would "see" tones.

Package creation is quite straight forward, thankfully.  Just have a look at
some of the existing examples, for instance in the Megaco/H.248 Protocol
document annexes, and follow the pattern.  See Protocol document section 12
for specifics.  Post as Internet-Draft to this list, and watch the fun.  If
IANA registration is not taken up through this WG, it can be done direct
with IANA as outlined in the Protocol doc.  If unfamiliar with I-D creation
and process, see the documentation elsewhere on the IETF web site (see esp.
http://www.ietf.org/ietf/1id-guidelines.txt).

(As an aside, I'm glad to see Megaco discussion of this, as I have a number
of historical phones at home, just 'cause they look sooo cool, and have
pulse service for this.  Also, just kinda fun to @#&& off the phone company
by paying less for something that costs more.  Call me twisted ... I'm quite
used to it ;-)

-- Peter

> From: John Donak [SMTP:[email-masked]]
> Sent: 13 Apr, 2000 09:28

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 14 Apr 2000 15:02:01 -0400

I would think the DP Package would permit a lot of things,
how the MGC chose to use them would be up to it.

Certainly, as has been suggested, an MG implementing DP Package
should be able to recognize digits, distinguishing them from flash
and hook state, and be able to create events the same as,
or equivalent to, DTMF digit detection, including digit maps.

Issues like allowing mixed DP/DTMF is the province of the MGC,
not the MG, and should be supported, but not required in Megaco.

Brian

> From: Brown, David
> opening the door to utilize legacy resources to access
> enhanced services in
> (1 sec of "#"  tone) would probably need to be translated to
> something else
> for DP phones.
>
> Dave Brown
> Of course dial-pulse phones can't dial "*" or "#", so their
> access codes
> are
> So, a dial-pulse subscriber is provisioned as such via MML,
> and this in
> turn
> When a dial-pulse subscriber dials, the line interface
> circuitry handles
> the
> "DTMF violation". As mentioned, since dial-pulse subscribers
> typically pay
> a

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 18 Apr 2000 09:17:49 -0400

I think there are differences in technology that have to be accounted for,
so we may not escape having to distinguish DTMF from DP in separate
packages.  The MGC can't expect a DP set to dial * or #, for instance.  The
billing issue is clearly one of operator policy.  That means we have to
supply the option to support it, not restrict operator actions.

Anyway, the whole question is moot until someone submits a DP package.

> From: Alf Heidermark [SMTP:[email-masked]]
> Sent: Tuesday, April 18, 2000 8:28 AM
> This requriment for billing of the feature cannot be manndatory in all
> networks. This means that the MGC does not have to be aware of whether
> it is pulse or DTMF. The MG must be able to find out itself.
> 
> Stephen Terrill wrote:
> >
> > The only reason that I saw suggested that the MGC needed it was for
> "billling" - not charging, but billing (and that is  very operator
> dependant).  It is not necessary that the billing is done on the MGC, but
> maybe another system again (this is quite common), as such I don´t see why
> the MGC needs to be bothered with such hardware details.
> >
> > Regards,
> >
> > ..//steve
> >
> > "Rosen, Brian" wrote:
> >
> > > Since the MGC needs it, and the MG needs it, you do it in the MGC and
> > > let it program the MG.
> > >
> > > Provisioning might be evil, but it's not totally unavoidable yet!
> > >
> > > Brian
> > >
> > > > From: Stephen Terrill [mailto:[email-masked]]
> > > > Sent: Tuesday, April 18, 2000 1:57 AM
> > > > To: Rosen, Brian
> > > > Cc: [email-masked]
> > > > Hi Brian,
> > > > Now you are just argueing where to do the provisoning, not
> > > > that provisoning can be avoided.  As it has to be done
> > > > somewhere, why the MGC?
> > > >
> > > > ..//steve
> > > >
> > > > "Rosen, Brian" wrote:
> > > >
> > > > > This is another "provision vs. program" argument.
> > > > > Yes, you could provision the timing characteristics.
> > > > > Since I think provisioning is evil, I'd prefer the MGC do it.
> > > > > As was pointed out, the MGC has to know if DTMF is "enabled"
> > > > > on the line, possibly for billing.  Having to have two parts
> > > > > with the same information is a cause of confusion and error.
> > > > >
> > > > > I would think almost all of the MGC code wouldn't know the
> > > > > difference.
> > > > >
> > > > > Brian
> > > > >
> > > > > > From: Stephen Terrill [mailto:[email-masked]]
> > > > > > Sent: Monday, April 17, 2000 3:23 AM
> > > > > > Hi,
> > > > > > I was trying to find the correct message from this thread to
> > > > > > respond to, so I would hitch it onto this.
> > > > > >
> > > > > > I would think that MGC shouldn´t be concerned with how the
> > > > > > digits were detected.  The MGC is requesting to detect
> > > > > > digits, and wether they are pulsed or DTMF shouldn´t matter -
> > > > > > this is matter of hardware.
> > > > > >
> > > > > > Of course there is an issue of configuration, to have the
> > > > > > terminal adapter (or line card) to be set for the type of
> > > > > > subcriber, however I haven´t viewed H.248 as a configuration
> > > > > > protocol - I understood that was done in other ways.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > ..//steve
> > > > > >
> > > > > > "Rosen, Brian" wrote:
> > > > > >
> > > > > > > Anyone can create a DRAFT.  Just write it up in the
> > > > proper format
> > > > > > > and email it to the Internet Drafts editor.
> > > > > > >
> > > > > > > Now, if you want IETF to DO anything with it, some working
> group
> > > > > > > (for example, Megaco) has to adopt it as a work item, and
> agree
> > > > > > > to turn it into an rfc (through it's consensus process).  I'd
> > > > > > > suspect we would be willing to do this for a dial pulse
> package,
> > > > > > > but that is up to the group to decide.
> > > > > > >
> > > > > > > Brian
> > > > > > > >
> > > > > >
> > > > << File: Card for Alf  Heidermark >>