JP2009506611A - Method for signaling a device so that a device performs asynchronous or includes a synchronization delay in a multimedia stream - Google Patents

Abstract

An improved system that allows a transmitting electronic device to explicitly indicate which streams in a multimedia stream being transmitted should not be synchronized or should include a specified amount of synchronization jitter, and Provide a method.
The present invention assists a receiving device in understanding stream characteristics. The present invention also allows a receiving device to make an informed decision as to whether to use synchronization jitter when synchronizing two or more streams. In certain applications, such as unidirectional video sharing or video PoC, the sending device of the stream instructs the receiving device to perform no or limited synchronization for better media quality. Can do.
[Selection] Figure 1

Description

  The present invention relates generally to the field of IP multimedia communications. More specifically, the present invention relates to signal notification (signaling) used in multimedia communications, in which the receiving device commands not to perform synchronization between different multimedia streams or includes synchronization jitter. ) Regarding the mechanism.

  During setup of an IP multimedia call, the sending device (ie, provider or caller) of the call specifies session information. The session information includes media and transmission related information. This session information is carried in a protocol message such as Session Description Protocol (SDP). The SDP is carried by a high-level signal notification protocol such as Session Initiation Protocol (SIP) or Real Time Streaming Protocol (RTSP). The Third Generation Partnership Project (3GPP) has designated SIP as the signaling protocol choice for multimedia session setup for the IP Multimedia Subsystem (IMS).

  In SDP, the sending device and the receiving device can specify different directions for the media stream, resulting in different types of applications. For example, if the sending device wants to set up a one-way media session (meaning that it sends video and the receiving device expects to receive only this video), this media in SDP Specify the stream as a = sendonly. If the receiving device receives this SDP message and wishes to join this session, the receiving device can specify the stream as a = recvonly. In a videophone, both the sending device and the receiving device specify the media stream direction as a = sendrecv.

  In general, IP multimedia calls require that different media types be synchronized on the receiving device side. For example, in audio / video IP calls, lip sync needs to be performed on the receiving device side for a good user experience. Another example of synchronization includes the use of subtitles, and if the audio and / or video sender is speaking in English, and together with the speech, the text of the speech is different in different languages. These two streams need to be synchronized at the receiving device.

  Different media streams (from the sending device side) are carried in different RTP / User Data Protocol (UDP) / Internet Protocol (IP) streams. The RTP time stamp is used by the client of the receiving device to perform synchronization between media.

  FIG. 1 shows a receiving device that receives a multimedia stream from a transmitting device. The horizontal axis represents elapsed time and shows the packets received. The audio and video buffer shown in FIG. 1 holds RTP packets when receiving packets from the transmitting device. The buffer performs jitter removal (from the network) and calculates the playout time for each packet for each media. Decoding is performed when the packet remains in the buffer for a given time. This time is generally variable and a portion of this time is referred to as jitter. When decoding is complete based on the playout time, the packet is given for display or playback. It should be noted that there can be two different buffers for decoding incoming queues, one for jitter and another for holding incoming RTP packets. For clear and illustrative purposes, in FIG. 1, only one queue is shown, showing a combined jitter and decoding buffer. When the packet is decoded and the playout time has elapsed, it is ready for playback or display. However, if the receiving device is trying to perform audio / video synchronization, it will attempt to delay the first arrived packet.

  In the example shown in FIG. 1, the audio packet 1 arrives at TA1, and the video packet arrives at TV1, which is a time later than TA1. It should be noted that the term “arrive” refers to the time that a packet arrives, or the playout time for each packet. In the example of FIG. 1, audio and video packets with the same playback time have the same reference clock acquisition time (at the transmitting device), which means they have been sampled at the transmitting device at the same time, so they are synchronized There is a need. The calculation of the reference clock acquisition time is performed using the RTP time stamp in the RTP packet and the NTP time stamp transmitted in the RTCP sender report (SR) packet. Audio and video packets can take different network paths, and the processing delay for each packet can be different, so it is very likely to reach the receiving device at different times. Thus, in the example shown in FIG. 1, the audio packet must be delayed by the time of TV1-TA1, which is synchronization jitter or delay.

  In the example shown in FIG. 1, if the application (or sender) does not intend to perform A / V synchronization and the receiving device nevertheless attempts to perform synchronization (because it is the default behavior) The receiving device is forced to hold the audio packet for an additional time. This action can overflow the audio buffer. Furthermore, audio packets at the head of the queue are delayed when attempting to synchronize, resulting in a bad user experience or media quality. If quality of service (QoS) is guaranteed, audio and video packets may have to be dropped if further delayed in the queue. Thus, packet loss, delay, even if the transmitting device does not want the media stream to be synchronized because there is no mechanism to indicate that the transmitting device does not require synchronized or delayed synchronization to the receiving device. Problems such as waste of packets and computational resources may occur.

  Request for Comments (RFC) No. 3388 from the Internet Engineering Task Force's Network Working Group allows the sending device to clearly specify which media streams in a session need to be synchronized. A mechanism is specified. New SDP attributes (eg, “group”, “intermediate”, and lip sync (LS)) are defined to help the sending device specify which media streams in the session need to be lip synced. Also, the default implementation behavior of the RTP receiving device is to synchronize media streams received from the same source. Further, RFC 3388 is required because the specification does not dictate whether the multimedia stream must be synchronized. RFC 3388 only specifies a mechanism that allows a transmitting device to specify which streams need to be synchronized if it is transmitting two or more streams.

  There are applications and uses that require that multimedia streams should not be synchronized. For example, in a Real Time Video Sharing (RTVS) application, the user initiates a unidirectional video sharing session. A unidirectional media session is established by specifying the media stream in SDP as a = sendly or a = recvnly. Already a bi-directional (or uni-directional) audio session is set up between the two parties. One of the parties in the call wants to share the video with the other party. Audio and video are set up on IP bearers, but audio or video sessions can be set up on circuit switched bearers as well. The shared video may be from a file or from a live camera view.

  In some scenarios in unidirectional video sharing, the transmitting device does not want to synchronize video and audio (shared from a file). One reason for this requirement to not synchronize may be that the transmitting device prefers that the video be received with high quality at the receiving device, even if delayed. In this situation, the transmitting device may prefer that the receiving device have a higher delay buffer and therefore not want to perform synchronization.

  Another example of unidirectional video sharing involves the user taking a video of some object and talking about it. In this situation, since the user is recording another object rather than taking a video of the user's own face, a coarser form of synchronization is sufficient than perfect synchronization. Yet another example includes “augmented reality” where graphics are combined with real-time audio and video. In this case, a coarser form of synchronization is sufficient.

  If the default behavior of the client is to synchronize these two streams, the receiving device client will employ a special algorithm to synchronize these streams. The synchronization algorithm on the receiving device side requires a specified amount of computational complexity, and the client will consume some resources even when the transmitting device does not like any synchronization. Audio and video streams can reach the receiving device with different delays. If the receiving device attempts to synchronize the stream, it may result in dropping audio and video frames, thus reducing the quality of the received media.

  Unfortunately, RFC 3388 does not describe a mechanism that can clearly identify which streams should not be synchronized. For example, the transmitting device wishes to transmit three streams, two audio streams (A1 and A2) and one video stream (V1) in the session, and the transmitting device synchronizes the streams A1 and V1. If it is desired to (ship sync), it can be specified using groups, intermediate SDP attributes, and LS semantic tags. This will indicate to the receiving device that A1 and V1 need to be synchronized and A2 should not be synchronized. However, for use cases where there are two or more streams and none of the streams need to be synchronized, RFC 3388 is insufficient. Also, to indicate lip sync performance (and in some cases where RFC 3388 can be used to specify non-lip sync), RFC 3388 must be commanded. Finally, RFC 3388 does not provide a mechanism by which a device can exhibit desirable synchronization jitter between different media.

  For the reasons described above, there is currently no mechanism that can instruct the receiving device in a multimedia call so that the transmitting device does not synchronize the multimedia stream conveyed by the transmitting device. There is also no mechanism for specifying synchronization delay (synchronization delay) or jitter.

  The present invention provides a mechanism by which a transmission or transmission device can explicitly indicate which streams in the multimedia stream being transmitted should not be synchronized or contain a specified amount of synchronization jitter. This mechanism helps the receiving device understand the characteristics of the stream so that it can make informed decisions about whether to perform synchronization and to specify the synchronization jitter value. To. In certain applications, such as unidirectional video sharing or video PoC, the sending device of the stream can indicate that the receiving device does not perform any synchronization for better media quality.

  One embodiment of the present invention involves the introduction of a number of new SDP attributes. The sending device specifies these attributes in the SDP during the session setup phase, and the attributes can be carried by any higher signaling protocol (eg SIP, RTSP, etc.). However, these attributes are not limited to the use of the SDP protocol and any other communication at any of layers 1-7 of the ISO OSI protocol stack (eg, XML, HTTP, UPnP, CC / PP, etc.) It can be defined and carried using a protocol.

  The present invention provides substantial benefits compared to the normal RFC3388 framework by providing the ability to indicate preferences for asynchronousness between the media streams of the transmitting device during the session setup phase. There are use cases and application cases where it is not desired to synchronize the media being transmitted by the transmitting device. When this preference can be signaled to the receiving device, the receiving device can set resources accordingly and not waste computing resources that can be used for other tasks or higher media quality. As a result, the present invention can reduce the packet loss of the receiving device that may occur when the receiving device attempts to perform media stream synchronization.

  In addition to the above, the present invention improves RFC 3388 by providing the ability to indicate preferences for synchronization jitter between the media streams of the transmitting device during the session setup phase. In addition, there are use cases and applications in which the transmitting device wishes that the media being transmitted should be synchronized with coarser jitter, so the ability of the receiving device to signal this preference to the receiving device It is possible to set resources accordingly. This also provides an opportunity to save computational resources. In some cases, this can also yield an improved level of media quality. In fact, in a forced media synchronization scenario, there is some packet loss that can occur due to data loss or other reasons at the receiving device when the receiving device attempts to perform media stream synchronization. This is due to the fact that media data can reach the receiving device with different delays, and some content results in being too late to be useful for fully synchronized playback there is a possibility. By controlling the synchronization jitter, this problem can be mitigated or eliminated.

  These and other objects, advantages, and features of the present invention, as well as the structure and mode of operation thereof, will be described below when considered in conjunction with the accompanying drawings in which like elements have like numerals throughout the several drawings. Will become apparent from the detailed description of.

  The present invention provides a mechanism by which a transmission or transmission device can explicitly indicate which streams in the multimedia stream being transmitted should not be synchronized or contain a specified amount of synchronization jitter. This mechanism helps the receiving device understand the characteristics of the stream so that it can make informed decisions about whether to perform synchronization and to specify the synchronization jitter value. To.

  In order to understand the implementation of the present invention, FIG. 1 shows that during the session setup period, the transmitting device does not want the receiving device to perform any synchronization or a specified value (eg 500 milliseconds). Can be used based on the understanding of performing synchronization with coarser synchronization delay or jitter. In this scenario, the receiving device has completed decoding for each packet in each media stream and can provide each packet for display when the playout time has elapsed. The receiving device may not delay the packet longer than the specified value. This serves to prevent jitter buffer overflow problems, packets are not delayed for synchronization purposes, and media quality is improved. In this scenario, the reception must manage both media queues separately without any correlation.

  If the sending device expects the receiving device to perform some synchronization with the specified delay value, the receiving device will determine the playout time difference (TV1-TA1) for audio and video packets after decoding. . If this value is smaller than the value set in the session setup for synchronization jitter, the receiving device need not hold audio and video packets for a longer period than the playout time indicates. If the value (TV1-TA1) is greater than the synchronization jitter, the receiving device needs to hold the packet for a short time. For example, if the synchronization jitter is specified as 500 milliseconds and TV1-TA1 is 350 milliseconds during session setup, the receiving device need not specify anything. However, if TV1-TA1 is 600 milliseconds, the audio packet must be delayed in the queue by an additional 100 milliseconds.

  In the first embodiment of the present invention, two mechanisms are specified that allow a multimedia stream sending device to indicate that the multimedia stream should not be synchronized. This embodiment includes the introduction of new SDP parameters that assist the sending device of the multimedia stream to specify that the receiving device should not perform synchronization.

  In the first mechanism, a new SDP attribute called “NO_SYNC” is introduced. “NO_SYNC” indicates that the stream should not be synchronized with any other multimedia stream in the session. The NO_SYNC attribute is specified as a = NO_SYNC.

