Asterisk, SS7 and 18x responses


We have an Asterisk box with 8 E1s - an SS7 interconnect.

We have a customer who asks us not to send any 18X response back to him when the number is invalid, only send it when it is a valid number. Is that even possible to be selective on? As I understand it, 18x are provisional and are sent at a time where we have no clue what the final response will be and we do not know if it is a valid number yet, - so how should we decide on whether to send 18x or not? Am I wrong? Or is there some way we can decide on whether to send the 18x response, dependent on the validity of the number?


It’s my understanding that SS7 uses Q.931 Cause Codes and they are grouped into the following on the following classes

  • Normal events: Cause 1-31
  • Resource unavailable: Cause 32-47
  • Service or option not available: Cause 48-63
  • Service or option not implemented: Cause 64-79
  • Invalid message: Cause 80-95
  • Protocol error: 96-111
  • Internetworking: Cause 112-127

(Cause code values of 128 and higher aren’t sent over the network, and aren’t defined in Recommendation Q.850)

Taking into consideration the description of the issue…

I’m going to assume that you mean SIP Response codes and on specific SIP 183 Session in progress.

If I’m not mistaken this SIP message usually occurs when the Telco wants to send audio to the far end system without considering the call answered, As an example, the message “The number that you dialed is not available please check the number and dial again” is normally sent by SIP 183 or PRI PROGRESS (Note: SIP 183 works similar to the PRI message PROGRESS).

If your Asterisk server is in the middle (between your customer and the telco’s switch) you could use a dialplan to catch calls to invalid numbers and then hang up the call with a different cause code.

Denis Martinez
Digium, Inc. | Support Technician L2
dCAP - Digium Certified Asterisk Professional

Thanks a lot for your answer!

Yes, I am talking about SIP response codes when I refer to 183.

All 1xx response codes in SIP are provisional, while 200-699 are final responses. So 183 indicates that the call is in progress. If for example the number does not exist, it would be appropriate to return 404, which means ‘not found’, or 484, ‘address incomplete’. The message ‘the number you dialed is not available’, is usually SIP code 4xx or 5xx.

So I am a bit confused as to how I can possibly know about the outcome of the call at the time when I need to send a progress message (183). I think I need to read more on the Q.931 and SS7 flow.

Added: If the flow is this from the SS7 side:


  • then I could handle it if the ACM part told me that the number does not exist, but it looks like this:

Len = 30 [ hex stuff ]
FSN: 104 FIB 1
BSN: 25 BIB 1
<[0] MSU
[ 99 e8 1b ]
Network Indicator: 0 Priority: 0 User Part: ISUP (5)
[ 05 ]
OPC 2164 DPC 2244 SLS 0
[ c4 08 1d 02 ]
CIC: 1
[ 01 00 ]
Message Type: ACM
[ 06 ]
Backward Call Indicator:
Charge indicator: 0
Called party’s status indicator: 0
Called party’s category indicator: 0
End to End method indicator: 0
Interworking indicator: 0
End to End information indicator: 0
ISDN user part indicator: 1
Holding indicator: 0
ISDN access indicator: 0
Echo control device indicator: 0
SCCP method indicator: 0
[ 00 04 ]
Generic Notification Indication:
[ 2c 01 fb ]
Unknown Parameter (0x36):
[ 32 ]
Unknown Parameter (0xc):
[ 04 10 03 50 96 00 50 ]

So therefore, how can I respond anything but 183 at all calls at the ACM level, if I have no info about how it is going to turn out?

Not necessary, I believe that ACM is equivalent to Q.931 ‘Call Proceeding’ message or SIP 100 Trying message, therefore, it means that the telco’s switch accepted the call, and “it’s looking what to do with it”

Maybe you would like to look for the HangUp cause code on the REL message.

Nop, SIP 183 doesn’t means that the call is in progress. It’s my understanding that this message happens when one of the sides (The side that sends the SIP 183) signal to the other side to open audio ports becuase a message will be sent, BUT the call shouldn’t be considered answered.

Not necessary, Please take into consideration that Asterisk is not the system that determines that the number does not exist, it only reports back to your customer system what telco is telling. Most likely the communication between the Asterisk and your end customer is like:

< 100 TRYING
< OK


I found on the internet a document that talk about SIP 183 Session Progress Message and has a few examples with SS7. … 183-00.txt

I think that It could contain usable information for you