[Help]Last update at http://inet.nttam.com : Tue May 30 10:01:48 1995

@Presentation to Inet '95 Conference@

Data and Telecommunications Gateway between the Internet and ISDN

May 13th 1995

Graham Knight <G.Knight@cs.ucl.ac.uk>
Saleem N. Bhatti <S.Bhatti@cs.ucl.ac.uk>
Stuart Clayman <S.Clayman@cs.ucl.ac.uk>


This paper describes work carried out at University College London to integrate public narrow-band ISDN services into the Internet world. The aim of the work is to provide a gateway that allows access to global Internet resources for users with Basic Rate ISDN access. The gateway not only supports traditional data applications but also newer multi-media, multicast applications such as VAT and WB. A subsidiary aim is to make it possible for a PSTN user to dial-in and join an Internet VAT conference


1 Introduction

2 ISDN Infrastructure

3 IP Support

4 New Developments

5 Support for IP Multicast

6. Native ISDN Services

7. Additional Services

8. Conclusions and Future Plans

9. Acknowledgements


Author Information

1 Introduction

For several years UCL has experimented with a home-built Primary Rate ISDN board attached to a Sun workstation[1]. Since the Sun is on the Internet, this has given us the chance to investigate the integration of the ISDN and Internet worlds. The first phase of these experiments has concentrated on a "data-communications oriented" approach - i.e. we have tried to extend the data-communications world of our LANs transparently across the ISDN. In this phase we have concentrated on traditional applications such as file transfer and access, remote login, WWW access etc. This has given us a good deal of experience of the problems which arise with the operation of IP over a circuit-switched network like ISDN. We now have several years of experience of supporting remote Basic-Rate ISDN users who access Internet resources through the UCL Primary rate gateway. Sections 2 and 3 of this paper summarise this work and report our experiences especially with regard to performance, security and economics.

Since the work began there have been dramatic changes in the Internet. Of great interest to us has been the introduction of applications and network support for isochronous services such as voice and video conferencing. Applications like VAT and IVS provide services on the Internet which have traditionally been regarded as the province of telecommunications rather than data-communications. This has led us to extend the capabilities of our ISDN gateway so it can act as a telecommunications-oriented gateway. The aim is to allow telecommunication services on the ISDN to communicate with those on the Internet. There are two aspects to this work; extension of isochronous IP services over ISDN (Section 5) and integration of isochronous IP services with existing ISDN services (Section 6).

2 ISDN Infrastructure

ISDN InfrastructurePrimary Rate ISDN in Europe means 30B+D - 30 circuit-switched 64Kbps channels and one 64Kbps signalling channel. The relevant Physical Layer standards for this[2][3] are widely implemented and standardisation on the Q.931[4] D-channel signalling protocol is becoming widespread. However, in the UK, a proprietary British Telecom signalling protocol called DASS2[5] is used; this pre-dates the CCITT protocol. Primary Rate access is now generally available in the UK. Installation costs about $1500 for 30 channels plus the cost of installing the cable - which could be as much as $20,000. Rental is about $20 per month per channel.

Basic Rate ISDN is now quite widely available throughout Europe. In the UK it is available to any customer served by a digital exchange (provided line quality is good enough). This means it is available to a large majority of subscribers in the country. The service is 2B+D circuit-switched with Q.931 signalling. Installation is about $600 with rental being $20 per month per channel. Call charges are exactly as for the PSTN. In British Telecom's case this means a stepped tariff with time being purchased in "units" each of which costs about 8c. At peak times, on a local call, one unit buys 57.5 seconds of connect time. Off-peak this rises to 220 seconds.

In comparison with other European services the UK one is rather costly in terms of installation and rental but rather reasonable in terms of call charges. Clearly this is not intended to encourage the residential user and has resulted in the ISDN being regarded as a "high cost, high value" service in the UK. This has had consequences for equipment costs since the cheaper ISDN equipment which is available in some European countries, notably Germany, is not marketed in the UK.

2.1 The UCL PR ISDN Configuration

