2 Fritz!Box 7490 - VPN - VoIP Probleme

[Faxenmacher]

Danke Micha & Peter für eure Antworten.

Ich hatte bereits das Telefoniegerät und die eigene Rufnummer nach dem Update gelöscht und neu eingerichtet, womit dann ein zu kurzes Passwort nicht mehr möglich ist.

Peter, wenn ich dich richtig verstehe, möchtest du checken, ob die Box A direkt mit dem VoIP-Provider (Telekom) der Box B kommunizieren will, oder mit Box B und diese dann mit dem VoIP-Provider. Immerhin ist der VoIP-Provider in beiden Boxen magentafarben.

Wie könnte ich denn die von dir angesprochenen SIP-Pakete aus den Fritzen rausholen?

Vielleicht noch ein Symptom: der Anrufer an Box B (zB mein Handy) hört normales Freizeichen, und an der Box B klingelt auch das Telefon.

Gruß vom Faxenmacher!

 

[PeterPawn]

Wie bereits geschrieben, stehen diese Informationen (für begrenzte Zeit) in den Support-Daten (in der Sektion "##### BEGIN SECTION sip SIP messages") und wie man diese Support-Daten aus der FRITZ!Box bekommt, steht entweder in der AVM-KB oder in diversen anderen Beiträgen hier.

 

[Faxenmacher]

Holladiewaldfee, auf die Supportseite der Fritze habe ich bestimmt seit 10 Jahren nicht mehr geschaut. Die kann ja inzw. erheblich mehr #ThumbsUp

Hier dann mal fangfrisch das Protokoll der Box A, wo es nicht klingelt. Ich habe alle anderen Rufnummern deaktiviert, aber irgendwie sippen die immer noch rum. Darum habe ich im Protokoll alles mit anderen Peers rausgefiltert, kann ich aber bei Bedarf nachliefern.

2018-12-03 10:43:13.029 - IN: my=[IPadr Box A]%15:5060 peer=[IPadr Box B] port=5060 UDP, sipiface=none:
INVITE sip:GSTWedel@[IPadr Box A];uniq=1493E306E7B7AC70D05E51C6CB656 2.0
Via: SIP/2.0/UDP [IPadr Box B]]:5060;branch=z9hG4bK20F84FCE26012032
From: <sip:[email protected]>;tag=DB2E6879FFCD8983
To: <sip:GSTWedel@[IPadr Box A];uniq=1493E306E7B7AC70D05E51C6CB656>
Call-ID: F5310B37BEA03736@[IPadr Box B]]
CSeq: 5787 INVITE
Contact: <sip:C67764277970E1F2C0090F0A09A03@[IPadr Box B]]>
Max-Forwards: 70
P-Called-Party-ID: <sip:[MSN Box B]@fritz.box>
Expires: 120
Session-Expires: 600;refresher=uac
Min-SE: 90
User-Agent: AVM FRITZ!Box 7490 113.07.01 (Aug 29 2018)
Supported: 100rel
Supported: replaces
Supported: timer
Allow-Events: telephone-event
Allow-Events: refer
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, PRACK, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, PUBLISH
Content-Type: application/sdp
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length:   413

v=0
o=user 74595 74595 IN IP4 [IPadr Box B]]
2018-12-03 10:43:13.059 - OUT: my=[IPadr Box A]%15:5060 peer=[IPadr Box B]] port=5060 UDP, sipiface=voip tcclass=sip, netmark=0:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP [IPadr Box B]]:5060;branch=z9hG4bK20F84FCE26012032
From: <sip:[email protected]>;tag=DB2E6879FFCD8983
To: <sip:GSTWedel@[IPadr Box A];uniq=1493E306E7B7AC70D05E51C6CB656>
Call-ID: F5310B37BEA03736@[IPadr Box B]]
CSeq: 5787 INVITE
User-Agent: AVM FRITZ!Box 7490 113.07.01 (Aug 29 2018)
Content-Length: 0



2018-12-03 10:43:15.801 - OUT: my=(null) peer=[IPadr Box B]] port=5060 UDP, sipiface=none tcclass=sip_internet, netmark=0:
NOTIFY sip:Kraftwerk@[IPadr Box B]];uniq=C67764277970E1F2C0090F0A09A03 SIP/2.0
Via: SIP/2.0/UDP 87.168.223.52:5060;branch=z9hG4bK452B42B98C8DF60C
From: <sip:Kraftwerk@[IPadr Box A]>;tag=F54823C45D3095ED
To: <sip:Kraftwerk@[IPadr Box A]>;tag=2505637401
Call-ID: 691D2C8BDD3BCAEB@[IPadr Box B]]
CSeq: 4103 NOTIFY
Contact: <sip:[email protected]>
Event: reg
Subscription-State: active;expires=2269
Max-Forwards: 70
User-Agent: AVM FRITZ!Box 7490 113.07.01 (Aug 29 2018)
Content-Type: application/reginfo+xml
Content-Length:   360



