# SDP: el Session Description Protocol

> SDP (Session Description Protocol, RFC 4566) es el formato de texto que SIP transporta para describir una sesión de medios: la dirección IP, los puertos, los tipos de medios y los códecs que ofrece cada lado. No es un transporte; es una descripción. SIP lo usa en un intercambio offer/answer (RFC 3264) para negociar los medios que intercambiarán los puntos finales sobre RTP.

- URL canónica: https://www.broadnet.me/es/reference/sdp-session-description-protocol
- Idioma: es
- Última actualización: 2026-07-18
- Editor: BroadNet (https://www.broadnet.me)

Cómo describe SDP una sesión de medios dentro de SIP: la estructura de líneas v=/o=/s=/c=/t=/m=/a=, el modelo offer/answer (RFC 3264), la negociación de códecs mediante rtpmap y los atributos de dirección de medios.

## Qué es SDP

SDP es un formato de texto pequeño, basado en líneas, que describe una sesión multimedia: qué medios (audio, vídeo), adónde enviarlos (dirección de conexión y puerto), qué códecs son aceptables y en qué dirección puede fluir. SIP no interpreta los medios en sí; transporta el SDP en el cuerpo del mensaje (Content-Type: application/sdp) y deja que los puntos finales acuerden los parámetros. SDP es puramente descriptivo: no transmite medios ni negocia nada por sí solo; la negociación proviene de cómo SIP intercambia dos cuerpos SDP.

## La estructura de líneas

Un cuerpo SDP es una secuencia de líneas de tipo de una sola letra en un orden fijo, dividida en una sección de nivel de sesión seguida de una o más secciones de nivel de medios que empiezan cada una con una línea m=. Las más importantes son o= (origen e id de sesión), c= (dirección de conexión), m= (tipo de medio, puerto, transporte y formatos) y las líneas de atributo a= que transportan los mapas de códec y la dirección. Las líneas están ordenadas y distinguen mayúsculas de minúsculas.

*Tipos de línea de SDP*

| Línea | Nombre | Transporta |
|---|---|---|
| v= | Versión | Versión SDP (0) |
| o= | Origen | Nombre de usuario, ID/versión de sesión, red/dirección |
| s= | Nombre de la sesión | Una etiqueta para la sesión |
| c= | Conexión | Tipo de red, tipo de dirección y dirección IP del medio |
| t= | Temporización | Hora de inicio/fin (0 0 para una llamada sin límite) |
| m= | Medios | Tipo de medio, puerto, transporte (RTP/AVP…) y formatos |
| a= | Atributos | rtpmap, fmtp, ptime, dirección (sendrecv…) y más |

## El modelo offer/answer

SIP negocia los medios con el modelo offer/answer de RFC 3264. Un punto final envía una oferta SDP (normalmente en el INVITE) que enumera los flujos de medios y todos los códecs que está dispuesto a usar. El otro devuelve una respuesta SDP (normalmente en el 200 OK) seleccionando de lo ofrecido —conservando solo los códecs que también admite, en su orden preferido, y fijando la dirección—. El resultado es la intersección que ambos lados acordaron. Un desajuste sin códec común es lo que produce un 488 Not Acceptable Here.

*Una oferta SDP para un único flujo de audio*

```text
v=0
o=alice 2890844526 2890844526 IN IP4 host.example.com
s=-
c=IN IP4 198.51.100.10
t=0 0
m=audio 49170 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=ptime:20
a=sendrecv
```

## Códecs y payload types

La línea m= enumera números de payload type de RTP, y cada a=rtpmap asigna un número a un códec y una frecuencia de reloj. Los payload types 0–95 incluyen asignaciones estáticas (0 = PCMU/G.711 ley µ, 8 = PCMA/G.711 ley A, 9 = G722, 18 = G729), mientras que 96–127 son dinámicos y deben definirse mediante un rtpmap. a=fmtp transporta parámetros específicos del códec, y telephone-event (RFC 4733) es como se negocia el DTMF. Enumerar los códecs en orden de preferencia permite al respondedor elegir el mejor mutuamente admitido.

*Payload types de audio RTP comunes*

| PT | Códec | Reloj | Nota |
|---|---|---|---|
| 0 | PCMU (G.711 µ-law) | 8000 | Estático; calidad telefónica (toll quality) de ~64 kbit/s |
| 8 | PCMA (G.711 A-law) | 8000 | Estático; calidad telefónica (toll quality) de ~64 kbit/s |
| 9 | G722 | 8000 | Banda ancha (audio de 16 kHz) |
| 18 | G729 | 8000 | Estático; ~8 kbit/s comprimido |
| 96–127 | Dinámico (Opus, evento telefónico…) | varía | Definido por a=rtpmap |

## Atributos de dirección de medios

Un atributo de dirección a= fija cómo fluyen los medios de un flujo. sendrecv es el valor bidireccional normal por defecto. sendonly y recvonly restringen el flujo a una dirección, usados para retención, anuncios y medios unidireccionales. inactive detiene los medios por completo manteniendo la sesión activa. Alternar estos (por ejemplo, sendonly ⇄ sendrecv en un re-INVITE) es como se implementan la retención de llamada, la reanudación y la música en espera sin caer el diálogo.

*Atributos de dirección de SDP*

| Atributo | Significado |
|---|---|
| a=sendrecv | Enviar y recibir contenido multimedia (predeterminado) |
| a=sendonly | Enviar únicamente (por ejemplo, anuncio o la parte retenida) |
| a=recvonly | Recibir únicamente (por ejemplo, la parte puesta en espera) |
| a=inactive | No hay medios en ninguna dirección; la sesión sigue activa |

## Preguntas frecuentes

### ¿Para qué se usa SDP en SIP?

SDP describe la sesión de medios: la dirección IP, los puertos, los tipos de medios y los códecs que ofrece cada punto final. SIP transporta dos cuerpos SDP en un intercambio offer/answer para negociar qué audio o vídeo intercambiarán los puntos finales sobre RTP. SDP en sí no transporta medios.

### ¿Qué es el modelo offer/answer de SIP?

Definido en RFC 3264, es cómo SIP negocia los medios: un lado envía una oferta SDP (a menudo en el INVITE) que enumera sus medios y códecs, y el otro devuelve una respuesta SDP (a menudo en el 200 OK) seleccionando el subconjunto que también admite. La intersección acordada es lo que fluye.

### ¿Qué significa la línea m= en SDP?

La línea m= (media) declara un flujo de medios: su tipo (audio/vídeo), el puerto al que enviar, el transporte (p. ej. RTP/AVP o RTP/SAVP para SRTP) y la lista de números de payload type de RTP ofrecidos. Cada payload type se describe luego con una línea a=rtpmap.

### ¿Cómo se eligen los códecs en una llamada SIP?

El oferente enumera los códecs aceptables en orden de preferencia en el SDP. El respondedor conserva solo los que también admite y los devuelve, seleccionando en la práctica el mejor códec mutuamente admitido. Si los conjuntos no se intersecan, la negociación falla, normalmente con un 488 Not Acceptable Here.

### ¿Cómo se hace la retención de llamada con SDP?

Cambiando el atributo de dirección de medios en un re-INVITE, por ejemplo fijando a=sendonly (o históricamente una dirección de conexión a cero) para poner en espera al lado remoto, y a=sendrecv para reanudar. El diálogo permanece activo; solo cambia la dirección de los medios.

## Fuentes

- [IETF RFC 4566 — SDP: Session Description Protocol](https://datatracker.ietf.org/doc/html/rfc4566)
- [IETF RFC 3264 — An Offer/Answer Model with SDP](https://datatracker.ietf.org/doc/html/rfc3264)

## Relacionado

- [Medios RTP y SRTP](https://www.broadnet.me/es/reference/rtp-and-srtp-media)
- [flujo de llamadas SIP](https://www.broadnet.me/es/reference/sip-call-flow)
- [Métodos y solicitudes SIP](https://www.broadnet.me/es/reference/sip-methods-and-requests)
- [encabezados SIP](https://www.broadnet.me/es/reference/sip-headers)
- [Voz programable (producto)](https://www.broadnet.me/es/products/voice)