Telefonabrüche verweigerte Rufannahme von der Gegenstelle

[Josef L]

Bei einem Kunden tritt verstärkt diese Probleme auf. ist eine 3CX Pro Debian lokal betrieben (seit über 2 Jahren) mit einem Vodafone Einzelrufnummernanschluss.

Es gibt Rufnummern, da kann man das Problem fast immer hinstellen, einmal kam ich kurz durch dann war das Gespräch abgebrochen, ich hatte erst die Vermutung das der gerufeneTeilnehmer vielleicht die Rufnummer auf sein Handy blockiert hat.

Ich konnte ihn ohne Probleme über meinen Vodafoneanschluss erreichen, er hat sein Handy überprüft und dort war alles in Ordnung, darauf hin habe ich erreichen können, aber der Gespräch war sofort abgebrochen.

Im Bereich des SIP Checker abe ich einen ausgehende Anruf auf diese Nummer anschließend generiert:



Kann der Sipcode durch die Fritzbox erzeugt werden? Wenn ich mein Handy anrufe ist alles ok



Ich habe auch einen Dump erzeugt:



rame 5650: Packet, 964 bytes on wire (7712 bits), 964 bytes captured (7712 bits)
Linux cooked capture v2
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 944
Identification: 0xca2f (51759)
010. .... = Flags: 0x2, Don't fragment
...0 0000 0000 0000 = Fragment Offset: 0
Time to Live: 64
Protocol: UDP (17)
Header Checksum: 0x6f0b [validation disabled]
[Header checksum status: Unverified]
Source Address: 127.0.0.1
Destination Address: 127.0.0.1
[Stream index: 1]
User Datagram Protocol, Src Port: 5063, Dst Port: 5062
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:[email protected]:5062 SIP/2.0
Method: INVITE
Request-URI: sip:[email protected]:5062
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP 127.0.0.1:5063;branch=z9hG4bK-524287-1---ec6acb2f97be6e31;rport
Max-Forwards: 70
Contact: <sip:[email protected]:5063>
To: <sip:[email protected]:5062>
From: " , Josef"<sip:[email protected]>;tag=5da0aa2d
Call-ID: T7Zt_lbO18V-izppuBkC2g..
[Generated Call-ID: T7Zt_lbO18V-izppuBkC2g..]
CSeq: 1 INVITE
Subject:
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE
Content-Type: application/sdp
Supported: replaces
User-Agent: 3CX WebRTC proxy
Content-Length: 382
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): 3cxWebRTC 4375165 18446744071566594418 IN IP4 127.0.0.1
Session Name (s): 176.95.226.18:[10510,]
Connection Information (c): IN IP4 127.0.0.1
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 8522 RTP/AVP 0 8 9 109 101
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:9 G722/8000/1
Media Attribute (a): rtpmap:109 opus/48000/2
Media Attribute (a): fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15
Media Attribute (a): ptime:20
Media Attribute (a): sendrecv
[Generated Call-ID: T7Zt_lbO18V-izppuBkC2g..]
[Generated Call-ID: hJFM4L5ypHY7uAS6aInZOQ..]


Frame 5888: Packet, 1032 bytes on wire (8256 bits), 1032 bytes captured (8256 bits)
Encapsulation type: Linux cooked-mode capture v2 (210)
Arrival Time: Aug 20, 2026 11:06:46.158080000 Mitteleuropäische Sommerzeit
UTC Arrival Time: Aug 20, 2026 09:06:46.158080000 UTC
Epoch Arrival Time: 1787216806.158080000
[Time shift for this packet: 0.000000000 seconds]
[Time delta from previous captured frame: 45.000 microseconds]
[Time delta from previous displayed frame: 45.000 microseconds]
[Time since reference or first frame: 28.981567000 seconds]
Frame Number: 5888
Frame Length: 1032 bytes (8256 bits)
Capture Length: 1032 bytes (8256 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: sll:ethertype:ip:udp:sip:sdp]
Character encoding: ASCII (0)
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Linux cooked capture v2
Protocol: IPv4 (0x0800)
Reserved: 0000
Interface index: 2
Link-layer address type: Ethernet (1)
Packet type: Sent by us (4)
Link-layer address length: 6
Source: GigaByteTech_01:3a:7e (74:56:3c:01:3a:7e)
Unused: 0000
Internet Protocol Version 4, Src: 192.168.4.252, Dst: 139.7.X.X.X
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 1012
Identification: 0xd82f (55343)
010. .... = Flags: 0x2, Don't fragment
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
...0 0000 0000 0000 = Fragment Offset: 0
Time to Live: 64
Protocol: UDP (17)
Header Checksum: 0xc478 [validation disabled]
[Header checksum status: Unverified]
Source Address: 192.168.4.252
Destination Address: 139.7.X.X.X
[Stream index: 12]
User Datagram Protocol, Src Port: 5062, Dst Port: 5060
Source Port: 5062
Destination Port: 5060
Length: 992
Checksum: 0xc91e [unverified]
[Checksum Status: Unverified]
[Stream index: 17]
[Stream Packet Number: 9]
[Timestamps]
[Time since first frame: 26.765856000 seconds]
[Time since previous frame: 13.065881000 seconds]
UDP payload (984 bytes)
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:[email protected]:5060 SIP/2.0
Method: INVITE
Request-URI: sip:[email protected]:5060
Request-URI User Part: +491726XXXX
E.164 number (MSISDN): 491726XXXX
Country Code: Germany (Federal Republic of) (49)
Request-URI Host Part: 05171.sip.arcor.de
Request-URI Host Port: 5060
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP 192.168.4.252:5062;branch=z9hG4bK-524287-1---bcb20e10f4cd013b;rport
Transport: UDP
Sent-by Address: 192.168.4.252
Sent-by port: 5062
Branch: z9hG4bK-524287-1---bcb20e10f4cd013b
RPort: rport
Max-Forwards: 70
Contact: <sip:[email protected],X,X:5062>
Contact URI: sip:[email protected],X,X:5062
Contact URI User Part: 05171XXXX
Contact URI Host Part: 176.9X,X,X
Contact URI Host Port: 5062
To: <sip:[email protected]:5060>
SIP to address: sip:[email protected]:5060
SIP to address User Part: +491726XXXX
E.164 number (MSISDN): 491726XXXX
Country Code: Germany (Federal Republic of) (49)
SIP to address Host Part: 05171.sip.arcor.de
SIP to address Host Port: 5060
From: "05171XXXX"<sip:[email protected]:5060>;tag=db041828
SIP from display info: "05171XXXX"
SIP from address: sip:[email protected]:5060
SIP from address User Part: 05171XXXX
SIP from address Host Part: 05171.sip.arcor.de
SIP from address Host Port: 5060
SIP from tag: db041828
Call-ID: JzBxCjJ33TvobE9YxXZJDQ..
[Generated Call-ID: JzBxCjJ33TvobE9YxXZJDQ..]
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE
Content-Type: application/sdp
Supported: replaces, timer
User-Agent: 3CXPhoneSystem 20.0.9.995 (995)
Remote-Party-ID: "05171XXXX"<sip:[email protected]:5060>;party=calling
[Expert Info (Note/Undecoded): Unrecognised SIP header (remote-party-id)]
[Unrecognised SIP header (remote-party-id)]
[Severity level: Note]
[Group: Undecoded]
Content-Length: 290
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): 3cxPS 13550676177059840 13050143423070209 IN IP4 176.9X,X,X
Owner Username: 3cxPS
Session ID: 13550676177059840
Session Version: 13050143423070209
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 176.9X,X,X
Session Name (s): 3cxPS Audio call
Connection Information (c): IN IP4 176.9X,X,X
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 176.9X,X,X
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 9094 RTP/AVP 8 0 18 101
Media Type: audio
Media Port: 9094
Media Protocol: RTP/AVP
Media Format: ITU-T G.711 PCMA
Media Format: ITU-T G.711 PCMU
Media Format: ITU-T G.729
Media Format: DynamicRTP-Type-101
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute Fieldname: rtpmap
Media Format: 8
MIME Type: PCMA
Sample Rate: 8000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute Fieldname: rtpmap
Media Format: 0
MIME Type: PCMU
Sample Rate: 8000
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute Fieldname: rtpmap
Media Format: 18
MIME Type: G729
Sample Rate: 8000
Media Attribute (a): fmtp:18 annexb=no
Media Attribute Fieldname: fmtp
Media Format: 18 [G729]
Media format specific parameters: annexb=no
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute Fieldname: rtpmap
Media Format: 101
MIME Type: telephone-event
Sample Rate: 8000
Media Attribute (a): sendrecv
[Generated Call-ID: JzBxCjJ33TvobE9YxXZJDQ..]