The NO_SYNC attribute can be defined at the media level (ie after the m line in SDP) or can be defined at the session level. When defined at the media level, the NO_SYNC attribute means that the media stream should not be synchronized with any other stream in the session. An example using the NO_SYNC attribute is as follows.
v = 0
0 = NRC 289084412 2890884235 IN IP4 123.11245.1
s = Demo
c = IN IP4 123.11245.1
m = video 6001 RTP / AVP 98
a = rtpmap: 98 MP4V-ES / 90000
a = NO_SYNC
m = video 5001 RTP / AVP 99
a = rtpmap 99 H2.63 / 90000
m = audio 6001 RTP / AVP 98
a = rtpmap: 98 AMR

  In the above example, the first video stream should not be synchronized at the receiving device. When the receiving device client receives this SDP, it knows that the video stream (with the MPEG4 codec) should not be synchronized with any other stream. The receiving device can choose to synchronize or not synchronize the remaining (audio and video) streams.

The NO_SYNC attribute is specified at the start of the session and suggests that all streams in the session should not be synchronized. This is shown as follows.
v = 0
o = NRC 289084412 2890884235 IN IP4 123.11245.1
s = Demo
c = IN IP4 123.11245.1
a = NO_SYNC
m = video 6001 RTP / AVP 98
a = rtpmap: 98 MP4V-ES / 90000
m = audio 6001 RTP / AVP 98
a = rtpmap: 98 AMR

  In the above example, the sending device indicates to the receiving device that not all of the streams in the session should be synchronized.

