Simple Phone Control Protocol (SPCP) :
IP Phone-Computer interaction for IP telephony services

Noriyuki Fukuyama <>
Fujitsu Laboratories Ltd.

Tsuyoshi Kanai <>
Fujitsu Laboratories of America, Inc.

Masanobu Morinaga <>
Fujitsu Laboratories Ltd.

Masahiro Matsuda <>
Fujitsu Laboratories Ltd.


The telephone will remain an essential component of telephony services even in a VoIP era. But its role would be limited to providing the user interface and basic call signaling control. More enhanced services should be produced by a cooperation with a computer connected through the IP network. This paper discusses our solution for IP Phone and computer interaction including our proposal for a protocol for those interactions. We call it "Simple Phone Control Protocol" or SPCP.


1. Introduction

Thanks to technical innovation and standardization, VoIP is now maturing as a practical technology. Its market is expected to expand rapidly in the near future. In the first stage of the technology's evolution, a call control mechanism was the biggest issue because it is the most essential for IP telephony systems. Now several call control protocols, including H.323[1], H.248[2] and SIP[3], seem to be solutions. Among the technical issues in a next stage we have chosen to fucus on the front-end of VoIP systems. We have worked to enhance IP telephony services as seen directly by users on an IP Phone or a VoIP client.

This paper discusses our solution for IP Phone and computer interaction including our proposal for a protocol for those interactions. We call it "Simple Phone Control Protocol" or SPCP[4].

2. IP Phone-Computer interaction for IP telephony services

2.1 IP Phone as a front-end of IP telephony services.

There are two types of front-ends for IP telephony services. One consists of a phone programmed ( in software) on a computer with audio input and output devices. This is known as a Soft Phone. Another is a conventional stand alone terminal used only for telephony. This is known as an IP Phone.

At the dawn of the VoIP technology, Soft Phones were the only options for an IP telephony terminal because it is easy implementation without any special hardware. The biggest advantage of the Soft Phone is the flexibility and feasibility of variety of telephony services. However, the Soft Phone user interface is still behind telephone's which has a long history as a telephony terminal.

This complexity of user interfaces for the Soft Phones tells us that even when using VoIP the telephone still remains an important user interface component.

2.2 Telephony service enhancement by IP Phone-Computer interaction

Though IP Phones have better interfaces for telephony services, when it comes to service enhancement, IP Phones fall behind Soft Phones. This is because of the IP Phones considerably limited information processing capabilities. Our approach to maintaining the power and familiarity of the telephone terminal as a user interface while enabling the enhanced services of the Soft Phone is IP Phone-Computer interaction. In our model an IP Phone handles basic telephony functions and the user interface. In addition, a computer, which is connected to the IP Phone, is in charge of the highly enhanced functions.

From hardware point of view this model might be considered a traditional Soft Phone which relocates its audio devices to a telephone-like device. However, our solution is actually completely different. In the Soft Phone solution just described, the telephone-like device isn't in charge of call control. It is just used as a user interface device for the computer. The Soft Phone cannot work by itself.

In our solution the IP Phone handles basic call functions and user interface. It can work stand-alone. The computer manages additional enhanced services by controlling the IP Phone through an abstracted interface.

In that sense, an IP Phone in our solution can be replaced by a Soft Phone. In such a scenario an application on one computer controls a Soft Phone on an another computer.

2.3 IP Phone-Computer connection

In conventional Computer Telephony Interface (CTI) systems, there were two individual networks. The PSTN was used for telephony and the IP network was used for computers. Interaction between telephone and computer needed special hardware and software to accommodate the differences between the two networks. (This remains the role of the MODEM.) However, since VoIP systems are based entirely on the IP network, the special devices are no longer necessary.

IP Phones enable interaction with almost any device on the IP network. As such, it is obvious that an open standard protocol is needed. Otherwise only limited number of devices will be able to interact with an IP Phone.

2.4 Sample services of IP Phone-Computer interaction

Here are some concrete examples of IP Phone-Computer interaction services.

2.4.1 Smart Phone Book

When a user chooses a calling party with a phone book application on a PC, the calling party's information is passed from the PC to the IP Phone. Then the IP Phone makes a call according to that information.

The phone book application keeps watching the IP Phone to record its status changes (e.g. connection established/busy/no answer) or call information (e.g. time stamp/elapsed time). This information can be used by other applications.

When the IP Phone gets an incoming call, it passes the call information to the PC. The application on the PC can search for the calling party's data in a local (or remote) database, and display that information on the PC's screen.

2.4.2 Voice Message

A user records some outgoing messages which are appropriate for certain situations or callers, and saves them on the PC. When an IP Phone receives an incoming call the application on the PC sends a response message to the IP Phone appropriate to the situation or the caller. The PC then records caller's voice message from the IP Phone and saves it, for playback at the convenience of the call recipient.

2.4.3 Multimedia Conference

A user pushes a particular function key on an IP Phone during a call. An application on a PC gets information of this call and then searches calling party's detailed information in its database. Then it initiates other connections to the calling party in different media types.

3. IP Phone-Computer interface

This section discusses requirements for IP Phone-Computer interfaces, then investigates several telephony interfaces.

3.1 Requirement

After looking at many sample services, we found the following sets of functions are necessary for the IP Phone-Computer interface.

+ Call control functions:

Functions the computer uses to operates a call on the IP Phone. It must be noted that the computer doesn't have to manage the whole process of the call. Those functions should be abstracted and simplified considerably. All they need to be capable of is initiating or watching call events.

+ Configuration control functions

Functions which the computer uses to operate the IP Phone configuration.

+ Data transaction functions

Functions the computer uses to exchanges some data with the IP Phone.

+ Device control functions

Functions with which the computer controls devices on the IP Phone.

3.2 Existing interfaces

This section looks at some existing interfaces from the perspective of the requirement outlined above.


SIP is a protocol which initiates a call. It describes not only a caller's address but also media types in SDP[5] format. SIP can be launched by a third party, which is neither a recipient nor a caller. So SIP could be used for the IP Phone-Computer interface. However it seems to be too involved and specific on call control. For instance we don't need SIP's features enabling negotiation with a recipient about address conversion method, communication media or so on. And SIP doesn't have other functions except for call control functions.

+ H.248

H.248 is a call control protocol with which a computer (Media Gateway Controller) controls an IP Phone (Media Gateway). So it should be examined to see if it meets the requirements. However H.248 is also too specific. It requires the computer to manage the whole process of a call. In our model the IP Phone handles much of this work.

+ H.323

H.323 is also a call control protocol for end-to-end. It doesn't meet the requirement.


The purpose of TAPI is almost same as ours. However it is an API for a telephony application, not a protocol. But it would be useful to migrate existing TAPI applications to our architecture. Then they could work with an SPCP driver for TAPI.

+ AT command

AT command is also an API. It might be possible to migrate AT command applications by using some sort of converter.

3.3 Proposed protocol

Since no existing protocols meet the requirements, we have developed a new protocol, named Simple Phone Control Protocol or SPCP. Figure 1 show a system diagram for SPCP usage. SPCP is outside of the main stream of the call signaling process. It just initiates or watches call events on an IP Phone indirectly. This means that SPCP can work with any call control protocol, including H.323, SIP or H.248.

Figure 1. System diagram for Simple Phone Control Protocol(SPCP)

4. Simple Phone Control Protocol (SPCP)

This section describes the details of SPCP.

4.1 Design criteria

Since an IP Phone is a quite new device, there are several issues to resolve. Overcoming these issues helped guide the design of SPCP.

- IP network

On a conventional Telephone-Computer interface through a MODEM, the connection can only be one-on-one. In an IP Phone-Computer interface through the IP network, N-on-M connections are available. An IP Phone can interact with any network device on the IP network, or any subset of devices. This enables a variety of new telephony services. But at the same time it raises new security issues. After all, any devices could invade the IP Phone. Another issue is a packet loss and delay on the IP network. Because IP networks are 'best effort' networks, packet delivery and latency is inconsistent.