The configuration is shown in Figure 1. This shows the Ethernet/ISDN router constructed from a SUN workstation and a "UCL Primary Rate ISDN Interface Board" (UPI) by a VME bus. This combination handles traffic from a variety of PCs and workstations with Basic Rate ISDN interfaces. Currently there are 7 regular home ISDN users amongst UCL staff plus a number of additional users around the UK and an occasional non-UK caller.

Figure 1. UCL IP/ISDN configuration

The UPI is a conventional communications interface designed around a M68020 chip and an AT&T "Spyder" 2Mbps synchronous chip. The Spyder implements the 32 ISDN sub-channels and provides HDLC support. In order to be able to interwork with a variety of ISDN equipment, the UPI supports several different methods for transporting IP datagrams over ISDN B-channels. These include PPP[6] and HDLC core plus some proprietary ones. Generally the software tries to guess which encapsulation is being used by inspecting the incoming datagrams. A demand-driven strategy is used to control ISDN call set-up. The first outgoing datagram for a particular destination triggers the set-up of a single B-channel. Thereafter, the outgoing bit-rate is monitored and additional channels are added if these are needed and if the remote interface can accept them. An idle timeout mechanism is used to close calls.

The majority of systems used at home by UCL staff are DOS/Windows PCs. There has been quite a large number of PC-bus Basic Rate ISDN products on the market in Europe for several years. Until recently manufacturers have tended to produce proprietary solutions for ISDN and have expected to sell both ends of the connection together with support and applications software. Now, a more open approach is discernible with quite wide support for the "CAPI" API[7] to provide a standard software interface to the ISDN hardware. Our original PC cards were from the British company "kn-X" and use a proprietary protocol over the ISDN which emulates an Ethernet bridge. With support from knX, this protocol was implemented in the UPI so that we could interwork with their cards. Recently we have begun to use the Teles S0 card. This is much cheaper (around $400) and, in principle, less powerful. It supports the CAPI interface and this enables us to use the "ISPA" packet driver[8] and "Trumpet Winsock"[9] software. These two are shareware products available at a reasonable cost. Together they support the industry standard "winsock" API which is used by most Internet software written for the Windows environment. Examples include the Eudora mail processing system, and the Mosaic and Netscape web browsers. The ISPA software is responsible for the interactions with the CAPI interface, setting up and releasing ISDN calls, and the encapsulation of IP datagrams on ISDN B-channels. A number of encapsulations are supported, including PPP.

We have interworked with a number of Unix workstations with Basic Rate ISDN interfaces. Mainly these have used SUN S-bus card from Diehl in Germany with IP software from NetCS or Bintec. We have now begun to use Sun's own ISDN support, which uses PPP

3 IP Support

3.1 Performance

One aim of this work was to provide Internet connectivity to the home with performance as close as possible to that available from the a UCL LAN workstation. At the same time, communications costs had to be minimised. One consequence of this is that a fairly aggressive policy must be used for timing out idle calls. At present, calls are normally timed out after 60 secs idle time. In the future this time will be reduced further once British Telecom go over to a "pay by the second" tariff from the present unit-based one. Even 60 seconds is short enough that calls frequently time-out without the user consciously suspending network activity - close scrutiny of a screen-full of data can easily take this long for example. Therefore it is often the case that ISDN calls must be set-up anew once the user commences typing again. It is crucial that this call set-up should take place as rapidly and unobtrusively as possible. The table below gives typical timings for incoming ISDN call handling by the UPI.

Event                              Time 
taken (ms) 
UPI receives "initial              60         
service request" from the             
network and indicates to              
the network its                       
willingness to accept                 
Network tells called and           600        
calling parties to go                 
UPI waits until the first          500        
datagram from the caller              
Delay until the first              10         
response datagram is                  
forwarded by the UPI  
Total                              1170       

Table 1. Call set-up delay in the UPI

This seems to be dominated by network signalling times. In fact these timings are probably a little unfair on the network since we have a 2Mbps "splitter" box between the UPI and the network which probably contributes some delay.