In another embodiment, an extension to RFC 3388 can be defined. This extension can be used to specify which streams should not be synchronized. The following is an example from a normal RFC3388 system that shows how synchronization is indicated in SDP.
v = 0
0 = Laura 289083124 289083124 IN IP4 one. example. com
t = 0 0
c = IN IP4 224.2.7.12/127
a = group: LS 1 2
m = audio 30000 RTP / AVP 0
a = mid: 1
m = video 30002 RTP / AVP 31
a = mid: 2
m = audio 30004 RTP / AVP 0
i = This media stream content the the Spanish translation (this media stream includes a Spanish translation)
a = mid: 3

In the above example, streams with mid 1 and mid 2 are synchronized. This is indicated with the LS semantic tag in the group attribute. However, in a new implementation, a new semantic tag is used with the group attribute “NLS” having an asynchronous meaning. The following example shows how a stream can be given an indication that it should not be synchronized with any other stream in the session.
v = 0
0 = Laura 289083124 289083124 IN IP4 one. example. com
t = 0 0
c = IN IP4 224.2.7.12/127
a = group: NLS 1
m = audio 30000 RTP / AVP 0
a = mid: 1
m = video 30002 RTP / AVP 31
a = mid: 2
m = audio 30004 RTP / AVP 0
i = This media stream contains Spanish translation (this media stream includes Spanish translation)
a = mid: 3

  In the above example, the stream with MID 1 is not synchronized with any other stream in the session. RFC 3388 is therefore extended with this new semantic tag to help the sending device indicate that no synchronization is required for the media stream.

