home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / protocol / tcpip / 4298 < prev    next >
Encoding:
Internet Message Format  |  1992-09-03  |  2.9 KB
  1. Xref: sparky comp.protocols.tcp-ip:4298 comp.dcom.isdn:511
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!jvnc.net!yale.edu!ira.uka.de!smurf.sub.org!news
  3. From: urlichs@smurf.sub.org (Matthias Urlichs)
  4. Newsgroups: comp.protocols.tcp-ip,comp.dcom.isdn
  5. Subject: Re: TCP/IP over ISDN
  6. Date: 4 Sep 1992 11:03:00 +0200
  7. Organization: University of Karlsruhe, FRG
  8. Lines: 50
  9. Message-ID: <1878o4INN4t9@smurf.smurf.sub.org>
  10. References: <1992Aug27.182348.19584@gandalf.ca> <1992Aug28.114002.25416@stc.nato.int> <1992Aug31.183707.18401@gandalf.ca>
  11.  
  12. In comp.protocols.tcp-ip, article <1992Aug31.183707.18401@gandalf.ca>,
  13.   djarrett@gandalf.ca (Dave Jarrett) writes:
  14. > In article <1992Aug28.114002.25416@stc.nato.int> koelman@stc.nato.int writes:
  15. > >> 
  16. > >>  - When the idle timer expires, the ISDN server issue a B-channel 
  17. > >>    connect request to the client ISDN station. The user-user data field
  18. > >>    in the connect request contains a "poll" command. 
  19. > >> 
  20. ... which would require both sides of the ISDN connection to keep state about
  21. the TCP connections crossing the ISDN link and to send bogus TCP packets to
  22. check if the system on the other side is still there. IMHO, this is not a
  23. reasonable requirement.
  24.  
  25. > >> This approach has two advantages over polling using SYNs:
  26. > >>  2. This approach is LAN protocol independant.
  27. > >> 
  28. Since TCP/IP is LAN protocol independent by definition, anything you do would
  29. have to be.
  30. > >
  31. > >This would imply that you get bandwidth for free through the
  32. > >user-to-user data  (unless that is charged separately).
  33. > >I don't think PTTs are that stupid.
  34. User-user data has some valid applications, such as the transmission of
  35. login information, or to check if your voice mail system has any new messages
  36. without actually calling in. ;-)
  37.  
  38. > >If they are then let's send all our IP traffic this way...
  39. > >(the MTU may be limited though :-))
  40.  
  41. Q.931 does limit the number and length of such data packets.
  42. The ISDN switch might also raise some alert if you're continuously trying
  43. to open connections, which are all mysteriously rejected; the main reason
  44. is that such processing causes an excessive load on the switch. 
  45. > 
  46. > It is true that user-user data is an optional facility in Q.931.
  47.  
  48. Unfortunately, the original request came from Germany.
  49. We don't have Q.931 (yet). We also don't have user-user data; maximum
  50. user information transmittable during call setup is 10 bits in forward
  51. direction (device address (1 decimal digit) and 2nd byte of service type)
  52. and 6 bits back (the cause value). So polling is possible, though I'd rather
  53. use it to ask if there's anything in the UUCP queue for the calling system.
  54.  
  55. -- 
  56. "Life would be much simpler and things would get done much faster if it
  57. weren't for other people"
  58.         -- Blore
  59. -- 
  60. Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
  61. Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/
  62.