07-10-2009 12:14 PM - edited 03-15-2019 06:55 PM
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
07-10-2009 12:37 PM
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.
07-10-2009 12:43 PM
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
07-10-2009 12:48 PM
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.
07-10-2009 01:07 PM
07-10-2009 02:08 PM
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.
07-10-2009 02:21 PM
07-10-2009 04:40 PM
This is a sh call active voice brief
dur hh:mm:ss tx:
IP
delay:
media inactive detected:
long duration call detected:
MODEMPASS
last
FR
ATM
Tele
MODEMRELAY info:
speeds(bps): local
Proxy
bw:
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?
07-10-2009 08:45 PM
If i convert this gateway to MGCP all is fine. However i need H323 for Unity faxing.
Any suggestions appreciated
07-12-2009 08:46 PM
Not sure if bumps are allowed....
07-13-2009 05:56 AM
"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.
07-13-2009 06:05 AM
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.
07-13-2009 06:36 AM
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.
07-13-2009 06:46 AM
You still need an inbound pattern match for the dialpeer to work.
Karl
07-13-2009 02:36 PM
I will try this and let you know - any thoughts on the strange codec behaviour?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide