home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / protocol / tcpip / 4388 < prev    next >
Encoding:
Internet Message Format  |  1992-09-11  |  2.4 KB

  1. Xref: sparky comp.protocols.tcp-ip:4388 comp.dcom.isdn:533
  2. Path: sparky!uunet!aria!marc
  3. From: marc@aria.Ascend.COM (Marco S Hyman)
  4. Newsgroups: comp.protocols.tcp-ip,comp.dcom.isdn
  5. Subject: Re: TCP/IP over ISDN
  6. Message-ID: <3302@aria.Ascend.COM>
  7. Date: 11 Sep 92 18:45:56 GMT
  8. References: <1992Sep8.183030.330@gandalf.ca> <1992Sep10.040648.20853@dumbcat.sf.ca.us> <1992Sep10.143836.11131@cbfsb.cb.att.com>
  9. Followup-To: comp.protocols.tcp-ip
  10. Organization: Ascend Communications, Alameda, CA
  11. Lines: 39
  12.  
  13. In article <1992Sep10.143836.11131@cbfsb.cb.att.com> deej@cbnewsf.cb.att.com
  14. (david.g.lewis) writes:
  15.  > In a previous article I wrote:
  16.  > >The "mandatory" called party number isn't in setups that come from a
  17.  > > Definity Generic I PBX.
  18.  > 
  19.  > Over a PRI it certainly is.  If a SETUP message is sent by a PBX to the AT&T
  20.  > network and does not include a Called Party Number IE, the call attempt will
  21.  > be cleared.  On the terminal side of the Definity, the terminal may receive
  22.  > information via Keypad IEs.
  23.  
  24. Uhh, this may be a function of the funny way we use our Definity.  It's the
  25. best T1/PRI test took we have (in addition to being a great PBX).  We have
  26. PRI on both the Network and Terminal side, an AT&T PRI from the network and
  27. several (6 or 8) internal T1 lines, some configured as PRI, with the PBX
  28. told they are tie lines.  Each internal line is a trunk group of its
  29. own and is dialed by using the trunk group.  When dialing from one PRI trunk
  30. group to another PRI trunk group the Called Party Number IE on the answering
  31. side exists but has no number.
  32.  
  33.  > Again, to get back to the original thread, certain IEs are designated as
  34.  > usable for user to user information transfer.  These include UUI, High Layer
  35.  > Compatibility, Low Layer Compatibility, subaddress IEs, and Codeset 7 IEs.
  36.  > If you attempt to use anything else to transfer user to user information,
  37.  > there is no guarantee, explicit or implied, that it will be delivered the
  38.  > way you want it - or that it will be delivered at all.
  39.  
  40. Agreed.  However, given the heterogeneous nature of the network there is
  41. currently no guarantee that any of the above will work between any two
  42. arbitrary endpoints.
  43.  
  44. I guess I'm coming down on the side of making a connection and performing
  45. control inband.  TCP/IP over xxx over ISDN.  PPP is overkill for xxx but
  46. will certainly work.
  47.  
  48. // marc
  49. -- 
  50. // work: marc@ascend.com          uunet!aria!marc
  51. // home: marc@dumbcat.sf.ca.us    pacbell!dumbcat!marc    
  52.