CB.2 FW 3.0K Build 001: VoIP-Anbieter Settings

Ältere Auerswald TK-Anlagen und Archiv COMmander Basic.2
41

Hi Alex,

probiere mal was Anderes.

[LIST]
[]In den Einstellungen für Sipgate NAT-Keepalive aktivieren und auf 15 - 30 Sekunden stellen.
[]In den Einstellungen für Sipgate das Registrierungsinterval auf 1 Minute reduzieren.
[*]Den SIP-UDP-Port von 5063 auf z.B. 5073 ändern.
[/LIST]

[LIST]
[]Sämtliche Port-Forwardings auf die Anlage sind zu überdenken, da sie ein Sicherheitsrisiko darstellen:
[INDENT][]Thereotisch wäre nur 5063 bzw dann 5073 für abgesetzte Nebenstellen notwendig, sonst kein SIP-Port.
[]Das Forwarden der RTP-Ports (49152 folgende) nur bei einseitigem oder kein Audio testweise vornehmen.
(Ich habe dieses Forwarding auch eingerichtet, weil ich nur einseitiges Audio hatte! Das ist aber nicht zwingend mit jedem Router nötig.)
[]Port-Forwardings auf TCP alle deaktivieren, außer es soll SIPS oder SIP-TCP verwendet werden.[/INDENT]
[/LIST]

[LIST]
[*]Den Router genauer unter die Lupe nehmen. Hat er ein SIP-ALG (ALG = Application Layer Gateway = SIP-Proxy im Router)? Eventuell testweise einen anderen Router verwenden.

[*]Wie ist der exakte Text am roten Registrierungsbubble? Ist das wirklich ein deutscher Text? Wenn ja, kommt er vom Provider!

[*]Hast Du schon mal einen Wireshark-Trace über die Weboberfläche der Anlage gemacht? Du musst tracen, wenn der Fehler ansteht und dann über mehrere Minuten (10 sollten reichen).
[/LIST]

Grüße
Olli

42

Tach Olli,

obwohl SipGate gerade mal wieder läuft und es eigentlich heisst :

“Never change a running system”

ist das deshalb ja lange noch nicht klar - danke also für die Tipps denen ich folgendermassen nachgegangen bin, bzw. diese umgesetzt habe :

[color=green]“In den Einstellungen für Sipgate NAT-Keepalive aktivieren und auf 15 - 30 Sekunden stellen.”[/color]
[color=green] [/color]
Steht nun auf 20 Sekunden.

[color=green]“In den Einstellungen für Sipgate das Registrierungsinterval auf 1 Minute reduzieren.”[/color]

Wurde auf 1 Minute reduziert.

[color=green]“Den SIP-UDP-Port von 5063 auf z.B. 5073 ändern.” [/color]

Steht noch auf 5063, da zuvor schon ca. 3 Monate ohne “Erfolg” auf 5067. Oder hat es mit 5073 eine eventuell besondere Bewandnis ?

[color=green]“Thereotisch wäre nur 5063 bzw dann 5073 für abgesetzte Nebenstellen notwendig, sonst kein SIP-Port.” [/color]

Wurde auf die tatsächlich verwendeten Ports 5060,5062,5063,5064 reduziert.

[color=green]“Das Forwarden der RTP-Ports (49152 folgende) nur bei einseitigem oder kein Audio testweise vornehmen.”[/color]

Ist jetzt komplett abgeschaltet - Verbindungstest steht noch aus.

[color=green]“Port-Forwardings auf TCP alle deaktivieren, außer es soll SIPS oder SIP-TCP verwendet werden.”[/color]

TCP-Forwardings auf betr. Ports waren schon immer und sind noch abgeschaltet.

[color=green]“Den Router genauer unter die Lupe nehmen. Hat er ein SIP-ALG (ALG = Application Layer Gateway = SIP-Proxy im Router)? Eventuell testweise einen anderen Router verwenden.”[/color]

Das Linksys WAG 160N-DE - Gateway verfügt über keinerlei SIP-Settings. Verhalten mit WAG 300N war identisch - mit CB.2 FW 2.x keine Probleme mit beiden Gateways.

[color=green]“Wie ist der exakte Text am roten Registrierungsbubble? Ist das wirklich ein deutscher Text? Wenn ja, kommt er vom Provider!”[/color]

Soweit ich mich erinnern kann, war es Deutsch - werde es beobachten. Auch für den Fall, dass es eine Provider(SipGate)-Meldung wäre, war es beim Auftreten dieser Meldung immer möglich, sich mit dem separaten SIP-Router bzw. dem Soft-Client bei SipGate zu registrieren.

[color=green]“Hast Du schon mal einen Wireshark-Trace über die Weboberfläche der Anlage gemacht? Du musst tracen, wenn der Fehler ansteht und dann über mehrere Minuten (10 sollten reichen).”[/color]

Nein, bislang noch nicht, da es leider nicht funktionierte - sollte es wieder auftreten, werde ich es versuchen - habe auch WireShark als Anwendung auf dem Rechner - geht das damit auch und falls ja mit welchen Settings ?

Nach den nun vorgenommenen Änderungen steht die Registrierung noch - also abwarten was der “Langzeit-Test” ergibt.

Gruß Alex

P.S.:

Prima wäre es, wenn man am Systemtelefon selektiv einstellen könnte, dass dort Fehlermeldungen, wie z.B. SIP-Fehler bzw. auch fehlendes ISDN-Amt eingeblendet werden, denn gerade bei SIP-Fehlern bekommt man das sonst nur mit, wenn man ins Monitoring schaut, nicht mehr raus rufen kann bzw. von irgend jemandem erfährt, dass man über betr. Nummer nicht erreichbar ist.
Noch besser wäre es, wenn die Anlage dem Anlagen-Admin automatisch eine Störungs-Email zuzusenden würde, so wie es z.B. bei “grossen” Brother-MFC´s mit Netzwerkkarte möglich ist (z.B. MFC-8840DN). Dort kann man sogar auswählen welche Störungen gemeldet werden, sowie auch ob eine Benachrichtigung stattfinden soll, wenn die Störung behoben ist. Wäre so auch eine prima Funktion zur Dokumentation bei sporadischen Fehlern.

43

Update :

Auch ohne das Port-Forwarding der Ports 49152 bzw. 49151 - 49408 /udp sind alle VoIP-Accounts noch erfolgreich registriert.

Die Verständigung habe ich zwischenzeitlich auch getestet und auch die ist einwandfrei, d.h. keine einseitige Verständigung o.ä.

Alex

44

Äh… umm… kleiner Hinweis am Rande:

SIP -> Klingeln
RTP -> Sprechen

Also: “registriert” bedeutet, daß per SIP der Client sich am Server anmelden konnte. Es bedeutet nicht, daß der Server noch eine Registrierung hat oder daß man damit irgendwie telefonieren könnte. Es bedeutet auch nicht, daß eingehende Telefonate funktionieren müssen. Das Registrierungsintervall soll vorbeugen, daß die Registrierung auf der Serverseite abläuft. Aber auch das ist keine Garantie dafür, daß man eine Telefonverbindung herstellen kann.

Abgehendes Telefonieren führt normalerweise eine ad-hoc Registrierung durch, wenn der Server sich weigert, den Client anzuerkennen.

Eingehende Telefonate setzen eine korrekte Registrierung voraus, jedoch auch eine korrekte Weiterleitung des SIP-Datenverkehrs auf den Port der Tk-Anlage, damit die INVITEs durchkommen. Das macht normalerweise die Portweiterleitung auf den in der Anlage genannten SIP-Port für den jeweiligen Account.

