Receiver actions and implementations for efficient media handling

TECHNICAL FIELD

p-0002The present invention generally relates to media technology in communication environments, and more particularly to actions and/or implementations on the receiver side for efficient media handling.

BACKGROUND

p-0003Modern communication systems support exchange of a wide variety of media between users, including voice, audio, video, text and images. Most so-called multimedia systems are based on the Internet Protocol (IP) technology. A particular example of such an IP-based system is the IP Multimedia Subsystem (IMS) [1], which allows advanced multimedia services and content to be delivered over broadband networks. For example, real-time user-to-user multimedia telephony (MMTel) services [2] will play a key role to satisfy the needs of different multimedia services.

p-0004By way of example, supplementary services will play an important role in modern communication systems such as IMS Multimedia Telephony (MMTel) systems, and it is important that such systems support the same or at least similar supplementary services that are found in traditional systems without causing performance degradations such as media distortions. Examples of supplementary services are calling line identification presentation, call on hold, conferencing and announcements. For example, announcements may be generated by the communication network or by the remote user's switchboard or computer.

p-0005Usage examples of announcements from the communication network include: <ul><li id="ul0001-0001" num="0000"><ul><li id="ul0002-0001" num="0005">Error messages when the command that the user has initiated cannot be completed. For example: when the caller has suppressed presentation of the phone number and the answerer has defined that he will not answer calls without seeing the phone number, then the system must present an error message to the caller.</li><li id="ul0002-0002" num="0006">When user A puts the session on hold the system may play a message about this to user B.</li><li id="ul0002-0003" num="0007">In a conference call, the conference server may present an announcement when a new user enters or when a user leaves the session, for example: “John Smith has entered the meeting” and “John Smith has left the meeting”.</li><li id="ul0002-0004" num="0008">A user has a pre-paid subscription that is running empty. The operator can restrict the usage due to a low amount and wants to announce that at session start or during the session (it might be a very long session).</li><li id="ul0002-0005" num="0009">A method that is used more and more on the Internet is to present an image with a pin code (or password) on a web page. The image of the pin code is distorted so much that automatic text recognition systems should not be able to detect the pin code while it should still be possible for a clever human to read the letters and numbers. This is used instead of sending the corresponding pin code with an (insecure) e-mail.</li></ul></li></ul>

p-0006Usage examples of announcements from the answerer are: <ul><li id="ul0003-0001" num="0000"><ul><li id="ul0004-0001" num="0011">A user calls a travel agency to book a ticket. The following scenario is likely:</li><li id="ul0004-0002" num="0012">1. The user talks with a travel agent to find the best traveling option. In this step, the discussion is between two humans.</li><li id="ul0004-0003" num="0013">2. After deciding on the travel, the user is requested to key in his credit card number. This is a man-machine communication where the user hears pre-recorded or machine-generated messages and presses the telephone buttons (0-9) to insert his numbers. In this process the following sentence probable: “Key in your credit card number”, “You have entered: 1234 5678 9012 3456. If this is correct then press 1, if not then press 2.”, “Insert the expiration date of your credit card”, “You have entered: Jan. 1, 2007”. These sentences will be generated by the announcement server.</li><li id="ul0004-0004" num="0014">3. After keying in the credit card number and other required data, the session continues with the travel agent in order to decide on further travel options.</li><li id="ul0004-0005" num="0015">4. These steps may be repeated multiple times.</li></ul></li></ul>

p-0007Compared to traditional communication systems, the conditions and requirements for handling media will change dramatically in modern multimedia communication systems, and there is thus a general need to provide solutions for efficiently handling media in such communication systems.

SUMMARY

p-0008The present invention overcomes these and other drawbacks of the prior art arrangements.

p-0009It is a general object of the present invention to improve the handling of media in a (multimedia) communication system.

p-0010In particular it is desirable to support supplementary services while eliminating or reducing media distortions on the receiver side in a highly cost-efficient manner.

p-0011It is a specific object to provide an improved method and system for reducing media distortions in a receiver equipped with a decoder for decoding incoming media streams.

p-0012It is another specific object to provide an improved receiver for use in a (multimedia) communication system.

p-0013These and other objects are met by the invention as defined by the accompanying patent claims.

p-0014It has been recognized by the inventors that the use of different encoder instances during a communication session may lead to a state mismatch in the decoder on the receiver side, resulting in distortions that may be annoying to the end-user. As an example, this may happen when media from a new media source is inserted in the communication session, e.g. when switching from one media source to another, or when media from a new source is added to an existing media stream.

p-0015A basic idea of the invention is therefore to detect a change in source of incoming media during an on-going communication session, and reset decoder states of the decoder in response to such a detected change before decoding new incoming media. In this way, the state mismatch can be avoided without the need for several active decoder instances in the receiver, leading to substantial savings with respect to overall complexity, memory usage and power consumption. This also means that media distortions can be eliminated or at least reduced when the decoded media is finally rendered.

p-0016Preferably, the detection mechanism is configured for detecting that media from a new media source is inserted in the communication session, e.g. when switching from one media source to another, or when media from a new source is added to the existing media stream. In general, however, a change in source can be a switch between sources, addition of a source and/or removal of a source.

p-0017In other words, the receiver is configured for detecting a potential state mismatch in the decoder during an on-going communication session, and for resetting the decoder in response to a detected potential state mismatch to thereby avoid the state mismatch.

p-0018In an intimately related aspect of the invention, the sending side enforces a decoder reset on the receiving side in preparation of media from a new source by sending a predefined signal pattern. On the receiving side this means that during an on-going communication session involving reception of media from a first media source the receiver will receive a predefined signal pattern in preparation of subsequent reception of media from a second different media source. The decoder will then be reset in response to the predefined signal pattern before initiating decoding of media from the second media source.

p-0019The invention is particularly applicable in modern communication systems for supplementary services such as announcements, call-on-hold and conference services.

p-0020Other advantages offered by the invention will be appreciated when reading the below description of embodiments of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

p-0021The invention, together with further objects and advantages thereof, will be best understood by reference to the following description taken together with the accompanying drawings, in which:

p-0022<figref idrefs="DRAWINGS">FIG. 1</figref> is a schematic diagram illustrating a basic example of switch between different media sources.

p-0023<figref idrefs="DRAWINGS">FIG. 2</figref> is a schematic diagram illustrating a basic example of addition/removal of a contributing source for a mixed media stream.

p-0024<figref idrefs="DRAWINGS">FIG. 3</figref> is a schematic diagram illustrating distortions when the encoder states are reset while the decoder states are not reset.

p-0025<figref idrefs="DRAWINGS">FIG. 4</figref> is a schematic diagram illustrating distortions when the decoder states are reset while the encoder states are not reset.

p-0026<figref idrefs="DRAWINGS">FIG. 5</figref> is a schematic flow diagram of a basic method according to an exemplary embodiment of the invention.

p-0027<figref idrefs="DRAWINGS">FIG. 6</figref> is a schematic block diagram primarily illustrating a receiver according to an exemplary embodiment of the invention.

p-0028<figref idrefs="DRAWINGS">FIG. 7</figref> is a schematic flow diagram of a method according to another exemplary embodiment of the invention.

p-0029<figref idrefs="DRAWINGS">FIG. 8</figref> is a schematic block diagram primarily illustrating a receiver according to a further exemplary embodiment of the invention.

p-0030<figref idrefs="DRAWINGS">FIG. 9</figref> is a schematic flow diagram of a method according to yet another exemplary embodiment of the invention.

DETAILED DESCRIPTION OF EMBODIMENTS

p-0031Throughout the drawings, the same reference characters will be used for corresponding or similar elements.

p-0032A careful analysis by the inventors has revealed that existing solutions suffer from one or more problems. In particular, it has been recognized that encoding the media with different instances of the encoder while using the same decoder will normally lead to a state mismatch in the decoder, resulting in significant distortions when the decoded media is rendered.

p-0033A main problem is that the media is encoded with different instances of the encoder while the decoder is the same. The reason for using the same decoder is because of complexity limitations and/or memory limitations and/or power consumption. In the example illustrated in <figref idrefs="DRAWINGS">FIG. 1</figref> it is considered that one type of media is produced with a sender/encoder <b>10</b>, denoted A, and this media is transmitted to a receiver/decoder <b>20</b>, denoted B, in e.g. a VoIP session. During the session the media from sender/encoder <b>10</b>, A, is replaced by the media encoded by a sender/encoder <b>30</b>, denoted X. In short, media produced at A is sent to B, and then replaced at least temporarily by media from X.

p-0034As illustrated in <figref idrefs="DRAWINGS">FIG. 2</figref>, there may be a similar problem in a communication session between a sender/encoder <b>10</b>, denoted A, and a receiver/decoder <b>20</b>, denoted B, when media from a sender/encoder <b>30</b>, denoted X, is added as a new contributing source to a mixed media stream by an intermediate mixer <b>40</b>. In the particular example of media communication based on the Real-time Transport Protocol (RTP) [3], there are two fields in the header of an RTP data packet that are of particular importance to media stream communication, namely the SSRC and CSRC fields. SSRC stands for Synchronization Source and identifies a unique RTP sender. CSRC stands for Contributing Source or Content Source and identifies the contributing source(s) of the mixed media payload. If there are multiple contributing sources, the payload is the mixed data from these sources. With reference to <figref idrefs="DRAWINGS">FIG. 2</figref>, it can be seen that each of the media sources A and X may send an individual media stream to the mixer <b>40</b> with an SSRC that corresponds to the payload source. The mixed media stream from the mixer <b>40</b> has an SSRC that corresponds to the mixer, and the CSRC values identify the contributing sources A and X of the mixed media stream to B. In analogy, a contributing source may of course also be removed from a mixed media stream.

p-0035There is also the possibility that the mixer (or application server) drops one of the sources and just forwards the other one to the receiver. Another possibility is that both streams go all the way to the receiver and the receiver has to choose which one to present to the listener.

p-0036Although switching of encoder instances works in existing circuit switched systems today, this works well because the used codecs are typically PCM [4] or ADPCM [5]. These codecs are sample-by-sample codecs which either do not use any prediction (PCM) or very limited amount of prediction (ADPCM). This means that the decoder will recover very rapidly from a state mismatch and the likelihood that this will cause an audible or otherwise perceivable distortion is low.

p-0037If one would use a codec that relies more on prediction and states, for example AMR [6] or AMR-WB [7], then switching between two encoders will cause a state mismatch in the decoder. For example, when switching from speech media from an encoder A to the media from an encoder X, the decoder states are the same as in the encoder A at the switching instant while the states in the encoder X will start from the initialization states. A similar state mismatch will occur if a switch is made back to the media from encoder A.

p-0038A further problem with a multi-rate codec such as AMR is that the speech from encoder A may very well be encoded with a lower rate codec mode, for example AMR 5.9 kbps, while the media from encoder X may very well be encoded with a higher rate codec mode, for example AMR 12.2 kbps. In this case, there is not only a state mismatch, but also a codec mode mismatch. Another example involves switching between codecs, for example between AMR and EVRC or between AMR and AMR-WB, representing a codec mismatch.

p-0039The states are very important for modern low-rate speech codecs since states are necessary in order to achieve good compression ratio while still providing good speech quality. A state mismatch can cause distortions that are more or less audible depending on the current content. In order to reduce the quality impact, it is therefore important to handle the media properly. In particular, the use of modern prediction-based codecs will normally lead to state mismatches, e.g. when an announcement interrupts the normal media, resulting in audible or otherwise perceivable distortions that may also be annoying to the user. Inter-frame prediction is used in many modern codecs, such as AMR or AMR-WB, in order to reduce the bit rate, i.e. to obtain a high compression ratio, while still providing good quality. The inter-frame prediction requires that states are passed from frame to frame. When an announcement interrupts the normal media, there will be a state mismatch since two different instances of the codec is used, one codec instance in UE A for the speech media from the user and one codec instance in the announcement server. The states in UE A have evolved according to the used prediction while the states in the announcement server start from the initialization states. A state mismatch can cause distortions that are more or less audible depending on the current content. Two examples of such distortions are shown in <figref idrefs="DRAWINGS">FIG. 3</figref> and <figref idrefs="DRAWINGS">FIG. 4</figref>. The distortions are in both cases clearly audible and are easily noticeable by the listener but the spikes in <figref idrefs="DRAWINGS">FIG. 3</figref> are much more annoying.

p-0040From <figref idrefs="DRAWINGS">FIGS. 3 and 4</figref> it can also be seen that it takes about 100-200 ms for the synthesis to recover after an asynchronous reset. A state-less codec such as PCM would instead recover immediately since there is no need to “build up” the states to the proper content.

p-0041This problem is not limited to speech. Similar problems occur also for general audio and for video. For these cases, one can in some cases expect even larger problems since these codecs typically has a larger compression ratio than speech codecs and to achieve this compression ratio they rely even more on good quality states.

p-0042As mentioned, a switch of encoder instances will occur when media from a given encoder is interrupted and replaced by an announcement encoded by a different encoder, a switch will occur when the announcement starts, another switch will occur when the announcement ends and/or the switch is made back to the original encoder instant. The announcement may be encoded “on the fly” or it may exist as prerecorded material, from a receiver viewpoint this does not make any difference though.

p-0043A state mismatch may also occur in call-on-hold situations. The state mismatch problem in call on hold scenarios can be illustrated as <ul><li id="ul0005-0001" num="0000"><ul><li id="ul0006-0001" num="0053">1. User A has a conversation with user B and both UEs are in send-receive state.</li><li id="ul0006-0002" num="0054">2. User A puts user B on hold. UE A will enter send-only state and UE B will enter receive-only state.</li><li id="ul0006-0003" num="0055">3. User A sets up a conversation with user C and both UEs are in send-receive state. User B might get an announcement or music on hold from X meanwhile, or might be muted.</li><li id="ul0006-0004" num="0056">4. User A resumes conversation with user B. Both UE A and UE B are in send-receive state.</li></ul></li></ul>

p-0044In addition to the problem in B when media from A is interrupted by an announcement or music on hold, the above scenario also gives a few potential problems in the transition from step 3 to step 4. <ul><li id="ul0007-0001" num="0000"><ul><li id="ul0008-0001" num="0058">1. The UE of User A has received packets from the UE of User C, and will all of a sudden get packets from the UE of User B. If the two streams C→A and B→A are decoded with two different decoder instances, this is normally a small problem. If on the other hand the two streams share a single decoder instance this gives a potential risk for severe state mismatch unless the decoder is reset.</li><li id="ul0008-0002" num="0059">2. The UE of User B may have received DTX SID update packets from the UE of User A, call announcement or music on hold, or nothing. This means that the decoder might be in a complete mute state or in another unknown state. If the music on hold or announcement is handled by a separate decoder instance the problem is normally limited, if on the other hand only one decoder instance is used then again severe state mismatch problems will often occur.</li></ul></li></ul>

p-0045The issue of only one decoder instance is especially important in cellular applications where the complexity and physical size issue is a key factor.

p-0046A basic idea according to an exemplary technology is to detect a potential state mismatch in the decoder during an on-going communication session, and reset the decoder to avoid the state mismatch, or at least reduce the distortion.

p-0047<figref idrefs="DRAWINGS">FIG. 5</figref> is a schematic flow diagram of a basic method according to an exemplary embodiment of the invention. The method is based on detecting a change in source of incoming media during an on-going communication session (S<b>1</b>). In response to such a detected change, decoder states of the decoder are reset before decoding new incoming media (S<b>2</b>). In this way, the state mismatch can be avoided, or the distortion may at least be reduced, without the need for several active decoder instances in the receiver. This leads to reduced media distortions when the decoded media is finally rendered, and also results in substantial savings with respect to overall complexity, memory usage and power consumption. In general, resetting the decoder means that the considered decoder states are set to some well-defined initialization states.

p-0048<figref idrefs="DRAWINGS">FIG. 6</figref> is a schematic block diagram primarily illustrating a receiver according to an exemplary embodiment of the invention. Basically, the incoming media may originate from several media sources, and a change in source may for example be a switch of media source, or the addition or removal of a media source from an existing media stream. The receiver <b>100</b> includes one or several buffers <b>110</b>, a decoder <b>120</b>, and a player <b>130</b>, as well as a detector <b>140</b>. The buffer(s) <b>110</b> such as a jitter buffer temporarily stores incoming data packets before they are sent to the decoder <b>120</b> for further processing. Variations in packet arrival time, so-called jitter, may occur because of network congestion, timing drift or route changes. A jitter buffer may then be used to equalize the delay variations by intentionally delaying arriving packets and forwarding the packets to the decoder in regular intervals. In this way, the end user experiences a clear connection with very little distortion. The detector <b>140</b> preferably monitors the incoming media stream, or the buffered media data, to detect a change in source of incoming media. Existing media frames in the buffer <b>110</b> are preferably successively output from the buffer, decoded and rendered, and the new media frames are buffered. The detector <b>140</b> then generates a reset signal for the decoder <b>120</b>. In response to the reset signal, the decoder <b>120</b> is reset to its initialization states before starting decoding and rendering the new media frames.

