Incoming call via ISDN PRI to a CMM Module

Unanswered Question
Oct 22nd, 2008
User Badges:

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



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
Jaime Valencia Wed, 10/22/2008 - 12:10
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    2011

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
User Badges:

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
User Badges:

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

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

What about this cause code?


Cause i = 0x8281 - Unallocated/unassigned number


thanks.

CHRIS CHARLEBOIS Wed, 10/22/2008 - 13:02
User Badges:
  • Silver, 250 points or more

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
User Badges:

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
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    2011

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
User Badges:

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
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    2011

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
User Badges:

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

Actions

This Discussion