SIP-Zusammenschaltung

Sie können die OpenTok-REST-API verwenden, um Ihre SIP-Plattform mit OpenTok-Sitzungen zu verbinden. Auf diese Weise können Sie Audio (und optional Video) aus einem SIP-Anruf als Stream in die OpenTok-Sitzung einbinden. Das Audio aus anderen Streams in der OpenTok-Sitzung wird gemischt und an Ihren SIP-Endpunkt gesendet. Wenn Sie Video in den SIP-Anruf einbinden, werden die Videostreams der anderen Teilnehmer (bis zu 9) in einem Rasterlayout angeordnet und als einzelner Videostream an Ihren SIP-Endpunkt gesendet.

Die SIP-Interconnect-Funktion wird nur in gerouteten Sitzungen unterstützt (Sitzungen, die die OpenTok Media Router).

Diese Seite enthält die folgenden Abschnitte:

Einführung in SIP

OpenTok SIP Interconnect ermöglicht die Interoperabilität zwischen WebRTC-Endpunkten und bestehenden Telefoniesystemen, sodass Nutzer kontextbezogene SIP-basierte Anrufe tätigen können, während sie gleichzeitig die Website oder die mobile Anwendung nutzen.

Ziel Anwendungsfälle

Anwendungsfall Kontaktzentrum

  • Unternehmenskunden setzen im Rahmen ihrer Omnichannel-Strategie für die Kommunikation auf WebRTC, damit die Endnutzer dies nutzen können:

    • Nutzung von Browsern oder mobilen Anwendungen für die Verbindung mit Kontaktzentren, anstatt nur über Telefone, um eine allgegenwärtige und kontextbezogene Erfahrung zu bieten

    • Nutzen Sie Video/Kollaboration zusätzlich zu Audio, um die Effizienz zu steigern und die Kundenzufriedenheit und -bindung zu erhöhen.

PSTN-Fallback

  • Es gibt Fälle, in denen eine Verbindung über die regulären OpenTok-Clients nicht möglich ist:

    • Wenn einer der Teilnehmer einen Browser hat, der WebRTC nicht unterstützt oder
    • Wenn die Firewall zu restriktiv ist

  • Sollte die Verbindung über IP/OpenTok aus den oben genannten Gründen fehlschlagen, benötigen Kunden einen Ausweichmechanismus. Mit OpenTok SIP Interconnect können Kunden innerhalb einer OpenTok-Sitzung einen herkömmlichen Telefonanruf tätigen. Zu diesem Zweck müssen Kunden ein SIP-PSTN-Gateway einrichten.

Einleiten eines SIP-Anrufs

Um den SIP-Anruf zu starten, verwenden Sie die OpenTok-REST-API. Senden Sie eine HTTPS-POST-Anfrage an die folgende URL:

https://api.opentok.com/v2/project/:apiKey/dial

Ersetzen Sie apiKey mit Ihrem OpenTok-API-Schlüssel.

Setzen Sie die Content-Type Kopfzeile zu application/json. Eine benutzerdefinierte Einstellung festlegen X-OPENTOK-AUTH Header zu einem JSON-Web-Token, das für die Verwendung mit den OpenTok-REST-API-Aufrufen gültig ist. Siehe den Abschnitt über Authentifizierung bei Aufrufen der OpenTok-REST-API.

Setzen Sie den Körper der Anfrage auf JSON-Daten des folgenden Formats:

{
  "sessionId": "OpenTok session ID",
  "token": "A valid OpenTok 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,
    "streams": ["stream-id-1", "stream-id-2"]
  }
}

Das JSON-Objekt enthält die folgenden Eigenschaften:

  • sessionId​ (erforderlich) — Die OpenTok-Sitzungs-ID für den SIP-Anruf, an dem teilgenommen werden soll.

  • token​ (erforderlich) — Das OpenTok-Token, das für den angerufenen Teilnehmer verwendet werden soll. Sie können ein Token hinzufügen data um festzustellen, ob es sich bei dem Teilnehmer um einen SIP-Endpunkt handelt, oder um andere Identifikationsdaten wie beispielsweise Telefonnummern. (Die OpenTok-Client-Bibliotheken enthalten Eigenschaften, mit denen die Verbindungsdaten eines mit einer Sitzung verbundenen Clients überprüft werden können.) Siehe die Token-Erstellung Leitfaden für Entwickler.

  • SIP uri ​(erforderlich): Die SIP-URI, die als Ziel des von OpenTok an Ihre SIP-Plattform initiierten SIP-Anrufs verwendet werden soll.

    Wenn die SIP uri enthält eine transport=tls Header: Die Aushandlung zwischen Vonage und dem SIP-Endpunkt erfolgt sicher. Beachten Sie, dass dies nur für die Aushandlung selbst gilt, nicht jedoch für die Audioübertragung. Wenn Sie möchten, dass auch die Medienübertragung von Audio (und Video, falls vorhanden) verschlüsselt wird, setzen Sie den secure Eigenschaft zu true.

    Dies ist ein Beispiel für eine sichere Anrufaushandlung:

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

    Dies ist ein Beispiel für eine unsichere Anrufaushandlung:

    "sip:user@sip.partner.com"

    Sie können auch die transport Kopfzeile zu transport=tcp oder transport=udp. Der Standardtransport ist udp.

  • SIP from (optional): Die Nummer oder Zeichenfolge, die an die endgültige SIP-Nummer als der Anrufer. Es muss sich um eine Zeichenkette in der Form von from@example.com, wobei from kann eine Zeichenkette sein oder eine Zahl sein.

    Wenn from auf eine Zahl gesetzt wird (zum Beispiel, "14155550101@example.com"), wird sie auf PSTN-Telefonen als eingehende Nummer angezeigt. Wenn from undefiniert oder auf eine Zeichenkette gesetzt ist (zum Beispiel, "joe@example.com"), wird +00000000 auf PSTN-Telefonen als eingehende Nummer angezeigt.

    Wenn from undefiniert ist oder auf eine Zeichenkette gesetzt ist (zum Beispiel, "joe@example.com"), d. h. eine unbekannte oder nicht autorisierte Nummer, wird diese in den meisten Fällen umgewandelt in "Unknown" bevor die Anfrage von SIP-Anbietern an einen Carrier zur PSTN-Terminierung weitergeleitet wird. Je nach Anbieter, "Unknown" wird auf PSTN-Telefonen als eingehende Nummer angezeigt. In einigen Fällen können die Anbieter diese Anrufe aus Sicherheitsgründen zurückweisen, um Probleme wie Nummernspoofing zu vermeiden. Falls der Anruf von den Anbietern nicht abgewiesen wird, wird +00000000 auf den PSTN-Telefonen als eingehende Nummer angezeigt.

    Eine Nummer gilt als nicht erkannt, wenn sie nicht E.164 oder nicht eine Vonage virtuelle Nummer wenn die Verbindung zu der Vonage Voice API, zum Beispiel.

  • SIP headers​ (optional) - Dieses Objekt definiert benutzerdefinierte Header, die der SIP-Datei hinzugefügt werden. INVITE Anfrage, die von OpenTok an Ihre SIP-Plattform gesendet wird.

  • SIP auth (optional) - Dieses Objekt enthält die username und password zu verwenden in dem SIP INVITE Anfrage für die HTTP-Digest-Authentifizierung, wenn dies von Ihrer SIP-Plattform verlangt wird.

  • secure (optional) - Ein boolesches Flag, das angibt, ob die Medien verschlüsselt übertragen werden müssen verschlüsselt (true) oder nicht (false(die Standardeinstellung).

  • video (optional) — Ein boolescher Schalter, der angibt, ob der SIP-Anruf Video enthält (true) oder nicht (false(Standard). Bei aktivierter Videoübertragung wird das Video des SIP-Clients in den OpenTok-Stream integriert, der an die OpenTok-Sitzung gesendet wird. SIP-Video ist auf 480p bei 800 kbit/s begrenzt. Der SIP-Client empfängt einen dynamisch zusammengesetzten Videostream aus den in der OpenTok-Sitzung veröffentlichten Streams.

  • observeForceMute (optional) — Ein boolescher Flag, der angibt, ob der SIP-Endpunkt Stummschaltung der Moderation erzwingen (true) oder nicht (false(Standard). Außerdem gilt bei observeForceMute eingestellt auf trueDer Anrufer kann „*6“ drücken, um die Stummschaltung des übertragenen Tons aufzuheben bzw. zu aktivieren. Damit die Stummschaltung per „*6“ funktioniert, MUSS der SIP-Anrufer RFC2833-DTMFs (RFC2833/RFC4733-Ziffern) aushandeln. Die Stummschaltfunktion wird bei SIP-INFO oder In-Band-DTMFs nicht unterstützt. Dem Anrufer wird eine Ansage (auf Englisch) abgespielt, wenn er die Stummschaltung aktiviert oder deaktiviert oder wenn der SIP-Client durch eine erzwungene Stummschaltung stummgeschaltet wird.

  • streams (optional) - Ein Array von Stream-IDs für Streams, die in den den SIP-Anruf einschließen. Wenn Sie diese Eigenschaft nicht festlegen, werden alle Streams in der Sitzung in den Anruf einbezogen.

Ein erfolgreicher Aufruf führt zu einer HTTP-200-Antwort, wobei die Verbindungs-ID und die Stream-ID in den JSON-Antwortdaten enthalten sind:

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

Das JSON-Objekt enthält die folgenden Eigenschaften:

  • id - Eine eindeutige ID für den SIP-Anruf.

  • connectionId — Die OpenTok-Verbindungs-ID für die SIP-Verbindung innerhalb der OpenTok-Sitzung. Mit dieser Verbindungs-ID können Sie den SIP-Anruf mithilfe der OpenTok REST-API beenden. Siehe der nächste Abschnitt.

  • streamId — Die OpenTok-Stream-ID für den Stream des SIP-Anrufs in der OpenTok-Sitzung.

Das OpenTok-SIP-Gateway sendet eine Standard-SIP-Nachricht INVITE an die Adresse, die Sie im REST-Aufruf angeben. Wenn sich Ihr SIP-Endpunkt verbindet, wird er als neue Verbindung zur OpenTok-Sitzung hinzugefügt, und sein Audio (sowie gegebenenfalls Video) wird einem neuen Stream in der OpenTok-Sitzung hinzugefügt. Die neue Verbindung wird sofort zur OpenTok-Sitzung hinzugefügt, ohne darauf zu warten, dass der SIP-Endpunkt den Anruf empfängt oder annimmt. In Clients, die mit der Sitzung verbunden sind, sendet das OpenTok-Client SDK Ereignisse aus, die auf die neue Verbindung und den neuen Stream hinweisen (genau wie bei anderen OpenTok-Verbindungen und -Streams). Clients können den Stream abonnieren, genau wie sie jeden anderen Stream in der Sitzung abonnieren würden.

Beenden eines SIP-Anrufs

Der Anruf wird beendet, wenn Ihr SIP-Server eine BYE Meldung (zum Beenden des Anrufs). Sie können einen Anruf auch mithilfe der OpenTok-REST-API-Methode beenden, um einen Client von einer Sitzung trennen. Verwenden Sie beim Aufruf dieser Methode die Verbindungs-ID des SIP-Anrufs. (Die REST-Methode für Einleiten des SIP-Anrufs gibt die Verbindungs-ID als Teil der Antwortdaten zurück.)

Wenn der SIP-Anruf beendet wird, werden auch die OpenTok-Verbindung und der Stream für den SIP-Anruf beendet. In jedem mit der Sitzung verbundenen Client löst das clientseitige OpenTok-SDK Ereignisse aus, die anzeigen, dass die Verbindung und der Stream beendet wurden (genau wie bei der Trennung anderer Clients von der Sitzung).

Das OpenTok-SIP-Gateway beendet einen Anruf automatisch nach 5 Minuten Inaktivität (5 Minuten ohne empfangene Medien). Außerdem schließt das OpenTok-SIP-Gateway aus Sicherheitsgründen jeden SIP-Anruf, der länger als 6 Stunden dauert.

Senden von DTMF-Signalen

Über die REST-API können Sie DTMF-Signale (Dual-Tone Multi-Frequency) an SIP-Endpunkte senden. Siehe Senden von DTMF-Ziffern an SIP-Clients.

Telefonie-Ereignisse werden über SDP ausgehandelt und als RFC4733/RFC2833-Digits an den entfernten Endpunkt übertragen.

Überwachung des Gesprächsverlaufs

Registrieren Sie sich, um Echtzeit-Ereignisrückrufe für Ihren SIP-Anruf auf Ihrem Anwendungsserver zu erhalten.

Entwickler können die OpenTok-REST-API nutzen, um ihre SIP-Plattform mit OpenTok-Sitzungen zu verbinden. Auf diese Weise können Sie Audio (und gegebenenfalls Video) aus einem SIP-Anruf als Stream in die OpenTok-Sitzung einbinden. Mithilfe der SIP-Anrufüberwachung können Entwickler den Verlauf des SIP-Anrufs direkt von ihrem App-Server aus überwachen. Wenn Sie sich für Callbacks registrieren, erhält Ihre Callback-URL HTTP-POST-Anfragen mit Informationen zum Verlauf des SIP-Anrufs.

Registrierung von Rückrufen

Informationen zu SIP-Anrufereignissen können an HTTP-Endpunkte auf Ihrem Server übermittelt werden. Sobald eine registrierte Aktivität auftritt, wird von der OpenTok-Infrastruktur eine HTTP-Anfrage an Ihren Endpunkt gesendet.

So registrieren Sie eine Rückruf-URL:

  1. Besuchen Sie Ihr Vonage Video API Account-Seite.

  2. Wählen Sie das OpenTok-Projekt aus, für das Sie einen Callback registrieren möchten.

  3. Legen Sie die Callback-URL im Abschnitt SIP-Überwachung fest.

    Sichere Rückrufe: Sie können Webhook-Rückrufanforderungen mit signierten Rückrufen sichern, unter Verwendung eines Signaturgeheimnisses. Siehe Sichere Rückrufe.

Überwachung der SIP-Anrufaktivität

Nach der ordnungsgemäßen Registrierung sendet die OpenTok-Infrastruktur HTTP-Anfragen für alle SIP-Anrufe eines bestimmten Projekts. Dies ist nützlich, um den Fortschritt von SIP-Anrufen zu verfolgen und bei Auftreten eines Fehlers entsprechende Maßnahmen zu ergreifen. Sie sollten Folgendes erwarten:

  • Mindestens eine callCreated Ereignis pro Anruf

  • Mindestens eine callDestroyed Ereignis pro Anruf

  • Eine unbestimmte Anzahl von callUpdated Ereignisse pro Anruf

  • Eine unbestimmte Anzahl von muteForced Ereignisse pro Anruf

Aufruf Erstellt

Ihr Endpunkt erhält das folgende JSON für jeden erstellten SIP-Anruf:

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

Siehe JSON-Eigenschaften unten für Beschreibungen.

Aufruf Aktualisiert

Ihr Endpunkt erhält das folgende JSON, wenn der Status jedes SIP-Anrufs aktualisiert wird:

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

Siehe JSON-Eigenschaften unten für Beschreibungen.

Anruf vernichtet

Ihr Endpunkt erhält das folgende JSON, wenn ein SIP-Anruf endet:

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

Siehe JSON-Eigenschaften unten für Beschreibungen.

Stummschaltung Erzwungen

Ihr Endpunkt erhält die folgende JSON-Daten, wenn ein SIP-Anruf aufgrund eines Moderationsereignis „Stummschaltung erzwingen“:

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

Siehe JSON-Eigenschaften unten für Beschreibungen.

Beachten Sie, dass Sie die Option observeForceMute Option (zu true), damit die SIP-Verbindung beim Aufbau ein „Force Mute“-Moderationsereignis erkennt.

JSON-Eigenschaften von SIP-Überwachungsereignissen

Das JSON-Objekt enthält die folgenden Eigenschaften:

  • sessionId -- Die mit diesem Ereignis verbundene Sitzungs-ID

  • projectId -- Die mit diesem Ereignis verbundene Projekt-ID

  • event -- callCreated | callUpdated | callDestroyed | muteForced

  • reason_code -- Für ein callDestroyed Veranstaltung, reason_code ist auf einen der folgenden Werte eingestellt:

    • A Standard-SIP-Antwortcode um Fehler beim SIP-Handshake zu erfassen

    • 700 – „Normale Beendigung“ – Dieser Grund gibt an, dass das Gespräch beendet wird, weil einer der am Gespräch beteiligten Teilnehmer die Beendigung des Gesprächs angefordert hat.

    • 703 -- "Unerwartete Löschung" -- Diese Ursache zeigt an, dass der Anruf unerwartet gelöscht wird.

    • 704 – „Media Timeout“ – Dieser Code weist darauf hin, dass unsere SIP-Brücke keinen RTP-Datenverkehr vom anderen SIP-Endpunkt empfangen konnte.

    • 705 -- "Max Duration" -- Der Anruf hat die maximale Dauer erreicht.

    • 706 -- "Max Inactive" -- Der Anruf hat die maximale Inaktivitätsdauer erreicht.

  • reason_message -- Für ein callDestroyed Veranstaltung, reason_message ist eine Zeichenkette, die den Grund beschreibt, warum der Aufruf abgebrochen wurde.

  • state -- Für ein callUpdated Veranstaltung, state ist auf einen der folgenden Werte eingestellt:

    • DIALING -- SIP-Anruf wurde eingeleitet

    • RINGING -- Der SIP-Anruf läutet gerade

    • ON_HOLD -- SIP-Anruf wird gehalten

    • ACTIVE -- Ein SIP-Anruf wurde angenommen und wird gerade ausgeführt

    • HANGUP -- Ein SIP-Anruf abgeschlossen

  • timestamp -- Der Zeitstempel des Ereignisses, in Millisekunden seit der Unix-Epoche

  • call -- Ein Objekt, das die Verbindung definiert und die folgenden Eigenschaften enthält:

    • id -- Die Konferenz-ID

    • connectionId -- Die Verbindungs-ID des SIP-Clients

    • createdAt —- Der Zeitstempelwert in Millisekunden seit der Unix-Epoche, der den Zeitpunkt angibt, zu dem der Aufruf erstellt wurde

Überlegungen zur Sicherheit

Vonage empfiehlt einige bewährte Vorgehensweisen für die Nutzung der SIP-Schnittstelle mit Ihren SIP-Servern. Das Unternehmen versucht, mögliche Angriffe abzuwehren, indem es Mechanismen bereitstellt, mit denen überprüft und autorisiert werden kann, dass die auf Ihrem Server empfangenen SIP-Anrufe legitim sind, und indem die gesamte Signalisierung und alle Medien verschlüsselt werden:

  • Verwenden Sie TLS und aktivieren Sie sichere Anrufe (SRTP) für die Signalisierung, um das Risiko eines Abfangens der Kommunikation zu vermeiden.

  • Aktivieren Sie die SIP-Authentifizierung auf Ihrem Server. Andernfalls könnte jeder, der Ihre SIP-URI kennt, Anrufe an Ihren Server senden.

Kontakt wenn Sie weitere Fragen haben.

Technische Einzelheiten

Unterstützung von RFC3550 (RTP/RTCP): Der Medienverkehr kann verschlüsselt (SRTP) oder unverschlüsselt (einfaches RTP) übertragen werden. Im Falle einer Verschlüsselung werden sowohl das DTLS- als auch das SDES-Protokoll unterstützt.

Codec-Unterstützung: Das OpenTok-SIP-Gateway unterstützt die Audio-Codecs OPUS, G.711 und G.722 sowie die Video-Codecs H.264 und VP8. Die Auflösung für SIP-Videos ist auf 480p bei 800 kbit/s begrenzt.

Signalisierung: Das OpenTok-SIP-Gateway unterstützt RFC 3261 (SIP) über UDP, TCP und TLS. Wenden Sie sich an Vonage, wenn Sie Informationen oder Unterstützung zu einer bestimmten Nebenstelle benötigen.

Das OpenTok-SIP-Gateway lehnt alle SIP-Nachrichten ab, die von einer SIP-Plattform eines Drittanbieters stammen, es sei denn, sie sind Teil eines vom OpenTok-SIP-Gateway initiierten SIP-Dialogs. Mit dem OpenTok-SIP-Gateway initiierte Anrufe können entweder mithilfe eines re-­INVITE mit dem sendonly/inactive Richtung im SDP oder eine re-­INVITE mit Port 0 in der SDP.

Andere Überlegungen: Frühe Medien sind deaktiviert.

Applications

Die OpenTok-Server-SDKs für Node und PHP enthalten Beispielaufrufe der OpenTok-Dial-API, bei denen die OpenTok-SIP- Interconnect-Funktionalität zum Einsatz kommt. Beispiele finden Sie unter:

Im Folgenden finden Sie Beispiele für SIP-Integrationen unter Verwendung von OpenTok SIP Interconnect mit Nexmo:

FAQ

Was ist SIP? Warum ist SIP wichtig?

Das Session Initiation Protocol (SIP) ist ein Kommunikationsprotokoll zur Signalisierung und Steuerung von Multimedia-Kommunikationssitzungen. Die häufigsten Applications von SIP sind die Internet-Telefonie für Sprach- und Videoanrufe sowie Instant Messaging über Internet Protocol (IP)-Netze.

In unserem Fall wird es verwendet, um eine Verbindung von OpenTok-Sitzungen zu einem SIP-Server eines Drittanbieters herzustellen. Sobald die Verbindung hergestellt ist, werden die Audio- (und gegebenenfalls auch die Video-)Daten über das RTP-Protokoll übertragen.

Was ist der Unterschied zwischen SIP und PSTN? Bietet OpenTok ein PSTN-Gateway an?

Das PSTN ist das traditionelle Telefonnetz. Das PSTN ist kein IP-Netz und verwendet kein SIP, aber viele Anbieter, wie Nexmo, verfügen über Gateways, die SIP-Protokolle in PSTN-Protokolle umwandeln. Auf diese Weise wird ein SIP-Anruf über IP in einen Telefonanruf umgewandelt.

Praktisch gesehen können wir dies auch dann ermöglichen, wenn die Vonage Video API keine PSTN-Anrufe unterstützt, indem wir SIP-Anrufe nutzen. Dann muss lediglich ein Anbieter gefunden werden, der SIP-Anrufe in PSTN-Anrufe umwandelt.

Kann ich mit der OpenTok-SIP-Interconnect-Funktion normale Telefone anrufen?

Mit OpenTok SIP Interconnect können Partner Anrufe an beliebige SIP-Endpunkte initiieren. Um Anrufe an ein normales Telefon zu tätigen oder von diesem zu empfangen, benötigen Kunden auf ihrer Seite ein Gateway, das den SIP-Anruf in die in Mobilfunk- und Festnetzen verwendeten Protokolle umwandelt.

Gibt es eine Möglichkeit, die Aus- und Einwahl von einer normalen Telefonnummer (PSTN) zu steuern?

Mit OpenTok SIP Interconnect können Kunden aus einer OpenTok-Sitzung heraus zu jedem beliebigen SIP-Ziel anrufen. Darüber hinaus können Kunden ein SIP-Gateway (entweder ihr eigenes oder das eines Drittanbieters) so konfigurieren, dass Anrufe an eine normale Telefonnummer getätigt werden können.

Obwohl die SIP-Interconnect-API keine eingehenden SIP-Anrufe unterstützt, können Kunden das Einwählen über ein normales Telefon (PSTN) implementieren, indem sie ein SIP-Gateway (eigenes oder von Drittanbietern) verwenden, um den von normalen Telefonen empfangenen eingehenden Anruf mit dem von OpenTok ausgehenden SIP-Anruf zu verbinden. Beispielapplications, die den Anwendungsfall „Konferenzschaltung“ veranschaulichen, finden Sie hier hier.

Unterstützt OpenTok SIP Interconnect die Übertragung von Videodaten?

Ja. Stellen Sie die video Flagge zu true beim Aufbau des SIP-Anrufs unter Verwendung der REST-API-Verfahren. SIP-Video ist auf 480p bei 800 kbps begrenzt.

Gibt es einen spürbaren Unterschied in der wahrgenommenen Audioqualität am WebRTC-Endpunkt im Vergleich zum SIP-Endpunkt?

Es wird erwartet, dass die Qualität gleich bleibt, allerdings mit einer zusätzlichen Latenzzeit am SIP-Endpunkt.

Wie funktioniert die Archivierungsfunktion bei OpenTok SIP Interconnect?

Die Archivierungsfunktion funktioniert genauso wie bisher bei einer WebRTC-Sitzung. Bis zu 16 Videostreams und die ersten 50 Audiostreams, einschließlich SIP-Audio- und -Videostreams, werden in das Archiv aufgenommen.

Wie navigiert der Benutzer durch die IVR? Wird es eine Wähltastatur in der Web-/Mobil-App geben?

Sie können die REST-API nutzen, um DTMF-Signale an SIP-Clients zu senden und so Interactive-Voice-Response-Systeme (IVR) zu unterstützen. Siehe Senden von DTMF-Signalen.

Mit welchen SIP-Servern ist OpenTok SIP Interconnect kompatibel?

Wir haben die Interoperabilität mit einigen der populärsten Telekommunikationsausrüstungen (ACME packet, Broadsoft), einigen populären SIP-Plattformen (Nexmo und andere) und dem populärsten Open-Source-SIP-Server (freeswitch) getestet. Es ist unmöglich, die Interoperabilität mit jedem einzelnen SIP-Server zu gewährleisten, aber wir versuchen, die Verwendung von SIP-Erweiterungen/Funktionen einzuschränken, um die Wahrscheinlichkeit von Fehlern zu verringern. Bisher mussten wir unsere Lösung noch nie ändern, um mit einem neuen SIP-Server zusammenzuarbeiten.

Wie kann man einen Anruf zu einem SIP-Client trennen, der mit einer OpenTok-Sitzung verbunden ist?

  • Verwendung der vorhandenen Client-API – Ein Web-Client (JavaScript), der mit einer OpenTok-Sitzung verbunden ist und über Moderatorenrechte verfügt, kann andere Clients, einschließlich SIP-Clients, dazu zwingen, die Verbindung zur Sitzung zu trennen.

  • Die Verwendung des REST-API für die serverseitige Moderation — Befinden sich die WebRTC-Clients auf Mobilgeräten oder möchte der Kunde den Clients keine Moderatorenrechte gewähren, können Anwendungsserver einen HTTP-DELETE-Befehl an einen verbundenen Client senden, um die Trennung der Verbindung serverseitig zu erzwingen.

Bekanntes Problem

Wenn ein SIP-Videoanruf an einen Linphone-SIP-Client getätigt wird und der Videoanruf über den VP8-Codec ausgehandelt wird, wird das von Linphone an das OpenTok-SIP-Gateway gesendete Videobild als schwarze Bilder angezeigt.