From editor@telecom-digest.org Thu Oct  7 22:49:34 2004
Received: (from ptownson@localhost)
	by massis.lcs.mit.edu (8.11.6p3/8.11.6) id i982nYF20634;
	Thu, 7 Oct 2004 22:49:34 -0400 (EDT)
Date: Thu, 7 Oct 2004 22:49:34 -0400 (EDT)
From: editor@telecom-digest.org
Message-Id: <200410080249.i982nYF20634@massis.lcs.mit.edu>
X-Authentication-Warning: massis.lcs.mit.edu: ptownson set sender to editor@telecom-digest.org using -f
To: ptownson
Approved: patsnewlist
Subject: TELECOM Digest V23 #475

TELECOM Digest     Thu, 7 Oct 2004 22:49:00 EDT    Volume 23 : Issue 475

Inside This Issue:                            Editor: Patrick A. Townson

    Telephone Numbers to Words Program (TELECOM Digest Editor)
    Re: Power Device Via UTP? (T. Sean Weintz)
    Re: Power Device Via UTP? (Rick Merrill)
    Re: Power Device Via UTP? (Bob Vaughan)
    Re: VOIP Home Connection (Frank@Nospam.com)
    Anybody Used DCI Telecom Long Distance in Canada? (Darko)
    Re: Pennsylvania Railroad's Crew Communication System? (David Clayton)
    Re: Phishing:  Latest Spam/Scam; Very Dangerous (jdj)
    Re: BART Cop Orders Radio Turned Off to Protect Trains (jdj)

All contents here are copyrighted by Patrick Townson and the
individual writers/correspondents. Articles may be used in other
journals or newsgroups, provided the writer's name and the Digest are
included in the fair use quote.  By using -any name or email address-
included herein for -any- reason other than responding to an article
herein, you agree to pay a hundred dollars to the recipients of the
email.

               ===========================

See the bottom of this issue for subscription and archive details
and the name of our lawyer; other stuff of interest.  

----------------------------------------------------------------------

Date: Thu, 7 Oct 2004 16:45:04 EDT
From: TELECOM Digest Editor <ptownson@telcom-digest.org>
Subect: Telephone Numbers to Words Program

    
A few days ago, someone wrote to the Digest expressing his difficulty
and frustration at finding words/phrases appropriate to his business
and toll free telephone numbers which would work with those words/phrases.

We referred him to Judith Oppenheimer of New York City who has
considerable experience with toll-free 800 numbers, both obtaining
them and keeping them. What I didn't do, however was refer him to
our own archives where we have a program originally written for Unix
computers which does what he was asking about. So I am going to 
reprint it here today for him, or any other reader who wishes to
play with it.

   From ptownson@massis.lcs.mit.edu  Wed Mar 19 09:10:57 1997
   Date: Wed, 19 Mar 1997 09:10:57 -0500 (EST)
   From: ptownson@massis.lcs.mit.edu (TELECOM Digest Editor)
   Subject: Word/Number Program


   Subject: Number/Word Program
   Date: Tue, 18 Mar 97 12:52:09 PDT
   From: rweller@h-e.com
   Organization: Hammett & Edison, Inc.

Pat, 

I am re-sending separately the number/word program in binhex form.  In
case you have problems with it, I am sending the source code in two
parts as plain text. 

Regards,

Bob 


/*-------------------------------------------------------------------
   number2word.c

   Program to find word equivalents to telephone numbers, or convert letter
   strings to numbers.  In number-to-word mode, a search is made for valid
   words based on a list read from a dictionary file.  Optionally, the word
   search may be turned off to print out all possible letter iterations.

   Command-line options:

     -r
         Reverse mode, convert letter strings to numbers (numbers to
         words is the default mode).

     -a
         In number to word mode, suppress the dictionary check for valid
         words and print out all possible letter combinations.

     -d file
         Use the named file as the word dictionary, it must contain a list
         of words one per line in alphabetical order.  If not specified,
         "words" in the current directory is the default.

     -s
         Rudimentary pluralization of words, if the last letter of a
         word being checked is 's' and there is no match for the whole
         word, drop the 's' and try again.  Normally the word must match
         a dictionary word exactly.

     -q
         Include 'q' and 'z' in the conversions, with 'q' on the 7 key
         and 'z' on the 9.  Normally these letters are not used when
         converting numbers to words, and are illegal when converting
         strings to numbers.

     -0
         0-o and 1-i mode.  With this option, 'o' is removed from its
         normal position on the 6 and made equivalent to 0, similarily
         'i' is moved from the 4 to the 1.  Without this, 0 and 1 are
         illegal when converting numbers to words, and are not used when
         converting strings to numbers.

   Following any options on the command line are numbers or strings to be
   converted.  Number arguments may contain letters in number to word mode,
   and strings may contain numbers in reverse mode.  In the first case,
   any letters will first be converted back to numbers, so all iterations
   of other letters on the same number key will be checked.  In the second
   case, the numbers are simply passed through unchanged.  In either mode,
   the arguments may contain separator characters, anything that is not
   [0-9A-Za-z] is a separator.  Separators are passed through unchanged,
   but in either mode a separator cannot be the first or last character of
   an argument, and no two separators may be sequential within the argument.

   As indicated above, arguments for number to word conversion must not
   contain digits 0 or 1 unless the option "-0" appears, and arguments for
   reverse conversion must not contain 'q' or 'z' unless "-q" appears.  In
   number to word mode, the arguments must not contain more than a maximum
   number of digits, not counting separators.  The limit is defined below
   as MAXNUM.  The number of letter iterations to check will increase
   geometrically with the number of digits, so setting MAXNUM very large
   might make this take a very long time.  10 is the recommended value.

   In number to word mode, separators are viewed as breaking the
   number into sub-strings.  During the word search, two approaches
   are used.  First a search is made for a word match to the entire
   number, ignoring separators, then a search is made for words that
   match each sub-string.  For example, "223-6636" will yield both
   "abdomen" and "bad-omen".

   "Release notes":

   The word search is only as good as the dictionary file, a very
   basic one with words up to 10 characters ought to be used along with
   this source file, but it can undoubtedly be improved.  This is left
   as an exercise for the interested student.

   This was written for a  Unix environment, and tested under a couple
   of  flavors (ULTRIX 3.1,  Linux 2.0.28),  but that's  as far  as it
   goes.  I  did this as  a favor for  a friend and not  primarily for
   distribution, and  I don't have the  time to deal  with support for
   other platforms.  You're welcome to do whatever you want with it to
   make it work on your  favorite OS/machine, but frankly I don't want
   to  hear  about  it,  hence  the  lack of  anything  here  like  my
   name/e-mail address.  Good luck! */

/*--------------------------------------------------------------------
   Header files. */

#include <stdio.h>
#include <string.h>
#include <ctype.h>

/*--------------------------------------------------------------------
   Constants and parameters. */

#define MAXNUM 10   /* Max number of digits in a number for word conversion. */

#define DICTNAME "words"   /* Default dictionary file name. */

#define WORDALLOC 2500   /* Allocation increment for word storage. */


/*--------------------------------------------------------------------
   Function prototypes. */

void loadwords(FILE *, int *);
void tonumbers(char *);
void toletters(char *, int);
void findwords(char *);
int checkword(char *, int);

/*-------------------------------------------------------------------
   Globals. */

struct {             /* Dictionary word lists, one for each word length. */
  int nword[26];     /* Number of words for each first letter. */
  char *index[26];   /* Pointers to first word for each letter. */
  char *block;       /* Word storage. */
} Words[MAXNUM];

int Mode = 1;   /* True for numbers to words, false for letters to numbers. */

int Nosearch = 0;   /* True to suppress word search and show all iterations. */

int Plurals = 0;   /* True to allow 's' at the end of any matching word. */

int Qmode = 0;   /* True to include 'q'<->7 and 'z'<->9. */

int Zeromode = 0;   /* True to make 'o'<->0 and 'i'<->1. */

int Nsub;             /* Substring info - number, length, and start of all */
int Slen[MAXNUM];     /*  substrings in a number being converted to words, */
char *Subs[MAXNUM];   /*  global to avoid duplication in recursion. */

/*--------------------------------------------------------------------
   Main routine. */

main(
     int argc,
     char **argv)

{
  FILE *dict;
  int n, i, s, iopt, istart, subl, lenflag[MAXNUM];
  char *p, *dname, str[(2 * MAXNUM) + 1];

/* Set the default dictionary file name. */

  dname = DICTNAME;

/* Begin parsing command line, look for options.  This supports "-a -b -c"
   or "-abc" forms, or any mixture. */

  iopt = 1;
  while (iopt < argc) {
    p = argv[iopt];
    if (*p != '-') {
      break;
    }
    for (p++; *p; p++) {
      switch (*p) {
      case 'r':   /* Switch to letter to number mode. */
	Mode = 0;
	break;
      case 'a':   /* Turn off word-search mode. */
	Nosearch = 1;
	break;
      case 'd':   /* Next arg has name for dictionary file. */
	if (++iopt >= argc) {
	  break;
	}
	dname = argv[iopt];
	break;
      case 's':   /* Set flag to check for pluralized words. */
	Plurals = 1;
	break;
      case 'q':   /* Include 'q' and 'z'. */
	Qmode = 1;
	break;
      case '0':   /* Make 0 be 'o' and 1 be 'i'. */
	Zeromode = 1;
	break;
      default:   /* What? */
	iopt = argc;
	break;
      }
      if (iopt >= argc) {
	break;
      }
    }
    iopt++;
  }

/* Done with options, there must be some more arguments to process.  Also
   iopt >= argc if an error occurred above. */

  if (iopt >= argc) {
    fprintf(stderr,
	    "usage: %s [-radsq0] arg ...\n",
	    argv[0]);
    fputs("       -r  convert strings to numbers\n", stderr);
    fputs("       -a  print all letter iterations\n", stderr);
    fputs("       -d  use next arg as name of dictionary file\n", stderr);
    fputs("       -s  append 's' to every word in dictionary\n", stderr);
    fputs("       -q  include 'q' <-> 7 and 'z' <-> 9\n", stderr);
    fputs("       -0  make 'o' <-> 0 and 'i' <-> 1\n", stderr);
    exit(1);
  }

/* Scan the arguments and check for errors.  In number to word mode,
   check the number of digits against the max, check for 0 and 1
   unless Zeromode is true, also track the possible sub-string lengths
   so that words of all required lengths can be loaded into the
   dictionary later.  In letter to number mode, check for 'q' and 'z'
   unless Qmode is true.  In either mode, check for a separator as the
   first/last character or two separators in a row.  Also, all the
   arguments get converted to lower-case in place. */

  istart = iopt;
  for (n = 0; n < MAXNUM; n++) {
    lenflag[n] = 0;
  }
  for (; iopt < argc; iopt++) {
    n = 0;
    subl = 0;
    s = -1;
    for (p = argv[iopt]; *p; p++) {
      *p = tolower(*p);
      if (isalnum(*p)) {
	s = 0;
	if (Mode) {
	  if (!Zeromode) {
	    if ((*p == '0') || (*p == '1')) {
	      fprintf(stderr, "%s: in '%s': '0' or '1' not allowed\n",
		      argv[0], argv[iopt]);
	      exit(1);
	    }
	  }
	  n++;
	  subl++;
	} else {
	  if (!Qmode) {
	    if ((*p == 'q') || (*p == 'z')) {
	      fprintf(stderr, "%s: in '%s': 'q' or 'z' not allowed\n",
		      argv[0], argv[iopt]);
	      exit(1);
	    }
	  }
	}
      } else {
	if (s) {
	  if (s < 0) {
	    fprintf(stderr, "%s: in '%s': illegal leading separator\n",
		    argv[0], argv[iopt]);
	  } else {
	    fprintf(stderr, "%s: in '%s': illegal repeated separator\n",
		    argv[0], argv[iopt]);
	  }
	  exit(1);
	}
	s = 1;
	if (Mode) {
	  lenflag[subl - 1] = 1;
	  if (Plurals && (subl > 1)) {
	    lenflag[subl - 2] = 1;
	  }
	  subl = 0;
	}
      }

    }
    if (s) {
      fprintf(stderr, "%s: in '%s': illegal trailing separator\n",
	      argv[0], argv[iopt]);
      exit(1);
    }
    if (Mode) {
      if ((n < 1) || (n > MAXNUM)) {
	fprintf(stderr, "%s: in '%s': illegal digit count\n",
		argv[0], argv[iopt]);
	exit(1);
      }
      lenflag[subl - 1] = 1;
      if (Plurals && (subl > 1)) {
	lenflag[subl - 2] = 1;
      }
      lenflag[n - 1] = 1;
      if (Plurals && (n > 1)) {
	lenflag[n - 2] = 1;
      }
    }
  }

/* Load the dictionary file, if needed.  Only words of lengths equal to
   possible word lengths in the actual arguments are loaded. */

  if (Mode && !Nosearch) {
    if ((dict = fopen(dname, "r")) == NULL) {
      fprintf(stderr, "%s: unable to open dictionary file '%s'\n",
	      argv[0], dname);
      exit(1);
    }
    loadwords(dict, lenflag);
    fclose(dict);
  }

/* Main loop over arguments.  First make a copy of the argument.  In
   number to word mode, run the arg through tonumbers() in case it
   contains any letters, then print it out.  Then build the substring
   locations in globals so this doesn't need to be done repeatedly on
   every letter iteration (the separators are not going to move around
   or change).  Finally call toletters(), which recursively handles
   number to letter conversions and calls the routine findwords() at
   the bottom to search for word matches.  In letter to number mode,
   simply echo the argument, call tonumbers(), and print the
   result. */

  for (iopt = istart; iopt < argc; iopt++) {
    strcpy(str, argv[iopt]);
    if (Mode) {
      tonumbers(str);
      putchar('\n');
      puts(str);
      Nsub = 0;
      Slen[0] = 0;
      Subs[0] = str;
      for (p = str; *p; p++) {
	if (isdigit(*p)) {
	  Slen[Nsub]++;
	} else {
	  Slen[++Nsub] = 0;
	  Subs[Nsub] = p + 1;
	}
      }
      Nsub++;
      toletters(str, 0);
    } else {
      putchar('\n');
      puts(str);
      tonumbers(str);
      puts(str);
    }
  }
  putchar('\n');
  exit(0);
}


