VoIP Shim for RTP Payload Formats
draft-johansson-avt-rtp-shim-01
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Ingemar Johansson | ||
| Last updated | 2006-10-23 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
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. 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".
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)