Two further sources of delay make their contribution. First, there another piece of signalling delay to account for whilst the initial service request is sent from the caller to the UPI. Second, there are processing delays in the calling system; the time between the key-stroke and initiating the ISDN call and the time between receipt of the echo and display on the screen. In practice these all seem to add between 1 and 1.5 seconds. The result (say 2.5 seconds) is a little disappointing given the advertised call set-up times for the ISDN of the order of 0.5 seconds. However, this seems to be just about acceptable to our users and is certainly an improvement on the combined set-up time of the PSTN plus the training time for a fast MODEM.

The throughput we achieve seems to depend largely on the quality of the TCP implementation in use. Here the PC/Windows implementations (Trumpet Winsock and CUTCP[10]) come off poorly in comparison with the Unix ones. We suspect this may be due to the baroque scheduling and buffering mechanisms inside DOS/Windows rather than to the TCP code itself. Table 2 gives some values obtained for FTP traffic using 1024byte packets, the other end of the connection being a Sun workstation on the UCL Ethernet. Note that these are payload rates. The true rate on the wire would be slightly greater because of the protocol overhead.

 Basic Rate System           LAN -> ISDN  ISDN -> LAN
 Sun Unix                        6.7          6.7 
 Trumpet Winsock (1 channel)     3.5          5.3 
 Trumpet Winsock (2 channel)     8.4         13.4 
 CUTCP (1 channel)               5.0          5.1 
 CUTCP (2 channel)              13.0         13.5 

Table 2. Throughput in KBytes/sec

The rates for the Sun Unix system can be obtained quite consistently. The rates for the various PC options are much more variable. When things go well, rates close to the theoretical maximum are seen. When things go badly there are large numbers of unnecessary re-transmissions, long processing delays occur somewhere inside DOS/Windows and throughput drops dramatically. The numbers given were obtained by transferring a 200KByte file and timing with a stop-watch.

3.2 Access control in the ISDN router

A measure of security on incoming calls is provided by the ISDN "Calling Line Id Presentation" (CLIP). This enables the called party to know the caller's ISDN number. Since it is provided by the network rather than the user's equipment it is not trivial to spoof. We are now gradually moving towards PPP as a standard encapsulation protocol and we will support the authentication extension it provides[11]. This will provide us with some measure of security when CLIP is unavailable - as presently for some international calls.

We have to care also for outgoing calls since these cost us real money. In this case the control is applied specifically to ISDN call set-up and not to data transfer. Before a call is made, the source IP address of the triggering datagram is tested against two tables of "authorised" and "unauthorised" address/mask pairs. For the call to be made, the source address must match one of the former and none of the latter. Note that data transfer is still possible to "unauthorised" addresses provided the ISDN call is not set up by the UPI. Effectively this enables our Basic Rate users to operate client Internet software without restriction. Invariably the client initiates activity so the ISDN call is set-up from the client end. As long as there is no long pause whilst waiting for a response from the server, no problems arise. Even if there is such a pause the system will normally recover as soon as the user looses patience and hits a key.

3.3 The system in use

Table 3 summarises usage during October and November 1994.

Host        No.     Mean      Mean      Mean  
name        of      volume    call      data  
            calls   per       duration  rate 
            made    call      (mm:ss)   (Kbps)                    

Bristol     121     147.78     08:01     2.45 
Tyr         129     212.59     03:48     7.44 
Orpheus     804     102.82     06:58     1.97 
Hermes      159      62.20     03:26     2.41 
Poseidon    114      23.09     02:40     1.15 
Apollo      864      73.90     07:10     1.37 
Satyr       164     137.65     08:20     2.20 
Golriz      291     259.53     09:48     3.53 
Phrygia     304     157.51     05:37     3.74 
Ulysses     749     190.83     07:15     3.50 
Arcadia    1082      87.97     03:58     2.95 
Summary    4781     123.08     06:13     2.66

Table 3. UCL ISDN usage Oct/Nov 1994