/*---------------------------------------------------------------------
   Routine reads in the word dictionary. */

void loadwords(
	       FILE *in,      /* Input stream. */
	       int *lenflg)   /* Flags indicate which word lengths to load. */

{
  int i, n, ilet[MAXNUM], count[MAXNUM], max[MAXNUM];
  char *p, word[50], letter[MAXNUM], *nextword[MAXNUM];

/* Initialize, zero out all the word lists. */

  for (n = 0; n < MAXNUM; n++) {
    letter[n] = 'a' - (char)1;
    ilet[n] = -1;
    count[n] = 0;

    max[n] = 0;
    Words[n].block = NULL;
    for (i = 0; i < 26; i++) {
      Words[n].nword[i] = 0;
      Words[n].index[i] = NULL;
    }
  }

/* Read and store words.  A word with any non-letter in it is ignored,
   as are words more than MAXNUM letters long.  All words are
   converted to lower- case also.  This assumes the input list is
   already in alphabetical order.  The words are stored without null
   termination, since the length of all the words in one structure is
   the same.  Allocation is in chunks of WORDALLOC words for all
   lengths. */

  while (fgets(word, 50, in)) {
    n = 0;
    for (p = word; *p; p++) {
      if (*p == '\n') {
	*p = '\0';
	break;
      }
      if (!isalpha(*p)) {
	n = 0;
	break;
      }
      *p = tolower(*p);
      n++;
    }
    if ((n < 1) || (n > MAXNUM)) {
      continue;
    }
    if (!lenflg[--n]) {
      continue;
    }
    if (max[n] == 0) {
      Words[n].block = (char *)malloc(WORDALLOC * (n + 1));
      nextword[n] = Words[n].block;
      max[n] = WORDALLOC;
    } else {
      if (count[n] == max[n]) {
	Words[n].block = (char *)realloc(Words[n].block,
					 (max[n] + WORDALLOC) * (n + 1));
	nextword[n] = Words[n].block + (max[n] * (n + 1));
	max[n] += WORDALLOC;
      }
    }
    if (*word != letter[n]) {
      if (*word < letter[n]) {
	fputs("**dictionary file is not sorted, exiting\n", stderr);
	exit(1);
      }
      ilet[n] += (int)(*word - letter[n]);
      letter[n] = *word;
    }
    strncpy(nextword[n], word, (n + 1));
    Words[n].nword[ilet[n]]++;
    count[n]++;
    nextword[n] += n + 1;
  }

/* Compute all the word index pointers in the structures, these
   couldn't be done on the fly because they all break if realloc()
   moves the block. */

  for (n = 0; n < MAXNUM; n++) {
    if (count[n] == 0) {
      continue;
    }
    p = Words[n].block;
    for (i = 0; i < 26; i++) {
      if (Words[n].nword[i] == 0) {
	continue;
      }
      Words[n].index[i] = p;
      p += Words[n].nword[i] * (n + 1);
    }
  }
}


/*------------------------------------------------------------------------
   Routine converts letters to numbers in string. */

void tonumbers(
	       char *str)   /* String to convert. */

