Gary,
My firm makes video-phone related products. Each has a
basic rate ISDN interface. Traditionally, for the EEC
we have tested to ETSI specs TBR3 (network signalling)
and TBR8 (audio). Since April this year, we have been
able to use existing approvals and self declare for
the new kit, but we still use the TBRs as a baseline.
Where we supply a complete product, we can control all
the sequences and levels. However, some of our product
is supplied to OEMs who add their own top level applications
software. With our PC add-in card, we ensure that our
low-level software limits encoded audio and, using
watchdog handshaking, if the PC hangs then the call
will be cleared down.
ISDN is based on the ITU standards but there are many
subtle variants, each of which requires a different
build of the software. If we provide a handset, the FCC
requires that it is hearing-aid compatible. The acoustic
and magnetic characteristics of earpieces may require slight
gain tweaks at certain frequencies to meet both of the
frequency response masks.
As with EMC testing, we take several different PCs which we 
believe to be representative of those available, do lots of 
testing, fix any bugs and do lots more testing.
Even if you meet all the specifications, there is bound to
be someone providing a telephone network interface which
is slightly different from the rest of the world. Solving
the problems is the fun bit of engineering.

On this side of the pond, we vote by using a graphite pencil
to mark an X in a box on a voting slip, by our preferred
candidate's name. All votes are hand counted. If the result is
close for the leading candidates, then the votes are usually
re-counted - again by hand and mark one eyeball.

Kind regards,

Geoff Lister
Senior Engineer
Motion Media Technology Ltd.,
Bristol, UK.
http://www.motion-media.com 


-----Original Message-----
From: Gary McInturff [mailto:gary.mcintu...@worldwidepackets.com]
Sent: 15 November 2000 16:49
To: 'Geoff Lister'
Cc: emc-p...@ieee.org
Subject: RE: FW: Compliance of a USB telephone


Morning Geoff,
        The copper interface has been my only point, and the USB phone
doesn't have it. I agree and said, in an apparently round-about method, the
part that really is phone-like has to operate like a phone, including
billing, acoustic, tear-down and set-up as you mention below. No question I
agree, but the RTT & E defines itself with by having metallic connections to
the public system. I suppose the real question is how do those phone
functions get verified and by whom? Got me, but there must be, or at least
should be in my opinion, some standard for phones that talks about
functionality and not the interface. But I do see your point, but the RTT&E
still identifies in its scope items that have a direct metallic interface. 
        You bring up another good point. I wasn't aware that the modem
manufacturers are pushing the process deeper into the CPU but that neither
relieves them from their standards obligations nor does it obligate the CPU
manufacturer to pretend they are a phone manufacturer because somebody
"might" install hardware or software, and USB phones don't have to pretend
they are modems. There is some overlap but the aren't responsible for each
other's differences.
        The most important point is that it isn't the responsibility of the
PC manufacturer to look around and divine what applications are out there
that could possible turn his computer into a phone, nor do they have to go
through all of the officiating bodies that care about phone standards. In
fact this would be redundant because the real phone manufacturer, including
hardware and software if any, has already been required to do so.
        That is the same point I am trying to make. The USB phone doesn't
have to go through the RTT&E standard  to test the copper interface because
the people who actually make the copper interface in whatever form already
have to do that. 
        The point of demarcation, in my opinion, is that you have to test
all of the stuff that makes your equipment work, but nothing more than that.
The PC is a general utility piece of equipment, without any standard
interconnects to the phone lines. Test it as a PC, including EMC and Safety.
If you build a phone test it as a phone not as a PC, if you build a copper
interface then test it as such by emulating the signals in and signals and
measuring them going out, and do dielectrics etc. If what you build has all
three elements as a single unit then run the full gammed of tests, but don't
try to impose those problems on those that don't manufacture a device that
is not phone, computer, and copper interface. 
        20 years or so ago, a friend who was trying to remotely load
software via a modem, forgot to terminate the call before he left the
office, and was sent a long distance bill for across the US that was 18
hours long. So the hang up problem isn't new nor strictly due to moving the
functional software from the modem to the PC.
        George, the people that are wiser and more knowledgeable you refer
to are not magic they come from our ranks and they get there by engaging in
exactly these types of discussions and forums, and mostly they are right but
sometimes they are not particularly as technology changes. As much as I hate
to admit it I occasionally am wrong as well but it shouldn't keep us from
engaging in discourse about the topic in order to get it correct.
        I thoroughly enjoy these discussions because it enhances my
knowledge and brings differing viewpoints and experiences to the problem.
While this discussion hasn't really solved the problem yet, it certainly has
affected my viewpoint and deepened my understanding. 
        Gary
        PS Tomorrow we'll talk about presidential vote counting manual
versus machine, or are you a Democrat or a Republican? AS you can imagine I
have an opinion about that as well.
<snip>  

-------------------------------------------
This message is from the IEEE EMC Society Product Safety
Technical Committee emc-pstc discussion list.

To cancel your subscription, send mail to:
     majord...@ieee.org
with the single line:
     unsubscribe emc-pstc

For help, send mail to the list administrators:
     Jim Bacher:              jim_bac...@mail.monarch.com
     Michael Garretson:        pstc_ad...@garretson.org

For policy questions, send mail to:
     Richard Nute:           ri...@ieee.org

Reply via email to