All except the first of these is in the home of a member of the UCL staff. These people will normally spend only a part of the day working from home. Typically there is a morning ISDN session to read mail, there may also be an evening session. The total ISDN connect time used per day is not all that great - the average for Table 3 works out at just over 44 minutes per day per user. There is quite a range of patters of usage. The users of Tyr and Apollo, for example, both use the ISDN principally as a means of accessing their UCL Unix mailboxes. The former has a Unix machine at home and has evolved a scheme for importing and exporting mail en bloc. The latter uses a PC essentially as a terminal emulator.

Figure 2. An example of one days ISDN activity

Figure 2 shows a days ISDN activity for the user of Arcadia - a 486 PC with a Teles card. The data was obtained by sampling traffic volumes at 3minute intervals. The initial burst in the first hour was mail processing using Eudora to import the day's mail en bloc . The activity in the second hour was a telnet session to a host at UCL. Although the scale is too small to show it, there were many ISDN connections and disconnections during this period. The final period between hours 6 and 8 involved a number of bulk transfers; downloading new software, WWW access etc. The total connect time for the day was 2 hours 31 minutes with about half the calls being made at the "peak rate" and half at the "standard rate". The total call charges for the day's activity would be about $11. This could be reduced quite considerably by a change of working pattern to move a portion of the connect time into the cheap rate. Nevertheless, the cost is of the same order as the cost of a return rail fare to UCL in central London - currently $13.50.

4 New developments

Now that the basic IP/ISDN service is established we have begun work on broadening the range of services offered. Much of the stimulus for this has been the emergence of isochronous services such as VAT and IVS on the Internet. These type of services are the bread and butter of the telecommunications world so some form of integration between the ISDN and Internet versions is attractive. In this paper we describe the approach we have taken towards support for these services through the UPI. The department also has considerable experience of providing multimedia services over ISDN using more direct forms of connection. This work is described in [ 12].

For the UPI work, we have adopted two approaches; first we have experimented with running VAT and WB over our existing IP/ISDN infrastructure, second we have begun implementation of a distributed telecommunications gateway. This work is described in the next two sections.

5 Support for IP multicast

The system described in Section 3 realises point-to-point IP over ISDN connectivity reasonably efficiently. However, the use of applications which take part in many-to-many communication using datagram multicasting techniques is growing on the Internet and this is not straightforward to implement over a point-to-point network like the ISDN. The intrinsic support for many-to-many communication which is a feature of the sub-network in LAN technologies must be simulated via multiple point-to-point links. However, since ISDN is quite costly, we must avoid making unnecessary ISDN calls.

5.1 The multicast backbone - MBONE

With IP multicasting, group D addresses are used, with each address identifying a global distributed group rather than a single host. Any host with suitable extensions [13] can receive and transmit multicast datagrams. However, to provide the correct forwarding for these packets across the whole of the Internet requires a backbone infrastructure providing global connectivity and correct routing for the multicast packets [14]. This connectivity is provided by a number of special routers, most of which implement the distance vector multicast routing protocol (DVMRP) [15,16 ]. DVMRP operation requires all multicast routers to distribute 'soft-state' about all the currently active groups of which they are aware. This distribution of state results in the formation of multicast routing trees that are rooted at the source of each data transmitter. A router that has members of a certain group (receivers or transmitters) grafts itself to the tree; routers that do not have members, prune themselves from the tree. However, as the distributed state is 'soft-state', it will eventually time-out, and multicast routers must then refresh the multicast routing tree by continually distributing control messages, pruning off from particular groups periodically. This means that, even when there are no members of a particular multicast group at a particular router, control messages will still flow for that group.

5.2 ISDN Connectivity Requirements

We would like to ensure that a teleworker using ISDN can make efficient use of the of the ISDN link. This means that the link should be set-up only when there is useful data being transmitted. The current system would time out ISDN connections when there are no datagrams flowing but would not distinguish between useful data and the continuous flow of control messages. It might be possible to add intelligence so that the ISDN call is dropped when only control messages are detected - the soft-state would simply be reinitiated when data does begin to flow. However, this is an inelegant solution and requires co-operation at both ends of the ISDN connection. What is required is for an explicit graft soft-state rather than explicit prune soft-state. Such a solution may be offered by the sparse mode model of the Protocol Independent Multicast (PIM) [17] approach.

5.3 An experimental set-up

The UPI is not multicast-aware, so we must provide the multicast routing to the remote ISDN home/teleworkers by the use of multicast tunnels. These use IP-in-IP encapsulation, wrapping the multicast packet up in a unicast packet to traverse the tunnel. Ideally, we would like to set up one multicast tunnel that will send multicast packets to the UPI where they can be sent to the remote ISDN sites. At UCL, we have a class B address 128.16 from which we use the subnet 128.16.80 (0xfffff000) to route to ISDN remote hosts via the UPI. Therefore, we would like to set-up a tunnel between 128.16.0 and 128.16.80. However, this is not possible with the current multicast router software as it regards these both to be on the same network, and does not send data packets through such a tunnel. (This problem is shortly to be resolved by the introduction of netmask specifications into the configuration files for the router software.) So, at the moment, we must use another class B address (!), for the remote ISDN hosts.

Whilst not an ideal set-up, this configuration has enabled us to get some experience of using multicast applications over the ISDN. We have run the Visual Audio Tool (VAT) and Shared WhiteBoard (WB) applications from Lawrence Berkeley Laboratories (LBL) and can obtain useable performance from the system using just one B-channel. VAT allows the use of voice encodings at considerably less than 64Kbps. We have found that Linear Predictive Encoding at 9Kbps is quite intelligible between a pair of Sun 4s - so there is still some bandwidth available for the whiteboard. Whilst we have conducted experiments allowing multimedia conferencing using the ISDN by using a central switch control [12], we have yet to mount a large-scale experiment using IP multicast with home/teleworkers. We hope to do this in the next phase of our experiments.

6. Native ISDN Services

The ISDN interface hardware in the UPI is completely general and quite capable of handling continuous bit-stream traffic as well as HDLC framed traffic. There are several sources of such traffic on the ISDN:

Our intention is to enable such services to interwork with existing Internet and LAN services. For example:

6.1 Extending ISDN Services across the LAN

To achieve this extension, two essential tasks must be performed at the boundary between the LAN and the ISDN. First, the ISDN signalling must be carried across the LAN, second there must be a packetisation/de-packetisation function. The UPI software has been extended so it can perform both these tasks:

  1. A simple protocol has been developed which can be used to carry the necessary signalling across the network (see Section 6.2).
  2. Incoming bit-stream traffic is chopped up into fixed-size chunks, inserted into IP datagrams and forwarded across the LAN.
  3. Return traffic from the LAN is stripped of all headers and then transmitted as a bit-stream. A "play-out buffer" in the UPI smoothes out the irregularities in the datagram stream from the LAN.

In principle there is a timing problem to be solved. ISDN bit streams are clocked by the network and, generally speaking, directly attached devices take their timing from this clock. In theory the clock should be carried across the LAN to the workstations. However, this is not simple to do and may, in any case, be undesirable. Consider a simple audio stream from the ISDN:

We have decided to ignore the problem for the present as our initial work is focused mainly on voice. Experience suggests that the workstation and network clocks remain sufficiently in synchronisation that over-run or under-run occur only rarely. When over-run occurs a packet is dropped from the UPI's playout buffer. Under-run results in the repetition of the last packet sent. Neither of these events is particularly noticeable to a listener. Clearly these sort of data losses would be much more important for a video stream in which the compression algorithm encodes the differences between one video frame and the next. For such a stream, loss of a datagram would necessitate a lengthy re-synchronisation procedure.

6.2 Signalling

ISDN signalling protocols require rather more messages to set up a call than is commonly the case for data communications protocols. This is necessary to cope with the requirements of human users who expect to be informed of the progress of the call through "dial tones, "ring tones" etc. If we are to extend ISDN telecommunication services across the LAN we must mirror ISDN signalling to some extent. We illustrate the signalling we have implemented by considering the handling of voice calls. All signalling messages on the LAN are carried in single UDP datagrams. Those between the UPI and the digital exchange use the DASS2 protocol.

