Teilproblem Re-Registrierung SIP Leitungen mit 1783VAW

Forum zu aktuellen Geräten der LANCOM Router/Gateway Serie

Moderator: Lancom-Systems Moderatoren

tom-1
Beiträge: 124
Registriert: 28 Dez 2005, 10:46

Teilproblem Re-Registrierung SIP Leitungen mit 1783VAW

Beitrag von tom-1 »

Hallo,
mit einem vorher zurückgesetztem und danach manuell neu konfigurierten 1783VAW (LCOS 10.00.0170RU2) habe ich ein Teilproblem mit der Re-Regstrierung von SIP Leitungen. Das Problem ist offenbar Provider-abhängig. Der Anschluss ist ein VDSL2 (All-IP) von der Telekom, momentan nur per IPv4.
Es sind momentan 20 SIP einzelne Leitungen (IPv4) registriert, die prinzipiell auch alle funktionieren, d.h. eine Anmeldung am Provider und ein gehendes oder kommendes Gespräch ist möglich. Telekom SIP Leitungen per Wizard + manueller Korrektur, alle anderen manuell. ALG nicht nicht aktiviert.

Mit allen SIP Leitungen der Telekom und Sipgate gibt es keine Probleme.

SIP Leitungen von EASYBELL, GMX und PBX/personel-voip melden in verhältnismäßig kleinen Abständen (<1/2h) einen Fehler, benötigen mehrere Minuten für eine erneute Registrierung und sind in dieser Zeit auch nicht nutzbar. Nach einigen Minuten sind sie ohne Eingriff erneut registriert und benutzbar. Die Fehler erscheinen in der Regel nicht synchron gleichzeitig über diese drei Anbieter, aber in der Regel synchron mit allen Leitungen eines dieser Anbieter.

Im LANmonitor steht im Fehlerfall bei der betreffenden SIP Leitung jeweils "IP-Adresse der Gegenstelle transport expired".

Mit Eintrag und Weglassen von Werten in der einzelnen Felder der SIE-Leitungskonfiguration und der Leitungsüberwachung habe ich so ziemlich alles probiert, was geht, auch Zeitwerte zwischen 60 und 600s. Keine Änderung des Verhaltens.

Hat jemand einen getesteten, dauerhaft funktionierenden SIP Eintrag für
EASYBELL oder GMX oder PBX (bzw. Personal-voip)?

Besonders EASYBELL wäre mir wichtig.

Mit einem SIP Trace kann ich nicht viel anfangen, das verstehe ich zu wenig.

Danke - Tom
Benutzeravatar
saigolae
Beiträge: 46
Registriert: 17 Dez 2014, 13:37

Re: Teilproblem Re-Registrierung SIP Leitungen mit 1783VAW

Beitrag von saigolae »

tom-1 hat geschrieben:Hallo,
mit einem vorher zurückgesetztem und danach manuell neu konfigurierten 1783VAW (LCOS 10.00.0170RU2) habe ich ein Teilproblem mit der Re-Regstrierung von SIP Leitungen. Das Problem ist offenbar Provider-abhängig. Der Anschluss ist ein VDSL2 (All-IP) von der Telekom, momentan nur per IPv4.
Es sind momentan 20 SIP einzelne Leitungen (IPv4) registriert, die prinzipiell auch alle funktionieren, d.h. eine Anmeldung am Provider und ein gehendes oder kommendes Gespräch ist möglich. Telekom SIP Leitungen per Wizard + manueller Korrektur, alle anderen manuell. ALG nicht nicht aktiviert.

Mit allen SIP Leitungen der Telekom und Sipgate gibt es keine Probleme.

SIP Leitungen von EASYBELL, GMX und PBX/personel-voip melden in verhältnismäßig kleinen Abständen (<1/2h) einen Fehler, benötigen mehrere Minuten für eine erneute Registrierung und sind in dieser Zeit auch nicht nutzbar. Nach einigen Minuten sind sie ohne Eingriff erneut registriert und benutzbar. Die Fehler erscheinen in der Regel nicht synchron gleichzeitig über diese drei Anbieter, aber in der Regel synchron mit allen Leitungen eines dieser Anbieter.

Im LANmonitor steht im Fehlerfall bei der betreffenden SIP Leitung jeweils "IP-Adresse der Gegenstelle transport expired".

Mit Eintrag und Weglassen von Werten in der einzelnen Felder der SIE-Leitungskonfiguration und der Leitungsüberwachung habe ich so ziemlich alles probiert, was geht, auch Zeitwerte zwischen 60 und 600s. Keine Änderung des Verhaltens.

Hat jemand einen getesteten, dauerhaft funktionierenden SIP Eintrag für
EASYBELL oder GMX oder PBX (bzw. Personal-voip)?

Besonders EASYBELL wäre mir wichtig.

Mit einem SIP Trace kann ich nicht viel anfangen, das verstehe ich zu wenig.

Danke - Tom
Hallo Tom

Was meinst du mit "Telekom SIP Leitungen per Wizard + manueller Korrektur" ?

Freundliche Gruesse

Eric
tom-1
Beiträge: 124
Registriert: 28 Dez 2005, 10:46

Re: Teilproblem Re-Registrierung SIP Leitungen mit 1783VAW

Beitrag von tom-1 »

Ich habe die Telekom SIP Leitungen mit dem Wizard eingerichtet, aber hinterher manuell korrigiert, unter anderem weil ich intern nicht mit den externen "MSN" Rufnummern, sondern mit kürzeren arbeite. Ich hätte natürlich auch gleich alle manuell einrichten können, so erschien es mir etwas weniger Arbeit.
Aber mit diesen Nummern (und 3x Sipgate) ist alles ok. Easybell ist mein Hauptproblem.

Tom
Benutzeravatar
saigolae
Beiträge: 46
Registriert: 17 Dez 2014, 13:37

Re: Teilproblem Re-Registrierung SIP Leitungen mit 1783VAW

Beitrag von saigolae »

tom-1 hat geschrieben:Ich habe die Telekom SIP Leitungen mit dem Wizard eingerichtet, aber hinterher manuell korrigiert, unter anderem weil ich intern nicht mit den externen "MSN" Rufnummern, sondern mit kürzeren arbeite. Ich hätte natürlich auch gleich alle manuell einrichten können, so erschien es mir etwas weniger Arbeit.
Aber mit diesen Nummern (und 3x Sipgate) ist alles ok. Easybell ist mein Hauptproblem.

Tom
Hallo Tom

Vielen Dank fuer Deine Nachricht.

Ich hatte mit meiner Frage gehofft, noch etwas fuer die Aufklaerung meines Problems abheben zu koennen.

Freundliche Gruesse

Eric
Jens.B
Beiträge: 50
Registriert: 08 Aug 2017, 10:32

Re: Teilproblem Re-Registrierung SIP Leitungen mit 1783VAW

Beitrag von Jens.B »

Hallo Tom,

ich habe seit dem Update auf die FW10 das gleiche Problem (Verbindung zu Easybell).

Hier ->
http://www.lancom-forum.de/lancom-syste ... C3%B6glich
<- wurde das schon mal angesprochen. Danach führt das angezeigte SIP-Paket mit "Expires: 0" zur Abmeldung, danach meldet sich der Lancon neu an - was eben etwas dauert.

Ich habe das bei mir überprüft, und ja, das Problem liegt in der FW10. Ich habe mich deshalb an den Lancom-Support gewendet (siehe unten), mal sehen was passiert. Der Easybell-Support hat zumindestens die Abmeldungen mit der FW10 bestätigt, zum genauen Grund aber nichts gesagt.

Ich bin zurück zur FW9.24, da läuft alles einwandfrei.

===>

Hallo Lancom-Support,

ich habe einen Lancom 1784VA (over ISDN), Hardware Rel. A, FW10

Ich benutzte das Teil u.a. als Verbindung unser alten ISDN-Anlage mit einem SIP-Trunk-Account bei Easybell. Vor einiger Zeit gab es ein Update auf die FW10, seit dem haben wir Probleme mit der Telefon-Verbindung.

Etwa alle 9-8 Minuten verliert der Lancom die Verbindung zu Easybell. Laufende Verbindungen sind davon nicht betroffen, aber die Erreichbarkeit während der Wiederverbindung ist eingeschränkt (keine Anrufe nach draussen; Anrufer klingeln, aber es kommt keine Verbindung zustande).

Ein Forumsbeitrag von Mai 2017 beleuchtet das Problem mit dem Ergebnis, das sich die FW10 anders verhält als die FW9.24. Bei der FW9.24 findet all 8 Minuten ein Reconnect zu den externen SIP-Accounts statt, die FW10 meldet sich zusätzlich vorher ab.

Wie im Forumsbeitrag beschrieben tauchen Pakete wie dieses in unserem SIP-Trace auf:

[SIP-Packet] 2017/08/04 09:06:30,065 Devicetime: 2017/08/04 09:06:33,611 [Packet]:
Sending datagram (686 Bytes) from 79.192.162.63:14519 to 195.185.37.60:5060 using TCP (RtgTag 0):
REGISTER sip:sip.easybell.de SIP/2.0\\r\\n
Via: SIP/2.0/TCP 79.192.162.63:14519;branch=...\\r\\n
From: <sip:004930xxxxxxx@sip.easybell.de>;tag=...\\r\\n
To: <sip:004930xxxxxxx@sip.easybell.de>\\r\\n
Call-ID: 004930xxxxxxx-sip.easybell.de-...\\r\\n
CSeq: 390 REGISTER\\r\\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS, PRACK, UPDATE, SUBSCRIBE\\r\\n
Max-Forwards: 70\\r\\n
Contact: *\\r\\n
Expires: 0\\r\\n
User-Agent: Lancom\\r\\n
Authorization: Digest username=...\r\\n
Content-Length: 0\\r\\n
\\r\\n

Diese führen zu dem beschriebenen Verlust der Verbindung mit anschliessendem Re-Login. Im Trace der FW9.24 sind Packete dieser Art nicht zu finden, dort gibt es auch das Problem nicht. Ich bin daher zurück auf die FW9.24 gewechselt.

<===

mit elektronischen Grüßen

Jens
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: Teilproblem Re-Registrierung SIP Leitungen mit 1783VAW

Beitrag von Jirka »

Hallo Jens,

ein De-REGISTER gibt es auch mit der 9.24 am Anfang, so wie es das De-REGISTER mit der 10.x eigentlich auch nur am Anfang geben sollte. Und Du hast oben angegebenes Paket mitten im laufenden Betrieb gesehen?

Viele Grüße,
Jirka
Jens.B
Beiträge: 50
Registriert: 08 Aug 2017, 10:32

Re: Teilproblem Re-Registrierung SIP Leitungen mit 1783VAW

Beitrag von Jens.B »

Hallo Jirka,

also ich habe mit der FW10 mit einem Trace die SIP-Pakete ca. 30 Minuten lang im normalen Betrieb mitgeschnitten und gespeichert. Da ich mich mit der Bedeutung der einzelnen Pakete nicht wirklich auskenne, habe ich nur nach den "Abmelde-Paketen" (Contact: * / Expires: 0) gesucht. Als klar war das die existieren und das Timing zu den Abmeldungen passt, bin ich zur FW9.24 gewechselt.

Damit habe ich wieder ca. 30 Minuten mitgeschnitten. Hier waren die "Abmelde-Pakete" nicht zu finden, es fanden auch keine Abmeldungen statt. Die anderen (Wieder-) Anmeldungen sehen bei FW10 und FW9.24 gleich aus, soweit ich das sagen kann. Die FW10 geht durch diesen Zyklus übrigens alle 10 Minuten, die FW9.24 alle 9 Minuten. Laut Easybell sind die 10 Minuten auch die bei denen eingestellte Anmeldezeit, danach muss neu angemeldet/verlängert werden. Ob der Lancom das berücksichtigt weiß ich nicht (Evtl. wartet der zu lange...??).

Was noch auffällt: Mit beiden Versionen der FW schlägt der jeweils 1. Versuch der (Wieder-) Anmeldung fehl, die entsprechende Anwort von Easybell:

[SIP-Packet] 2017/08/04 08:39:35,152 Devicetime: 2017/08/04 08:39:38,614 [Packet]:
Receiving datagram (546 Bytes) at 79.192.162.63:10853 from 195.185.37.60:5060 using TCP (RtgTag 0):
SIP/2.0 401 Unauthorized\r\n
...

Der Lancom wiederholt sofort, dann klappt es. Ich glaube nicht, das das was mit dem Verlust der Anmeldung zu tun hat, ich wollte es nur erwähnen.

Wie sehen denn die DE-Register-Pakete in der FW9.24 aus?

MfG

Jens
Jens.B
Beiträge: 50
Registriert: 08 Aug 2017, 10:32

Re: Teilproblem Re-Registrierung SIP Leitungen mit 1783VAW

Beitrag von Jens.B »

Hi Alle,

hier mal ein Update zur genannten Problematik:

Ich hatte mich am 7.8. an den Lancom-Support gewandt, nach einer Mail am 18.8. ("bitte warten...") kam dann gestern folgendes:

==>
Am 30.08.2017 um 17:41 schrieb support@lancom.de:
> Sehr geehrter Herr Baae,
>
> vielen Dank für Ihre Anfrage vom 07.08.2017. Um ein solches Verhalten zu klären benötigen wir
> einen Trace im "Fehlerfall". Ob und wann ein Update kommt, welches dieses Verhalten ändert ist
> mir nicht bekannt, da bis jetzt keine Meldung bei uns im Support eingegangen ist. ...
<==

