WO2001035594A2

WO2001035594A2 - Telecommunications control protocol processing

Info

Publication number: WO2001035594A2
Application number: PCT/GB2000/004274
Authority: WO
Inventors: Anargyros Garyfalos
Original assignee: British Telecommunications Public Limited Company
Priority date: 1999-11-08
Filing date: 2000-11-08
Publication date: 2001-05-17
Also published as: WO2001035594A3; AU1163601A

Abstract

A software application program for processing control messages constructed in accordance with a telecommunications control protocol, said program having an object-oriented structure and being arranged to dynamically load an object class, whereby a control message is processed, at run time.

Description

TELECOMMUNICATIONS CONTROL PROTOCOL PROCESSING

This invention relates to telecommunications control protocol processing, and in particular a software application program, and data processing means, for processing control messages constructed in accordance with a telecommunications control protocol. The invention is particularly, but not exclusively, directed to text-based application-layer control protocols.

The Session Initiation Protocol (SIP) is an application-layer control protocol for creating, modifying and terminating sessions having one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these. SIP supports session descriptions that allow participants to agree on a set of compatible media types. It also supports user mobility by proxying and redirecting requests to the user's current location. SIP is not tied to any particular conference control protocol. There is widespread interest in the protocol, especially for telephony-related applications. SIP was proposed by the Internet Engineering Task Force (IETF) group and is now a proposed standard published as RFC 2543. The entities used in SIP are user agents, proxy servers, redirect serves and location servers. A user is addressed using an email-like address "user@host", where "user is a user name or phone number and "host" is a domain name or numerical Internet Protocol (IP) address. SIP defines a number of request types, in particular INVITE, ACK, BYE, OPTIONS, CANCEL, and REGISTER. Responses to SIP messages indicate success or failure, distinguished by status codes, 1 xx ( 100 to 1 99) for progress updates, 2xx for success, 3xx for redirection, and higher numbers for failure. Each new SIP transaction has a unique call identifier (call ID), which identifies the session. If the session needs to be modified, e.g. for adding another media, the same call identifier is used as in the initial request, in order to indicate that this is a modification of an existing session.

The SIP user agent has two basic functions: listening for incoming SIP messages, and sending SIP messages upon user actions or incoming messages. The SIP user agent typically also starts appropriate applications according to the session that has been established. The SIP proxy server relays SIP messages, so that it is possible to use a domain name to find a user, rather than knowing the IP address or name of the host. An SIP proxy can thereby also be used to hide the location of the user. A redirect server returns the location of the host rather than relaying the SIP message. Both redirect and proxy servers accept registrations from users, in which the current location of the user is given. The user's location can be stored at a dedicated location server. Typical signalling sequences between two user agents UA (A) and UA (B) over an IP network using an SIP redirect server (RS), and an SIP proxy server (PS), each also using an SIP location server (LS), are shown in Figs. 1 and 2, respectively.

SIP is typically implemented by transmitting Internet Protocol (IP) packets. SIP is independent of the packet layer and only requires an unreliable datagram service, as it provides its own reliability mechanism. While SIP typically is used over UDP or TCP, it could be used over frame relay, ATM AAL5 or X.25.

SIP is a text based protocol and is based to a certain extent (in terms of syntax) on the HTTP protocol. A typical messages consists of a single request line, a number of header lines and a message body.

The request line indicates the type of the messages, the message destination and the SIP version it complies with. The following is a typical example:

INVITE sip:Richard@bt.com SIP/2.0

A header line contains the name of the header type, followed by a semicolon and the contents as these are defined for the specific header. Consequently, each header type is used for a specific purpose (either to indicate some parameters or to issue a request). The following are typical examples: From: sip:Richard@bt.com To: sip:Steve@bt.com Subject: Official meeting The message body may be of any content, although it usually has contents formatted in accordance with the Session Description Protocol (SDP).

Extensibility of SIP may be achieved by the definition of new header types. For example, a desired charging scheme may be implemented using a new header type which contains several parameters. The following is and example of an SIP header line including and example of a new header type (BT_charge): BT charge: Allowed_bandwidth = X, Tarrif = Y

