Subject: Re: MEGACO and Dial Pulse Lines

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

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]>

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

Subject:  Re: MEGACO and Dial Pulse Lines

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,
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
 > >
 > >
 > > 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: Vance Shipley <[email-masked]>
Date: Thu, 13 Apr 2000 12:03:03 -0400

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