Telefona IP Real Time Protocol RTP

RTP: Real Time Protocol

Protocolo que permite el transporte de MEDIA (voz/video) en tiempo real sobre

redes IP Descrito en RFC 1889 / RFC 3550 Va acompaado de un protocolo denominado RTCP , Real Time Control Protocol RTP permite enumerar los paquetes IP lo que permite detectar perdida de paquetes y ordenar los paquetes en el endpoint receptor RTP/RTCP operan sobre UDP

RTP Payload Type: Audio

Payload type 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 Encoding name PCMU Reserved G726-32 GSM G723 DVI4 DVI4 LPC PCMA G722 L16 L16 QCELP Reserved MPA G728 DVI4 DVI4 G729 Media type Audio Audio Audio Audio Audio Audio Audio Audio Audio Audio Audio Audio Audio Audio Audio Audio Audio Audio Clock rate (Hz) 8,000 8,000 8,000 8,000 8,000 16,000 8,000 8,000 8,000 44,100 44,100 8,000 90,000 8,000 11,025 22,050 8,000 Channels 1 1 1 1 1 1 1 1 1 2 1 1 1 1 1 1 1 1

RTP Payload Type: Video

Payload type Encoding name Media type Clock rate (Hz)

24 25 26 27 28 29 30 31 32 33 34 3571 7276 7795 96127 Dyn Dyn

Unassigned CelB JPEG Unassigned nv Unassigned Unassigned H261 MPV MP2T H263 Unassigned Reserved Unassigned Dynamic BT656 H263-1998

Video Video Video Video Video Video Video Video Video Audio/video Video

90,000 90,000 90,000

90,000 90,000 90,000 90,000

Video Video

90,000 90,000

CODECS
Codec Information
Codec and Bit Rate Codec Sample Size G.711 (64Kbps) G.729 (8 Kbps) G.723.1 (6.3 Kbps) G.723.1 (5.3 Kbps) 80 bytes 10 bytes 24 bytes 20 bytes 4.1 3.92 3.9 3.8 160 Bytes 20 Bytes 24 Bytes 20 Bytes

Bandwidth Calculations
MOS Voice Payload Size Voice Payload Size PPS Bandwidth Ethernet Kbps 20 ms 20 ms 30 ms 30 ms 50 50 34 34 87.2 Kbps 31.2 Kbps 21.9 Kbps 20.8 Kbps

Bandwidth= total packet size * PPS PPS= (codec bit rate)/(voice payload size) Total Packet Size= (L2 header: Ethernet)+(IP/UDP/RTP Header)+(voice Payload) Etehernet header= 18 bytes IP/UDP/RTP Header= (20 + 8 + 12)= 40 bytes

RTP Header

RTP Header
The RTP Header As mentioned, RTP carries the actual encoded voice. What this means is that one or more digitally coded samples make up the RTP payload.An RTP header is attached to this payload and the packet is sent to UDP. The RTP header includes information necessary for the destination application to reconstruct the original voice sample (at least to as close a match as is enabled by the coding scheme used). The meanings of the various header fields are as follows: Version (V) This field should be set to the value 2, which is the current version of RTP. Padding (P) This field is comprised of one bit and indicates whether the packet contains one or more padding octets at the end of the payload. Because of the fact that the payload needs to align with a 32- bit boundary, it is possible that the end of the payload contains padding to align with the boundary. If such padding exists, then the P bit is set and the last octet of the padding contains a count of how many padding octets are included. Of course, such padding octets should be ignored. Extension (X) This field is comprised of one bit and indicates whether the fixed header, as shown in Figure, contains a header extension. If this bit is set, then the header is followed by exactly one header extension, as described later and with the format shown in Figure 2-13. CSRC Count (CC) The CC uses a four-bit field indicating the number of contributing source identifiers included in the header and takes a value of 0 to 15. Refer to Contributing Source Identifiers described later

RTP Header
Marker (M) The marker is a one-bit field, the interpretation of which is dependent upon the payload being carried. RFC 1889 does not mandate any specific use of this bit, but RFC 1890 (audio-video profile) does. RFC 1890 states that, for an application that does not send packets during periods of silence, this bit should be set in the first packet after a period of silence . Applications that do not support silence suppression should not set this bit. Payload Type (PT) This field comprises seven bits and indicates the format of the RTP payload. The content of the PT field is interpreted according to the tables. In general, a single RTP packet will contain media coded according to only one payload format. The exception to this rule is the RED profile, where several payload formats may be included. In the case of RED, the payload itself contains information as to how the primary and redundant samples are coded and how they are arranged within the payload. Specifically, the first several octets of the payload contain information about the primary and redundant samples, including the coding schemes used, sample lengths, and timestamp data. The exact number of octets used to convey this information depends on the number of primary and redundant samples contained in the RTP packet. Refer to RFC 2198. Sequence Number This is a 16-bit field. It is set to a random number by the sender at the beginning of a session and is incremented by one for each successive RTP packet sent. It enables the receiver to detect packet loss and/or packets arriving in the wrong order. Timestamp This is a 32-bit field indicating the instant at which the first sample in the payload was generated. The sampling instant must be derived from a clock that increases monotonically and linearly in time so that far-end applications may play out the packets in a synchronized manner and so that jitter calculations may be performed.The resolution of the clock needs to be adequate to support synchronized playout. The clock frequency is dependent on the format of the payload data. For static payload formats, the applicable clock frequency is defined in the RTP profile. For example, the frequency for typical voice-coding schemes is 8,000 Hz. The increase in the timestamp value from packet to packet will depend on the number of samples contained in a packet. The timestamp is tied to the number of sampling instants that occur from one packet to the next. For example, if 1 packet contains 10 voice samples and a timestamp value of 1, then the next packet should have a timestamp value of 11. Assuming that the sampling occurs at a rate of 8,000 Hz (every 0.125 milliseconds), then the difference of 10 in the timestamp indicates a difference in time of 1.25 milliseconds. If no packets are sent during periods of silence, then the next RTP packet may have a timestamp significantly greater than the previous RTP packet. The difference will reflect the number of samples contained in the first packet and the duration of silence. The initial value f the timestamp is a random number, chosen by the sending application.

RTP Header
Synchronization Source (SSRC) This is a 32-bit field indicating the synchronization source, which is the entity responsible for setting the sequence number and timestamp values and is normally the sender of the RTP packet. The identifier is chosen randomly by the sender so as not to be dependent upon network addresses. It is meant to be globally unique within an RTP session. In the case when the RTP stream is coming from a mixer, then the SSRC identifies the mixer, not the original source of media.

Contributing Source (CSRC) This is a 32-bit field containing an SSRC value for a contributor to a session. The field is used when the RTP stream comes from a mixer and is used to identify the original sources of media behind the mixer. There may be 0 to 15 CSRC entries in a single RTP header.

FIN