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