The semantic tags LS and NLS can be used in the same session description to describe which streams should be synchronized and which streams should not be synchronized. For example, in the SDP example shown below, stream 1 should not be synchronized with any other stream in the session, and stream 2 and stream 3 should be synchronized. In this way, the transmitting device explicitly describes which streams should be synchronized and which streams should not be synchronized.
v = 0
o = Laura 289083124 289083124 IN IP4 one. example. com
t = 0 0
c = IN IP4 224.2.7.12/127
a = group: NLS 1
a = group: LS 2 3
m = audio 30000 RTP / AVP 0
a = mid: 1
m = video 30002 RTP / AVP 31
a = mid: 2
m = audio 30004 RTP / AVP 0
i = This media stream contains the Spanish translation (this media stream includes a Spanish translation)
a = mid: 3

  In a second embodiment of the present invention, a mechanism is introduced that allows a multimedia stream transmitting device to indicate a synchronization delay or jitter value between multimedia streams that the receiving device wishes to synchronize. . In this embodiment, the new SDP parameter is used to specify the jitter value. With these SDP attributes, the sending device can also specify that no stream in a given multimedia session should be synchronized with any other stream in the same session.

In one particular implementation of this embodiment, a new SDP attribute called “sync_jitter” is defined. This attribute indicates the synchronization delay between multimedia streams. The sync_jitter SDP attribute is specified in units of time (eg milliseconds) or any other suitable unit. A sync_jitter value of 0 means that asynchronous should be executed. Attributes in SDP
a = sync_jitter: value // value is for example in milliseconds. (The value is, for example, milliseconds.)
Is specified as

The sync_jitter SDP attribute can be used in conjunction with group and mid attributes and LS semantic tags (as defined in RFC3388). When used with this attribute, sync_jitter specifies the synchronization jitter that is accepted between streams that need to be synchronized as specified in the LS semantic tag. The following is an example from RFC 3388 that describes how synchronization is usually shown in SDP.
v = 0
o = Laura 289083124 289083124 IN IP4 one. example. com
t = 0 0
c = IN IP4 224.2.7.12/127
a = group: LS 1 2
m = audio 30000 RTP / AVP 0
a = mid: 1
m = video 30002 RTP / AVP 31
a = mid: 2
m = audio 30004 RTP / AVP 0
i = This media stream contains the Spanish translation (this media stream includes a Spanish translation)
a = mid: 3

  In the above example, streams with mid 1 and mid 2 are synchronized. This is indicated by the LS semantic tag in the group attribute. However, in this example, there is no way to indicate the desired synchronization between streams with mid 1 and 2. Depending on the various applications (such as unidirectional video sharing or videophone for real-time conversation), the synchronization value will be different.

The following example extends the above example with the sync_jitter attribute. If the above SDP description is used for a unidirectional video sharing application, and if a coarser form of synchronization is sufficient for a particular situation, the transmitting device will account for synchronization jitter between streams with mid 1 and mid 2. For example, a value of 500 milliseconds can be used. In such a situation, the SDP is as follows:
v = 0
o = Laura 289083124 289083124 IN IP4 one. example. com
t = 0 0
c = IN IP4 224.2.7.12/127
a = group: LS 1 2
a = sync_jitter: 500
m = audio 30000 RTP / AVP 0
a = mid: 1
m = video 30002 RTP / AVP 31
a = mid: 2
m = audio 30004 RTP / AVP 0
i = This media stream contains the Spanish translation (this media stream includes a Spanish translation)
a = mid: 3

