PRI H323 gateway inbound calls not working

Unanswered Question
Jul 10th, 2009
User Badges:

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



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
CHRIS CHARLEBOIS Fri, 07/10/2009 - 12:37
User Badges:
  • Silver, 250 points or more

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.

appserv Fri, 07/10/2009 - 12:43
User Badges:

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

CHRIS CHARLEBOIS Fri, 07/10/2009 - 12:48
User Badges:
  • Silver, 250 points or more

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.

appserv Fri, 07/10/2009 - 13:07
User Badges:

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?!



Attachment: 
CHRIS CHARLEBOIS Fri, 07/10/2009 - 14:08
User Badges:
  • Silver, 250 points or more

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.

appserv Fri, 07/10/2009 - 16:40
User Badges:

This is a sh call active voice brief



: ms. + pid:

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

IP : rtt:ms pl:/ms lost://

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 :,,,,, endpt: /

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?

appserv Fri, 07/10/2009 - 20:45
User Badges:

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


Any suggestions appreciated

CHRIS CHARLEBOIS Mon, 07/13/2009 - 05:56
User Badges:
  • Silver, 250 points or more

"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 Mon, 07/13/2009 - 06:05
User Badges:

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.

CHRIS CHARLEBOIS Mon, 07/13/2009 - 06:36
User Badges:
  • Silver, 250 points or more

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.

karldbrooks Mon, 07/13/2009 - 06:46
User Badges:

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


Karl

appserv Mon, 07/13/2009 - 14:36
User Badges:

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

Nicholas Matthews Mon, 07/13/2009 - 19:41
User Badges:
  • Red, 2250 points or more

ccapi isn't going to give you the details you need for this.


debug h225 asn1

debug h245 asn1

debug ip tcp transactions



These will allow you to see if cucm is communicating back to the gateway. My guess is that it is, because normally if there is no response you'll see cause=38 for network out of order or cause=47 resources unavailable.


Sounds like an h323 issue possibly on CUCM. Hard to tell.


-nick

appserv Sat, 07/18/2009 - 11:53
User Badges:

I've done a debug of the follwoing


debug h225 asn1

debug h245 asn1

debug ip tcp transactions


and its attached. just having a read through it now



Attachment: 
appserv Sat, 07/18/2009 - 11:48
User Badges:

Modiying the POTS dial-peer 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


had no effect.


thanks

a.gooding Sun, 07/19/2009 - 17:59
User Badges:
  • Bronze, 100 points or more

not sure if this may help but id normally not apply the translations to the Voice port itself and apply to the dial-peer instead.


Id say remove the profiles on the Voice port and put the incoming called number as the PSTN pilot number or pattern coming in into your dial peer and then apply the tanslation profile incoming to match the rule that you need the call to be terminated against.



Actions

This Discussion