Frame 5976: Packet, 953 bytes on wire (7624 bits), 953 bytes captured (7624 bits)
Encapsulation type: Linux cooked-mode capture v2 (210)
Arrival Time: Aug 20, 2026 11:06:46.279645000 Mitteleuropäische Sommerzeit
UTC Arrival Time: Aug 20, 2026 09:06:46.279645000 UTC
Epoch Arrival Time: 1787216806.279645000
[Time shift for this packet: 0.000000000 seconds]
[Time delta from previous captured frame: 25.846000 milliseconds]
[Time delta from previous displayed frame: 25.846000 milliseconds]
[Time since reference or first frame: 29.103132000 seconds]
Frame Number: 5976
Frame Length: 953 bytes (7624 bits)
Capture Length: 953 bytes (7624 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: sll:ethertype:ip:udp:sip:sdp]
Character encoding: ASCII (0)
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Linux cooked capture v2
Protocol: IPv4 (0x0800)
Reserved: 0000
Interface index: 1
Link-layer address type: Loopback (772)
Packet type: Unicast to us (0)
Link-layer address length: 6
Source: 00:00:00_00:00:00 (00:00:00:00:00:00)
Unused: 0000
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 933
Identification: 0xca6d (51821)
010. .... = Flags: 0x2, Don't fragment
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
...0 0000 0000 0000 = Fragment Offset: 0
Time to Live: 64
Protocol: UDP (17)
Header Checksum: 0x6ed8 [validation disabled]
[Header checksum status: Unverified]
Source Address: 127.0.0.1
Destination Address: 127.0.0.1
[Stream index: 1]
User Datagram Protocol, Src Port: 5062, Dst Port: 5483
Source Port: 5062
Destination Port: 5483
Length: 913
Checksum: 0x01a5 [unverified]
[Checksum Status: Unverified]
[Stream index: 18]
[Stream Packet Number: 14]
[Timestamps]
[Time since first frame: 26.768021000 seconds]
[Time since previous frame: 9.913352000 seconds]
UDP payload (905 bytes)
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:[email protected]:5483 SIP/2.0
Method: INVITE
Request-URI: sip:[email protected]:5483
Request-URI User Part: EndCall
Request-URI Host Part: 127.0.0.1
Request-URI Host Port: 5483
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bK-524287-1---a5e73d7447fb1179;rport
Transport: UDP
Sent-by Address: 127.0.0.1
Sent-by port: 5062
Branch: z9hG4bK-524287-1---a5e73d7447fb1179
RPort: rport
Max-Forwards: 70
Contact: <sip:[email protected]:5062>
Contact URI: sip:[email protected]:5062
Contact URI User Part: 49
Contact URI Host Part: 127.0.0.1
Contact URI Host Port: 5062
To: <sip:[email protected]:5062>
SIP to address: sip:[email protected]:5062
SIP to address User Part: 01726XXX
SIP to address Host Part: 127.0.0.1
SIP to address Host Port: 5062
From: " Josef"<sip:[email protected]>;tag=65d35425
SIP from display info: ", Josef"
SIP from address: sip:[email protected]
SIP from address User Part: 49
SIP from address Host Part: 127.0.0.1
SIP from tag: 65d35425
Call-ID: hJFM4L5ypHY7uAS6aInZOQ..
[Generated Call-ID: hJFM4L5ypHY7uAS6aInZOQ..]
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Subject: p=#NOTFOUND
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE
Content-Type: application/sdp
Supported: replaces, timer
Content-Length: 379
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): 3cxPS 29756508333932544 19664081841553409 IN IP4 127.0.0.1
Owner Username: 3cxPS
Session ID: 29756508333932544
Session Version: 19664081841553409
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 127.0.0.1
Session Name (s): 3cxPS Audio call
Connection Information (c): IN IP4 127.0.0.1
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 127.0.0.1
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 8522 RTP/AVP 0 8 9 109 101
Media Type: audio
Media Port: 8522
Media Protocol: RTP/AVP
Media Format: ITU-T G.711 PCMU
Media Format: ITU-T G.711 PCMA
Media Format: ITU-T G.722
Media Format: DynamicRTP-Type-109
Media Format: DynamicRTP-Type-101
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute Fieldname: rtpmap
Media Format: 0
MIME Type: PCMU
Sample Rate: 8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute Fieldname: rtpmap
Media Format: 8
MIME Type: PCMA
Sample Rate: 8000
Media Attribute (a): rtpmap:9 G722/8000/1
Media Attribute Fieldname: rtpmap
Media Format: 9
MIME Type: G722
Sample Rate: 8000 (RTP clock rate is 8kHz, actual sampling rate is 16kHz)
Audio Channels: 1
Media Attribute (a): rtpmap:109 opus/48000/2
Media Attribute Fieldname: rtpmap
Media Format: 109
MIME Type: opus
Sample Rate: 48000
Audio Channels: 2
Media Attribute (a): fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
Media Attribute Fieldname: fmtp
Media Format: 109 [opus]
Media format specific parameters: maxplaybackrate=48000
Media format specific parameters: stereo=1
Media format specific parameters: useinbandfec=1
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute Fieldname: rtpmap
Media Format: 101
MIME Type: telephone-event
Sample Rate: 8000
Media Attribute (a): fmtp:101 0-15
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-15
Media Attribute (a): ptime:20
Media Attribute Fieldname: ptime
Media Attribute Value: 20
Media Attribute (a): sendrecv
[Generated Call-ID: hJFM4L5ypHY7uAS6aInZOQ..]


