5200R neue Firmware 8.2b und VoIP 1und1 MSN

Ich kann es selber auch bestätigen.
Die Einstellungen haben geholfen.

Leider ist seite ca einer Woche alles fratze…
Es haben keine Änderungen in der TK stattgefunden.
Raustelefonieren und Gesprächsannahme funktioniert nur
noch sporadisch. Von 5 Telefonanten die reinkommen, kan man eins annehmen.
Beim Raustelefonieren ist es ähnlich.

Moin Moin.
Der Stun-Server von 1und1 scheint derzeit instabil zu sein, Versuch am Besten mal eine Alternative, z. B. stun.sipgate.net Port 10000.

Stimmt. Haben das Problem seit ein paar Wochen. Nach Umstellung auf stun.sipgate.net Port 10000 scheint nun alles wieder zu klappen. Keine Ahnung was 1und1 da treibt…

Moin!

Bei uns gibt es leider auch die gleichen Probleme. Es ist einfach nur grrr…

Also wirklich funktioniert es noch nicht. STUN-Server wurde nun auf den von Auerswald empfohlenen
sipgate.net Port 3478 geändert. Die meisten Anrufe klappen, aber manche Anrufer erhalten durchgehend das Besetztzeichen obwohl Leitungen frei sind. Jemand ähnliche Erfahrungen?

Hallo MrMaulwurf,

läuft der Sipgate STUN nicht auf Port 10000 ??? Siehe Post auch von Herrybert …

Gruß
Michael

Gehen beide, laut Auerswald (siehe Link) Port 3478 hatte aber auch schon 10000 drin. Hab gestern nun neue Firmware installiert mal sehen ob es etwas bringt die nächsten Tage.

Der Mythos mit Port 10000 bei sipgate ist nicht tot zu kiegen. Der STUN-Server von sipgate läuft schon seit Jahren auf dem Standarport.

https://help.sipgate.de/hc/de/search?utf8=✓&query=stun

jo

Moin! Hier funktioniert es auch wieder nicht mehr, obwohl es auch auf die Empfehlung hin geändert wurde.

Es wäre super, wenn du eine Rückmeldung gibst, ob das Update geholfen hat.

Grüße,
Jens

Moin Jens.
Welche Infos kannst Du uns bei Deiner Installaion zu Stabilität der Leitung geben?
Die Portweiterleitung im Router hast Du auch eingerichtet, oder?

Aktiviere bitte mal parallel die Option „ DNS-Abfrage überdauert SIP Session (RFC 3263)“ im VoIP-Anbieeprofil von 1und1 in der Anlage.

Moin!

Eins schicke ich gleich mal vorweg, ich bin in dieser ganzen Thematik (leider) eher Laie, aber zumindest nicht uninteressiert. Aber ich kratze eben doch nur an der Oberfläche.
Trotzdem habe ich mich bewusst für eine Auerswald TK-Anlage und einen Lancom Router (1783VA) entschieden.

Der LANmonitor meldet ~11MBit/s Upstream und ~54MBit/s Downstream. Im täglichen Gebrauch kann ich keinerlei Aussetzer oder dergleichen feststellen. Auch Homeoffice und längere Videokonferenzen laufen sauber durch.

Im Router habe ich das Port-Forwarding eingerichtet:
5060 auf IP-Adresse TK-Anlage und Map-Port 5063 / UDP
20000-50175 auf IP-Adresse TK-Anlage UDP

In den Firewall-Regeln habe ich die bekannten IP-Adressen ebenfalls berücksichtigt:
217.10.68.145 bzw. 217.10.68.152 (für Sipgate)
212.227.18.131 bis .140 / 212.227.18.197 bis .206 / 212.227.67.33 und .34 / 212.227.67.131 bis .140 / 212.227.67.197 bis .206
212.227.124.1 bis .255 (lässt sich das evtl. auf weniger einschränken?)

In der Compact 4000 (Version 8.4A - Build 004) nutze ich für 1und1 das Profil „de 1und1 IPv4 T38 V202“.

Die Einstellungen sehen so aus:
Registrar: sip.1und1.de / 5060 / 30 Min. / Re-Registrierung nach SIP Forbidden bzw. Timeout
NAT-Traversal: aktiviert (unter Verwendung von rport)
Intervall für NAT-Keep-Alive: 255 Sek. / Default
Outbound-Proxy: manuell / sip.1und1.de / 5060
SIP-Port: 5063
SIP-Session-Timer: 30 Min.
SIP-Transport UDP
IP-Protokoll: IPv4
RTP NAT-Traversal: aktiviert mit Verwendung von STUN
STUN-Server: stun.sipgate.net / 3478 / 10 Min.
Deregistrieren, wenn es NAT Änderungen gibt: Ja
DNS-Abfrage überdauert SIP Session: Ja

Die Registrierungen sind für die drei Rufnummern auch grün. Wobei es hier schon das erste Kuriosum gibt.
Ich kann die drei Rufnummern immer wieder mal nicht auf einmal registrieren. Dann kommt bei zwei Rufnummern „403: Nicht unterstuetzte IP im Contact-Header“
Bei den beiden betroffenen Rufnummern muss ich die Nutzung deaktivieren und erst eine (die zweite Rufnummer) und danach die zweite (die dritte Rufnummer) registrieren.
Ich habe keinen Dunst was das für ein Phänomen/Problem ist. Falls hierzu jemand eine Idee/Erklärung hat, wäre ich auch dankbar.

Das Telefonieren funktioniert nun aber noch lange nicht. Ich habe das mit dem Drahthai mal versucht mitzuschneiden:

Ein eingehendes Telefonat (vom Handy) sieht so aus:
122 24.503896 212.227.124.129 192.111.1.111 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=d82e) [Reassembled in #123]
123 24.503990 212.227.124.129 192.111.1.111 SIP/SDP 368 Request: INVITE sip:49XXXXXXXXX@217.84.158.183:5060;rinstance=ADC75DA7A5968E6DFC33838293C88AFF |
124 24.597761 192.111.1.111 212.227.124.129 SIP 661 Status: 100 Trying |

126 24.997356 192.111.1.111 192.111.1.22 DNS 76 Standard query 0x002c A stun.sipgate.net
127 25.011171 192.111.1.22 192.111.1.111 DNS 108 Standard query response 0x002c A stun.sipgate.net A 217.10.68.152 A 217.10.68.145
128 25.012570 192.111.1.111 217.10.68.152 CLASSIC-STUN 70 Message: Binding Request
129 25.022808 192.111.1.111 217.10.68.152 CLASSIC-STUN 70 Message: Binding Request
130 25.033293 192.111.1.111 217.10.68.152 CLASSIC-STUN 70 Message: Binding Request
131 25.101893 192.111.1.111 212.227.124.129 SIP 1046 Status: 180 Ringing |

148 28.045223 192.111.1.111 217.10.68.152 CLASSIC-STUN 70 Message: Binding Request
149 28.055437 192.111.1.111 217.10.68.152 CLASSIC-STUN 70 Message: Binding Request
150 28.065675 192.111.1.111 217.10.68.152 CLASSIC-STUN 70 Message: Binding Request

156 31.077950 192.111.1.111 217.10.68.152 CLASSIC-STUN 70 Message: Binding Request
157 31.088181 192.111.1.111 217.10.68.152 CLASSIC-STUN 70 Message: Binding Request
158 31.098427 192.111.1.111 217.10.68.152 CLASSIC-STUN 70 Message: Binding Request

177 34.119063 192.111.1.111 212.227.124.129 SIP 721 Status: 486 Busy Here |
178 34.142909 212.227.124.129 192.111.1.111 SIP 644 Request: ACK sip:49XXXXXXXXX@217.84.158.183:5060;rinstance=ADC75DA7A5968E6DFC33838293C88AFF

Unsere Telefone klingeln auch brav zweimal, aber ein Gespräch kann nicht angenommen werden und nachdem es zweimal geklingelt hat, hört es auch wieder auf („Busy Here“?!?).
In der Gesprächsdatenliste werden diese Anrufe auch aufgeführt.

Nach diesem ganzen Theater und dem vermeintlichen Problem bei 1und1 habe ich mir noch eine Rufnummer bei Easybell eingerichtet.
Allerdings kommt es hier ebenfalls zu Problemen, wobei ich nicht ausschließen möchte, dass weder Easybell noch Auerswald der Verursacher ist, als vielmehr ich selber.

Jedenfalls sieht ein eingehendes Telefonat (vom Handy) so aus:
64 19.929945 195.185.37.60 192.111.1.111 SIP/SDP 1068 Request: INVITE sip:0049XXXXXXXXXX@217.84.158.183:55425;transport=tcp;rinstance=84EA1F2E7EC5AFF3D687AE4B7411FF17 |
65 19.930066 192.111.1.111 195.185.37.60 TCP 66 40227 → 5064 [ACK] Seq=794 Ack=1464 Win=5215 Len=0 TSval=164461612 TSecr=1175881002
66 20.018464 192.111.1.111 195.185.37.60 SIP 390 Status: 100 Trying |
67 20.075338 195.185.37.60 192.111.1.111 TCP 66 5064 → 40227 [ACK] Seq=1464 Ack=1118 Win=358 Len=0 TSval=1175881148 TSecr=164461621
68 20.370797 192.111.1.111 195.185.37.60 SIP 450 Status: 486 Busy Here |
69 20.387992 195.185.37.60 192.111.1.111 TCP 66 5064 → 40227 [ACK] Seq=1464 Ack=1502 Win=358 Len=0 TSval=1175881460 TSecr=164461656
70 20.388101 195.185.37.60 192.111.1.111 SIP 486 Request: ACK sip:0049XXXXXXXXXX@217.84.158.183:55425;transport=tcp;rinstance=84EA1F2E7EC5AFF3D687AE4B7411FF17 |
71 20.388174 192.111.1.111 195.185.37.60 TCP 66 40227 → 5064 [ACK] Seq=1502 Ack=1884 Win=5215 Len=0 TSval=164461658 TSecr=1175881460

Warum meldet auch hier die TK-Anlage „486 Busy Here“? Ehrlich gesagt, verstehe ich das überhaupt nicht.

Ist es evtl. doch möglich, dass in der Firmware ein Fehlerchen enthalten ist? Aber dann müssten doch noch weit mehr Nutzer betroffen sein, oder?
Oder ist die Privatnutzung mit Einzelrufnummern doch eher die (ganz seltene) Ausnahme?

Es wäre wirklich sehr schön, wenn dieses Problem behoben wird!

Grüße,
Jens

Hallo Jens.

Folgendes fällt,auf:

  1. fragmentierungen von sip-Paketen darf nicht sein, dies führt zu Problemen. Dies wird vermutlich im Router passieren, am Besten prüfen ob der SIP-ALG deaktiviert ist (sollte also aus bleiben).
  2. Die Portweiterleitung von Port 5060 auf die TK-Anlage ist zu deaktivieren, da der Port 5060 in der Anlage im Normalfall nur für die internen VoIP-Telefone verwendet wird.
  3. Am Besten nur den einen sip-Port (im Anbieter sieht man diesen unter „SIP-Port“ auf die TK-Anlage umleiten,die RTP-Port einfach nicht einrichten.

Hallo!

Die Fragmentierung gab es nur bei diesem einen Versuch, sonst nie und SIP-ALG ist auch ausgeschaltet. Ich behalte das aber im Auge.

Bzgl. dem Port bin ich jetzt unklar. 1und1 verwendet doch den 5060. Und im Anbieterprofil der C4000 steht bei SIP-Port 5063. Dann muss ich doch den 5060 auf den 5063 im Port-Forwarding umleiten, oder?

Noch mal kurz die Frage was „Busy here“ bedeuten soll? Kann es da mehrere Ursachen für geben?

Besten Dank für die Hilfe!

Grüße,
Jens

Moin Jens.

Nein, das mit den Ports verwirrt immer.
Wenn in der Anlage der Port 5063 beim Anbieter angegeben ist musst Du nur diesen Port im Router umleiten, also: 5063 auf 5063 !
Der Port 5060 der Anlage sollte wie gesagt niemals erreichbar aus dem Internet sein.

Moin Martin!

Besten Dank! Das habe ich in der Tat falsch verstanden. Ich habe jetzt soweit alles korrigiert und es funktioniert auch. Ich hoffe es bleibt so!

Warum mein Easybell „Busy here“ gemeldet hat, weiß ich mittlerweile auch. In der Rufverteilung war für die Interne RufNr., warum auch immer, „Rückfall“ eingestellt. Das kann dann natürlich nicht klappen…

Grüße,
Jens

Also aktuell scheint das Problem hier mit der neuen Firmware gelöst zu sein. Es hat sich keiner mehr beschwert, dass bezetzt ist obwohl eine freie Leitung vorhanden war.