Consider first a voice call made from a LAN workstation to a PSTN phone. Referring to Figure 3, the workstation (W/S) sends a "Outgoing Call Init" message to the UPI (1) which causes the UPI to send an "Initial Service Request" message to the exchange (2). At this point the internal public network signalling takes over and, eventually, the remote phone will ring. The exchange informs the UPI that this has been done (3) and the UPI sends an "Outgoing Ring Ack" back to the workstation (4). At this point the workstation user can be given some indication - audible or visual - that the remote phone is ringing. Assuming the phone is answered, the exchange informs the UPI that the call has succeeded (5) and the UPI passes this information on to the workstation (6). Voice traffic may now begin.

Figure 3. Message sequence: outgoing call from W/S

The situation is more complex for a call coming from the ISDN. The first requirement is that the call should be routed to the correct LAN workstation. There are a number of ways in which this could be done:

  1. ISDN phones can generate a "sub-address" which would be passed to the UPI. We could allocate a different sub-address to each workstation and, thereby, select the correct recipient for the incoming call. Unfortunately, at present, most phones are connected via the PSTN and not the ISDN so this "solution" would be of limited use.
  2. We could pay for a set of "Direct Dial In" (DDI) numbers and allocate these to our workstations. This would work but DDI is expensive and we are a University ...
  3. We could accept the incoming call and use in-band signalling via DTMF tones to select the correct workstation. This means implementing a call answering service in software and implies the ability to recognise DTMF tones.

We have chosen option iii. All incoming calls are passed to a server process which deals with the initial signalling, transmits a voice "welcome" message to the caller and searches for DTMF tones in the incoming bit-stream through a digital filtering process. It then hands the call on to the correct workstation. Figure 4 shows the details for a call made from a PSTN phone.

Initially the UPI is informed of the call by signalling from the ISDN (1) and sends an "Incoming Call Init" message (2) to the "Incoming Call Server" (ICS) which listens for these on a well-known address. The ICS accepts the call (3)(4) and sends the welcome message on the newly opened voice link (5). The caller transmits the desired extension number using DTMF tones (6) and the ICS consults its database to find the address of the called workstation. The ICS then asks whether the workstation will accept the call (7)(8) and, if it will, tells the UPI to redirect the voice link to the workstation (9).

In our first version, the ICS database is static and is administered by a human manager. In fact the "extension" numbers used are identical to the ones allocated to workstation users on the main college PBX. In the future we intend that the database should be updated dynamically from information from "active badges" [18]. These are credit-card sized badges which may be worn by staff and which can be detected by sensors attached to workstations. For staff wearing these badges, calls may be directed to a workstation to which they are physically close, rather than to the "home" workstation.

6.3 Security Issues

The current implementation is entirely experimental and completely insecure. Thus it is possible for unauthorised users to make calls, for voice traffic to be monitored and, even, for an existing call to be re-directed elsewhere in mid-flight. At the very least we need to implement an authentication mechanism. We need this to be lightweight in order to minimise the per-packet overhead in the UPI. We intend to use a mechanism similar to that used in the SNMPv2 protocol[19]. This calculates a security checksum on each packet by applying the MD5 [20] algorithm to the payload of the packet concatenated with a shared secret value. It is computationally infeasible to calculate such a checksum correctly without knowing the secret value. Therefore, a packet with a correct checksum can be assumed to have originated from the possessor of the secret.

7. Additional Services

Once the mechanisms described in Sections 6.1 and 6.2 have been implemented we have a general method of directing ISDN bit-streams to LAN workstations. If the bit-stream is carrying 64Kbps PCM voice it is straightforward to implement a phone emulation on the workstation - the principle remaining issues are HCI ones. A number of interesting variations on this theme are possible however and these are discussed below.

7.1 Enhanced voice services

It is simple to provide each user with an answering machine. In fact this facility has been included in the design of the ICS which can adopt the answering machine rôle if it is unable to redirect an incoming call to the correct user. In the near future we intend to enhance this by allowing voice messages to be delivered to users through the mail system.

