[behoben] iFMC: Anruf bricht nach Annahme ab

Siehe oben. Das Problem tritt häufiger auf, wenn der Gesprächspartner eine Telefonanlage mit Warteschleifenmusik o.ä. geschalten hat.

Hallo zusammen,

danke für eure Antworten! Die relevanten Einträge im Logfile schauen für mich in Ordnung aus:

[2023-01-24 16:02:52,233] VERBOSE[265333][C-0000a82e] app_dial.c: SIP/+49821[StarfaceSIPTrunk]-00001c01 answered Local/00491769[MeinHandy]@international-00000501;1
[2023-01-24 16:02:52,234] VERBOSE[265343][C-0000a82e] bridge_channel.c: Channel SIP/+49821[StarfaceSIPTrunk]-00001c01 joined 'simple_bridge' basic-bridge <f98e643a-e263-4655-ba02-ac27c2156530>
[2023-01-24 16:02:52,235] VERBOSE[265333][C-0000a82e] bridge_channel.c: Channel Local/00491769[MeinHandy]@international-00000501;1 joined 'simple_bridge' basic-bridge <f98e643a-e263-4655-ba02-ac27c2156530>
[2023-01-24 16:03:02,442] VERBOSE[265338][C-0000a82d] bridge_channel.c: Channel SIP/+49821[StarfaceSIPTrunk]-00001c00 left 'simple_bridge' basic-bridge <557e2f7f-c74f-4f61-b7b6-10eb9cccb5fa>
[2023-01-24 16:03:02,451] VERBOSE[265334][C-0000a82d] bridge_channel.c: Channel Local/00491769[MeinHandy]@international-00000501;2 left 'simple_bridge' basic-bridge <557e2f7f-c74f-4f61-b7b6-10eb9cccb5fa>
[2023-01-24 16:03:02,593] VERBOSE[3914] manager.c: Manager 'actionasterisk' from 127.0.0.1, hanging up channel: Local/00491769[MeinHandy]@international-00000501;2
[2023-01-24 16:03:02,594] VERBOSE[265334][C-0000a82d] pbx.c: Spawn extension (international, 00491769[MeinHandy], 4) exited non-zero on 'Local/00491769[MeinHandy]@international-00000501;2'
[2023-01-24 16:03:02,594] VERBOSE[265334][C-0000a82d] pbx.c: Executing [h@international:1] NoOp("Local/00491769[MeinHandy]@international-00000501;2", "HC 16") in new stack
[2023-01-24 16:03:02,594] VERBOSE[265334][C-0000a82d] pbx.c: Executing [h@international:2] Goto("Local/00491769[MeinHandy]@international-00000501;2", "_exit_,0") in new stack
[2023-01-24 16:03:02,594] VERBOSE[265334][C-0000a82d] pbx_builtins.c: Goto (international,_exit_,0)
[2023-01-24 16:03:02,596] VERBOSE[265333][C-0000a82e] bridge_channel.c: Channel Local/00491769[MeinHandy]@international-00000501;1 left 'simple_bridge' basic-bridge <f98e643a-e263-4655-ba02-ac27c2156530>
[2023-01-24 16:03:02,598] VERBOSE[265333][C-0000a82e] pbx.c: Spawn extension (international, 07315032168, 4) exited non-zero on 'Local/00491769[MeinHandy]@international-00000501;1'
[2023-01-24 16:03:02,598] VERBOSE[265333][C-0000a82e] pbx.c: Executing [h@international:1] NoOp("Local/00491769[MeinHandy]@international-00000501;1", "HC 16") in new stack
[2023-01-24 16:03:02,598] VERBOSE[265333][C-0000a82e] pbx.c: Executing [h@international:2] Goto("Local/00491769[MeinHandy]@international-00000501;1", "_exit_,0") in new stack
[2023-01-24 16:03:02,598] VERBOSE[265333][C-0000a82e] pbx_builtins.c: Goto (international,_exit_,0)
[2023-01-24 16:03:02,601] VERBOSE[265343][C-0000a82e] bridge_channel.c: Channel SIP/+49821[StarfaceSIPTrunk]-00001c01 left 'simple_bridge' basic-bridge <f98e643a-e263-4655-ba02-ac27c2156530>
[2023-01-24 16:03:02,806] NOTICE[3914] manager.c: Request to hangup non-existent channel: Local/00491769[MeinHandy]@international-00000501;1

Schau ich in den TCP Dump, läuft das Gespräch augenscheinlich einwandfrei ab. Das Gespräch endet, wenn der SIP Trunk ein "BYE" Paket für die iFMC Leitung schickt. Anschließend sendet die Starface ein "BYE" Paket an den Sip Trunk für das Gespräch mit dem Angerufenen. Dementsprechend wäre die Starface fein raus, weil mein Handy den Hangup initiiert und die Starface das korrekt zur Kenntnis nimmt.

Zur Firewall: SIP-ALG ist deaktiviert, UDP Flusskontrolle scheint unsere Firewall nicht zu können. Die eingehenden Ports waren jedoch nicht richtig gesetzt! Eine eingehende Portweiterleitung für Port 10.000–20.000 scheint die Lösung zu sein. Zumindest erreiche ich nun die Telefonnummer, die bislang Probleme bereitete. Komisch ist, dass unser Trunk-Anbieter in der Dokumentation als Portbereich für Mediadaten 16.384 - 65.535 angibt, die Starface jedoch eingehend 10.000 bis 20.000 und ausgehend 1.025 bis 65.535.

Eingehend sind nun die Ports 5060 und 5061 zur Signalisierung sowie 10.000–20.000 für Audiodaten freigegeben. Ausgehend gibt es keine Beschränkung, deswegen habe ich keine weiteren Regeln angelegt.

Quote

Anrufer == Eingehender Anruf ==> STARFACE == Ausgehender Anruf ==> [Mobilnr]

Hier wird für einen eingehenden Anruf ein Ausgehender Anruf auf deine Mobilnr platziert.

Quote

Bei einem ausgehenden Anruf

[Mobilnr] <== Ausgehender Anruf == STARFACE == Ausgehender Anruf ==> [Zielnummer]

Das ist tatsächlich variabel, ich bekomme dazu unterschiedliche Hinweise. Nachdem jetzt eine exemplarische Rufnummer funktioniert, warte ich auf Rückmeldungen der Kollegen. Ich melde mich wieder. Hoffentlich mit der Nachricht, dass alles nun funktioniert. Besten Dank für eure Unterstützung!

Vorweg zusammengefasst: Ich erhalte im Fehlerfall vom Trunk kein einziges RTP-Paket. Ich frag mal nach, ob auf seiner Seite etwas nicht stimmt.

Danke noch einmal für euren Input. Leider hat sich die Situation noch nicht verbessert. Mit oben beschriebenen Einstellungen (Port Forwarding/Destination NAT auf 5060, 5061, 5222, 10000-2000), "Hinter NAT: Ein" und "Qualify" komme ich auf regelmäßig folgendes Fehlverhalten:

- Eingehender iFMC Anruf: Abgenommen, man konnte niemanden hören, nach ca. 7s automatisch aufgelegt

- Eingehender iFMC Anruf: Abgenommen, man konnte niemanden hören, es wurde nicht automatisch aufgelegt; irgendwann haben wir am Telefon den Auflegen-Knopf gedrückt

- Ausgehender iFMC Anruf: hat funktioniert, aber nach knapp 5 Minuten haben wir den Gesprächspartner nicht mehr gehört, er aber uns noch; dasselbe passierte auch bereits andersrum

Jetzt ist es so, dass diese Konfiguration nicht optimal ist, weil die Blacklist in der Starface explodiert. Nach einiger Recherche habe ich die "beste" Konfiguration so verstanden:

- Keine Portweiterleitungen

- Einstellung "Hinter NAT: Aus" (hiermit scheint Destination NAT gemeint zu sein, siehe RE: [gelöst] Sipgate Leitung geht ohne Port Forwarding)

- Firewall testweise gnädigerweise offen

Nun sind wir wieder beim eingangs beschriebenen Verhalten, dass ich beim ausgehenden iFMC Anruf an die 0731 50 32168 nichts höre und nach etwa 9 Sekunden automatisch aufgelegt wird. Ich gehe davon aus, dass eingangs beschriebenes iFMC Verhalten auch bei Kollegen weiterhin auftreten wird – melde mich dazu aber gerne.

