Patent Application
20070217430
This invention relates generally to initiating communications and more particularly to initiating Internet protocol communications.
Session initiation protocol (SIP) is a protocol utilized to set up communications channels for communicating according to Internet protocol. One portion of the session initiation protocol involves the offer/answer model adopted by SIP (RFC3264). Another protocol associated with setting up Internet protocol communications is the session description protocol (SDP) (RFC2327). Originally, SDP was intended as a way of specifying media characteristics for the Mbone network. The offer/answer model of SIP places restrictions on SDP's use of SIP so that SDP offers sent by one user agent must be answered in order to have a valid SIP session establishment.
Two major offer/answer models are supported for SIP dialogue establishment. The first model is sometimes referred to as the “early offer” model. In it, the offer is placed in a SIP INVITE method. The answer is then returned in a 200 response or reliable provisional response, and the following ACK (acknowledgment) has no SDP. The second model called “delayed offer,” is often used by back-to-back user agents. Back-to-back user agents refer to a SIP based logical entity that can receive and process INVITE messages as a SIP user agent server (UAS). It also acts as a SIP user agent client (UAC) that determines how the request should be answered and how to initiate the outbound calls. In it, the initial INVITE contains no SDP. The offer then is passed in the 200 response or reliable provisional response, and the ACK contains the answer.
SDP convolves the specification of addresses and port numbers to be used for session establishment with the declaration of the session capabilities (CODECS, bit rates, video form-factors and frame rates, etc.). SDP is defined by the RFC2327 standard. An SDP offer or answer is typically embedded in a SIP message as a MIME-encoded body part.
According to one embodiment of the invention, a method for use in establishing communications includes receiving an invitation for communication at a first device. The invitation for communication is devoid of video capability information. In response to receiving the invitation for communication, the method includes transmitting, from the first device, a signal other than an SDP signal. This signal includes multimedia capability information. After transmission of the signal, the first device receives an offer and incorporates the video capability information included in the signal.
According to another embodiment of the invention, a method for use in establishing communication includes receiving, from a first device, a signal other than an SDP signal. The signal includes multimedia capability information. In response to receiving the signal, the method includes transmitting, to the first device, an offer than incorporates the multimedia capability information.
Embodiments of the invention provide numerous technical advantages. Some, none, or all embodiments may benefit from the below described advantages. For example, according to one embodiment of the invention, a method is provided that allows a user agent to establish communications even in a back-to-back user agent environment without complicated SDP signaling. Further, such a method reduces the occurrence of failed attempts to establish communications sessions due to incompatibilities of certain protocols.
Other advantages will be readily apparent to one of skill in the art.
For a more complete understanding of the present invention and its features and advantages, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which:
Embodiments of the present invention and its advantages are best understood by referring to
User agents 12 and 14 refer to Internet protocol devices that may be used in conjunction with a multimedia conferencing facility, such as an Internet protocol phone, video phone, or other suitable device. Multimedia conferencing facility 16 is one example of a back-to-back user agent. In this example the teachings of the invention are described in the context of a multimedia conferencing facility, although other back-to-back user agents may be used. Multimedia conferencing facility 18 operates in general to connect user agents 12 and 14 through audio and video IP communications. Video relay 18 is a device that can distribute video media throughout a multiconferencing network. Note that while audio media are typically mixed in a multimedia conference, the Video relay merely switches various media according to policies requested by the multimedia conferencing facility 16.
In one embodiment, multimedia conferencing facility 16 includes a computer-readable memory 20 associated with a processor 22. Logic 24 stored in memory 20 may be executed on processor 22 to perform the functions of multimedia conferencing facility 16, including those described herein. Memory 20 and processor 22 may take any suitable form, including conventional and yet-to-be developed memories and processors. Similarly, relay 18 may include, in one embodiment, a computer-readable memory 30 associated with a processor 32. Logic 34 stored in memory 30 may be executed on processor 32 to perform the functions of relay 18, including those described herein. Memory 30 and processor 32 may take any suitable form, including conventional and yet-to-be developed memories and processors.
The teachings of the invention recognize that in the context of system 10 in which one or more of user agent 12 and user agent 14 wish to connect using a delayed offer to a back-to-back user agent 16, which in this example is a multimedia conferencing facility, that is also associated with a video relay 18, that conventional use of SDP offers may be problematic. This is described in greater detail below in conjunction with
Because media relays do not encode media, they often do not have enough information to specify media capabilities. At the same time, the media relay must be able to generate addresses and port numbers in its SDP, which implies that it must also generate media capability information. With reference to
At step 30, a user agent 12 transmits a delayed offer invite to multimedia conferencing facility 16. Because the invite is a delayed offer invite it includes no SDP containing media capabilities or address information associated with the communication to be established. At step 32, according to SIP protocol, the delayed offer invite is forwarded to relay 18, also as a delayed offer, i.e., without an SDP. This is because the multimedia conferencing facility 16 is seeking to obtain the media capability and address information that would normally form a part of the SDP from another user agent. However in this case, because a relay is involved, the invite is sent directly to relay 18, but this is problematic.
What should occur is at step 34 a valid offer containing valid SDP must be returned in a 200 SIP message. However, in order to do so, relay 18 must provide the address and port information associated with the communication to be established as well as the media capabilities associated with the communication to be established. But, because relay 18 does not typically possess media capabilities, it has no media capabilities to return in a valid SDP as part of a 200 SIP response. Thus, the process flow breaks down at this point and communications with user agent 12 are not established. If communication had not broken down, at step 36, multimedia conferencing facility 16 would have forwarded the valid offer to user agent 12, which would then acknowledge the offer and provide an answer at step 38. This acknowledgment would then be forwarded on to relay 18 at step 40.
The teachings of the invention recognize that the main reason this communication breaks down is that multimedia conferencing facility 16 cannot contain port or address information on behalf of relay 18 and that relay 18 does not maintain media capabilities. This is problematic because an SDP requires both of these components to be part of a valid offer. However, the teachings of the invention recognize that although multimedia conferencing facility 16 does not have knowledge of port or address information, it does have media capability information. Further, although video relay 18 does not possess media capability information, it does have port and address information. Thus, according to the teachings of the invention, a mechanism is provided that allows aggregation of both multimedia conferencing capabilities as well as port and address information from each of the multimedia conferencing facility 16 and the relay 18 such that they may be used together.
The teachings of the invention also recognize that, according to SIP protocol, any SIP message that is not an answer that includes an SDP is considered an offer, which must be responded to with an answer. Thus, in the specific SIP embodiment, it would be difficult to transmit media capability of multimedia conferencing facility 16 within an SDP body part contained by a SIP invite, because this would require relay 18 to provide an answer. This would not be desirable because that offer would not include correct port and address information, which are unknown to multimedia conferencing facility 16.
One method for effecting this aggregation of port and address information with media capability information while being able to communicate within the SIP protocol (which is not required in all embodiments) is to create an INVITE that has a body part that is similar to SDP but that is not an SDP body part. By not being an SDP body part, media capability information known by multimedia conferencing facility 16 may be communicated to relay 18 as part of a SIP invite, but without requiring relay 18 to respond with an answer (which it could not because the offer would not include valid port and address information with the INVITE). Media capability information is one example of SDP body part information, or information that is normally included in an SDP body part. Other examples include session information, including bandwidth restrictions, and directionality information. In one example this SDP body part information may be encoded as SIP header information.
In one specific implementation, rather than transmitting an SIP INVITE with a valid SDP body part, the INVITE is transmitted with an SDP template, which in a specific implementation uses dummy port address information. The Multi-part Internet Mail Extension (MIME) type of the SDP template, is set to a type other than that assigned to SDP, such that the INVITE conforms to the delayed offer model instead of the early offer model. Compliance with the delayed offer model is important because relay 18 is then free to respond with an offer having a valid SDP. Use of a non-SDP MIME type allows the characteristics of the offer to be changed such that the offer does not require port and address information. In essence, a two-way handshake is changed to a three-way handshake, utilizing media capability information from multimedia conferencing facility 16 and port and address information from relay 18. Relay 18 then supplies port information of where to send media in a valid offer in response to the invite.
A specific implementation is illustrated in
The method 100 begins at step 102. At step 104 a delayed offer INVITE is received at a device. This delayed offer invite may be transmitted from a user agent such as user agent 12 to a back-to-back user device, which in this example is a multimedia conferencing facility 16. The sending of this invite is illustrated in
At step 106, a second delayed offer SIP invite is transmitted from multimedia conferencing facility 16 to relay 18. The sending of this invite is illustrated at reference numeral 202 in
In one particular implementation, template 203 has the same syntax as an SDP body part, even though it has a different MIME type. This implies that it also includes a fake IP address and port number that would normally indicate the IP address and port number to which communications should be sent once the communication channels are set up. However, in this instance, this IP address and port number are fake IP addresses and port numbers. In a particular implementation, this is performed for ease of use with existing equipment designed to parse SDP syntax containing port and address information; however, it is not necessary that a fake IP address or port number be provided in all embodiments. Further, it is not necessary that the invitation sent from multimedia conferencing facility 16 to relay 18 be a SIP invite. Rather, it is significant only that this signal is other than an SDP signal and that it includes media capability information.
At step 108, relay 18 transmits an offer from relay 18 to multimedia conferencing facility 16. In one particular implementation this offer is a valid SDP offer embedded within a SIP response message with response code 200(OK). This offer 205 (
At step 110 a valid SDP offer is transmitted to the user agent 12, as designated by reference numeral 206 in
In other embodiments, the SIP response message 204 may contain a response code other than 200 OK. The offer may also be provided in any reliable provisional response, such as 180 (ringing) or 183 (call progress). If a reliable provisional response is used, the call flow may be altered so that the answer will be carried in a provisional acknowledgement (PRACK) method, conforming to procedures laid out in RFC 3262, in some embodiments.
It is noted that although
Although some embodiments of the present invention have been described in detail, it should be understood that various changes, substitutions, and alterations can be made hereto without departing from the spirit and scope of the invention as defined by the appended claims.
