DirectRouting und Q.850 Codes (2024)

Table of Contents
Fehlerbild Analyse der Anrufe SIP auf Q.850 Mapping Cause=63 und PSTN Beispiel ISDN2SIP Beispiel SfB On-Premises Q.850 und Busy on Busy (BOB) Fix für Direct Routing und Q.850 Weitere Links References
Inhaltsverzeichnis
  1. Fehlerbild
  2. Analyse der Anrufe
  3. SIP auf Q.850 Mapping
  4. Cause=63 und PSTN
  5. Beispiel ISDN2SIP
  6. Beispiel SfB On-Premises
  7. Q.850 und Busy on Busy (BOB)
  8. Fix für Direct Routing und Q.850
  9. Weitere Links

Diese Seite beschreibt die Zusammenhänge zwischen ISDN-Codes (Q.850) und Direct Routing, wenn Sie auf der Amts-Seite eine ISDN-Verbindung (E1/T1/S2m/S0) haben. Ein Fehlverhalten seitens Microsoft hat mich auf diesen Sonderfall aufmerksam gemacht.

Fehlerbild

Ich habe bei Tests zum ThemaDirect Routing und Media Bypass von meinem Mobiltelefon auch einfach mal einen TeamOnly-Benutzer angerufen, der nicht angemeldet war, der keine VoiceMail, Stellvertreter o.ä. hatte und ich daher ein "Nicht erreichbar" erwartet hätte. Allerdings habe ich auf meinem Mobiltelefon ein Freizeichen gehört und der Ruf hat sehr lange geklingelt. Da sollte ich dann doch mal nachsehen, was genau passiert ist.

Analyse der Anrufe

Ein Bick mit dem Syslog-Viewer auf die Logfiles zeigt den Anruf. Genau genommen sind es aber fünf Anrufe.

DirectRouting und Q.850 Codes (1)

Ich bin aber sehr sicher, dass ich nur genau einen Anruf gestartet habe. Ich sehe aber von der Cloud auch einen "480 Temporarily Unavailable". Ich sehe aber auch den Q.850 Code von Microsoft. Da muss ich dann erst mal nachschauen, was auf der ISDN-Seite passiert.

Im Mai 2020 hat Microsoft dann wohl den Code auf die 34 geändert

DirectRouting und Q.850 Codes (2)

Auch das ist nicht gerade der richtige Weg, denn der Anrufer hier versucht auch wieder mit einer Wahlwiederholung das "Gassenbesetzt" zu lösen.

See Also
Informationen zur Tabelle mit den Ursachencodes für getrennte interne Anrufe beim Sprach-RouterUnderstand Voice Router Internal Call Disconnect Cause Code Table

SIP auf Q.850 Mapping

Dazu gibt es entsprechende Listen, in denen empfohlene Umsetzungen beschrieben sind. Die Herausforderung ist ja nicht erst seit Teams vorhanden sondern schon seit den ersten VoIP-Versuchen aktuell

In allen Dokumentationen ist das Mapping für ISDN zu SIP analog zur RFC3398 beschrieben. Da halten sich wohl alle Entwickler dran.

 The following mapping values are RECOMMENDED: Normal event ISUP Cause value SIP response ---------------- ------------ 1 unallocated number 404 Not Found 2 no route to network 404 Not found 3 no route to destination 404 Not found 16 normal call clearing --- (*) 17 user busy 486 Busy here 18 no user responding 408 Request Timeout 19 no answer from the user 480 Temporarily unavailable 20 subscriber absent 480 Temporarily unavailable 21 call rejected 403 Forbidden (+) 22 number changed (w/o diagnostic) 410 Gone 22 number changed (w/ diagnostic) 301 Moved Permanently 23 redirection to new destination 410 Gone 26 non-selected user clearing 404 Not Found (=) 27 destination out of order 502 Bad Gateway 28 address incomplete 484 Address incomplete 29 facility rejected 501 Not implemented 31 normal unspecified 480 Temporarily unavailable

In diese Richtung gibt es aber auch mehrere ISDN Codes (19/20/31), die alle auf ein "SIP/2.0 480 Temporarily unavailable" umgesetzt werden. In meinem Fall ist aber die Gegenrichtung interessant, welcher SIP-Code auf welche Q.850 Code umgesetzt wird. Dazu zitiere ich einfach die Audiocodes Dokumentation

DirectRouting und Q.850 Codes (3)
Quelle:https://www.audiocodes.com/media/13230/mediant-1000b-gateway-and-e-sbc-users-manual-ver-72.pdf

Der SIP Error "SIP/2.0 480 Temporarily unavailable" sollte als auf einen ISDN Code 18 umgesetzt werden.

DirectRouting und Q.850 Codes (4)

Hier ist aber zu sehen, dass in dem "SIP/2.0 480 Temporarily unavailable" der Fehler "Cause=63" kommt und diese vom Gateway zu einem Q.850 Code 63 umgesetzt wird.

