Patent Application
20070130475
This invention relates to methods of sending information over the Internet, and more particularly to transmission methods which conform to the SIP protocol.
SIP (Session Initiation Protocol) is an application-layer control (signaling) protocol which cooperates with other protocols to facilitate communication between Internet endpoints, which in this context are also referred to as “user agents”. More specifically, SIP can establish, modify, and terminate Internet telephony calls and other multimedia sessions. SIP provides support of this type by, among other things, locating the end point for a communication, ascertaining whether the called party is available, determining the media to be used and the corresponding media parameters, and setting up and managing the session. A thorough description of SIP may be found in J. Rosenberg et al., RFC 3261, The Internet Society (2002) (www.faqs.org/rfcs/rfc3261.html).
The logical entities that implement rules defined by the SIP protocol are referred to as “SIP elements” or “SIP agents”. SIP elements include user agent (UA) clients, UA servers, stateless proxies, stateful proxies, and registrars. Data sent between the SIP agents as part of the SIP protocol are referred to as “SIP messages”. A SIP message is either a request or a response.
A SIP message includes a header, and may also include a message body. The header is constructed as a sequence of one or more header fields which contain information about the message. A typical header field is populated by a header field name, and may also include a list of one or more header field values.
If the SIP message includes a message body, the pertinent header fields will specify the Internet media type and length of the message body, and whether it has undergone any compression or other encoding.
For a variety of reasons, it would be desirable to be able to send control messages and other data between specific agents in the SIP network without processing, or even without detection, of those messages by intermediary SIP agents. For example, a SIP agent may drop a header from a message passing through it if the agent fails to recognize the header. However, new SIP features and new extensions to SIP will generally require new headers. Even if the new headers can be processed by the agents at the pertinent endpoints of the network, there may be a danger of losing header information in transit unless the entire network has been overhauled. Thus, it would promote the early introduction of new SIP features, before operators invest in network overhaul, if the new headers could be embedded so as to evade processing by intermediary agents.
Other uses for such embedded information might include peer-to-peer communication between specified SIP proxies or agents of transactional or billing information, recording of signaling information for specific sessions between agents for subsequent processing, or communication of information for monitoring network operations, while excluding other proxies and agents from access to the information.
We have devised such a method for embedding information in SIP messages. In one aspect, our new method involves sending information from one SIP agent to another by encrypting the information, embedding the encrypted information in one or more SIP header fields, and transmitting a SIP message that includes the field or fields in which the information is embedded. Specifically, the header fields to be used for this purpose are those whose values are material to the working of the SIP protocol only insofar as they are unique and can be used to ascertain dialog-id, call-id, or other identifying information. Such a property leaves room for us to use these fields to insert unique information and then use that information as the call-id, dialog-id, or the like. Such fields are referred to here as “implementation-defined”. The term “implementation-defined” will have that meaning throughout the discussion below.
In a second aspect, our invention involves a SIP agent receiving such embedded information from another SIP agent by receiving a SIP message that includes SIP header fields, at least one of which is implementation-defined, extracting embedded information from one or more of the implementation-defined SIP header fields, and decrypting the extracted information.
Of the various types of SIP messages that might be used for the embedding of information, it is advantageous to use SIP messages of the most basic types. That will assure that the information can be transported in standard SIP messages, which are relatively plentiful, and are compatible with any SIP agent with which the message might have contact. Basic SIP messages include, for example, the request messages REGISTER, INVITE, ACK, CANCEL, BYE, and OPTIONS, and their responses.
We have identified four header fields which occur in basic SIP messages, and which include implementation-defined parameters, which are examples of header fields useful for the method to be described here.
The header fields we have identified are Via, From, To, and Call-ID.
The “Via” header field includes an address to which responses to a request message are to be sent, and also includes a “branch” parameter for the client and server to use to identify the transaction which the message creates. The branch parameter is implementation-defined, but it must be prefixed by the string “z9hG4bK”.
The “From” header field includes a URI (Uniform Resource Identifier) to identify the initiator of a request message. The “From” header field also includes a “tag” parameter, typically a random string selected by the UAC. (A UAC—User Agent Client—is the logical entity that creates the new request and sends it using the client transaction state machinery.) The tag is used for identification purposes. For example, a “dialog,” i.e., a peer-to-peer SIP relationship, is uniquely identified by the combination of a “To” tag, a “From” tag, and the value of the “Call-ID” field. The “From” tag parameter is implementation-defined.
The “To” header field includes a URI to identify the user or resource that is the target of the request message. A “tag” parameter may be included if the request relates to a dialog.
The “Call-ID” header field provides a unique string for identifying a grouped series of messages. For example, all requests and responses sent by the user agents in a dialog share the same Call-ID. The Call-ID header is implementation-defined. Typically, this field is populated with a cryptographically random string. However, the precise string used is arbitrary, provided only that it can serve its identification function.
In accordance with our method, information is embedded in implementation-defined header fields, such as those described above. With reference to
However, the SIP agent at the destination end point, or one or more intermediary SIP agents on the route between the end points, may be instructed to store certain headers for further processing, in order to recover embedded information therefrom.
As noted above, the “branch” parameter must be prefaced with the string “z9hG4bK”. Therefore, if encrypted information is to be populated into the branch parameter field, it will have to be prepended by this string, in unencrypted form.
It will be advantageous to prepend encrypted information (as embedded in any appropriate field) with a pattern, herein denominated an “initial search string”, which indicates the presence of information to be recovered. The use of such a string can prevent wasteful attempts to decode header fields that do not, in fact, contain embedded information.
Any of various known methods may be used for exchanging the public key K1 and the initial search string. These include, among others, secure phone calls and secure email transmissions.
The utility of the initial search string can be enhanced by designing it to be an index to the format of the data to which it is prepended. Although in principle there is no restriction on the format of the initial search string (other than those that might be imposed by the SIP protocol on the header fields that are affected), it will as a practical matter often be advantageous to use a string at least four characters in length.
Below, we will provide examples of three possible formats for encrypted information, which we denominate S1, S2, and S3, respectively. We also describe a possible format for the initial search strings, which we respectively denominate Pattern1, Pattern2, and Pattern3. The initial search strings are user defined, and are determined prior to the communication to which they pertain.
The three exemplary formats are summarized in the table below:
The type of format that we denominate “parameter-value pairs” is used to pass values for user-defined parameters. The corresponding structure S1 is of the type represented by the following table:
If the initial character is “A”, for example, this format may be used to send advertisements. When one SIP agent requires information from another, the initial character may, e.g., be “R” for “request”. When one SIP agent is replying to another, the initial character may be “P” for “reply”.
The field following the initial character contains a sequence of parameter-value pairs separated by commas.
The type of format that we denominate “Command” is used to send a command, which may take one or more arguments. The corresponding structure S2 is of the type represented by the following table:
The initial character may, for example, take the value “C” to indicate that the data that follow it represent a command. The field following the initial character contains the name of the command, followed, if pertinent, by a list of arguments arg1, arg2, etc., separated by commas.
The type of format that we denominate “Messages” is used to send a message or a string of an arbitrary type. The corresponding structure S3 is of the type represented by the following table:
The initial character may, for example, take the value “M” to denote “message”. The field following the initial character contains the message or string to be sent.
One header may be used to contain all of the embedded information, or the information may be embedded across a multiplicity of headers. However, if the information is spread across multiple Via headers, for example, the SIP agent which is designated to receive the embedded information must strip and process the multiplicity of Via headers, and not just a single Via header. This implies that of the Via headers that contain embedded information, all but one are dummy headers that a SIP agent will process and remove from the SIP message in either direction.
The dummy Via headers may include dummy domain names, provided the non-dummy Via header belonging to the pertinent SIP agent is on top, and the pertinent SIP agent knows how to process the dummy headers. The destination SIP agent that has been targeted to receive the embedded information should also know how to process and strip the dummy Via headers.
Embedded information in the “To”, “From”, and “Call-Id” headers cannot be spread across multiple headers of those respective types, because multiplicities of headers of those types would cause the SIP protocol to fail.
In the “To” and “From” headers, information is embedded by inserting it in the “Tag” field. That is, these headers include a string of the form “tag=value”. The embedded information is inserted in the place denominated as “value”.
The “Call-Id” field contains a string of the form “abcd@domain.com”. Information can be embedded in this field by inserting it before the “@” sign; that is, by inserting it in the place denominated as “abcd”.
On receipt by the SIP agent which is the targeted recipient for the embedded information, the headers are stored for subsequent processing. The subsequent processing includes, for example, selecting those header fields that have initial search strings, and decrypting them to recover the embedded information.