p-0049It is advantageous to monitor one or more packet header fields and detect a change in a packet field between packets in the incoming media data stream, to monitor the media payload using signal classification algorithms or water-marking techniques to detect a change in source, or to monitor explicit control signaling such as SIP signaling.

p-0050Examples of suitable detection mechanism include detecting a change in packet header fields such as the SSRC and/or CSRC fields in RTP streams, detecting a change in call-on-hold state, and detecting a change in media encoding between packets in the incoming media data. Other examples will be described below.

p-0051It should also be understood that re-initialization of the jitter buffer associated with the decoder (so-called re-buffering) may be considered as a particular form of resetting of the decoder.

p-0052A particular application of the invention is VoIP (Voice over IP) in MMTel systems, but the invention can also be used for video and general audio codecs. In particular it is desirable to ensure that supplementary services such as call announcements, call on hold, Explicit Call Transfer (ECT) or other supplementary services where the media source is changed are reconstructed without any distortions or at least with as small distortions as possible in the receiver. For example, the receiver may detect that an announcement comes from a different source than the normal media (from UE A) and take appropriate actions to minimize (or at least reduce) the distortions. The receiver may also detect a transfer to/from call on hold, Explicit Call Transfer or other similar services, indicating a change in source of incoming media.

p-0053As described above, it is important to handle the media properly in order to minimize any annoying distortions. The handling of the actions to reduce the distortions is primarily done in the receiving end.

Examples of Detection of State Reset Triggers.

p-0054There are several ways to detect that a reset of the decoder is necessary for instance due to the start and end of an announcement or other change in source. Some detection methods are reliable and rely on some kind of signaling. Other detection methods are less reliable because they require detecting some kind of characteristics.

p-0055Examples of reliable methods include: <ul><li id="ul0009-0001" num="0000"><ul><li id="ul0010-0001" num="0071">The RTP header contains an SSRC (synchronization source) field which includes a random number from the source. If the SSRC field is changed then the receiver knows that the source is different.</li><li id="ul0010-0002" num="0072">When the announcement media has ended, the SSRC value will switch back to the original SSRC value.</li><li id="ul0010-0003" num="0073">It is possible to have media from multiple sources in one RTP packet. In this case, there will be one SSRC field and one or several CSRC (contributing source) fields. The encoder X, which encodes the announcement media, may choose to add its media to the RTP packet from encoder A, which means that it will add a CSRC value. When SSRC and/or CSRC changes, the receiver knows that the added media comes from a different source.</li><li id="ul0010-0004" num="0074">When the announcement media has ended, the CSRC value will be removed from the subsequent RTP packets.</li><li id="ul0010-0005" num="0075">The media from encoder A and the announcement server may also be encoded differently. For example: The media from encoder A may use AMR-WB (wideband AMR) and the media from the encoder X may use AMR (narrowband AMR).</li><li id="ul0010-0006" num="0076">Different encoding is indicated by allocating different RTP Payload Types (PT) for the different configurations. This is also one reliable method to detect that the media comes from a different source.</li><li id="ul0010-0007" num="0077">When the media from encoder X has ended, the original codec format will be used for media from encoder A.</li><li id="ul0010-0008" num="0078">SIP signaling. In call on hold scenarios some of the parties will enter a send-only or receive-only state to later go back to a send-receive state. These transitions will then serve as an indication of a change in source.</li><li id="ul0010-0009" num="0079">The media originating from the announcement server may be detected using signal classification algorithms.</li><li id="ul0010-0010" num="0080">Some sort of announcement identifier can be included in the actual media using so-called media water-marking.</li><li id="ul0010-0011" num="0081">An announcement server may also send an explicit signal to inform the receiver that it has started and when it has ended sending announcement media. One possibility is to use the Talk Burst Control (TBC) signaling [8] defined for PoC (Push-to-talk over Cellular) [9].</li></ul></li></ul>

p-0056Examples of alternative methods include: <ul><li id="ul0011-0001" num="0000"><ul><li id="ul0012-0001" num="0083">The jitter characteristics will normally change when switching from media from encoder A to media from the encoder X since the encoder X resides in an announcement server. This is because the total jitter, perceived by the receiver, is the sum of the jitter over the uplink, the core network and the downlink. And when the media is sent from the announcement server the jitter from the uplink is not applicable since the media is not sent over this air interface.</li><li id="ul0012-0002" num="0084">For similar reasons, one can also expect that the packet loss characteristics change.</li></ul></li></ul>

p-0057<figref idrefs="DRAWINGS">FIG. 7</figref> is a schematic flow diagram of a method according to another exemplary embodiment of the invention. In this particular example, a change in media source during an on-going session is first detected (S<b>11</b>), and then existing media in the jitter buffer is decoded and played-out (S<b>12</b>). Optionally, the jitter buffer is re-initialized (S<b>13</b>). Media data from the new source is stored in the jitter buffer (S<b>14</b>). In response to the detection of a change in source, the decoder states are reset (S<b>15</b>) before decoding new media. Finally, the new media is decoded and played-out (S<b>16</b>).

p-0058<figref idrefs="DRAWINGS">FIG. 8</figref> is a schematic block diagram primarily illustrating a receiver according to a further exemplary embodiment of the invention, similar to that of <figref idrefs="DRAWINGS">FIG. 6</figref>. In this particular example, however, the receiver <b>100</b> further comprises a unit <b>150</b> for re-initializing the jitter buffer(s). In addition, the player <b>130</b> is implemented as a more flexible and general rendering module, including optional functions such as fading, time-scaling and bandwidth extension and so forth for providing a smooth transition between media from different sources.

p-0059In the following, exemplary embodiments of the invention relating to actions when announcements or call on hold are detected will be described with exemplary reference to <figref idrefs="DRAWINGS">FIG. 9</figref>.

