Mapping PSTN cause codes with the corresponding SIP Cause codes

Unanswered Question
May 18th, 2009


We are trying to integrate the Asterisk dialer through SIP trunk with Cisco 3845 gateway running c3845-adventerprisek9-mz.124-15.XZ2 IOS image on the same. I`m facing some issues in my attempt to track the Special Information Tones (SIT) on this deployment ,where in the normal disconnect cause code 16 for all the calls are being reported to the Asterisk dialer on the SIP trunk. Ideally it should be the different cause codes for each of the SIT type. Could somebody please advise ,if this is supported with the Cisco Voice gateway platforms? This is kind of urgent for us.


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
rajasekarvs Mon, 05/18/2009 - 12:54


Thanks for th equick turnaround. We are connecting to the PSTN though ISDN - T1. We would like to capture all the SIT tones and identify them with appropriate type. For example the PSTN disconnect cause code 1 is mapped with the Unallocated number (SIT), etc.,


Paolo Bevilacqua Mon, 05/18/2009 - 13:09

There are no SIT tones with ISDN, and router present to the remote site any in-band tone during the call setup.

The cause codes are provided via Q931, and the router does the best mapping possible to/from SIP.

Paolo Bevilacqua Mon, 05/18/2009 - 14:24

Nice, but the documentation states support for FXO* and CAS only. The OP mentioned ISDN instead.

* It would be also interesting to understand how FXO is supported as there is no such thing on the AS5xxx series.

Nicholas Matthews Mon, 05/18/2009 - 15:15

I'm sure it's referencing T1 FXO lines, which nobody uses anyways.

Thought I would throw it out there because it's kind of nifty.


rajasekarvs Tue, 05/19/2009 - 05:43

Hi Guys,

It`s right that the SIT informations are sent via the ISDN Q931 cause codes ,but the mapping part from the voice gateway seems to be working incorrectly ,as it always does the graceful disconnect and sends "16" as the cause code on the SIP trunk. Ideally this should be different values for each of the disconnect causes. For example , it should return the value of "1" for the unallocated number. So that the Asterisk would mark this call with the appropriate SIP cause code mapping configured on the same.

According to the documents and the "show sip-ua map pstn-sip" shows the correct mapping. But it always sends the normal clearing cause code "16" and that leads to our issue. Please advise. Could appreciate ,if you guys can give me your contact number to discuss the same.


Paolo Bevilacqua Tue, 05/19/2009 - 08:42

Post a trace taken with "debug isdn q931" and "debug ccsip message" to prove your point.

Do not enable any other debug.

rajasekarvs Tue, 05/19/2009 - 10:22


Please find the requested debugs from the voice gateway as attached. I have attached the traces from the Asterisk box as well. The test call was made to an unallocated number for which the disconnect cause code should have been "1" but we have got "16" instead.


Paolo Bevilacqua Tue, 05/19/2009 - 12:48

Note: you're referring to Progress Indicator to SIP mapping, not disconnect cause to sip mapping.

The disconnect cause is 16 because asterisk is actually disconnecting in a normal manner, not the router or PSTN.

Anyway, do you have configured ?

voice service voip

signaling forward

rajasekarvs Tue, 05/19/2009 - 14:26


I already have the Signalling forward unconditional command under the Voice services voip configured. The disconenction piece , I`m confused here. The Asterisk makes a call through SIP trunk to the Cisco VG and the call is hooked on to the PSTN. The call gets disconnected by the PSTN switch after the SIT tone being played and sends a disconnect message to the Cisco VG. The Cisco VG in turn should send the corresponding SIP message to the Asterisk. Please advise ,if my understanding is correct here.

If my understanding is correct ,then the disconnect event is not initiated by the Asterisk.


Paolo Bevilacqua Tue, 05/19/2009 - 16:06

No, asterisk is disconnecting, see below. This is normal, as the person making the call, hangs up after listening to the PSTN announcement. If you was to wait longer, you could see PSTN disconnecting perhaps.

I agree the router should send an INFO message to reflect the PI "number unavailable", however to an human user, that does not make much of a difference.

.May 19 18:13:58.077: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:


CANCEL sip:912561366440@ SIP/2.0

Via: SIP/2.0/UDP;branch=z9hG4bK5c48ed41;rport


From: "6099772546" ;tag=as7574b329


Call-ID: 42d5a10b32a6f1e832a20309314d0965@

CSeq: 102 CANCEL

User-Agent: Asterisk PBX

Max-Forwards: 70

Content-Length: 0

rajasekarvs Wed, 05/20/2009 - 11:15

Thanks for the input. Looks like the Asterisk is sending the disconnect message to the Cisco VG and VG sends the SIP hangup cause code 487 with ISDN Q931 disconnect cause code "16" back to the Asterisk. Its not the PI that I`m referring here.

Please take a look at the extract below for the SIP disconenct cause mapping with Q931 disconnect codes.

/* Causes for disconnection (from Q.931) */












The same mapping is found on the Cisco VG as well ,but it returns the incorrect code.

Please advise.


Paolo Bevilacqua Wed, 05/20/2009 - 11:25

Hi, the thing is that the cancel message from asterisk does not specify a cause, consequently the router translates that to a normal disconnect to q931, as defined in the table you referenced.

On the other hand, router fails to forward PI for unallocated number that I think is what your problem is about.

I think it would forward that via H.323, but this is clearly irrelevant this discussion.