The reverse process is also possible. We can envisage a user composing a voice message and requesting that this be delivered by phone at a pre-arranged time. Of course, this kind of service is not without its dangers - we all know someone who deserves to be called in the middle of the night and regaled with, let us say, cuckoo-clock noises. At the very least we will need a call-logging service so that guilty parties can be identified!

7.2 Internet Audio Conferencing

We have begun work on a "gateway" between the VAT conferencing system and our LAN/ISDN voice system. The motivation is to allow users with nothing more sophisticated than a voice phone to join VAT conferences.

Figure 4. Incoming call handling

VAT can use a variety of voice encodings so one task of the gateway will be conversion between these encodings and the 64Kbps PCM used on the ISDN. This is a comparatively straightforward though computationally expensive task.

We envisage the gateway as a server process to which we allocate an extension number. A caller who wishes to join a VAT conference calls the UPI, tone-dials the VAT gateway extension number and is passed to the gateway by the ICS as described in Section 6.2. By means of a pre-recorded voice message the VAT gateway then asks the user to enter (via tones again) the address of the conference s/he wishes to join. We intend to add a simple directory function which will allow the user to be read a list of available conferences. Once the caller has selected a conference, a new process will be forked to handle the rest of the call.

7.3 One-to-one calls via the Internet

The system we are developing at present is intended to provide access to ISDN services for local LAN users. There are circumstances in which one would like to extend this access to non-local users. For example, there have been occasions where a member of staff attending a conference or demonstration away from UCL needs to phone another staff member in his/her home (for business use, obviously). It is not unusual at these events to find it easier to obtain access to a workstation on the Internet than it is to get hold of a phone which can be used Internationally. If a voice call could be made across the Internet to UCL, with the last hop being a local call through the UPI, then the problem would be solved.

For such a solution to be viable, it must be possible to make the call from a "standard" workstation - i.e. no specialised software should be required. A mechanism has been devised which requires only the availability of telnet and VAT on the remote system. In fact this is based on a prototype which was used to provide a service to the UK from INET '94 in Prague. In this service, a telnet session was opened to a special server at UCL The caller logged on to the server - authenticating him/herself by means of a password - and was then prompted for the number to be dialled. The server now allocated an address to be used in a private VAT session between itself and the caller. At the same time it initiated the ISDN/PSTN call. In the Prague prototype this was done through a Tandberg videophone directly attached to the workstation which hosted the server. We now propose modifying this system so that it initiates the ISDN call via a signalling exchange with the UPI. Once the call has succeeded the called party will be tied in to the VAT session in a way similar to that of Section 7.2. (An interesting side-effect of this, of course, is the avoidance of International telephone charges.)

7.4 Non-voice services

Obviously, today, the analogue service provided by the PSTN carries traffic types other than voice. Of particular interest are fax and data services provided through MODEMs. We are currently designing a system to implement such services through our ISDN gateway, with implementation scheduled to take place in the summer. The intention is that the ICS should hand such calls to a specialised server which emulates a MODEM. With this service in place we could offer up to 30 extra lines for home users with MODEMs and give all our users the facility to send and receive faxes.

The task of the server is quite intensive computationally. The bit stream it receives from the ISDN will be the 64Kbps PCM samples from an analogue signal which is itself a result of a (possibly complex) modulation of the original digital signal. Successful implementation will require the application of quite complex digital filtering techniques in near real time. However, we are optimistic that this can be done at least for the more simple (and slower) modulation techniques.

8. Conclusions and Future Plans

The UPI has proved to be a useful tool which has enabled us to investigate various aspects of interworking between ISDN and the Internet. As a bonus, it has also enabled us to provide a useful Internet access service for UCL staff. We are optimistic that, in the future, we will be able to extend the service to include voice and MODEM support for non-ISDN users.

In summary, the current situation is as follows:

In the next few months we plan to complete the following:

9. Acknowledgements