Sprache ist RTP über die genannten Ports oberhalb von 40000. Sprache läuft über UDP, d.h. verbindungslos. Das hat mit einer Registrierung absolut nichts zu tun. Abgehend funktionieren Telefonate normalerweise, da die meisten Router zu einem abgehenden UDP-Datenstrom automatisch einen entsprechenden eingehenden erlauben. Tun sie dies nicht, hört man die Gegenseite nicht, diese hört einen jedoch korrekt.

Eingehende Telefonate (wenn das INVITE korrekt durchgeführt wurde) funktionieren ggf. nicht, wenn der Router den eingehenden RTP-Datenstrom nicht akzeptiert. Es kann jedoch auch sein, daß der abgehende Datenstrom (die Verbindung ist ja bidirektional) zugleich den eingehenden gestattet (siehe oben).

Langer Rede kurzer Sinn: die Registrierung alleine sagt noch nichts über die Notwendigkeit eines Portforwardings für die RTP-Ports aus. Das stellst Du erst fest, wenn telefoniert wird… insbesondere bei eingehenden Telefonaten nach einer längeren Pause des nicht-abgehend-Telefonierens.

–gandalf.

45

“Ja nee is klar” [SIZE=1](frei nach Atze Schröeder)[/SIZE] - zumindest soweit, dass die Registrierung noch nichts über die Möglichkeit zu sprechen aussagt, doch das geht in beide Richtungen, also Duplex und auch von beiden Seiten, ausgehend und kommend ohne diese Portforwardings von 49152(1) - 49408/udp … zumindest im Moment noch, denn ich habe schon oft gehofft der Spuk wäre vorbei und es ginge jetzt :wall: aber die Hoffnung stirbt zuletzt :teufel:

Alex

46

Wie schon befürchtet :

Zu früh gefreut !

[color=red]Fehler: 503[/color]
[color=red]Service Unavailable[/color]

Ist also auf Englisch und somit nicht von SipGate generiert.

Doch nun kommts :

Obwohl Port 5073 gar nicht geforgewardet ist, habe ich als eine Art Verzweiflungstat den Port von 5063 auf 5073 geändert und siehe da

Registrierung ist erfolgreich [SIZE=4][color=seagreen]o[/color][/SIZE]

[color=black]Wieder zurück auf 5063 > Fehler 503[/color]
erneut auf 5073 > i.O.

Wie gesagt Port 5073 ist nicht geforgewardet - muss man das verstehen :wall:

Zumindest bin ich so für den Moment mal wieder “online” und vielleicht hilft das ja weiter - Olli lag mit der 5073 nicht sooo verkehrt, allerdings sollte der Port ja auch geforwardet werden…

Eben hab ich noch mal geschaut :

Nun sind die beiden SipGate-Accounts eingeloggt, dafür aber der Betamax (VoiPDiscount) dauerhaft auf Fehler 503 - Port von 5062 auf 5072, der auch nicht geforwardet ist geändert > Registrierung erfolgreich :confused:

Schaffe das heute nicht mehr, werde aber versuchen den Fehler morgen nochmal zu provozieren und zu tracen.

Alex

47

Das kann auch nur daran liegen, daß die 503-behafteten Ports schon genutzt wurden, d.h. in den NAT-Tables des Routers bekannt waren und die neuen eben nicht.

Teste auf jeden Fall immer zuerst eingehende und dann abgehende Telefonate. Ich würde wirklich gerne mal einen SIP-Trace sehen, wenn der 503-Zustand erreicht ist.

–gandalf.

48

[quote=gandalf94305]Das kann auch nur daran liegen, daß die 503-behafteten Ports schon genutzt wurden, d.h. in den NAT-Tables des Routers bekannt waren und die neuen eben nicht.

Teste auf jeden Fall immer zuerst eingehende und dann abgehende Telefonate. Ich würde wirklich gerne mal einen SIP-Trace sehen, wenn der 503-Zustand erreicht ist.

–gandalf.[/quote]

Dummerweise gehts nun wieder mit irgend einem Port bzw. Ports, d.h. auch 5063, womit ich den Zustand nicht in einem Trace darstellen kann.

Trotzdem habe ich getraced und obwohl alles i.O. scheint, taucht dort ständig bei SipGate & VoipDiscount die SIP-Meldung

Status: 483 Too Many Hops

entdecke.

Bei SipGate sind es 8 Hops in 21 ms, bei VoIPDiscount 11 Hops in 29 ms, doch bei VoIPDiscount kommt keine Meldung 483 !

Offenbar bei der Registrierung bei SipGate erscheint zunächst die Meldung “401 Unauthorized” direkt gefolgt von “200 o.K.”

Könnte es sein, dass eben zu viele Hops als eigentlich vom Header erlaubt werden vorhanden sind und die Registrierung somit nur zufällig halt doch mal zustande kommt, wobei die Betamaxe dabei flexibler sind als SipGate ?

Wie viele Hops sind zu SipGate “normalerweise”, d.h. von anderen bei denen es keine Probleme gibt zu verzeichnen ?

Bez. der Vermutung des NAT, könnte das schon sein, doch mit dem Router zuvor war es genauso und der aktuelle ist erst seit Juni 2009 in Betrieb - der “Effekt” war von Anfang an derselbe wie jetzt.

Alex

49

Was steht im Max-Forwards SIP Headerfeld jeweils?

Gibt es in den Paketen irgendwelche Record-Route Headerfelder?

Sind Outbound-Proxies festgelegt?

Normalerweise kommt 483, wenn man zu viele Proxy-Hops auf dem Weg zum Ziel verwendet. Das dürfte bei Dir bis sipgate nicht der Fall sein, d.h. die andere Option ist, daß sipgate ein Problem mit der Zuordnung Deiner REGISTER-Credentials auf deren richtigen Server hat… das kann auch in falschen Credentials (Username!) liegen. Du hast wirklich die Einstellungen von dieser Seite (SIP-ID und SIP-Password) für die Konfiguration des Accounts verwendet?

https://secure.sipgate.de/user/settings.php#overview

–gandalf.

50

[color=green]Was steht im Max-Forwards SIP Headerfeld jeweils?[/color]

Max-Forwards: 70
SipGate max. 70, d.h. mit 8 also o.k. :good:

[color=green]Gibt es in den Paketen irgendwelche Record-Route Headerfelder?[/color]

So wie ich das sehe ja :eek:

X-Auerswald-Device: ed0cb789a3f1d3227f8e92be52974767
Expert Info (Note/Undecoded): Unrecognised SIP header (X-Auerswald-Device)
Unrecognised SIP header (X-Auerswald-Device)
Severity level: Note
Group: Undecoded

Nicht erkannter SIP header hört sich irgendwie weniger gut an :rolleyes:

[color=green]Sind Outbound-Proxies festgelegt?[/color]

Bei SipGate nein - VoipDiscount ja.

[color=green]Normalerweise kommt 483, wenn man zu viele Proxy-Hops auf dem Weg zum Ziel verwendet. Das dürfte bei Dir bis sipgate nicht der Fall sein, d.h. die andere Option ist, daß sipgate ein Problem mit der Zuordnung Deiner REGISTER-Credentials auf deren richtigen Server hat… das kann auch in falschen Credentials (Username!) liegen. Du hast wirklich die Einstellungen von dieser Seite (SIP-ID und SIP-Password) für die Konfiguration des Accounts verwendet?[/color]

[color=black]Alles noch mal überprüft - bei den beiden SipGate-Accounts ist alles wie von SipGate vorgegeben gesetzt.[/color]
Würde mit falschem Username etc. denn überhaupt was funktionieren ?

