[Problem] Fritz!Box verarbeitet BYE von Asterisk nicht

[crispinus]

Hallo,
bei der Konfiguration einer kleinen Telefonanlage mit Asterisk hinter einer Fritz!Box tritt das Problem auf, dass die Fritz die BYE-Nachricht von Asterisk nach Hangup() nicht wahrnimmt (Asterisk versucht mehrfach zu retransmitten) und deshalb dem anrufenden Teilnehmer kein Besetzt signalisiert.
Zum Setup: auf der Fritz!Box wurde ein Konto für Asterisk angelegt, dieses funktioniert auch (Asterisk kann sich erfolgreich registrieren).
Ich rufe dann mit einem an der Fritz!Box angemeldeten DECT-Telefon (**611) die Asterisk-Nebenstelle an (**622). Das Gespräch kommt zustande, Asterisk kann das Gespräch annehmen und z.B. ein File abspielen, was dann am Telefon auch hörbar ist. Am Ende des Dialplans kommt ein Hangup(), welches auch dazu führt, dass Asterisk eine entsprechende BYE-Nachricht an die Fritz!Box verschickt, es ertönt aber kein Besetzt-Signal (die Message kommt offenbar auch gar nicht an oder wird nicht beantwortet, da mehrere Retransmissions folgen).

Im Log schaut das aus wie im angehängten File.

Was läuft hier falsch? Da alle Phasen des Anrufs bis aufs BYE tadellos funktionieren, kommt ein Firewall-Problem eigentlich nicht in Frage (auf dem Asterisk-Host läuft auch eine Firewall, diese hat aber alle relevanten Ports wie 5060-5080 und 10000-20001 (RTP-Ports) geöffnet). Auch mit abgeschalteter Firewall läuft es zudem nicht.
Es kann also eigentlich nur an der Zusammensetzung der BYE-Nachricht liegen, ich kenne mich aber zu wenig im SIP-Standard aus um hier den Fehler zu sehen und freue mich über Hilfe...

VG crispinus

 

[PeterPawn]

die Message kommt offenbar auch gar nicht an oder wird nicht beantwortet

Das zeigt ja der Blick in die Support-Daten der FRITZ!Box ... wenn man dann weiß, ob sie tatsächlich ankommt, macht es auch Sinn, sich über den Aufbau der Message Gedanken zu machen.

Kommt sie nicht an, muß man ohnehin woanders suchen ... denn

(a) steht in #1 nicht wirklich, ob das ausschließlich im LAN der FRITZ!Box erfolgt (es käme ja auch "reg_from_outside" infrage) und eine Firewall (mit einem UDP-Timeout, denn es steht in #1 auch nichts, wie lang das abgespielte Sprach-File nun war/ist) käme ansonsten durchaus auch in Betracht und

(b) wäre es - sofern es doch ein Firewall-Problem ist - dann ja eher die FRITZ!Box-Seite der Verbindung, wo die Firewall (eingehenden) Traffic abweist, solange das Asterisk nicht ausgehenden Verkehr filtert. Und da wüßte ich dann nicht, wie Du in der FRITZ!Box die Firewall abschalten willst ... außer es gibt eben tatsächlich gar kein "WAN".

Aber das steht eben alles nicht in #1 ... würde hier anstelle von UDP aber gleich TCP verwendet (was ja kein Problem darstellen dürfte, die FRITZ!Box unterstützt beide Protokollvarianten), würde eine Firewall mit "connection tracking" diese Verbindung auch erst dann abräumen, wenn die jeweiligen FIN-Pakete gesichtet wurden - da gibt es dann kein (ggf. zu kurzes) UDP-Timeout.

 

[koyaanisqatsi]

Moinsen


Das "BYE" kommt an und wird auch beantwortet, siehe "CSeq:" und "User-Agent:"...

<--- SIP read from UDP:192.168.1.3:5060 --->
BYE sip:**[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bKBD29E185A806C049
From: "Julian" <sip:**[email protected]>;tag=7933D1827BA48659
To: <sip:**[email protected]:5060>;tag=as06f30c6e
Call-ID: [email protected]
CSeq: 64 BYE
X-RTP-Stat: CS=11;PS=124;ES=275;OS=19840;SP=0/0;SO=0;QS=-;PR=0;ER=275;OR=0;CR=0;SR=0;QR=-;PL=0,0;BL=0;LS=0;RB=0/0;SB=0/0;EN=PCMU;DE=;JI=0,0;DL=0,0,0;IP=192.168.1.3:7086,192.168.1.110:15770
X-RTP-Stat-Add: DQ=0;DSS=0;DS=0;PLCS=0;JS=0
X-SIP-Stat: DRT=0;IR=0
Reason: Q.850; cause=16
Max-Forwards: 70
User-Agent: AVM FRITZ!Box 6490 Cable (lgi) 141.07.01 TAL (Oct 22 2018)
Supported: 100rel,replaces,timer
Allow-Events: telephone-event,refer
Content-Length: 0

PS: Meine Erfahrungen mit Asterisk...
1. Alle Extensions die ein Dial() machen, brauchen weder Answer() noch Hangup()
...denn dass machen die Endgeräte ja schon.
...ohne Hangup() gibt es ein "Autofallthrough" mit Hangup(16).
...außerdem wird versucht die Extension "h" auszuführen.
2. Sprachprompts und Ansagen benötigen dagegen zwingend ein Answer() und Hangup()
...denn das Answer() öffnet die RTP Sprachkanäle und wenn das Timeout erreicht wird sorgt dann das Asteriskseitige Hangup() für ein ordentliches Ende ( und schliessen der Sprachkanäle ).

 

[crispinus]

Hallo,
vielen Dank für die bisherigen Antworten. Ich habe versuchsweise in Asterisk die sip.conf mit tcpenable=yes versehen und die entsprechenden Einzeleinträge um transport=tcp ergänzt. Das Verhalten verändert sich nicht, die Bye-Message wird weiterhin mehrfach erneut übertragen und nicht beantwortet.
Die beantwortete Bye-Message, die man ganz am Ende des Logs sieht, ist übrigens entstanden, nachdem dann das DECT-Telefon aufgelegt wurde, sie ging also originär von der Fritz!Box aus und wurde von Asterisk korrekt beantwortet. Nicht beantwortet wird aber die davor stehende, von Asterisk initiierte Bye-Message, die wird eben auch mehrfach übertragen, da von der Fritz keine Reaktion erfolgt. Da alle anderen Teile des Anrufs funktionieren (ich habe u.a. auch schon mit einer längeren Bandansage sowie Auswahlmenüs und Verbindungen zu anderen Nebenstellen über Dial() getestet, all das läuft) scheint mir ein Firewall-Problem, egal auf welcher Seite, eher auszuschließen zu sein.
Wenn man sich die Bye-Message von Asterisk anschaut, so steht dort hinter sip: die im Contact-Header genannte Sequenz, während die von der Fritz! gesendete Bye-Message nach Auflegen des DECTs hinter dem BYE in der sip-Adresse die Nebenstelle direkt benennt, an die die Bye-Message gerichtet ist (**622). Liegt hier vielleicht das Problem?

VG crispinus

 

[PeterPawn]

Das "BYE" kommt an und wird auch beantwortet

Nur das aus der "falschen Richtung", also das vom DECT-Telefon (611) ausgehende und damit vom FRITZ!OS erzeugte. Das erkennt man - nebenbei - auch an den "X-RTP-Stat"-Headern, die die Infos zur Qualität der Verbindung wiedergeben, die man sich auch im GUI für die IP-Calls ansehen kann - die werden so (afaik) nur vom FRITZ!OS erzeugt und ich rate mal ganz kräftig, daß das ursprünglich ein "Service" für 1&1 war.

-----------------------------------------------------------------------------------------

Mich würde ja weiterhin interessieren, ob die Message nun ankommt in der FRITZ!Box oder nicht. AVM ist ja an einigen Stellen (nach meiner Erfahrung zumindest) eher "schweigsam", teilweise auch im Hinblick auf die Reaktionen in Form von Fehlernachrichten in einem SIP-Dialog.

Das ist per se auch richtig, weil man (gerade mit UDP dank der nicht eindeutig geklärten Identität des Gegenübers) auch Attacken fahren kann, bei denen so ein Registrar (oder UAS/UAC) als "amplifier" benutzt wird, indem er Nachrichten/Quittungen an einen Empfänger schickt, der diese gar nicht angefordert hatte, weil jemand eine gefälschte Absenderadresse bei UDP verwendet hat. Und da es bei einigen SIP-Messages keine Authentifizierung gibt (ein "BYE" hat z.B. keine), kann man so etwas durchaus zum Multiplizieren von Datenmengen mißbrauchen und wo ein einziger Client noch kein Problem ist, weil er zwischen Wiederholungen ja wartet, ist das bei 1.000 oder 10.000 parallel angegriffenen UAS (denn hier ist die Box ja in dieser Rolle) dann schon eher ein Problem.

Da ist es dann eine Gratwanderung, ob und wann man auf eine SIP-Message mit dem passenden Fehlercode und einer Antwort reagiert und wann man einfach auf jede Reaktion verzichtet, weil die Message so offensichtlich nicht zu einem aktiven SIP-Dialog gehört. Eigentlich ist die von Asterisk verwendete "Contact"-Angabe ja genau dafür da um anzuzeigen, wo (unter welcher URI) der Peer weitere Nachrichten empfangen will und die hier von Asterisk verwendete "Contact"-Angabe ist genau die aus der vorhergehenden Bestätigung seitens der FRITZ!Box. Da sollte also die URI eigentlich nicht der Grund sein, warum die Message der FRITZ!Box nicht schmeckt. Die Zuordnung der Nachricht zum korrekten Dialog sollte anhand der From- und To-Header (samt Tag zur Unterscheidung bei mehreren Dialogen) und der Call-ID erfolgen ... aber wie bereits geschrieben: Erst mal klären, daß die Message auch tatsächlich beim "voipd" ankommt und von ihm verworfen/ignoriert wird - vorher machen weitere Überlegungen gar keinen richtigen Sinn.

 

[gehtdoch]

Wenn man sich die Bye-Message von Asterisk anschaut, so steht dort hinter sip: die im Contact-Header genannte Sequenz, während die von der Fritz! gesendete Bye-Message nach Auflegen des DECTs hinter dem BYE in der sip-Adresse die Nebenstelle direkt benennt, an die die Bye-Message gerichtet ist (**622). Liegt hier vielleicht das Problem

Solange man nicht sicher weiß, dass das Paket überhaupt ankam ... .

Ich würde mir diese quasi nicht betreibbare Konstruktion keine Sekunde antun. FB raus, ein Modem rein und den Asteriskserver die Internetverbindung aufbauen lassen. Damit hat er dann auch die InternetIP und man muss sich nicht mit NAT rumschlagen. Außerdem ist die Fehlerquelle FB weg und man kann ordentlich debuggen / analysieren bei Problemen.

 

[roussel2nis]

Hi guys,

Sorry not speaking German.

I have the same problem when I use the FritzBox as a trunk for PSTN interface.

When external caller is hanging up, Asterisk does not detect that hang up and the scripts are executed until error.

In that case, I don't see "BYE" from FritzBox to Asterisk.

 

[hannes_h]

Hallo crispinus,

ich habe das selbe Problem.
konnte das Problem mittlerweile gelöst werden?

 

[remoter3406]

Hallo zusammen,

hier auch das gleiche Problem, ich nutzte PJSIP

Mit dem SIP Client Phonerlite funktioniert es

Phonerlite

----OK----

13:16:13,536: T: 192.168.1.254:5060 (UDP)
BYE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bK803ca259417eea11ae8411a2c8c4684e;rport
From: <sip:[email protected]:5060>;+sip.instance="<urn:uuid:80B8CA41-417E-EA11-AE7E-11A2C8C4684E>";tag=8088dd54417eea11ae8411a2c8c4684e
To: <sip:[email protected]>;tag=0B6A23541EC3D869
Call-ID: [email protected]
CSeq: 7 BYE
Contact: <sip:[email protected]:5060;gr=80B8CA41-417E-EA11-AE7D-11A2C8C4684E>
Max-Forwards: 70
User-Agent: PhonerLite 2.77
Content-Length: 0
-------------------------------------------

13:16:13,549: R: 192.168.1.254:5060 (UDP)
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bK803ca259417eea11ae8411a2c8c4684e;rport=5060
From: <sip:[email protected]:5060>;+sip.instance="<urn:uuid:80B8CA41-417E-EA11-AE7E-11A2C8C4684E>";tag=8088dd54417eea11ae8411a2c8c4684e
To: <sip:[email protected]>;tag=0B6A23541EC3D869
Call-ID: [email protected]
CSeq: 7 BYE
X-RTP-Stat: CS=100;PS=123;ES=290;OS=19680;SP=0/0;SO=0;QS=-;PR=289;ER=290;OR=46240;CR=0;SR=0;QR=-;PL=0,0;BL=0;LS=0;RB=0/0;SB=-/-;EN=PCMA;DE=PCMA;JI=0,1;DL=1,1,1;IP=192.168.1.254:7078,192.168.1.2:5062
X-RTP-Stat-Add: DQ=3;DSS=0;DS=0;PLCS=32;JS=1
X-SIP-Stat: DRT=8;IR=0
User-Agent: AVM FRITZ!Box 7490 113.07.11 TAL (May 10 2019)
Supported: 100rel,replaces,timer
Allow-Events: telephone-event,refer
Content-Length: 0

######################################

Asterisk
----keine Antwort----

<--- History Entry 21 Sent to 192.168.1.254:5060 at 1587024496 --->
BYE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.114:5060;rport;branch=z9hG4bKPj09974d7a-ca2c-4d6b-b22f-78b1e56c6c7f
From: <sip:[email protected]>;tag=a0912832-19dc-46f7-8989-2f130526fecb
To: <sip:[email protected]>;tag=4FF1E73BCA62943A
Call-ID: [email protected]
CSeq: 4159 BYE
Reason: Q.850;cause=16
Max-Forwards: 70
User-Agent: Asterisk PBX 17.3.0
Content-Length:  0

Ich tippe auf das 'From' beim Asterisk ist das die Extension nicht der Anmeldename.
Kann man das anpassen?

 

[remoter3406]

So ich habe es gefunden

es ist das 'From' dort MUSS der Benutzername der in der Fritzbox eingetragen ist drin sein.
Lösung ist der contact_user bei der Registration, dort den Benutzernamen der Fritzbox eintragen.

Unschöner nebeneffekt:
Der Username in der Fritzbox muss 8Zeichen lang sein, so das ich nicht mehr meine 6stellige Rufnummer eintragen kann,
die ich bei der Exten und in einer externen Applikation ausgewertet habe.
Ich habe für mich 'LTG' vor die Rufnummer gesetzt und das in der Applikation entfernen lassen.
Alternativ könnte man z.b. auch die Vorwahl vorsetzten.

Ich hoffe es hilft bei eueren Problem genauso.

 

[to-scho]

Für die wenigen, die chan_sip (sip.conf) und nicht res_pjsip (pjsip.conf) verwenden ist die Lösung auch einfach:

Man muss die Extension bei der Registrierung an der Fritzbox gleich dem fritzbox_username des IP Telefons der Fritzbox benennen:
register=fritzbox_username:fritzbox_password@fritzbox_ip/fritzbox_username

Ich hatte ganz hinten die extension entsprechend dem heise Artikel "Überallklingel" anders benannt und damit das hier beschriebene Problem bekommen.