Ich habe dann wie gewünscht einen Trace von 45 Minuten aufgezeichnet und hin geschickt. Zum Aufnehmen bin ich zur FW10.00.0170RU2 gewechselt, hinterher wieder zurück zur FW9.24.0153RU3.

Also nichts wirklich Neues, ausser das man im Trace die Abmeldung besser sehen kann (via "Call-Manager"). Wen's interessiert, ich habe mal einen Auszug für eine unserer Nummern angehängt (ich kann nix mit hochladen...).

Man sieht sehr schön, das die Leitung um 09:41:31,801 auf "not operable" geht, um 09:42:09,944 dann zurück auf "operable" wechselt (35 Sekunden ohne Login). Der erste Registrierungsversuch nach der Trennung schlägt wohl fehl, erst danach klappt's dann. Die Gültigkeit der Anmeldung ist dann 10 Minuten (new expires: 600), das deckt sich mit der Aussage von Easybell.

Nebenbei: Ich habe mich in meiner Antwort über die lange Reaktionszeit des Supports beschwert, da das jetzt schon mehrfach vorgekommen ist. Ist das da Standard, das man Wochen warten muss?


Mit elektronischen Grüßen

Jens

Code: Alles auswählen

[Callmanager] 2017/08/31 09:41:31,801  Devicetime: 2017/08/31 09:41:32,007 [EASYBELL6338 Registrar Transport]: Scheduling renewal (remote IP address 195.185.37.60 no longer resolvable through DNS)

[Callmanager] 2017/08/31 09:41:31,801  Devicetime: 2017/08/31 09:41:32,007 [SIP-Provider] : EASYBELL6338: renewing registrar transport due to expiration

[Callmanager] 2017/08/31 09:41:31,801  Devicetime: 2017/08/31 09:41:32,012 [SIP-Provider] : EASYBELL6338: stopRegistration: this:064e2200, caller:01a152d4, registration:enabled, register_info:active

[Callmanager] 2017/08/31 09:41:31,801  Devicetime: 2017/08/31 09:41:32,015 [SIP-Provider] : Line 'EASYBELL6338' changed status to 'NOT operable'

[Callmanager] 2017/08/31 09:41:31,801  Devicetime: 2017/08/31 09:41:32,018 [EASYBELL6338 Registrar Transport]: (Re)Starting with domain name "sip.easybell.de"

[Callmanager] 2017/08/31 09:41:31,801  Devicetime: 2017/08/31 09:41:32,018 [EASYBELL6338 Registrar Transport]: No (more) addresses to iterate -> Restarting

[Callmanager] 2017/08/31 09:41:31,801  Devicetime: 2017/08/31 09:41:32,018 [EASYBELL6338 Registrar Transport]: New restart backoff is 36 seconds

[Callmanager] 2017/08/31 09:41:31,801  Devicetime: 2017/08/31 09:41:32,018 [EASYBELL6338 Registrar Transport]: Restarting in 36 seconds

...

[Callmanager] 2017/08/31 09:42:07,754  Devicetime: 2017/08/31 09:42:08,018 [EASYBELL6338 Registrar Transport]: (Re)Starting with domain name "sip.easybell.de"

[Callmanager] 2017/08/31 09:42:07,754  Devicetime: 2017/08/31 09:42:08,018 [EASYBELL6338 Registrar Transport]: Got valid IP address from DNS cache

[Callmanager] 2017/08/31 09:42:07,754  Devicetime: 2017/08/31 09:42:08,018 [EASYBELL6338 Registrar Transport]: New transport endpoint is 195.185.37.60:5060, transport state is "FixedIpBootstrapping"

[Callmanager] 2017/08/31 09:42:07,754  Devicetime: 2017/08/31 09:42:08,018 [EASYBELL6338 Registrar Transport]: (Re)Starting with domain name "sip.easybell.de"

[Callmanager] 2017/08/31 09:42:07,754  Devicetime: 2017/08/31 09:42:08,018 [EASYBELL6338 Registrar Transport]: Got valid IP address from DNS cache

[Callmanager] 2017/08/31 09:42:07,754  Devicetime: 2017/08/31 09:42:08,018 [EASYBELL6338 Registrar Transport]: New transport endpoint is 195.185.37.60:5060, transport state is "FixedIpBootstrapping"

[Callmanager] 2017/08/31 09:42:07,804  Devicetime: 2017/08/31 09:42:08,029 [EASYBELL6339 Registrar Transport]: (Re)Starting with domain name "sip.easybell.de"

[Callmanager] 2017/08/31 09:42:07,804  Devicetime: 2017/08/31 09:42:08,029 [EASYBELL6339 Registrar Transport]: Got valid IP address from DNS cache

[Callmanager] 2017/08/31 09:42:07,804  Devicetime: 2017/08/31 09:42:08,029 [EASYBELL6339 Registrar Transport]: New transport endpoint is 195.185.37.60:5060, transport state is "FixedIpBootstrapping"

[Callmanager] 2017/08/31 09:42:07,804  Devicetime: 2017/08/31 09:42:08,041 [EASYBELL6340 Registrar Transport]: (Re)Starting with domain name "sip.easybell.de"

[Callmanager] 2017/08/31 09:42:07,804  Devicetime: 2017/08/31 09:42:08,041 [EASYBELL6340 Registrar Transport]: Got valid IP address from DNS cache

[Callmanager] 2017/08/31 09:42:07,804  Devicetime: 2017/08/31 09:42:08,041 [EASYBELL6340 Registrar Transport]: New transport endpoint is 195.185.37.60:5060, transport state is "FixedIpBootstrapping"

[Callmanager] 2017/08/31 09:42:07,804  Devicetime: 2017/08/31 09:42:08,047 [SIP-Provider] : EASYBELL6338: registrar transport is ready

[Callmanager] 2017/08/31 09:42:07,804  Devicetime: 2017/08/31 09:42:08,047 [SIP-Provider] : EASYBELL6338: startRegistration: this:064e2200, caller:01a198c0, registration:enabled, register_info:NOT active

[Callmanager] 2017/08/31 09:42:07,804  Devicetime: 2017/08/31 09:42:08,047 [SIP-Provider] : EASYBELL6338: RegisterTimeout: isNotAvailable:no, TimerExpired:no, this:064e2200

[Callmanager] 2017/08/31 09:42:07,804  Devicetime: 2017/08/31 09:42:08,047 [SIP-Provider] : EASYBELL6338: RegisterTimeout: eNaUnregister

[Callmanager] 2017/08/31 09:42:07,804  Devicetime: 2017/08/31 09:42:08,047 [SIP-Provider] : EASYBELL6338: Unregister: CallId:00493053696338-sip.easybell.de-ba0e10b1@00a0572ba034

[Callmanager] 2017/08/31 09:42:07,804  Devicetime: 2017/08/31 09:42:08,047 [SIP-CALL] : cSipCall constructor (type 2) --- call=06b794e0, MediaStub=06b799a8, SIP call-id=845143299@00a0572ba034

[Callmanager] 2017/08/31 09:42:07,804  Devicetime: 2017/08/31 09:42:08,047 [SIP-Provider] : EASYBELL6338: Unregister: created SIP call

[Callmanager] 2017/08/31 09:42:07,804  Devicetime: 2017/08/31 09:42:08,047 [SIP-Provider] : EASYBELL6338: processing pending messages -> registrar transport state:Ready, database has calls

[Callmanager] 2017/08/31 09:42:07,804  Devicetime: 2017/08/31 09:42:08,047 [SIP-Provider] : -----[ GENERATE REGISTER, call-id=541

[Callmanager] 2017/08/31 09:42:07,804  Devicetime: 2017/08/31 09:42:08,047 [SIP-Provider] : m_RegisterContactUri:<sip:00493053696338@217.246.170.62:13983>

[Callmanager] 2017/08/31 09:42:07,804  Devicetime: 2017/08/31 09:42:08,047 [SIP-Provider] : m_RegisterContactUri:<sip:00493053696338@217.246.170.62:13301>

[SIP-Packet] 2017/08/31 09:42:07,804  Devicetime: 2017/08/31 09:42:08,048 [Packet]: 
Sending datagram (689 Bytes) from 217.246.170.62:13301 to 195.185.37.60:5060 using TCP (RtgTag 0):
REGISTER sip:sip.easybell.de SIP/2.0\r\n
Via: SIP/2.0/TCP 217.246.170.62:13301;branch=z9hG4bK-3ebd4763-2e1dffe5;rport\r\n
From: <sip:00493053696338@sip.easybell.de>;tag=1434681905-1920447245\r\n
To: <sip:00493053696338@sip.easybell.de>\r\n
Call-ID: 00493053696338-sip.easybell.de-ba0e10b1@00a0572ba034\r\n
CSeq: 13 REGISTER\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS, PRACK, UPDATE, SUBSCRIBE\r\n
Max-Forwards: 70\r\n
Contact: *\r\n
Expires: 0\r\n
User-Agent: Lancom\r\n
Authorization: Digest realm="sip.easybell.de", 
Content-Length: 0\r\n
\r\n

[Callmanager] 2017/08/31 09:42:07,804  Devicetime: 2017/08/31 09:42:08,048 [SIP-Provider] : EASYBELL6338: restartShortRegisterTimer -> time:5, this:064e2200, Caller:01a283f0

[Callmanager] 2017/08/31 09:42:07,804  Devicetime: 2017/08/31 09:42:08,048 [SIP-Provider] : EASYBELL6338: processing pending messages -> registrar transport state:Ready, database has calls

[Callmanager] 2017/08/31 09:42:07,804  Devicetime: 2017/08/31 09:42:08,048 [SIP-Provider] : EASYBELL6338: No messages were pending!

[SIP-Packet] 2017/08/31 09:42:07,834  Devicetime: 2017/08/31 09:42:08,085 [Packet]: 
Receiving datagram (547 Bytes) at 217.246.170.62:13301 from 195.185.37.60:5060 using TCP (RtgTag 0):
SIP/2.0 401 Unauthorized\r\n
Via: SIP/2.0/TCP 217.246.170.62:13301;branch=z9hG4bK-3ebd4763-2e1dffe5;rport=13301\r\n
From: <sip:00493053696338@sip.easybell.de>;tag=1434681905-1920447245\r\n
To: <sip:00493053696338@sip.easybell.de>;tag=1d24a28a0bded6c40d31e6db8aab9ac6.3660\r\n
Call-ID: 00493053696338-sip.easybell.de-ba0e10b1@00a0572ba034\r\n
CSeq: 13 REGISTER\r\n
P-NGCP-Auth-IP: 212.172.97.118\r\n
P-NGCP-Auth-UA: Lancom\r\n
WWW-Authenticate: Digest realm="sip.easybell.de", 
Server: Sipwise NGCP Proxy 3.X\r\n
Content-Length: 0\r\n
\r\n

[Callmanager] 2017/08/31 09:42:07,834  Devicetime: 2017/08/31 09:42:08,085 [SIP-Provider] : cSipProviderLine::UnauthorizedHndl 1

[Callmanager] 2017/08/31 09:42:07,834  Devicetime: 2017/08/31 09:42:08,085 [SIP-Provider] : cSipProviderLine::UnauthorizedHndl 2  set true

[SIP-Packet] 2017/08/31 09:42:07,834  Devicetime: 2017/08/31 09:42:08,086 [Packet]: 
Sending datagram (689 Bytes) from 217.246.170.62:13301 to 195.185.37.60:5060 using TCP (RtgTag 0):
REGISTER sip:sip.easybell.de SIP/2.0\r\n
Via: SIP/2.0/TCP 217.246.170.62:13301;branch=z9hG4bK-bd1e4b59-af39b67a;rport\r\n
From: <sip:00493053696338@sip.easybell.de>;tag=1434681905-1920447245\r\n
To: <sip:00493053696338@sip.easybell.de>\r\n
Call-ID: 00493053696338-sip.easybell.de-ba0e10b1@00a0572ba034\r\n
CSeq: 14 REGISTER\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS, PRACK, UPDATE, SUBSCRIBE\r\n
Max-Forwards: 70\r\n
Contact: *\r\n
Expires: 0\r\n
User-Agent: Lancom\r\n
Authorization: Digest username="00493053696338", realm="sip.easybell.de", algorithm=MD5, uri="sip:sip.easybell.de", 
Content-Length: 0\r\n
\r\n

[Callmanager] 2017/08/31 09:42:07,834  Devicetime: 2017/08/31 09:42:08,086 [SIP-Provider] : EASYBELL6338: restartShortRegisterTimer -> time:5, this:064e2200, Caller:01a27ca0

[SIP-Packet] 2017/08/31 09:42:07,834  Devicetime: 2017/08/31 09:42:08,091 [Packet]: 
Receiving datagram (549 Bytes) at 217.246.170.62:11762 from 195.185.37.60:5060 using TCP (RtgTag 0):
SIP/2.0 401 Unauthorized\r\n
Via: SIP/2.0/TCP 217.246.170.62:11762;branch=z9hG4bK-79c2640a-76f05386;rport=11762\r\n
From: <sip:00493053696339@sip.easybell.de>;tag=-1652474829--1129914142\r\n
To: <sip:00493053696339@sip.easybell.de>;tag=1d24a28a0bded6c40d31e6db8aab9ac6.0ccd\r\n
Call-ID: 00493053696339-sip.easybell.de-2d478ab7@00a0572ba034\r\n
CSeq: 13 REGISTER\r\n
P-NGCP-Auth-IP: 212.172.97.118\r\n
P-NGCP-Auth-UA: Lancom\r\n
WWW-Authenticate: Digest realm="sip.easybell.de", 
Server: Sipwise NGCP Proxy 3.X\r\n
Content-Length: 0\r\n
\r\n

[Callmanager] 2017/08/31 09:42:07,834  Devicetime: 2017/08/31 09:42:08,092 [SIP-Provider] : cSipProviderLine::UnauthorizedHndl 1

[Callmanager] 2017/08/31 09:42:07,834  Devicetime: 2017/08/31 09:42:08,092 [SIP-Provider] : cSipProviderLine::UnauthorizedHndl 2  set true

[SIP-Packet] 2017/08/31 09:42:07,854  Devicetime: 2017/08/31 09:42:08,124 [Packet]: 
Receiving datagram (445 Bytes) at 217.246.170.62:13301 from 195.185.37.60:5060 using TCP (RtgTag 0):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/TCP 217.246.170.62:13301;branch=z9hG4bK-bd1e4b59-af39b67a;rport=13301\r\n
From: <sip:00493053696338@sip.easybell.de>;tag=1434681905-1920447245\r\n
To: <sip:00493053696338@sip.easybell.de>;tag=1d24a28a0bded6c40d31e6db8aab9ac6.3660\r\n
Call-ID: 00493053696338-sip.easybell.de-ba0e10b1@00a0572ba034\r\n
CSeq: 14 REGISTER\r\n
P-NGCP-Auth-IP: 212.172.97.118\r\n
P-NGCP-Auth-UA: Lancom\r\n
Server: Sipwise NGCP Proxy 3.X\r\n
Content-Length: 0\r\n
\r\n

[Callmanager] 2017/08/31 09:42:07,854  Devicetime: 2017/08/31 09:42:08,124 [SIP-Provider] : SIP WAN line OkHndl(): sequence valid:yes, message method:6

[Callmanager] 2017/08/31 09:42:07,854  Devicetime: 2017/08/31 09:42:08,124 [SIP-Provider] : -----[ 200 REGISTER OK HANDLE, call 06b794e0, message's sequence 14, call's sequence 14

[Callmanager] 2017/08/31 09:42:07,854  Devicetime: 2017/08/31 09:42:08,124 [SIP-Provider] : RegisterOkHndl: Unregister -> restartShortRegisterTimer

[Callmanager] 2017/08/31 09:42:07,854  Devicetime: 2017/08/31 09:42:08,124 [SIP-Provider] : EASYBELL6338: restartShortRegisterTimer -> time:2, this:064e2200, Caller:01a28d08

[Callmanager] 2017/08/31 09:42:07,854  Devicetime: 2017/08/31 09:42:08,125 [CALL-INFO] : ~cCmCallInfo 0 -> Caller:022bacac,  Cln.Number:00493053696338, Cld.Number:00493053696338

[Callmanager] 2017/08/31 09:42:07,854  Devicetime: 2017/08/31 09:42:08,125 [CALL-INFO] : ~cCmCallInfo 0.1 -> Caller:022bacac

[Callmanager] 2017/08/31 09:42:07,854  Devicetime: 2017/08/31 09:42:08,125 [CALL-INFO] : ~cCmCallInfo 2 -> Caller:022bacac

[Callmanager] 2017/08/31 09:42:07,854  Devicetime: 2017/08/31 09:42:08,125 [VCM] : cCmCall::ClearCall

[Callmanager] 2017/08/31 09:42:07,854  Devicetime: 2017/08/31 09:42:08,125 [VCM] : cCmCall::~cCmCall  Cln.Number:, Cld.Number:

[Callmanager] 2017/08/31 09:42:09,874  Devicetime: 2017/08/31 09:42:10,124 [SIP-Provider] : EASYBELL6338: RegisterTimeout: isNotAvailable:no, TimerExpired:yes, this:064e2200

[Callmanager] 2017/08/31 09:42:09,874  Devicetime: 2017/08/31 09:42:10,124 [SIP-Provider] : EASYBELL6338: RegisterTimeout: eNaRegister

[Callmanager] 2017/08/31 09:42:09,874  Devicetime: 2017/08/31 09:42:10,124 [SIP-Provider] : EASYBELL6338: Register: CallId:00493053696338-sip.easybell.de-ba0e10b1@00a0572ba034

[Callmanager] 2017/08/31 09:42:09,874  Devicetime: 2017/08/31 09:42:10,124 [SIP-CALL] : cSipCall constructor (type 2) --- call=06b7be00, MediaStub=06b7c2c8, SIP call-id=159331167@00a0572ba034

[Callmanager] 2017/08/31 09:42:09,874  Devicetime: 2017/08/31 09:42:10,124 [SIP-Provider] : EASYBELL6338: Register: created SIP call

[Callmanager] 2017/08/31 09:42:09,874  Devicetime: 2017/08/31 09:42:10,124 [SIP-Provider] : EASYBELL6338: processing pending messages -> registrar transport state:Ready, database has calls

[Callmanager] 2017/08/31 09:42:09,874  Devicetime: 2017/08/31 09:42:10,125 [SIP-Provider] : -----[ GENERATE REGISTER, call-id=545

[Callmanager] 2017/08/31 09:42:09,874  Devicetime: 2017/08/31 09:42:10,125 [SIP-Provider] : m_RegisterContactUri:<sip:00493053696338@217.246.170.62:13301>

[Callmanager] 2017/08/31 09:42:09,874  Devicetime: 2017/08/31 09:42:10,125 [SIP-Provider] : m_RegisterContactUri:<sip:00493053696338@217.246.170.62:13301>

[SIP-Packet] 2017/08/31 09:42:09,874  Devicetime: 2017/08/31 09:42:10,125 [Packet]: 
Sending datagram (744 Bytes) from 217.246.170.62:13301 to 195.185.37.60:5060 using TCP (RtgTag 0):
REGISTER sip:sip.easybell.de SIP/2.0\r\n
Via: SIP/2.0/TCP 217.246.170.62:13301;branch=z9hG4bK-d021b370-8bba33ae;rport\r\n
From: <sip:00493053696338@sip.easybell.de>;tag=243768656--221953372\r\n
To: <sip:00493053696338@sip.easybell.de>\r\n
Call-ID: 00493053696338-sip.easybell.de-ba0e10b1@00a0572ba034\r\n
CSeq: 15 REGISTER\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS, PRACK, UPDATE, SUBSCRIBE\r\n
Max-Forwards: 70\r\n
Contact: <sip:00493053696338@217.246.170.62:13301;transport=TCP>\r\n
Expires: 480\r\n
User-Agent: Lancom\r\n
Authorization: Digest username="00493053696338", realm="sip.easybell.de", algorithm=MD5, uri="sip:sip.easybell.de", 
Content-Length: 0\r\n
\r\n

[Callmanager] 2017/08/31 09:42:09,874  Devicetime: 2017/08/31 09:42:10,125 [SIP-Provider] : EASYBELL6338: restartShortRegisterTimer -> time:5, this:064e2200, Caller:01a28370

[SIP-Packet] 2017/08/31 09:42:09,934  Devicetime: 2017/08/31 09:42:10,169 [Packet]: 
Receiving datagram (522 Bytes) at 217.246.170.62:13301 from 195.185.37.60:5060 using TCP (RtgTag 0):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/TCP 217.246.170.62:13301;branch=z9hG4bK-d021b370-8bba33ae;rport=13301\r\n
From: <sip:00493053696338@sip.easybell.de>;tag=243768656--221953372\r\n
To: <sip:00493053696338@sip.easybell.de>;tag=1d24a28a0bded6c40d31e6db8aab9ac6.d9d4\r\n
Call-ID: 00493053696338-sip.easybell.de-ba0e10b1@00a0572ba034\r\n
CSeq: 15 REGISTER\r\n
P-NGCP-Auth-IP: 212.172.97.118\r\n
P-NGCP-Auth-UA: Lancom\r\n
Server: Sipwise NGCP Proxy 3.X\r\n
Contact: <sip:00493053696338@217.246.170.62:13301;transport=TCP>;expires=600\r\n
Content-Length: 0\r\n
\r\n

[Callmanager] 2017/08/31 09:42:09,934  Devicetime: 2017/08/31 09:42:10,170 [SIP-Provider] : SIP WAN line OkHndl(): sequence valid:yes, message method:6

[Callmanager] 2017/08/31 09:42:09,934  Devicetime: 2017/08/31 09:42:10,170 [SIP-Provider] : -----[ 200 REGISTER OK HANDLE, call 06b7be00, message's sequence 15, call's sequence 15

[Callmanager] 2017/08/31 09:42:09,934  Devicetime: 2017/08/31 09:42:10,170 [SIP-Provider] : RegisterOkHndl: found contact with expires value: Contact.Expires:600, ResponseUri:<sip:00493053696338@217.246.170.62:13301;transport=TCP>, RegisterUri:<sip:00493053696338@217.246.170.62:13301>

[Callmanager] 2017/08/31 09:42:09,944  Devicetime: 2017/08/31 09:42:10,170 [SIP-Provider] : RegisterOkHndl: new expires: 600

[Callmanager] 2017/08/31 09:42:09,944  Devicetime: 2017/08/31 09:42:10,172 [SIP-Provider] : Line 'EASYBELL6338' changed status to 'operable'

[Callmanager] 2017/08/31 09:42:09,944  Devicetime: 2017/08/31 09:42:10,176 [SIP-Provider] : EASYBELL6338: restartRegisterTimer -> MinExpiresTime:0, time:600, this:064e2200, Caller:01a287bc

hubiuwe
Beiträge: 27
Registriert: 17 Jan 2016, 08:23
Wohnort: Mainz

Re: Teilproblem Re-Registrierung SIP Leitungen mit 1783VAW

Beitrag von hubiuwe »

Hallo Zusammen!
Ich habe auch das Problem mit easybell und Portunity.
Bei meinen 1und1 SIP-Leitungen tritt das Problem nicht auf. Dazu unten mehr.

Die Zeile im Trace von Jens.B hat mich stutzig gemacht.

Code: Alles auswählen

[Callmanager] 2017/08/31 09:41:31,801  Devicetime: 2017/08/31 09:41:32,007 [EASYBELL6338 Registrar Transport]: Scheduling renewal (remote IP address 195.185.37.60 no longer resolvable through DNS)
Danach habe ich über lange zeit einige TRACES trace + VCM-DNS trace + SIP-Packet

Code: Alles auswählen

[VCM-DNS] 2017/09/17 18:48:16,662  Devicetime: 2017/09/17 18:48:16,572 [SIP DNS Cache]: Queried resolving of host name "sip.sipport.de" (Tag 0) with transaction ID 43542

[VCM-DNS] 2017/09/17 18:48:16,865  Devicetime: 2017/09/17 18:48:16,593 [SIP DNS Cache]: Processing DNS client response for transaction ID 43542

[VCM-DNS] 2017/09/17 18:48:16,865  Devicetime: 2017/09/17 18:48:16,593 [SIP DNS Cache]: Updated address record for "sip.sipport.de" with IP address 188.246.0.82 to TTL 0

[VCM-DNS] 2017/09/17 18:48:21,669  Devicetime: 2017/09/17 18:48:21,572 [SIP DNS Cache]: Entry <_sip._udp.sip.sipport.de, Tag 0>: Erased address record "sip.sipport.de" (188.246.0.82) (expired)
Auffällig ist der TTL von 0
Zu diesem Zeitpunkt tritt der Fehler auf und die Leitung wechselt auf "NOT operable"

Das Problem kommt also vom SIP-DNS-Cache
Also weiter mit " trace + VCM-DNS trace + DNS"

Code: Alles auswählen

[VCM-DNS] 2017/09/17 19:15:51,735  Devicetime: 2017/09/17 19:15:51,572 [SIP DNS Cache]: Entry <_sips._tcp.sip.easybell.de, Tag 0>: Renewing address record "sip.easybell.de" (195.185.37.60) since TTL expired

[VCM-DNS] 2017/09/17 19:15:51,735  Devicetime: 2017/09/17 19:15:51,572 [SIP DNS Cache]: Queried resolving of host name "sip.easybell.de" (Tag 0) with transaction ID 53220


[DNS] 2017/09/17 19:15:51,954  Devicetime: 2017/09/17 19:15:51,583
DNS Rx (intern): Src-IP 192.168.X.X, RtgTag 0
Query Request: STD A for sip.easybell.de
Not found in local DNS database => forward to next server

[DNS] 2017/09/17 19:15:51,954  Devicetime: 2017/09/17 19:15:51,583 [info] : 
create new source map entry for 192.168.X.X
using IPv6 DNS server 2003:180:2:8100::53 on 1UND1

[DNS] 2017/09/17 19:15:51,954  Devicetime: 2017/09/17 19:15:51,594
DNS Rx (1UND1): Src-IP 2003:180:2:8100::53, RtgTag 0
Query Response:
STD A sip.easybell.de ip resolved to 195.185.37.60 (TTL = 0)

[VCM-DNS] 2017/09/17 19:15:51,954  Devicetime: 2017/09/17 19:15:51,594 [SIP DNS Cache]: Processing DNS client response for transaction ID 53220

[VCM-DNS] 2017/09/17 19:15:51,954  Devicetime: 2017/09/17 19:15:51,594 [SIP DNS Cache]: Updated address record for "sip.easybell.de" with IP address 195.185.37.60 to TTL 0
Der DNS-Forwarder im LC liefert ab und zu eine DNS Response mit TTL=0.
Das ist der Auslöser für den Fehler.
Bei 1und1 tritt es "nicht" auf da die Standard TTL über 60000 liegt, daß man den Verfall genau trifft ist damit sehr unwahrscheinlich.


Die Frage ist jetzt warum wird überhaupt eine Antwort mit TTL=0 zurückgeliefert.
Ich werde versuchsweise andere DNS-Server einstellen.
Zuletzt geändert von hubiuwe am 18 Sep 2017, 15:10, insgesamt 1-mal geändert.
Jens.B
Beiträge: 50
Registriert: 08 Aug 2017, 10:32

Re: Teilproblem Re-Registrierung SIP Leitungen mit 1783VAW

Beitrag von Jens.B »

Hallo Alle,

hier gibt's auch was Neues (naja, nicht wirklich...).

Auf die Zusendung der Traces hat sich der Support gemeldet mit der Aussage:
"...ich habe mir den Trace angeschaut und zusätzlich noch einen VoIP-Experten aus unserem Haus über den Trace schauen lassen. Alle 480 Sekunden wird neu registriert. Ein "DEREGISTER" ist im Trace nicht vorhanden. Auch ist die Leitung dauerhaft als "registered" in den Tabellen. Die korrekte Paketreihenfolge im Trace ist: REGISTER->401UNAUTORIZED(Provider)->REGISTER(mit Zusatzinfos)->OK(vom Provider).
Im Trace ist kein Fehlverhalten erkennbar."

Ich habe dann geantwortet:
"...so ganz kann ich Ihren Ausführungen nicht folgen.
Wenn - wie Sie sagen - alles ok ist, warum gehen die angezeigten SIP-Registrierungen im LANmonitor regelmässig verloren? Und warum passiert das mit der FW10.00, mit der FW9.24 aber nicht?
Ich habe die aufgenommenen Traces mal gefiltert, erst nach "[Callmanager]", dann nach "6338". Anbei finden Sie den entsprechenden Auszug als TXT und PDF. Die 6338 entpricht einer der genutzten Nummern/Accounts (00493053696338). Alle gezeigten Zeilen wiederholen sich im Trace für alle 4 Accounts.
Man sieht in Zeile 7, wie die Leitung EASYBELL6338 auf 'NOT operable' wechselt. Zu diesem Zeitpunkt wechselt die Anzeige im LANmonitor von "... (Registriert)" auf "! ... (Registrierungsversuch)". Im Log sieht man dann die Versuche der Registrierung, nachdem das geklappt hat, wechselt die Leitung in Zeile 39 zurück auf 'operable'. Die Anzeige im LANmonitor wechselt zurück auf "... (Registriert)". Dazwischen liegen immerhin 15 Sekunden.
In Zeile 77 bis Zeile 110 wiederholt sich sich das Ganze dann nochmal, diesmal dauert es ganze 38 Sekunden.
Nach meiner Interpretation ist das genau der geschilderte Verlust der Registrierung, oder sehe ich das falsch?
Und nochmal zum DEREGISTER:
Diese information stammt aus dem Lancom-Forum, wo ein ähnlich gearteter Fall diskutiert wurde. Dort wurde ein SIP-Paket der Form
[SIP-Packet] 2017/08/31 09:14:48,903 Devicetime: 2017/08/31 09:14:49,048 [Packet]:
Sending datagram (687 Bytes) from 217.246.170.62:13983 to 195.185.37.60:5060 using TCP (RtgTag 0):
REGISTER sip:sip.easybell.de SIP/2.0\r\n
Via: SIP/2.0/TCP 217.246.170.62:13983;branch=z9hG4bK-fdef8e1b-17b3c7d1;rport\r\n
From: <sip:00493053696338@sip.easybell.de>;tag=635880649--453563702\r\n
To: <sip:00493053696338@sip.easybell.de>\r\n
Call-ID: 00493053696338-sip.easybell.de-ba0e10b1@00a0572ba034\r\n
CSeq: 6 REGISTER\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS, PRACK, UPDATE, SUBSCRIBE\r\n
Max-Forwards: 70\r\n
Contact: *\r\n
Expires: 0\r\n
User-Agent: Lancom\r\n
Authorization: Digest username="00493053696338", realm="sip.easybell.de", algorithm=MD5, uri="sip:sip.easybell.de", ...\r\n
Content-Length: 0\r\n
\r\n
als De-Register bezeichnet wegen "Expires: 0".
Ob das stimmt weiß ich nicht. Diese Pakete kommen allerdings im Log der FW10.00 vor, bei der FW9.24 dagegen nicht."

Dann wieder der Lancom-Support:
"...Ich habe nochmal mit einem Kollegen gesprochen. Tatsächlich sind REGISTER Pakete mit "Expires: 0" DEREGISTER-Pakete. Diese werden nach Anfrage bei der Entwicklung auch mit der 9.24.0261 RU5 gesendet. Einen direkten Zusammenhang mit den Fehlern in der Registrierung sieht mein Kollege nicht. Ich habe nochmal eine angepasste Trace-Konfiguration angehängt, die Sie bitte mit der 9.24 und der LCOS 10 ausführen. Ohne diesen Vergleich kann das Verhalten nicht genau analysiert werden."

Also schön, noch ein Trace. Die Parameter der mitgeschickten VoIP.lcg-Datei sehen so aus:
[TraceCfg2.0]
trace + Callmanager
trace + SIP-Packet
trace + VCM-DNS

[Console Section]
0 bootlog
5 Status/Voice-Call-Manager/Lines

Ich habe jeweils 45 Minuten mit der FW9.24 und der FW10.00 aufgezeichnet. Die Ergebnisse sind kürzer, entsprechen aber im Wesentlichen den vorangegangenen Traces (FW10 verliert die Registrierung, FW9 nicht).

Jetzt wieder ich:
"...bis jetzt war ich bestenfalls verwundert, nun bin ich aber ziemlich irritiert.

1.) Die ganze Sache hat doch mit meiner Problembeschreibung und dem Hinweis auf die De-Register-Pakete angefangen. Aber erst nach einem erneuten Hinweis wird das überhaupt berücksichtigt.

2.) Das Sie nun die "Spur" dieser Pakete aufnehmen ist ja erfreulich. Ich frage mich allerdings, warum Sie die Existenz und die Wirkung der De-Register-Pakete erst prinzipiell verneinen (Zitat: "Ein "DEREGISTER" ist im Trace nicht vorhanden." ), dann nach wiederum erneuter Rücksprache mit den "VoIP-Experten" sind die plötzlich vorhanden und machen auch das besagte, und jetzt schicken auch noch beide FW-Versionen diese Pakete. Abgesehen davon, das wir von der FW9.24.0153RU3 reden (und nicht ...RU5) kann ich hierüber nur den Kopf schütteln.

3.) Ich werde das Gefühl nicht los, das ich hier ihren Job mache. Diese Traces mit den verschiedenen FW-Versionen, das Filtern der Logs, die Suche nach Hinweisen im Internet/Foren, das Alles können Sie doch auch machen, und das mit einem müden Lächeln. Wir stehen jetzt nach 6 Wochen da, wo ich nach ca. 2 Stunden Internetrecherche war. Nur das ich hier nach etlichen zusätzlichen Stunden meiner Zeit von Ihnen höre: "Das ist ja interessant, da kann ich aber nichts zu sagen. Kann ich noch einen Trace haben?". Man-O-Man...

So, das musste mal raus.

Ich hatte schon am 4.8.2017 zwei Traces gemacht (FW9.24 und FW10), dort sind allerdings nur die SIP-Pakete zu sehen. In diesen Logs taucht eben das beschriebene De-Register-Paket nur in der FW9.24 auf, in der FW10.00 eben nicht. Das war dann für mich der Anlass, mich an den Support zu wenden. Ich schicke die Traces mal mit, da sieht man das nämlich ganz gut."

Kleiner Verschreiber im letzten Absatz, da sind die FW-Versionen vertauscht...

Jetzt ist wieder der Support dran.

Und Sorry für die länglichen Zitate, aber langsam kommen mir Zweifel am Support-Willen bzw. -können des Supports. Das Thema ist technisch sicherlich komplex, aber das gebotene Hin und Her macht keinen Spass.

Hubiuwe:
Die Fehler bzw. Merkwürdigkeiten habe ich auch bemerkt. Es wäre schön, wenn Du dich damit auch an den Lancom-Support wenden würdest.
a) Damit die das Problem/mögliche Ursache mitkriegen.
b) Damit die sehen, das mehr als einer das Problem haben.