- IP Phone

The IP Phone specification (including the number or location of function keys, display size or other devices) might vary between makers. A new IP Phone which is E-mail or Web capable is likely to emerge soon. SPCP should be able to work with those different user interfaces or functions. So we designed the protocol by assuming that an IP Phone has minimum call control functionality and user interface.

4.2 Protocol features

- Text base message

SPCP's messages are containers of plain text. Its syntax is similar to HTTP's[6]. SPCP is extensible and easy to debug.

- Server-client model

SPCP is a protocol for server-client architecture, in which an IP Phone acts as a server and a computer functions as a client.

- Notification mechanism

SPCP has functions for notifying the PC when there is a change in an IP Phone's call status.

- TCP connection

SPCP uses TCP for its transport layer. Even N-to-M connections can be handled by using TCP connection identification. And TCP has a capability of recovering missing packets.

- User authentication

SPCP adopts a challenge-response authentication method[7, 8]. Authentication is necessary for preventing illegal access to an IP Phone. Authentication also allows user dependent services.

- Multiple call capability

SPCP can handle multiple calls by using a call reference number. Then it can work with a gateway or a terminal adaptor which handle multiple calls.

- Media data transfer

SPCP uses an HTTP like syntax so that it can handle multimedia data[9] (such as text, voice or images) in the same manner. An IP Phone can use HD storage on a computer as an extra storage device. More complex process can be handled by exchanging programmed scripts as media data.

- Flexible GUI

SPCP has functions to get/modify button information and control/watch buttons. Those are designed to be flexible in order to accommodate various types of IP Phones.

4.3 Command









Release session



Call control

Make call



Send dialed digits



Answer incoming call



Hung up



Suprementary service

Hold call



Park call



Transfer call



Forward incoming call



Reject incoming call



Conference call



Inquire notice



Control QoS



Media/device control

Send/receive data



Set/get information



Order function




Inquire product name



Check presence



Self test



Proprietary use





Session established



Call control

Calling recipient






Incoming call received



Recipient busy






Suprementary service

Event notice



Device control





Progress notice



Proprietary user



Figure 2. Table of messages (Request/Notice)

5. Conclusion

The telephone will remain an essential component of telephony services even in a VoIP era. But its role would be limited to providing the user interface and basic call signaling control. More enhanced services must be produced by a cooperation with a computer connected through the IP network. In a conventional PSTN era a related cooperation worked through MODEM interface. The MODEM interface offered very limited functionality and its services were mediocre at best. However once the telephone is smoothly coupled to the IP network, capabilities will be open to lots of network devices and its potential will expand considerably.

Quite a few people are aware of the potential of IP Phone-Computer interaction. But unfortunately they tend to focus on individual application implementation and don't think about establishing common interface. If independent applications continue to be produced in ever growing numbers, IP Phones which serve only a particular application will proliferate. That reduces potential for IP telephony as a whole. Since an IP Phone is an important resource of IP telephony, it must be open to all of applications. This is a textbook case where a standard is called for. It is in this spirit that we offer SPCP.


  1. ITU-T Recommendation H.323, "Packet Based Multimedia Communications Systems", ITU-T, 1998.
  2. ITU-T Recommendation H.248, "Media Gateway Control Protocol", ITU-T, 2000.
  3. M. Handley, H. Schulzrinne, E. Schooler and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, IETF, March 1999.
  4. T. Kanai, M. Morinaga, N. Fukuyama and M. Matsuda, "Simple Phone Control Protocol (SPCP)",, IETF Internet-draft, December, 1999.
  5. M. Handley and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, IETF, April 1998.
  6. R. Fielding, J. Gettys, J. Mogul and H. Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1" STD 1, RFC 2068, IETF, January 1997.
  7. J. Klensin, R. Catoe and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response" STD 1, RFC 2195, September 1997.
  8. R. Rivest, "The MD5 Message-Digest Algorithm" RFC 1321, April 1992.
  9. N. Borenstein and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies." RFC 1521, Bellcore, Innosoft, September 1993.