rajasekarvs Wed, 05/20/2009 - 11:41

Hi Nick,

Do you have any inputs on this? I hope you have understood our issue. If not please let me know and I`m glad to explain the same to you.


Nicholas Matthews Wed, 05/20/2009 - 11:47

Hi Raj,

This is an artifact of how the provider is disconnecting the call. Paolo is right.

RX <- PROGRESS pd = 8 callref = 0x878F

Cause i = 0x8381 - Unallocated/unassigned number

Progress Ind i = 0x8388 - In-band info or appropriate now available

Because this isn't a disconnect, it's not a disconnect cause code. This basically just says "Play reorder tone into the audio stream and let the user hang up".

There are better ways to do this, but we can't change that on the gateway.

Fact is, in this call flow, the SIP side hangs up with the Cancel. That's the disconnect, and as such it gets the 0x10 cause code.


Paolo Bevilacqua Wed, 05/20/2009 - 12:03

Fact also is, SIP is never notified of an important call progress event. It could use it for whatever purpose, but it cannot.

Reading around documentation it seems that the router should forward that, but it doesn't. Strange.

rajasekarvs Wed, 05/20/2009 - 12:12


Could appreciate ,if any workarounds can be suggested for this...:) This is really eating up my brian for more than a week and holds a module of the project as well...:(


rajasekarvs Thu, 05/21/2009 - 11:44

No changes in the set of SIP messages in the transaction.Same as earlier.


rajasekarvs Thu, 05/21/2009 - 11:44

No changes in the set of SIP messages in the transaction.Same as earlier.


Paolo Bevilacqua Thu, 05/21/2009 - 11:47

I think that router not forwarding the number unallocated PI is a real problem and you should engage cisco about it.

rajasekarvs Thu, 05/21/2009 - 11:55

Any idea on the default behaviour ? Is it supposed to forward or not?


Nicholas Matthews Thu, 05/21/2009 - 15:15

Hi Raj,

I'm not quite sure how SIP would need to forward this information through to the Asterisk PBX.

If you put a case in between 9-12 est tomorrow I'll take a look at this.


rajasekarvs Fri, 05/22/2009 - 04:56


I have an update ,that the same scenario works with Cisco AS5400XM VG as the gateway sends the appropriate PI & SIP message to the Asterisk. This proves for now,that the ISRs do not support our case. Lemme do some more research with the same and I`ll my findings with you...


Paolo Bevilacqua Fri, 05/22/2009 - 10:02

Can you post the trace of Q.931 and SIP ? I'd like to see how this is handled.

I think the GW should forward both a 4xx message as the call has ultimately failed, and the PI of inband announcement or tones. So the OGW has the choice of what to do with their user.

On the other hand I understand that in your case it's automated calls and not users so all what you wanted is the error message.

rajasekarvs Fri, 05/22/2009 - 10:21

Hey ,

I don`t think I can get the gateway traces ,as I`m trying the call with our production gateway that`s processing the live calls and we don`t have a test AS5400...:(

You are right ,it`s all the automated calls from the dialer and we just wanted the error message back to write the call result on to the database.


Paolo Bevilacqua Fri, 05/22/2009 - 11:06

Just briefly enable debug q931 for a single PRI and the ccsip message, that is not impacting to CPU. You can always log debug to buffer for even a better way.

You will need to show these to the TAC if you want the issue resolved on the ISR.

rajasekarvs Tue, 05/26/2009 - 04:59


I`m sorry for the delayed response.Lemme try getting the debugs from the gateway and I`ll upload them to this thread.


asandborgh Wed, 01/11/2012 - 09:44

Was there ever an answer from Cisco why the unallocated cause code was not forwarded via SIP?  I have the same situation with a 15.1(3) 3845  to a  8.5 CUCM - the carrier sends an unallocated back in a progress message on an outbound call but actually goes on to connect the call for about 60 seconds.  The gateway never forwards what should be a 404 (I would think), but instead sends a series of "183 Session Progress" messages to the CUCM and the caller just hears ringback.  Now I know the carrier should disconnect the call straight away in a perfect world, but getting them to change will likely be next to impossible.  We do have "Signalling forward unconditional" already configured.  Is there something we can do to force the forward of the unallocated/404?

Any help would be appreciated.



Paolo Bevilacqua Wed, 01/11/2012 - 10:04

If acceptable in your case, can you try

voice call disc-pi-off

that makes the VG to disconnect imediately even in presence of PI.

asandborgh Wed, 01/11/2012 - 10:24

Thanks Paolo for the quick reply.  I gave it a go, but unfortunately that didn't work on this one.


asandborgh Wed, 01/11/2012 - 14:06

I asked PDI too.  Will let you know if they send anything back....

asandborgh Tue, 01/24/2012 - 19:10

Turns out my issue is an IOS bug, from Cisco:

There is a documented IOS bug on this, CSCta66956, which was supposed to fix that issue in your current IOS version 15.1(3)T. However, looking at the internal bug notes for CSCta66956, I found that an IOS file build error happened and the fix code was removed from the IOS versions that were supposed to include that fix. For this problem, a new software defect was raised, CSCtq49731, and the fix code was added to public IOS versions in train 15.2T.

BTW, if you look for bug CSCtq49731 in Cisco's web site, you will see that it specifically mentions "Cause i = 0x82E46C", however this bug actually applies to all cause codes.




This Discussion