Introducción al SIP

Vonage SIP Interconnect permite la interoperabilidad entre los puntos finales WebRTC y los sistemas de telefonía existentes para que los usuarios puedan realizar llamadas basadas en SIP en contexto, mientras navegan simultáneamente por el sitio web o la aplicación móvil.

Puede utilizar la API REST para conectar su plataforma SIP a las sesiones. Esto le permite añadir audio (y, opcionalmente, vídeo) de una llamada SIP como un flujo en la sesión. El audio de otros flujos en la sesión se mezclan y se envían a su punto final SIP. Si incluye vídeo en la llamada SIP, el vídeo de los flujos de los demás participantes (hasta 9) se organiza en una cuadrícula y se envía como un único flujo de vídeo a su terminal SIP.

La función de interconexión SIP sólo se admite en sesiones enrutadas (sesiones que utilizan el protocolo Router multimedia).

SIP Diagram

Casos prácticos

Caso práctico del centro de contacto

  • Los clientes empresariales, como parte de su estrategia omnicanal de comunicaciones, están considerando WebRTC para que los usuarios finales puedan:

    • Utilizar navegadores o aplicaciones móviles para conectar con los centros de contacto, en lugar de utilizar sólo los teléfonos, con el fin de ofrecer una experiencia más ubicua y contextual.

    • Utilizar el vídeo y la colaboración, además del audio, para mejorar la eficacia y aumentar la satisfacción y retención de los clientes.

RTC de emergencia

  • Hay casos en los que la conectividad mediante los clientes SDK normales no es posible:

    • Si uno de los participantes tiene un navegador que no admite WebRTC o
    • Si el cortafuegos es demasiado restrictivo

  • Si la conectividad a través de IP/Vonage falla por las razones mencionadas anteriormente, los clientes necesitarán un mecanismo alternativo. La interconexión SIP permite a los clientes realizar una llamada telefónica normal en una sesión. Para ello, los clientes deben configurar una pasarela SIP-PSTN.

Iniciar una llamada SIP

Para iniciar la llamada SIP, utilice la API REST. Realice una solicitud HTTPS POST a la siguiente URL:

/v2/project/:app-id/dial

Sustituir :app-id con su ID APP.

Fije el Content-Type encabezado a application/json. Además, establecer un encabezado de autenticación de portador es decir: Authorization: Bearer <token> donde <token> es un JWT generado utilizando su credenciales.

Establezca el cuerpo de la solicitud en datos JSON con el siguiente formato:

{
  "sessionId": "session ID",
  "token": "A valid token",
  "sip": {
    "uri": "sip:user@sip.partner.com;transport=tls",
    "from": "from@example.com",
    "headers": {
      "headerKey": "headerValue"
    },
    "auth": {
      "username": "username",
      "password": "password"
    },
    "secure": true|false,
    "video": true|false,
    "observeForceMute": true|false
  }
}

El objeto JSON incluye las siguientes propiedades:

  • sessionId​ (obligatorio) - El ID de sesión de la llamada SIP a la que unirse.

  • token​ (obligatorio) - El token que se utilizará para el participante al que se llama. Puede añadir datos de token para identificar que el participante es un punto final SIP o para otros datos de identificación, como números de teléfono. (Las bibliotecas de cliente incluyen propiedades para inspeccionar los datos de conexión de un cliente conectado a una sesión). Consulte la sección Creación de fichas guía.

  • SIP uri (obligatorio): El URI SIP que se utilizará como destino de la llamada SIP iniciada desde Vonage a tu plataforma SIP.

Si el SIP uri contiene un transport=tls la negociación entre Vonage y el punto final SIP se realizará de manera segura. Ten en cuenta que esto sólo se aplicará a la negociación en sí, y no a la transmisión de audio. Si también deseas que la transmisión de medios de audio (y video, si se incluye) esté encriptada, configura la opción secure propiedad a true.

Este es un ejemplo de negociación de llamada segura:

"sip:user@sip.partner.com;transport=tls"

Este es un ejemplo de negociación de llamada insegura:

"sip:user@sip.partner.com"

También puede ajustar el transport encabezado a transport=tcp o transport=udp. El transporte por defecto es udp.

  • SIP from (opcional): El número o cadena que se enviará al número SIP final como la persona que llama. Debe ser una cadena con la forma from@example.comdonde from puede ser una cadena o un número.

Si from se establece en un número (por ejemplo, "14155550101@example.com"), aparecerá aparecerá como número entrante en los teléfonos RTC. Si from no está definido o es una cadena (por ejemplo, "joe@example.com"), +00000000 aparecerá como número entrante en los teléfonos RTC.

Si from no está definido, o se establece en una cadena (por ejemplo, "joe@example.com"), que sea no reconocido o un número no autorizado, en la mayoría de los casos se convertirá en "Unknown" antes de que los proveedores SIP envíen la solicitud a un operador para su terminación en la RTPC. Dependiendo del proveedor, "Unknown" aparecerá como número entrante en los teléfonos RTC. En algunos casos, los proveedores pueden rechazar esas llamadas por motivos de seguridad, para evitar problemas como la falsificación de números. En el caso de que la llamada no sea rechazada por los proveedores, +00000000 aparecerá como número entrante en los teléfonos RTC.

Un número se considera no reconocido cuando no es E.164 o no es un Número virtual de Vonage si se conecta a la dirección API de voz de Vonage, por ejemplo.

  • SIP headers​ (opcional) - Este objeto define las cabeceras personalizadas que se añadirán al SIP INVITE iniciada desde OpenTok a su plataforma SIP.

  • SIP auth (opcional) - Este objeto contiene el username y password que se utilizará en el SIP INVITE solicitud de autenticación HTTP digest, si es requerida por su plataforma SIP.

  • secure (opcional) - Un indicador booleano que indica si los medios deben transmitirse cifrados (true) o no (falsepor defecto).

Una llamada exitosa resulta en una respuesta HTTP 200, con el ID de conexión y el ID de flujo incluidos en los datos de respuesta JSON:

{
  "id": "b0a5a8c7-dc38-459f-a48d-a7f2008da853",
  "connectionId": "e9f8c166-6c67-440d-994a-04fb6dfed007",
  "streamId": "482bce73-f882-40fd-8ca5-cb74ff416036",
}

  • video (opcional) - Un indicador booleano que indica si la llamada SIP incluirá vídeo (true) o no (falsepor defecto). Con video incluido, el video del cliente SIP se incluye en la transmisión de Vonage que se envía a la sesión. El video SIP está limitado a 480p a 800 kbps. El cliente SIP recibirá un flujo de video compuesto dinámico de los flujos publicados en la sesión.

  • observeForceMute (opcional) - Un indicador booleano que indica si el punto final SIP observa force mute moderation (true) o no (falsepor defecto). Además, con observeForceMute ajustado a true, la persona que llama puede pulsar "*6" para activar y silenciar el audio publicado. Para que el conmutador de silencio "*6" funcione, el llamante SIP DEBE negociar DTMFs RFC2833 (dígitos RFC2833/RFC4733). La conmutación de silencio no es compatible con SIP INFO o DTMFs en banda. Se reproduce un mensaje (en inglés) a la persona que llama cuando ésta silencia y vuelve a silenciar, o cuando el cliente SIP es silenciado a través de una acción de forzar silencio.

  • streams (opcional) - Una matriz de IDs de flujos para los flujos a incluir en la llamada SIP. Si no establece esta propiedad, todas las secuencias de la sesión se incluirán en la llamada. sesión se incluirán en la llamada.

Una llamada exitosa resulta en una respuesta HTTP 200, con el ID de conexión y el ID de flujo incluidos en los datos de respuesta JSON:

{
  "id": "b0a5a8c7-dc38-459f-a48d-a7f2008da853",
  "connectionId": "e9f8c166-6c67-440d-994a-04fb6dfed007",
  "streamId": "482bce73-f882-40fd-8ca5-cb74ff416036",
}

El objeto JSON incluye las siguientes propiedades:

  • id - Un ID único para la llamada SIP.

  • connectionId - El ID de conexión para la conexión de la llamada SIP en la sesión. Puede utilizar este ID de conexión para finalizar la llamada SIP, utilizando la API REST. Véase la sección siguiente.

streamId - El ID de flujo para el flujo de la llamada SIP en la sesión.

La pasarela SIP envía un mensaje SIP estándar INVITE a la dirección que proporcione en la llamada REST. Cuando su punto final SIP se conecta, se añade como una nueva conexión a la sesión, y su audio (y vídeo, si se incluye) se añade a un nuevo flujo en la sesión. La nueva conexión se añade inmediatamente a la sesión sin esperar a que el punto final SIP reciba o acepte la llamada. En los clientes conectados a la sesión, la Client SDK envía eventos indicando la nueva conexión y flujo (igual que lo haría para otras conexiones y flujos). Los clientes pueden suscribirse al flujo, igual que se suscribirían a cualquier otro flujo de la sesión.

Finalización de una llamada SIP

La llamada finaliza cuando su servidor SIP envía un mensaje BYE (para terminar la llamada). También puede finalizar una llamada utilizando el método de la API REST para desconectar a un cliente de una sesión. Utilice el ID de conexión de la llamada SIP al llamar a este método. (El método REST para iniciar el SIP devuelve el ID de conexión como parte de los datos de respuesta).

Cuando la llamada SIP finaliza, la conexión y el flujo de la llamada SIP también finalizan. En cada cliente conectado a la sesión, el SDK para el cliente envía eventos indicando que la conexión y el flujo han finalizado (igual que cuando otros clientes se desconectan de la sesión).

La puerta de enlace SIP de Vonage finaliza automáticamente una llamada luego de 5 minutos de inactividad (5 minutos sin medios recibidos). Además, como medida de seguridad, la puerta de enlace SIP de Vonage cierra cualquier llamada SIP que dure más de 6 horas.

Envío de señales DTMF

Puede enviar señales DTMF (multifrecuencia bitono) a puntos finales SIP utilizando la API REST. Consulte Envío de dígitos DTMF a clientes SIP.

Los eventos de telefonía se negocian a través de SDP y se transmiten como dígitos RFC4733/RFC2833 al terminal remoto.

Seguimiento del progreso de la llamada

Regístrese para recibir devoluciones de llamada de eventos en tiempo real para su llamada SIP en su servidor de aplicaciones.

Los desarrolladores pueden usar la API REST de Vonage para conectar su plataforma SIP a las sesiones. Esto te permite añadir audio (y vídeo, si está incluido) de una llamada SIP como flujo en la sesión.

Con la monitorización de llamadas SIP, los desarrolladores pueden monitorizar el progreso de la llamada SIP, desde el servidor de su aplicación. Al registrarse en las devoluciones de llamada, su URL de devolución de llamada recibirá solicitudes HTTP POST con información sobre el progreso de la llamada SIP.

Registro de retrollamadas

La información de eventos de llamadas SIP puede registrarse en puntos finales HTTP dentro de tu servidor. Cada vez que ocurre una actividad registrada, se emite una solicitud HTTP desde la infraestructura de Vonage a tu punto final.

Para registrar una URL de devolución de llamada:

  1. Visite su Cuenta API de Video de Vonage página.

  2. Seleccione el proyecto para el que desea registrar una devolución de llamada.

  3. Establezca la URL de devolución de llamada en la sección Supervisión SIP.

Supervisión de la actividad de las llamadas SIP

Una vez registrada correctamente, la infraestructura envía peticiones HTTP para todas las llamadas SIP de un proyecto específico. Esto es útil para seguir el progreso de las llamadas SIP y tomar medidas si se produce un error. Es de esperar:

  • Al menos una callCreated evento por llamada

  • Al menos una callDestroyed evento por llamada

  • Un número indefinido de callUpdated eventos por llamada

  • Un número indefinido de muteForced eventos por llamada

Llamada Creada

Su endpoint recibirá el siguiente JSON por cada llamada SIP creada:

{
  "sessionId":  "2_MX4xMzExMjU3MX5-MTQ3MDI1NzY3OTkxOH45QXRr",
  "applicationId":  "123456", 
  "event":  "callCreated",
  "timestamp":  1470257688309,
  "call": {
    "id":  "<conference-id>",
    "connectionId":  "<sip-ot-connection-id>",
    "createdAt":  1470257688143
  }
}

Véase Propiedades JSON a continuación para ver las descripciones.

Llamada actualizada

Su endpoint recibirá el siguiente JSON cuando se actualice el estado de cada llamada SIP:

{
  "sessionId":  "2_MX4xMzExMjU3MX5-MTQ3MDI1NzY3OTkxOH45QXRr",
  "applicationId":  "123456",
  "event":  "callUpdated",
  "state":  "HANGUP",
  "timestamp":  1470257688309,
  "call": {
     "id":  "<conference-id>",
     "connectionId":  "<sip-ot-connection-id>",
     "createdAt":  1470257688143
  }
}

Véase Propiedades JSON a continuación para ver las descripciones.

Llamada Destruida

Su endpoint recibirá el siguiente JSON cuando finalice cada llamada SIP:

{
  "sessionId":  "2_MX4xMzExMjU3MX5-MTQ3MDI1NzY3OTkxOH45QXRr",
  "applicationId":  "123456",
  "event":  "callDestroyed",
  "reason_code":  "400",
  "reason_message":  "Bad Request",
  "timestamp":  1470257688309,
  "call": {
    "id":  "<conference-id>",
    "connectionId":  "<sip-ot-connection-id>",
    "createdAt":  1470257688143
  }
}

Véase Propiedades JSON a continuación para ver las descripciones.

Silencio Forzado

Su endpoint recibirá el siguiente JSON cuando una llamada SIP sea silenciada debido a un evento de moderación de forzar silencio:

{
  "sessionId":  "2_MX4xMzExMjU3MX5-MTQ3MDI1NzY3OTkxOH45QXRr",
  "applicationId":  "123456",
  "event":  "muteForced",
  "timestamp":  1470257688309,
  "call": {
    "id":  "<conference-id>",
    "connectionId":  "<sip-ot-connection-id>",
    "createdAt":  1470257688143
  }
}

Véase Propiedades JSON a continuación para ver las descripciones.

Tenga en cuenta que debe establecer el observeForceMute (para true) al crear la conexión SIP para que observe un evento de moderación de forzar silencio.

Propiedades JSON de los eventos de monitorización SIP

El objeto JSON incluye las siguientes propiedades:

  • sessionId -- El ID de sesión asociado a este evento
  • applicationId -- El ID del proyecto asociado a este evento
  • event -- callCreated | callUpdated | callDestroyed | muteForced
  • reason_code -- Para un callDestroyed evento, reason_code se establece en una de las siguientes opciones:
    • A código de respuesta SIP estándar para capturar errores en el handshake SIP
    • 700 -- "Normal Clearing" -- Esta causa indica que la llamada se está borrando porque uno de los usuarios implicados en la llamada ha solicitado que se borre la llamada.
    • 703 -- "Despeje inesperado" -- Esta causa indica que la llamada se está despejando inesperadamente.
    • 704 -- "Media Timeout" -- Este código indica que nuestro puente SIP no pudo recibir ningún tráfico RTP del otro punto final SIP.
    • 705 -- "Max Duration" -- La llamada ha alcanzado la duración máxima.
    • 706 -- "Max Inactive" -- La llamada ha alcanzado la duración máxima de inactividad.
  • reason_message -- Para un callDestroyed evento, reason_message es una cadena que describe la razón por la que se destruyó la llamada.
  • state -- Para un callUpdated evento, state se establece en una de las siguientes opciones:
    • DIALING -- Se ha iniciado una llamada SIP
    • RINGING -- Está sonando una llamada SIP
    • ON_HOLD -- La llamada SIP está en espera
    • ACTIVE -- Se ha contestado a una llamada SIP y está en curso
    • HANGUP -- Una llamada SIP completada
  • timestamp -- La marca de tiempo del evento, en milisegundos desde la época Unix
  • call -- Un objeto que define la conexión y que contiene las siguientes propiedades:
    • id -- La identificación de la conferencia
    • connectionId -- ID de conexión del cliente SIP
    • createdAt -- El valor de la marca de tiempo, en milisegundos desde la época Unix, para cuando se creó la llamada.

Consideraciones de seguridad

Existen algunas prácticas recomendadas por Vonage al usar la interfaz SIP con tus servidores SIP. Intentan mitigar los posibles ataques proporcionando los mecanismos para autenticar y autorizar que las llamadas SIP recibidas en tu servidor son legítimas y para cifrar toda la señalización y los medios:

  • Utilizar TLS y habilitar llamadas seguras (SRTP) para la señalización para evitar la posibilidad de interceptar las comunicaciones.
  • Active la autenticación SIP en su servidor. De lo contrario, cualquiera que conozca su URI SIP podría enviar llamadas a su servidor.

Póngase en contacto con nosotros si tiene más preguntas.

Detalles técnicos

Compatibilidad con RFC3550 (RTP/RTCP): El tráfico multimedia puede ser cifrado (SRTP) o no cifrado (RTP plano). En caso de cifrado, se admiten los protocolos DTLS y SDES.

Compatible con códecs: La puerta de enlace SIP de Vonage admite los códecs de audio OPUS, G.711 y G.722; y los códecs de video H.264 y VP8. El video SIP está limitado a 480p a 800 kbps.

Señalización: La puerta de enlace SIP de Vonage admite RFC 3261 (SIP) sobre UDP, TCP y TLS. Comunícate con Vonage si necesitas información o soporte para alguna extensión específica.

La puerta de enlace SIP de Vonage rechazará cualquier mensaje SIP proveniente de una plataforma SIP de terceros a menos que sea parte de un diálogo SIP iniciado por la puerta de enlace SIP de Vonage. Las llamadas iniciadas con la puerta de enlace SIP de Vonage se pueden poner en espera utilizando un re-­INVITE con el sendonly/inactive en el SDP o un re-­INVITE con el puerto 0 en el SDP.