The sync_jitter attribute can be used in conjunction with a value of 0. A value of 0 essentially specifies that the sending device does not want a particular media stream to be synchronized with any other stream in a given session. As mentioned above, the default implementation is to perform synchronization, and if the SDP implementation of the transmitting device does not support RFC 3388, the transmitting device uses the sync_jitter attribute with a value of 0 to Indicates that a given stream does not want to be synchronized with any other stream. An example of an SDP in which the transmitting device designates the sync_jitter value as 0 is as follows.
v = 0
o = NRC 289084412 2890884235 IN IP4 123.11245.1
s = Demo
c = IN IP4 123.11245.1
m = video 6001 RTP / AVP 98
a = rtpmap: 98 MP4V-ES / 90000
a = sync_jitter: 0
m = video 5001 RTP / AVP 99
a = rtpmap 99 H2.63 / 90000
m = audio 6001 RTP / AVP 98
a = rtpmap: 98 AMR

  In the above example, the transmitting device does not want the first video stream (comprising MPEG-4) to be synchronized with any other stream in the session. The receiving device can choose whether to synchronize the two remaining streams given to the session.

  It should be noted that since 0 has a different meaning, an appropriate value other than 0 for sync_jitter may have to be selected to indicate that no synchronization is required.

  FIG. 4 is a general flow chart representing an implementation of an embodiment of the present invention in which a transmitting device can specify either asynchronous or introduction of a specific value of synchronous jitter. In step 300 of FIG. 4, the transmitting device communicates SDP information. The SDP information includes instructions of the type described above relating to the synchronization of the multimedia stream being transmitted. In step 310, the receiving device receives SDP information. In step 320, the receiving device reads the SDP information to see if there is an instruction that does not synchronize any or all of the multimedia stream, whether it contains a certain amount of synchronization jitter, or whether full synchronization occurs Judging. If there is an asynchronous instruction, this instruction is followed at step 330. If there is a synchronization jitter value, at step 340, a specified amount of jitter is introduced into the stream. If there is no instruction regarding the lack of synchronization or amount of synchronization jitter, or if there is a specific instruction for complete synchronization, complete synchronization occurs at step 350.

  2 and 3 show one exemplary electronic device 12 in which the present invention can be implemented. The electronic device of FIGS. 2 and 3 includes a mobile phone and can be used as a transmitting device or a receiving device. However, it should be understood that the invention is not intended to be limited to one particular type of electronic device. For example, the electronic device 12 may include a personal digital assistant (PDA), a combination of a PDA and a mobile phone, an integrated messaging device (IMD), a desktop computer, a notebook computer, or a variety of other devices.

  2 and 3 includes a housing 30, a display 32 in the form of a liquid crystal display, a keypad 34, a microphone 36, an earphone 38, a battery 40, an infrared port 42, an antenna 44, and a UICC according to one embodiment of the present invention. Smart card 46, card reader 48, wireless interface circuit 52, codec circuit 54, controller 56, and memory 58. The individual circuits and elements are all of the kind familiar to those skilled in the art, for example in the Nokia range of mobile phones.

  The present invention is described in the general context of method steps that can be implemented in one embodiment by a program product that includes computer-executable instructions, such as program code, that is executed by a computer in a network environment.

  Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The specific order of such executable instructions or associated data structures represents an example of a corresponding operation for performing the functions described in such steps.

  The software and web implementation of the present invention is accomplished by standard programming techniques with rule-based logic and other logic that performs various database search, correlation, comparison, and decision steps. be able to. Also, as used in the specification and claims, the terms “component” and “module” receive one or more lines of software code and / or hardware implementation and / or manual input. It should be noted that the aim is to encompass implementation using equipment to do.

  The foregoing descriptions of embodiments of the present invention have been presented for purposes of illustration and description. The present invention is not intended to be exhaustive or limited to the precise forms disclosed, and modifications and variations are possible in light of the above teachings or It can be obtained by practice of the invention. The embodiments describe the principles of the invention and its practical applications so that those skilled in the art can use the invention in various embodiments and with various modifications suitable for the particular application envisaged. Selected and explained.

FIG. 6 illustrates the transmission of multiple audio and video packets from a transmitting device to a receiving device, where synchronization is performed by the receiving device even though the transmitting device does not require synchronization. It is a perspective view of the electronic device which can be used for implementation of this invention. It is the schematic of the circuit of the electronic device of FIG. Figure 5 is a flow chart representing a standard implementation of one embodiment of the present invention.

Claims (35)