Habe zu spät gesehen das ich auch eine CSV exportieren kann.

 

[bitn2]

Was für eine Rolle spielt die Fritzbox in diesem Konstrukt? Nur Modem oder sind die Rufnummern dort terminiert? Ja das kann zu Problemen führen. Grundsätzlich ist weder die Rufnummer noch die Fritzbox supportet. Was auch auffällt, in deinem Log sieht man das der Anruf von Vodafone abgelehnt wird. Wo ist die Rufnummer denn eingerichtet? In der Fritzbox oder in der 3cx? Wenn 3cx mit welchem Template?

EDIT: Das ist auch nicht korrekt

From: <sip:[email protected]:5062>;tag=f8301922

 

[avraammich_3CX]

Hi,

SIP/2.0 500 Server Internal Error
Via: SIP/2.0/UDP 192.168.4.252:5062;received=176.94.74.147;branch=z9hG4bK-524287-1---9cc41c465a45db21;rport=5062
To: <sip:+49 [email protected]:5060>;tag=6a4b1cf2-6a86d37f32f0d814-gm-po-lucentPCSF-138297
From: ""05171XXX""<sip:+495171XXX@arcor.de:5060>;tag=eaf44f58


Was ist hier der User Agent?

 

[Josef L]

@avraammich_3CX @bitn2

