Netcologne SIP-Leitung Re-Registrierung

[MoinMoin]

Moin hagicgn,

kannst du mal von einen erfolglosen Anruf eine Capture auf der WAN-Seite mit gleichzeitigem SIP-Packet und Callmanager Trace machen? Wenn NetCologne recht hat, dann muß das Invite im Ethernet-Capture zu sehen sein (und da mit einen ICMP Port Unreachable abgelehnt werden), nicht aber im SIP-Packet Trace.

Was für einen Internetzugang hast du eigentlich? xDSL kann es ja nicht sein, zumindest nicht direkt am 1930EF.

Ciao, Georg

[hagicgn]

Hallo Georg,

ok, das versuche ich heute Abend.

Was für einen Internetzugang hast du eigentlich? xDSL kann es ja nicht sein, zumindest nicht direkt am 1930EF.

Hier habe ich FTTB über G.Fast bis in die Wohnung. Das ext Modem ist ein Drytek Vigor 166. DL/UL: 1000/200 Mbit/s

Vg
Dirk

[MoinMoin]

Moin hagicgn,

kann es sein, daß beim externen Modem die UDP-Haltezeit (so es da sowas gibt) zu klein ist?

Ciao, Georg

[hagicgn]

Hi Georg,

das Modem ist im Bridge-Mode konfiguriert. Da dürfte es mit UDP bzw. TCP/IP doch gar nicht direkt was zu tun haben, oder liege ich da falsch?

Vg
Dirk

[MoinMoin]

Moin hagicgn,

so sollte es sein. Warten wir den Trace ab.

Ciao, Georg

[Dr.Einstein]

Das Erhöhung der UDP Timer im Lancom wird nicht die Lösung bringen. Diese greift nur, wenn ein Gerät hinter dem Lancom Router eine Verbindung ins Internet aufbaut. In deinem Fall baut aber der Call Manager aus dem LCOS direkt die Verbindung zu Netcologne auf. Der Lancom hält, so kein Softwarefehler vorliegt, so lange die Verbindung offen, wie der Expired-Timer vorgibt. Selbst wenn die Verbindung abgelaufen sein sollte, bin ich der Überzeugung, dass das Paket im SIP Packet Trace erscheinen müsste und nicht als ICMP Redirect abgelehnt wird auf ETH-Ebene. Bin gespannt, was dein Trace auf Basis von Moinmoin ergibt.

Ich habe das Gefühl, dass vorgeschaltete Modem verschluckt was auf dem VoIP VLAN. Ich hatte schon einmal einen ähnlichen Fall mit einem Zyxel Modem, wo IPSec Pakete gedroppt wurden von einem Modem, was eigentlich nur L1 (teilweise L2) macht.

Kurz gesagt. Wireshark anwerfen auf der WAN Schnittstelle. Ankommend den Fehlerfall erzeugen. Nach dem Paket SIP Invite suchen. Kein Paket da = kam nie > Netcologne oder Modem. Kommt an, aber nicht im Callmanager > LCOS Bug / Konfigfehler.

[hagicgn]

Hallo zusammen,

Ich habe das Gefühl, dass vorgeschaltete Modem verschluckt was auf dem VoIP VLAN. Ich hatte schon einmal einen ähnlichen Fall mit einem Zyxel Modem, wo IPSec Pakete gedroppt wurden von einem Modem, was eigentlich nur L1 (teilweise L2) macht.

Das gesamte VLAN-Tagging für Netcologne (Internet und VOIP) macht der Lancom. Im Modem ist wirklich nichts eingestellt.
Vor Netcologne (kurz NC) hat mit gleicher HW-Konfig das VOIP mit SIPAGTE drei Jahre funktioniert. Sipgate ging aber natürlich direkt über die
NC-Internetgegenstelle. Für NC-VOIP muss man eine eigene anlegen, da andere VLAN-ID.

Auf dem Ethernettrace (Ethernet-Data) habe ich im Fehlerfall kein Invite gesehen. Gefiltert habe ich auf die IP des NC-SIP-Servers (172.17.66.118).
Entsprechend kam beim Call-Manager und SIP auch nichts an.

Registrieungsanfrage LC 1930EF:

Code: Alles auswählen

