Subject: Re: Cisco SG16: Annex E comments

From: Peter Blatherwick <[email-masked]>
Date: Thu, 3 Feb 2000 10:37:05 -0600

Actually, we're talking about E.6 here, DTMF Detection Package, aren't we?
(Not E.4)

While I certainly agree with the general all-or-nothing approach in
packages, this must always be balanced with not burdening low cost devices
if at all possible.  In this case though, I expect virtually all real life
implementations would be DSP based or equivalent, so there is no cost
difference to support the full range of tones.  Therefore, I support single
DTMF detection package with da-dd support mandatory.

I should point out though that this is not the same logic that led to the
current text as we worked it through at Red Bank.  If I remember correctly
(adjust time-frame to 03:00 or so ;-), we reasoned that actual application
use of da-dd is quite uncommon, and if the MGC really needed da-dd, it could
audit to figure out if its supported by doing AuditCap(ObservedEvents).  We
therefore opted to make this range optional, to not burdening all for the
needs of few and not creating extra packages.

I prefer the mandatory solution, since I think its cleaner, but if there's
any objection at all on cost basis then we should revert to keeping it
optional as it is now, following Red Bank logic.  I'm ok with either really,
but would not favour creation of an extra package.

NOTE: A very similar issue arises in E.5, Basic DTMF Generator Package, but
nothing is said about optional tones.  This may be a mistake, since I think
the original intent was to use the same approach here.  Whichever way the
decision on E.6 goes, E.5 should be the same.  Following the same logic as
above, we should simplify and make da-dd mandatory in E.5 as well (ie no
change from the way it is now).  Again, i'm ok with either.

Another tiny nit on these: E.6 title should be "Basic DTMF Detection
Package", to line up with E.5.

BTW, in general IP Phone would not use Tone Detect, but Res GWs certainly
would.  Both would use Tone Generate.

-- Peter

> -----Original Message-----
> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: 3 Feb, 2000 09:07
> To:   [email-masked]
> Subject:      Re: Cisco SG16: Annex E comments
>
> I'm okay with making da-dd mandatory.  I suppose it's a residential GW
> and/or IPPhone that might care.
> The packetcable stuff makes it mandatory, right?  Any reaction from the
> IPPhone folks?
>
> Brian
>
>       -----Original Message-----
>       From: Tom-PT Taylor [mailto:[email-masked]]
>       Sent: Wednesday, February 02, 2000 3:18 PM
>       To: [email-masked]
>       Subject: Re: Cisco SG16: Annex E comments
>
>
>
>       Another issue, which has been discussed.  The package is broken as
> it stands -- the MGC cannot tell whether the da-dd events are supported.
> We have three alternatives: the two Chip proposes, or keep things as they
> are and add a global read-only property which indicates whether da-dd are
> supported.  I favour making support of da-dd mandatory, on the ground that
> the phone types served by the MG are independent of the MG itself.
>
>               -----Original Message-----
>       From:   Chip Sharp [SMTP:[email-masked]]
>       Sent:   Tuesday, January 25, 2000 8:18 PM
>       [[TomT]]  snip
>       Section:        E.4
>       Category:       Technical
>       Issue:          The draft text specifies that "Support of dA-dD is
> optional".
>       Having optional events in a package tends to defeat the purpose of
> packages
>       in the first place.
>       Proposal:       It is recommended that either support for the
> signals become
>       mandatory or they are provided in a separate package.
>
>               v13 Status:     OPEN. No relevant text changed.
>
>

---

From: Michael Brown <[email-masked]>
Date: Mon, 7 Feb 2000 10:27:16 -0500

Just to toss in a view from the large res line GW side of the issue, I
also have no problem with making dA-dD a mandatory part of both
generation and detection. The Res Line GW needs them for support of ADSI
services. It's hard to imagine that there are DTMF detection devices
which don't support all of DTMF based on cost.

Michael

"Blatherwick, Peter (P.) [EXCHANGE:CAR:AT14]" wrote:

>
>
> Actually, we're talking about E.6 here, DTMF Detection Package, aren't
> we?  (Not E.4)
>
> packages, this must always be balanced with not burdening low cost
> devices if at all possible.  In this case though, I expect virtually
> all real life implementations would be DSP based or equivalent, so
> there is no cost difference to support the full range of tones.
> Therefore, I support single DTMF detection package with da-dd support
> mandatory.
>
> I should point out though that this is not the same logic that led to
> the current text as we worked it through at Red Bank.  If I remember
> correctly (adjust time-frame to 03:00 or so ;-), we reasoned that
> actual application use of da-dd is quite uncommon, and if the MGC
> really needed da-dd, it could audit to figure out if its supported by
> doing AuditCap(ObservedEvents).  We therefore opted to make this range
> optional, to not burdening all for the needs of few and not creating
> extra packages.
>
> I prefer the mandatory solution, since I think its cleaner, but if
> there's any objection at all on cost basis then we should revert to
> keeping it optional as it is now, following Red Bank logic.  I'm ok
> with either really, but would not favour creation of an extra package.
>
> NOTE: A very similar issue arises in E.5, Basic DTMF Generator
> Package, but nothing is said about optional tones.  This may be a
> mistake, since I think the original intent was to use the same
> approach here.  Whichever way the decision on E.6 goes, E.5 should be
> the same.  Following the same logic as above, we should simplify and
> make da-dd mandatory in E.5 as well (ie no change from the way it is
> now).  Again, i'm ok with either.
>
> BTW, in general IP Phone would not use Tone Detect, but Res GWs
> certainly would.  Both would use Tone Generate.
>
> -- Peter
>
>
>      I'm okay with making da-dd mandatory.  I suppose it's a
>      residential GW and/or IPPhone that might care.
>      The packetcable stuff makes it mandatory, right?  Any reaction
>      from the IPPhone folks?
>
>      Brian
>           Another issue, which has been discussed.  The package is
>           broken as it stands -- the MGC cannot tell whether the da-dd
>           events are supported.  We have three alternatives: the two
>           Chip proposes, or keep things as they are and add a global
>           read-only property which indicates whether da-dd are
>           supported.  I favour making support of da-dd mandatory, on
>           the ground that the phone types served by the MG are
>           independent of the MG itself.
>
>           Issue:          The draft text specifies that "Support of
>           dA-dD is optional".
>           Having optional events in a package tends to defeat the
>           purpose of packages
>           in the first place.
>           Proposal:       It is recommended that either support for
>           the signals become