Wundert mich sowieso, das da nicht mehr passiert. Ist die Kombination Lancom/Easybell so selten? Easybell sagt, sie haben mehrere Kunden mit Lancom. Lancom sagt, ich bin der Einzige mit dem Problem. Bei anderen VoIP-Anbietern scheint es keine Probleme zu geben, oder?


Mit elektronischen Grüßen

Jens
Jens.B
Beiträge: 50
Registriert: 08 Aug 2017, 10:32

Re: Teilproblem Re-Registrierung SIP Leitungen mit 1783VAW

Beitrag von Jens.B »

Hi Alle,

noch mal zu den De-Register-Paketen:

Beim Lesen der gesammelten Texte ist mir aufgefallen, das sowohl der Lancom-Support als auch Jirka (hier aus dem Forum) sagen, das auch die FW9.24 solche Pakete versendet. Ich habe die im Log der FW9.24 nicht gesehen. Daher noch mal die genauen verglichenen Versionen:

9.24.0153RU3 <--> 10.00.0170RU2

Ist da schon innerhalb der FW9.24 was geändert worden?


Mit elektronischen Grüßen

Jens
Jens.B
Beiträge: 50
Registriert: 08 Aug 2017, 10:32

Re: Teilproblem Re-Registrierung SIP Leitungen mit 1783VAW

Beitrag von Jens.B »

Hi Alle,

heute mittag hat sich der Lancom-Support gemeldet:

"... Das Verhalten ist jedoch nicht auf die DE-Register Pakete zurückzuführen sondern vermutlich auf die interne DNS-Auflösung im Voice-Call-Manager bei unterschiedlichen Anbietern. Mit Anschlüssen der deutschen Telekom oder Vodafone ist ein solches Verhalten noch nicht bekannt. Deswegen habe ich auch den neuen Trace benötigt. Dieses Verhalten konnte ich schon bei einem weiteren Kunden beobachten. Dieses Verhalten muss ich jedoch mit der Entwicklung besprechen."

Offensichtlich rückt jetzt die DNS-Auflösung ins Visier...

Hubiuwe:
Hattest Du dich schon beim Support gemeldet? Es gibt einen weiteren Kunden ausser mir... ;-)


Mit elektronischen Grüßen

Jens
hubiuwe
Beiträge: 27
Registriert: 17 Jan 2016, 08:23
Wohnort: Mainz

Re: Teilproblem Re-Registrierung SIP Leitungen mit 1783VAW

Beitrag von hubiuwe »

Hallo Zusammen.

Hatte noch keine Zeit. Werde versuchen heute Abend noch ein paar Traces zu machen und mich an den Support wenden.