Jetzt habe ich mir mal ein paar TCP Dumps angeschaut. Erst einen Mitschnitt eines ordentlichen Telefonats, dann eines "kaputten" Telefonats. Da mich auch interessiert, welche Pakete ankommen und abgelehnt werden, habe ich den Mitschnitt direkt an der Schnittstelle zwischen Router und Internet angefertigt.

Falls Bedarf besteht, kann ich einen Screenshot in zensierter Form hochladen. Ein normaler Anruf läuft wie folgt ab:

Quote

Es beginnt mit der klassische Sip Authentifikation. Es folgt ein INVITE, RINGING, sowie ein 200 OK (INVITE) mit meiner Handynummer. Anschließend gibt es erneut Authentifikation, INVITE und RINGING zur Zielrufnummer. Bevor es zum 200 OK (INVITE) kommt, tauschen mein Handy und die Starface RTP Pakete aus. Nach dem 200 OK (INVITE) fließen vier RTP-Paketarten zwischen Starface <=> SIP Trunk: 1x eingehend und 1x ausgehend pro Verbindung.

Eingehende RTP-Pakete haben nicht den klassischen Zielport 10.0000–20.000 auf der Starface, welcher im SDP angefordert wurde, sondern einen anderen. Hier ersetzt unser SIP-Trunk-Anbieter die Ports passend:

Quote

Um NAT auf RTP-Ebene zu erkennen, werden die Source-IP und der Source-Port des ersten RTP Paketes, das von der IP-PBX beim Vermittlungssystem eintrifft verwendet, um den Mediastrom an diese IP-Adresse und Port zu senden.

Soweit so gut. Das scheint auch zu funktionieren. Schickt die Starface ein 200 OK (BYE), erhalten wir vom Trunk ein 200 OK (BYE) zurück. Ich sehe, dass noch wenige UDP-Pakete eintreffen, die mit einem ICMP "Destination unreachable (Port unreachable) abgewunken werden. Ich schneide also alles Relevante mit.

Was soll ich sagen. Beim Anruf an die 0731 50 32168 spielt sich exakt das selbe ab, bis auf zwei Punkte:

1. Bei INVITE der Zielrufnummer: Nach "100 TRYING" kommt "183 Session Progress", anschließend "200 OK (INVITE)". In allen anderen Fällen erhalte ich sein "180 Ringing" anstelle des "183 Session Progress".

2. Es fließt kein einziges RTP-Paket. Weder für meine Handynummer, noch für die Zielrufnummer. Da ich hier quasi direkt an der Schnittstelle zum Internet abgreife, muss ich davon ausgehen, dass der SIP-Trunk nichts rausschickt. Meine Firewall und NAT jammern nicht. Ich sende kein ICMP "Unreachable" o.ä. raus.

Ich frag mal beim Trunk-Anbieter an, was da los ist und melde mich, wenn ich mehr weiß. Noch einmal besten Dank für eure Denkanstöße, wie man an die Sache rangeht! Erst einmal das Wichtigste: überhaupt telefonieren können. Warum Gespräche nach einiger Zeit abbrechen können, ist im Forum ganz gut dokumentiert ("UDP-Aging"). Das ist dann nur noch Wertespielerei.

In meinem Fall spielten zwei Fehler mit rein:

1. RTP Pakete kamen nicht durch die Firewall an die Starface. Hier mussten also zwingend die im Wiki genannten eingehenden Ports zur Starface weitergeleitet werden.

2. Es kam zum Fehlerfall, wenn ein neuer Codec ausgehandelt werden musste. Ich konnte ein Beispiel aufzeichnen, bei dem über iFMC jemand ausgehend angerufen wird. Das Telefonat Starface <=> Handy intern läuft dabei auf g722. Das anschließend aufgebaute Telefonat Starface <=> Extern läuft zunächst auf auf g722, bis der SIP Trunk nach wenigen Paketen plötzlich g711a schickt. Die Starface schickt weiterhin g722, bis der Trunk die Verbindung trennt. Zumindest interpretiere ich das so. Kann auch anders sein, aber irgendein plötzlicher Wandel von g722 auf g711a findet statt, welcher die Verbindung trennt. Lösung: g722 und prophylaktisch g729 deaktivieren. Seitdem ist Ruhe.