{
  char *p;

/* Do it. */

  for (p = str; *p; p++) {
    switch (*p) {
    case 'a':
    case 'b':
    case 'c':
      *p = '2';
      break;
    case 'd':
    case 'e':
    case 'f':
      *p = '3';
      break;
    case 'g':
    case 'h':
      *p = '4';
      break;
    case 'i':
      if (Zeromode) {
	*p = '1';
      } else {
	*p = '4';
      }
      break;
    case 'j':
    case 'k':
    case 'l':
      *p = '5';
      break;
    case 'm':
    case 'n':
      *p = '6';
      break;
    case 'o':
      if (Zeromode) {
	*p = '0';
      } else {
	*p = '6';
      }
      break;
    case 'p':
    case 'q':
    case 'r':
    case 's':
      *p = '7';
      break;
    case 't':
    case 'u':
    case 'v':
      *p = '8';
      break;
    case 'w':
    case 'x':
    case 'y':
    case 'z':
      *p = '9';
      break;
    }
  }
}


/*---------------------------------------------------------------------
   Routine to convert numbers to letters.  This is recursive, the main
   call is for the first digit, each recursive call for a subsequent
   digit.  Digits are replaced by letters in place in the passed
   string.  At the deepest level, findwords() is called to check the
   converted string for words.  Each digit is restored for the next
   recursive pass. */

void toletters(
	       char *str,   /* String being converted. */
	       int p)       /* Digit to work on. */

{
  char *l, savenum;
  int q;

/* Skip past a separator, earlier checks make it safe to assume there are
   never two separators in a row nor a separator at the very end. */

  if (!isalnum(str[p])) {
    p++;
  }

/* Set possible letter string for the digit.  If '0' or '1' appear it is
   save to assume Zeromode is true due to earlier checks. */

  switch (str[p]) {
  case '0':
    l = "o";
    break;
  case '1':
    l = "i";
    break;
  case '2':
    l = "abc";
    break;
  case '3':
    l = "def";
    break;
  case '4':
    if (Zeromode) {
      l = "gh";
    } else {
      l = "ghi";
    }
    break;
  case '5':
    l = "jkl";
    break;
  case '6':
    if (Zeromode) {
      l = "mn";
    } else {
      l = "mno";
    }
    break;
  case '7':
    if (Qmode) {
      l = "pqrs";
    } else {
      l = "prs";
    }
    break;
  case '8':
    l = "tuv";
    break;
  case '9':

    if (Qmode) {
      l = "wxyz";
    } else {
      l = "wxy";
    }
    break;
  }

/* Loop over letters, recurse.  If  at the bottom, if Nosearch is true
   just  print out  the string,  otherwise call  findwords(),  it will
   print out the string if a match is found. */

  q = p + 1;
  savenum = str[p];
  while (*l) {
    str[p] = *l;
    if (str[q]) {
      toletters(str, q);
    } else {
      if (Nosearch) {
	puts(str);
      } else {
	findwords(str);
      }
    }
    l++;
  }
  str[p] = savenum;
}

/*----------------------------------------------------------------------
   Routine to take a number converted to a letter string and search it
   for words that match the dictionary list. */

void findwords(
	       char *str)   /* Converted string to search for words. */

{
  int i, wlen;
  char *p, whole[MAXNUM + 1];

/* Make a copy of the string with separators stripped and check for a whole
   string word match.  Skip this if there is only one substring, in that case
   the substring is the whole string and this is redundant. */

  if (Nsub > 1) {
    wlen = 0;
    for (i = 0; i < Nsub; i++) {
      strncpy((whole + wlen), Subs[i], Slen[i]);
      wlen += Slen[i];
    }
    whole[wlen] = '\0';
    if (checkword(whole, wlen)) {
      puts(whole);
    }
  }

/* Check for substring matches, all must match for success. */

  for (i = 0; i < Nsub; i++) {
    if (!checkword(Subs[i], Slen[i])) {
      return;
    }
  }
  puts(str);
}


/*----------------------------------------------------------------------
   Routine to compare a string of known length to dictionary, return
   true or false for match. */

int checkword(
	      char *w,   /* Word string, is *not* null terminated. */
	      int n)     /* Length. */

{
  int i, j, l;
  char *c;

/* Do it. */

  j = (int)(*w - 'a');
  if ((l = Words[n - 1].nword[j]) > 0) {
    for (i = 0, c = Words[n - 1].index[j]; i < l; i++, c += n) {
      if (strncmp(w, c, n) == 0) {
	return(1);
      }

    }
  }

/* No match, if Plurals flag is true and the last letter is an 's',
   check again for words one letter shorter. */

  if (Plurals && (n > 1) && (w[n - 1] == 's')) {
    n--;
    if ((l = Words[n - 1].nword[j]) > 0) {
      for (i = 0, c = Words[n - 1].index[j]; i < l; i++, c += n) {
	if (strncmp(w, c, n) == 0) {
	  return(1);
	}
      }
    }
  }
  return(0);
}

              ---------   cut here -----------

This is an interesting program.  Yes, it could be put on a web page,
and that page could allow conversions in either direction (numbers to
words, words to numbers), in fact it has been.

But, before an effort you go to an effor on this, check these sites:

Both ways:

    http://www.dialabc.com/  <-- very interesting and comprehensive!

    http://www.phonespelling.com/
    http://www22.verizon.com/Vanity/

Number to words:

    http://www.phonespell.org/
    http://labrocca.com/phone/

Words to numbers:

    http://www.phonetic.com/

(I found those with a Google search: phone number to word.)

Unix is still a good OS, but so any folks are using Windows these
days. If you feel like it, make the changes needed for Windows or
the OS of your choice from the script above. 

Patrick Townson

------------------------------

From: T. Sean Weintz <strap@hanh-ct.org>
Subject: Re: Power Device Via UTP?
Date: Thu, 07 Oct 2004 16:21:13 -0400
Organization: Posted via Supernews, http://www.supernews.com