Die Rufnummern sind in der 3CX natürlich eingerichtet, die Fritzbox macht nur den Internetzugang.

Ich muss mir mal das Protokoll ansehen, wenn ich mich anrufe. Muss ja was anders sein.

SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.168.4.252:5062;received=176.94.74.147;branch=z9hG4bK-524287-1---0ea0285b23e1dd22;rport=5062
Contact: <sip:139.X.X.X:5060;x-afi=000>
To: <sip:[email protected]:5060>;tag=6a4b1cf2-6a86e1c120d4e7ef-gm-po-lucentPCSF-155789
From: ""05171XXX"<sip:[email protected]:5060>;tag=3469d368
Call-ID: Tuyz1DHZ_vtdbw9SdmioBw..


Wo muss denn der Useragent stehen?

Er steht hier z.B.
Via: SIP/2.0/UDP 127.0.0.1:5063;branch=z9hG4bK-524287-1---ec6acb2f97be6e31;rport
Max-Forwards: 70
Contact: <sip:[email protected]:5063>
To: <sip:[email protected]:5062>
From: " , Josef"<sip:[email protected]>;tag=5da0aa2d
Call-ID: T7Zt_lbO18V-izppuBkC2g..
[Generated Call-ID: T7Zt_lbO18V-izppuBkC2g..]
CSeq: 1 INVITE

 

[Josef L]

@avraammich_3CX @bitn2

Ich habe jetzt bei mir in der Anlage gestestet, ich habe auch ein Vodafoneanschluss:

update.2 = response_sent {

2 {

sip_message {

SIP/2.0 200 OK

Via: SIP/2.0/UDP 127.0.0.1:5063;branch=z9hG4bK-524287-1---e8b8ce5b8f713a01;rport=5063

Contact: <sip:[email protected]:5060>

To: "MakeCall to 01725xxxx"<sip:[email protected]:5060>;tag=96d8e271

From: <sip:[email protected]:5060>;tag=12f70232

Call-ID: u29O2ubUr8Nx-zFMeWWWzA..

CSeq: 2 INVITE

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE

Content-Type: application/sdp

Supported: replaces, timer

Content-Length: 350


update.8 = destinations {

rule_name=Regional

routes_count=1

0 {

route {

trunk=10007

dial=+49172xxxx

caller=", Josef"<sip:[email protected]:5060>;tag=12f70232

}

}

lines_count=1

}

 

[avraammich_3CX]

markieren den Leg/Anruf im Wireshark ->dann Flow Sequenzen klicken.

Welcher Endpunkt (user Agent)sendet 500 Server Internal Error?

 

[Josef L]

@avraammich_3CX ich hoffe ich habe dich richtig verstanden.

Den Fehler habe ich über den SIP-Trunk Checker erhalten:



und folgende Rufnummer wurde angerufen +49 1726XXXX über den Test ausgehende Anrufe.


Ich habe noch einmal gestestet gerade

jetzt geht der Anruf raus:


.
vorhin ging das eine ganze Zeit nicht, bei diesem Test kam die oben stehende Fehlermeldung

 

[Josef L]

Ich habe heute ein Test mit einem eingehende Anruf gemacht um einen Abbruch mit zu schneiden, dieser Tritt in der Regel nach +- 10 Minuten auf.

 

[Josef L]

@avraammich_3CX @bitn2 @fxbastler

Ich habe die Bereiche aus vorherigen Bild mit einer KI auswerten lassen, kann mich jemand dabei unterstützen, was zu machen ist?

Ruf: 05132xxx -> 05171xxxx · 9 SIP-Nachrichten · 2 Parteien · Ergebnis: abgebrochen
Zusammenfassung
Ein eingehender INVITE von 139.7.xx.xxx wird von 192.168.4.252 (3CXPhoneSystem) nach ~8 Sekunden mit 200 OK
angenommen. Die Verbindung besteht ca. 9 Minuten, wird durch einen Session-Timer-UPDATE bestätigt, und dann durch ein
BYE des Carriers mit dem Reason 'Session released - due to fail over reregistration or due to registration collision' beendet.
Der Gesprächsabbau ist somit nicht durch den Teilnehmer initiiert, sondern durch ein Registrierungsereignis auf der
Carrier-Seite erzwungen.

kritisch:
Erzwungenes BYE durch Registrierungskollision oder Failover-Reregistrierung
Der BYE trägt explizit den Reason-Header 'SIP;cause=500;text="Session released - due to fail over reregistration or due to registration
collision"', was bedeutet, dass die Netzwerk-Seite (Alcatel-Lucent-Proxy/PCSF bei 127.0.0.1) den laufenden Dialog terminiert hat, weil
05171xxx sich neu registriert hat (z.B. nach Failover oder doppelter Registrierung) und die bestehende Session damit als ungültig
gilt. Dies ist die direkte und eindeutig belegte Abbruchursache.
RFC: RFC 3326 §2 (Reason Header), RFC 3261 §10 (REGISTER)

Warnung:
From-URI-Userpart wechselt inkonsistent zwischen ACK/UPDATE und INVITE/BYE
Im INVITE und BYE lautet der From-Userpart '05132xxx', im ACK und UPDATE hingegen '+495132xxx' – bei identischer Call-ID
([email protected]), identischem From-Tag und gleichem Dialog. Obwohl RFC
3261 §12.2.1.1 fordert, dass die From-URI innerhalb eines Dialogs konstant bleibt, führt dies hier zu keinem sichtbaren Fehler, deutet
aber auf eine inkonsistente B2BUA-/Proxy-Behandlung im Alcatel-Lucent-PCSF-Knoten (127.0.0.1) hin.

Hinweis
Kein Record-Route im Dialog, aber mehrstufiges Routing via 127.0.0.1
Der INVITE enthält zwei Via-Einträge (139.7.x.x und 127.0.0.1), jedoch kein Record-Route-Header, sodass alle
Mid-Dialog-Requests (ACK, UPDATE, BYE) direkt an den Contact adressiert werden und 127.0.0.1 nicht im Route-Set ist. Mit mittlerer
Sicherheit ist dies eine bewusste Proxy-Konfiguration (lose Routing-Topologie), könnte jedoch bei Topologiewechseln zu
Routing-Problemen führen.

Ruf: 05132xxxx -> ROUTER · 7 SIP-Nachrichten · 1 Parteien · Ergebnis: abgebrochen
Zusammenfassung
Ein INVITE von 127.0.0.1:5062 an einen 3CX RoutePoint (127.0.0.1:5483) wird nach 180 Ringing sofort (nach nur 17 ms) mit
CANCEL abgebrochen, versehen mit Reason: SIP;cause=200;text='Call terminated'. Der Callee quittiert korrekt mit 200 OK auf
CANCEL und 487 auf INVITE, sendet jedoch danach noch einen 481 auf eine zweite CANCEL-Retransmission. Der ACK auf
487 schließt die Transaktion ab.

Kritisch:
CANCEL nach nur 17 ms – Ruf wird vor echtem Klingelversuch abgebrochen
Der CANCEL trifft 17 ms nach dem INVITE ein, bevor ein Mensch oder ein Gerät überhaupt reagieren könnte. Der Reason-Header
'SIP;cause=200;text=Call terminated' zeigt an, dass der Abbruch durch ein bereits erfolgreich abgeschlossenes Ereignis auf der
aufrufenden Seite ausgelöst wurde – typisch für einen parallel laufenden Fork, der bereits mit 200 OK beantwortet wurde.
RFC: RFC 3261 §9.1, RFC 4458 §4

Warnung:
481 auf CANCEL-Retransmission mit abweichendem To-Tag
Die zweite CANCEL-Retransmission (im Trace als '2× zusammengefasst') trifft ein, nachdem der 3CX RoutePoint die
CANCEL-Transaktion bereits abgeschlossen hat; er antwortet mit 481 und verwendet dabei ein neues To-Tag (e21fd652 statt
6a79bc5e). Das ist ein Implementierungsfehler des 3CX RoutePoint: ein 481 auf CANCEL ist nicht RFC-konform – korrekt wäre eine
erneute 200 OK oder stilles Verwerfen der Retransmission innerhalb des Transaktions-Timers.

Hinweis:
INVITE ohne SDP (Offer-less INVITE)
Das INVITE trägt Content-Length: 0 und kein SDP. Mit mittlerer Sicherheit deutet dies auf ein delayed-offer-Szenario hin, bei dem das
SDP-Offer erst im ACK geliefert würde – da der Ruf jedoch abgebrochen wird, bleibt dies folgenlos, ist aber ungewöhnlich für einen
einfachen internen Ruf.
RFC: RFC 3261 §13.2.1, RFC 3264 §5

Ruf: 05132xxxx -> 80 · 6 SIP-Nachrichten · 1 Parteien Ergebnis: abgebrochen
Zusammenfassung
Der UAC (127.0.0.1:5062) sendet ein INVITE an einen 3CX RoutePoint (127.0.0.1:5483), der mit 180 Ringing antwortet. Nach
ca. 8 Sekunden ohne weitere Antwort bricht der UAC den Ruf mit CANCEL ab. Der Abbruch wird sauber mit 200 OK
(CANCEL), 487 Request Terminated und ACK abgeschlossen.

Kritisch:
CANCEL nach 8 Sekunden – RoutePoint hat keinen finalen Response geliefert
Der 3CX RoutePoint verbleibt nach der 180 Ringing für ~8 Sekunden ohne 200 OK oder anderen finalen Response, was den UAC
zum CANCEL veranlasst. Mit mittlerer Sicherheit deutet dies auf eine Fehlkonfiguration oder einen Timeout im RoutePoint selbst hin
(z.B. kein erreichbares Ziel, Dial-Plan-Fehler), da kein weiterer Provisional-Response oder Progress sichtbar ist.
RFC: RFC 3261 §13.3.1

Warnung:
INVITE ohne SDP (SDP-loses INVITE)
Das INVITE trägt Content-Length: 0 und kein SDP-Body, ist also ein 'offerless INVITE' (RFC 3264). Der 3CX RoutePoint sendet
daraufhin ebenfalls keine SDP-Offer in der 180 Ringing – da kein 200 OK folgt, bleibt offen, ob der RoutePoint offerless INVITEs
korrekt verarbeitet hätte.

Hinweis:
CANCEL Reason: cause=200 – semantisch ungewöhnlich
Der Reason-Header 'SIP;cause=200;text="Call terminated"' ist strukturell gültig, aber semantisch unüblich: cause=200 suggeriert einen
erfolgreichen Abschluss als Abbruchgrund, was irreführend ist. Dies hat keine funktionale Auswirkung auf diesen Dialog, kann aber
Logging und CDR-Auswertung verfälschen.

Ruf: 05132xxx -> 48 · 18 SIP-Nachrichten · 1 Parteien · Ergebnis: erfolgreich
Zusammenfassung
Ein eingehender Anruf auf Leg 1 (Mobile Client, bO9JHoEeGnbJmQBEVyU4Ag..) wird nach ~8 Sekunden durch einen
Call-Pickup/-Transfer via SIP Replaces (Leg 2, u74ql07UhsiPP1qB3vwKXw.., 3CX WebRTC Proxy) übernommen. Leg 1 wird
per CANCEL beendet (487 Request Terminated), während Leg 2 erfolgreich etabliert wird und nach ca. 9 Minuten sauber per
BYE abgebaut wird.

Warnung;
Leg 2: Re-INVITE vom B2BUA nach 200 OK ohne erkennbare Antwort im Trace
Nach dem ACK auf den Replaces-INVITE (CSeq 2) sendet 127.0.0.1:5062 sofort einen weiteren Re-INVITE (CSeq 2,
13633125842157570 statt 13633125842157569, also neues SDP-Angebot) an 127.0.0.1:5063 – eine Antwort darauf fehlt im Trace
vollständig, bis das BYE nach ~9 Minuten folgt. Mit mittlerer Sicherheit handelt es sich um einen internen B2BUA-seitigen
Medienpfad-Update (z.B. Codec- oder Port-Anpassung Richtung Leg 1), der entweder nicht beantwortet wurde oder dessen Antwort im
Capture fehlt.
Erstellt

 

[avraammich_3CX]

sieht so aus als ob der SIP Trunk auch wo anderes Registriert ist.
Bin mir nicht sicher was die Fritte hier bewirkt.

 

[Josef L]

Gut kann ich leider aktuell auch nicht sagen, als ich die vor 2 Jahren mit konfiguriert habe, habe alle Rufnummern rausgeschmissen. Der Admin hatte mir mal ein VPN-Zugang eingerichtet, der ist nicht mehr aktiv. Ich muss am Montag über Fernwartung darauf zugreifen. Und mir das ansehen, ob da was verändert wurde. Der Admin ist leider wegen OP nicht greifbar.

 

[Josef L]

Ich wollte mich kurz zurückmelden, in der FritzBox waren tatsächlich wieder die Rufnummern aktiv. Nach der Löschung einen einen Testanruf gemacht mit der Dauer von 16 Minuten, ohne Abbruch. Ich hoffe das läuft alles wieder stabil.

Ich möchte mich bei allen Bedanken die sich eingebracht haben.

 

[bitn2]

Ich wollte mich kurz zurückmelden, in der FritzBox waren tatsächlich wieder die Rufnummern aktiv. Ich hatte darauf einen Testanruf gemacht und der 16 minuten gedauert ohne Abbruch. Ich hoffe das läuft alles wieder stabil.

Das habe ich schon vermutet. Das passiert gerne mal, deswegen sind die Provider Fritzboxen auch immer Mist.

 

[mbehrens]

Ich wollte mich kurz zurückmelden, in der FritzBox waren tatsächlich wieder die Rufnummern aktiv. Nach der Löschung einen einen Testanruf gemacht mit der Dauer von 16 Minuten, ohne Abbruch. Ich hoffe das läuft alles wieder stabil.

Davon würde ich bei den verwendeten Ports nicht ausgehen.

 

[Josef L]

Warum? Was soll nicht passen?

 

[mbehrens]

Warum? Was soll nicht passen?

Die Benutzung von Port 5060 ist in einer Umgebung mit einer FritzBox regelmäßig mehr als suboptimal.

 

[bitn2]

Die Benutzung von Port 5060 ist in einer Umgebung mit einer FritzBox regelmäßig mehr als suboptimal.

Laut Log wird Port 5062 benutzt.

 

[mbehrens]

Laut Log wird Port 5062 benutzt.

Einmal daneben geschaut

 

[bitn]

Wer eine Fritte vor der 3CX betreibt muss lernen durch Schmerzen Spreche da aus Erfahrung
Ist bei uns auch schon ein passiert.
Wenn das eine Provider Fritzbox ist, dann kann das immer wieder passieren wenn Vodafone tolle Ideen hat. Das liegt dann an der Autoprovisionierung.
Ich würde mich nie wieder darauf einlassen.

Beste Grüße

 

[Josef L]

Ich habe dem Kunden schon vorgeschlagen einen anderen Router zu nehmen. Würde da Draytek ín Erwägung ziehen. Der Admin muss nur mitspielen, er ist leider zur Zeit nicht verfügbar.