[Problem] Asterisk WebRTC SIP.js - Höre die ersten Sekunden nicht

[Hativ3]

Hallo,

ich betreibe eine Asterisk 16 Installation und ein WebPhone auf Basis von SIP.js. Leider höre ich oft die ersten paar Sekunden nicht, wenn ich jemanden anrufe. So wird z.B. von der Ansage "Ihr Anruf konnte nicht entgegen genommen werden, bitte hinterlassen Sie eine Nachricht nach dem Ton." mal mehr oder weniger viel von "Ihr Anruf" abgeschnitten. Bei eingehenden Anrufen ist alles in Ordnung.

Der Asterisk steht in einem Rechenzentrum, der Browser/Client ist hinter NAT.

Die Verzögerung ist im Asterisk-Log hier zu sehen (Sekunde 11 zu 13):
[Nov 2 17:58:11] VERBOSE[15217][C-00000002] app_dial.c: PJSIP/hativ-voip-00000003 answered PJSIP/hativ-00000002
[Nov 2 17:58:11] VERBOSE[15226][C-00000002] bridge_channel.c: Channel PJSIP/hativ-voip-00000003 joined 'simple_bridge' basic-bridge <80f71862-7910-4363-97e4-8d8a9e98765f>
[Nov 2 17:58:11] VERBOSE[15217][C-00000002] bridge_channel.c: Channel PJSIP/hativ-00000002 joined 'simple_bridge' basic-bridge <80f71862-7910-4363-97e4-8d8a9e98765f>
[Nov 2 17:58:13] VERBOSE[15217][C-00000002] res_rtp_asterisk.c: 0x7f05cc0773a0 -- Strict RTP qualifying stream type: audio
[Nov 2 17:58:13] VERBOSE[15217][C-00000002] res_rtp_asterisk.c: 0x7f05cc0773a0 -- Strict RTP switching source address to 91.67.195.16:58920
[Nov 2 17:58:13] VERBOSE[15217][C-00000002] res_rtp_asterisk.c: 0x7f05cc0773a0 -- Strict RTP learning complete - Locking on source address 91.67.195.16:58920
[Nov 2 17:58:13] VERBOSE[15226][C-00000002] res_rtp_asterisk.c: 0x7f05cc0860d0 -- Strict RTP switching to RTP target address 212.117.203.158:32406 as source
[Nov 2 17:58:13] VERBOSE[15226][C-00000002] res_rtp_asterisk.c: 0x7f05cc0860d0 -- Strict RTP learning complete - Locking on source address 212.117.203.158:32406

Hat jemand eine Idee, was das sein könnte? Oder Ansatzpunkte für weitere Fehlersuche?

 

[Hativ3]

Niemand eine Idee?

 

[gehtdoch]

Dir wird nichts anderes bleiben als den kompletten Weg zu tracen (pcap) - alles andere ist Kaffeesatzleserei. Vor asterisk / am NAT-GW (oder vor NAT-GW) und auf asterisk selbst. Dann siehst Du wenigstens mal, wo das Delay (nicht) zu Stande kommt. Danach sieht man dann weiter.

 

[sonyKatze]

Hast Du mit der Antwort von gehtdoch arbeiten können? Ich würde das nämlich genauso machen. Irgendwie ein Packet-Trace ziehen und das genauer anschauen. Bei WebRTC wird DTLS-SRTP verwendet. Vielleicht kannst Du es durch ECDSA/AES128 statt RSA/AES256 beschleunigen. Oder es ist ein ICE/STUN-Ding. Was mir an Deinem Log noch auffällt: Wird es besser, wenn Du testweise mal strictrtp=no in der Konfigiurationsdatei rtp.conf setzt?

 

[Hativ3]

strictrtp=no hat leider keine Verbesserung gebracht.

Hier der Mitschnitt:

Client


192.168 = Mein PC
37.157 = Asterisk

Server


212.117 = VoIP-Anbieter
37.157 = Asterisk
95.88 = Mein PC

