DirectRouting und Q.850 Codes

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 Thema Direct 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.

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

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

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


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.

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:


Q.850 CAUSE CODES  https://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 Causes  https://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.

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 #3
SIP/2.0 480 Temporarily Unavailable
Via: SIP/2.0/TLS 192.168.100.102:59521;branch=x
From: "User1" <sip:+49xxxxxx@uclabor.de;user=phone>;tag=x;epid=x
To: <sip:+49xxxxxx@gate.uclabor.de;user=phone>;tag=x
Call-ID: xxx-xxx-xxx-xxx-xxx
CSeq: 41503 INVITE
Supported: em,timer,replaces,path,resource-priority
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
Server: Mediant 1000/v.7.20A.250.256
Reason: Q.850 ;cause=19
Content-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) TLS
SIP/2.0 480 Temporarily Unavailable
FROM: <sip:+49xxxxxx@gate.uclabor.de>;tag=1c1623588440
TO: <sip:+495251304xxx@sfb.uclabor.de;user=phone>;tag=889c3336;epid=1F3786F8ED
CSEQ: 1 INVITE
CALL-ID: 12705305162722019102137@192.168.100.116
VIA: SIP/2.0/TLS 192.168.100.116:5067;branch=z9hG4bKac1417715829;alias
CONTENT-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 Here
FROM: <sip:+49160xxxxxxxx@uclabor.de>;tag=xxxx
TO: <sip:+495251304805@sbc.uclabor.de;user=phone>;tag=xxxx
CSEQ: 1 INVITE
CALL-ID: xxxxxx@sbc.uclabor.de
VIA: SIP/2.0/TLS sbc.uclabor.de:5061;branch=z9hG4bKac1161925514
REASON: 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: 0
ALLOW: INVITE
ALLOW: ACK
ALLOW: OPTIONS
ALLOW: CANCEL
ALLOW: BYE
ALLOW: NOTIFY
SERVER: 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:

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

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