Network Working Group I. Johansson Internet-Draft Ericsson AB Intended status: Experimental August 22, 2006 Expires: February 23, 2007 VoIP Shim for RTP Payload Formats draft-johansson-avt-rtp-shim-00 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 February 23, 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. The main application is for two party teleconferencing, The presented Johansson Expires February 23, 2007 [Page 1] Internet-Draft VoIP Shim for RTP August 2006 mechanism is not recommended to be used for multi party teleconferencing applications. 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] Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Multi party teleconferencing . . . . . . . . . . . . . . . 3 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Adaptation procedure for Voice (AMR) . . . . . . . . . . . 3 2.1.1. Downwards adaptation . . . . . . . . . . . . . . . . . 4 2.1.2. Upwards adaptation . . . . . . . . . . . . . . . . . . 5 3. Packet Design . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. The Shim blocks . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Basic Shim block . . . . . . . . . . . . . . . . . . . 6 3.1.2. NULL shim . . . . . . . . . . . . . . . . . . . . . . 6 3.1.3. Short requests . . . . . . . . . . . . . . . . . . . . 7 3.1.4. Future extension Shim . . . . . . . . . . . . . . . . 8 4. SDP considerations . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Johansson Expires February 23, 2007 [Page 2] Internet-Draft VoIP Shim for RTP August 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 inband signaling for VoIP where the demands of compact inband signaling is high especially for wireless links. 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. This applies especially to cases where IP/UDP/ RTP headers are efficiently compressed by e.g RoHC [RFC3095], while RTCP is not compressed at all. Additionally it is possible that RTCP will be suppressed in VoIP flows, the only method to send feedback information then is by means of inband signaling such as outlined in the proposed schema. In the case of Video transmission the bitrate is considerably higher and the size of the RTCP is not a big issue, for these cases e.g http://tools.ietf.org/wg/avt/draft-wenger-avt-avpf-ccm-04.txt is a better alternative 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 but complications may occur if RTP streams are e.g multiplexed in e.g a mixer as it might be difficult to combine different requests with simple rules, also it is not possible to distinguish the origin of the different metrics. 2. 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. 2.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 Johansson Expires February 23, 2007 [Page 3] Internet-Draft VoIP Shim for RTP August 2006 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. 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 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. 2.1.1. Downwards adaptation In case packet loss >= X% (typically 5%): 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 conclude 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. 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 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%. Johansson Expires February 23, 2007 [Page 4] Internet-Draft VoIP Shim for RTP August 2006 2.1.2. Upwards adaptation In case packet loss < Y% (typically 2%): 1a) If redundancy is used, the redundancy is turned off and the codec rate is increased. 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 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. The trick here is probably to see the correlation between increasing the bitrate and an increase in packet loss. Note that upwards adaptation only occur if a downwards adaptation has taken place earlier. Note 2: 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% 3. Packet Design The Shim is implemented as a field with a few bytes of additional bytes of inband signaling data (Shim blocks) between the RTP header and the RTP payload. The Shim is a format in witch the length of the Shim blocks are 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 that duplicate Shims blocks with the same ID-type is not allowed. This is to avoid confusion in the receiving end and also to keep the total size of the Shim blocks as small as possible. The Shim is put in between the RTP header (after possible header extension) and the payload as follows: Johansson Expires February 23, 2007 [Page 5] Internet-Draft VoIP Shim for RTP August 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 | +-----------------------------------------------+ | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. The following section indicates that it is possible to specify other Shim blocks. These are however not specified yet. 3.1. The Shim blocks 3.1.1. Basic Shim block The basic Shim block looks like below. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F| ID |x x x x| +-+-+-+-+-+-+-+-+ F : Follow flag, 1 indicates that one or more Shim blocks follow this block. ID : An ID-type of the Shim data 3.1.2. NULL shim SHIM_NULL : Null Shim 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 Johansson Expires February 23, 2007 [Page 6] Internet-Draft VoIP Shim for RTP August 2006 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 to specify two payload types for the same RTP stream, 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.3. Short requests ID F000xxxx..F110xxxx are used for sending short requests that are no longer than 1 octet. 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. 3.1.3.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 Johansson Expires February 23, 2007 [Page 7] Internet-Draft VoIP Shim for RTP August 2006 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 space, this of course increases delay but is preferable over the degradation caused by the frame losses. 3.1.3.2. SHIM_REQ_RED_SDP : Request for redundancy with bitmask specified in SDP. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F|0 1 0| DATA | +-+-+-+-+-+-+-+-+ As SHIM_RED but interpretation of DATA is specified in SPD 3.1.3.3. SHIM_REQ_AGG : Request frame aggregation. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F|0 1 1| 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 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. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|1 1 1| LEN | DATA (1 to 16 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 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. 4. SDP considerations SDP signaling should verify that all parts support Shim Johansson Expires February 23, 2007 [Page 8] Internet-Draft VoIP Shim for RTP August 2006 5. IANA Considerations To be able to use the functionality defined by this document with specific payload formats, new MIME subtypes have to be registered. 6. Security Considerations This shim layer implies no additional security concerns than for any RTP payload format. 7. Acknowledgements The authors would like to thank all the people who gave feedback on this document. 8. 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. Johansson Expires February 23, 2007 [Page 9] Internet-Draft VoIP Shim for RTP August 2006 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 February 23, 2007 [Page 10] Internet-Draft VoIP Shim for RTP August 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 February 23, 2007 [Page 11]