Incoming call via ISDN PRI to a CMM Module

Unanswered Question
Oct 22nd, 2008

I'm getting this message when doing a 'debug isdn q931' for an imcoming call via ISDN PRI to a CMM module. The caller end is hearing a "you've reached a number that is no longer in service" message. Any ideas?:

Oct 22 19:40:14.481: ISDN Se1/0:23 Q931: SETUP pd = 8 callref = 0x143E

Bearer Capability i = 0x8090A2

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98381

Exclusive, Channel 1

Facility i = 0x9F8B0100A10F02015F06072A8648CE1500040A0100

Protocol Profile = Networking Extensions

0xA10F02015F06072A8648CE1500040A0100

Component = Invoke component

Invoke Id = 95

Operation = InformationFollowing (calling_name)

Name information in subsequent FACILITY message

Progress Ind i = 0x8283 - Origination address is non-ISDN

Calling Party Number i = 0x2183, '808532XXXX' (number omitted)

Plan:ISDN, Type:National

Called Party Number i = 0xC1, '544XXXX' (number omitted)

Plan:ISDN, Type:Subscriber(local)

Oct 22 19:40:14.481: ISDN Se1/0:23 Q921: User TX -> RR sapi=0 tei=0 nr=37

Oct 22 19:40:14.485: ISDN Se1/0:23 Q921: User TX -> INFO sapi=0 tei=0, ns=34 nr=37

Oct 22 19:40:14.485: ISDN Se1/0:23 Q931: RELEASE_COMP pd = 8 callref = 0x943E

Cause i = 0x8081 - Unallocated/unassigned number

Oct 22 19:40:14.497: ISDN Se1/0:23 Q921: User RX <- RR sapi=0 tei=0 nr=35

Oct 22 19:40:23.373: ISDN Se1/1:23 Q921: User TX -> RRp sapi=0 tei=0 nr=8

Oct 22 19:40:23.381: ISDN Se1/1:23 Q921: User RX <- RRf sapi=0 tei=0 nr=8

Oct 22 19:40:44.509: ISDN Se1/0:23 Q921: User TX -> RRp sapi=0 tei=0 nr=37

Oct 22 19:40:44.517: ISDN Se1/0:23 Q921: User RX <- RRf sapi=0 tei=0 nr=35

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
Jaime Valencia Wed, 10/22/2008 - 12:10

you're telling the telco that the number they're dialing is not on your server.

that's why you send the Cause i = 0x8081 - Unallocated/unassigned number

make sure you do the proper routing to add/remove digits in order to reach the right called party

ie you receive 10 digits but your DN is only 4, strip 6 digits to match that.

HTH

java

if this helps, please rate

morioka Wed, 10/22/2008 - 12:16

Thanks. What's the proper procedure to strip digits? The telco is supposed to be sending 7 digits and I have the significant digits set to "7" in the inbound calls of the gateway.

morioka Wed, 10/22/2008 - 12:18

Also, I set up a translation pattern for 54459XX to 59XX.

morioka Wed, 10/22/2008 - 12:53

What about this cause code?

Cause i = 0x8281 - Unallocated/unassigned number

thanks.

CHRIS CHARLEBOIS Wed, 10/22/2008 - 13:02

Does the gateway's CSS include the partition in which you created this translation pattern?

The ISDN error isn't the problem, I think. I beleive that your CallManager cannot route that call internally, which is why it is telling the gateway to teminiate with the ISDN error that you are seeing. Can you pull the CCM traces?

morioka Wed, 10/22/2008 - 13:31

Here's a CM trace from the RTMT:

It's a call from 808532XXXX to 544XXXX

CcRegisterPartyA | tcc_idle0 | Cdcc(1,100,175,1151) | Cc(1,100,176,1) | (1,100,133,1).66093-(*:10.75.82.11) | [R:NP - HP: 0, NP: 1, LP: 0, VLP: 0, LZP: 0 DBP: 0]CI=23067621 CI.branch=0 CSS= cssIns=0 aarCSS= aarDev=1 FQDN=pi=0si1 CallRef=6498 OLC=0 Name=locale: 1 Name: UnicodeName: pi: 0 encodeType=10 ConnType=3 XferMode= ConnTime=0 nwLoc=Unknown ta.ip=0 ta.port=0 region=Operations_Center capCount=5 devType=7 mixerCId=0 mediaReq=0 portToPort.loc=1 MOH.MRGL=CPB_MRG MOH.userHoldID=0 MOH.netHoldID=0 MOH.supp=0 devName=S1/[email protected] ctiActive=0 ctiFarEndDev=2 ctiCCMId=1 devCepn= activeCaps=0 VideoCall=0 VideoCap=0 dataCap=2 devCap=0 CryptoCapCount=0 secure=1 loginId= UnicodeName: retriedVideo=0FromTag=ToTag=CallId= UAPortFlag=0 wantDTMFRecep=1 provOOB=0 supp DTMF=1 DTMF Cfg=1 DTMF PT=0 DTMF reqMed=0 isPrefAltScript=0 audioPtyId=3 doNotAppendLineCSS=0 flushCapIns=0ccBearCap.l=0ccBearCap.itc=0ccBearCap.itr=0

