[Problem] be.IP plus kurze Abbrüche bei dem Gespräch

[mazar]

Hallo zusammen ,

neues Jahr neues Problem .

Da ich ja letztes Jahr alles neu gemacht habe (hat auch bis vor einem Monat alles funktioniert) habe ich jetzt ein neues Problem.
Ich habe eine be.IP plus (neuste FW) mit 2 Elmeg IP630 Standort A und eine Fritz!Box mit 2 Elmeg IP630 Standort B die eine Site-to-Site VPN aufbauen, die VPN Verbindung läuft meiner Meinung 1a

Jetzt kommt mein Problem.
Wenn jemand Anruft und es geht jemand bei Standort B dran habe ich kurze Abbrüche so von 2 - 3 Sekunden und dann hört man den Teilnehmer wieder.
Bei Wireshark wird mit der Anruf angezeigt also CANCELLED INVITE 200 487
Habt ihr evtl eine Idee? Kennt jemand das Phänomen

 

[sonyKatze]

Mich wundert die SIP-Status-Abfolge. Aber eigentlich sollte es dem laufenden Gespräch egal sein. Egal:

1. Sind die Elmegs an Standort B direkt in die FRITZ!Box eingebucht oder direkt bei Euch?
2. Was ist Euch, Standard A, also die be.IP plus?
3. Falls die Elmegs direkt mich Euch verbunden sind, ist in der FRITZ!Box an Standort B noch versehentlich ein Telefonie-Anbieter hinterlegt?

 

[mazar]

Hallo,

1. Die Elmegs sind über VPN in der be.IP plus Standort A eingebucht.
2. Uns gehört beides.
3. Ja also habe geschaut, hier sind 2 Geräte Konfiguriert und 3 Rufnummern die aber nicht genutzt werden.

Habe jetzt mal einen kleinen Auschnitt von Wireshark hinzugefügt, dort fällt auf das er beim gespräch die Pakete verliert.

192.168.89.1	192.168.88.65	SIP/SDP	1039​	Request: INVITE sip:[email protected]:5060 |
192.168.88.65	192.168.89.1	SIP	440​	Status: 100 Trying |
192.168.88.65	192.168.89.1	SIP	636​	Status: 180 Ringing |
192.168.88.65	192.168.89.1	UDP	32​	5060 → 5060 Len=4
192.168.88.65	192.168.89.1	UDP	32​	5060 → 5060 Len=4
192.168.88.65	192.168.89.1	NTP	76​	NTP Version 4, client
192.168.89.1	192.168.88.65	NTP	76​	NTP Version 4, server
192.168.88.65	192.168.89.1	SIP/SDP	1041​	Status: 200 OK (INVITE) |
192.168.89.1	192.168.88.65	SIP	626​	Request: ACK sip:[email protected]:5060 |
192.168.89.1	192.168.88.65	RTP	200​	PT=ITU-T G.722, SSRC=0xA4028800, Seq=0, Time=0
192.168.89.1	192.168.88.65	RTP	200​	PT=ITU-T G.722, SSRC=0xA4028800, Seq=1, Time=160
192.168.88.65	192.168.89.1	ICMP	228​	Destination unreachable (Port unreachable)
192.168.89.1	192.168.88.65	RTP	200​	PT=ITU-T G.722, SSRC=0xA4028800, Seq=2, Time=320
192.168.88.65	192.168.89.1	ICMP	228​	Destination unreachable (Port unreachable)
192.168.89.1	192.168.88.65	RTP	200​	PT=ITU-T G.722, SSRC=0xA4028800, Seq=3, Time=480
192.168.88.65	192.168.89.1	ICMP	228​	Destination unreachable (Port unreachable)
192.168.89.1	192.168.88.65	RTP	200​	PT=ITU-T G.722, SSRC=0xA4028800, Seq=4, Time=640
192.168.88.65	192.168.89.1	ICMP	228​	Destination unreachable (Port unreachable)
192.168.89.1	192.168.88.65	RTP	200​	PT=ITU-T G.722, SSRC=0xA4028800, Seq=5, Time=800
192.168.89.1	192.168.88.65	RTP	200​	PT=ITU-T G.722, SSRC=0xA4028800, Seq=6, Time=960
192.168.88.65	192.168.89.1	ICMP	228​	Destination unreachable (Port unreachable)
192.168.89.1	192.168.88.65	RTP	200​	PT=ITU-T G.722, SSRC=0xA4028800, Seq=7, Time=1120
192.168.89.1	192.168.88.65	RTP	200​	PT=ITU-T G.722, SSRC=0xA4028800, Seq=8, Time=1280
192.168.89.1	192.168.88.65	RTP	200​	PT=ITU-T G.722, SSRC=0xA4028800, Seq=9, Time=1440
192.168.89.1	192.168.88.65	RTP	200​	PT=ITU-T G.722, SSRC=0xA4028800, Seq=10, Time=1600
192.168.88.65	192.168.89.1	RTP	200​	PT=ITU-T G.722, SSRC=0x6DF98021, Seq=55500, Time=1607638843, Mark
192.168.89.1	192.168.88.65	RTP	200​	PT=ITU-T G.722, SSRC=0xA4028800, Seq=11, Time=1760
192.168.88.65	192.168.89.1	RTP	200​	PT=ITU-T G.722, SSRC=0x6DF98021, Seq=55501, Time=1607639003

 

[sonyKatze]

Verlorende RTP-Pakete am Anfang wären normal, weil das UDP-Hole-Punching ein paar Millisekunden braucht. Aber das sind Millisekunden. Deckt sich nicht mit Deinem geschilderten Symptom. Und eigentlich dürftest Du im selben VPN gar keine Firewall mehr dazwischen haben? Das solltest Du überprüfen, wer da überhaupt die Paket wegwirft; vielleicht sogar das Telefon selbst? Keine große Ahnung. Mein wilder Vorschlag: Die Hardware-Beschleunigung auf der FRITZ!Box probeweise abschalten.

 

[Kalle2006]

Der Titel des Threads ist irreführend, denn das Problem kann auch an der FB liegen.

 

[mazar]

[Edit Novize: Überflüssiges Fullquote gemäß der Forumsregeln gelöscht]

Okay also habe mal Testweise die Option abgeschaltet und habe mal an der Fritz!Box die Telefonie deaktiviert.

[Edit Novize: Überflüssiges Fullquote des Beitrags direkt darüber gemäß der Forumsregeln gelöscht]
Stimmt die Frage ist ob es auch in diese Kategorie gehört :-/.