Netcologne SIP-Leitung Re-Registrierung

[hagicgn]

Noch ein Nachtrag:

das ext. Modem hat zwei LAN-Ports. Testweise hatte ich den WAN-Port2 als DSL-2 konfiguriert und die NC-VOIP-Gegenstelle daran gebunden, so dass NC-Internet und NC-VOIP über zwei getrennte Ports das Lancom verlassen. Das vereinfacht das Paket-Capture (auf DSL-2).
Das Vlan-Priomapping 1TR112 habe ich dann deaktiviert.

Erstmal funktioniert es wie vorher. Der Fehlerfall ist identisch. Es kommt dann kein einziges Paket über DSL-2.

Folgendes ist mir noch aufgefallen.
Das ist der Capture eines abgehenden Calls im Fehlerfall (also ein vorangegangener inCall wurde nicht signalisiert).
Hier sehe ich den Eintrag "Proxy Auth required". Im Gutzustand sehe ich diesen Eintrag bei abgehenden Calls nicht:

Code: Alles auswählen

3	0.003987	10.15.20.5	172.17.66.118	SIP/SDP	1310	Request: INVITE sip:01795929515@sip.netcologne.de | 
4	0.009129	172.17.66.118	10.15.20.5	SIP	371	Status: 100 Trying | 
5	0.021108	172.17.66.118	10.15.20.5	SIP	573	Status: 407 Proxy Authentication Required | 
6	0.022122	10.15.20.5	172.17.66.118	SIP	425	Request: ACK sip:01795929515@sip.netcologne.de | 
7	0.022138	10.15.20.5	172.17.66.118	SIP/SDP	1279	Request: INVITE sip:01795929515@sip.netcologne.de | 
8	0.027852	172.17.66.118	10.15.20.5	SIP	371	Status: 100 Trying | 
9	0.618898	172.17.66.118	10.15.20.5	SIP	680	Status: 180 Ringing | 

Nach dem abgehenden Call funktionieren auch wieder inCalls eine zeitlang.

VG
Dirk

[tobiasr]

Ich beobachte das hier weiter sehr gespannt, denn ich würde auch gerne meine Netcologne SIP Leitungen im Lancom nutzen.

[Dr.Einstein]

Habe mal meine Kunden durchgescannt, dabei habe ich einen Netcologne Kunden gefunden, funktioniert alles problemlos, gleiche SIP Server, gleiches Produkt. ReRegister via REGISTER nicht via OPTIONS, auch hohe krumme Expired Timer.

Unterschied: Internes Modem vom Lancom im Einsatz statt externes Draytec.

Code: Alles auswählen

/Setup/Voice-Call-Manager/Lines/SIP-Provider/Line/N_12345678
> ls

Name                       INFO:    N_12345678
Mode                       VALUE:   provider
Domain                     VALUE:   sip.netcologne.de
Rtg-tag                    VALUE:   1
Port                       VALUE:   5060
User-id                    VALUE:   22112345678
Auth-Name                  VALUE:   22112345678
Display-Name               VALUE:   +4922112345678
Secret                     VALUE:   *
Registrar                  VALUE:   sip.netcologne.de
Cln-Prefix                 VALUE:
Number/Name                VALUE:   12345678
Refer-forwarding           VALUE:   No
Local-Port                 VALUE:   0
(Re)Registration           VALUE:   Yes
Registration-interval      VALUE:   480
Line-control-method        VALUE:   Auto
Line-control-interval      VALUE:   60
Trusted                    VALUE:   Yes
Privacy-Method             VALUE:   RFC3325
User-Id-Field              VALUE:   PPI
remove-FROM-usertype       VALUE:   No
Active                     VALUE:   Yes
Trunk-Inc-Cld-In-ToHeader  VALUE:   No
Dtmf-Method                VALUE:   RTP-Event
Transport                  VALUE:   UDP
Fallback                   VALUE:   No
Verify-Server-Certificate  VALUE:   No-Verification
SRTP                       VALUE:   Ignore
SRTP-Ciphers               VALUE:   AES-CM-128,AES-CM-192,AES-CM-256,F8-128
SRTP-Message-Auth-Tags     VALUE:   HMAC-SHA1-32,HMAC-SHA1-80
Strict-Mode                VALUE:   Yes
Allow-Inbound-UDP-From     VALUE:   LAN,VPN,WAN
Overlap-Dialing            VALUE:   No
Loopback-Address           VALUE:
Allow-SIP302-Forwarding    VALUE:   No
Tcp-Timeout                VALUE:   5
Comment                    VALUE:
Telekom-Profile            INFO:    Telekom-Other

Code: Alles auswählen

 /st/voice/line

Index   Name                               Domain                                                            Remote-IP-Address                                          Number                Type              Reg-status        Reg-state            Line-status       Quality           Registered-since     Registered-until     Register-Interval  Transport
========-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1       N_12345678                         sip.netcologne.de                                                 172.17.66.118                                                                    SIP-Provider      Registered        Idle                 Ready             Unspecified       10/24/2024 05:00:31  10/24/2024 08:22:34  1681               UDP

Ansonsten mal die Firmware vom Vigor geprüft? Evtl. hängt es auch mit den Einstellmöglichkeiten bzgl. des VLAN Taggings im Modem zusammen:

https://www.draytek.de/vigor13016516616 ... uters.html

[hagicgn]

Hallo Dr. Einstein,

erstmal danke für deine Arbeit.

Die Fw des Vigors ist aktuell (4.27).
Das Vigor kann zwar generell das Tagging übernehmen,
aber nicht mit unterschiedlichen VlanIDs für Voice und Daten.
Jedenfalls wüsste ich nicht wie.

Ich könnte mir auch vorstellen, dass das Modem etwas verwürfelt, so wie Du schon vermutet hast.

So ganz glauben kann ich es auch nicht, dass NC tatsächlich einen Fehler macht. Das wäre vermutlich nicht nur mir aufgefallen.

VG
Dirk

[MoinMoin]

Moin, moin,

ich habe hier auch seit vielen Jahren einen NC-Anschluß mit VoIP in der Geschmacksrichtung NetAachen. Allerdings auch mit internem Modem. Funktioniert vollkommen problemlos.

(Re)Registration: yes
Registration-Interval; 480
Line-Control-Method: Auto
Line-Control_interval: 60

Die Line-Control Einstellungen sind, soweit ich weiß, für Keep-Alive zusätzlich zur Re-Registrierung. Wenn du da Options einstellst, solltest du also beides sehen, Register und Options.

Wenn die Aufforderung zur Authentifizierung nur im Fehlerfall erfolgt, deutet das darauf hin, daß auf der Providerseite die Registrierung abgelaufen ist.

Ciao, Georg

[hagicgn]

Hallo zusammen,

Line-Control_interval: 60

Laut Lancom-Doku wird dieses Inntervall wieder mit dem vorgeschlagenen vom Sip-Server überschrieben.

Ueberwachungsintervall
Das Intervall der Leitungsüberwachung in Sekunden. Dieser Wert wirkt sich sowohl auf die Leitungsüberwachung mit Register-Request als auch mit Option-Request aus. Das Überwachungsintervall muss mindestens 60 Sekunden betragen und legt fest, nach welcher Zeit die Überwachungsmethode erneut angewendet wird. Wenn die (Re-)Registrierung aktiviert ist, wird das Überwachungsintervall auch als Zeitraum bis zur nächsten Registrierung verwendet.
Anmerkung: Werte kleiner als 60 Sekunden werden automatisch als 60 Sekunden angenommen.
Anmerkung: Falls die Gegenstelle in der Antwort auf einen Option-Request einen anderen Wert für das Überwachungsintervall vorschlägt, so wird dieser akzeptiert und in der Folgezeit verwendet

Was ist denn der Unterschied zwischen den beiden Parametern:

Registration-Interval; 480
Line-Control_interval: 60

VG
Dirk

[MoinMoin]

