US20070162613A1 - Processing network communication control messages - Google Patents

Processing network communication control messages Download PDF

Info

Publication number
US20070162613A1
US20070162613A1 US11/724,248 US72424807A US2007162613A1 US 20070162613 A1 US20070162613 A1 US 20070162613A1 US 72424807 A US72424807 A US 72424807A US 2007162613 A1 US2007162613 A1 US 2007162613A1
Authority
US
United States
Prior art keywords
sip
message
address
protocol
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/724,248
Inventor
Alan O'Neill
Philip Clarke
Paul Felton
Caroline Beauchamps
Shaun Baker
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
British Telecommunications PLC
Original Assignee
British Telecommunications PLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by British Telecommunications PLC filed Critical British Telecommunications PLC
Priority to US11/724,248 priority Critical patent/US20070162613A1/en
Publication of US20070162613A1 publication Critical patent/US20070162613A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/561Adding application-functional data or data for application control, e.g. adding metadata
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/563Data redirection of data network streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/169Special adaptations of TCP, UDP or IP for interworking of IP based networks with other networks 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08Protocols for interworking; Protocol conversion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/327Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the session layer [OSI layer 5]

Definitions

  • This invention relates to processing control messages for use in communications network, and in particular to a method, data processing system and software application program for processing control messages constructed in accordance with a communications control protocol.
  • the invention is particularly, but not exclusively, directed to text-based application-layer communication control protocols.
  • the Session Initiation Protocol 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.
  • IETF Internet Engineering Task Force
  • a SIP user agent is an end-system that allows a user to participate in a session.
  • a SIP user agent contains both a user agent client and a user agent server.
  • a user agent client is used to initiate a session and a user agent server is used to respond to request from a user agent client.
  • a user is addressed using an email-like address identifier “user@host”, where “user” is a user name or phone number and “host” is a domain name or numerical Internet Protocol (IP) address.
  • IP Internet Protocol
  • SIP messages indicate success or failure, distinguished by status codes, 1xx ( 100 to 199 ) 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.
  • call ID call identifier
  • 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, for example using the Domain Name System (DNS) rather than knowing the IP address or name of the host.
  • DNS Domain Name System
  • a 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.
  • SIP Internet Protocol
  • IP Internet Protocol
  • SIP is typically implemented by transmitting Internet Protocol (IP) packets.
  • IP Internet Protocol
  • 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 message 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.
  • 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 message body may be of any content, although it usually has contents formatted in accordance with the Session Description Protocol (SDP).
  • SDP Session Description Protocol
  • SIP URL address identifiers such as sip:Richard@bt.com are required for the exchange of SIP messages in a similar way that e-mail URL address identifiers are required for the exchange of electronic mail.
  • a method for processing control messages constructed in accordance with a first communications protocol for use in a communications network, each control message including a first address identifier having a format defined by said first protocol; said method comprising the steps of:
  • a control message constructed in accordance with a first network protocol can be readily converted for transmission over a second network protocol to a network system having an network address identifier constructed in accordance with the second protocol.
  • the integration of new communications services implemented over a new protocol can be improved with the above method.
  • a control messages constructed in accordance with a newly implemented communications protocol can be readily converted for transmission to a network address associated with a communications service provided over a widely implemented protocol where the address corresponds to an intended destination address associated with a new communications service provided over the newly implemented protocol.
  • the address identifier can be resolved back to an address identifier associated with a widely implemented protocol and the message sent to the location associated with that resolved address by means of a service available over the widely implemented communications protocol. This may be necessary, for instance, if the network system associated with the original address identifier is not capable of receiving control messages constructed in accordance with the newly implemented protocol.
  • a further advantage of the above method is that users can readily address messages etc, for transmission over one communications protocol using an address identifier associated with another communication protocol. The ability to make use of the address space associated with a widely implemented communications protocol is very important when say new services are to be introduced using a new protocol.
  • a user may address a message to another user using a new address identifier derived from a known identifier regardless of whether the user is aware of the recipient's address identifier for the newly introduced protocol or whether the recipient has indeed been allocated a new address identifier or is capable of receiving the message over the new protocol.
  • all or part of the control message may be re-formatted for transmission over the second protocol.
  • the address identifier only may be re-formatted and the remainder of the message discarded.
  • a control message is processed in accordance with steps i) and ii) in response to a detected delivery failure of said control message to a network system associated with said first address identifier.
  • a control message fails to be delivered using a communication service provided over one protocol, say a newly implemented protocol, the message can be processed according to the above method for delivery over another communications protocol, for example a widely implemented protocol.
  • control message is processed in response to said first address identifier being identified as an invalid address identifier.
  • said control message having invalid destination address identifier can be processed for transmission by means of a service implemented over another protocol to a valid network address recognised by that protocol.
  • control message is processed in response to said network system associated with said first address identifier failing to respond to said message. This allows control messages to be processed for delivery by another communications service when the intended destination network system is unavailable or unwilling to receive control messages delivered in accordance with one network protocol but available or willing to accept messages delivered in accordance with another network protocol.
  • said method further comprises the step of selecting a pre-determined error message for transmission to said network device associated with said second address in accordance with a respective failure mode associated with said detected control message delivery failure. In this way a destination end user or end system can be informed of a detected delivery failure.
  • said method further comprises the step of linking said control message to said pre-determined message for transmission to said network device associated with said second address identifier.
  • data contained in the control message can be made available to the intended recipient in such a way that pre-determined message templates can be used for message construction.
  • said pre-determined message comprises executable code, or an network address identifier for accessing executable code, wherein said code is capable of processing said control message in accordance with said first protocol.
  • said pre-determined message comprises a pre-defined data structure for registering said first address identifier with an address database associated with said first protocol.
  • end systems or users can readily register an address identifier for receiving communications services provided over a newly implemented protocol.
  • said first address identifier comprises at least one address component and said step of processing said message comprises constructing said second address identifier to include at least one component of said first address.
  • address components can be common to both first and second address identifiers.
  • said second address identifier is contained in said first address identifier and said method comprises the step of parsing said control message to identify said first address identifier and determine said second address identifier from said first address identifier. This enables the second address identifier to be readily derivable from the first address identifier.
  • said first protocol is an application layer control protocol. This provides for the implementation of user applications and new communications services.
  • said application layer control protocol conforms to Session Initiation Protocol
  • said second protocol is an application layer protocol
  • said second protocol conforms to an Internet mail transfer protocol.
  • SIP messages can be addressed to an existing address identifier, for example and e-mail address identifier constructed in accordance with Simple Mail Transfer Protocol (SMTP), and translated to a corresponding SIP address identifier for transmission to a SIP user agent server regardless of whether the SIP address identifier is known to the user.
  • SMTP Simple Mail Transfer Protocol
  • the present invention enables messages to be readily diverted from a SIP defined destination URL address identifier to a corresponding SMTP defined destination URL address identifier for the same user or end system.
  • users may send SIP messages to SMTP address identifiers using the SMTP network protocol and infrastructure and SMTP messages to SIP address identifiers using the SIP network protocol and infrastructure.
  • a system for processing control messages constructed in accordance with a first communications protocol for use in a communications network, each control message including a first address identifier having a format defined by said first protocol; said system comprising:
  • FIG. 1 a is a schematic representation of a typical SIP message signalling sequence in a network comprising a SIP re-direct server;
  • FIG. 1 b is a schematic representation of a typical SIP message signalling sequence in a network comprising a SIP proxy server;
  • FIG. 2 is a block diagram of a SIP user agent
  • FIG. 3 is a block diagram of a SIP user agent graphical user interface
  • FIG. 4 is a schematic representation of a communications network comprising a plurality of SIP enabled network domains.
  • FIG. 5 is a flow diagram of a method implemented in the communications network of FIG. 4 .
  • FIGS. 1 a and 1 b typical signalling sequences are shown in FIGS. 1 a and 1 b between two user agents 100 and 102 connected over a communications network using a SIP redirect server 106 ( FIG. 1 a ), and a SIP proxy server 108 ( FIG. 1 b ).
  • a SIP location server 110 is connected to the respective SIP network server for address resolution.
  • user agent 100 sends a SIP Invite message 112 to user agent 102 .
  • the Invite message is received at and processed by the re-direct server 106 to determine the network location of user agent 102 .
  • the re-direct server sends a location query 114 to the location server 110 .
  • the location server determines the current network location of user agent 102 and sends this information to the re-direct server in a message 116 for transmission to the user agent 100 in a message 118 .
  • User agent 100 then sends an Invite message 120 to user agent 102 , either directly or via other SIP re-direct or proxy servers, which then responds by sending an acceptance message 122 to the user agent 100 .
  • User agent 100 completes the session or call set up procedure by sending an acknowledgement 124 . Once the session has been set up information can be exchanged between the respective user agents.
  • user agent. 100 sends a SIP Invite message 126 to user agent 102 as before but instead of being processed by a re-direct server the message is processed by the network proxy server 108 .
  • the proxy server sends a location query 128 to the location server 110 .
  • the location server determines the current network location of the user agent 102 and sends this information back to the proxy server in a message 130 .
  • the proxy server then relays the Invite message to the user agent 102 by means of a message 132 which is processed by the user agent 102 .
  • a call acceptance message 134 is then sent back to the proxy server which relays a corresponding message 136 to the user agent 100 .
  • the user agent 100 then sends an acknowledgement message 138 to the proxy server which similarly relays a corresponding message 140 to the user agent 102 .
  • a typical SIP user agent 200 comprises a front end system in the form of a graphical user interface (GUI) 202 , a SIP client program 204 , a SIP server program 206 , a media module 208 , a network interface 210 a SIP address cache 212 , a SIP URL address generator 214 and a SIP message processor 216 .
  • GUI graphical user interface
  • buttons 302 to 310 each of which represents a different SIP request method.
  • Button 302 represents the SIP “INVITE” request for inviting a callee to a SIP session
  • button 304 represents the “OPTIONS” request for discovering the capabilities of the receiving terminal
  • button 306 represents the “BYE” request for terminating a call or a call request
  • button 308 represents the “CANCEL” request for terminating incomplete call requests
  • button 310 represents the “REGISTER” request method for registering the current location of the user with a respective domain location database 110 .
  • the respective request methods are invoked by a user clicking the respective button, by mouse controlled cursor click or otherwise.
  • the GUI further comprises a text box 314 labelled “To: SIP URL” for user input, by keyboard entry or address book entry selection for example, of the SIP address identifier of an intended callee, that is to say the SIP destination message header field “To”; a text box 316 labelled “To: e-mail URL” for user input of the e-mail address identifier of the intended callee; and, a text box 318 labelled “Title” for displaying title information to identify the session.
  • a further text box 320 is provided for the input of other SIP message text including for example other SIP header types and text comprising the SIP message body. Text may be input into any one of the text boxes 314 , 316 , 318 , 320 using known text processing means, for example, keyboard entry, selection from pull down menus or cut and paste text processing applications.
  • the SIP message constructor is configured to process data entered into any one of the boxes 314 , 316 , 320 , 320 and construct a SIP message including the relevant request type for transmission to an appropriate SIP network server. For example, the message constructor copies the text entered in the text box 314 to the SIP message header type “To:” in the SIP message being constructed. Other header types are determined by the message constructor such as “Content-type:” and “Content length:” for example.
  • the user agent client program is configured to initiate a SIP session or “call” and the user agent server program is configured to respond to a call.
  • the user agent client program implements the SIP request methods Invite, Options, Bye, Cancel and Register, and the user agent server implements the methods Invite, Bye, Cancel and Ack methods.
  • Messages are passed from the user agent client to the network interface 210 for transmission to the intended callee associated with the destination SIP URL address.
  • SIP messages are received at the destination end by the network interface and are processing by the user agent server.
  • the media module 208 provides the necessary API's for sending system calls to appropriate media applications for processing different media types once a SIP session has been established.
  • the user When a user wishes to initiate a SIP session, the user interacts with the GUI 202 to construct a SIP Invite message including a destination SIP or e-mail address. Once all the necessary data has been input to the GUI, including the SIP header types and message body, the message processor constructs an appropriate SIP message for transmission to the callee. In the event that the callee's SIP URL address is unknown to the user, the user inputs the callee's SMTP e-mail address in the text box 316 . The e-mail address is then sent to the SIP URL generator 214 .
  • the SIP URL generator 214 comprises a software program for generating a SIP URL address identifier from a respective SMTP e-mail address identifier for a respective user.
  • the SIP URL generator is configured to process the e-mail address identifier, in accordance with a set of pre-determined rules, to generate a corresponding SIP URL address identifier for the callee.
  • the e-mail address is processed by the SIP URL generator which adds a prefix address component to the existing e-mail address components “user@host” etc.
  • the prefix address component identifies the communications protocol that the new URL is to be used with. In this embodiment “sip” is added as a prefix.
  • a suffix address component is also added to identify a SIP domain name authority the newly generated SIP URL address identifier is to be identified with.
  • the SIP URL generator is configured to process the SMTP e-mail address “alan.oneill@bt.com” to derive the SIP URL address identifier “sip:alan.oneill@bt.com.sipit.com”, that is to say, to add the protocol prefix “sip” and the domain suffix “sipit.com” to the existing SMTP readable e-mail address “alan.oneill@bt.com”.
  • the SIP URL generator is configured to generate SIP URL address identifiers by processing a respective address identifier constructed in accordance with the Internet e-mail communications protocol SMTP.
  • the SIP URL generator is configured to process the same SMTP e-mail address identifier to derive the SIP URL address identifier “sip:alan.oneill@bt.com.uk.sipit.com”, that is to say a geographical identifier “uk” is additionally added to the SMTP e-mail address identifier.
  • the additional geographic identifier may assist scalability of the name space and hence network routing efficiency of the resulting SIP message, for example.
  • a plurality of network domains 400 , 402 and 404 are each connected to the Internet 406 by means of a respective SIP network server 408 , 410 and 412 .
  • the SIP network servers are configured for use both as SIP proxy and SIP re-direct servers.
  • the SIP network servers provide access to and from the respective domains.
  • Each network domain comprises a plurality of SIP user agents 200 ( a - g ).
  • SIP user agents 200 a , 200 b and 200 c are connected to the network server 408 in the domain 400
  • SIP user agents 200 d , and 200 e are connected to the network server 410 in the domain 402
  • SIP user agents 200 f and 200 g are connected to the network server 412 in the domain 404 .
  • Each SIP network server is connected to a respective location server 110 for SIP address resolution and an associated SIP to SMTP e-mail gateway 414 .
  • Each SMTP e-mail gateway is connected to a respective SMTP Mail Transfer Agent (MTA) 416 for relaying SMTP e-mail messages to respective destination SMTP MTA's over transport layer TCP connections.
  • MTA SMTP Mail Transfer Agent
  • Each SIP to SMTP e-mail gateway 414 comprises an SMTP e-mail address generator 418 and a message processor 420 which comprises an SMTP user agent.
  • the e-mail address generator comprises software for generating an SMTP address identifier from a SIP URL address identifier.
  • the e-mail address generator is configured in a similar but reverse manner to the address generator 214 .
  • the e-mail address generator is configured to process the SIP URL destination address identifier of an out going SIP message to derive a corresponding SMTP e-mail address identifier.
  • the e-mail address generator processes the SIP URL address in accordance with the same pre-determined set of rules as the SIP address generator 214 , but processes these rules in reverse order with respect to the address generator 214 . For instance, in one embodiment a SIP message arriving at the SIP to SMTP e-mail gateway 414 is parsed to determine the destination SIP URL. The SIP URL is then passed to the SIP to e-mail address generator 418 . The remaining part of the SIP message is re-formatted by the message processor 420 into SMTP format suitable for transmission as an SMTP e-mail message.
  • the address generator 418 is programmed in accordance with the above set of rules, that is to say to remove the protocol identifier prefix “sip” from the SIP URL address and to remove the sip domain suffix component “sipit.com”.
  • the address generator sends the re-formatted SMTP address identifier to the message processor where the newly derived SMTP address is added to the re-formatted message as the destination SMTP address for that message.
  • the message processor adds the newly generated SMTP address to the SMTP “To:” header field of a respective SMTP message.
  • the address generator 418 is programmed to derive the SMTP e-mail address identifier alan.oneill@bt.com from SIP URL “sip:alan.oneill@bt.com .sipit.com”.
  • the message processor 420 constructs an appropriate SMTP message for transmission to the newly generated SMTP address according to the content of the respective SIP control message.
  • the SIP message payload for example the SDP message component of the SIP message, is added as text to the respective SMTP message body for transmission to the respective destination SMTP address.
  • the SDP text shown in box 320 is processed and added as text to the SMPT message payload by the message processor 420 .
  • a user initiates a SIP session in step 500 by interaction with the GUI 202 of a SIP user agent 200 .
  • a data entry for each of the required data types is input by the user including a destination SIP address in box 314 or, in the absence of a known SIP URL for the intended recipient, an SMTP e-mail address that is known to be allocated to the recipient in box 316 .
  • Data relating to the SIP message is processed into SIP format by the SIP message processor 216 and is then submitted to the user agent client 204 by the user selecting the Invite button 302 by mouse click or other data input command.
  • the user agent client determines in step 502 whether a SIP URL address has been provided or an SMTP e-mail address.
  • step 508 If a SIP URL has been provided processing proceeds to step 508 . However, if an SMTP e-mail address identifier has been provided the user agent client sends the e-mail address to the address generator 214 for processing to a respective SIP URL address identifier in step 504 . A respective SIP URL is generated in accordance with the above described method. In step 506 the newly derived SIP URL address is added to the SIP destination header type “To:” following the INVITE request type of the SIP message.
  • the SIP message is transmitted to the appropriate local SIP network server 408 , 410 or 412 in step 508 to be relayed or re-directed to a network server associated with the destination SIP URL address.
  • the network server that receives the SIP message queries its associated location database 110 in step 510 , using DNS or other address resolution means, to determine the network server the SIP message should be transmitted to.
  • a network server having authority for the domain for the destination SIP URL determines whether the destination SIP URL address is a valid network address, that is to say, whether the SIP URL address has been allocated by the domain authority to a SIP user.
  • the SIP URL destination address is a valid network address if it can be resolved by a location database using DNS or other resolution means to a respective numerical IP address, for example. In this respect address resolution may involve querying other location databases associated with other network SIP servers or SIP domains in a similar way that DNS resolves numerical IP addresses.
  • the location server if the destination SIP URL address is valid, that is to say it has been allocated to a respective user and can be resolved, the location server returns the IP address of the next SIP server that is configured to relay or re-direct the message or if appropriate the IP address of the end system currently associated with the destination SIP URL.
  • the SIP message is sent to the next SIP network server or destination end system in step 516 .
  • an appropriate SIP network server transmits the SIP message to an associated SIP to SMTP e-mail gateway in step 516 .
  • the destination SIP URL may be invalid for instance because it was automatically generated from a known e-mail address identifier in step 504 and no corresponding SIP address exists.
  • the message processor 420 re-formats the SIP message to an SMTP message for communication over the Internet 406 in accordance with SMTP in step 518 .
  • step 520 the destination.
  • SIP URL address is processed by the address generator 418 in step 520 to derive the SMTP e-mail address encapsulated within the SIP URL address. Additional information and data is added to the re-formatted SMTP e-mail message in step 522 including, for example the text:
  • the SMTP message is sent to an associated mail transfer agent 416 in step 524 for transmission to the e-mail address derived in step 520 using the SMTP network protocol.
  • the sender is informed by the SIP server that the destination SIP URL was not valid and that the message was instead re-formatted according to SMTP and sent to the SMTP e-mail address derived in step 520 .
  • a SIP message could be readily diverted to a SIP to e-mail gateway if the user or the end system associated with the user was unavailable or unwilling to receive SIP messages at the time of message transmission.
  • the respective SIP server selects an appropriate message from an associated message library (not shown) for inclusion with the original SIP message in step 522 .
  • the message library includes a respective delivery failure message for each SIP message delivery failure mode, including for example, destination SIP user agent unavailable, user unavailable, network connection failure, user unwilling to join SIP session or user unwilling to join designated sessions, user will be available at ⁇ time, date>, etc.
  • SIP to e-mail gateway 414 could be readily implemented in other network devices such as a respective network SIP server or a SIP user agent.

Abstract

Control messages constructed in accordance with a first communications protocol for use in a communications network each include a first address identifier having a format defined by the first protocol. The control message is processed to derive a second address identifier having a format defined by a second communications protocol. The control message is re-formatted for transmission, in accordance with the second protocol, to a network system associated with the second address identifier.

Description

    CROSS REFERENCE TO RELA TED APPLICA TIONS
  • This application is a divisional application of U.S. patent application Ser. No. 10/220,498 filed Aug. 30, 2002 which was the national phase of PCT/GB 01/01343 filed Mar. 26, 2001 and which claimed priority from EP application 00302424.7 filed Mar. 24, 2000, the disclosure of which priority applications is incorporated herein by reference.
  • BACKGROUND
  • 1. Technical Field
  • This invention relates to processing control messages for use in communications network, and in particular to a method, data processing system and software application program for processing control messages constructed in accordance with a communications control protocol. The invention is particularly, but not exclusively, directed to text-based application-layer communication control protocols.
  • 2. Related Art
  • 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 servers and location servers. A SIP user agent is an end-system that allows a user to participate in a session. A SIP user agent contains both a user agent client and a user agent server. A user agent client is used to initiate a session and a user agent server is used to respond to request from a user agent client. A user is addressed using an email-like address identifier “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, 1xx (100 to 199) 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, for example using the Domain Name System (DNS) rather than knowing the IP address or name of the host. A 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.
  • 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 message 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).
  • SIP URL address identifiers such as sip:Richard@bt.com are required for the exchange of SIP messages in a similar way that e-mail URL address identifiers are required for the exchange of electronic mail.
  • By using an e-mail type address it is possible to deliver a SIP message to a SIP server that knows the location of the user or user agent server the message is intended for. The IP address of the SIP server having authority for the callee's address can be readily determined by DNS. However, this approach requires users of both SIP and e-mail services to be allocated different and potentially confusing SIP and e-mail addresses. This exacerbates the problem of address memory, address book maintenance and in particular, address resolution using database queries. A further problem associated with SIP is that as a newly implemented protocol there is no delivery guarantee, that is to say delivery of a SIP message addressed using a SIP URL may fail, for instance because the intended recipient is not enabled to receive SIP messages.
  • BRIEF SUMMARY
  • According to an aspect of the present invention there is provided a method for processing control messages constructed in accordance with a first communications protocol for use in a communications network, each control message including a first address identifier having a format defined by said first protocol; said method comprising the steps of:
      • i) processing said control message to derive a second address identifier from said first identifier, said second identifier having a format defined by a second communications protocol; and,
      • ii) re-formatting said control message for transmission, in accordance with said second protocol, to a network system associated with said second address identifier.
  • In this way, a control message constructed in accordance with a first network protocol can be readily converted for transmission over a second network protocol to a network system having an network address identifier constructed in accordance with the second protocol. The integration of new communications services implemented over a new protocol can be improved with the above method. For instance, a control messages constructed in accordance with a newly implemented communications protocol can be readily converted for transmission to a network address associated with a communications service provided over a widely implemented protocol where the address corresponds to an intended destination address associated with a new communications service provided over the newly implemented protocol. For instance, if a message is sent but not delivered to a user or location identified by an address identifier associated with a newly implemented protocol, the address identifier can be resolved back to an address identifier associated with a widely implemented protocol and the message sent to the location associated with that resolved address by means of a service available over the widely implemented communications protocol. This may be necessary, for instance, if the network system associated with the original address identifier is not capable of receiving control messages constructed in accordance with the newly implemented protocol. A further advantage of the above method is that users can readily address messages etc, for transmission over one communications protocol using an address identifier associated with another communication protocol. The ability to make use of the address space associated with a widely implemented communications protocol is very important when say new services are to be introduced using a new protocol. For example, a user may address a message to another user using a new address identifier derived from a known identifier regardless of whether the user is aware of the recipient's address identifier for the newly introduced protocol or whether the recipient has indeed been allocated a new address identifier or is capable of receiving the message over the new protocol. In the context of the present invention it is to be understood that all or part of the control message may be re-formatted for transmission over the second protocol. For instance, the address identifier only may be re-formatted and the remainder of the message discarded.
  • Preferably, a control message is processed in accordance with steps i) and ii) in response to a detected delivery failure of said control message to a network system associated with said first address identifier. In this way if a control message fails to be delivered using a communication service provided over one protocol, say a newly implemented protocol, the message can be processed according to the above method for delivery over another communications protocol, for example a widely implemented protocol.
  • Conveniently, said control message is processed in response to said first address identifier being identified as an invalid address identifier. In this way a control message having invalid destination address identifier can be processed for transmission by means of a service implemented over another protocol to a valid network address recognised by that protocol.
  • In preferred embodiments, said control message is processed in response to said network system associated with said first address identifier failing to respond to said message. This allows control messages to be processed for delivery by another communications service when the intended destination network system is unavailable or unwilling to receive control messages delivered in accordance with one network protocol but available or willing to accept messages delivered in accordance with another network protocol.
  • Preferably, said method further comprises the step of selecting a pre-determined error message for transmission to said network device associated with said second address in accordance with a respective failure mode associated with said detected control message delivery failure. In this way a destination end user or end system can be informed of a detected delivery failure.
  • Conveniently, said method further comprises the step of linking said control message to said pre-determined message for transmission to said network device associated with said second address identifier. In this way data contained in the control message can be made available to the intended recipient in such a way that pre-determined message templates can be used for message construction.
  • In preferred embodiments, said pre-determined message comprises executable code, or an network address identifier for accessing executable code, wherein said code is capable of processing said control message in accordance with said first protocol. In this way end systems or users can readily access software programs for receiving communications services provided over a newly implemented protocol.
  • Preferably, said pre-determined message comprises a pre-defined data structure for registering said first address identifier with an address database associated with said first protocol. In this way end systems or users can readily register an address identifier for receiving communications services provided over a newly implemented protocol.
  • Conveniently, said first address identifier comprises at least one address component and said step of processing said message comprises constructing said second address identifier to include at least one component of said first address. In this way address components can be common to both first and second address identifiers.
  • In preferred embodiments, said second address identifier is contained in said first address identifier and said method comprises the step of parsing said control message to identify said first address identifier and determine said second address identifier from said first address identifier. This enables the second address identifier to be readily derivable from the first address identifier.
  • Preferably, said first protocol is an application layer control protocol. This provides for the implementation of user applications and new communications services.
  • Conveniently, said application layer control protocol conforms to Session Initiation Protocol In preferred embodiments, said second protocol is an application layer protocol.
  • Preferably, said second protocol conforms to an Internet mail transfer protocol.
  • Thus, SIP messages can be addressed to an existing address identifier, for example and e-mail address identifier constructed in accordance with Simple Mail Transfer Protocol (SMTP), and translated to a corresponding SIP address identifier for transmission to a SIP user agent server regardless of whether the SIP address identifier is known to the user. Thus, the present invention enables messages to be readily diverted from a SIP defined destination URL address identifier to a corresponding SMTP defined destination URL address identifier for the same user or end system. In this way users may send SIP messages to SMTP address identifiers using the SMTP network protocol and infrastructure and SMTP messages to SIP address identifiers using the SIP network protocol and infrastructure.
  • According to another aspect of the invention there is provided a software program for implementing said method.
  • According to a further aspect of the invention there is provided a system for processing control messages constructed in accordance with a first communications protocol for use in a communications network, each control message including a first address identifier having a format defined by said first protocol; said system comprising:
      • a processor for processing said control message to derive a second address identifier from said first identifier, said second identifier having a format defined by a second communications protocol; and,
      • a message constructor for re-formatting said control message for transmission, in accordance with said second protocol, to a network device associated with said second address identifier.
    BRIEF DESCRIPTION OF THE DRAWINGS
  • The invention will now be described with reference to the accompanying drawings in which:
  • FIG. 1 a is a schematic representation of a typical SIP message signalling sequence in a network comprising a SIP re-direct server;
  • FIG. 1 b is a schematic representation of a typical SIP message signalling sequence in a network comprising a SIP proxy server;
  • FIG. 2 is a block diagram of a SIP user agent;
  • FIG. 3 is a block diagram of a SIP user agent graphical user interface;
  • FIG. 4 is a schematic representation of a communications network comprising a plurality of SIP enabled network domains; and,
  • FIG. 5 is a flow diagram of a method implemented in the communications network of FIG. 4.
  • DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS
  • With reference to the drawings, typical signalling sequences are shown in FIGS. 1 a and 1 b between two user agents 100 and 102 connected over a communications network using a SIP redirect server 106 (FIG. 1 a), and a SIP proxy server 108 (FIG. 1 b). In both arrangements a SIP location server 110 is connected to the respective SIP network server for address resolution.
  • In FIG. 1 a, user agent 100 sends a SIP Invite message 112 to user agent 102. The Invite message is received at and processed by the re-direct server 106 to determine the network location of user agent 102. The re-direct server sends a location query 114 to the location server 110. The location server determines the current network location of user agent 102 and sends this information to the re-direct server in a message 116 for transmission to the user agent 100 in a message 118. User agent 100 then sends an Invite message 120 to user agent 102, either directly or via other SIP re-direct or proxy servers, which then responds by sending an acceptance message 122 to the user agent 100. User agent 100 completes the session or call set up procedure by sending an acknowledgement 124. Once the session has been set up information can be exchanged between the respective user agents.
  • In FIG. 1 b, user agent. 100 sends a SIP Invite message 126 to user agent 102 as before but instead of being processed by a re-direct server the message is processed by the network proxy server 108. The proxy server sends a location query 128 to the location server 110. The location server determines the current network location of the user agent 102 and sends this information back to the proxy server in a message 130. The proxy server then relays the Invite message to the user agent 102 by means of a message 132 which is processed by the user agent 102. A call acceptance message 134 is then sent back to the proxy server which relays a corresponding message 136 to the user agent 100. The user agent 100 then sends an acknowledgement message 138 to the proxy server which similarly relays a corresponding message 140 to the user agent 102.
  • With reference now to FIG. 2, a typical SIP user agent 200 comprises a front end system in the form of a graphical user interface (GUI) 202, a SIP client program 204, a SIP server program 206, a media module 208, a network interface 210 a SIP address cache 212, a SIP URL address generator 214 and a SIP message processor 216.
  • A typical SIP GUI is shown in FIG. 3. The GUI 202 comprises a plurality of buttons 302 to 310 each of which represents a different SIP request method. Button 302 represents the SIP “INVITE” request for inviting a callee to a SIP session, button 304 represents the “OPTIONS” request for discovering the capabilities of the receiving terminal, button 306 represents the “BYE” request for terminating a call or a call request, button 308 represents the “CANCEL” request for terminating incomplete call requests and button 310 represents the “REGISTER” request method for registering the current location of the user with a respective domain location database 110. The respective request methods are invoked by a user clicking the respective button, by mouse controlled cursor click or otherwise. The GUI further comprises a text box 314 labelled “To: SIP URL” for user input, by keyboard entry or address book entry selection for example, of the SIP address identifier of an intended callee, that is to say the SIP destination message header field “To”; a text box 316 labelled “To: e-mail URL” for user input of the e-mail address identifier of the intended callee; and, a text box 318 labelled “Title” for displaying title information to identify the session. A further text box 320 is provided for the input of other SIP message text including for example other SIP header types and text comprising the SIP message body. Text may be input into any one of the text boxes 314, 316, 318, 320 using known text processing means, for example, keyboard entry, selection from pull down menus or cut and paste text processing applications.
  • The SIP message constructor is configured to process data entered into any one of the boxes 314, 316, 320, 320 and construct a SIP message including the relevant request type for transmission to an appropriate SIP network server. For example, the message constructor copies the text entered in the text box 314 to the SIP message header type “To:” in the SIP message being constructed. Other header types are determined by the message constructor such as “Content-type:” and “Content length:” for example.
  • The user agent client program is configured to initiate a SIP session or “call” and the user agent server program is configured to respond to a call. In this regard the user agent client program implements the SIP request methods Invite, Options, Bye, Cancel and Register, and the user agent server implements the methods Invite, Bye, Cancel and Ack methods. Messages are passed from the user agent client to the network interface 210 for transmission to the intended callee associated with the destination SIP URL address. SIP messages are received at the destination end by the network interface and are processing by the user agent server. The media module 208 provides the necessary API's for sending system calls to appropriate media applications for processing different media types once a SIP session has been established.
  • When a user wishes to initiate a SIP session, the user interacts with the GUI 202 to construct a SIP Invite message including a destination SIP or e-mail address. Once all the necessary data has been input to the GUI, including the SIP header types and message body, the message processor constructs an appropriate SIP message for transmission to the callee. In the event that the callee's SIP URL address is unknown to the user, the user inputs the callee's SMTP e-mail address in the text box 316. The e-mail address is then sent to the SIP URL generator 214.
  • The SIP URL generator 214 comprises a software program for generating a SIP URL address identifier from a respective SMTP e-mail address identifier for a respective user.
  • The SIP URL generator is configured to process the e-mail address identifier, in accordance with a set of pre-determined rules, to generate a corresponding SIP URL address identifier for the callee. In one arrangement, the e-mail address is processed by the SIP URL generator which adds a prefix address component to the existing e-mail address components “user@host” etc. The prefix address component identifies the communications protocol that the new URL is to be used with. In this embodiment “sip” is added as a prefix. A suffix address component is also added to identify a SIP domain name authority the newly generated SIP URL address identifier is to be identified with. In one example the SIP URL generator is configured to process the SMTP e-mail address “alan.oneill@bt.com” to derive the SIP URL address identifier “sip:alan.oneill@bt.com.sipit.com”, that is to say, to add the protocol prefix “sip” and the domain suffix “sipit.com” to the existing SMTP readable e-mail address “alan.oneill@bt.com”. Thus, the SIP URL generator is configured to generate SIP URL address identifiers by processing a respective address identifier constructed in accordance with the Internet e-mail communications protocol SMTP. In another example the SIP URL generator is configured to process the same SMTP e-mail address identifier to derive the SIP URL address identifier “sip:alan.oneill@bt.com.uk.sipit.com”, that is to say a geographical identifier “uk” is additionally added to the SMTP e-mail address identifier. The additional geographic identifier may assist scalability of the name space and hence network routing efficiency of the resulting SIP message, for example.
  • Referring now to FIG. 4, a plurality of network domains 400, 402 and 404 are each connected to the Internet 406 by means of a respective SIP network server 408, 410 and 412. In the network of FIG. 4 the SIP network servers are configured for use both as SIP proxy and SIP re-direct servers. The SIP network servers provide access to and from the respective domains. Each network domain comprises a plurality of SIP user agents 200(a-g). SIP user agents 200 a, 200 b and 200 c are connected to the network server 408 in the domain 400, SIP user agents 200 d, and 200 e are connected to the network server 410 in the domain 402, and SIP user agents 200 f and 200 g are connected to the network server 412 in the domain 404. Each SIP network server is connected to a respective location server 110 for SIP address resolution and an associated SIP to SMTP e-mail gateway 414. Each SMTP e-mail gateway is connected to a respective SMTP Mail Transfer Agent (MTA) 416 for relaying SMTP e-mail messages to respective destination SMTP MTA's over transport layer TCP connections.
  • Each SIP to SMTP e-mail gateway 414 comprises an SMTP e-mail address generator 418 and a message processor 420 which comprises an SMTP user agent. The e-mail address generator comprises software for generating an SMTP address identifier from a SIP URL address identifier. In this regard the e-mail address generator is configured in a similar but reverse manner to the address generator 214. The e-mail address generator is configured to process the SIP URL destination address identifier of an out going SIP message to derive a corresponding SMTP e-mail address identifier. The e-mail address generator processes the SIP URL address in accordance with the same pre-determined set of rules as the SIP address generator 214, but processes these rules in reverse order with respect to the address generator 214. For instance, in one embodiment a SIP message arriving at the SIP to SMTP e-mail gateway 414 is parsed to determine the destination SIP URL. The SIP URL is then passed to the SIP to e-mail address generator 418. The remaining part of the SIP message is re-formatted by the message processor 420 into SMTP format suitable for transmission as an SMTP e-mail message.
  • In one embodiment the address generator 418 is programmed in accordance with the above set of rules, that is to say to remove the protocol identifier prefix “sip” from the SIP URL address and to remove the sip domain suffix component “sipit.com”. The address generator sends the re-formatted SMTP address identifier to the message processor where the newly derived SMTP address is added to the re-formatted message as the destination SMTP address for that message. The message processor adds the newly generated SMTP address to the SMTP “To:” header field of a respective SMTP message. For example, the address generator 418 is programmed to derive the SMTP e-mail address identifier alan.oneill@bt.com from SIP URL “sip:alan.oneill@bt.com .sipit.com”.
  • The message processor 420 constructs an appropriate SMTP message for transmission to the newly generated SMTP address according to the content of the respective SIP control message. For example, the SIP message payload, for example the SDP message component of the SIP message, is added as text to the respective SMTP message body for transmission to the respective destination SMTP address. In the example described with reference to FIG. 3, the SDP text shown in box 320 is processed and added as text to the SMPT message payload by the message processor 420.
  • With reference now to the flow diagram of FIG. 5, a user initiates a SIP session in step 500 by interaction with the GUI 202 of a SIP user agent 200. A data entry for each of the required data types is input by the user including a destination SIP address in box 314 or, in the absence of a known SIP URL for the intended recipient, an SMTP e-mail address that is known to be allocated to the recipient in box 316. Data relating to the SIP message is processed into SIP format by the SIP message processor 216 and is then submitted to the user agent client 204 by the user selecting the Invite button 302 by mouse click or other data input command. The user agent client determines in step 502 whether a SIP URL address has been provided or an SMTP e-mail address. If a SIP URL has been provided processing proceeds to step 508. However, if an SMTP e-mail address identifier has been provided the user agent client sends the e-mail address to the address generator 214 for processing to a respective SIP URL address identifier in step 504. A respective SIP URL is generated in accordance with the above described method. In step 506 the newly derived SIP URL address is added to the SIP destination header type “To:” following the INVITE request type of the SIP message.
  • The SIP message is transmitted to the appropriate local SIP network server 408,410 or 412 in step 508 to be relayed or re-directed to a network server associated with the destination SIP URL address. The network server that receives the SIP message queries its associated location database 110 in step 510, using DNS or other address resolution means, to determine the network server the SIP message should be transmitted to. In step 512 a network server having authority for the domain for the destination SIP URL determines whether the destination SIP URL address is a valid network address, that is to say, whether the SIP URL address has been allocated by the domain authority to a SIP user. The SIP URL destination address is a valid network address if it can be resolved by a location database using DNS or other resolution means to a respective numerical IP address, for example. In this respect address resolution may involve querying other location databases associated with other network SIP servers or SIP domains in a similar way that DNS resolves numerical IP addresses. In step 514, if the destination SIP URL address is valid, that is to say it has been allocated to a respective user and can be resolved, the location server returns the IP address of the next SIP server that is configured to relay or re-direct the message or if appropriate the IP address of the end system currently associated with the destination SIP URL. The SIP message is sent to the next SIP network server or destination end system in step 516. If the SIP URL is invalid, that is to say it has not been allocated by the appropriate domain authority for use in the network, an appropriate SIP network server transmits the SIP message to an associated SIP to SMTP e-mail gateway in step 516. The destination SIP URL may be invalid for instance because it was automatically generated from a known e-mail address identifier in step 504 and no corresponding SIP address exists. Under these circumstances the message processor 420 re-formats the SIP message to an SMTP message for communication over the Internet 406 in accordance with SMTP in step 518. In step 520 the destination. SIP URL address is processed by the address generator 418 in step 520 to derive the SMTP e-mail address encapsulated within the SIP URL address. Additional information and data is added to the re-formatted SMTP e-mail message in step 522 including, for example the text:
      • “You were called by SIP user <sender's SIP URL and associated data> at <time, date> with message <SIP message body content (SDP)> but you were not found in the SIP registration system. You can register at <http hyperlink> where you can download a SIP client.”
        or,
      • “You were called by SIP user <sender's SIP URL and associated data> at <time, date> with message <SIP message body content (SDP)> but you were not found in the SIP registration system. You can register using the attached http form <http registration form with mailto: URI address>. A SIP client <SIP client executable code> is attached.”
  • The SMTP message is sent to an associated mail transfer agent 416 in step 524 for transmission to the e-mail address derived in step 520 using the SMTP network protocol. In step 526 the sender is informed by the SIP server that the destination SIP URL was not valid and that the message was instead re-formatted according to SMTP and sent to the SMTP e-mail address derived in step 520.
  • It will be seen that the other embodiments of the present invention could be readily implemented by the skilled person, for instance instead of the SIP message being diverted to a SIP to e-mail gateway in the event that the destination SIP URL address is invalid, a SIP message could be readily diverted to a SIP to e-mail gateway if the user or the end system associated with the user was unavailable or unwilling to receive SIP messages at the time of message transmission. In one embodiment, the respective SIP server selects an appropriate message from an associated message library (not shown) for inclusion with the original SIP message in step 522. The message library includes a respective delivery failure message for each SIP message delivery failure mode, including for example, destination SIP user agent unavailable, user unavailable, network connection failure, user unwilling to join SIP session or user unwilling to join designated sessions, user will be available at <time, date>, etc.
  • It will also be seen that in other embodiments the SIP to e-mail gateway 414 could be readily implemented in other network devices such as a respective network SIP server or a SIP user agent.

Claims (3)

1. A method for processing messages in a unified packet network capable of processing and delivering packet messages using first and second destination address formats, said method comprising:
transmitting a message into a packet network having a first destination address format encapsulating information sufficient to derive a second address format for the same destination;
if said first address format is determined not to be deliverable in said network, then deriving said second address format from said encapsulated information and re-transmitting said message into said network using said second address format for said destination.
2. A method as in claim 1 wherein said first address format is in accordance with SIP and said second address format is in accordance with SMTP.
3. A method as in claim 1 wherein if said first address format is determined not to be deliverable then an error message is also generated and sent to the intended message recipient using said derived second address format.
US11/724,248 2000-03-24 2007-03-15 Processing network communication control messages Abandoned US20070162613A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/724,248 US20070162613A1 (en) 2000-03-24 2007-03-15 Processing network communication control messages

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
EP00302424.7 2000-03-24
EP00302424A EP1137235A1 (en) 2000-03-24 2000-03-24 Processing network communication control messages
US10/220,498 US7243162B2 (en) 2000-03-24 2001-03-26 Processing network communication control messages
PCT/GB2001/001343 WO2001074030A1 (en) 2000-03-24 2001-03-26 Processing network communication control messages
US11/724,248 US20070162613A1 (en) 2000-03-24 2007-03-15 Processing network communication control messages

Related Parent Applications (2)

Application Number Title Priority Date Filing Date
US10/220,498 Division US7243162B2 (en) 2000-03-24 2001-03-26 Processing network communication control messages
PCT/GB2001/001343 Division WO2001074030A1 (en) 2000-03-24 2001-03-26 Processing network communication control messages

Publications (1)

Publication Number Publication Date
US20070162613A1 true US20070162613A1 (en) 2007-07-12

Family

ID=8172821

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/220,498 Expired - Lifetime US7243162B2 (en) 2000-03-24 2001-03-26 Processing network communication control messages
US11/724,248 Abandoned US20070162613A1 (en) 2000-03-24 2007-03-15 Processing network communication control messages

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US10/220,498 Expired - Lifetime US7243162B2 (en) 2000-03-24 2001-03-26 Processing network communication control messages

Country Status (5)

Country Link
US (2) US7243162B2 (en)
EP (2) EP1137235A1 (en)
CA (1) CA2403769C (en)
DE (1) DE60141203D1 (en)
WO (1) WO2001074030A1 (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050193133A1 (en) * 2002-04-08 2005-09-01 Nokia Corporation Message header for messaging service
US20070047571A1 (en) * 2005-08-23 2007-03-01 Kandikonda Prasad V Session initiation protocol survivable server
US20080208993A1 (en) * 2005-06-10 2008-08-28 Robert Skog Method For Distributing New Services in an Internet Multimedia Subsystem (Ims), and a Node Adapted Therefore
US20090103451A1 (en) * 2005-01-05 2009-04-23 International Business Machines Corporation Method and system for topology discovery in an SIP network
US20100306398A1 (en) * 2009-05-27 2010-12-02 International Business Machines Corporation Message Processing to Improve Server Performance
US8001192B1 (en) * 2004-06-28 2011-08-16 Sprint Spectrum L.P. Method and apparatus for automatically generating custom format messages based on message-destination

Families Citing this family (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6958994B2 (en) 1998-09-24 2005-10-25 Genesys Telecommunications Laboratories, Inc. Call transfer using session initiation protocol (SIP)
US7120141B2 (en) 1998-09-24 2006-10-10 Genesys Telecommunications Laboratories, Inc. Integrating SIP control messaging into existing communication center routing infrastructure
US20070121601A1 (en) * 1998-09-24 2007-05-31 Genesys Telecommunications Laboratories, Inc Integrating SIP Control Messaging into Existing Communication Center Routing Infrastructure
US6934279B1 (en) * 2000-03-13 2005-08-23 Nortel Networks Limited Controlling voice communications over a data network
EP1137235A1 (en) * 2000-03-24 2001-09-26 BRITISH TELECOMMUNICATIONS public limited company Processing network communication control messages
US6917612B2 (en) * 2000-09-01 2005-07-12 Telefonaktiebolaged L M Ericsson System and method for address resolution in internet protocol (IP)-based networks
US7512151B2 (en) * 2001-04-17 2009-03-31 Nokia Corporation Providing a network node with service reference information
US7984110B1 (en) * 2001-11-02 2011-07-19 Hewlett-Packard Company Method and system for load balancing
EP1329859A1 (en) * 2002-01-17 2003-07-23 Siemens Aktiengesellschaft Method of realising payments in communication networks
US7743065B2 (en) * 2002-06-27 2010-06-22 Siebel Systems, Inc. System and method for cross-referencing information in an enterprise system
KR100487124B1 (en) * 2002-11-12 2005-05-03 삼성전자주식회사 method for processing session information of session initiation protocol system and recorded medium thereof
EP1576769A4 (en) * 2002-11-13 2011-08-31 Intel Corp Multi-modal web interaction over wireless network
US7366782B2 (en) * 2003-04-14 2008-04-29 At&T Corp. Systems and methods for termination of session initiation protocol
KR100544195B1 (en) * 2003-08-12 2006-01-23 삼성전자주식회사 Method and system of initiating session using session initiation protocol under mobile IPv6
JP4273899B2 (en) * 2003-09-25 2009-06-03 日本電気株式会社 Network system, protocol conversion apparatus and method
US7761571B2 (en) * 2003-11-25 2010-07-20 Panasonic Corporation SIP service for home network device and service mobility
DK1697851T3 (en) * 2003-12-01 2010-05-03 Interdigital Tech Corp Session initiation protocol (SIP) based on user-initiated handover
US20060026286A1 (en) * 2004-07-06 2006-02-02 Oracle International Corporation System and method for managing user session meta-data in a reverse proxy
CN100499597C (en) * 2005-05-20 2009-06-10 华为技术有限公司 Method for transmitting MM4 interface message in multimedia message system
US7594020B2 (en) * 2005-05-31 2009-09-22 Microsoft Corporation Re-establishing a connection for an application layer via a service layer
US8515421B2 (en) * 2005-11-12 2013-08-20 Interdigital Technology Corporation IMS enabled attach procedure for LTE
US8571198B2 (en) * 2006-10-10 2013-10-29 Cisco Technology, Inc. Handling redirect calls
KR100814398B1 (en) * 2006-12-07 2008-03-18 삼성전자주식회사 Voip phone providing multi-call service and method thereof
US9100500B2 (en) * 2007-01-08 2015-08-04 Qualcomm Incorporated Methods and systems of providing local access number calling features
US9088641B2 (en) * 2007-01-09 2015-07-21 Qualcomm Incorporated Method and system for transmitting audio data between computing devices
WO2008100909A2 (en) * 2007-02-12 2008-08-21 Iskoot, Inc. Methods and systems for performing authentication and authorization in a user-device environment
WO2008121965A2 (en) * 2007-03-29 2008-10-09 Iskoot, Inc. Methods and systems for performing server-based mobile chat
WO2008151033A2 (en) * 2007-05-30 2008-12-11 Iskoot, Inc. Methods and systems for propagating information across a network
US8391848B2 (en) 2007-06-07 2013-03-05 Qualcomm Iskoot, Inc. Telecommunication call support for mobile devices with presence features
US9015279B2 (en) * 2007-06-15 2015-04-21 Bryte Computer Technologies Methods, systems, and computer program products for tokenized domain name resolution
US8200644B2 (en) * 2007-06-15 2012-06-12 Bryte Computer Technologies, Inc. Methods, systems, and computer program products for search result driven charitable donations
WO2009077003A1 (en) 2007-12-17 2009-06-25 Telefonaktiebolaget Lm Ericsson (Publ) Session initiation protocol stack optimisation
US7724652B2 (en) * 2008-01-08 2010-05-25 International Business Machines Corporation Method of reducing network congestion
EP2355455A1 (en) * 2010-02-04 2011-08-10 Gemalto SA Method for generating a permanent public SIP address associated with a private identity on an IMS network
US20110289434A1 (en) * 2010-05-20 2011-11-24 Barracuda Networks, Inc. Certified URL checking, caching, and categorization service
JP5693065B2 (en) * 2010-07-06 2015-04-01 キヤノン株式会社 Communication terminal, communication terminal control method and program
DE102015016616A1 (en) * 2015-12-22 2017-06-22 Giesecke & Devrient Gmbh Device and method for connecting a production device to a network
US11743304B2 (en) * 2019-12-27 2023-08-29 Ribbon Communications Operating Company, Inc. Methods and apparatus to preserve original attestation/signature information for diverted calls

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6138149A (en) * 1997-06-05 2000-10-24 Sony Corporation System for tracking information copied from a web page and sent via electronic mail
US6147773A (en) * 1995-09-05 2000-11-14 Hewlett-Packard Company System and method for a communication system
US20010028654A1 (en) * 1998-12-11 2001-10-11 Farooq Anjum Architecture for the rapid creation of telephony services in a next generation network
US6393463B1 (en) * 1997-12-26 2002-05-21 Casio Computer Co., Ltd. Electronic mail communication apparatus, electronic mail system, and electronic mail communication method
US6577622B1 (en) * 1999-09-27 2003-06-10 3Com Corp. System and method for using a portable information device to establish a conference call on a telephony network
US20030110292A1 (en) * 2001-12-07 2003-06-12 Yukiko Takeda Address translator, message processing method and euipment
US6651166B1 (en) * 1998-04-09 2003-11-18 Tumbleweed Software Corp. Sender driven certification enrollment system
US6651087B1 (en) * 1999-01-28 2003-11-18 Bellsouth Intellectual Property Corporation Method and system for publishing an electronic file attached to an electronic mail message
US6678735B1 (en) * 2000-01-26 2004-01-13 Nortel Networks Limited Method and apparatus for a sip client manager
US6735621B1 (en) * 2000-02-18 2004-05-11 Nortel Networks Limited Method and apparatus for messaging between disparate networks
US6988143B2 (en) * 2000-03-24 2006-01-17 British Telecommunications Processing network address identifiers
US7243162B2 (en) * 2000-03-24 2007-07-10 British Telecommunications Public Limited Company Processing network communication control messages

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5210869A (en) * 1990-05-24 1993-05-11 International Business Machines Corporation Method and system for automated transmission of failure of delivery message in a data processing system
US5278955A (en) * 1990-06-18 1994-01-11 International Business Machines Corporation Open systems mail handling capability in a multi-user environment
EP0886826A1 (en) 1996-01-26 1998-12-30 Ex Machina, Inc. System and method for transmission of data
AU1390399A (en) 1997-11-24 1999-06-15 Pointcast, Inc. Identification and processing of compressed hypertext markup language (html)

Patent Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6147773A (en) * 1995-09-05 2000-11-14 Hewlett-Packard Company System and method for a communication system
US6138149A (en) * 1997-06-05 2000-10-24 Sony Corporation System for tracking information copied from a web page and sent via electronic mail
US6393463B1 (en) * 1997-12-26 2002-05-21 Casio Computer Co., Ltd. Electronic mail communication apparatus, electronic mail system, and electronic mail communication method
US6651166B1 (en) * 1998-04-09 2003-11-18 Tumbleweed Software Corp. Sender driven certification enrollment system
US20010028654A1 (en) * 1998-12-11 2001-10-11 Farooq Anjum Architecture for the rapid creation of telephony services in a next generation network
US6651087B1 (en) * 1999-01-28 2003-11-18 Bellsouth Intellectual Property Corporation Method and system for publishing an electronic file attached to an electronic mail message
US6577622B1 (en) * 1999-09-27 2003-06-10 3Com Corp. System and method for using a portable information device to establish a conference call on a telephony network
US6678735B1 (en) * 2000-01-26 2004-01-13 Nortel Networks Limited Method and apparatus for a sip client manager
US6735621B1 (en) * 2000-02-18 2004-05-11 Nortel Networks Limited Method and apparatus for messaging between disparate networks
US6988143B2 (en) * 2000-03-24 2006-01-17 British Telecommunications Processing network address identifiers
US7243162B2 (en) * 2000-03-24 2007-07-10 British Telecommunications Public Limited Company Processing network communication control messages
US20030110292A1 (en) * 2001-12-07 2003-06-12 Yukiko Takeda Address translator, message processing method and euipment

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050193133A1 (en) * 2002-04-08 2005-09-01 Nokia Corporation Message header for messaging service
US8001192B1 (en) * 2004-06-28 2011-08-16 Sprint Spectrum L.P. Method and apparatus for automatically generating custom format messages based on message-destination
US20090103451A1 (en) * 2005-01-05 2009-04-23 International Business Machines Corporation Method and system for topology discovery in an SIP network
US8009585B2 (en) * 2005-01-05 2011-08-30 International Business Machines Corporation Method and system for topology discovery in an SIP network
US20080208993A1 (en) * 2005-06-10 2008-08-28 Robert Skog Method For Distributing New Services in an Internet Multimedia Subsystem (Ims), and a Node Adapted Therefore
US20070047571A1 (en) * 2005-08-23 2007-03-01 Kandikonda Prasad V Session initiation protocol survivable server
US8125888B2 (en) * 2005-08-23 2012-02-28 Multi-Tech Systems, Inc. Session initiation protocol survivable server
US20100306398A1 (en) * 2009-05-27 2010-12-02 International Business Machines Corporation Message Processing to Improve Server Performance
US8560714B2 (en) 2009-05-27 2013-10-15 International Business Machines Corporation Message processing to improve server performance

Also Published As

Publication number Publication date
US7243162B2 (en) 2007-07-10
EP1137235A1 (en) 2001-09-26
US20030046404A1 (en) 2003-03-06
EP1266503B1 (en) 2010-01-27
CA2403769A1 (en) 2001-10-04
DE60141203D1 (en) 2010-03-18
EP1266503A1 (en) 2002-12-18
WO2001074030A1 (en) 2001-10-04
CA2403769C (en) 2011-01-04

Similar Documents

Publication Publication Date Title
CA2403769C (en) Processing network communication control messages
US6988143B2 (en) Processing network address identifiers
US7469299B2 (en) Bridging user agent and a proxy server for supporting network services
Schulzrinne et al. The session initiation protocol: Internet-centric signaling
AU772765B2 (en) SIP-based feature control
US7412529B2 (en) Method for processing session information of session initiation protocol system and recorded medium thereof
JP5565977B2 (en) Method and system for managing message threads in an integrated IP messaging service
US9124722B2 (en) Recursive query for communications network data
Handley et al. RFC2543: SIP: Session Initiation Protocol
US20030043992A1 (en) Architecture for transporting PBX signaling codes via sip
US20020103850A1 (en) System and method for out-sourcing the functionality of session initiation protocol (SIP) user agents to proxies
US20050044159A1 (en) Messaging system
KR20050122227A (en) System and method to provide interoperability between session initiation protocol and other messaging services
KR20060122979A (en) System and method for pushing content to a terminal utilizing a network-initiated data service technique
WO2001093061A1 (en) Communications protocol
EP1139631A1 (en) Method of initiating a data transfer from a server to a client
EP1493256A1 (en) Message header for messaging service
KR20050018041A (en) Method and system of initiating session using session initiation protocol under mobile IPv6
KR100592881B1 (en) Method and device for providing multimedia messaging service using parlay x gateway system
Gurbani et al. Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs)
WO2001091433A2 (en) Processing of call session information
Edney et al. Session Initiation Protocol
WO2000068812A1 (en) Method of operating an email directory service

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION