Difference between revisions of "M4 Disconnect Codes"

From Kolmisoft Wiki
Jump to navigationJump to search
 
(6 intermediate revisions by 3 users not shown)
Line 1: Line 1:
M4 Disconnect Codes (DC) is a rework of [[M2 Hangupcause Codes]] to support a new structure with the idea to move away from ISDB Q.850 codes to the SIP codes.
M4 Disconnect Codes (DC) is a rework of [[M2 Hangupcause Codes]] to support a new structure with the idea to move away from ISDN Q.850 codes to the SIP codes.
 
The rework is done in steps and for some time old HGC codes still are used in the system. CDRs in the system still shows old 3XX [[M2 Hangupcause Codes]].
 
<br>
= What can be done with Disconnect Codes =
 
* Replace/change Disconnect Codes coming from your Termination Point. For example 486 cause code to 503
* Replace/change Disconnect Codes going out to your Origination Point. For example 486 cause code to 503
* Set which Disconnect Code should be rerouted and which should not
* Control Reason header for each Disconnect Code
* Control to save CDR or not to save CDR for each Disconnect Code
* Create different Groups of Disconnect Codes for various situations / Connection Points


The rework is done in steps and for some time old HGC codes still are used in the system. CDRs in the system still show old 3XX [[M2 Hangupcause Codes]].


<br>
<br>
[[File:dc1.png]]
[[File:dc1.png]]
<br>
= Detailed Description =


<br><br>
<br><br>
== DC Groups ==
== DC Groups ==


System supports different groups of codes:
The system supports different groups of codes:


* Default - default values for the codes used in case it is necessary to reset back from custom changes from the Global group. Values in the Default group can't be changed in any way
* Default - default values for the codes used in case it is necessary to reset back from custom changes from the Global group. Values in the Default group can't be changed in any way
Line 27: Line 41:
* Q.850 - [https://networking.ringofsaturn.com/Routers/isdncausecodes.php ISDN Q.850 Codes] currently used as main codes in the system. Used for Reason Header generation.
* Q.850 - [https://networking.ringofsaturn.com/Routers/isdncausecodes.php ISDN Q.850 Codes] currently used as main codes in the system. Used for Reason Header generation.
* SIP - SIP Codes 3XX-6XX (returned from TP on failed call)
* SIP - SIP Codes 3XX-6XX (returned from TP on failed call)
* CORE - Unique Core related codes in the format 8XX (returned when a call fails in the system for various reasons)
* CORE - Unique Core-related codes in the format 8XX (returned when a call fails in the system for various reasons)


<br><br>
<br><br>
Line 41: Line 55:
* Reroute - property to tell the system if a call should be rerouted for some code. Applied only in the SIP namespace.
* Reroute - property to tell the system if a call should be rerouted for some code. Applied only in the SIP namespace.
* Reason Header - possible actions with the Reason Header
* Reason Header - possible actions with the Reason Header
* Save CDR - should we save CDR for this code. Can only be changed in the Global group.
* Save CDR - should we save CDR for this code? Can only be changed in the Global group.




Line 56: Line 70:
After this transformation, the system checks OP DC Group and if the change is necessary to the code - applies it based on OP DC Group.
After this transformation, the system checks OP DC Group and if the change is necessary to the code - applies it based on OP DC Group.


Logic looks like this:
The logic looks like this:


SIP response (3xx-6xx) from TP -> Code transformation based on TP DC Group -> Code transformation based on OP DC Group -> response with transformed code is sent to OP
SIP response (3xx-6xx) from TP -> Code transformation based on TP DC Group -> Code transformation based on OP DC Group -> response with transformed code is sent to OP
Line 62: Line 76:
Example:
Example:


TP sends 503 -> TP DC Group has the rule to transform 503 to 500, so now code is 500 -> OP DC Group has the rule to transform 500 to 501 -> 501 is sent to OP
TP sends 503 -> TP DC Group has the rule to transform 503 to 500, so now the code is 500 -> OP DC Group has the rule to transform 500 to 501 -> 501 is sent to OP


503 -> 500 -> 501
503 -> 500 -> 501
Line 83: Line 97:


<br>
<br>
=== Code change logic for CORE codes 8xx ===
=== Code change logic using SIP and Q.850 codes together ===
 
Request from the Clients: We are trying to add a SIP 503 Service or option not available, unspecified Q850 = 63 and reroute = NO
 
You can't do that as a pair: SIP 503 + Q850:63 = Reroute NO
 
M4 operates only with SIP codes and SIP 503 is "reroute" YES (You can change 503 to Reroute NO, but that would be terribly wrong).
 
M4 does not check SIP AND Q850 codes together. It only checks the SIP code and reacts based on it.
 
<br>
 
=== Code change the logic for CORE codes 8xx ===


Core namespace Codes mark call failure inside the system (Core).
Core namespace Codes mark call failure inside the system (Core).


Some CORE namespace codes apply only from the OP DC Group because TP is not known yet. For example when OP User is blocked system will return DC 840.
Some CORE namespace codes apply only from the OP DC Group because TP is not known yet. For example, when OP User is blocked system will return DC 840.


For some codes TP is known, so TP->OP transformation will be applied. For example, when the TP call limit reached, DC will be 852 and it will be taken from this TP's DC Group initially.
For some codes TP is known, so TP->OP transformation will be applied. For example, when the TP call limit is reached, DC will be 852 and it will be taken from this TP's DC Group initially.


<br><br>
<br><br>
Line 99: Line 125:
Example:
Example:


Using the previous example, let's say TP has no custom change for code 503. So in the first step when 503 is received, the system checks TP DC Group, does not found custom change for 503 code, then
Using the previous example, let's say TP has no custom change for code 503. So in the first step when 503 is received, the system checks TP DC Group, does not find a custom change for 503 code, then
the system checks Global DC Group for the code 503. If change is found - it's applied and the logic proceeds further as in the previous example.
the system checks Global DC Group for the code 503. If change is found - it's applied and the logic proceeds further as in the previous example.


Line 107: Line 133:
The system decides if it should try the next TP in the Routing Table based on the code received from the previous TP.
The system decides if it should try the next TP in the Routing Table based on the code received from the previous TP.


With Reroute YES - the next TP will be tried. With NO - call will end.
With Reroute YES - the next TP will be tried. With NO - the call will end.


Reroute property is only valid for the SIP Namespace.  
Reroute property is only valid for the SIP Namespace.  
Line 135: Line 161:
* Overwrite - drop Reason Header from TP if such comes and generate a new one based on our SIP->Q.850 mapping
* Overwrite - drop Reason Header from TP if such comes and generate a new one based on our SIP->Q.850 mapping


OP and TP can impact the final action for the Reason Header. That means that Reason Header actions from OP and TP are combined together to get the final action by which system will decide what to do with the Reason Header.
OP and TP can impact the final action for the Reason Header. That means that Reason Header actions from OP and TP are combined together to get the final action by which the system will decide what to do with the Reason Header.


The table below shows how the final action is calculated:
The table below shows how the final action is calculated:
Line 142: Line 168:




The logic goes like this: TP sends (or does not send) Reason Header to the system, the system checks TP DC Group what to do with it, does it. Then checks OP DC Group and applies its rule.
The logic goes like this: TP sends (or does not send) Reason Header to the system, the system checks TP DC Group what to do with it, does it? Then checks OP DC Group and applies its rule.


If action is "Generate if none" or "Overwrite" - the Reason Header could be generated if SIP Code has a mapping to the Q.850 code. If such mapping does not exist - Reason Header will not be generated.
If the action is "Generate if none" or "Overwrite" - the Reason Header could be generated if SIP Code has a mapping to the Q.850 code. If the such mapping does not exist - The Reason Header will not be generated.


IMPORTANT! OP DC Group will be used to find the SIP->Q.850 mapping for the Reason Header generation.
IMPORTANT! OP DC Group will be used to find the SIP->Q.850 mapping for the Reason Header generation.
Line 276: Line 302:
|-
|-
| 882 || MNP CIP does not match TP
| 882 || MNP CIP does not match TP
|-
| 883 || LNP search error
|-
|-
|}
|}
Line 281: Line 309:


<br><br>
<br><br>
= Troubleshooting =
= Troubleshooting =


Line 287: Line 316:
  [DEBUG] LegA[503]<-Core[503]<-LegB[503]
  [DEBUG] LegA[503]<-Core[503]<-LegB[503]


Means 503 came from TP (LegB) went to the Core unchanged by TP DC Group (Core), went to OP (LegB) unchanged by OP DC Group as 503
This means 503 came from TP (LegB) went to the Core unchanged by TP DC Group (Core), went to OP (LegB) unchanged by OP DC Group as 503


  [NOTICE] SIP [503] -> Q.850 [41] from DCG [5] retrieved
  [NOTICE] SIP [503] -> Q.850 [41] from DCG [5] retrieved
Line 304: Line 333:
  No DC [503] change  Stop Reroute [0]  Group [4]
  No DC [503] change  Stop Reroute [0]  Group [4]


Shows Reroute, DC Group usage and Code change
Shows Reroute, DC Group usage, and Code change


  TP/OP/Final Reason Header Action: 1/3/3
  TP/OP/Final Reason Header Action: 1/3/3
Line 317: Line 346:
= See also =
= See also =
* [[M2 Hangupcause Codes]]
* [[M2 Hangupcause Codes]]
* https://wiki.freeswitch.org/wiki/Hangup_Causes

Latest revision as of 12:32, 27 January 2023

M4 Disconnect Codes (DC) is a rework of M2 Hangupcause Codes to support a new structure with the idea to move away from ISDN Q.850 codes to the SIP codes.

The rework is done in steps and for some time old HGC codes still are used in the system. CDRs in the system still shows old 3XX M2 Hangupcause Codes.


What can be done with Disconnect Codes

  • Replace/change Disconnect Codes coming from your Termination Point. For example 486 cause code to 503
  • Replace/change Disconnect Codes going out to your Origination Point. For example 486 cause code to 503
  • Set which Disconnect Code should be rerouted and which should not
  • Control Reason header for each Disconnect Code
  • Control to save CDR or not to save CDR for each Disconnect Code
  • Create different Groups of Disconnect Codes for various situations / Connection Points



Dc1.png


Detailed Description



DC Groups

The system supports different groups of codes:

  • Default - default values for the codes used in case it is necessary to reset back from custom changes from the Global group. Values in the Default group can't be changed in any way
  • Global - a global group used for the values which are not set in the Custom Groups. Values in the Global group can be freely changed. Save CDR property can only be changed in the Global group.
  • Custom Groups - groups that can be created for custom Code changes.

Each group can be applied to the OP and TP.

Dc groups.png



Namespace

Disconnect Codes are separated into Namespaces:

  • Q.850 - ISDN Q.850 Codes currently used as main codes in the system. Used for Reason Header generation.
  • SIP - SIP Codes 3XX-6XX (returned from TP on failed call)
  • CORE - Unique Core-related codes in the format 8XX (returned when a call fails in the system for various reasons)



Codes

Each code has several properties:

  • Code - actual code
  • Reason - description of the code
  • Changed Code/Reason - SIP code/reason to be used in case if the change is necessary (covers Q.850->SIP mapping also)
  • Q.850 - Q.850 Code change. Only applicable to the SIP Codes for SIP->Q.850 mapping. Used for Reason Header generation.
  • Reroute - property to tell the system if a call should be rerouted for some code. Applied only in the SIP namespace.
  • Reason Header - possible actions with the Reason Header
  • Save CDR - should we save CDR for this code? Can only be changed in the Global group.




Code change logic

Code change logic by OP/TP

DC Group can be assigned to the OP and the TP separately. That means OP can have different code change logic compared to the TP.

When the SIP response comes from the TP it's in the format 3xx-6xx. Based on this response and TP DC Group, the response code can be transformed into another code.

After this transformation, the system checks OP DC Group and if the change is necessary to the code - applies it based on OP DC Group.

The logic looks like this:

SIP response (3xx-6xx) from TP -> Code transformation based on TP DC Group -> Code transformation based on OP DC Group -> response with transformed code is sent to OP

Example:

TP sends 503 -> TP DC Group has the rule to transform 503 to 500, so now the code is 500 -> OP DC Group has the rule to transform 500 to 501 -> 501 is sent to OP

503 -> 500 -> 501

This is an extreme example to illustrate the logic, usually, such changes are not necessary.


Code change logic using SIP and Q.850 codes

Conversion does not work like this 2 times: 

SIP 500 ---> Q.850 = 111, then
Q.850 = 111 ---> SIP 404

If you want to get SIP 404 (when SIP 500 is received), then you should make the SIP 500 ---> SIP 404 conversion rule (without intermediary Q.850 codes).

Q.850 -> SIP conversion is not used, it's just for informational purposes only.

SIP -> Q.850 code conversion is used only when Reason Header is generated.


Code change logic using SIP and Q.850 codes together

Request from the Clients: We are trying to add a SIP 503 Service or option not available, unspecified Q850 = 63 and reroute = NO

You can't do that as a pair: SIP 503 + Q850:63 = Reroute NO

M4 operates only with SIP codes and SIP 503 is "reroute" YES (You can change 503 to Reroute NO, but that would be terribly wrong).

M4 does not check SIP AND Q850 codes together. It only checks the SIP code and reacts based on it.


Code change the logic for CORE codes 8xx

Core namespace Codes mark call failure inside the system (Core).

Some CORE namespace codes apply only from the OP DC Group because TP is not known yet. For example, when OP User is blocked system will return DC 840.

For some codes TP is known, so TP->OP transformation will be applied. For example, when the TP call limit is reached, DC will be 852 and it will be taken from this TP's DC Group initially.



Global group Code usage

If OP or TP DC Groups do not have custom changes for the code, Global DC Group is consulted and if the change is found - it's applied from the Global group.

Example:

Using the previous example, let's say TP has no custom change for code 503. So in the first step when 503 is received, the system checks TP DC Group, does not find a custom change for 503 code, then the system checks Global DC Group for the code 503. If change is found - it's applied and the logic proceeds further as in the previous example.



Reroute

The system decides if it should try the next TP in the Routing Table based on the code received from the previous TP.

With Reroute YES - the next TP will be tried. With NO - the call will end.

Reroute property is only valid for the SIP Namespace.

IMPORTANT! Reroute property is taken from the TP DC Group only. In other words - the DC Group assigned to the OP does not impact Reroute logic of the call.



Reason Header

This property manages the actions of the SIP Reason Header.

Defined in:

Example, how it looks: 

Reason: Q.850 ;cause=17 ;text="User busy" ;extension= 01 02 03
Reason: Q.850 ;cause=1 ; text="Unallocated (unassigned) number"

Possible actions:

  • Drop - do not send Reason Header, drop it
  • Pass - send Reason Header down the line
  • Generate if none - pass and if Reason Header is missing - generate it
  • Overwrite - drop Reason Header from TP if such comes and generate a new one based on our SIP->Q.850 mapping

OP and TP can impact the final action for the Reason Header. That means that Reason Header actions from OP and TP are combined together to get the final action by which the system will decide what to do with the Reason Header.

The table below shows how the final action is calculated:

Reason header action logic.png


The logic goes like this: TP sends (or does not send) Reason Header to the system, the system checks TP DC Group what to do with it, does it? Then checks OP DC Group and applies its rule.

If the action is "Generate if none" or "Overwrite" - the Reason Header could be generated if SIP Code has a mapping to the Q.850 code. If the such mapping does not exist - The Reason Header will not be generated.

IMPORTANT! OP DC Group will be used to find the SIP->Q.850 mapping for the Reason Header generation.



Save CDR

Property is used to tell the system if some call's CDR should be saved to DB.

It can be changed only in the Global DC Group and only for SIP and CORE Namespaces.

EXCEPTION: Currently System does not save CDRs when there are too many CPS (>1000/s). HGC 342 / DC 802

IMPORTANT: several variables in the system.conf also influence CDR behavior and should be noted when troubleshooting.




CORE Disconnect Codes

Code Reason
Global system codes
800 Not authenticated
801 Global call limit reached
802 Global CPS limit reached
803 Duplicate CallID/UniqueID
804 MySQL query timeout
805 Call terminated by hangup command
Radius codes
814 Radius server did not receive accounting start packet (acct start timeout)
815 Radius server did not receive accounting stop packet (acct stop timeout)
OP codes
820 OP not found by IP address
821 OP was found by IP but tech prefix does not match
822 OP was found by IP but the port does not match
823 OP not active
824 OP codecs not allowed
825 OP call limit reached
826 OP CPS limit reached
827 OP rate not found
828 OP rate margin lower than allowed
OP User codes
840 OP User blocked
841 OP User balance limit reached (balance min)
842 OP User balance too low to make a call
843 OP User call limit reached
844 OP User not allowed to dial through own TPs
845 OP User call rate higher than allowed
846 OP User daily spend limit reached
TP codes
850 Suitable TP not found
851 TP unreachable (periodic check)
852 TP call limit reached
853 TP CPS limit reached
854 TP reached call limit in a Dial Peer
855 TP reached CPS limit in a Dial Peer
856 TP User blocked
857 TP User balance limit reached (balance max)
858 TP User call limit reached
Source codes
860 Source not accepted by OP regexp
861 Source denied by OP regexp
862 Source not accepted by TP regexp
863 Source denied by TP regexp
864 Source in the blacklist
865 Source not in the whitelist
Destination codes
870 Destination empty
871 Destination in the blacklist
872 Destination not in the whitelist
873 Destination blocked in OP Tariff
874 Destination blocked in TP Tariff
Other codes
880 Dial Peer not found
881 MNP search error
882 MNP CIP does not match TP
883 LNP search error




Troubleshooting

Radius Log

[DEBUG] LegA[503]<-Core[503]<-LegB[503]

This means 503 came from TP (LegB) went to the Core unchanged by TP DC Group (Core), went to OP (LegB) unchanged by OP DC Group as 503 

[NOTICE] SIP [503] -> Q.850 [41] from DCG [5] retrieved

shows SIP->Q.850 mapping 

[NOTICE]  TP [19:sipp-UAS] q850_reason [NORMAL_TEMPORARY_FAILURE] cd->dialstatus [FAILED] q850_code [41] cd->hangupcause [41] legA sip code [503] legB sip code [503] Hangup disp [recv_refuse]

same data in a different representation

Kamailio log

GET_DC_FROM_CACHE  DC [503] TP [19]
 No DC [503] change   Stop Reroute [0]   Group [5]
GET_DC_FROM_CACHE  DC [503] OP [12]
No DC [503] change   Stop Reroute [0]   Group [4]

Shows Reroute, DC Group usage, and Code change 

TP/OP/Final Reason Header Action: 1/3/3
...
Reason Header overwritten

Shows Reason header actions (0 - drop, 1 - pass, 2 - generate, 3 - overwrite). In this example 1/3/3 means OP/TP/Final, eg pass+overwrite -> overwrite




See also

Retrieved from "https://wiki.kolmisoft.com/index.php?title=M4_Disconnect_Codes&oldid=28616"