This work has been supported by contracts from the European Commission under the ESPRIT programme. In particular, support has come from the PROOF (Primary Rate ISDN OSI Office) and MIDAS (Management In a Distributed Application and Service environment) projects.Much of the implementation and detailed software design for components of this system has been done as project work by students on the UCL "Data Communications Networks and Distributed Systems" MSc course - and this is to continue over this summer. The authors are very grateful for the hard work put in by (in alphabetical order); Matthew Album, Mike Breretton, Lionel Chaine, Spiros Chatzis, Ronan Flood, Dimitris Glitsos, Dimitris Kogias, Geok Kwok, Cheng Quek, Peng Tan, Garry Telloke and Thiam Yeo.


[1] Extending the LAN via ISDN", Proc. INET'93 International Networking Conference", Internet Society, Reston, Virginia, 1993

[2] CCITT G.703, "Physical and Electrical Characteristics of hierarchical digital interfaces", CCITT Blue Book Fascicle III.4, 1988

[3] CCITT G.704, "Synchronous Frame Structures used at Primary and Secondary Hierarchical Levels", CCITT Blue Book Fascicle III.4, 1988

[3] CCITT G.704, "Synchronous Frame Structures used at Primary and Secondary Hierarchical Levels", CCITT Blue Book Fascicle III.4, 1988

[4] CCITT Q.931, "ISDN User-Network Interface Layer 3 - Specification of Basic Call Control", CCITT Blue Book, Fascicle Vi.8, 1988

[5] British Telecom, "Digital Access Signalling System No. 2 (DASS2)", Volume 1 - Core Document - Issue 2, Draft 2, Sept. 1988

[6] W. Simpson, "The Point-to-Point Protocol (PPP)", Internet RFC1661, 07/21/1994

[7] The CAPI Association, "Common API version1.1 Profile A". Sept. 7 1990

[8] Herbert Hanewinkel, "ISPA Version 2.0.4, a Packet-Driver for ISDN-API 1.1", Am Haderner Winkel 9, D-82061 Neuried, Germany, October 1994

[9] Peter R. Tattam "TRUMPET WINSOCK Version 2.0", Trumpet Software International Pty Ltd. 1994

[10] Brad Clements, "Clarkson University Extensions to NCSA Telnet for the PC Version 2.2TN and Version 2.2D", Educational Resources Center, Clarkson University, Potsdam NY 13676, July 1988

[11] B. Lloyd, W. Simpson, "PPP Authentication Protocols", Internet RFC1334, 10/20/1992

[12] S Clayman, Bjorn Hestnes, Peter Kirstein, "The Interworking of Internet and ISDN Networks for Multimedia Conferencing" To appear in "Information Systems and Use", 1995

[13] S. Deering, "Host extensions for IP multicasting", RFC 1122, Aug 1988

[14] S. E. Deering "Multicast Routing in a Datagram Network", PhD Thesis, Stanford University, California, USA, 1991

[15] S. Deering, C. Partridge, D. Waitzman, "Distance vector multicast routing protocol", Internet RFC 1075, Nov. 1998

[16] S. Deering, "Multicast routing in Internetworks and Extended LANs", ACM Symposium on Communication Architectures and Protocols, pp 55-64, ACM SIGCOMM, Aug 1998

[17] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, L. Wei, "Protocol Independent Multicast (PIM): Motivation and Architecture", Work In Progress, Internet-Draft (draft-ietf-idmr-pim-arh-01.ps) Jan 1995

[18] R. Want, A. Hopper, V. Falacao, J. Gibbons "The Active Badge Location System", Olivetti Research Ltd.

[19] J. Galvin, K. McCloghrie, "Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)", Internet RFC1446, 05/03/1993.

[20] R. Rivest, "The MD5 Message-Digest Algorithm", Internet RFC1321, 04/16/1992

Author Information

Graham Knight (http://www.cs.ucl.ac.uk/staff/G.Knight

Saleem N Bhatti (http://www.cs.ucl.ac.uk/staff/S.Bhatti

Stuart Clayman (http://www.cs.ucl.ac.uk/staff/S.Clayman

Return to the Table of Contents