AW: VoIP: Cisco SPA2101: Keine Registrierung

[#1]

Hallo allerseits,

seit dem dem 05.04.22 registriert sich mein analoger Telefonadapter SPA2021 nicht mehr. Die Fehlermeldung ist: Registraion failed.

Bei der Konfiguration von Router/ATA habe ich nichts geändert, Nachfrage bei der Telekom-Hotline nach Veränderung um den 05.04.22 hat nichts ergeben. Anmeldung erfolgt per SRV-Record, als DNS sind 8.8.8.8 und 1.1.1.1 eingetragen.

Hier gings noch (Auzug aus dem log):

Mar 22 06:37:02 spa2102-2 Addr Change(0) d9001c21:5060->d9001502:5060
Mar 22 06:37:05 spa2102-2 last message buffered 3 times
Mar 22 09:30:29 spa2102-2 RTPMAP 101 --> 136
Mar 22 09:30:29 spa2102-2 RTPMAP 101 --> 136
Mar 22 09:30:29 spa2102-2 [0:0]AUD ALLOC CALL (port=16602)
Mar 22 09:30:29 spa2102-2 [0:0]RTP Rx Up
Mar 22 09:30:32 spa2102-2 CID:OnHookTx Pol
Mar 22 09:30:32 spa2102-2 DTMF/FSK
Mar 22 09:30:32 spa2102-2 CID:DONE
Mar 22 09:30:53 spa2102-2 CC:Connected
Mar 22 09:30:53 spa2102-2 [0:0]ENC INIT 8
Mar 22 09:30:53 spa2102-2 [0:0]RTP Tx Up (pt=8->d90005b4:22948)
Mar 22 09:30:53 spa2102-2 [0:0]RTCP Tx Up
Mar 22 09:30:53 spa2102-2 [0:0]RTP Rx 1st PKT @16602(2)
Mar 22 09:30:54 spa2102-2 [0:0]DEC INIT 8
Mar 22 09:31:10 spa2102-2 [0:0]LAT-- 7(2)
Mar 22 09:31:18 spa2102-2 [0:0]LAT-- 6(2)
Mar 22 09:31:26 spa2102-2 [0:0]LAT-- 5(2)
Mar 22 09:31:34 spa2102-2 [0:0]LAT-- 4(2)
Mar 22 09:31:42 spa2102-2 [0:0]LAT-- 3(2)
Mar 22 09:32:18 spa2102-2 [0:0]LAT-- 3(2)
Mar 22 09:32:34 spa2102-2 [0:0]LAT++ 4(2)
Mar 22 09:32:51 spa2102-2 CC:Ended
Mar 22 09:32:51 spa2102-2 [0:0]AUD Rel Call
Mar 22 09:33:23 spa2102-2 Terminated 287144
Mar 22 09:33:23 spa2102-2 Terminated
Mar 22 09:33:24 spa2102-2 CC:Clean Up
Mar 22 09:33:24 spa2102-2 OBJ POOL STAT ---
Mar 22 09:33:24 spa2102-2 OP:RTPRXB = 96 ( 96 192)
Mar 22 09:33:24 spa2102-2 OP:RTPREB = 40 ( 40 48)
Mar 22 09:33:24 spa2102-2 OP:RTPTXB = 64 ( 64 108)
Mar 22 09:33:24 spa2102-2 OP:TIMEOU = 102 (120 52)
Mar 22 09:33:24 spa2102-2 OP:SIPCOR = 0 ( 1 28)
Mar 22 09:33:25 spa2102-2 OP:SIPCTS = 30 ( 32 588)
Mar 22 09:33:25 spa2102-2 OP:SIPSTS = 32 ( 32 6064)
Mar 22 09:33:25 spa2102-2 OP:SIPAUS = 0 ( 8 588)
Mar 22 09:33:25 spa2102-2 OP:SIPDLG = 10 ( 10 148)
Mar 22 09:33:25 spa2102-2 OP:SIPSES = 12 ( 12 8456)
Mar 22 09:33:25 spa2102-2 OP:SIPREG = 0 ( 4 468)
Mar 22 09:33:25 spa2102-2 OP:SIPLIN = 0 ( 2 140)
Mar 22 09:33:25 spa2102-2 OP:SUBDLG = 2 ( 2 6444)
Mar 22 09:33:25 spa2102-2 OP:STUNTS = 16 ( 16 68)

Hier geht' s nicht mehr:

Apr 5 21:04:44 spa2102-2 RSE:GetServerAddrErr(tel.t-online.de,1)=-101
Apr 5 21:04:44 spa2102-2 Addr Change(0) d9001c21:5060->0:5060
Apr 5 21:04:44 spa2102-2 last message buffered 1 times
Apr 5 21:04:44 spa2102-2 TP:?Tx->0
Apr 5 21:04:44 spa2102-2 [0]SIP:ICMP Error 0 (0:5060, 3)
Apr 5 21:04:44 spa2102-2 RSE:GetServerAddrErr(tel.t-online.de,1)=-101
Apr 5 21:04:44 spa2102-2 Addr Change(0) d9001c21:5060->0:5060
Apr 5 21:04:44 spa2102-2 last message buffered 1 times
Apr 5 21:04:44 spa2102-2 TP:?Tx->0
Apr 5 21:04:44 spa2102-2 [0]SIP:ICMP Error 0 (0:5060, 3)

Was kann ich machen? Hat jemand eine Idee? Danke für die Unterstützung,

Wolfgang

[#2]

@oliaros 

Erstmal DNS, damit man sieht, ob die DNS-SRV Auflösung funktioniert.

Dann SIP-Pakete.

[#3]

Hmm, ich bekomme weder mit

fli4l 3.6.2 # tcpdump -i eth1 -vv udp port 53 or tcp port 53
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes

noch mit

fli4l 3.6.2 # tcpdump -i eth1 -n -s 0 port 5060 -vv
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes

einen output. Wo ist der Denkfehler?

Gruss, oliaros

[#4]

@oliaros 

Ich würde mit tcpdump alles mitschneiden und in einer Datei speichern (z.B. tcpdump -i ppp0 -s 0 -w /tmp/tcpdump.pcap).

Diese Datei dann in WireShark laden und dort analysieren.

[#5]

Hallo,

ich habs versucht:

Frame 268: 771 bytes on wire (6168 bits), 771 bytes captured (6168 bits)
Encapsulation type: Linux cooked-mode capture v1 (25)
Arrival Time: Apr 11, 2022 19:11:44.194407000 Mitteleurop�ische Sommerzeit
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1649697104.194407000 seconds
[Time delta from previous captured frame: 0.015211000 seconds]
[Time delta from previous displayed frame: 0.015211000 seconds]
[Time since reference or first frame: 1.000869000 seconds]
Frame Number: 268
Frame Length: 771 bytes (6168 bits)
Capture Length: 771 bytes (6168 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: sll:ethertype:ip:udp:sip]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Linux cooked capture v1
Packet type: Unicast to us (0)
Link-layer address type: PPP (512)
Link-layer address length: 0
Unused: 0000000000000000
Protocol: IPv4 (0x0800)
Internet Protocol Version 4, Src: 217.0.147.197, Dst: 91.61.xx.xxx
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0xb8 (DSCP: EF PHB, ECN: Not-ECT)
1011 10.. = Differentiated Services Codepoint: Expedited Forwarding (46)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 755
Identification: 0x6337 (25399)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment Offset: 0
Time to Live: 60
Protocol: UDP (17)
Header Checksum: 0x2f1e [validation disabled]
[Header checksum status: Unverified]
Source Address: 217.0.147.197
Destination Address: 91.61.xx.xxx
User Datagram Protocol, Src Port: 5060, Dst Port: 5062
Source Port: 5060
Destination Port: 5062
Length: 735
Checksum: 0xb41d [unverified]
[Checksum Status: Unverified]
[Stream index: 1]
[Timestamps]
[Time since first frame: 0.017385000 seconds]
[Time since previous frame: 0.017385000 seconds]
UDP payload (727 bytes)
Session Initiation Protocol (401)
Status-Line: SIP/2.0 401 Unauthorized
Status-Code: 401
[Resent Packet: False]
[Request Frame: 266]
[Response Time (ms): 17]
Message Header
Via: SIP/2.0/UDP 192.168.0.122:5062;rport=5062;received=91.61.xx.xxx;branch=z9hG4bK-db6e47a6
Transport: UDP
Sent-by Address: 192.168.0.122
Sent-by port: 5062
RPort: 5062
Received: 91.61.xx.xxx
Branch: z9hG4bK-db6e47a6
WWW-Authenticate: Digest algorithm=MD5,realm="tel.t-

online.de",nonce="4e42414e4241cdbfd6469c31bf1afe13aaf07926e162",qop="auth"
Authentication Scheme: Digest
Algorithm: MD5
Realm: "tel.t-online.de"
Nonce Value: "4e42414e4241cdbfd6469c31bf1afe13aaf07926e162"
QOP: "auth"
From: "+49xxxxyyyyyy" <sip:+49xxxxyyyyyy@tel.t-online.de>;tag=5f4ccf4076cae4co0
SIP from display info: "+49xxxxyyyyyy"
SIP from address: sip:+49xxxxyyyyyy@tel.t-online.de
SIP from address User Part: +49xxxxyyyyyy
E.164 number (MSISDN): 49531342864
Country Code: Germany (Federal Republic of) (49)
SIP from address Host Part: tel.t-online.de
SIP from tag: 5f4ccf4076cae4co0
To: "+49xxxxyyyyyy" <sip:+49xxxxyyyyyy@tel.t-online.de>;tag=mavodi-0-4b-10-1-ffffffc7-83e-ffffffffffffffff-

8f030000-623b7ac8-_02A1BFB9634D-271f-423b9700-37f91b-62546138-b8488
SIP to display info: "+49xxxxyyyyyy"
SIP to address: sip:+49xxxxyyyyyy@tel.t-online.de
SIP to address User Part: +49xxxxyyyyyy
E.164 number (MSISDN): 49xxxxyyyyyy
Country Code: Germany (Federal Republic of) (49)
SIP to address Host Part: tel.t-online.de
SIP to tag: mavodi-0-4b-10-1-ffffffc7-83e-ffffffffffffffff-8f030000-623b7ac8-_02A1BFB9634D-271f-

423b9700-37f91b-62546138-b8488
Call-ID: e8e2e1ef-2dcaa1a2@192.168.0.122
[Generated Call-ID: e8e2e1ef-2dcaa1a2@192.168.0.122]
CSeq: 17035 REGISTER
Sequence Number: 17035
Method: REGISTER
Reason: SIP;cause=401;text="CC_SIP_UNAUTHORIZED_401"
Reason protocols: SIP
Cause: Unauthorized (401)
Text: CC_SIP_UNAUTHORIZED_401
Session-ID: 00000000000000000000000000000000; remote=8ca4972af9a66b0febbfca23afba6fb7
local-uuid: 00000000-0000-0000-0000-000000000000
remote-uuid: 8ca4972a-f9a6-6b0f-ebbf-ca23afba6fb7
Content-Length: 0

Allerdings sehe ich nur  "Reason: SIP;cause=401;text="CC_SIP_UNAUTHORIZED_401" und nicht den Grund. Vielleicht siehst du mehr?

Gruss, oliaros

[#6]

@oliaros 

401 Unauthorized ist schon ok, dann folgt normalerweise ein Register mit den Anmeldedaten.

Kannst du die pcap-Datei in eine Cloud kopieren und mir den Link dazu per PN senden, natürlich nur wenn du möchtest.

[#7]

@oliaros  schrieb:
Via: SIP/2.0/UDP 192.168.0.122:5062;rport=5062;received=91.61.xx.xxx;branch=z9hG4bK-db6e47a6
Transport: UDP
Sent-by Address: 192.168.0.122
Sent-by port: 5062
RPort: 5062

Wieso steht beim REGISTER als Quellport 5062?

Was löst "nslookup" bei dem Proxy "received=91.61.xx.xxx" auf?

[#8]

@OlliD.IRQ8  schrieb:
Wieso steht beim REGISTER als Quellport 5062?

Warum nicht?

[#9]

@OlliD.IRQ8  schrieb:

Wieso steht beim REGISTER als Quellport 5062?

Was löst "nslookup" bei dem Proxy "received=91.61.xx.xxx" auf?

Im lokalen Netz sind sich zwei SPA2102 (192.168.0.121 und 192.168.0.122) mit jeweils zwei Lines, der 1.  hat UDP 5060 und 5061, der 2. 5062 und 5063.

Die 91.61.xx.xxx war meine externe IP Adresse zu diesem Zeitpunkt.

Gruss, Oliaros

[#10]

@oliaros Dein Cross-Post im IP-Phone-Forum enthält eine Antwort …

Laut dem Post dort, ist die Ursache ein zu langes „Tag“ im SIP-Header „To“. Wie dort bereits beschrieben, könntest Du einen Telekom Speedport (am Ende ist eine Liste der geeigneten Modelle) bzw. eine Digitalisierungsbox dazwischen schalten. Dann buchst Du das Tisch-Telefon daran und nicht direkt bei der Telekom Deutschland an. Heul.