SIP: el modelo de oferta / respuesta
El uso de SDP con SIP se indica en la respuesta de oferta de SDP RFC 3264. El tipo de cuerpo del mensaje predeterminado en SIP es application/sdp.
La parte que llama enumera las capacidades de los medios que están dispuestos a recibir en SDP, generalmente en un INVITE o en un ACK.
La parte llamada enumera sus capacidades de medios en la respuesta 200 OK al INVITE.
Un uso típico de SIP de SDP incluye los siguientes campos: versión, origen, asunto, hora, conexión y uno o más medios y atributos.
SIP no utiliza los campos de asunto y hora, pero se incluyen por motivos de compatibilidad.
En el estándar SDP, el campo de asunto es un campo obligatorio y debe contener al menos un carácter, sugerido como s = - si no hay asunto.
El campo de tiempo generalmente se establece en t = 00. SIP usa los campos de conexión, medios y atributos para configurar sesiones entre UA.
El campo de origen tiene un uso limitado con SIP.
El ID de sesión generalmente se mantiene constante durante una sesión SIP.
La versión se incrementa cada vez que se cambia el SDP. Si el SDP que se envía no cambia del enviado anteriormente, la versión se mantiene igual.
Como el tipo de sesión de medios y el códec que se utilizará son parte de la negociación de la conexión, SIP puede usar SDP para especificar múltiples tipos de medios alternativos y para aceptar o rechazar selectivamente esos tipos de medios.
La especificación de oferta / respuesta, RFC 3264, recomienda que se utilice un atributo que contenga a = rtpmap: para cada campo de medios. Un flujo de medios se rechaza estableciendo el número de puerto en cero para el campo de medios correspondiente en la respuesta SDP.
Ejemplo
En el siguiente ejemplo, la persona que llama Tesla quiere configurar una llamada de audio y video con dos posibles códecs de audio y un códec de video en el SDP llevado en el INVITE inicial -
v = 0
o = John 0844526 2890844526 IN IP4 172.22.1.102
s = -
c = IN IP4 172.22.1.102
t = 0 0
m = audio 6000 RTP/AVP 97 98
a = rtpmap:97 AMR/16000/1
a = rtpmap:98 AMR-WB/8000/1
m = video 49172 RTP/AVP 32
a = rtpmap:32 MPV/90000Los códecs están referenciados por los números de perfil 97, 98 de RTP / AVP.
La parte llamada Marry responde a la llamada, elige el segundo códec para el primer campo de medios y rechaza el segundo campo de medios, solo desea una sesión de AMR.
v = 0
o = Marry 2890844526 2890844526 IN IP4 172.22.1.110
s = -
c = IN IP4 200.201.202.203
t = 0 0
m = audio 60000 RTP/AVP 8
a = rtpmap:97 AMR/16000
m = video 0 RTP/AVP 32Si esta llamada de solo audio no es aceptable, Tom enviaría un ACK y luego un BYE para cancelar la llamada. De lo contrario, se establecería la sesión de audio y se intercambiarían paquetes RTP.
Como ilustra este ejemplo, a menos que se mantenga el número y el orden de los campos de medios, la parte que llama no sabría con certeza qué sesiones de medios estaban siendo aceptadas y rechazadas por la parte llamada.
Las reglas de oferta / respuesta se resumen en las siguientes secciones.
Reglas para generar una oferta
Una oferta de SDP debe incluir todos los campos de SDP obligatorios (esto incluye v =, o =, s =, c = y t =). Estos son campos obligatorios en SDP.
Por lo general, incluye un campo de medios ( m = ), pero no es necesario. Las líneas de medios contienen todos los códecs enumerados en orden de preferencia. La única excepción a esto es que si el punto final admite una gran cantidad de códecs, se debe enumerar el que tiene más probabilidades de ser aceptado o el más preferido. Los diferentes tipos de medios incluyen audio, video, texto, MSRP, BFCP, etc.
Reglas para generar una respuesta
Una respuesta de SDP a una oferta debe construirse de acuerdo con las siguientes reglas:
La respuesta debe tener el mismo número de m = líneas en el mismo orden que la respuesta.
Las transmisiones de medios individuales se pueden rechazar configurando el número de puerto en 0.
Las transmisiones se aceptan enviando un número de puerto distinto de cero.
Las cargas útiles enumeradas para cada tipo de medio deben ser un subconjunto de las cargas útiles enumeradas en la oferta.
Para cargas útiles dinámicas, no es necesario utilizar el mismo número de carga útil dinámica en cada dirección. Por lo general, solo se selecciona una única carga útil.
Reglas para modificar una sesión
Cualquiera de las partes puede iniciar otro intercambio de oferta / respuesta para modificar una sesión. Cuando se modifica una sesión, se deben seguir las siguientes reglas:
El número de versión de la línea de origen ( o = ) debe ser el mismo que el último enviado, lo que indica que este SDP es idéntico al intercambio anterior, o puede incrementarse en uno, lo que indica un nuevo SDP que debe analizarse.
La oferta debe incluir todas las líneas de medios existentes y deben enviarse en el mismo orden.
Se pueden agregar transmisiones de medios adicionales al final de la lista de líneas m = .
Se puede eliminar un flujo de medios existente estableciendo el número de puerto en 0. Esta línea de medios debe permanecer en el SDP y en todos los intercambios de ofertas / respuestas futuras para esta sesión.
Llamada en espera
Un participante en una llamada puede poner temporalmente al otro en espera. Esto se hace enviando un INVITE con un SDP idéntico al del INVITE original pero cona = sendonly atributo presente.
La llamada se activa de nuevo enviando otro INVITE con el a = sendrecvatributo presente. La siguiente ilustración muestra el flujo de llamadas de una llamada en espera.