Moin Dirk,

ich hab so das Gefühl, die Doku ist da nicht auf dem neuesten Stand. Mal nachhören.

Ciao, Georg

[hagicgn]

Hallo zusammen,

ich habe die Sip-Line mit den Einstellungen von Dr. Einstein parametriert.
Das Ergebnis ist das gleiche. Irgendwie kann es ja nur noch am Modem liegen.
Ich wüsste sonst nicht, was ich noch falsch parametriert haben könnte.

VG
Dirk

[MoinMoin]

Moin Dirk,

die Doku ist definitiv falsch. Line-Control ist von der Registrierung unabhängig. Wenn du da auf Options stellst, sollte, zusätzlich zur üblichen Re-Registrierung, nach der eingestellten Zeit jeweils ein Options-Paket geschickt werden. Dumm nur, daß NC dir empfiehlt, Options zu schicken, deren Server die Pakete dann aber ablehnt.

Dennoch könnten die Options helfen, die Verbindung offen zu halten. Wenn die Options immer beantwortet werden, sollte das Modem da nichts blockieren. Zumindest würde ich erwarten, daß dann auch Invites durchkommen.

War der Versuch mit den Options erfolglos, oder hattest du wegen der Fehlermeldung vom Server abgebrochen?

Ciao, Georg

[hagicgn]

Hallo Georg,

gerade habe ich mit NC telefoniert, das brachte aber keine neuen Erkenntnisse.

War der Versuch mit den Options erfolglos, oder hattest du wegen der Fehlermeldung vom Server abgebrochen?

Das führte neben den Serverantworten auch zum gleichen Fehlerbild.

Folgende Versuche habe ich noch gemacht, Paket-Capturing mit dem 1930EF auf der DSL-Schnittlstelle und Filter im Wireshark auf vlan.id==20:
Mitschnitte jeweils ca 2 min:
Leitungsüberwachungsintervall immer: 60s.
Die Methode der Überwachung habe ich variiert:

1) Methode Auto: Kein einziges Paket im Mitschnitt
2) Methode Register: Kein einziges Paket im Mitschnitt
3) Methode Options: 1 Paket "Request Options", dass vom Sip-Server mit "forbidden" beantwortet wurde.

zu 3)

Code: Alles auswählen

406	58.116539	10.15.20.5	172.17.66.118	SIP	393	Request: OPTIONS sip:172.17.66.118 | 
407	58.121790	172.17.66.118	10.15.20.5	SIP	345	Status: 403 Forbidden | 

Für mein Verständnis müsste ich doch in den Mittschnitten immer alle 60s ein Paket sehen, oder gilt das Intervall tatsächlich nur für Sip-Options?

Wenn ich im Lancom ein festes Registrierungsinterval vorgeben könnte, würde das wohl das Problem lösen.
Quasi ein „ignore“ des vorgeschlagenen Timeouts vom Sip-Server.

VG
Dirk

[Dr.Einstein]

Das gilt nur für SIP Options. Das Expired und Reregister ist fest in der SIP RFC niedergeschrieben. Da darf nicht einfach der Client alle 60 Sekunden anfragen, wenn der Server ihm 15-30 Minuten mitgibt. Tut man es trotzdem, werfen die Server in der Regel ein "423 Interval Too Brief" zurück. Der Lancom macht alles richtig.

Man muss bei dir herausfinden, wo das Paket vom Provider (INVITE) verloren geht. Am Lancom kommt es nachweislich nicht mehr an. Der Provider schickts zumindest am Server nachweislich ab. Bist du an einem Anschluss, der Fallback auf SVDSL / VVDSL / VDSL macht, wenn du etwas anderes als Modem ranklemmst? Vllt. hast du noch ein anderes Gerät zur Verfügung um dein Modem auszuschließen.

[hagicgn]

Hallo Dr. Einstein,

danke für deine Erläuterung. Dann habe ich es jetzt verstanden.
Der Anschluss macht wirklich nur G.Fast. Es liegt sogar eine Cat6-Verkabelung bis in den Keller. Eigentlich könnte man direkt PPoE machen.