2018-12-03 10:43:15.848 - IN: my=[IPadr Box A]%15:5060 peer=[IPadr Box B]] port=5060 UDP, sipiface=none:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 87.168.223.52:5060;branch=z9hG4bK452B42B98C8DF60C;received=[IPadr Box A]
From: <sip:Kraftwerk@[IPadr Box A]>;tag=F54823C45D3095ED
To: <sip:Kraftwerk@[IPadr Box A]>;tag=2505637401
Call-ID: 691D2C8BDD3BCAEB@[IPadr Box B]]
CSeq: 4103 NOTIFY
User-Agent: AVM FRITZ!Box 7490 113.07.01 (Aug 29 2018)
Content-Length: 0



2018-12-03 10:43:21.053 - OUT: my=[IPadr Box A]%15:5060 peer=[IPadr Box B]] port=5060 UDP, sipiface=voip tcclass=sip, netmark=0:
SIP/2.0 480 Temporarily not available
Via: SIP/2.0/UDP [IPadr Box B]]:5060;branch=z9hG4bK20F84FCE26012032
From: <sip:[email protected]>;tag=DB2E6879FFCD8983
To: <sip:GSTWedel@[IPadr Box A];uniq=1493E306E7B7AC70D05E51C6CB656>;tag=C3B16753426DAA4C
Call-ID: F5310B37BEA03736@[IPadr Box B]]
CSeq: 5787 INVITE
User-Agent: FRITZ!OS
Content-Length: 0



2018-12-03 10:43:21.555 - OUT: my=[IPadr Box A]%15:5060 peer=[IPadr Box B]] port=5060 UDP, sipiface=voip tcclass=sip, netmark=0:
SIP/2.0 480 Temporarily not available
Via: SIP/2.0/UDP [IPadr Box B]]:5060;branch=z9hG4bK20F84FCE26012032
From: <sip:[email protected]>;tag=DB2E6879FFCD8983
To: <sip:GSTWedel@[IPadr Box A];uniq=1493E306E7B7AC70D05E51C6CB656>;tag=C3B16753426DAA4C
Call-ID: F5310B37BEA03736@[IPadr Box B]]
CSeq: 5787 INVITE
User-Agent: FRITZ!OS
Content-Length: 0



2018-12-03 10:43:21.596 - IN: my=[IPadr Box A]%15:5060 peer=[IPadr Box B]] port=5060 UDP, sipiface=none:
ACK sip:GSTWedel@[IPadr Box A];uniq=1493E306E7B7AC70D05E51C6CB656 2.0
Via: SIP/2.0/UDP [IPadr Box B]]:5060;branch=z9hG4bK20F84FCE26012032
From: <sip:[email protected]>;tag=DB2E6879FFCD8983
To: <sip:GSTWedel@[IPadr Box A];uniq=1493E306E7B7AC70D05E51C6CB656>;tag=C3B16753426DAA4C
Call-ID: F5310B37BEA03736@[IPadr Box B]]
CSeq: 5787 ACK
User-Agent: AVM FRITZ!Box 7490 113.07.01 (Aug 29 2018)
Content-Length: 0

Was mir mit meinem gefährlichem Halbwissen auffällt, dass bei 'From' und 'P-Called-Party-ID' @fritz.box steht und nicht die IP-Adresse der Box B. Kann ja sein, dass die Box A das nicht auflösen muss, es würde ja IPadr Box A und nicht IPAdr Box B rauskommen

8 Sek nach dem SIP Invite von Box B meldet die Box A 'Temporarily not available'. Solange bleibt auch die LED an. Wo können wir sehen, was in diesen 8 Sek passiert? Kann ggf. ein Softphone helfen, was die SIP-Nachrichten zwischen Fritze zum UA loggen kann?

Sonnige Grüße vom Faxenmacher

 

[PeterPawn]

Da im INVITE noch so viel Schrott steht, kann man vom SDP-Teil nur noch die ersten zwei Zeilen sehen ... da sollte aber noch viel mehr kommen, nämlich u.a. auch noch die Info, wo der RTP-Stream für das Gespräch zu finden wäre - so richtig mit IP-Adresse und Portnummer.