A method for providing synchronization information to a plurality of multimedia streams, comprising:
Communicate multiple multimedia streams to the receiving device,
Includes specific instructions for the receiving device that allow an asynchronous or specified amount of synchronization delay between at least one of the plurality of multimedia streams and at least one other of the plurality of multimedia streams. Convey information about the plurality of multimedia streams;
A method comprising:   The method of claim 1, wherein the command is included as an attribute in session information communicated to the receiving device.   The method of claim 1, wherein the instructions include an acceptable synchronization delay value between at least two of the multimedia streams.   The method of claim 1, wherein the instruction includes a "sync_jitter" attribute.   The method of claim 4, wherein the "sync_jitter" attribute is accompanied by a value indicating asynchronous.   The method of claim 4, wherein the "sync_jitter" attribute is accompanied by an acceptable synchronization delay value.   The method of claim 4, wherein the "sync_jitter" attribute is an SDP attribute.   The method of claim 1, wherein the instruction includes a "NO_SYNC" attribute.   The method of claim 1, wherein the instruction includes an "NLS" semantic tag.   The method of claim 1, wherein the communicated information instructs the receiving device not to synchronize any of the plurality of multimedia streams with each other.   The communicated information comprises instructing the receiving device not to synchronize one of the plurality of multimedia streams with any other of the plurality of multimedia streams. Item 2. The method according to Item 1. A computer program product that provides synchronization information to multiple multimedia streams,
Computer code for communicating a plurality of multimedia streams to a receiving device;
Includes specific instructions for the receiving device that allow an asynchronous or specified amount of synchronization delay between at least one of the plurality of multimedia streams and at least one other of the plurality of multimedia streams. Computer code for communicating information about the plurality of multimedia streams;
A computer program product comprising:   The computer program product of claim 12, wherein the instructions are included as attributes in session information communicated to the receiving device.   The computer program product of claim 12, wherein the instructions include an acceptable synchronization delay value between at least two of the multimedia streams.   The computer program product of claim 12, wherein the instructions include a "sync_jitter" attribute.   The computer program product of claim 15, wherein the “sync_jitter” attribute is accompanied by an acceptable synchronization delay value.   The computer program product of claim 15, wherein the "sync_jitter" attribute is an SDP attribute.   The communicated information comprises instructing the receiving device not to synchronize one of the plurality of multimedia streams with any other of the plurality of multimedia streams. Item 13. The computer program product according to Item 12.   The computer program product of claim 12, wherein the communicated information instructs the receiving device not to synchronize any of the plurality of multimedia streams. A processor;
Computer code for communicating a plurality of multimedia streams to a receiving device;
Includes specific instructions for the receiving device that allow an asynchronous or specified amount of synchronization delay between at least one of the plurality of multimedia streams and at least one other of the plurality of multimedia streams. A memory unit operatively coupled to the processor, comprising: computer code for communicating information about the plurality of multimedia streams;
An electronic device comprising:   The electronic device according to claim 20, wherein the command is included as an attribute in session information transmitted to the receiving device.   The electronic device of claim 20, wherein the instructions include an acceptable synchronization delay value between at least two of the multimedia streams.   The electronic device of claim 20, wherein the instruction includes a "sync_jitter" attribute.   24. The electronic device of claim 23, wherein the "sync_jitter" attribute is accompanied by an acceptable synchronization delay value.   24. The electronic device of claim 23, wherein the “sync_jitter” attribute is an SDP attribute.   The electronic device of claim 20, wherein the communicated information instructs the receiving device not to synchronize any of the plurality of multimedia streams.   The communicated information comprises instructing the receiving device not to synchronize one of the plurality of multimedia streams with any other of the plurality of multimedia streams. Item 20. The electronic device according to Item 20.   The electronic device comprises a device selected from the group consisting of a mobile phone, a personal digital assistant, a laptop computer, a desktop computer, an integrated messaging device, and combinations thereof. Electronic devices. A method for processing multimedia content, comprising:
Receive multiple multimedia streams from the sending device,
Receiving information about the plurality of multimedia streams from the transmitting device;
The received information includes specific instructions that allow an asynchronous or specified amount of synchronization delay between at least one of the plurality of multimedia streams and at least one other of the plurality of multimedia streams. And displaying the plurality of multimedia streams according to the specific instruction.
A method comprising:   The method of claim 29, wherein the instructions include an acceptable synchronization delay value between at least two of the multimedia streams.   30. The method of claim 29, wherein the instruction includes a "sync_jitter" attribute.   The method of claim 31, wherein the "sync_jitter" attribute is accompanied by an acceptable synchronization delay value.   30. The method of claim 29, wherein none of the plurality of multimedia streams are synchronized with each other due to the received information.   30. The method of claim 29, wherein the received information does not synchronize one of the plurality of multimedia streams with any other of the plurality of multimedia streams. A processor;
Means for communicating a plurality of multimedia streams to a receiving device;
Specific instructions for the receiving device that allow an asynchronous or specified amount of synchronization delay between at least one of the plurality of multimedia streams and at least one other of the plurality of multimedia streams; Means for communicating information about the plurality of multimedia streams; and a memory unit operatively coupled to the processor;
An electronic device comprising:

Images