Cause=63 und PSTN

Das Gateway meldet also ein "PSTNDisconnectCall()" mit dem Fehlercode 63 an das Amt. Da stellt sich natürlich die Frage, welche Überlegung Microsoft mit dem Code verbindet, zumal er in den üblichen Tabellen nicht aufgeführt ist. Bei Starcom wurde ich dann mal fündig:

DirectRouting und Q.850 Codes (5)
Q.850 CAUSE CODEShttps://www.startelecom.ca/resources/q-850-cause-codes/

Und auf einer alten Seite bei Dialogic gab es noch eine zusätzliche Information.

Cause 63 Service or option not available, unspecified - This cause is used to report a service or option not available event only when no other cause in the service or option not available class applies.
Quelle: Dialogic ITU Standard Causeshttps://www.dialogic.com/webhelp/MSP1010/10.2.3/WebHelp/MSP_DG/ISUP/Cause_Codes.htm

Überraschend ist für mich dann aber, was mein Mobilfunkanbieter aus diesem Fehler macht. Er wiederholt die Anwahl immer wieder.

DirectRouting und Q.850 Codes (6)

Der Fehler 63 wird also als "bitte noch mal versuchen" durch das Netzwerk interpretiert. Auf meinem Smartphone hingegen sehe ich davon gar nichts. Dort habe ich ein Freizeichen, als wenn der Ruf aufgebaut wurde und die Gegenseite "klingelt"

Beispiel ISDN2SIP

Exemplarisch habe ich einen Anruf von Skype for Business zum ISDN-Netz an eine nicht erreichbare Rufnummer ausgeführt und die "480"-Meldung mitgeschnitten. Das Gateway antwortet auf den INVITE des Skype for Business Servers mit dem 480 und einem passenden "Reason"

---- Outgoing SIP Message to 192.168.100.102:59521 from SIPInterface #3SIP/2.0 480 Temporarily UnavailableVia: SIP/2.0/TLS 192.168.100.102:59521;branch=xFrom: "User1" <sip:+49xxxxxx@uclabor.de;user=phone>;tag=x;epid=xTo: <sip:+49xxxxxx@gate.uclabor.de;user=phone>;tag=xCall-ID: xxx-xxx-xxx-xxx-xxxCSeq: 41503 INVITESupported: em,timer,replaces,path,resource-priorityAllow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATEServer: Mediant 1000/v.7.20A.250.256Reason: Q.850 ;cause=19Content-Length: 0

Hier steht sauber der "cause=19" drin,. Das Gateway hast also von der ISDN-Seite die Meldung bekommen und auf einen "480" samt passendem "Reason"-Code umgesetzt.

Beispiel SfB On-Premises

In der Gegenrichtung habe ich von einem Mobil-Telefon einen Anruf an einen Skype for Business On-Premises Benutzer gestartet, der ebenfalls nicht angemeldet war. Hier sehe ich dann die Antwort des Mediation Servers

---- Incoming SIP Message from 192.168.100.12:5067 to SIPInterface #0 (Lan-GW) TLSSIP/2.0 480 Temporarily UnavailableFROM: <sip:+49xxxxxx@gate.uclabor.de>;tag=1c1623588440TO: <sip:+495251304xxx@sfb.uclabor.de;user=phone>;tag=889c3336;epid=1F3786F8EDCSEQ: 1 INVITECALL-ID: 12705305162722019102137@192.168.100.116VIA: SIP/2.0/TLS 192.168.100.116:5067;branch=z9hG4bKac1417715829;aliasCONTENT-LENGTH: 0

Interessanterweise liefert Skype for Business Mediation Server gar kein "Reason"-Feld mit. Das Gateway wird hier dann seine eigene Mapping-Tabelle nutzen.

Q.850 und Busy on Busy (BOB)

Im Mai/Juni 2019 wurde auch die Funktion "Besetzt bei Besetzt" in Teams ausgerollt, d.h. eine Endstelle konnte so konfiguriert werden, dass ein Zweitanruf nicht gemeldet wurde. Auch hier ist mit genau der Fehler wieder begegnet. Hier aber mit dem "486 Busy Here".

SIP/2.0 486 Busy HereFROM: <sip:+49160xxxxxxxx@uclabor.de>;tag=xxxxTO: <sip:+495251304805@sbc.uclabor.de;user=phone>;tag=xxxxCSEQ: 1 INVITECALL-ID: xxxxxx@sbc.uclabor.deVIA: SIP/2.0/TLS sbc.uclabor.de:5061;branch=z9hG4bKac1161925514REASON: Q.850;cause=63;text="xxxx-xxxx-xxxx-xxxx-xxxx;User is busy and currently active on another call."CONTACT: <sip:api-du-a-euwe.pstnhub.microsoft.com:443;transport=tls;x-i=xxxx-xxxx-xxxx-xxx-xxxx;x-c=/v1/ngc/call/xxx/s/1/xxx>CONTENT-LENGTH: 0ALLOW: INVITEALLOW: ACKALLOW: OPTIONSALLOW: CANCELALLOW: BYEALLOW: NOTIFYSERVER: Microsoft.PSTNHub.SIPProxy v.2019.4.24.4 i.EUWE.4