Ich werde auch mal alternative DNS Server testen.

Gruß
hubiuwe
Beiträge: 27
Registriert: 17 Jan 2016, 08:23
Wohnort: Mainz

Re: Teilproblem Re-Registrierung SIP Leitungen mit 1783VAW

Beitrag von hubiuwe »

Hallo

Ich habe jetzt versuchsweise im LC alle Provider DNS-Server durch Google DNS-Server ersetzt.
Der Versuch über eine Stunde zeigte ein viel :mrgreen: besseres Verhalten.

Das o.g. Problem trat in der einen Stunde nur 1 mal auf.
DNS TTL hatte 1 mal kurz einen Wehrt von 0.
Die sofortige DNS-Anfrage bei einem Googleserver lieferte wieder einen aktuellen Wehrt und die SIP-Leitung wechselte sofort wieder auf bereit.
Dabei war die Leitung nur 1s nicht verfügbar.

Das ist wohl erst mal ein Workaround.
Bitte mal testen.
Ich werde mich auch noch an den Support wenden.

Durch meinen Anbieter 1und1 (Carrier = Telekom) zugewiesene DNS-Server:
2003:180:2:8100::53
2003:180:2:8000::53
217.237.148.22
217.237.150.51

Versuchsweise eingesetzte Google-Server:
8.8.8.8
8.8.4.4
2001:4860:4860::8888
2001:4860:4860::8844

Gruß Uwe
Jens.B
Beiträge: 50
Registriert: 08 Aug 2017, 10:32

Re: Teilproblem Re-Registrierung SIP Leitungen mit 1783VAW

Beitrag von Jens.B »

Hallo Uwe,

das klingt doch schon mal besser. Wie Du auch bemerkst sollte die SIP-Leitung eigentlich nie in den Zustand "not operable" gehen, auch nicht für eine Sekunde...

Kann man im Router eigentlich zu einem Net-Namen eine feste IP hinterlegen? Oder als SIP-Server eine IP eintragen? Nicht gut, ich weiß, so könnte man aber die DNS-Auflösung umgehen.

Danke für die Mühe, mal sehen was bei rum kommt.


Mit elektronischen Grüßen

Jens
Antworten