Momentan habe leider kein weiteres Gerät zum Testen.

Dass ich jetzt intern auch die VlanIDs verwende, die NC extern benötigt, ist ja eigentlich kein Problem.
Ich könnte temporär mal die Gegenstelle NC-Internet deaktivieren, so dass das Modem nur eine VlanID „sieht“.

Wenn es so gar nicht geht, müsste ich den VCM abschalten und die Registrierung direkt über das Gigaset-Telefon machen.
Das wäre interessant, ob es dann funktioniert. Ich werde hier berichten .

VG
Dirk

[hagicgn]

Hallo zusammen,

es gibt ein paar neue Erkenntnisse.
Etwas off-topic möchte zunächst ich diese Erkenntnisse kurz teilen:

Das ext. Modem hatte ich per Reset-Button auf Werkseinstellung gesetzt. Dann im Modem (Bridge-Mode):
* HW-Acceleration Aus -> gleiches Fehlerbild und ca. 800-810 Mbit/s Download
* HW-Acceleration Ein -> gleiches Fehlerbild und ca. 900-910 Mbit/s Download

Ich habe danach den VCM abgelschaltet und eine Route zum Netzwerk des SIP-Servers über die NetcologneVOIP-Gegenstelle eingerichtet.
Die Anmeldedaten dann im Gigaset eingetragen, so dass sich das direkt bei NC registrieren kann. Das Timeout ist dort mit 180s vorbesetzt.

Dann habe ich wieder ein Paket-Capture gemacht und auf VlandID == 20 gefiltert.

Das sind wenige Minuten (<5min):

Code: Alles auswählen

36	3.996058	10.15.20.5	172.17.66.118	SIP	556	Request: REGISTER sip:sip.netcologne.de  (1 binding) | 
37	4.000915	172.17.66.118	10.15.20.5	SIP	449	Status: 200 OK (REGISTER)  (1 binding) | 
85	24.006603	10.15.20.5	172.17.66.118	UDP	50	39367 → 5060 Len=4
194	38.036992	10.15.20.5	172.17.66.118	SIP	555	Request: REGISTER sip:sip.netcologne.de  (1 binding) | 
195	38.044477	172.17.66.118	10.15.20.5	SIP	448	Status: 200 OK (REGISTER)  (1 binding) | 
301	58.047491	10.15.20.5	172.17.66.118	UDP	50	39367 → 5060 Len=4
367	72.088320	10.15.20.5	172.17.66.118	SIP	556	Request: REGISTER sip:sip.netcologne.de  (1 binding) | 
368	72.094084	172.17.66.118	10.15.20.5	SIP	449	Status: 200 OK (REGISTER)  (1 binding) | 
416	92.097690	10.15.20.5	172.17.66.118	UDP	50	39367 → 5060 Len=4
537	106.138118	10.15.20.5	172.17.66.118	SIP	556	Request: REGISTER sip:sip.netcologne.de  (1 binding) | 
538	106.144564	172.17.66.118	10.15.20.5	SIP	449	Status: 200 OK (REGISTER)  (1 binding) | 
637	126.147812	10.15.20.5	172.17.66.118	UDP	50	39367 → 5060 Len=4
705	140.185792	10.15.20.5	172.17.66.118	SIP	555	Request: REGISTER sip:sip.netcologne.de  (1 binding) | 
706	140.190278	172.17.66.118	10.15.20.5	SIP	448	Status: 200 OK (REGISTER)  (1 binding) | 
775	160.186701	10.15.20.5	172.17.66.118	UDP	50	39367 → 5060 Len=4
964	174.226550	10.15.20.5	172.17.66.118	SIP	556	Request: REGISTER sip:sip.netcologne.de  (1 binding) | 
965	174.232342	172.17.66.118	10.15.20.5	SIP	449	Status: 200 OK (REGISTER)  (1 binding) | 
1391	194.238316	10.15.20.5	172.17.66.118	UDP	50	39367 → 5060 Len=4
1531	208.268031	10.15.20.5	172.17.66.118	SIP	555	Request: REGISTER sip:sip.netcologne.de  (1 binding) | 
1532	208.274429	172.17.66.118	10.15.20.5	SIP	448	Status: 200 OK (REGISTER)  (1 binding) | 
1684	228.277425	10.15.20.5	172.17.66.118	UDP	50	39367 → 5060 Len=4
1749	242.316487	10.15.20.5	172.17.66.118	SIP	556	Request: REGISTER sip:sip.netcologne.de  (1 binding) | 
1750	242.321000	172.17.66.118	10.15.20.5	SIP	449	Status: 200 OK (REGISTER)  (1 binding) | 
2255	262.326914	10.15.20.5	172.17.66.118	UDP	50	39367 → 5060 Len=4