Im Ringbuffer ist die Länge des protokollierten Pakets begrenzt (worauf genau, wußte ich mal und habe ich garantiert auch irgendwo beschrieben ("showshringbuf sip") - der genaue Wert spielt hier aber wohl ohnehin keine Rolle, weil es halt "zu kurz" ist) und damit muß man dann doch zum Paketmitschnitt der FRITZ!Box greifen (den wirst Du ja dann in der Support-Seite auch gesehen haben), wenn man die vollständigen Pakete sehen will.

Bis zum Beweis des Gegenteils bleibe ich bei meiner Vermutung, daß Box B hier nicht als B2BUA arbeitet und Box A versucht, sich direkt mit der RTP-Source zu verbinden, weil das so in den SDP-Angaben steht. Was das ist, wie das aussehen sollte, kannst Du z.B. in der Wikipedia nachlesen: https://de.wikipedia.org/wiki/Session_Description_Protocol - da sieht man dann auch, was ich mit "zu kurz" meine.

 

[Faxenmacher]

Jetzt habe ich leider noch nicht die Zeit gefunden, den Trace zu machen oder ihn gar auszuwerten. Wireshark habe ich seit Jahren nicht mehr benutzt.

Ich habe aber mal ein analoges Telefon an Fon1 angeschlossen (ein 611er in mausgrau ) et voila, der Fernsprechtischapparat klingelt und ich kann das Gespräch führen. Also muss doch irgendwas in der Fritze krumm sein.

Nun habe ich das Szenario erweitert und eine 3. Fritze and Standort C (Easybell DSL und VoIP statt Telekom) mit hinzugenommen, jew. mit LAN-LAN VPN zw. jeden Standort, entsp. Telefoniegerät und RufNr. überall eingerichtet. Das Verhalten bestätigt sich dort. Anrufe von Box A und Box B über VPN nach Box C werden über DECT (Fritz M2) nicht signalisiert, wohl aber über Fon1. Box C ist eine 7430 auch mit v7.01

Und nu?

Gruß vom Faxenmacher!

 

[PeterPawn]

So lange Pausen im Thread machen es dann zwar kompliziert, sich noch an den Inhalt zu erinnern ... aber man kann ja (ausnahmsweise) mal zurückblättern und noch einmal lesen. Wobei das keine "Dauerlösung" sein kann ... wenn man das ständig machen soll, verliert man ja auch das Interesse.

Wenn die Beschreibung vollständig ist, fällt halt irgendwie auf, daß die "nicht klingelnden Endgeräte" alles diejenigen sind, die auf mehrere Rufnummern und entsprechende Signalisierung reagieren könnten (ggf. sogar mit unterschiedlichen Klingeltönen), während bei analogem Anschluß nur noch die Klingelspannung den Ausschlag gibt, ob da nun etwas signalisiert wird oder nicht.

Das führt wohl dann tatsächlich eher zu der Vermutung, daß in der Konfiguration der Telefonie etwas nicht stimmt und die Signalisierung des eingehenden Anrufs so erfolgt, daß der keinem der (schlaueren) Endgeräte zugeordnet werden kann (ggf. schon vom "telefon"-Daemon und nicht erst, wenn sich ein Endgerät selbst für nicht zuständig erklärt) und das analoge Telefon eigentlich nur "aus Gewohnheit" oder wg. "Alle Anrufe annehmen" etwas anders macht.

 

[Faxenmacher]

Danke für deine Geduld # daumenhoch. Bin im Moment beruflich zu stark gefordert für kürzere Reaktionen.

Deine Denkrichtung kann ich nachvollziehen. Bei VoIP, DECT und S0/ISDN sagt die Fritze über ein Datenprotokoll 'du sollst klingeln', und an Fon1 macht sie das selber mit der Wechselspannung.

Was immer wir hier rausfinden könnten und würden, ich wüsste nicht, was ich anders konfigurieren könnte - jedenfalls in der GUI. Inzw. habe ich mir die nötigen Funktionen mit ein paar Parallelrufen auf Sipgate-Nummern hingefriemelt, Das ist zwar nicht dolle, reicht aber erstmal. Vllt. setze ich die Fritzen über die hoffentlich ruhigeren Weihnachtstage mal komplett neu auf, dann haut es vllt. mit einer frischen Installation hin.

Danke für deine/eure konstruktiven Kommentare. Dann lasse ich ich hier die Geschichte als ungelöst enden.

Gruß vom Faxenmacher!