URGENT question on draft-ietf-avt-tones-07

Gunnar Hellstrom gunnar.hellstrom at OMNITOR.SE
Sat Feb 12 07:36:18 EST 2000


Steve and all,
Thank you for making the observation of the double nature of CRd and MRd.
The same cahnges as you have done, I need to do in the Call Type
Discrimination package of H.248 discussed now in SG16.

When looking through avt-tones, I saw that the example showing different
signals displayed V.21 bits 10 times longer than they usually are.

This is the table from avt-tones-07

------------------------------Table with
errors---------------------------------------
          Tone name             frequency  on period  off period
          ______________________________________________________
          CNG                        1100        0.5         3.0
          V.25 CT                    1300        0.5         2.0
          CED                        2100        3.3          --
          ANS                        2100        3.3          --
          ANSam                   2100*15        3.3          --
          V.21 "0" bit, ch. 1        1180      0.033
          V.21 "1" bit, ch. 1         980      0.033
          V.21 "0" bit, ch. 2        1850      0.033
          V.21_"1"_bit,_ch._2________1650______0.033____________
          ITU dial tone               425         --          --
          U.S. dial tone          350+440         --          --
          ______________________________________________________
          ITU ringing tone            425  0.67--1.5        3--5
          U.S._ringing_tone_______440+480________2.0_________4.0
          ITU busy tone               425
          U.S. busy tone          480+620        0.5         0.5
          ______________________________________________________
          ITU congestion tone         425
          U.S. congestion tone    480+620       0.25        0.25


   Table 7: Examples of telephony tones
----------------------------------------------------------------------------
------------------
If the V.21 bits are aiming at being used for 300 bit/s V.21, that is the
most common case, they should be specified to have a length of 0.0033 or
rather 0.00333 seconds if you can support that precision.

Agree?

-----
Comment on your original topic - the V.8 bis signals.
In your message, you have 1375 Hz and 1357 Hz. They should both be the same
and be 1375. That is also correct in avt-tones-07, so - no problem.

About timing of these tones, V.8 bis is a bit fuzzy,saying that 400 ms is
preferred but for some cases, not to cause interworking problems with
existing devices it can be reduced to 280 ms. I do not know what is behind
that, and do not understand how the DCE can select between these two cases,
so I hope that your single timing of 400 ms is OK. Maybe Bruce Adams,
rapporteur of Q4/16 and in charge of V.8 bis maintenance can comment on
that.
-----



Regards

Gunnar Hellström

> -----Original Message-----
> From: casner at cisco.com [mailto:casner at cisco.com]
> Sent: Friday, February 11, 2000 10:40 PM
> To: rem-conf at es.net; ITU-SG16 at mailbag.cps.intel.com
> Cc: Henning Schulzrinne
> Subject: URGENT question on draft-ietf-avt-tones-07
>
>
> To the IETF AVT working group and ITU SG16:
>
> --> Interested parties need to respond by end of day PST Monday 2/14 <--
>
> The following has come up during IESG discussion of the
> draft-ietf-avt-tones-06.txt document:
>
> > In section 3.11 there are two events (CRd and MRd) where the signals
> > are different for the initiator and the responder.
> > This implies that the entity doing the translation between
> audio and events
> > need to be aware of the higher layer roles of the communicating peers.
> > Is this a reasonable assumption?
>
> This appears to be a valid concern that we did not realize in the
> working group review of this document.  One would want the gateway
> that is doing the translation from an event to a tone to not be
> required to know the higher layer roles.
>
> It would be possible to give two different codepoints to each of these
> events.  I don't know if there has already been enough implementation
> of this protocol that this would cause a problem, and the purpose of
> this message is to find out.  Given that the modem and fax tones were
> added fairly late in the development of the draft, I suspect is would
> not be a problem to add two codepoints in that section (32-47) without
> changing the other sections.
>
> The author (Henning Schulzrinne) agreed:
>
> > This is at least ambiguous, particularly for a "pass-through" gateway
> > that's pretty clueless as to call state. There are effectively four tone
> > sequences
> >
> > 1375/2002 followed by 1150
> > 1529/2225 followed by 1150
> > 1357/2002 followed by 1900
> > 1529/2225 followed by 1900
> >
> > My suggestion would be to split the Crd and Mrd into Crdi and Crdr for
> > the initiating and responding side. Same for the other pair.
>
> The draft has been revised to make this split, so the codepoints 41-49
> are now different.  The revised draft has been submitted but is
> available in the meantime as:
>
> http://www.cs.columbia.edu/~hgs/rtp/drafts/draft-ietf-avt-tones-07.txt
> http://www.cs.columbia.edu/~hgs/rtp/drafts/draft-ietf-avt-tones-07.ps
>
> I believe that, subject to this change, the draft has been approved by
> the IESG.  If there are no objections from the working group by the
> end of the day PST on Monday (2/14), then I will give our OK for the
> -07 draft be sent to the RFC editor.  This is a very short response
> time, but our goal is to get the RFC number assigned before the end of
> the SG16 meeting on 2/18.  To those at the SG16 meeting, please call
> this issue to the attention of interested parties that might not have
> seen this message.
>                                               -- Steve Casner
>
>
>
______________________________________
Gunnar Hellström
Omnitor AB
Alsnögatan 7, 4tr
S-116 41 Stockholm
Sweden

Mob +46 708 204 288
Tel +46 8 556 002 03
Fax +46 8 556 002 06
Video +46 8 556 002 05
Txt (All kinds) +46 8 556 002 05
E-mail gunnar.hellstrom at omnitor.se
WWW:     http://www.omnitor.se



More information about the sg16-avd mailing list