Fehlendes Ringback bei Calls zu Teilnehmern auf Arcor-Plattform
vor 6 Jahren
Hallo Spezialisten der SIP-Telekomplattform!
Seit geraumer Zeit ist bei outbound Calls zu Teilnehmern der Arcor-Plattform via AllIP der Telekom kein Ringback im Telefon des Callers mehr zu hören. Hintergrund ist vermutlich, dass das Signaling zur Arcor-Plattform seitens der Telekom gestört zu sein scheint:
Anstatt nach dem Invite ein 100 Trying / 180 Ringing dem Caller zu übermitteln (damit weiß das Telefon, dass das Ringback lokal erzeugt werden muss), kommt ein 100 Trying / 183 Session in progress ohne SDP an (also beginnender Aufbau von early media ohne einen SDP-Kanal bereitzustellen - das macht nun wenig Sinn). Folge ist, dass das Telefon kein Ringback signalisiert, da kein "Inband-Signaling" möglich ist mangels SDP.
Geht man den gleichen Outbound-Call via Easybell, tritt keinerlei Problem auf - das Signaling entspricht genau dem üblichen Soll: 100 / 180.
Bitte mal den Übergang zur Arcor-Plattform checken und das Signaling wieder so einstellen, dass es passt - entweder mit 183 + SDP (und iband signaling) oder ohne 183 und nur 180 Ringing - dann weiß mein SIP-Telefon auch wieder, was es machen soll!
Danke!
894
7
Das könnte Ihnen auch weiterhelfen
1050
0
4
1189
0
1
vor 4 Jahren
274
0
3
vor 6 Jahren
Das sinnlose 183 Session Progress Paket filtern bei den betroffenen Nummern -- dann kann es keinen Schaden mehr anrichten. Hierzu erst mal eine dedizierte Chain einrichten, in die alle Pakete geschoben werden, die 183 Session Progress - Pakete sind:
iptables -N t-online-in-broken
# Diese Rule schiebt alle Session Progress Pakete von t-online in die t-online-in-broken - Chain:
iptbales -I INPUT -i ppp0 -p udp -m iprange --src-range 217.0.18.0-217.0.29.255 -d eigene InternetIP --sport 5060 --dport 5060 -m conntrack --ctstate RELATED,ESTABLISHED -m string --string "183 Session Progress" --algo bm -j t-online-in-broken
# In der t-online-in-broken - chain dann für die betroffenen Teilnehmernummern die Session Progresse-Pakete droppen.
iptables -A t-online-in-broken -m string --string "49..." --algo bm -j DROP
Die genannten Regeln setzen voraus, dass ein funktionierendes connection tracking eingerichtet ist für SIP. Außerdem sind sie nur Workaround-Teil eines gesamten Regelwerks, um das Prinzip als Solches aufzuzeigen.
Umsetzung erfolgt auf eigenes Risiko. Hat hier funktioniert!
Bei der Regelreihenfolge im Gesamtkonstrukt darauf achten, dass die Regeln für die RTP-Pakete vor dieser Workaroundregel abgearbeitet werden, so dass nicht der ganze RTP-Strom durch den String-Check muss.
1
Antwort
von
vor 6 Jahren
Als Ergänzung, damit sich niemand wundert, warum der Workaround überhaupt funktioniert: Die Telekom schickt nach dem SDP-losen 183 Session Progress noch ein 180 Ringing - was ja für sich allein genommen völlig ok wäre und es dann auch ist, wenn man den 183 einfach verwirft.
Uneingeloggter Nutzer
Antwort
von
vor 6 Jahren
Ersteinmal vielen Dank für das Gespräch. Wie besprochen können Sie mir gerne einen Trace als Direktnachricht schicken.
Gruß
Sören G.
4
Antwort
von
vor 6 Jahren
Damit auch hier der aktuelle Stand abgebildet ist, ich habe das Ticket an Spezialisten für das Thema übergeben. Wir kontrollieren regelmäßig den Stand des selbigen.
Gruß Sören G.
Antwort
von
vor 6 Jahren
Haben sich die Kollegen bei dir gemeldet?
Es wurde alles geprüft und auf unserer Seite sieht soweit alles sauber aus.
Der Fehler wird durch unsere Plattform erzeugt.
Beste Grüße
Markus Km.
Antwort
von
vor 6 Jahren
Hi @user347 Haben sich die Kollegen bei dir gemeldet?
Haben sich die Kollegen bei dir gemeldet?
Ja
Es wurde alles geprüft und auf unserer Seite sieht soweit alles sauber aus. Der Fehler wird durch unsere Plattform erzeugt.
Der Fehler wird durch unsere Plattform erzeugt.
Korrekt, der Fehler wird durch Ihre Plattform erzeugt - aber es wurde trotzdem abgelehnt, das Ganze zu fixen - mit der Begründung, es käme doch neben dem SDP-losen 183 auch ein 180 Ringing - frei nach dem Motto, das Telefon des Callers soll sich gefälligst selbst das korrekte Paket aussuchen und das falsche einfach verwerfen.
Die beiden Pakete sind jedoch widersprüchlich: 183 teilt dem Caller mit, dass das Alerting vom B-Teilnehmer (Callee) erzeugt wird (via RTP), während 180 dem Caller mitteilt, dass er das Alerting lokal selbst erzeugen muss.
Damit das 183er-Paket funktionieren kann, muss jedoch ein SDP enthalten sein - da ist aber keiner, weil das Paket an dieser Stelle offensichtlich falsch ist.
Nebenbei:
Ich habe die Paketfilterregel nun so angepasst, dass sie allgemeingültig ist und nur noch die 183er-Pakete verwirft, die ohne SDP daherkommen (in der Chain t-online-in-broken - die Regel in der INPUT-Chain bleibt unverändert):
iptables -A t-online-in-broken -m string --string "rtpmap" --algo bm -j ACCEPT
iptables -A t-online-in-broken -j DROP
-> Die rufnummernspezifischen Einträge werden somit nicht mehr benötigt.
Uneingeloggter Nutzer
Antwort
von
Uneingeloggter Nutzer
Frage
von