The definition of such new header types is a mechanism which offers both flexibility and extensibility.

There is a drawback with the definition of new header types in known implementations of SIP. For example, in a direct User Agent to user Agent interaction User Agent A may support the extension BT_charge whereas User Agent B may not. In this example, BT charge may specify a number of new headers or even new request types that allow an efficient negotiation on charging issues about the multimedia session to be set up. When User Agent A sends an invitation to B, it may explicitly specifies that it requires B to support the BT_charge extension in order to proceed. This can be done by the inclusion of a standard SIP header called "Require" in the first INVITE request. In this way, when User Agent A sends an invitation to B containing the Require header, B determines that it does not support the BT_charge extension and sends a negative response indicating the reason, that is to say, BT charge not supported. Interaction between A and B is then terminated. In order for B to be able to support the BT_charge extension, a system administrator must shut down B obtain details of the required extension and then implement the new header and request types by loading a new program or modifying the system code, and restart the User Agent. The time and effort required to do this renders the process unviable, both in terms of cost and performance. In addition, further problems may arise due to differences in the implementations of the respective extensions.

In accordance with one aspect of the present invention there is provided a software application program for processing control messages constructed in accordance with a telecommunications control protocol, said program having an object-oriented structure and being arranged to dynamically load an object class, whereby a control message is processed, at run time.

By using the dynamic class loading capabilities of an object-oriented programming language, new classes can be loaded into an already running telecommunications control protocol implementing system and can be used as though they were available at the time the system was started. Thus, control messages containing new, or modified, protocol elements can be handled by the system without the necessity for a new program to be loaded, or the system to be shut down for modifications to its program code to be made. In this way delay is reduced to an acceptable level.

One example of an object-oriented programming language having dynamic class loading capabilities is Java (Registered Trade Mark) . When a Java Virtual Machine (JVM) is started up, the byte-code for various classes is loaded into the JVM prior to commencement of execution of the specified program. The classes loaded include all those that are needed for the specified program to run. Up to this point, the process of class loading is performed using native code which assumes that the byte code files for the required classes reside on the local file system, and may be located by making use of the CLASSPATH environment variable. Once execution has commenced, it is possible to dynamically load further classes in one of two ways. If the byte code file of the required class is available locally, and can be located by following the CLASSPATH, then the static method Class. forName (), which is briefly documented in Appendix A1 and Appendix A2 and, can be used to load the class as a system class. If the byte code file is not available locally, or cannot be traced via the CLASSPATH, then it can be loaded from a remote source by means of a Java Remote Method Invocation (RMI) ClassLoader function or a Java URLCIassLoader function.

In accordance with a further aspect of the invention there is provided a software application program for processing control messages constructed in accordance with a telecommunications control protocol, said protocol defining a control message to have a construction including one or more protocol elements of a predefined format and having a plurality of respective types, wherein said program is arranged to process a control message by means of a different element type processing means for each of said plurality of respective types of at least one of said protocol elements, and, on receipt of a control message from a remote party that indicates that an element type processing means for a type of said at least one of said protocol elements is not available locally, to retrieve said unavailable element type processing means remotely in order to process a control message received from, or to be sent to, said remote party.

The two parties involved can then conduct communications in accordance with the desired telecommunications control protocol, even where initially the two parties are running different versions of the protocol.

The program preferably has an object-oriented structure, in which the processing means is or are one or more object classes. The locally unavailable object class or classes are preferably retrieved by dynamically loading the missing class or classes during run time. As mentioned above, the RMI ClassLoader class provided in Java can be used to allow such dynamic class loading from a remote file system.

In a preferred embodiment, the locally unavailable object class or classes are retrieved from a source identified in the control message sent by the remote party. Locally unavailable Java byte code files may be retrieved from a location identified in the control message and loaded using the method URLCIassLoader documented in Appendix A3. In this way, control messages containing new, or modified, protocol element types can be handled in a seamless manner even if the respective object class or classes are locally unavailable and their remote locations initially unknown to the receiving party.

Thus, in embodiments of both aspects of the invention, the program is structured to allow not only new header types, but also new request types, to be processed using classes loaded by a dynamic loading function during run time.

Preferred embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

Figures 1 and 2 show typical session control signalling used in SIP; Figure 3 shows a schematic illustration of an SIP control program to be implemented on a user side device in accordance with an embodiment of the invention; Figure 4 shows a schematic illustration of a part of the SIP control message handling method of the program illustrated in Figure 3; Figure 5 shows a generic class diagram, using a Universal Modelling Language (UML) notation, of the classes in a SIP protocol program component according to an embodiment of the invention;

Figure 6 shows an event diagram at the arrival of an SIP message, using the SIP protocol component illustrated in Figure 5;

Figure 7 is an event diagram showing the parsing of an SIP message using the SIP protocol component illustrated in Figure 5; and

Figure 8 is an event diagram showing the construction of an SIP message using the SIP protocol component illustrated in Figure 5. Referring now to Figure 3, in this embodiment of the invention an SIP control programme 2, implemented in Java and to be run on a user-side computer workstation with an IP connection, includes an SIP protocol component, ServicePack component 6 and a MultimediaApplication interface 8.

The ServicePack 6 is responsible for containing and operating any call control services: these are created by a service developer.

The MultimediaApplication interface 8 is a simple Java Interface with certain functions. It is intended to be inherited by the actual Multimedia application (i.e. videoconferencing, IP telephony tools, etc) in order to offer a standard API to the SIP control program 2. The SIP protocol component 4 is responsible for handling all activities related to the protocol functionality (parsing/constructing messages, setting timeouts, etc). It "translates" them into events out of the context of SIP and notifies the other parts on the generation of these events. For example, when receiving an SIP request, it will send the appropriate temporary responses and then it will pass the relevant event type to the ServicePack 6. Subsequently, the defined call control will be triggered and the final response type will be passed back to the SIP protocol component 4. Based on that response, the final response will be sent back to the calling user agent and if necessary the object inheriting the MultimediaApplication interface will be notified (i.e. Start/End application, pass parameters, etc).

The main parts of the SIP protocol component 4 are the following:

An API part which offers a standard interface to the external applications; A Headers part which contains header classes for all the different header types supported by the SIP protocol component;

A Message Handling part which contains message parser and constructor classes; A User Agent part which includes classes forming the front end part of the application; and

A Handlers part which contains all the class objects (handlers) each of which is responsible for handling the operation of the protocol for different respective request types received in incoming messages.

The modularity of the Headers part and the Handlers part facilitates extensibility both in terms of changing a single header or handler class, and in terms of adding a new header or handler class. More explanation on this part is provided below. Figure 4 shows an overview of the Message Handling part operating on an incoming SIP control message 10.

Whenever a packet containing an SIP control message 1 0 arrives, it is initially in the form of a text string containing the request line and the header lines. The message 10 is passed to an instance of a MessageParser class 1 2, which parses the text string and creates an instance of an SIPMessage object 14. This class contains a vector list 1 6 of different objects corresponding to the request line and all the header lines contained in the original message. The vector list 1 6 objects illustrated in the example of Figure 4 include a request line object 1 8, a VIA header object 20, a FROM header object 22, a TO header object, and one or more other header objects 26.

The remaining parts of the application can now operate on the SIPMessage object 14 and they retrieve the required information by questioning the corresponding object of the Vector list.

Whenever the MessageParser 1 2 reads a line from the textual representation of the message, it takes the first word (which denotes the type of the header), and by using the method Class. forNameO (Appendices A1 and A2), dynamically searches for and loads a locally available header class with that name. If the header class is not found or the message contains an header that identifies a remote location where the locally unavailable header class can be retrieved, then the method URLCIassLoader (Appendix A3) is used to retrieve and dynamically load that header class.

For instance, using the Class. forName () method, if the MessageParser 1 2 reads the line "BT_charge:Allowed_Bandwidth = X Tarrif = Y", the MessageParser will dynamically search for the class type BT_charge indicated at the start of the header line, and through a standard function (ReadContents in this Java embodiment) will pass the rest of the line to be parsed by and included in an instance of the BT charge header class. If the class type BT charge is not found in local storage using the Class. forName () method the MessageParser will use the

URLCIassLoader method to first retrieve the class type BT_charge from a remote location identified in the message. The location identifier may be a URL. In order to support this additional functionality a new header type is required. For instance, a new header type can be defined as:-

Class_Repository = ("Class-Repository" | "cl") ":" 1 * URL

For example:

Class_Repository = http://www.jungle.bt.co.uk/SIPheaders/

Class_Repository = http://www.jungle.bt.co.uk/SIPheaders/, http://www.bt.com/SIPheaders

A new header of the above type may be used when an SIP User Agent indicates to another User Agent the location of one or more a header classes that are necessary for an SIP session to take place. For example, if User Agent A sends an SIP invitation message to User Agent B, the message may include a Class-Repository header which identifies the location of one or more header classes. On receipt of the message User Agent B checks whether the header classes are available locally and loads any that are not from the URL location identified in the Class_Repository header. Since the classes are loaded at run time the interaction between A and B is seamless and continues as if all the header classes were available locally to B.

Although it may be argued that the above approach to parsing different elements of the incoming SIP message 10 imposes a performance penalty, it introduces the advantage that message parsing is performed in a way which facilitates the extensibility of the application to handle new header types. Using this technique, to change the SIP protocol to support a non-standard extension, the following steps are carried out (exemplary code fragments are available from Appendix B):

1 . Create a header class that implements the Header interface (see Appendix B.1 ).

2. Implement the functions defined by the interface and those needed for the operation of the class (See Appendix B.2). 3. Store the new class in storage accessible to the SIP protocol component during run time. The storage may be either local or remote, with the MessageParser 12 dynamically loading the new class during run time.

The code which allows this flexibility resides in the MessageParser class (See appendix B.3) . Since at least in Java the name of a class cannot contain any "-" characters, whenever the MessageParser 1 2 replaces it with the "_" character instead (e.g. dynamically loading a class named calljd instead of call-id).

Figure 5 is a generic class diagram, using UML notation, showing the most important functions, attributes and relations between the classes that implement the dynamic class loading feature of the SIP protocol component 4. This component 4 includes the MessageParser class 1 2 and the SIPMessage class 14 referred to above. Also included is a UserAgent class 30 which implements an SIP interface 32, whereby access to the SIP protocol component 4 by external applications is provided. The UserAgent class 30 contains a UDP class 36, whereby IP network functions (datagram packet receipt and sending) is enabled. The UserAgent 30 uses the MessageParser class 1 2 to create an instance of the SIPMessage class 14. The SIPMessage class 14 contains one or more header object classes 42. In Figure 5, the header object classes 42 are indicated generically, with individual classes corresponding to each currently supported SIP header type and possible future SIP header type extensions. Each example of the header objects class 42 implements a standard header interface 44, whereby the SIPMessage accesses the header object class 42.

The UserAgent class 30 also contains zero or more instances of a UAThread class 46. One instance of the UAThread class 46 is created for each call ID currently handled by the SIP protocol component 4. The UAThread class 46 contains a handler object 48, which implements a handler interface 50 whereby the handler object is accessed by the UAThread class 46. In Figure 5, the handler object classes 48 are indicated generically, with individual classes corresponding to each currently supported SIP request type and possible future SIP request type extensions. Each example of the handler objects class 48 implements a standard handler interface 50, whereby the UAThread class 46 accesses the handler object class 48. At any one time, an instance of the handler object class 48 uses either an incoming SIPMessage, an outgoing SIPMessage, or both. Therefore, the handler object class may use up to a maximum of two SIPMessages. In Figure 5, the indication "Handler Object" does not define the name of a class, but stands for any class that implements the handler interface. Apart from the inherited functions, each "Handler Object" may have different attributes and functions. The same applies to the indication "Header Object".

The UserAgent class 30 also uses a MessageConstructor class 52, which reads from the SIPMessage class 14 in order to construct an SIP control message, formatted as a text string with the various request lines, message lines, header lines and message body lines as specified in the SIP protocol, to create an outgoing packet to be sent by the UDP class 36.

Figure 6 illustrates an event sequence beginning with the receipt of an SIP control message by the SIP protocol component 4. Wherever appropriate, instances of classes described in Figure 5 are annotated with the same reference numerals, incremented by 100. In step 1 , a UDP object 1 36 passes the received text string message to a UserAgent object 30. In step 2, the UserAgent object 136 passes the text string message to a MessageParser object 1 1 2, which in step 3 creates an incoming SIPMessage object 1 14A. The creation of the incoming SIPMessage object is described in further detail below with reference to Figure 7. In steps 5 and 6, the SIPMessage object is passed back to the UserAgent object, which then retrieves the caller ID from the caller ID header object in the SIPMessage object 1 14A. The UserAgent object then creates a UAThread object 146, having the appropriate caller ID as an attribute, using the incoming SIPMessage object 1 14A. The UAThread object 146 then retrieves the type of SIPMessage from the SIPMessage object 1 1 4A in steps 8 and 9, and initiates a handler object 148 of the appropriate request type with the incoming SIPMessage object 1 14A, in step 10. In step 1 1 , the handler object 148 processes the incoming SIPMessage object 1 14A and decides on a response thereto, in the form of a type of outgoing control message to be sent. In step 1 2, the handler object 148 creates an instance of the SIPMessage class 1 14 in the form of an outgoing SIPMessage object 1 14B, containing the appropriate request line and header objects as a vector list. In step 1 3, the handler object 148 passes the outgoing SIPMessage object 1 14B to the UAThread object 146, which in turn passes the outgoing SIPMessage object 1 14B to the UserAgent object 1 30, calling on the UserAgent object 130 to send the outgoing SIPMessage. In step 1 5, the UserAgent object 1 30 creates a MessageConstructor object 1 52, calling on the MessageConstructor object to create a text string message to be included in an outgoing UDP packet. The Message Constructor object 1 52 in steps 1 6 and 1 7 retrieves the appropriate header objects, and thereby, in step 1 8, constructs the text string to be sent out in the UDP packet which is then passed to the UserAgent 130 in step 1 9. Finally, in step 20, the UserAgent object 130 calls on the UDP object 1 36 to send the constructed SIP control message on an appropriate interface. Referring now to Figure 7, when the MessageParser object 1 1 2 is requested by the UserAgent object 1 30 to create an SIP message, step 1 , the packet is passed as a string object 1 10. The MessageParser calls on the object and reads the first line of the SIP protocol message, steps 2 and 3. In step 4, the MessageParser 1 1 2 identifies the type of request of the message, and constructs the appropriate incoming SIP message object 1 14A.

Next, the MessageParser object 1 1 2 reads the next line, the first header line, of the message string and dynamically loads the appropriate header class, step 8. It then passes the line string to the appropriate header object 1 26A, and adds the header object 1 26A to the incoming SIPMessage 1 14A. The operation is repeated, in steps 1 1 to 1 5, for the next line of the incoming SIPMessage, and for as many header lines as present in the incoming SIPMessage. Once the vector list of header objects is completed, the SIPMessage object 1 14A is passed back to the UserAgent 1 30. Referring now to Figure 8, when the Message Constructor object 1 52 is requested to create an outgoing SIPMessage string by the UserAgent 1 30, step 1 , the Message Constructor object 1 52 first reads the type of SIP request to be constructed from the SIP message object 1 1 4B, steps 2 and 3, and creates and edits the first line of the outgoing packet string object 1 1 OB, step 4, to contain the appropriate request type line. In steps 5 and 6, the first header objects 1 26C is read from the outgoing SIPMessage 1 14B and the appropriate line string is first created as a line string 1 54 and then appended to the outgoing packet string object 1 10 in steps 7 to 10. Steps 5 to 7 are repeated for all header objects in the vector list of the outgoing SIP message object 1 14B. Once the full string message 1 10B has been constructed, the Message Constructor object 1 52 passes the control message to the UserAgent, step 1 1 .

It should be mentioned that not only are the header object classes dynamically loaded in this embodiment, but the UAThread class 46 is adapted to dynamically load the appropriate handler classes in step 1 0 of Figure 6, thus allowing ready extensibility of the request types handled by the program in the same manner as extensibility of header types handled by the program.

In the above-described embodiment with reference to Figures 6, 7 and 8, the header object classes are dynamically loaded from local storage. In a further embodiment, one or more header object classes, or handler object classes, may be remotely dynamically loaded by the RMI ClassLoader function or the URLCLassLoader function. The program may identify the existence of an extension class for processing new request or header types by, for example a new header line received in an initial SIP message sent by a remote party, such as: New Header: address = 1 32.146.107.43... or,

Class Repository = http://www.jungle.bt.co.uk/SIPheaders/, as previously mentioned.

The header line may thus not only indicate the existence of the new class, but also identify the source from which the class may be obtained by dynamic loading.

It will be appreciated that further modifications and variations are also to be employed by the skilled person, without exceeding the scope of the present invention. The invention is not only applicable to SIP, but also to other telecommunications protocols such as HTTP.

Appendix A1 - Class. forNamef)

public static Class forName (String className) throws ClassNotFoundException

Returns the Class object associated with the class or interface with the given string name. Invoking this method is equivalent to:

Class. forName(className, true, currentLoader)

Where currentLoader denotes the defining class loader of the current class.

For example, the following ocde fragment returns the runtime Class descriptor for the class named Java. lang. Thread:

Class t = Class. forNameC'java. lang. Thread")

A call to forNameC'X") causes the class names X to be initialized.

Appendix A2 - Class. forNameO

class MessageParser

// "name" is the type of the header line. // "line" is the String which contains the contents of that header line.

Class object = void. class; Header h;

try{ object = Class. forName(name); //Load the class which is called "name" h = (Header)(object.newlnstanceO); //Create new object h.readString(line); // The new "header" object reads /the line sip.addHeader(h);

} catch(Exception e){ System. out. printlnC'Class was not found"); HPart to change

}

Appendix A3

class MessageParser {^{• • ■}

// "name" is the type of the header line.

// "line" is the String which contains the contents of that header line. // "location" is the URL from which the remote class is available.

Class object = void. class; Header h;

try{ object = Class. forName(name); //Load the class which is called "name" h = (Header)(object.newlnstance()); //Create new object h.readString(line); // The new Header object reads the line

sip.addHeader(h); // Add this Header object to the vector in SIPMessage }

catch(Exception e){ //If class was not found locally then...

URL urlList[] = { new URL(location)}; ClassLoader loader; loader = new URLCIassLoader(urlList); // Create a URLCIassLoader

object = loader. loadClass (name); // Load the class which is called "name"

h = (Header)object.newlnstance(); // Create an instance of the class

h.readString(line); // The new "header" object reads the line sip.addHeader(h); }

Appendix B1 Header Interface

public interface Header extends Java. lang. Cloneable {

Public String getTitleO; //Returns the title of the header it

//represents. Public void readString(String line); //Reads the contents as a String and

//formulates any internal parameters. Public String getStringO; //Returns the contents of the header in

//a String format. Public String getTypeO; //Returns one of the type of the header I

//it represents (as specified by the SIP

//RFC).

Appendix B2 Example of a Header class

Public class call id implements Header{ private String id,title; public call_id(){ //Public constructor id = new StringC'"); title = new String("Call-ID"); //Initialise the title of the //header

}

public void readString(String s){id = s.trim();} public String getString(){return id;} public void setlD(String s{id = s;}

//This is the only function added to the //class other than those defined by the //Header interface public String getTypeO {return "general-header";}

Appendix B3 Part of MessageParser class

public void makeSIPMessage(Vector v){ //When a SIP message arrived, each line

//was placed into a Vector as a separate //item. This vector is then passed to //this function.

for(int i-1 ;i < v.size();l + + ){ String line = (String)v.elementAt(i); //Get the String representation of

//each header line int index = line.indexOf(" :");

String name = (line. substring(0, index)). trim(); //Get the header's name name = name. replaceC-',' '); //Replace any '-' chars with '_' .

//This is necessary as a class //name may not contain a '-' //character. try{

Class classname = void. class; //call corresponding class classname = Class. forName(name); Header o; try{

0 = (Header)(classname.newlnstance());

} catch(Exception e){

System. out. printlnC'Can not find class"); Break;

} o.readString((line.substring(index + 1 )).trim()); //read the string. sip.addHeader(o); //add to the sip message object.

} catch(ClassNotFoundException e){System.out.println("Class was not fund");} catch(No ClassDefFoundError ee){System.out.println("Class was not found");}

Claims

1 . A software application program for processing control messages constructed in accordance with a telecommunications control protocol, said program having an object-oriented structure and being arranged to dynamically load an object class, whereby a control message is processed, at run time.

2. A program according to claim 1 , wherein said program is arranged to partition the contents of said control message and create a plurality of element objects from said control message, said objects being instances of classes dynamically loaded at run time.

3. A program according to claim 2, wherein said protocol defines a plurality of header types, said program being arranged to dynamically load a class or classes, representing each said header type, at run time.

4. A program according to claim 3, wherein said control message comprises a request line and a plurality of header lines, said plurality of header lines each containing a different respective header type.

5. A program according to claim 2, 3 or 4, wherein said program is arranged to create a message object containing said element objects as a vector array, and to pass said message object to a handler for processing in accordance with said protocol.

6. A program according to any preceding claim, wherein said protocol defines a plurality of control message types, said program being arranged to dynamically load a class or classes, for handling each said message type, at run time.

7. A program according to any preceding claim, wherein said program is arranged to dynamically load a class, whereby a control message, containing an element not specifically defined in said protocol, is processed.

8. A program according to any preceding claim, wherein said control message is an incoming message received from a remote party.

9. A program according to claim 8, wherein said dynamically loaded class or classes is/are loaded from said remote party.

1 0. A program according to any of claims 1 to 8, wherein said dynamically loaded class or classes is/are loaded from local storage.

1 1 . A program according to any preceding claim, wherein said protocol is an application layer control protocol.

1 2. A program according to any preceding claim, wherein said protocol is a text-based protocol.

1 3. A software application program for processing control messages constructed in accordance with a telecommunications control protocol, said protocol defining a control message to have a construction including one or more protocol elements of a predefined format and having a plurality of respective types, wherein said program is arranged to: process a control message by means of a different element type processing means for each of said plurality of respective types of at least one of said protocol elements; and on receipt of a control message from a remote party that indicates that an element type processing means for a type of said at least one of said protocol elements is not available locally, to retrieve said unavailable element type processing means remotely in order to process a control message received from, or to be sent to, said remote party.

14. A program according to claim 1 3, wherein said program has an object-oriented structure, and said processing means is/are one or more object classes, and said retrieval comprises dynamically loading a class, which is unavailable locally, during run time.

1 5. A program according to claim 1 3 or 14, wherein said locally- unavailable element type processing means is retrieved from a source identified in a control message sent by said remote party.

1 6. A program according to any of claims 1 3 to 1 5, wherein said protocol is a session control protocol, and said program is arranged to detect the location of said locally-unavailable element type processing means, within a storage system at said remote party, in a control message received from said remote party.

1 7. A program according to claim 1 6, wherein said location is detected in a control message containing an invitation to join a session.

1 8. Data processing apparatus programmed with the software application program according to any preceding claim.

1 9. A computer workstation according to claim 1 8.