Oberste Zeile ist die Anrufannahme bei Sekunde 265. Erst bei Sekunde 267 hört man etwas (die UDP-Pakete).

Sieht für mich so aus als würde mit STUN die Zeit vertrödelt werden, oder? Aber warum?

Nochmal zur Information: Mein PC ist hinter NAT (normaler Internetanschluss mit FRITZ!Box, IPv4), Asterisk im Rechenzentrum mit fester eigener IP-Adresse.

Bilder gemäß Boardregeln geschrumpft by stoney

 

[gehtdoch]

Nun, ich denke, Du hast Dir die Antwort schon selbst gegeben. Mit STUN selbst kenne ich mich nicht aus (ich baue Lösungen dieser Art grundsätzlich nicht auf, weil sie die Sache noch komplizierter machen, als SIP an sich schon ist. Mach doch ein Gateway dazwischen - dann musst Du die NAT-Nummer nicht fahren).

Warum "geht" es bei eingehenden Calls? Hier kann ich nur orakeln, weil der Gesamt-SIP-Trace hier nicht zu erkennen ist:

Damit STUN loslegen kann, werden ja erst mal die SDPs der beiden Beteiligten (asterisk und SIP-Phone) benötigt - vorher kann er mangels Info gar nicht anfangen.

Im Inbound-Fall könnte das Problem deshalb nicht auffallen, weil der eingehende Call via 183 session progress läuft (early media - vom eingehenden Call getriggert) und in diesem Zeitfenster (bis Du abnimmst) dann die STUN-Nummer unbemerkt gefahren werden kann.

Was heißt das aus meiner Sicht für den ausgehenden Fall? Du müsstest Asterisk dazu bewegen, early media zu Dir zu fahren. So würde ich das als Workaround angehen (besser wäre aus meiner Sicht aber immer noch ein Gateway, das Dir die NAT-Nummer erspart und damit Komplexität und Fehleranfälligkeit reduziert - was machst Du, wenn der STUN-Server, aus welchen Gründen auch immer (da kann es viele geben), nicht reagiert -> noch ein Grund mehr, warum ein Call den Bach runter gehen kann, obwohl SIP völlig ok ist).

 

[Hativ3]

Hallo gehtdoch,

was meinst Du mit Gateway?

Early Media habe ich schon mal versucht hinzukriegen, hat aber bisher nicht geklappt. Das lag aber eher an SIP.js als an Asterisk. Ich versuche das nochmal.

 

[gehtdoch]

was meinst Du mit Gateway?

Ziel ist, kein NAT fahren zu müssen. Da Dein Asterisk ja eine Internet-IP hat, musst Du auf der anderen Seite (Clientseite) noch dafür sorgen, dass auch da SIP direkt mit der Internet-IP gefahren werden kann. Das erreichst Du z.B. mit dem Einsatz eines Gateways (welches selbst direkt auf die Internet-IP zugreifen kann - also im Falle von IPv4 auf dem Router selbst läuft, welcher die Internet-IP hat). Dann verbindet sich der SIP-Client mit dem Gateway und das Gateway leitet den Call dann weiter zu Asterisk. Stichworte wären hier SBC (session border controller - asterisk könntest Du z.B. dazu einsetzen) oder SIP Proxy (einfacher - opensips z.B.).
Andere Variante könnte sein, mit IPv6 auf beiden Seiten zu fahren, so dass auch der Client eine Internet-IP (-> globale IPv6-Adresse) bekommt. Auch damit hättest Du NAT vom Tisch - aber dafür auch ein potentielles Security-Loch (muss extra bedacht werden, wenn man es denn macht).

 

[Hativ3]

Das mit dem Gateway ist nicht praktikabel, da auf Asterisk von verschiedenen Orten und auch von unterwegs zugegriffen wird.

Ich habe aber nun wohl early media in SIP.js zum laufen bekommen, und zwar habe ich folgende Optionen gesetzt:

rel100: "required",
inviteWithoutSdp: true,

Aktuell sieht es so aus, als wäre das Problem damit gelöst oder zu mindest stark gemildert.