Subject: Re: Meaning Of BR Signal Type

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 2 Feb 2000 08:22:13 -0600

It's a point of view.  If you want to change the DTMF digit into a long
tone, you also override the type by setting it to TO.  This certainly isn't
a crucial issue, but in my mind at least it would increase the justification
for distinguishing BR from TO.

> -----Original Message-----
> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: Tuesday, February 01, 2000 6:47 PM
> To:   [email-masked]
> Subject:      Re: Meaning Of BR Signal Type
>
> I don't agree with this.  Every signal has a duration, and the DEFAULT may
> be
> provisioned, but it can be overridden.  The MGC should be able to override
> the
> default.  Certainly something like a DTMF digit has to be able to be
> overridden to generate a "long tone" for example.
>
> I'd accept that some MGs may not be able to do this, but I expect that
> won't
> be much of a problem.
>
> Brian
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:[email-masked]]
> > Sent: Tuesday, February 01, 2000 2:31 PM
> > To: [email-masked]
> > Subject: Meaning Of BR Signal Type
> >
> >
> > This one has been flogged nearly to death, but from recent
> > discussions I
> > think we have the following understanding of the BR signal type.
> >
> > BR: the duration is known to the MG (either by provisioning
> > or by design).
> > The MGC must not specify a duration.
> >
> > I would propose that this definition replace the current text
> > in section
> > 7.1.11.
> >
> >
> > Tom Taylor
> > Advisor -- IPConnect Standards
> > E-mail: [email-masked] (internally, Tom-PT Taylor)
> > Phone and FAX: +1 613 736 0961
> >

---

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

While it would work, I don't particularly like the idea of making the
long tone digit a TO signal . The problem is that the current
definitions in E.3.3 and E.5.3 seems to show provisioned not as the
default but as the only choice for BR duration. I would prefer we allow
for specifying a duration as an override to provisioning in the text in
7.1.11 .

Also, I just noticed that the duration was changed from milliseconds to
hundredths. I guess I missed the discussion, but don't understand why
that was done.

Michael

"Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:

>
>
> It's a point of view.  If you want to change the DTMF digit into a
> long tone, you also override the type by setting it to TO.  This
> certainly isn't a crucial issue, but in my mind at least it would
> increase the justification for distinguishing BR from TO.
>
>      I'd accept that some MGs may not be able to do this, but I expect
>      that won't
>      be much of a problem.
>
>      Brian
>

---

From: Christian Groves <[email-masked]>
Date: Tue, 8 Feb 2000 15:31:12 +0100

G'Day Michael,

It was because with the timeout period being a 16bit integer and the
time period being in millseconds, you could only play a signal for
approx 64,0000ms or 64secs.
Hundreth's of a second at least gives you 10x the amount. Perhaps the
value should be double int?

Cheers, Christian

Michael Brown wrote:
> default but as the only choice for BR duration. I would prefer we
> allow for specifying a duration as an override to provisioning in the
> text in 7.1.11 .
>
> Also, I just noticed that the duration was changed from milliseconds
> to hundredths. I guess I missed the discussion, but don't understand
> why that was done.
>
> Michael
>
> >      I'd accept that some MGs may not be able to do this, but I
> >      expect that won't
> >      be much of a problem.
> >
> >      Brian
> >