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:
[email protected]
with the single line:
unsubscribe emc-pstc
For help, send mail to the list administrators:
Jim Bacher: [email protected]
Michael Garretson: [email protected]
For policy questions, send mail to:
Richard Nute: [email protected]