Da das alles mit der CB2 FW 2.x nicht auftrat, schließe ich nicht aus, dass die CB2 was an SipGate sendet, was dort nicht bzw. nicht immer oder nicht immer richtig verwertet werden kann, sowie demzufolge ab und zu zum Fehler 503 führt, was sich NAT für diesen Port dann eine gewisse Zeit merkt und somit über längere Zeit keine Registrierung mehr zustande kommt.
Auch möglich wäre, dass die an SipGate gesendeten Daten unterwegs verfälscht werden bzw. was verloren geht und dadurch dieser Effekt zustande kommt, womit dann der ISP, der schon lange zum Kreise der Verdächtigen gehört (T-Home / T-Online über DSLAM) mal wieder gefragt wäre, die aber alles von sich weisen, wie man das ja aus den guten alten “Post”-Zeiten kennt.

Noch mal zur Erinnerung :

Im Moment sind die SipGate-Accounts trotz dieser Fehlermeldung korrekt registriert und funktionieren auch !

Alex

51

SipGate stieg gestern mit Fehler 503 erneut aus und ich habe gleich getraced, d.h. jetzt ist Auswertung angesagt :floet:

Alex

52

[quote=PABX-Alex]SipGate stieg gestern mit Fehler 503 erneut aus und ich habe gleich getraced, d.h. jetzt ist Auswertung angesagt :floet:

Alex[/quote]

Auch nach 5 Monaten des geduldigen Wartens auf eine Auswertung und Lösung des Problem, sowie der neuen Firmware 3.8C besteht das Problem immer noch … was jetzt :confused:

Alex

53

Bei mir ist sipgate durchgehend ohne Probleme registriert…

Das könnte nun bei Dir eine Wechselwirkung mit dem NAT des Routers sein. Es hilft also nur, eine Auswertung des SIP-Traces durchzuführen.

–gandalf.

54

Moin.

Bei mir gehen meine Sipgate Accounts wunderbar. Sogar einer als Tk-Anlagenanschluss mit Durchwahl.

55

Nachdem ich zwischenzeitlich einen von Auerswald für “gut” befundenen Router testweise benutzt, aber nach 2-3 Wochen auch damit wieder den Fehler 503 erhielt, habe ich ein wenig mehr gegoogelt und siehe da, ich bin auf Meldungen gestossen, die besagen, dass User von deren VoIP-Provider aufgefordert wurden den NAT-Keepalive zu erhöhen, da zu kurze Intervalle das Netz überlasten würden, und man bis diese Zeit erhöht worden wäre, den Account sperren würde.

So dachte ich mir, vielleicht macht so etwas SipGate je nach Netzlast zeitweise ganz automatisch und habe NAT-Keepalive auf 180 gesetzt.

Seither und das sind nun schon über 3 Wochen, gab´s keine Probleme mehr mit Fehler 503 - hoffe das bleibt auch so, denn man soll bekanntlich den Tag nicht vor dem Abend loben und ich bekam diese Fehlermeldung auch schon mal nach 4 Wochen problemlosen Betrieb.

Interessant ist nur, dass dieses Problem mit der letzten FW 2.x nicht existierte.

Alex

56

Ich habe bisher immer noch keine SIP-Traces hier gesehen…

NAT-Keepalives sind ja vielleicht gar nicht erforderlich und ggf. sogar kontraproduktiv, wenn sie zu Sperren beim Provider führen. Ich verwende mit meinem Router überhaupt keine NAT-Keepalives und sipgate ist durchgängig registriert. SIP-Session-Timer ist bei mir auf 10 min gesetzt.

STUN ist ebenso ein Thema. Bei manchen Routern muss man STUN verwenden, bei anderen darf man STUN nicht verwenden. Es kommt also auf die spezielle Kombination an… generelle Regeln gibt es nicht.

–gandalf.

57

[quote=gandalf94305]Ich habe bisher immer noch keine SIP-Traces hier gesehen…
…
–gandalf.[/quote]

Die Traces gingen an die Cremlinger :slight_smile:

Es gab übrigens bislang keine Ausfälle mehr, wobei das nicht immer gleich bemerkt werden muss - geschickt wäre eine Störungsmeldung auf dem Sys-Tel wenn ein Amt abnippelt.

Alex