[Ethernet-Data] 2024/10/22 19:27:40,921  Devicetime: 2024/10/22 19:27:40,899
Sent 809 byte Ethernet packet via DSL-1:
IPv4 Hdr Checksum   : inserted by hardware
IP Proto Checksum   : inserted by hardware
-->IEEE 802.3 Header
Dest                : 54:e0:32:c7:87:c2
Source              : 06:a0:57:9c:46:8e (LANCOM (local-1) 9c:46:8e)
Type                : 802.1p/q VLAN (0x8100)
-->802.1p/q VLAN Header
VLAN Id             : 20
VLAN Prio           : 6
VLAN CFI            : 0
Type                : IPv4 (0x0800)
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0xc0) (Precedence 6) / (DSCP CS6)
Total length        : 791
ID                  : 23329
Fragment            : Offset 0
TTL                 : 64
Protocol            : UDP
Checksum            : 65535 (updated by hardware)
Src Address         : 10.15.56.245
Dest Address        : 172.17.66.118
-->UDP Header
Src Port            : 15392
Dest Port           : SIP
Length              : 771
Checksum            : 0 (updated by hardware)
-->SIP Packet
Header              : REGISTER sip:sip.netcologne.de SIP/2.0
                      Via: SIP/2.0/UDP 10.15.56.245:15392;branch=z9hG4bK-f51c0215-08a32d4c;rport
                      From: <sip:XXXXXXXXXXX@sip.netcologne.de>;tag=1662042106-1932835962
                      To: <sip:XXXXXXXXXXX@sip.netcologne.de>
                      Call-ID: XXXXXXXXXXX-sip.netcologne.de-78fcbf35@00a0579c468e
                      CSeq: 235 REGISTER
                      Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS, PRACK, UPDATE, SUBSCRIBE, INFO
                      Max-Forwards: 70
                      Contact: <sip:XXXXXXXXXXX@10.15.56.245:15392;transport=UDP>
                      Expires: 480
                      User-Agent: LANCOM 1930EF 10.80.0833
                      Authorization: Digest username="XXXXXXXXXXX", realm="sip.netcologne.de", algorithm=MD5, uri="sip:sip.netcologne.de", nonce="Zxf7RWcXoW1s3na8yvuwn4Ix8agntV0r", response="9b6f1a2c6a4103e8d5b9736cc9a70308"
                      Content-Length: 0

Antwort:

Code: Alles auswählen

[Ethernet-Data] 2024/10/22 19:27:40,936  Devicetime: 2024/10/22 19:27:40,920
Received 536 byte Ethernet packet via DSL-1:
Physical Port       : WAN-1
IPv4 Hdr Checksum   : OK
IP Proto Checksum   : OK
-->IEEE 802.3 Header
Dest                : 06:a0:57:9c:46:8e (LANCOM (local-1) 9c:46:8e)
Source              : 54:e0:32:c7:87:c2
Type                : 802.1p/q VLAN (0x8100)
-->802.1p/q VLAN Header
VLAN Id             : 20
VLAN Prio           : 6
VLAN CFI            : 0
Type                : IPv4 (0x0800)
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length        : 518
ID                  : 0
Fragment            : Offset 0
TTL                 : 126
Protocol            : UDP
Checksum            : 2396 (OK)
Src Address         : 172.17.66.118
Dest Address        : 10.15.56.245
-->UDP Header
Src Port            : SIP
Dest Port           : 15392
Length              : 498
Checksum            : 61094 (OK)
-->SIP Packet
Header              : SIP/2.0 200 OK
                      Via: SIP/2.0/UDP 10.15.56.245:15392;received=10.15.56.245;branch=z9hG4bK-f51c0215-08a32d4c;rport=15392
                      From: <sip:XXXXXXXXXXX@sip.netcologne.de>;tag=1662042106-1932835962
                      To: <sip:XXXXXXXXXXX@sip.netcologne.de>;tag=378f79ec882e20b678dbf237e214d889.15770000
                      Call-ID: XXXXXXXXXXX-sip.netcologne.de-78fcbf35@00a0579c468e
                      CSeq: 235 REGISTER
                      Contact: <sip:XXXXXXXXXXX@10.15.56.245:15392;transport=UDP>;expires=1716
                      Server: Sipwise NGCP Proxy mr11.5.1
                      Content-Length: 0

Netcologne hat mir noch folgendes mitgegegen. Das war gestern ein Anrufversuch im Fehlerfall:

Code: Alles auswählen

100trying. 2024-10-21 20:08:00 +0200 : 172.17.66.118:5060 -> 10.15.56.245:15392 INVITE sip:XXXXXXXXXXX@10.15.56.245:15392;transport=UDP SIP/2.0 Via: SIP/2.0/UDP 172.17.66.118:5060;branch=z9hG4bKg8l56a2068rmtob01i30.1
From: XXXXXXXXXXX@sip.netcologne.de:5060>;tag=71FE8BDF-671698800008BECC-679EA6C0 To: XXXXXXXXXXX@sip.netcologne.de:15392> CSeq: 339 INVITE Call-ID: 3e1ce89ed35c51956371322cab88ff16@87.136.4.17_pbx-1 Max-Forwards: 68 Supported: path,replaces,199 Allow: UPDATE, CANCEL, NOTIFY, MESSAGE, PRACK, REFER, INVITE, BYE, ACK, OPTIONS P-Early-Media: supported Content-Type: application/sdp Content-Length: 288
Contact: ngcp-lb@172.17.66.118:5060;ngcpct=7369703a3137322e31372e36342e3135333a35303830;transport=udp> 

Beim Lancom kam nichts an.

Ich habe auf dem WAN-1 drei Gegenstellen konfiguriert. NC-Internet, NC-VOIP und eine IPOE-Verbindung zur Konfigseite des Modems.
Vielleicht kommt das was durcheinander. Wie gesagt, das Modem taggt nichts.

Müsste ich irgendwelche Keep-Alive Pakete sehen?

VG
Dirk

PS: Wie mache ich denn mit dem Wireshark ein Capture auf der WAN-Seite? Ich denke, den WAN-2 als Monitor-Port konfigurieren.
Aber das Windows-Laptop ist doch dann nach max. 250ms von Schädlingen befallen, oder sehe ich das zu eng?

[5624]

PS: Wie mache ich denn mit dem Wireshark ein Capture auf der WAN-Seite? Ich denke, den WAN-2 als Monitor-Port konfigurieren.
Aber das Windows-Laptop ist doch dann nach max. 250ms von Schädlingen befallen, oder sehe ich das zu eng?

Du gehst ins WEBconfig des Routers, auf Packetcapture, wählst deine Schnittstelle aus und startest dieses dann. Du bekommst dann eine PCAP-Datei, die du mit Wireshark öffnen kannst. Dein Rechner ist dabei nie direkt im Internet.

Desweiteren ist Windows seit sehr sehr sehr langer Zeit nicht mehr so anfällig für Schadsoftware. Dass ist etwa seit Windows 7 vorbei. Da sind Linux-Systeme heute anfälliger, weil die meisten bis heute der Meinung sind, dass Linux "virensicher" sei und daher einfach unsichere Systeme ins Netz stellen.

[hagicgn]

Du gehst ins WEBconfig des Routers, auf Packetcapture, wählst deine Schnittstelle aus und startest dieses dann. Du bekommst dann eine PCAP-Datei, die du mit Wireshark öffnen kannst. Dein Rechner ist dabei nie direkt im Internet.

Oh man. Danke. Das hatte ich total verdrängt.

So, der Capture liefert im Fehlerfall kein Invite. Genauer gesagt, während des Captures gar keine Kommunikation mit dem NC-SIP-Server (172.17.66.118).

Im funktionierenden Status sehe ich im Capture das Invite vom SIP-Server (hier Paketheader).

Code: Alles auswählen

153	4.146723	172.17.66.118	10.15.56.245	SIP/SDP	1003	Request: INVITE sip:XXXXXXXXXX@10.15.56.245:15416;transport=UDP | 
154	4.150328	10.15.56.245	172.17.66.118	SIP	493	Status: 100 Trying | 
155	4.231010	10.15.56.245	172.17.66.118	SIP	644	Status: 180 Ringing | 
277	9.604516	172.17.66.118	10.15.56.245	SIP	487	Request: CANCEL sip:XXXXXXXXXX@10.15.56.245:15416;transport=UDP | 
278	9.605180	10.15.56.245	172.17.66.118	SIP	461	Status: 200 OK (CANCEL) | 
279	9.605197	10.15.56.245	172.17.66.118	SIP	594	Status: 487 Request Terminated | 
285	9.610503	172.17.66.118	10.15.56.245	SIP	457	Request: ACK sip:XXXXXXXXXX@10.15.56.245:15416;transport=UDP | 

Das sind die Header von einem erfolgreichen Register:

Code: Alles auswählen

1374	32.022880	10.15.56.245	172.17.66.118	SIP	811	Request: REGISTER sip:sip.netcologne.de  (1 binding) | 
1375	32.043800	172.17.66.118	10.15.56.245	SIP	538	Status: 200 OK (REGISTER)  (1 binding) | 

-> Also ist es wohl entweder Netcologne oder das Modem.

Für mich zum Verständnis: Wie hält der Call-Manager die Verbindung offen? Einfach, indem er bis zum Timeout auf dem Port eingehende Pakete akzeptiert? Oder müsste ich Keep-Alive-Pakete sehen?

