cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

3844
Views
5
Helpful
39
Replies
Highlighted
Hall of Fame Master

Re: Mapping PSTN cause codes with the corresponding SIP Cause co

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.

Highlighted
Beginner

Re: Mapping PSTN cause codes with the corresponding SIP Cause co

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.

Raj

Highlighted
Hall of Fame Master

Re: Mapping PSTN cause codes with the corresponding SIP Cause co

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.

Highlighted
Beginner

Re: Mapping PSTN cause codes with the corresponding SIP Cause co

Hi,

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

Raj

Highlighted
Enthusiast

Re: Mapping PSTN cause codes with the corresponding SIP Cause co

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.

Thanks,

Art

Highlighted
Hall of Fame Master

Re: Mapping PSTN cause codes with the corresponding SIP Cause co

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.

Highlighted
Enthusiast

Re: Mapping PSTN cause codes with the corresponding SIP Cause co

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

Art

Highlighted
Hall of Fame Master

Re: Mapping PSTN cause codes with the corresponding SIP Cause co

By coincidence, today I needed this one too and doesn't work.

I keep trying.

Highlighted
Enthusiast

Re: Mapping PSTN cause codes with the corresponding SIP Cause co

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

Highlighted
Enthusiast

Re: Mapping PSTN cause codes with the corresponding SIP Cause co

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.

Cheers!

Art