p-0060Upon detecting (S<b>21</b>) that the announcement media is received, or call on hold state is changed, examples of actions of the receiving entity (UE) include: <ul><li id="ul0013-0001" num="0000"><ul><li id="ul0014-0001" num="0089">Play-out or finalize (S<b>22</b>) the existing media frames from encoder A in the jitter buffer as soon as possible and buffer the announcement media (S<b>24</b>).</li><li id="ul0014-0002" num="0090">The receiver may use time scaling in order to speed up the play-out of the media from encoder A.</li><li id="ul0014-0003" num="0091">Before starting generating the announcement media, the decoder should be reset to the initialization states (S<b>25</b>). Once the decoder is reset, decoding of the new media can be initiated (S<b>26</b>).</li><li id="ul0014-0004" num="0092">Re-initialize (S<b>23</b>) the jitter buffer (so called re-buffering).</li><li id="ul0014-0005" num="0093">If the media encoded by encoder X is announcement media, it is not really real-time (real-time requirements don't apply to pre-recorded media) The receiver may buffer up more media in the jitter buffer before starting the play-out, thereby reducing the risk of late losses.</li><li id="ul0014-0006" num="0094">The play-out of the media from encoder A should preferably use fade-out (reduce the volume gradually from the used (normal) volume to zero). The receiver should preferably use fade-in (increase the volume gradually from zero to the normal volume) for the announcement media (S<b>28</b>).</li><li id="ul0014-0007" num="0095">The receiver can also monitor the regenerated signal before it is played out in order to detect any spikes so that they can be muted.</li><li id="ul0014-0008" num="0096">Upon detecting that the speech media from encoder A and the announcement media use different acoustic bandwidths, for example encoded by AMR-WB (50-7000 Hz) and AMR (300-3400 Hz) respectively, the receiver should preferably use bandwidth extension (wideband extension) in order to produce a smooth transition (S<b>27</b>). Other similar procedures for providing a smooth transition between different media can also be envisaged for audio and video.</li></ul></li></ul>

p-0061When there is no more announcement media being received, examples of actions of the receiving entity (UE) include: <ul><li id="ul0015-0001" num="0000"><ul><li id="ul0016-0001" num="0098">Play-out any announcement media still existing in the jitter buffer as soon as possible (S<b>22</b>).</li><li id="ul0016-0002" num="0099">The receiver may use time scaling to speed up the play-out of the remaining announcement media.</li><li id="ul0016-0003" num="0100">Reset the decoder before playing out media from encoder A (S<b>25</b>).</li><li id="ul0016-0004" num="0101">Re-initialize the jitter buffer (re-buffering) (S<b>23</b>). This is especially important since there will normally be less jitter on the RTP packets from encoder X if it resides in a box in the network such as an announcement server than from encoder A, which means that the jitter buffer normally has adapted to a lower buffering level than it used for the RTP packets from encoder A. And then when switching back to the media from encoder A, the jitter buffer does not contain enough data to cope with the larger jitter that can be expected for the media from encoder A.</li><li id="ul0016-0005" num="0102">A possible modification is to store the jitter buffer target level and adaptation states before switching to the announcement media and re-initialize the jitter buffer adaptation with the level and the states.</li></ul></li></ul>

p-0062As previously described, the sending side may enforce a decoder reset on the receiving side in preparation of media from a new source by sending a predefined signal pattern. This means that during an on-going communication session involving reception of media from a first media source the receiver will receive a predefined signal pattern in preparation of subsequent reception of media from a second different media source. The decoder will then be reset in response to the predefined signal pattern before initiating decoding of media from the second media source. For example, upon switching back from a call on hold state the sending entity (UE) may transmit a codec homing frame or similar signal pattern (even a number of empty frames) and thereby enforce a decoder reset in the receiver.

p-0063Exemplary advantages of the invention: <ul><li id="ul0017-0001" num="0000"><ul><li id="ul0018-0001" num="0105">Distortions due to switching between media sources, addition and/or deletion of media sources are reduced and may even be completely removed. This gives a more pleasant transition between the media, e.g. when an announcement has to be generated for the receiving user.</li><li id="ul0018-0002" num="0106">There is also a complexity advantage, both MIPS and memory, in the UE since the UE does not have to have several active codec instances executing in parallel.</li></ul></li></ul>

p-0064The embodiments described above are merely given as examples, and it should be understood that the present invention is not limited thereto. Further modifications, changes and improvements which retain the basic underlying principles disclosed and claimed herein are within the scope of the invention.

ABBREVIATIONS

ADPCM Adaptive Differential PCM

AMR Adaptive Multi-Rate

AMR-WB AMR-WideBand

CSRC Contributing Source

DTX Discontinuous Transmission

ECT Explicit Call Transfer

EVRC Enhanced Variable Rate Codec

IMS IP Multimedia Subsystem

IP Internet Protocol

MIPS Million Instructions Per Second

MMTel Multi Media Telephony

PCM Pulse Code Modulation

p-0065PoC Push-to-talk over Cellular

RTP Real-Time Protocol

SID Silence Descriptor

SIP Session Initiation Protocol

SSRC Synchronization Source

TBC Talk-Burst Control

UE User Equipment

p-0066VoIP Voice over IP

REFERENCES

p-0067<ul><li id="ul0019-0001" num="0110">[1] 3GPP TS 23.228, “IP Multimedia Subsystem (IMS), Stage 2”.</li><li id="ul0019-0002" num="0111">[2] 3GPP TS 26.114. “IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction”.</li><li id="ul0019-0003" num="0112">[3] RFC 3550, “RTP: A Transport Protocol for Real-Time Applications”, H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson.</li><li id="ul0019-0004" num="0113">[4] ITU-T Recommendation G.711, “Pulse Code Modulation (PCM) of Voice Frequencies”.</li><li id="ul0019-0005" num="0114">[5] ITU-T Recommendation G.726, “40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM)”.</li><li id="ul0019-0006" num="0115">[6] 3GPP TS 26.071, “Mandatory Speech Codec speech processing functions; AMR Speech CODEC; General description”.</li><li id="ul0019-0007" num="0116">[7] 3GPP TS 26.171, “Speech codec speech processing functions; Adaptive Multi-Rate—Wideband (AMR-WB) speech codec; General description”.</li><li id="ul0019-0008" num="0117">[8] Open Mobile Alliance, “PoC User Plane”, Candidate Version 1.0—27 Jan. 2006, Chapter 6.5.</li><li id="ul0019-0009" num="0118">[9] Open Mobile Alliance, “OMA PoC System Description”, Draft Version 2.0—21 Jun. 2006.</li></ul>