Otras consideraciones: Los primeros medios están desactivados.

PREGUNTAS FRECUENTES

¿Qué es el SIP? ¿Por qué es importante el SIP?

El Protocolo de Iniciación de Sesión (SIP) es un protocolo de comunicaciones para la señalización y el control de sesiones de comunicación multimedia. Las aplicaciones más comunes del SIP son la telefonía por Internet para llamadas de voz y vídeo, así como la mensajería instantánea, a través de redes de Protocolo de Internet (IP).

En nuestro caso se utiliza para establecer una llamada desde las sesiones a un servidor SIP de terceros. Una vez establecida la llamada, el audio (y el vídeo, si está incluido) se envía utilizando el protocolo RTP.

¿Cuál es la diferencia entre SIP y PSTN? ¿Vonage ofrece una puerta de enlace PSTN?

La RTPC es la red telefónica tradicional. La RTC no es una red IP y no utiliza SIP, pero muchos proveedores, como Nexmo, tienen pasarelas para convertir los protocolos SIP en protocolos RTC. De ese modo, una llamada SIP sobre IP se convierte en una llamada telefónica.

En términos prácticos, incluso si la Video API de Vonage no admite llamadas PSTN, la habilitamos al admitir llamadas SIP. A partir de ahí, es cuestión de encontrar un proveedor que convierta las llamadas SIP en llamadas PSTN.

¿Puedo llamar a teléfonos normales con la función de interconexión SIP?

La interconexión SIP de Vonage permite a los socios iniciar llamadas a cualquier punto final SIP. Para realizar/recibir llamadas a/desde un teléfono normal, los clientes necesitan una pasarela en su lado para convertir la llamada SIP a los protocolos utilizados en las redes de telefonía móvil/fija.

¿Existe alguna forma de gestionar la marcación de salida o de entrada desde un número de teléfono normal (RTC)?

Con SIP Interconnect, los clientes pueden marcar desde una sesión a cualquier destino SIP. Además, los clientes pueden configurar una pasarela SIP (propia o de terceros) para llamar a un número de teléfono normal.

Aunque la API de interconexión SIP no admite llamadas SIP entrantes, los clientes pueden implementar la marcación desde un teléfono común (PSTN) utilizando una puerta de enlace SIP (propia o de terceros) para conectar la llamada entrante recibida desde teléfonos comunes con la llamada SIP saliente proveniente de Vonage.

¿Admite SIP Interconnect el envío de vídeo?

Sí. Ajuste el video bandera a true al iniciar la llamada SIP utilizando el Método API REST. El vídeo SIP está limitado a 480p a 800 kbps.

¿Existe una diferencia notable en la calidad de audio percibida en el punto final WebRTC frente al punto final SIP?

La expectativa es tener la misma calidad, aunque con latencia adicional en el punto final SIP.

¿Cómo funciona la función de archivado con SIP Interconnect?

La capacidad de archivado funciona exactamente igual que hoy para una sesión WebRTC. Hasta 16 secuencias de vídeo y las primeras 50 secuencias de audio, incluidas las secuencias de audio y vídeo SIP, formarán parte del archivo.

¿Cómo navega el usuario por el IVR? Habrá un teclado de marcación en la aplicación web/móvil?

Puede utilizar la API REST para enviar señales DTMF a clientes SIP con el fin de admitir sistemas de respuesta de voz interactiva (IVR). Consulte Envío de señales DTMF.

¿Con qué servidores SIP es compatible SIP Interconnect?

Hemos probado la interoperabilidad con algunos de los equipos de telecomunicaciones más populares (ACME packet, Broadsoft), algunas plataformas SIP populares (Nexmo, y otros), y el servidor SIP de código abierto más popular (freeswitch). Es imposible garantizar la interoperabilidad con todos y cada uno de los servidores SIP, pero intentamos limitar el uso de extensiones/características SIP para reducir las posibilidades de fallo. Hasta ahora, nunca hemos tenido que cambiar nuestra solución para interoperar con ningún nuevo servidor SIP.

¿Cómo se puede desconectar una llamada a un cliente SIP conectado a una sesión?

  • Uso de la API de cliente existente: un cliente Web (JavaScript) conectado a una sesión con privilegios de moderador puede forzar a otros clientes, incluidos los clientes SIP, a desconectarse de una sesión.
  • Uso de la API REST para la moderación del lado del servidor - Si los clientes WebRTC están en dispositivos móviles o el cliente no quiere dar privilegios de moderador a los clientes, los servidores de aplicaciones pueden emitir un HTTP DELETE a un cliente conectado para forzar una desconexión del lado del servidor.