cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7929
Views
0
Helpful
4
Replies

H323 ISDN call to PSAP

Hello,

I have an H323 gateway with multiple PRIs terminating in it. All calls work correctly on these gateways except I have a problem with 911 calls to the local PSAP. In the Q931 debug, I do not get a connect message when the PSAP answers the call:

*Jul 8 21:38:26.012: ISDN Se0/0/1:23 Q931: TX -> SETUP pd = 8 callref = 0x0387

Bearer Capability i = 0x8090A2

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98381

Exclusive, Channel 1

Calling Party Number i = 0x2181, 'xxxxxxxxxx'

Plan:ISDN, Type:National

Called Party Number i = 0xA1, '911'

Plan:ISDN, Type:National

Redirecting Number i = '!', 0x0082, '911'

Plan:ISDN, Type:National

*Jul 8 21:38:26.108: ISDN Se0/0/1:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8387

Channel ID i = 0xA98381

Exclusive, Channel 1

*Jul 8 21:38:26.708: ISDN Se0/0/1:23 Q931: RX <- PROGRESS pd = 8 callref = 0x8387

Cause i = 0x82FF - Interworking error; unspecified

Progress Ind i = 0x8281 - Call not end-to-end ISDN, may have in-band info

After talking to the PSAP for 3 minutes, the call terminates:

*Jul 8 21:46:04.515: ISDN Se0/0/1:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x0389

Cause i = 0x8093 - User alerting, no answer

*Jul 8 21:46:04.603: ISDN Se0/0/1:23 Q931: RX <- RELEASE pd = 8 callref = 0x8389

*Jul 8 21:46:04.603: ISDN Se0/0/1:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x0389

I presume that the gateway disconnects the call because it doesn't know that the call has been answered.

I found the following fix in the Cisco CUCM SRND:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/6x/e911.html#wp1043779

It says the fix is to add "progress_ind alert enable 8" to the pots dial peer and "voice rtp send-recv" to the global config. I've done this and we still have the same problem. Has anyone come across this problem before and found a fix?

Thanks,

Glenn

4 Replies 4

Hello Glenn,

Try adding "progress_ind progress enable 8" to the dial peer.

Hope that helped, if so please rate.

paolo bevilacqua
Hall of Fame
Hall of Fame

That is a serious problem, and I don't think that any router configuration can fix lack of connect acknowledgment.

See the problems are beginning early:

Cause i = 0x82FF - Interworking error; unspecified

You need to talk to your carrier, but be prepared to escalate and insist, because from what I understand few people fully understand the intricacies of N.A. PSAP, and a lot of fingerpointing occurs.

We've already spoken to the LEC and they said they can't/won't do anything about this.

There must be some way around this as we also have an Avaya PBX that sees the same setup messages (or lack thereof) but does not drop the call. Is there a timer I can change as a potential workaround?

Thanks,

Glenn

That could be T310 however I think it resets when ALERT is received.

The switch/psap/whatever is violating the standard but the PBX is tolerant about that, may be they know better.

I find personally very irritating that telcos and/or cisco do not take a clear stance on this matter. Fortunately I do not live where PSAP is used.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: