Telecommunications – Transmitter and receiver at separate stations – Plural transmitters or receivers
Reexamination Certificate
2001-12-27
2004-02-17
Maung, Nay (Department: 2631)
Telecommunications
Transmitter and receiver at separate stations
Plural transmitters or receivers
C370S503000
Reexamination Certificate
active
06694145
ABSTRACT:
BACKGROUND
1. Field of the Invention
The present invention relates generally to the field of communications. In particular, the invention relates to the use of signaling messages in multimedia communications.
2. Discussion of the Related Art
There are numerous network transport protocols that carry various forms and combinations of multimedia content such as voice, video, web content, graphics and text. Signaling messages work in concert with these transport protocols by enabling terminals on communications networks to contact one another and agree on the parameters of a multimedia session they would like to share. A session is considered to be any exchange of data between two or more terminals.
A recent example of signaling messages is the Session Initiation Protocol (SIP) developed by the Internet Engineering Task Force Version 2.0 of SIP was published by the IETF in 1999 as RFC 2543. An Internet-Draft containing bug fixes and clarifications to SIP 2.0 was published in 2000 as RFC 2543bis. Since then, there have been a few revisions of SIP 2.0 and there are likely to be more revisions and backwardly compatible extensions of SIP 2.0 in the future. For the sake of simplicity all such known and future revisions and backwardly compatible extensions of SIP 2.0 will be referred to in this application simply as “SIP” or “SIP 2.0”.
A variety of SIP messages are used to establish, modify, and terminate multimedia sessions. The names and numbers of the messages are defined in RFC 2543bis. A SIP multimedia session can be a conference, but is not necessarily a conference. Common examples of SIP multimedia sessions are Internet telephony calls, video streaming, etc. SIP is an application-layer protocol that works without dependency on the type of session that is being established. Like the Hypertext Transfer Protocol (HTTP), SIP is based on a request/response transaction model. Each transaction consists of a request that evokes a particular method or function and at least one response.
A variety of multimedia communication services may be implemented using SIP application servers and SIP messages to setup and control the sessions. A SIP message can also can be used to carry content payloads (MIME types such as JPEG) inside the message without having to first set up a multimedia session. This offers the possibility of providing push or push-like “non-call” services such as instant messaging. For example, even though the SIP INVITE message is a signaling message, it may be used for this purpose. MIME-payloads such as image/jpeg or audio/midi may be included in one INVITE message. Other SIP message types (e.g. INFO) may also be used and new message types may be defined for the purpose of providing payload without setting up a multimedia session.
FIG. 1
shows a simple method of using the SIP INVITE message to send data without setting up a multimedia session. First, User A sends a SIP INVITE message (F1) to User B which includes a payload inside it. User B responds by returning “100 Trying” (F2), “180 Ringing” (F3), and “200 OK” (F4), which confirms receipt of the message. User A then sends a “BYE” message (F5), to User B which acknowledges this message by returning “200 OK” (F6). This method has the disadvantage that it can create significantly increased signaling load. When used in conjunction with the User Datagram Protocol (UDP), RFC 768, the method has the further disadvantage that the SIP messages cannot carry attachments which are larger than about 1.5 KB. Message segmentation or transport using the Transport Control Protocol (TCP) are also undesirable. Furthermore, there can be some content, such as some of that on the World Wide Web, which cannot be utilized any other way than by using a Uniform Resource Locator (URL), RFC 1738.
RFC 2543.bis and WO 00/51306 describe a system in which a URL may be placed in a SIP message instead of a payload and the user receiving the SIP message containing the URL obtains the data from the server corresponding to the URL and presents it to the user. This URL is the same as that used by other Internet protocols. The domain name in the URL may be that of the person sending the SIP message, a SIP service provider, a third party, etc. Unfortunately, the manner and duration of the procedure necessary for obtaining the data may vary widely and unpredictably. The procedure may be affected by such factors as, for example, the type and amount of data, the bandwidth capacity of the network of either the user or the server corresponding to the URL, etc. The procedure may be especially slow, sporadic and/or unreliable in wireless communication networks. As a result, the loading and presenting of the data may be completed and occur during any one of the phases of the call establishment setup. For example, the data may be loaded and presented either: before the 180 Ringing message (F3); between the 180 Ringing message (F3) and the 200 OK message (F4); or after the 200 OK message (F4). It is even possible that, if the session is short and the download takes a long time, the download might not even be completed before the session is terminated. This may be undesirable since the data may be presented to the user at different times in different sessions. The situation where the downloaded content is presented a considerable length of time after the phone starts to ring is particularly undesirable.
The problem is exacerbated in third generation (3G) wireless communication networks supporting advanced mobile terminals and allowing a user to subscribe to and access a variety of different multimedia communication services. An advanced mobile terminal supported by such a network and using the latest innovations in computers, software, displays and other technologies may access and receive many different multimedia formats. These multimedia services may be provided by different information sources in other networks and may be based on and built upon a variety of data transfer techniques. This introduces more delay and uncertainty into the procedure associated with loading and presentation of data located at a URL included in a SIP message.
For at least these reasons, present methods of utilizing SIP to transfer multimedia content have disadvantages, especially for user terminals supporting may different types of communications services or in certain types of networks, such as wireless communication networks. Accordingly, there is a need for an effective solution that allows for synchronization of SIP messages and multimedia content loading.
BRIEF SUMMARY
It is therefore an object of the following described example embodiments to overcome the above mentioned disadvantages. In particular, an object of the example embodiments is to provide a solution which facilitates synchronization of signaling messages and multimedia content loading in a user terminal.
In the example embodiments, the URL necessary for obtaining multimedia content from a server or other network element maintaining the content is included in a first signaling message. The user terminal receiving the first signaling message is able to communicate with the server or other network element as desired to synchronize the loading and presentation of the multimedia content according to other information provided to the user terminal in the first signaling message.
A particular aspect of the example embodiments involves an extension to SIP INVITE messages that allows the downloading and presentation of the multimedia content to be controlled by requesting that it be synchronized with a particular SIP message in a call set-up procedure. A user agent in the user terminal receiving the SIP INVITE message responds by sending messages to a URL and as necessary according to a protocol designated in the SIP INVITE message and coordinating the downloading and presentation of the content. The user agent in the terminal may coordinate all of the ongoing messages. The messages used to download the content may be of a type or in accordance with a protocol or otherwise of a manner useful or necessary for communications that dif
Immonen Pekka Salomo
Riikonen Arto
Brown Raysman Millstein Felder & Steiner
Maung Nay
Nokia Corporation
Trinh Tan
LandOfFree
Synchronization of signaling messages and multimedia content... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Synchronization of signaling messages and multimedia content..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Synchronization of signaling messages and multimedia content... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3340615