Man sieht sofort, dass die Re-Registrierung sehr häufig durchgeführt wird.

Folgend ein Ausschnitt aus der Antwort des SIP-Servers. Interessant ist, dass dem Gigaset ein viel kürzeres Timeout gemeldet wird
(hier 45s statt über 1500s beim Lancom). Das ist auch das Registrierungsintervall des obigen Captures.

Code: Alles auswählen

0150   5f 31 36 38 5f 37 37 5f 31 37 32 0d 0a 43 53 65   _168_77_172..CSe
0160   71 3a 20 34 36 20 52 45 47 49 53 54 45 52 0d 0a   q: 46 REGISTER..
0170   43 6f 6e 74 61 63 74 3a 20 3c 73 69 70 3a 32 32   Contact: <sip:xx
0180   31 35 36 30 39 30 33 38 39 40 31 39 32 2e 31 36   xxxxxxxx@192.16
0190   38 2e 37 37 2e 31 37 32 3a 35 30 36 35 3e 3b 65   8.77.172:5065>;e
01a0   78 70 69 72 65 73 3d 34 35 0d 0a 43 6f 6e 74 65   xpires=45..Conte
01b0   6e 74 2d 4c 65 6e 67 74 68 3a 20 30 0d 0a 0d 0a   nt-Length: 0....

Damit funktioniert nun die Telefonie. Die Invites kommen immer durch.

Tja. Und nun? Fragt der Lancom zu "freundlich" beim Sip-Server an?
(Die Frage habe ich vorhin auch NC gestellt, mal schauen, was die antworten).

VG
Dirk

[hagicgn]

Hallo zusammen,

nach anderthalbwöchigem Ticket-Pingpong mit NC geb ich's auf.
NC ist nicht auf die Frage eingegangen, warum der Gigasetbasistation ein fixes Registrierungstimeout von 45s gemeldet wird, dem Lancom aber ein variierendes von 1500-1750s (beides war in der Sip-Serverantwort zu sehen).
Auch auf den Hinweis, dass bei der Registrierung über den Lancom vielleicht (warum auch immer) von einem Buisiness-Anschluss ausgegangen wird, bei dem möglichwerweise längere Registrierungsintervalle in der ganzen Kette möglich sind, bekam ich keine Antwort.
Man könne Router von Fremdherstellern nicht supporten.

Ich kann damit leben, dass der VCM im Lancom nun abgeschaltet ist und sich das Gigaset direkt anmeldet. Es geht in meinem Fall leider nicht anders.
Interessant wäre, ob es Mitleser gibt, die ebenfalls einen Privat-Anschluss von NC mit VCM verwenden.

Ich danke euch allen für die Untestützung, bei der Fehlersuche habe ich einiges dazugelernt .

VG
Dirk

[tobiasr]

Danke für die Rückmeldung. Ich habe privat eine! Privatkunden-Rufnummer, die ich aber tatsächlich garnicht nutze und auch nicht registriert habe. Ein Kunde hätte ganz gerne eine den NetCologne Geschäftskundenanschluss mit einem LTE-Lancom betrieben. Wenn das nicht geht, bleibt er bei der Fritzbox.