Danke für eure Unterstützung .

Dirk

[Dr.Einstein]

Auf dem Ethernettrace (Ethernet-Data) habe ich im Fehlerfall kein Invite gesehen. Gefiltert habe ich auf die IP des NC-SIP-Servers (172.17.66.118).
Entsprechend kam beim Call-Manager und SIP auch nichts an.

hast du auch mal auf SIP 5060 oder ICMP gefiltert?

[hagicgn]

hast du auch mal auf SIP 5060 oder ICMP gefiltert?

Ok, das mache ich dann heute Abend.
Ich hatte gedachacht, eventuelle ICMP Pakete
würde ich dann auch mit der Absendeadresse des SIP-Servers sehen.

Netcologne hat schon geantwortet:

Bitte Voice-Call-Manager (kein SIP-ALG, ...) abschalten und SIP-OPTIONS senden. Gleiches Thema wie hier mit Lancom: https://www.pascom.net/forum/t/deutschl ... ren/3026/5 Das eingehende INVITE kann fragmentiert ankommen, daher ist dies ggf. nicht unmittelbar sichtbar.

Ich schaue mir das heute Abend an.

VG
Dirk

[Dr.Einstein]

würde ich dann auch mit der Absendeadresse des SIP-Servers sehen.

War eher die Theorie, dass es von einer anderen IP kommt

[tobiasr]

Ich verstehe die Antwort von Netcologne nur nicht. Du registrierst doch explizit über den VCM und sie empfehlen den VCM abzuschalten.

[MoinMoin]

Moin, moin,

die Antwort von NC bezieht sich offenbar auf einen Fall, bei dem der VCM nicht zum Einsatz kam, sondern die Registrierung von einem Gerät hinter dem LANCOM vorgenommen wurde. Ist hier allso nicht anwendbar.

Kann die Filterung anhand des VLAN erfolgen? Dann sieht man allen Traffic auf der Voice-Verbindung.

Ciao, Georg

[hagicgn]

Hallo zusammen,

was NC möchte, verstehe ich auch nicht so ganz. Das SIP-ALG war auch deaktiviert.

Kann die Filterung anhand des VLAN erfolgen? Dann sieht man allen Traffic auf der Voice-Verbindung.

Ja, es kommt nichts im Fehlerfall.

Das ist ein Paket-Capture von DSL-1 im Lancom und Filter auf VlanID == 20 (Telefonienetz von NC).
Der Fehlerfall taucht nicht auf, danach habe ich einen Anruf von innen nach außen getätigt (s. Capture) . Funktionierte. Der direkt im Anschluss folgende eingehende Anruf wurde dann auch signalisiert (nicht im Capture):

Code: Alles auswählen

567	37.530719	10.15.56.245	172.17.66.118	SIP/SDP	1317	Request: INVITE sip:XXXXXXXX@sip.netcologne.de | 
568	37.534484	172.17.66.118	10.15.56.245	SIP	375	Status: 100 Trying | 
569	37.546491	172.17.66.118	10.15.56.245	SIP	577	Status: 407 Proxy Authentication Required | 
570	37.547552	10.15.56.245	172.17.66.118	SIP	427	Request: ACK sip:XXXXXXXX@sip.netcologne.de | 
571	37.547568	10.15.56.245	172.17.66.118	SIP/SDP	1286	Request: INVITE sip:XXXXXXXX@sip.netcologne.de | 
572	37.551004	172.17.66.118	10.15.56.245	SIP	375	Status: 100 Trying | 
579	38.703748	172.17.66.118	10.15.56.245	SIP	684	Status: 180 Ringing | 

NC schreibt, sie möchten SIP-Options haben. Das ist eine andere Re-Registrierungsmethode, oder?
Diese Einstellung: VCM/Line/Sip-Provider/<Line>/Leitungsüberwachung -> Options?
Das hatte ich probiert, klappt aber auch nicht.

Und im Capture mit einer Re-Registrierung über Options sieht das so aus:

Code: Alles auswählen

3903	1110.305453	10.15.56.245	172.17.66.118	SIP	398	Request: OPTIONS sip:172.17.66.118 | 
3904	1110.310829	172.17.66.118	10.15.56.245	SIP	350	Status: 403 Forbidden | 
4274	1210.311470	10.15.56.245	172.17.66.118	SIP	399	Request: OPTIONS sip:172.17.66.118 | 
4275	1210.317737	172.17.66.118	10.15.56.245	SIP	351	Status: 403 Forbidden | 

VG
Dirk

Edit: SIP-Options-Capture eingefügt