[Gelöst] SIP-User verliert Registrierung

[eddy08]

Hallo,

ich benötige im Lancom 1803VAW und N670IP einen zusätzlichen SIP-User, dieser wurde im Lancom und N670IP hinterlegt.
Dieser funktioniert soweit nur leider verliert er nach einigen Stunden die Verbindung und wird im Lanmonitor als "Nicht registriert" anzeigt.
Die DECT-Mobilteil sind davon nicht betroffen und sind weiterhin registriert.

Hier ein Tracelog vom Lancom.

Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,630 [VCM] : Destruct CmCall(1b0f0050)  Cln.Number:, Cld.Number:

[SIP-Connection] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,630 [SIP UDP Transport (192.168.10.10:5060)]: Discarding (local socket was 192.168.10.1:5060, Tag 0)

[SIP-Connection] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,630 [SIP UDP Transport (192.168.10.10:5060)]: Processing new inbound SIP message

[SIP-Connection] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,630 [SIP UDP Transport (192.168.10.10:5060)]: VCM registrar proceeds with REGISTER request

[Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,631 [SIP]: cSipCallDb::FindCall - CallId: e82318bb-ec6e-4315-81e2-d636ef2ba00d, pCall->GetCallId(): e82318bb-ec6e-4315-81e2-d636ef2ba00d

[Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,631 [Registrar] : - info       : SipRegistrarProcessMessage: SIP call=1adfc050

[Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,631 [Registrar] : - info       : checking authentication: local auth required=yes, is VPN WAN packet=no

[Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,631 [Registrar] : - info       : REGISTER accepted (auth OK)

[Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,631 [Registration Registry]: cSipRegistrationRegistry::UpdateRegistration  -- iter-isTrunkUser:  0,  iter-Name: 10,  To-Name: 10

[Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,631 [Registration Registry]: cSipRegistrationRegistry::UpdateRegistration  --  iter-Domain: intern,  To-Domain: intern

[Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,631 [Registration Registry]: cSipRegistrationRegistry::UpdateRegistration  2

[Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,631 [SIP Registration]: 10@intern: cSipRegistration::UpdateRegistration  --  isTrunkUser: No

[Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,631 [SIP Registration]: 10@intern: cSipRegistration::UpdateRegistration  --  iter-Name: 10,  Contact-Name: 10

[Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,631 [SIP Registration]: 10@intern: cSipRegistration::UpdateRegistration  --  iter-Domain: 192.168.10.10,  Contact-Name: 192.168.10.10

[Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,631 [SIP-URI]: URI COMPARISON

[Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,631 [SIP Registration]: 10@intern: Removing deliberately expiring binding <sip:[email protected]:5060;transport=UDP>

[SIP-Connection] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,631 [SIP UDP Transport (192.168.10.10:5060)]: Discarding (local socket was 192.168.10.1:5060, Tag 0)

[Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,638 [SIP-Binding] : Destruct cEntity(1adaa850)

[Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,638 [Registration Registry]: No bindings remain, removing registration

[Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,646 [SIP Registration]: 10@intern: Registration destroyed

[Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,646 [SIP]: SipMsgMakeCommonPart - Uri Type: sip

[Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,646 [SIP-CALL] : stop session timer for call 0x1adfc050

[Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,646 [SIP-CALL] : stop session refresh timer for call 0x1adfc050

[Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,647 [SIP]: cSipCallDb::RemoveCall - CallId: e82318bb-ec6e-4315-81e2-d636ef2ba00d

[SIP-Connection] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,648 [SIP UDP Transport (192.168.10.10:5060)]: Discarding (local socket was 192.168.10.1:5060, Tag 0)

[Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,648 [CALL-INFO] : Destruct CallInfo(1adfc050)  -> Caller:03c58d58,  Cln.Number:10, Cld.Number:

[Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,648 [CALL-INFO] : ~cCmCallInfo 0

[Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,648 [CALL-INFO] : ~cCmCallInfo 1

[Callmanager] 2025/10/22 07:27:37,120  Devicetime: 2025/10/22 07:27:36,648 [VCM] : cCmCall::ClearCall

Vielen Dank
Eddy

 

[sonyKatze]

Man müsste genau Deine Geräte haben, also irgendeinen Router mit LCOS und ALL-IP-Option und eines der aktuellen Gigaset DECT-Single-Cell. Dann könnte man versuchen Deinen Fall nachzubauen. Wird hier aber niemand haben. Mein Tipp:

a) im Lancom „eigenen“ Forum fragen​

b) SIP-Mitschnitte liefern​

Weißt Du wie Letzteres geht? Am Einfachsten wäre wohl einen Port im Lancom auf Port-Mirroring zu stellen, einen Computer mit Wireshark dran und dann mitlaufen lassen … und auf „sip“ filtern. Klingt jedenfalls so, also würde die Gigaset ihr Re-REGISTER zu spät oder gar nicht machen.

zusätzlichen SIP-User

Klingt so, also würde parallel ein SIP-User tun, richtig?

 

[Deleted member 468195]

Überprüfe bitte in der N670 IP im entsprechenden Profil unter „Provider- oder PBX-Profile“ die Einstellung „Anmelde-Refreshzeit“.
Standardmäßig steht dieser Wert auf 600 Sekunden, das ist jedoch zu lang für den LANCOM, der einen Expires-Wert von 120 Sekunden vorgibt.
Setze die Refresh-Zeit daher auf einen Wert ≤ 120 Sekunden – damit bleibt die Registrierung dauerhaft stabil und die Verbindung wird nicht mehr unterbrochen.

 

[sonyKatze]

An sowas bitte nicht Herumschrauben, auf keinen Fall ohne Mitschnitt. Die Anmelde-Refreshzeit wird ausgehandelt, d.h. man kann zwar eine Zeitspanne und das Maximum vorgeben, braucht die Gegenseite aber etwas Kürzeres, dass muss sie das sagen. Oder anders formuliert: Wenn man das Problem so einfach lösen könnte, wäre das ein Workaround aber nicht die Ursache. Kann nämlich auch sein, dass das Re-REGISTER nicht ankommt (wegen irgendwelchen Subnetze oder VLANs) oder falsch zugeordnet wird. Hier hilft wirklich nur ein Mitschnitt. Wenn das zu kompliziert ist oder dazu Schritte unklar sind, bitte einfach melden.

 

[eddy08]

@Fall

Die Expires-Wert von 120 Sekunden habe ich schon verändert, gleiches Problem.

@sonyKatze

Ich kann den kompletten SIP-Mitschnitt, gern per PM senden.

Zum testen habe ich mal den SIP-User von 10 auf 99 geändert, damit ich nicht mit evtl. N670IP-Nummer wie 10,11,12 usw.
in Konflikt komme, macht keinen Unterschied. Nach ca. ca. 12 Stunden ist die Nummer nicht mehr registriert.

 

[sonyKatze]

In der ersten Antwort des Lancom, steht im Header Contact: der Parameter expires=? Welche Zeitspanne ist dort angegeben und wann macht Gigaset ein Re-REGISTER?

 

[eddy08]

Meinst du diese Zeile?

[Callmanager] 2025/10/22 07:21:26,255 Devicetime: 2025/10/22 07:21:25,745 [SIP Binding]: <sip:[email protected]:5060;transport=UDP>: New expiration time: 120s (was 60s)

 

[sonyKatze]

Nein, ich meine die Ethernet-Mitschnitte (Wireshark oder Port-Mirroing oder Mirror-Port oder LCOScap oder RPCap oder …). Das was Du gepostet hast, ist bereits (mindestens) eine Interpretation des Protokoll-Ablaufs. Für die Analyse sind quasi die rohen Ethernet-Daten nötig.

 

[eddy08]

Ich hab nochmal eine Trace mit Lanconfig gestartet mit den Einstellungen Provisioning, SIP-Connection und SIP-Packet.
Die Rufnummer 10 ist vorhanden, bis zu dem Zeitpunkt wo ein neues Provisioning durch den N670IP gestartet wird, danach werden die Daten
vom Lancom als TRUNK_0000 abgeholt. Es gibt danach noch einen Versuch die Rufnummer 10 anzumelden mit Expires: 0, danach ist Ende für 10 im Trace.

Die Rufummer 10 ist im Lancom unter den SIP-Nummer hinterlegt, zusätzlich noch im N670IP als TRUNK_0001.

Und ich denke hier ist das Problem, eigentlich sollte beim Provisioning der SIP-User 10 vom LANCOM automatisch kommen?
Da dies nicht funktioniert hat, habe ich ihn manuell im N670IP hinterlegt, bis zu dem Tag als ich bemerkte, die 10 ist irgendwann weg

[SIP-Packet] 2025/10/30 10:08:15,467  Devicetime: 2025/10/30 10:08:15,248 [Packet]:
Receiving datagram (613 Bytes) at 192.168.10.1:5060 from 192.168.10.101:5060 using UDP (RtgTag 0):
REGISTER sip:intern SIP/2.0\r\n
Via: SIP/2.0/UDP 192.168.10.101:5060;rport;branch=z9hG4bKPj1b2b5697-c7e3-43c2-b4e4-92070583cc49\r\n
Max-Forwards: 70\r\n
From: <sip:10@intern>;tag=35b3bf1b-e9ca-4f70-abe5-50e07d7a8e58\r\n
To: <sip:10@intern>\r\n
Call-ID: ad27897e-c2d0-4aa3-9c61-86a80328b212\r\n
CSeq: 41607 REGISTER\r\n
User-Agent: Gigaset N670 IP PRO/83.V2.65.0+build.8504c90;589EC68147B1\r\n
Contact: <sip:[email protected]:5060>\r\n
Expires: 0\r\n
Authorization: Digest username="10", realm="intern", nonce="fa131fe27d098ff1d33c44d8699e226c", uri="sip:intern", response="24d660b880e962ff7f1e70c100467066", algorithm=MD5\r\n
Content-Length:  0\r\n
\r\n

[SIP-Connection] 2025/10/30 10:08:15,562  Devicetime: 2025/10/30 10:08:15,249 [SIP UDP Transport (192.168.10.101:5060)]: VCM registrar proceeds with REGISTER request

[SIP-Connection] 2025/10/30 10:08:15,562  Devicetime: 2025/10/30 10:08:15,249 [SIP UDP Transport (192.168.10.101:5060)]: Discarding (local socket was 192.168.10.1:5060, Tag 0)

[SIP-Packet] 2025/10/30 10:08:15,562  Devicetime: 2025/10/30 10:08:15,264 [Packet]:
Sending datagram (413 Bytes) from 192.168.10.1:5060 to 192.168.10.101:5060 using UDP (RtgTag 0):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/UDP 192.168.10.101:5060;branch=z9hG4bKPj1b2b5697-c7e3-43c2-b4e4-92070583cc49;received=192.168.10.101;rport=5060\r\n
From: <sip:10@intern>;tag=35b3bf1b-e9ca-4f70-abe5-50e07d7a8e58\r\n
To: <sip:10@intern>;tag=-1721994434-14160333\r\n
Call-ID: ad27897e-c2d0-4aa3-9c61-86a80328b212\r\n
CSeq: 41607 REGISTER\r\n
User-Agent: LANCOM 1803VAW 10.92.0167\r\n
Server: Lancom\r\n
Supported: timer\r\n
Content-Length: 0\r\n
\r\n

[SIP-Connection] 2025/10/30 10:08:15,562  Devicetime: 2025/10/30 10:08:15,265 [SIP UDP Transport (192.168.10.101:5060)]: Discarding (local socket was 192.168.10.1:5060, Tag 0)

[SIP-Connection] 2025/10/30 10:08:15,562  Devicetime: 2025/10/30 10:08:15,266 [SIP UDP Transport (192.168.10.101:5060)]: Discarding (local socket was 192.168.10.1:5060, Tag 0)

[SIP-Connection] 2025/10/30 10:08:16,576  Devicetime: 2025/10/30 10:08:16,355 [SIP UDP Transport (192.168.10.101:5060)]: Processing new inbound SIP message

 

[sonyKatze]

Provisioning

Puh.

Zwar wurde in Gigaset N670 IP Pro und Gigaset N870 IP Pro seit LCOS 10.50 was gemacht. Im Change-Log zu LCOS 10.70 ebenfalls. Auch im Change-Log zu LCOS 10.92. Aber ich bezweifele, dass Lancom das dauerhaft und auch alle Konstellation nachtestet, dass deren beider Software-Abteilungen jemals ordentlich geschweige kontinuierlich miteinander redeten. So liest sich das jedenfalls im Lancom-Forum, als mehr Glück und Zufall aus Projekten heraus als irgendwas gezielt Getestetes.

Mein Tipp daher das mit der Provisioning unbedingt sein lassen. Du kannst das auch ohne Provisioning. Du verlierst nichts durch die fehlende Provisioning. Das ist nur was für System-Integratoren, die jene Systeme lediglich hinstellen wollen und ein Konfigurationsfile unterm Arm haben. Offenbar ist es auch bei Dir ein Problem. Also bitte mal ohne probieren. Willst Du trotzdem unbedingt die Provisioning bitte wirklich im Lancom-Forum weitermachen … wobei dieser Thread besser sein dürften … Weitere Threads findest Du dort unter einer Suche: n670* |N610* |n870*

Hier im Thread kannst Du gerne weiter machen, aber bitte ohne Provisioning. Denn bei der Konstellation kann ich nicht helfen.

manuell im N670IP hinterlegt

Und auch Provisioning aus, also sowohl auf der Gigaset als auch Lancom?

 

[eddy08]

Mir ist noch eine Idee eingefallen, die ich leider nicht sofort getestet habe:
Ich habe die Rufnummer 10 hinterlegt und anschließend im N670IP das Provisioning manuell gestartet.
Daraufhin war die Rufnummer 10 sofort nicht mehr registriert – das bedeutet, dass das Provisioning sie überschrieben hat.

Dabei ist mir bewusst geworden:
Wenn im LANCOM mehrere SIP-User hinterlegt sind, stellt sich die Frage, warum das N670IP von vier Festnetznummern eigentlich nur eine Rufnummer übernimmt. Es könnte ja sein, dass ich mehrere Nummern nutzen möchte.
Der LANCOM stellt die Rufnummer 10 zwar zur Verfügung, doch offenbar kann das N670IP nur die Rufnummern übernehmen, die der LANCOM beim Provisioning explizit übermittelt – und genau das erklärt vermutlich, warum meine SIP-User 10 nie korrekt übernommen wurde.

Ich wusste bisher nicht, dass man das Provisioning im LANCOM deaktivieren darf.
Ich war der Meinung, das müsse dauerhaft aktiviert bleiben – ähnlich wie beispielsweise VPN.
Ein TK-Servicetechniker hat mir jedoch geraten, das Provisioning im LANCOM einfach zu deaktivieren, da meine Geräte bereits vollständig eingerichtet seien.

Und tatsächlich: Das war offenbar die Lösung.
Nach einem Neustart des N670IP bleibt meine Rufnummer 10 im Gigaset weiterhin aktiv.
Ich werde es die nächsten Tagen noch beobachten.