Crimson_M wrote:

> I know very little about the 802.3 standard and transmission lines, in
> general as I'm a hardware guy. But, I'm curious if you suppose it is
> possible to power a simple, low power device via 100/10BaseT? Consider
> a setup such as,

> Gateway/Router/etc. ========== UTP ========== Device

> Where the device would contain some simple hardware, just enough to
> communicate via TCP/IP and perform some other simple functions.

> I'm just thinking abstractly here and don't have any ideas on specs at
> all ... What do you think?

YES! It is possible. There is in fact a standard for doing exactly
that - the 802.3af "power over ethernet"or PoE standard.

Many devices are supporting this now -- especially IP phones for PBX
systems, wireless access points, and 3com even makes mini ethernet
switches that draw their power from a central switch using PoE.

Lemme know if you want more info.

------------------------------

From: Rick Merrill <RickMerrill@comTHROW.net>
Subject: Re: Power Device Via UTP?
Organization: Comcast Online
Date: Thu, 07 Oct 2004 20:33:57 GMT


Crimson_M wrote:

> I know very little about the 802.3 standard and transmission lines, in
> general as I'm a hardware guy. But, I'm curious if you suppose it is
> possible to power a simple, low power device via 100/10BaseT? 

No, but CAT5 yes.

------------------------------

From: techie@tantivy.stanford.edu (Bob Vaughan)
Subject: Re: Power Device Via UTP?
Date: Thu, 7 Oct 2004 23:29:08 UTC
Organization: Tantivy Associates


In article <telecom23.474.10@telecom-digest.org>,
Crimson_M <crimson_m@hotmail.com> wrote:

> I know very little about the 802.3 standard and transmission lines, in
> general as I'm a hardware guy. But, I'm curious if you suppose it is
> possible to power a simple, low power device via 100/10BaseT? Consider
> a setup such as,

> Gateway/Router/etc. ========== UTP ========== Device

> Where the device would contain some simple hardware, just enough to
> communicate via TCP/IP and perform some other simple functions.

> I'm just thinking abstractly here and don't have any ideas on specs at
> all ... What do you think?

Certainly ... It's called Power_Over_Ethernet, and is commonly used to
power wireless access points, and similar devices.

See http://www.nycwireless.net/poe for a tutorial on building your own
POE adaptors.


               -- Welcome My Son, Welcome To The Machine --
Bob Vaughan  | techie@{w6yx|tantivy}.stanford.edu | kc6sxc@w6yx.ampr.org
	     | P.O. Box 19792, Stanford, Ca 94309
-- I am Me, I am only Me, And no one else is Me, What could be simpler? --

------------------------------

From: Frank@Nospam.com
Subject: Re: VOIP Home Connection
Date: Thu, 07 Oct 2004 22:50:48 GMT
Organization: EarthLink Inc. -- http://www.EarthLink.net


> the way. Wouldn't it be a kick in your posterior to find out telco had
> installed a second line for some neighbor of yours, and had grabbed
> your supposedly unused pair to do the job?  

And, that could happen any time after you connect the inside wiring to
your Vonage adapter.  Moral: Don't use the inside wire for Vonage
unless you disconnect the telco side at the Network Interface Device.

> In any event, don't pay AT&T to do this, and don't listen to
> Verizon.  PAT]