Das Verhalten beim Anruf aus dem Mobilfunknetz ist auch hier identisch: Er bekommt kein Besetztzeichen und die Telekom startet mehrere Anrufe zur "Heilung" des unbekannten Fehlers 63

Fix für Direct Routing und Q.850

Natürlich habe ich den Fehler so erst mal direkt an die entsprechenden Personen bei Microsoft gesendet. Ich hatte Sie ja zufällig zwei Wochen vorher auf dem MVP-Summit in Redmond persönlich getroffen. Innerhalb weniger Minuten kam direkt die Rückmeldung, dass das so nicht richtig sein könnte und intern schon entsprechende Untersuchungen laufen, um ein geeignetes Verhalten umzusetzen. Bis dahin können Sie aber je nach Gateway/SBC eine Message Manipulation einsetzn. Ursache ist natürlich der Q.850-Code von Microsoft, der hier eine 63 statt einer 18 oder 19 oder 20 liefert. Ich habe zuerst versucht diese Zuordnung über das "Release Cause Mapping" zu überschreiben, aber es hat nicht gewirkt:

DirectRouting und Q.850 Codes (7)

Allerdings habe ich danach im Syslog immer noch gesehen, dass der falsche Code 63 weiter gegeben wird. Anscheinend wirkt diese Tabelle nur, wenn im SIP-Paket drin nicht ein Code hinterlegt wurde.

Dann sollte aber eine Manipulation des SIP-Pakets die Unstimmigkeit aus der Welt schaffen. Entsprechend hat mein Kollege dann eine Header Manipulation in der folgenden Weise für das "Busy Problem" umgesetzt

DirectRouting und Q.850 Codes (8)

In der INI-Datei von Audiocodes sieht das dann wie folgt aus:

[ MessageManipulations ]FORMAT MessageManipulations_Index = MessageManipulations_ManipulationName, MessageManipulations_ManSetID, MessageManipulations_MessageType, MessageManipulations_Condition, MessageManipulations_ActionSubject, MessageManipulations_ActionType, MessageManipulations_ActionValue, MessageManipulations_RowRole;MessageManipulations 4 = "Teams Busy is real Busy", 4, "any", "header.request-uri.methodtype=='486' and header.reason.reason.cause=='63'", "header.reason.reason.cause", 2, "'17'", 0;[ \MessageManipulations ]

Damit wird die eingehende SIP-Message so verändert, dass der SBC/Gateway dann den "richtigen" Q.850 Code weiter gibt.

Wichtiger als die Beseitigung des kleinen Fehlers ist mit aber den Zusammenhang zwischen einer Q.850-Meldung im SIP-Paket und der entsprechenden Weitergabe auf einem ISDN-Trunk herzustellen. Der war mir so vorab bislang nicht bewusst. Ich dachte, dass die interne Tabelle zur Umsetzung eines SIP-Codes auf einen Q.850 Code und ggfls. eine manuelle Anpassung für die Meldung in Richtung ISDN maßgeblich ist.

Weitere Links

DirectRouting und Q.850 Codes (2024)

References

Top Articles
No Butter Chocolate Chip Cookies
Ultra-Chewy Vegan Snickerdoodles
Here Are the Net Worth and Income That Put You in the Top 5% of American Households by Age | The Motley Fool
How YouTube became a TV powerhouse and how much ad revenue it makes
Jim Rau Dog Shows Results
Beryl is first hurricane of 2024 Atlantic season | CNN
The Commercial Appeal from Memphis, Tennessee
Every NBA Starting Lineup
Release Notes Juni 2024
Target Nasal Spray Recall
Latest Posts
40+ Keto Baked Goods Made Without Almond Flour (cookies, brownies, breads, cakes, muffins, & more!)
Almond Flour Mug Cake
Article information

Author: Kerri Lueilwitz

Last Updated:

Views: 6133

Rating: 4.7 / 5 (47 voted)

Reviews: 86% of readers found this page helpful

Author information

Name: Kerri Lueilwitz

Birthday: 1992-10-31

Address: Suite 878 3699 Chantelle Roads, Colebury, NC 68599

Phone: +6111989609516

Job: Chief Farming Manager

Hobby: Mycology, Stone skipping, Dowsing, Whittling, Taxidermy, Sand art, Roller skating

Introduction: My name is Kerri Lueilwitz, I am a courageous, gentle, quaint, thankful, outstanding, brave, vast person who loves writing and wants to share my knowledge and understanding with you.