002742567| 2008/10/22 11:19:27.181| 001| SdlSig | CcSetupInd | tcc_idle0 | Cdcc(1,100,175,1151) | Cc(1,100,176,1) | (1,100,133,1).66093-(*:10.75.82.11) | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]CI=23067621 CI.branch=0 pli.plid=65 pli.l=1 pli.pl=5FDataType=0opId=0invokeId=0resultExp=0 pi.piid=30 pi.l=2 pi2.piid=30 pi2.l=0 pi3.piid=30 pi3.l=0 cgPart= cgPat= AAR=tn=2npi=1nd=808532XXXXpi=1si3 cgpnVM= cgpnVMCSS= cgpnVMPNum= DD=pi=0si1 cdPart= cdPat= cdpn=tn=3npi=1nd=544XXXXpi=0si1 cdpnVM= cdpnVMCSS= cdpnVMPNum= itrPart= itrPat= LRPart= LRPat= LR=pi=0si1 LRVM= LRVMCSS= LRVMPNum= LRFR=0 oPart= oPat= oCpdn=pi=0si1 oCdpnVM= oCdpnVMCSS= oCdpnVMPNum= oRFR=0 ts= posMatches= rdn.l=0 ta.ip=0 ta.port=0 OLF=0 devType=7 devCap=41925720 bc.l=0 bc.itr=1 bc.itc=0 bc.trm=0 maxForwards=70 featurePriority=1 nonTargetPolicy=0 linkedCi=0

002742568| 2008/10/22 11:19:27.181| 001| Created | | | MatrixControl(1,100,143,1165) | Cdcc(1,100,175,1151) | | NumOfCurrentInstances: 2

002742569| 2008/10/22 11:19:27.181| 001| SdlSig | AddPartyReq | await_command | MatrixControl(1,100,143,1165) | Cdcc(1,100,175,1151) | (1,100,133,1).66093-(*:10.75.82.11) | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]

002742570| 2008/10/22 11:19:27.181| 001| SdlSig | AddRes | tcc0_await_setup_da | Cdcc(1,100,175,1151) | MatrixControl(1,100,143,1165) | (1,100,133,1).66093-(*:10.75.82.11) | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]

002742571| 2008/10/22 11:19:27.181| 001| SdlSig | DaReq | wait | Da(1,100,170,1) | Cdcc(1,100,175,1151) | (1,100,133,1).66093-(*:10.75.82.11) | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0] CI=23067621 Fqdn=pi=0si1 Cgpn=tn=2npi=1nd=808532XXXXpi=1si3 DialedNum=tn=3npi=1nd=544XXXXpi=0si1 requestID=0 DigitAnalysisComplexity=0

002742572| 2008/10/22 11:19:27.181| 001| SdlSig | DaRes | setup_da | Cdcc(1,100,175,1151) | Da(1,100,170,1) | (1,100,133,1).66093-(*:10.75.82.11) | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]CI=23067621 Block NoPotentialMatchesExist OnNetrequestID =0

002742573| 2008/10/22 11:19:27.181| 001| SdlSig | CcDisconnReq | restart0 |

Jaime Valencia Wed, 10/22/2008 - 14:11

1st of all we would need to know how many digits your extensions are. also if this is MGCP or H323

the proper way to take strip digits is configure the significant digits on the GW config.

you may also use translation patterns but most usually it's done as close as possible to the GW or in the GW. also make sure the inbound CSS is correctly configured because CUCM is not able to reach whatever number you're trying to call.

just look at the trace Block NoPotentialMatchesExist

the issue indeed seems to be routing on CUCM

HTH

java

if this helps, please rate

morioka Wed, 10/22/2008 - 14:18

thanks for the reply. this is a MGCP gateway and the significant digits are set to 4 to match the extension length which is also 4. The telco is sending 7-digits. The gateway CSS is able to reach the correct partitions and this was verified with the dialed digit analyzer.

Jaime Valencia Wed, 10/22/2008 - 15:59

ok, if still no avail an SDI trace would show us exactly what's going on and what's matching.

check your unassigned DNs to make sure there is nothing there

HTH

java

if this helps, please rate

morioka Fri, 10/24/2008 - 13:04

Thanks for all of the help. A restart of the CMM module fixed the problem.

Actions

This Discussion