[TELECOM Digest Editor's Note: Oh, you are absolutely correct!
Especially so in larger inner city older neighborhoods where telco
tends to run short on cable pairs a lot of times anyway. Here is a 
real life example: A long-time friend of mine who lived in Chicago
many years ago as I did lived with his parents on the west side. The
parents had their own phone lines; my friend had a private phone of
his own in his bedroom, not connected in any way or associated with
his parent's line. A separate pair coming in from the pole. One day
in his experiments, he got into the modular jack in his bedroom, saw
his own phone there, of course, and there was the other pair tied
on there as well. As neat as could be, phone-man style, not just
some spaghetti mound of wires as you might find in a do-it-yourself
kind of wiring. He listened on that pair and heard dial tone. This
got him quite curious: it was not his parent's phone pair, so who was
it?  

Back in those days, you got ring-back by dialing '571-6' in Chicago.
So he dialed the ring-back code and waited for an answer, which 
came soon enough. A lady who answered told him she was across the
alley and down the street a block or so, and she told him her phone
had just been installed a day or two earlier. *Someone* -- some
outside plant tech guy had put in that lady's phone but had failed
to go down the alley and open up any multiples on the line. In phone
jargon, a 'multiple' is any place on a cable run where a pair (of
wires) makes an appearance. Its very common in older outside plant
(dating back, lets say to the 1940-50 era) in dense inner city areas,
to do it that way: string one cable with maybe 500 pairs therein
down the alley, open each pair at each possible location or house,
and attach it to the demarc. In the 1940-50 era, things were 'different'
than they are today in terms of people, communities, and telephony. In
those days, as people moved around (not very often, I might add), when
someone moved in somewhere, the pair (within that cable) was given to
them (like today), but other dwelling places on that block or within
the reach of that cable had that pair lifted off *their* demarc. A very
effecient and very inexpensive way of doing things. But, things were
'different' in those times. In the last building I lived in while I
was in Chicago, the *big* demarc in the building basement had 
several hundred pairs all terminated there, and two very distinct
memories I have were of a large cluster of wires with a string tag on
them saying "this fifty pairs serves the switchboard at (address)",
which was across the street and down the block; an ancient old
building where the lobby switchboard had been removed entirely a
dozen years earlier! And the string-tag was dated *April, 1922* by 
a long-forgotten, long-dead phone man. And I recall that I was on
'Rogers Cable 2712, pair 83'. (Rogers Park was the name of the
central office.) 

If people in large cities only knew how they are getting ripped off
by Illinois Bell, New York Telephone and other telcos who sell them
a 'private line' but never bother to mention how in fact the cable
bringing them their phone line has at least a dozen multiples or
splices on each pair along the way, most of which terminate in
*other people's homes* and an unscrupulous, dishonest person could
easily tap their line and listen to them or place calls on their
line. (You know the old service rep gag, when they are trying to get
you to pay your bill: "but sir, it was a direct dialed call, *you had
to have made the call*.") And when you raise enough hell with them and
defy them to cut off your phone for non-payment then maybe they will
send a guy out to check the wires and see what you claimed was really
true. 

So, by all means, Frank, if you are planning to dump Bell entirely -- 
and who wouldn't if they had a practical solution to it --  then yes,
cut them off at the demarc totally. But, as an expedient solution, if
you plan to keep at least one backup line from Bell in your house, as
most of us do, then make *very certain* that at least the pair you are
going to use for Vonage does not reach the demarc, cause chances are
likely, if Bell needs it they will just take it anyway.  PAT]

------------------------------

From: dv_temp-01@yahoo.com (Darko)
Subject: Anybody used DCI Telecom Long Distance in Canada?
Date: 7 Oct 2004 14:33:51 -0700
Organization: http://groups.google.com


DCI Telecom have post-paid dial arround plans with good rates and no
setup or monthly fees.

Is anybody aware of any problems with them?

Darko

------------------------------

From: David Clayton <dcstar@XYZ.myrealbox.com>
Subject: Re: Pennsylvania Railroad's Crew Communication System?
Date: Fri, 08 Oct 2004 08:09:47 +1000


hancock4@bbs.cpcn.com (Lisa Hancock) contributed the following:

> David Clayton <dcstar@XYZ.myrealbox.com> wrote: 

>> The train system in my city uses the "trip stop" system, but a few
>> months ago at the end of a line a driver got out of his cabin (for a
>> "pit stop") but left both trip stops up and the brakes off.

> I think there is a misunderstanding.  The train motorman has no
> control over the trip stops, they are a trackside mechanism controlled
> by the signals.  In North America, if the brakes were left off and the
> train rolled, it would hit a red signal and be "tripped" before
> hitting another train.

Possibly, on the trains here the leading bogie has a lever which if it
hits a raised arm on the track at a "Stop" signal applies the
emergency brakes on the train.

When these trains change direction at a terminus, the driver has to
manually raise the lever at one end and also lower it at the other end --
in the case I mentioned he raised one but forgot to lower the other so
it wasn't there to stop the train when it rolled away!

> But a word about manual overrides:

> Subway systems typically allow the motorman to override the tripstop
> so he can proceed through a red signal -- under certain circumstances.
> The rules are quite strict that when doing so the motorman must be
> prepared to stop well short of any obstruction, another train, or
> broken rail -- in essence, to only creep along.  In practice this was
> used to follow closer behind a departing train into a station to save
> a little time.

> Unfortunately, motorman error in such cases has resulted in accidents,
> and some systems have outlawed bypassing the tripstop.  It is also a
> tradeoff between convenience and safety and an ongoing debate.

That issue also came up here last year, an empty train returning to
the yards went through a stop, but instead of slowly proceeding (as he
was supposed to) he went too fast, came around a bend and slammed into
another train at a station.

Of course, I won't mention that a lot of these things seemed to have
happened since the state privatised the train system about 10 years
ago.

Two companies took over about half the system each, one finally walked
away from the contract last year and it cost the state pay big money
to the remaining one to take over and run the whole system.

Regards,

David Clayton, e-mail: dcstar@XYZ.myrealbox.com
Melbourne, Victoria, Australia.
(Remove the "XYZ." to reply)

Dilbert's words of wisdom #18: Never argue with an idiot. They drag
you down to their level then beat you with experience.

------------------------------

From: jdj <jdj@now.here>
Subject: Re: Phishing:  Latest Spam/Scam; Very Dangerous
Date: Thu, 07 Oct 2004 16:44:43 -0700
Organization: Posted via Supernews, http://www.supernews.com


It's not only crackers, spyware and trojans collecting your info from
your computer, etc., trashers and divers are also reselling whatever
personal and account info they find in the trash instead of using it
themselves.

And don't think you're safe just because the info you discovered was
stolen from you has not been used in the past few years. "It hasn't
been used yet" means just that and not "therefore it will never be
used".

------------------------------

From: jdj <jdj@now.here>
Subject: Re: BART Cop Orders Radio Turned Off to Protect Trains
Date: Thu, 07 Oct 2004 16:44:35 -0700
Organization: Posted via Supernews, http://www.supernews.com


On Sat, 25 Sep 2004 19:39:25 -0700, Lisa Hancock wrote:

> jdj <jdj@now.here> wrote in message
> news:<telecom23.442.5@telecom-digest.org>:

>> A BART cop ordered riders to turn off their FRS radios while in the
>> station and on trains to keep the trains from crashing.

> Would you have a newspaper or other citation for this?  We need a lot
> more information to reach any conclusion and what and why happened.

Sorry, I think I did not ask for any conclusions. I was curious about
others' experiences most particularly with airlines.

>> This reminds me when they ordered people to turn off receivers or face
>> jail years earlier. At the time they claimed their own radios were
>> "special" and so could be used on trains. I later verified with their
>> own radio shop that there was nothing special about their radios.

> I have never heard of BART placing any restrictions on radios, other
> then perhaps asking people with radios to keep them off to avoid
> disturbing other passengers.  Before lightweight "Walkman" headphones
> came out. some rude people carried "boom boxes" which were big portable
> radios with big speakers, and played them very loudly.

 From inauguration through at least 1976, as I recall, signs were
posted requesting that no transmitters be used in stations and on
trains. But BART police demanded that receivers be turned off as well.

It was not very long after I talked to the senior radio tech that
those signs disappeared.

> Years ago airlines wouldn't allow psgrs to use their transistor radios
> onboard because it interfered with their navigation equipment.  I never
> understood how just listening to a radio could interfere with other
> equipment, but this was a common standard restriction.  I don't know if
> it still applies today.

> As to the claim BART radios were "special" years ago, there is
> definitely truth to that.  BART's original train control system had many
> problems, including a train that ignored a stop signal and flew off at a
> terminal into the parking lot.  Whether silencing radio receivers would
> make a difference I don't know, but it is a fact BART had serious system
> problems and may have been very sensitive about any perceived risk of
> interference, justified or not.

No, there is no truth to it. BART did not use any special radios. They
used ordinary Motorola radios for admin, maintenance, road and public
safety on three bands. As I mentioned, the radio shop said they had no
"special" radios.

I remember the Fremont Station incident where the train ran past the
end of the platform. I do not recall the details but I do recall it
was not related to radio interference.

>> [TELECOM Digest Editor's Note: Security and police are often times very
>> heavy-handed, often times just to make up for their personal feelings
>> of inadequacy.

> It is important to distinguish invidual officer actions from department
> policy, and also take into account the circumstances present.  When
> someone is bearing safety responsibility, it is natural to err on the
> side of caution; and people without any of that responsibility might not
> understand that reasoning.

>   Also, like it or not, some citizen complaints against cops are
> simply unfounded.  In my old city cops had a bad reputation among young
> people and I tried to research it out.  It turned out nobody personally
> had a bad experience, indeed several people had been helped by cops
> going out of their way for them.  It was that everybody "had heard"
> something.  Lots of rumors, no facts.  I have personally seen incidents
> where cops took a lot of abuse yet were blamed for the incident.

>   Cops and prosecutors are human and do make mistakes, but it is
> important to get all the facts before reaching a conclusion.

>> Have you ever been told *as a passenger, not the driver* in an
>> automobile not to use your cellular phone because it 'might distract
>> the driver'?

> Never heard that.  But I've heard to turn off cell phones while
> refueling the car, and I wonder if that's really necessary.

Yes it is. Transmitters set up RF eddy currents in nearby metal
objects and at certain points there is high enough voltage to produce
sparks if other conditions are met. Ths can occur even with a
milliwatt transmitter.  Even though the odds are against it, the risk
remains.

There was a Discovery Channel MythBusters episode set up to test the
theory that a cell phone could cause petrol to explode. The test was
apparently set up to see if a transmitting cell phone, all by itself,
could cause a container of petrol to explode. It did not in any way
resemble the scenario of refueling a vehicle while talking on the cell
phone.

>> I can sort of see why they do not want drivers to use cell phones in
>> cars, but before they enforce that too strongly, they should look at
>> their own radio use in the car: driving a hundred miles an hour chasing
>> someone, while talking on the radio, yet a citizen is not supposed to
>> obey traffic rules and speed limits and talk on a cell phone?  PAT]

> You have a point, cops driving at high speed do get into some nasty
> accidents, although many times it's the person their chasing that plows
> into an innocent person, or a motorist ignores the siren and flashing
> lights and drives out in front of the cop (which I've seen). I will note
> that cops get a very vigorous driver training program and their radio
> calls are generally quite terse and to the point.  In contrast, I've
> seen uncountable cell phone drivers get so distracted as to just stop
> dead in the middle of an intersection or street, to concentrate on the
> conversation, get in the wrong lane and be oblvious about it, etc.  If
> someone's cell phone call was simply "I'm running late, be there in 15
> minutes" it wouldn't be so bad, but people have extended detailed
> conversations which distracts them from their driving.

> [TELECOM Digest Editor's Note: You are correct that police and prose-
> cutors are human beings (or human beans as Mayor Daley once said after
> the nasty riots in April, 1968 when MLK was assassinated.) And, people
> do get very angry when they discover their supermen and super-heros are
> just as human as they themselves. That being said, however, because
> police officers are routinely given so much more trust than the rest of
> us, the trade off should be they are *very careful, almost exceptionally
> well behaved and honest* -- at least that's how it should be. Police
> officers are often times fond of saying, 'we have our civil liberties
> and free speech rights also.'  Yes, they do, but IMO some of their 'free
> speech rights' and 'civil rights' should be an agreed on trade off in
> exchange for their jobs. An officer who lies or otherwise misbehaves
> should be dealt with very sternly, not just a slap on the wrist as they
> often times get if they get caught. I mean, if you cannot depend on
> *them* to tell the truth and behave themselves, then exactly who are we
> supposed to be able to trust?    PAT]

> George Mitchell <george@coventry.m5p.com> wrote

>> Lisa Hancock wrote:

>>> As to the claim BART radios were "special" years ago, there is
>>> definitely truth to that.  BART's original train control system had
>>> many problems, including a train that ignored a stop signal and flew
>>> off at a terminal into the parking lot.

> Let me clarify the above paragraph.  By 'radios' I meant the train
> control system, not the audio communication system.

Strictly speaking, BART did not use radios to control trains. Only in
an extremely broad sense would the system be considered "radio". The
little white fins atop the cars were/are antennae for voice comms.

> BART uses automated train operation and protection.  The speed and
> stopping of trains is controlled by signals sent to the train from
> wayside transmitters.  A second and critical component of this system is
> train protection so that one train does not collide with another. BART
> was an early modern automated train system.

> The rest of my paragraph is correct.  The original BART system had
> pushed the state of the art and had many problems in practice.

> [GW continues]

>> This had nothing to do with radios.  The lead car of the train was
>> receiving a 27-mph signal from the track.  The system for trans-
>> mitting the speed command from the lead car to the rest of the train
>> was to transmit one of a specified set of audio frequency signals over
>> a wire bus.  However, the crystal in the 27-mph oscillator was cracked
>> and oscillated at the 72-mph frequency, causing the train to speed up
>> instead of slow down.  The operator was not able to apply the brakes in
>> time to stop before reaching the end of the track.

> http://www.wws.princeton.edu/cgi-bin/byteserv.prl/~ota/disk3/1976/7614/761406.PD

> That link is invalid. Returns 404.

> My point is that BART depends on wireless communications to transmit
> speed commands from wayside onto the train AND that BART had many
> problems with this system.  The above example is just one of many
> problems they had to deal with.

Strictly speaking, it is wireless. The car's shielded pickup is very close
to a device alongside or just above the third rail. This is the data
communications link. I know that the signalling does not occur above
1MHz -- I did check! (Very surreptitiously.)

The system is similar in function to a tape recorder: In a tape
recorder the tape head detects changes in magnetic flux from the
moving tape and is designed not to pick up stray magnetic fields. The
tape head also produces a magnetic flux which is concentrated on the
tape to record sounds.

The BART control system is designed the same way, except the "tape"
carries a magnetic signal that changes continuously. The train pickup
is designed to only pick up signals from the "tape" and to "record"
signals to the "tape".

There is a detailed layman's description of the magnetic pickup in a
periodical somewhere. It was published sometime around 1975. Also
published were details of the control system, complete with lots of
pictures of the IBM mainframe and ops center. If I recall correctly,
there was also extensive coverage of BART in IBM's internal
publication, "Think".

> Concerning the above problem, I'm surprised that a broken crystal (do
> crystals even break that easily?) would just so happen to send out a
> different valid signal.  In Bell System signalling, they were very
> careful to avoid harmonic frequencies or any frequencies as well as
> pulse coding that could be misinterpreted as something else.  Note that
> Touch Tone signals use two-tones, not just one.  This kind of safety
> design goes back to the 1940s.  Likewise, in more traditional railroad
> signalling, the pulse codes were carefully designed and implemented with
> very rugged gear to avoid misinterpretation.  If a failure occurs, it is
> interpreted as a stop signal.  (BART chose to not use traditional
> railroad technology.)

Yes, crystals do break while in use. They are not perfect. When they
break, they can and do produce output at higher frequencies. A
crystal's resonant frequency is a function of it's dimensions as well
as composition.

> Anyway, a stray or errant signal could and did cause a BART train wreck.
> Naturally BART mgmt would be interested in preventing such problems.
> On other automated rail systems, a positive read of a specific signal is
> required to proceed, the failure to receive that signal stops the train.

No, a stray signal did not cause the crash. A faulty signalling
device, as has been described, caused it.

The train was commanded to accelerate. Even emergency braking could
not have stopped the train before the crash. There was not enough
track left.  This was pointed out in the report and in the media. The
end of track is only about a car-length or two past the end of the
platform.

> As someone else explained, superhet radio receivers retransmit a signal,
> and this signal happens to interfere with navigation.  Well, a radio
> that is actually transmitting could send out similar signal
> interference.

The problem with FM band superhets is that the local oscillator
frequency is traditionally set above the band of interest, in this
case, within the air-nav band of 108 to 118MHz. The interference is of
such a nature that it would be discernible as interference and not a
navigation signal. I suspect that modern airnav systems would not be
fooled.

> As to the current issue, walkie-talkies are transmitters, and as such,
> send out signals obviously stronger than within a receiver's superhet
> circuits.  It is possible that such signals either directly or through
> distortion/harmonics could interfere with normal train control.  While a
> wreck is unlikely, it could force a train into an emergency stop between
> stations, which is obviously undesirable.

Not possible when the control signal band is below the bands in use by
radios, as in the case of BART. Harmonics do not appear below the
fundamental.

> Until such time that modern walkie-talkies would be tested to ensure
> their signals do not and cannot interfere with train control and train
> protection, they should not be permitted to be used on BART.

Then all transmitters should have been banned on those grounds. Yet
cell phones were allowed, as well as untested radios from other
agencies. And again, nearby transmitters, including high-powered
transmitters, adjacent to the track, caused no problems.

It is not a current issue as there is no longer a policy banning
transmitters in stations or on trains.

There is no evidence that any radios interfere with train operation.

The longer this goes on, the more I remember from my "VIP" tour of BART
all those years ago ...

------------------------------

TELECOM Digest is a not-for-profit, mostly non-commercial educational
service offered to the Internet by Patrick Townson. All the contents
of the Digest are compilation-copyrighted. You may reprint articles in
some other media on an occasional basis, but please attribute my work
and that of the original author.

Contact information:    Patrick Townson/TELECOM Digest
                        Post Office Box 50
                        Independence, KS 67301
                        Phone: 620-402-0134
                        Fax 1: 775-255-9970
                        Fax 2: 530-309-7234
                        Fax 3: 208-692-5145         
                        Email: editor@telecom-digest.org

Subscribe:  telecom-subscribe@telecom-digest.org
Unsubscribe:telecom-unsubscribe@telecom-digest.org

URL information:        http://telecom-digest.org

Anonymous FTP: mirror.lcs.mit.edu/telecom-archives/archives/
  (or use our mirror site: ftp.epix.net/pub/telecom-archives)

Email <==> FTP:  telecom-archives@telecom-digest.org 

      Send a simple, one line note to that automated address for
      a help file on how to use the automatic retrieval system
      for archives files. You can get desired files in email.

*************************************************************************
*   TELECOM Digest is partially funded by a grant from                  *
*   Judith Oppenheimer, President of ICB Inc. and purveyor of accurate  *
*   800 & Dot Com News, Intelligence, Analysis, and Consulting.         *
*   http://ICBTollFree.com, http://1800TheExpert.com                    *
*   Views expressed herein should not be construed as representing      *
*   views of Judith Oppenheimer or ICB Inc.                             *
*************************************************************************

ICB Toll Free News.  Contact information is not sold, rented or leased.

              ************************


   ---------------------------------------------------------------

All opinions expressed herein are deemed to be those of the
author. Any organizations listed are for identification purposes only
and messages should not be considered any official expression by the
organization.

End of TELECOM Digest V23 #475
******************************