Network Working Group I. Johansson Internet-Draft Ericsson AB Intended status: Experimental October 22, 2006 Expires: April 25, 2007 VoIP Shim for RTP Payload Formats draft-johansson-avt-rtp-shim-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 25, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document provides a general mechanism to provide with compact and efficient inband signaling mechanisms for VoIP applications using the RTP (Real-Time Transport Protocol). It provides the option to include a few additional inband signaling bytes in between the RTP header and the RTP payload. The intention of using Shim is to enable a fast inband signaling channel that can be used for adaptation purposes. Johansson Expires April 25, 2007 [Page 1] Internet-Draft VoIP Shim for RTP October 2006 The intention of the proposed inband signaling is that it should act as a wrapper around the actual payload. For instance if the payload is AMR-NB (RFC 3267), shim will encapsulate the payload in a fashion similar to RCF2198. In order to distinguish this encapsulated payload from a "normal" payload, necessary attributes are specified in SDP. The main application is for two party teleconferencing but the presented mechanism can be used for multi party teleconferencing applications as well. The name Shim is to refer to the "little thing something that one put in between". The name Shim is to refer to the "little thing something that one put in between". Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] Johansson Expires April 25, 2007 [Page 2] Internet-Draft VoIP Shim for RTP October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Multi party teleconferencing . . . . . . . . . . . . . . . 4 2. Motivation for inband signaling . . . . . . . . . . . . . . . 4 2.1. Problems with RTCP . . . . . . . . . . . . . . . . . . . . 5 2.2. Inband signaling . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Use of RTP extension bit . . . . . . . . . . . . . . . 5 2.2.2. Shim inband signaling . . . . . . . . . . . . . . . . 6 3. Packet Design . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. The Shim messages . . . . . . . . . . . . . . . . . . . . 7 3.1.1. NULL shim . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2. Short requests . . . . . . . . . . . . . . . . . . . . 8 3.1.3. Acknowledge shim . . . . . . . . . . . . . . . . . . . 9 3.1.4. Future extension Shim . . . . . . . . . . . . . . . . 10 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Adaptation procedure for Voice (AMR) . . . . . . . . . . . 11 5.1.1. Downwards adaptation . . . . . . . . . . . . . . . . . 12 5.1.2. Upwards adaptation . . . . . . . . . . . . . . . . . . 12 5.2. Practical implementation considerations . . . . . . . . . 13 6. SDP considerations . . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 10. Normative References . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Johansson Expires April 25, 2007 [Page 3] Internet-Draft VoIP Shim for RTP October 2006 1. Introduction The objective of the Shim mechanism is to include additional inband data in the RTP packets in VoIP applications. The main application is to provide with a fast and efficient and robust inband signaling for VoIP where the demands of compact inband signaling is high especially for wireless links. In the proposed schema the inband signaling is used to transmit various requests that are important in order to enable adaptation and thus make a VoIP application robust to varying channel conditions. Although the obvious is to base the requests on features that can be measured on application layer (packet loss, jitter). It is perfectly possible to use lower layer features if they are available. Shim is by no means seen as something that should replace RTCP, instead Shim should be regarded as a fast, high efficiency inband signaling format especially tailored for VoIP where RTCP might otherwise constitute a too large amount of the total bitrate in the transmission channel or simply put may not be transmitted with enough robustness to be useful for adaptation. This applies especially to cases where IP/UDP/RTP headers are efficiently compressed by e.g RoHC [RFC3095], while RTCP is at its best only compressed on UDP level. Additionally it is possible that RTCP will be suppressed in VoIP flows as the RTCP bandwidth may be set to zero, the only method to send feedback information then is by means of inband signaling such as outlined in the proposed schema. 1.1. Multi party teleconferencing The presented mechanism is mainly intended for two party teleconferencing. It is possible to use Shim in multi party teleconferencing as well especially for those cases where conference bridges are implemented as mixing devices where the audio streams are mixed on sample (PCM) level, Shim inband signaling is then relatively easy to implement as each leg between the conference bridge and the clients is to be regarded as a point to point connection. In multi party conference bridges where RTP streams are e.g multiplexed in a mixer without transcoding, policing of the Shim messages will be necessary in order to avoid confusing requests. 2. Motivation for inband signaling Johansson Expires April 25, 2007 [Page 4] Internet-Draft VoIP Shim for RTP October 2006 2.1. Problems with RTCP RTCP is regarded as the obvious alternative when it comes to the question as to how control information for e.g adaptation purposes is to be transmitted between two peers in a point to point VoIP call. One problem with RTCP is that the packets are quite bulky. A typical RTCP-SR packet is at least 82bytes with IPv4 header and even with transmission over RoHC compressed links the compressed RTCP packets are still about 55bytes or larger. Such large packets are very likely to become segmented over highly VoIP optimized radio links such as those standardized in 3GPP for HSPA or GERAN-EDGE. This is normally not a problem if the system load is low and the coverage is good. Problems arise however when the radio conditions degrade or a hand held terminal user moves to towards the edge of the network coverage. In the above mentioned bad conditions the probability of successful transmission of a packet is inversely proportional to the size of the packet. This means that in some cases RTCP packets might be lost while most of the RTP packets arrive successfully at the receiver. The risk of placket loss is also increased due to the fact that RTCP packets are likely to become segmented. 2.2. Inband signaling There are at least two different methods possible to achieve inband signaling in the RTP flows. 2.2.1. Use of RTP extension bit The option to use the RTP extension bit is presented in http://tools.ietf.org/wg/avt/draft-ietf-avt-rtp-hdrext/ draft-ietf-avt-rtp-hdrext-06.txt It is in practice possible to transport the Shim bytes presented in this draft in the RTP header extension field presented above. The minimum overhead is 8 bytes even though only one byte actual inband signaling information is transmitted. The 7 bytes added overhead compared to the schema proposed in this draft means in practice that the codec rate needs to be reduced by 1.4kbps in a typical VoIP application in order to reach the same total bitrate. Switching of the extension bit value in the RTP header has some consequences in RoHC compressed links. As a typical example the additional RoHC overhead is 4 bytes for 3 consecutive packets. This additional overhead + the 8 byte overhead is enough to cause Johansson Expires April 25, 2007 [Page 5] Internet-Draft VoIP Shim for RTP October 2006 segmentation in VoIP optimized radio bearers specified in 3GPP with the increased risk that these packets are lost. 2.2.2. Shim inband signaling The inband signaling proposed in this draft is designed to be as compact as possible. The proposed schema is intended for application layer adaptation for VoIP. The inband signaling can be seen as a wrapper around an already specified payload format (e.g RFC3267), this makes it a new payload format, additionally one can look at the concept in the view of RFC2198 with the modifications that the block PT, timestamp offset and block fields are omitted. The original payload is then specified as one payload type in SDP (e.g PT=97). Another payload type is also specified that contain Shim + the original payload (PT=98) When the application wish to transmit inband signaling it simply switches from the original payload (PT=97) to the payload containing the Shim + original payload (PT=98), after the inband signaling is transmitted the payload type is switched back to PT=97. It is also possible to always transmit PT=98, the overhead is then one byte compared to the original payload. Switching of payload type in the RTP header means in RoHC compressed links that the RoHC overhead will be increased temporarily, a typical example is that the RoHC header increase is 4 bytes for 3 consecutive packets. One method to avoid this change of payload type is to always use the payload type that corresponds to Shim + payload above and accept the continuous 1 byte overhead that this cause. 3. Packet Design The Shim is implemented as a field with a few bytes of additional bytes of inband signaling data (Shim messages) between the RTP header and the RTP payload. The Shim is a format in which the length of the Shim messages is self contained. The minimum size of the Shim is 1 octet, the maximum size is given by the largest allowed size of the RTP packet. Important to note is that duplicate Shims messages with the same ID-type is not allowed (except for SHIM_EXT). This is to avoid confusion in the receiving end and also to keep the total size of the Shim messages as small as possible. The Shim is put in between the RTP header (after possible header extension) and the payload as follows: Below a typical RTP packet with Shim inserted between RTP header and payload Johansson Expires April 25, 2007 [Page 6] Internet-Draft VoIP Shim for RTP October 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Shim (variable length, byte aligned) | payload | +-----------------------------------------------+ | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Shim messages are typically in the form of requests. It is up to the receiver to follow the requests, in some cases the receiver might not want to follow a request for redundant transmission if it for instance discovers that the transmission bandwidth is not high enough. As some requests may not be followed, precaution must be taken to ensure that the issuer of the requests does not continue to send the requests as this only means a waste of bandwidth, therefore a limit of a predetermined number of failed requests must be applied. The following section indicates that it is possible to specify other Shim messages. These are however not specified yet. 3.1. The Shim messages The basic Shim message looks like below. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+ |F| ID | ---------- +-+-+-+-+-+-+-+-+-+-+-+ F : Follow flag, 1 indicates that one or more Shim messages follow this block. ID : An ID-type of the Shim data 3.1.1. NULL shim SHIM_NULL : Null Shim Johansson Expires April 25, 2007 [Page 7] Internet-Draft VoIP Shim for RTP October 2006 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |0|0 0 0|0 0 0 0| +-+-+-+-+-+-+-+-+ This is the minimum overhead of the Shim. If no inband signaling is transmitted this NULL Shim acts as a token that makes it possible to signal simply that no Shim is present. NULL Shim is not used in packets where actual Shim is transmitted. This NULL Shim will cause a continuous overhead of 1 octet regardless if Shim is transmitted or not. A method to avoid the continuous 1 byte overhead is (as already mentioned before) to specify two payload types for the same RTP stream as specified before, one that contains Shim and one that does not contain Shim. If Shim need to be transmitted the payload type is temporarily switched to the payload type that supports Shim. 3.1.2. Short requests ID F000xxxx..F101xxxx are used for sending short requests that are no longer than 1 octet. 3.1.2.1. SHIM_REQ_RED : Request for redundancy level and offset of redundant data. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F|0 0 1| DATA | +-+-+-+-+-+-+-+-+ DATA field can have the following values Syntax: RROO RR : redundancy level RR = 00 -> No redundancy RR = 01 -> 100% redundancy RR = 10 -> 200% redundancy RR = 11 -> 300% redundancy OO : Offset of redundant data OO = 00 redundant data in next packet OO = 01 redundant data 2 packets later OO = 10 redundant data 3 packets later OO = 11 redundant data 4 packets later The RR and OO values are limited by the max redundancy and max offset defined in SDP. Motivation for OO: Some transmission paths might in severe cases have a very bursty packet loss behavior with multiple packet losses. It might therefore be necessary to transmit redundant data with more Johansson Expires April 25, 2007 [Page 8] Internet-Draft VoIP Shim for RTP October 2006 space, this of course increases delay but is preferable over the degradation caused by the frame losses. 3.1.2.2. SHIM_REQ_AGG : Request frame aggregation. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F|0 1 0| DATA | +-+-+-+-+-+-+-+-+ DATA field can have the following values: 0000 -> 1 frame / packet 0001 -> 2 frames / packet 0010 -> 3 frames / packet 0011 -> 4 frames / packet .. 1111 -> 15 frames / packet The SHIM_REQ_AGG requests are limited by the max and min frames/ packet defined in SDP. 3.1.2.3. SHIM_CMR : Codec mode request. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F|0 1 1| CMR | +-+-+-+-+-+-+-+-+ The CMR field is 4 bits that are used for codec mode requests, the interpretation of the bits are specified by the application at session setup. 3.1.3. Acknowledge shim SHIM_ACK : Acknowledge Shim 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|1 1 0|a b c d| SN % 256 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ abcd pattern: The pattern is an OR bitmask defining which part(s) of the received shim was ACK'ed or rejected. The received Shim messaged subject to the ACK message are numbered 1 to 4 with 1 being the first Shim message in the Shim field or the first Shim message after a possible ACK message. a bit : If "0", Shim message 1 was NACK'ed, if "1" it was ACK'ed b bit : If "0", Shim message 2 was NACK'ed, if "1" it was ACK'ed c bit : If "0", Shim message 3 was NACK'ed, if "1" it was ACK'ed d bit : If "0", Shim message 4 was NACK'ed, if "1" it was ACK'ed SN % 256 - RTP sequence number Modulo 256 of the received Shim. Johansson Expires April 25, 2007 [Page 9] Internet-Draft VoIP Shim for RTP October 2006 The ACKnowledge Shim is used to acknowledge (ACK) (or not acknowledge, NACK) one or more received Shim fields. Up to four Shim fields may be handled in this message. A SHIM_ACK is always transmitted first and only one SHIM_ACK is permitted in the packet. Note that a received SHIM_ACK is not acknowledged. It is not necessary to use the SHIM_ACK as it is possible to verify that Shim messages are followed by means of inspection of the received RTP flow. 3.1.4. Future extension Shim In order to make parsing of future extensions of Shim safe a future extension Shim is provided. The interpretation of the DATA field is not specified here. A parser that does not support future extensions should read past this Shim block and ignore the contents. SHIM_EXT: Future extension Shim 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|1 1 1| LEN | EXT.ID | DATA (1 to 16 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- EXT.ID Extended ID field. LEN field specifies the length of the data LEN=0000 equals 1 byte of data that follows. LEN=0001 equals 2 bytes of data that follows. .. LEN=1111 equals 16 bytes of data that follows. The EXT.ID field is defined by the application. 4. Examples In this section a few examples of Shim inband signaling is given (currently only 1 example). For easier readability only the Shim part of the RTP packets is displayed in the examples. The signaling is assumed to be between two endpoints (A and B), 4.1. Example 1 In this example a request for frame aggregation 2 frames/packet and 100% redundancy is set from B to A. This means that at SHIM_REQ_AGG is followed by a SHIM_REQ_RED. Shim will then look like below. The Shim is transmitted in a packet with sequence number 127. Johansson Expires April 25, 2007 [Page 10] Internet-Draft VoIP Shim for RTP October 2006 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0 1 0|0 0 1 0|0|0 0 1|0 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SHIM_REQ_AGG | SHIM_REQ_RED | Note that the Follow bit of the first Shim message is "1" while it is "0" for the second Shim message. Receiver A parses this, it is found of that the request for frame aggregation can be accepted. The request for redundancy is not accepted however. An ACK is sent back to B, also is sent a SHIM_REQ_AGG in the same packet. The sequence number of the packet containing the Shim is 130. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1 1 0|1 0 0 0|0 1 1 1 1 1 1 1|0|0 1 0|0 0 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SHIM_ACK | SHIM_REQ_AGG | Receiver B parses this, it is found of that the request for frame aggregation can be accepted. An ACK is sent back to A. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1 1 0|1 0 0 0|1 0 0 0 0 0 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SHIM_ACK | 5. Use Cases This example tries to highlight how the Shim signaling can be used in a VoIP session. The example is just an example, there exist a multitude of other ways to implement similar functionality. 5.1. Adaptation procedure for Voice (AMR) In order for a Voice service to behave well for all channel conditions it will be necessary to use adaptation. For the AMR-NB and AMR-WB codecs it is possible seamlessly reduce the codec bitrate if the channel conditions degrade. This is supported by means of the CMR bits in RFC3267, and is also possible to achieve by means of SHIM_CMR. Reducing the codec rate during poor transmission channel conditions might be sufficient e.g if the transport channel has a wireless hop where the packets are transmitted in blocks and the amount of error resilience is largest for the smallest transmission blocks. Examples Johansson Expires April 25, 2007 [Page 11] Internet-Draft VoIP Shim for RTP October 2006 of such wireless hops are GERAN-EDGE. Another condition where this might work is congestion. For other transmission channels this might not be the case and here it will be necessary to turn on redundancy besides lowering the codec bitrate. Other cases exist where it is simply put no gain to go down in bitrate. As it is generally not possible from an application perspective to know what transmission technologies are used on lower layers the method below is proposed to be used. 5.1.1. Downwards adaptation In case packet loss >= X% (typically 3%): 1) Reduce codec bitrate (optionally also reduce packet rate). For instance if the codec bitrate was 12.2kbps the bitrate is reduced to 6.7kbps. 2) Wait for some time (2-4sec, random value) to determine if the packet loss has decreased. 3) If the packet loss does not decrease, redundancy is turned on (optionally frame aggregation can also be increased to reduce the packet rate). This is performed by means of Shim inband signaling. NOTE that redundancy is not allowed if the total payload size exceeds the original payload size by Y% (10-20%). For instance it is not possible to use redundancy with 2*4.75kbps if the original bitrate (or maximum bitrate) specified in SDP was 5.9kbps. It is however possible to use redundancy with 2*6.7kbps if the original bitrate was 12.2kbps as the increase in bitrate is quite modest. If the packet loss increases to an amount where it is worse than without redundancy, redundancy is turned off and disabled throughout the session. 4) If it was concluded that redundancy is needed (improves quality) there is no need to do step 2 during the rest of the session, instead a lower codec bitrate in combination with redundancy (if allowed, see above) is always used when packet loss > X%. 5.1.2. Upwards adaptation In case packet loss < Y% (typically 1%): 1a) If redundancy is used, the redundancy is turned off and the codec rate is increased. Johansson Expires April 25, 2007 [Page 12] Internet-Draft VoIP Shim for RTP October 2006 1b) If no redundancy is used (not turned on above), the bitrate is increased to the original bitrate. Optionally it is here possible to use probed redundancy with the reduced bitrate and increase the codec bitrate to the original bitrate if the action was successful i,e the packet loss did not increase. In case 1b it may be possible that the packet loss rate increases, in order to avoid an oscillating behavior in the packet loss behavior in this case a maximum of 3 attempts are done to increase the bitrate, after this the bitrate is kept at the lower bitrate throughout the session. Note that upwards adaptation only occur if a downwards adaptation has taken place earlier. Note also: It may be necessary to introduce a hysteresis in the thresholds for downwards/upwards adaptation. As an example downwards adaptation occurs when packet loss is above 3% and upwards adaptation occur when packet loss is less than 1% 5.2. Practical implementation considerations There are a number of ways to implement the signaling. The requests can be followed or simply discarded by the receiving end. The sender will monitor the received packet flow to see if the requests have been followed. If the request has not been followed within 2 round trip times a new similar request is transmitted again, unless an different request of the same ID-type is being transmitted. After two unsuccessful trials the particular request is disabled. In order to make transmission of requests more robust the same request is transmitted two or three times in two or three consecutive packets. The specifics are more implementation issues. For instance it is possible to take SHIM_REQ_RED into account when determining show the Shim's should be transmitted, in case the other end has requested that redundancy is transmitted with an offset of two packets it might be wise to transmit Shim in the same manner. 6. SDP considerations SDP signaling should verify that all parts support Shim, below is an outline of an SDP offer/answer. An example of an SDP offer is given below Johansson Expires April 25, 2007 [Page 13] Internet-Draft VoIP Shim for RTP October 2006 ============================== m=audio 49152 RTP/AVP 98 97 a=rtpmap:98 signalling-shim/8000/1 a=fmtp:98 orig-pt=97 a=rtpmap:97 AMR-NB/8000/1 a=fmtp:97 mode-change-capability=2 a=ptime:20 a=maxptime:240 ============================== Two payloads are offered, one that corresponds to AMR as specified in RFC3267 (PT=97), the other that contains Shim aswell (PT=98). The corresponding SDP answer my look like below. ============================== m=audio 49152 RTP/AVP 97 98 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-set=0,2,4,7; mode-change-period=2;\ mode-change-neighbor=1; mode-change-capability=2 a=rtpmap:98 signalling-shim/8000/1 a=fmtp:98 orig-pt=97 max-red=1; max-red-offset=1;\ min-frame-aggregation=2;max-frame-aggregation=1 a=ptime:20 a=maxptime:80 ============================== Both payload types are offered which means that it is possible to switch between the two payload types at whim. Another response may look like below if Shim is not allowed. ============================== m=audio 49152 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-set=0,2,4,7; mode-change-period=2;\ mode-change-neighbor=1; mode-change-capability=2 a=ptime:20 a=maxptime:80 ============================== 7. IANA Considerations To be able to use the functionality defined by this document with specific payload formats, new MIME subtypes have to be registered. 8. Security Considerations This shim layer implies no additional security concerns than for any Johansson Expires April 25, 2007 [Page 14] Internet-Draft VoIP Shim for RTP October 2006 RTP payload format. 9. Acknowledgements The authors would like to thank all the people who gave feedback on this document. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [RFC3267] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. Author's Address Ingemar Johansson Ericsson AB Laboratoriegrand 11 SE-971 28 Lulea SWEDEN Phone: +46 73 7083289 Email: ingemar.s.johansson (AT) ericsson.com Johansson Expires April 25, 2007 [Page 15] Internet-Draft VoIP Shim for RTP October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Johansson Expires April 25, 2007 [Page 16]