cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2806
Views
0
Helpful
18
Replies

PRI H323 gateway inbound calls not working

appserv
Level 1
Level 1

HI,

We have a 2801 GW running IOS c2801-spservicesk9-mz.124-11.XW10.bin. GW has a PRI. Call manager version is 4.1.3 sr5d

Outbound calls work fine however we cannot get any inbound calls to complete.

Attached is a debug isdn q931 and debug voice ccapi inout and a config of the router.

From the debug voice ccapi inout the call hits dial-peer 100 and then bounces to dial-peer 101. Does this indicate an issue with Call Manager? We've configured our H323 gateway in CCM as we normally do.

Thanks

Quinn

18 Replies 18

Is there a firewall between the gateway and the CCM? Take a look at this segment from the ccapi inout output:

Jul 10 20:10:53.829: //28/9B08F3F9800D/CCAPI/ccSaveDialpeerTag:

Outgoing Dial-peer=100

Jul 10 20:11:08.836: //29/9B08F3F9800D/CCAPI/cc_api_call_disconnected:

Cause Value=18, Interface=0x660203C0, Call Id=29

Jul 10 20:11:08.836: //29/9B08F3F9800D/CCAPI/cc_api_call_disconnected:

Call Entry(Responsed=TRUE, Cause Value=18, Retry Count=0)

Do you see the 15 seconds between when the call setup happens and the call is disconnected (with cause value 18)? I don't know what cause value 18 is, but I'd bet it has something to do with a timeout, which usually indicates that something is getting blocked somewhere.

Thanks for your reply.

I think cause value 18 = no user responding. Which matches the phone seup in CCM whihc is ring for 15 seconds. Caller gets no ringing.

No firewalls or ACL's in the way right now - i've stripped everything back

I don't think the 15 seconds is a CCM setting. That 'no user responding' message is a H.323 message, not a CCM message. I suspect that the VG is not getting a H.323 response from the CallManager to it's H.323 setup messages. That's the only reason the VG would try a different dial-peer. If it was actually connected to the CCM, the CCM would either connect to drop the call, and the VG would *not* try another dial-peer.

I've just done a call forward all on the 78124 dn in CCM to my mobile. and this call completed successfully.

attached is the debug q931 of this.

i'm confused?!

I'd be interested in what the ccapi inout looks like on that call. If's it's able to send the call back out the gateway, that would make me think it's a rtp issue, such as the codec or a dsp. Although it looks like you have the codecs all configured correctly.

here it is. thanks for looking

This is a sh call active voice brief

: ms. + pid:

dur hh:mm:ss tx:/ rx:/

IP : rtt:

delay://ms

media inactive detected: media cntrl rcvd: timestamp:

long duration call detected: long duration call duration : timestamp:

MODEMPASS buf:/ loss /

last s dur:/s

FR [int dlci cid] vad: dtmf: seq:

(payload size)

ATM [int vpi/vci cid] vad: dtmf: seq:

(payload size)

Tele (callID) [channel_id] tx://ms noise: acom: i/o:/ dBm

MODEMRELAY info:// xid:/ total://

speeds(bps): local / remote /

Proxy :

bw: / codec:

tx:

rx:

Telephony call-legs: 1

SIP call-legs: 0

H323 call-legs: 1

Call agent controlled call-legs: 0

SCCP call-legs: 0

Multicast call-legs: 0

Total call-legs: 2

1218 : 187 17525690ms.1 +-1 pid:1 Answer 1093631830 connected

dur 00:00:00 tx:0/0 rx:0/0

Tele 0/1/0:15 (187) [0/1/0.10] tx:0/0/0ms None noise:0 acom:0 i/0:0/0 dBm

1218 : 188 17525700ms.1 +-1 pid:100 Originate 78124 connecting

dur 00:00:00 tx:0/0 rx:0/0

IP 0.0.0.0:0 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g729r8 pre-ietf TextRelay: off

media inactive detected:n media contrl rcvd:n/a timestamp:n/a

long duration call detected:n long duration call duration:n/a timestamp:n/a

Telephony call-legs: 1

SIP call-legs: 0

H323 call-legs: 1

Call agent controlled call-legs: 0

SCCP call-legs: 0

Multicast call-legs: 0

Total call-legs: 2

why is it using this codec g729r8 pre-ietf?? I've nto specified this anywhere?

If i convert this gateway to MGCP all is fine. However i need H323 for Unity faxing.

Any suggestions appreciated

Not sure if bumps are allowed....

"why is it using this codec g729r8 pre-ietf?? I've nto specified this anywhere?"

Sure you have. It's the third preference on your voice-class codec 10. And the fact that this works with MGCP and not with H.323 makes me wonder about the region that the H.323 gateway is in. Is it in a different device pool than the phone, and if so, are the two device pools in the same region? Or, at least, if they are different regions, are you allowing the G.711 codec between them? You could remove the 'codec preference 3 g729r8' command from the voice class codec 10 command.

Although that doesn't really explain why the call isn't working. Unless, of course, the phone you are calling doesn't support G.729r8.

karldbrooks
Level 4
Level 4

The call on your Q.931 trace has a called number of '212484869' however your inbound POTS dialpeer has a destination-pattern of 1T.

Change your POTS dialpeer to:

dial-peer voice 1 pots

voice cut-through alert

tone ringback alert-no-PI

preference 1

incoming called-number .T

destination-pattern 1T

progress_ind alert enable 8

direct-inward-dial

port 0/1/0:15

This will cover all incoming calls with the .T and all outgoing calls of 1T, however I would recommend having separate incoming and outgoing POTS dialpeers.

The calls are matching dial-peer 1 because it's the only POTS dial-peer and the port matches, so that is not causing the problem. It's probably good practice to create a specific inbound POTS dial-peer using the 'incoming called number' command, but it's not necessary to fix this issue.

Also, the CCAPI indicates that it is matching dial-peer 1 for the inbound leg.

You still need an inbound pattern match for the dialpeer to work.

Karl

I will try this and let you know - any thoughts on the strange codec behaviour?

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: