home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / dcom / modems / 19035 < prev    next >
Encoding:
Text File  |  1993-01-06  |  1.9 KB  |  44 lines
  1. Newsgroups: comp.dcom.modems
  2. Path: sparky!uunet!indetech!wetware!wsrcc!wolfgang
  3. From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht)
  4. Subject: Re: ZyXEL voice and flow control
  5. Message-ID: <C0GHIz.MoJ@wsrcc.com>
  6. Keywords: ZyXEL voice flow control
  7. Organization: W S Rupprecht Computer Consulting, Fremont CA
  8. References: <rkimball.725840444@athena> <1993Jan04.235850.9340@tyrell.tynet.sub.org> <rkimball.726258443@athena> <2B4AF74B.602A@telly.on.ca>
  9. Date: Wed, 6 Jan 1993 23:35:23 GMT
  10. Lines: 32
  11.  
  12.  
  13. >>>ZyXEL modems use XON/XOFF in voice mode. I'd appreciate to
  14. >>>see a new ROM revision supporting
  15. >>>1.) Proper RTS/CTS flowcontrol in voice mode
  16. >This would be OK, however the current method is not unreasonable
  17. >and should not inhibit you from developing your voice application.
  18.  
  19. Having to deal with software flow control forces one to write fairly
  20. inefficient code.  One can't just do a single "write(buffer, 1024)"
  21. and be done with it.  One is forced to write *single* bytes and do a
  22. timed out read() on each byte just in case the other end just sent an
  23. XOFF down the line.
  24.  
  25. I don't see how any person could claim that byte-at-time writes with
  26. intervening reads are "reasonable".
  27.  
  28. >When one is sending voice, it is prudent to read information from the
  29. >DCE (modem) since the modem will be decoding the DTMF buttons pushed.
  30. >The information is shielded by <dle>.  Thus a program should look for
  31. ><dle> shielded xoff, xon, 0, 1,2,3,4,5,6,7,8,9,#,*,c(t-30 signal),
  32. >b(busy), or <etx>, VCON.  This is one of the nice features of the
  33. >voice, that you can be decoding DTMF information both on sending and
  34. >receiving voice.
  35.  
  36. While it may be nice to periodically check for DTMF result codes, I
  37. would imagine that one could very well write k's of data between DTMF
  38. checks.  That is if one didn't have to check for XOFF.
  39.  
  40. -wolfgang
  41. -- 
  42. Wolfgang Rupprecht    wolfgang@wsrcc.com (or) decwrl!wsrcc!wolfgang
  43. Snail Mail:           39469 Gallaudet Drive, Fremont, CA 94538-4511
  44.