CNS Ankommend seit heute auf E-SIM ohne Funktion

Nebenbei bemerkt: Zahlreiche unserer Kunden haben seit letzter Woche Donnerstag das Problem mit O2-Mobil auf unsere Festnetz-Rufnummern anzurufen. Direkte O2-Kunden verzeichnen einen Abbruch nach ca. 30 Sekunden, Freenet-Kunden haben kein Audio. Ein Freenet-O2-Kunde hat bei bei nur einer physischen SIM bereits das Problem mit der falschen Rufnummernanzeige, wie oben beschreiben.

Wurde an dem Huawei-Softswitch von O2 ein “Update” eingespielt?

Mir ist seit heute mittag aufgefallen, das bei uns in der Firma bei der Funktion Single Number Reach auch meine Rufnummer des Dienstapparates angezeigt wird, statt die des Anrufers. Nutze eSim. Da muss ich morgen mal eine Plastik-SIM mitnehmen.

Da momentan immer mehr Kunden sich “neu” melden, bei denen es vorher funktioniert, scheint O2 hier gerade eine Migration durchzuführen.

Mir schwant fürchterliches. ;-)

Hi @Bytegetter 

Holla die Waldfee, da hast du ja ein spannendes Fehlerbild mitgebracht. Am 27.07 ist dir der Fehler das erste mal geschildert worden, ist das soweit korrekt? Da bielo diesen “Fehler” auch schon beobachtet hat, ist die Frage, ob es bei euch beiden eine Gemeinsamkeit gibt. Vielleicht mögt ihr ja mal beide eure PLZ oder Vorwahlengebiete verraten, vielleicht können wir das ganze so schon ein wenig eingrenzen. Ansonsten müssen wir mal schauen, wie wir das ganze strategisch angehen und an wen wir dieses “Fehlerbild” adressieren und ob wir dafür dann weitere Daten von euch benötigen.  

VG Matze

P.S 

Danke fürs testen. Bitte dann hier direkt berichten.

E

Folgende Fehlerbilder gibt es seit letzter Woche, wenn der A-Teilnehmer bei O2 ist:

• Gespräche brechen nach ca. 33 Sekunden ab
• Bei zumindest einem Freenet-Kunden kein RTP

B-Teilnehmer bei O2

• Tlw. dauerhaft falsche Rufnummernübermittlung bei bestimmten SIM-Karten

Die Fehlerbilder werden aktuell überwiegend aus ganz Brandenburg und Berlin gemeldet (also dem gesamten Einzugsbereich).

Das Fehlerbild mit den Rufnummern kann ich aktuell in Sachsen-Anhalt dauerhaft nachstellen. In Brandenburg wäre am Wochenende ein Test möglich.

Alle Fehlerbilder treten nur mit O2-Kunden auf. Für die B-Seite kann ich nur für DNS:NET sprechen, da dies meine Plattform ist.

Zeitfenster ist hauptsächlich ab dem 27.07., tlw. aber auch schon vorher. Dies spricht für eine Datenbank- oder Plattform-Migration (erst ein paar Testkunden, wenn der Störnebel niedrig bleibt dann kommen größere Kundenmengen). Ich hatte mal 60.000 SIP-Kunden auf eine andere Datenbank migriert, dass haben gerade mal 6 (In Worten: sechs) Kunden mitbekommen. Hätte ich vorher den Re-Register-Timeout nach unten gesetzt, dann wären es noch weniger gewesen. Aber nun gut. ;)

@bielo und @Bytegetter Ich kann “Entwarnung” geben. Ich würde mir das gerne auf die Fahne schreiben, aber irgendwer war da vorher schon aktiv hinter den Kulissen 😄 

Der Fehler ist der Fachabteilung schon aufgefallen und man ist in der Analyse, zumindest wurde uns die Info gerade so schon zugetragen.  

Auf eurer Seite der Leitung ist also alles soweit korrekt (davon sind wir eh ausgegangen, es ist aber immer gut, wenn man direkt die Bestätigung dazu bekommt).

Jetzt heißt es abwarten. Die Vermutung, das irgendwo was “kaputt gepatcht” wurde kommt mir aber ziemlich valide vor, von daher werden da jetzt einige IT Kollegen im Serverkeller sicher die ein oder andere Überstunde machen müssen. (Ich hab das jetzt etwas lapidar mit einem Grinsen und einem lachenden und auch einem weinenden Auge getippt, ich bin mir aber sicher, dass ihr das richtig einschätzen könnt, wie das ganze gemeint war 😄) 

Danke auf jeden Fall für die Meldung und die ausführliche Fehlerauflistung, wir leiten das mal gesammelt so an die Kollegen weiter, jeden Hinweis der zur Lösungsfindung führt ist da sicher gern gesehen. 

VG Matze  

Handy ist zusätzlich mit Plastik-SIM bestückt. 

Da fällt mir ein, wir migrieren seit heute die komplette IP Telefonie zu Telefonica. Muss ich nochmal nachlesen.

Edit nach @o2_Matze : Das klingt doch super. Danke 

@o2_Matze: Sind alle 3 Fehler bekannt?

@Bytegetter Die Kollegen haben uns die Info geschickt, dass die fehlerhafte Rufnummernanzeige bei RUL aufgefallen ist und der Fehler dazu in der Analyse ist.

Ich könnte mir vorstellen, das alles andere damit zusammenhängt. 

Ansonsten nur zur Vollständigkeit halber:

Falsche Anzeige der Rufnummer bei Weiterleitung und Gespräche brechen nach ca. 33 Sekunden ab.

Was wäre der dritte Fehler? 

VG Matze

@o2_Matze 

Fehler 3:

Freenet-Mobilfunk-Kunden bei O2, die unsere Festnetz-Rufnummern anrufen, haben gar kein Audio (=RTP). Meine RTP-Zähler auf dem Softswitch zählen aber hoch (d.h. es kommen auf meiner Plattform Audio-Daten an und werden auch vom Router (in dem Fall eine Fritzbox) gesendet, aber auf dem Handy ist nichts zu hören. Davon gibt es aktuell zwei Kunden, die ich kenne. Der Kunde von uns, mit dem ich heute telefoniert hatte, hat folgende Attribute: Freenet-Kunde, physischie Single-SIM, kein RTP, falsche Rufnummernanzeige.

Bei den Kunden, bei denen gar kein Audio geht (RTP auf Mobilfunkseite tot): Hier vermuten wir aktuell ein Problem mit der ptime (Erklärung ptime hier: https://www.msxfaq.de/skype_for_business/technik/sdp.htm )

Hier der Call dazu (bitte nach Sichtung löschen, danke):

AAAAAAAAA: Freenet-Mobilfunk-Kunde
BBBBBBBBB: Unser Festnetz-Kunde

01.08.2023 16:42:46.269 +02:00: 87.136.9.110:5060 -> 213.220.155.226:5060
INVITE sip:+BBBBBBBBB;npdi;rn=+49D167BBBBBBBBB@dns-net.de;user=phone SIP/2.0
Via:  SIP/2.0/UDP 87.136.9.110:5060;branch=z9hG4bK+55e295bb86b7543bc261d98e4f3d0c7b1+BIAA3GQ+1+a680bdc4
From:  <sip:+AAAAAAAAA@telefonica-voip.de:5060;user=phone>;tag=87.136.9.110+1+9931928e+3d223ab2+BIAA3GQ
To:  <sip:+BBBBBBBBB@telekom.de;user=phone>
CSeq:  944186 INVITE
Expires:  180
Route:  <sip:dns-net.de;lr>
Content-Length:  761
Supported:  timer,replaces,199, 100rel
Contact:  <sip:457625FA0AA5CDB3-BIAA3GQ@87.136.9.110:5060;transport=udp;lr>
Record-Route:  <sip:457625FA0AA5CDB3-BIAA3GQ@87.136.9.110:5060;transport=udp;lr>
Content-Type:  application/sdp
Call-ID: bcf6325a0a0f766f4747c2b2ca788c57@87.136.9.110
Max-Forwards:  64
Allow:  INVITE, ACK, CANCEL, BYE, INFO, NOTIFY, PRACK, UPDATE, OPTIONS, MESSAGE
Accept:  application/sdp, application/3gpp-ims+xml
P-Asserted-Identity:  <sip:+AAAAAAAAA;cpc=ordinary@telefonica-voip.de:5060;user=phone>
P-Asserted-Identity:  <tel:+AAAAAAAAA;cpc=ordinary>
P-Preferred-Service:  urn:urn-7:3gpp-service.ims.icsi.mmtel
Session-ID:  12372861484458624900000000000000;remote=00000000000000000000000000000000
P-Mav-Extension-Correlation-ID:  e8d016b80100164f2ff
x-hmr:  iiI7!od_slb15!ois18!
Session-Expires:  1800;refresher=uac
Min-SE:  90
P-Early-Media:  supported

v=0
o=Sonus_UAC 129137227219883 129137227219883 IN IP4 87.136.9.110
s=-
c=IN IP4 87.136.249.32
t=0 0
m=audio 32848 RTP/AVP 112 116 9 118 8 0 111 110
b=AS:80
b=RS:1000
b=RR:3000
a=sendrecv
a=rtpmap:112 EVS/16000
a=rtpmap:116 AMR-WB/16000/1
a=rtpmap:9 G722/8000
a=rtpmap:118 AMR/8000/1
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:111 telephone-event/16000
a=rtpmap:110 telephone-event/8000
a=msi:mavodi-0-15b-c6-3-ffffffff-bf250000-5ffdf125c556d-2d64-ffffffffffffffff-@10.137.195.12-10.137.207.3;UAGOFF04-233
a=rtcp-xr:voip-metrics
a=maxptime:240
a=fmtp:112 br=5.9-24.4;bw=nb-swb;max-red=0
a=fmtp:116 mode-change-capability=2;max-red=220
a=fmtp:118 mode-change-capability=2;max-red=220
a=fmtp:111 0-15
a=fmtp:110 0-15
a=ptime:20

Bei mir ist der Fehler weg. Ich weiß, dass gestern unser Datenverarbeitungszentrum dazu ein Ticket ausgelöst hat, weil der Fehler bei etlichen Kollegen war. 

Ev.t bekomme ich raus, ob es an uns (z.B. die Migration zu Telefónica) lag oder o2 hat in der Nachschicht gearbeitet. 

Bei mir funktioniert die Rufnummernanzeige auch wieder. Blieben noch die restlichen Themen.

Hi @Bytegetter 

Verzeih der Thread ist mir durchgerutscht. 

Hat sich mittlerweile wieder alles beruhigt, oder gibt es noch Herausforderungen? 

Falls es sich dabei noch um Freenet-Mobilfunk handelt, müssten sich diese direkt an ihre Kundenbetreuung wenden.

VG Matze 

Hallo Matze,

CNS funktioniert nun. Im Pascom-Forum gibt es noch Meldungen, dass es ab und zu nicht funktioniert. Das war aber auch schon vor 10 Jahren bei TF so, als ich noch bei QSC gearbeitet hatte. Es gibt eine Route zu O2, bei der CNS nicht funktioniert.

Der Fehler bei mir lag daran, dass TF das SDP-Attribut “a=rtcp-xr” geändert hat. Da war vorher ein “;” am Ende, wie im Ursprünglichen RFC 3621 definiert. Dass Errata dazu wurde bei mir nicht berücktsichtigt. Im SDP ist die Zeile nun auch ohne trailing “;” zulässig, was mein Softswitch aber als Fehlerhaft verwarf. Nachdem ich einen Hotfix eingespielt hatte funktionieren diese Calls nun auch wieder.

Leider habe ich keinen Carrier-Kontakt zu TF, so dass es etwas schwierig ist, solche Fehler zu analysieren.