Calls between two pbxs connected to a call manager not working

Answered Question
May 8th, 2012

Hi

I have a bit of a complexed design.

Call manager 6 is configured as centralised with gateways at mutiple sites. Some sites have extensions of the call managers using voip phones while other sites that already have their pbx connect to the call manager using the router over a t1 pri digital trunk. The gateway is configured using h323 to the call manager.

I am having this issue when calls from one site with a legacy pbx is dialling a number for another legacy pbx the user is getting the prompt that "call cant be completed". The route patterns is correct and calls can be made from the legacy pbx to sites with extensions off the call manager.

Will this be a codec issue? I am seeing the digits coming across from the legacy pbx to gateway and they are correct. The only thing is that this set of digits were translated since the user couldnt send digits according to a standard.Looking at the debugs the correct digits are being sent to call manager.

In my case the user is doing the following

user calling number (55221300)-->legacy pbx (calling number 5221300)-->t1 pri-->site A router-->translated to 85221300-->call manager-->route pattern-->SiteB router (1300)-->customer pbx-->phone(1300) rings.

If the user dials an extension of the call manager the calls is successful

user calling number (55202900)-->legacy pbx (calling number  5202900)-->t1 pri-->site A router-->translated to 85202900-->call manager-->translation pattern 5202900-->voip phone rings.

Calls to the site legacy pbx are successful from a voip phone, i still have to verify from site B.

Any thoughts.

I have this problem too.
0 votes
Correct Answer by marmugam about 1 year 11 months ago

Hi rramlal,

You are right about the number which is passed to CCM, it is indeed "85221300"

// From the setup.

05/09/2012 13:30:25.602 CCM|In  Message -- H225SetupMsg -- Protocol= H225Protocol|

05/09/2012 13:30:25.602 CCM|Ie - H225BearerCapabilityIe -- IEData= 04 03 80 90 A3 |

05/09/2012 13:30:25.602 CCM|Ie - H225CallingPartyIe -- IEData= 6C 06 09 80 32 31 36 32 |

05/09/2012 13:30:25.602 CCM|Ie - Q931CalledPartyIe -- IEData= 70 09 80 38 35 32 32 31 33 30 30 |

// But during DA the 8 is stripped, and rest of the digits are sent. It cannot be any translation-pattern issue, as in the setup, we do see the correct digits and it didnt even pass the Digit analysis results. So GW setting is changing it. Only place I can think of is "significant digits".

05/09/2012 13:30:25.611 CCM|H225Cdpc::getDefCcSetupInd Overlapflag 1 sendingComplete 152|

05/09/2012 13:30:25.611 CCM|H225Cdpc - before parsing IVRDN. cdpn=5221300 cgpn=2162 rdn=|

05/09/2012 13:30:25.612 CCM|Cdcc - (0000820) - storeDchanCrp - secure capability on side 0 is (1,0)|

05/09/2012 13:30:25.612 CCM|Cdcc::preliminaryProcessCcSetupInd: precLvl=5|

05/09/2012 13:30:25.612 CCM|Digit Analysis: wait_DaReq: Matching Legacy Numeric, digits=5221300|

05/09/2012 13:30:25.613 CCM|Digit analysis: wait_DaReq - cepn=[] BlockFlag=[1]|<CLID::GoRTTCluster>

05/09/2012 13:30:25.613 CCM|Digit Analysis: getDaRes - voiceMailCallingSearchSpace=[]|

// I am suspecting the below reason, I think you have significant digits misconfigured. Can you change it "all". Save the configuration, and reset the gateway and test the call. Make sure to have Partition of RP 85221300 associated to Incoming CSS of H323 GW.


In the Device--Gateway(h323)----> Call Routing Information - Inbound Calls---->Significant digits

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (1 ratings)
minkdennis Tue, 05/08/2012 - 21:10

Mate,

that is quite a setup. have you verified connectivity between site A and site B gateways?

I f you call from site A to site B, you are saying site A GW does send digits on to CUCM,   after that are you seeing a call being attempted inbound on the Site B GW (debugs)? Also I would set up a dialpeer on site A GW with a single number pattern

55202900 pointing to site B gateway, and see if the call gets established without the CUCM in the equation. 

I would be worth checking your codec settings on your dial peers as well as your region settings to to see if all match up or if transcoders are required. 

marmugam Tue, 05/08/2012 - 21:26

Hi,

++ Assuming H323 is used for signalling  between both the PBX with CCM.

++ The fact that same number works for CCM registered phone leaves the Side A out of the problem.

++ Make sure to have the partition of  Route Pattern(85221300)  in the incoming css of Side A h323 GW.

++ DNA also will help to isolate the CSS/Partition issue.

++ If it is intact, quickly turn on "debug isdn q931" in Side B router, and see if the setup is sent to PBX.

++ If it is there, then see who is releasing the call. And get the below debugs.

++ If you dont see anything in isdn q931 debugs, then enable "debug h225 asn1/q931" to see  if it is making to the Side B Router. If it is there,  then turn on the following debugs:-

### debug h225 asn1

### debug h245 asn1

### debug cch323 all

### debug voip ccapi inout

### debug isdn q931

++ If you dont see any h225 setup, go back to CCM and check Css/parition for any misconfiguration. And make sure to configure H323 GW for SIde B in CCM. If things look ok,  then Detailed CCM traces will quickly isolate the problem. Please do capture it from all the nodes and upload here.

HTH,

Murali

rramlal@fj-icl.com Wed, 05/09/2012 - 11:14

I ran both debugs below and didnt received any logs at site b. User  is still getting the message that the number could not be dialed as  specified.

debug isdn q931

debug h225 asn1/q931

I ran the traces on call manager and i have uploaded. Please advise if you are able to see any issues.

Attachment: 
marmugam Wed, 05/09/2012 - 12:59

Hi,

// Received H225 Setup

097863485| 2012/05/09 13:30:50.658| 001| SdlSig    | H225Setup                             | restart0                      | H225D(1,100,159,5)              | H225Handler(1,100,158,1)        | (1,100,158,1).1-(*:10.109.0.5)          | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]          CES=0          SAPI=0          DSL=0          IEP=0          PID=(100,1,7,449479)

097863486| 2012/05/09 13:30:50.658| 001| Created   |                                       |                               | H225Cdpc(1,100,160,228)         | H225D(1,100,159,5)              |                                         | NumOfCurrentInstances: 1

097863487| 2012/05/09 13:30:50.658| 001| SdlSig    | H225Setup                             | null0                         | H225Cdpc(1,100,160,228)         | H225D(1,100,159,5)              | (1,100,158,1).1-(*:10.109.0.5)          | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]          CES=0          SAPI=0          DSL=0          IEP=0          PID=(100,1,7,449479)

// AFter Digit analysis, and ccm is unable to complete the digit analysis, and not returning any Intecept where it can route the call. Block flag set.

097863500| 2012/05/09 13:30:50.659| 001| SdlSig    | CcRegisterPartyA                      | wait                          | Cc(1,100,176,1)                 | H225Cdpc(1,100,160,228)         | (1,100,158,1).1-(*:10.109.0.5)          | [R:NP - HP: 0, NP: 1, LP: 0, VLP: 0, LZP: 0 DBP: 0]CI=25431354 CI.branch=0  CSS=c8e1d0d0-561f-409d-f83b-79413761d90b cssIns=0 aarCSS= aarDev=1 FQDN=pi=0si1 CallRef=20 OLC=1 Name=locale: 1 Name:  UnicodeName:  pi: 0 encodeType=10 ConnType=3 XferMode=  ConnTime=2 nwLoc=OnNet ta.ip=0 ta.port=0 region=REG-M09 capCount=0 devType=7 mixerCId=0 mediaReq=0 portToPort.loc=14 MOH.MRGL=MRG-SOFTWARE:MRG-DC1:ocs_mrg MOH.userHoldID=0 MOH.netHoldID=0 MOH.supp=0 devName=10.109.0.5 ctiActive=0 ctiFarEndDev=2 ctiCCMId=1 devCepn= activeCaps=0 VideoCall=0 VideoCap=0 dataCap=0 devCap=0 CryptoCapCount=0 secure=0 loginId= UnicodeName:  retriedVideo=0FromTag=ToTag=CallId= UAPortFlag=0 wantDTMFRecep=1 provOOB=0 supp DTMF=1 DTMF Cfg=1 DTMF PT=0 DTMF reqMed=1 isPrefAltScript=0 audioPtyId=0 doNotAppendLineCSS=0 flushCapIns=0ccBearCap.l=0ccBearCap.itc=0ccBearCap.itr=0hasLocationCACInfo =0 lineId.directoryNumber=pi=0si1 lineId.partition=

097863501| 2012/05/09 13:30:50.659| 001| Created   |                                       |                               | Cdcc(1,100,175,821)             | Cc(1,100,176,1)                 |                                         | NumOfCurrentInstances: 2

097863502| 2012/05/09 13:30:50.660| 001| SdlSig    | CcSetupInd                            | wait                          | Cc(1,100,176,1)                 | H225Cdpc(1,100,160,228)         | (1,100,158,1).1-(*:10.109.0.5)          | [R:NP - HP: 0, NP: 1, LP: 0, VLP: 0, LZP: 0 DBP: 0]CI=25431354 CI.branch=0  pli.plid=65 pli.l=1 pli.pl=5FDataType=0opId=0ssType=0invokeId=0resultExp=0 pi.piid=0 pi.l=0 pi2.piid=30 pi2.l=0 pi3.piid=30 pi3.l=0 cgPart= cgPat= AAR=tn=0npi=9nd=2162pi=1si0 cgpnVM= cgpnVMCSS= cgpnVMPNum= DD=pi=0si1 cdPart= cdPat= cdpn=tn=0npi=0nd=5221300pi=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=1 devType=7 devCap=50273240 bc.l=3 bc.itr=1 bc.itc=0 bc.trm=0 maxForwards=70 featurePriority=1 nonTargetPolicy=0 linkedCi=0 IWFDI=0mTransitCounterInfo.isPresent= 0mTransitCounterInfo.transCount= 0

097863503| 2012/05/09 13:30:50.660| 001| SdlSig    | CcRegisterPartyA                      | tcc_idle0                     | Cdcc(1,100,175,821)             | Cc(1,100,176,1)                 | (1,100,158,1).1-(*:10.109.0.5)          | [R:NP - HP: 0, NP: 1, LP: 0, VLP: 0, LZP: 0 DBP: 0]CI=25431354 CI.branch=0  CSS=c8e1d0d0-561f-409d-f83b-79413761d90b cssIns=0 aarCSS= aarDev=1 FQDN=pi=0si1 CallRef=20 OLC=1 Name=locale: 1 Name:  UnicodeName:  pi: 0 encodeType=10 ConnType=3 XferMode=  ConnTime=2 nwLoc=OnNet ta.ip=0 ta.port=0 region=REG-M09 capCount=0 devType=7 mixerCId=0 mediaReq=0 portToPort.loc=14 MOH.MRGL=MRG-SOFTWARE:MRG-DC1:ocs_mrg MOH.userHoldID=0 MOH.netHoldID=0 MOH.supp=0 devName=10.109.0.5 ctiActive=0 ctiFarEndDev=2 ctiCCMId=1 devCepn= activeCaps=0 VideoCall=0 VideoCap=0 dataCap=0 devCap=0 CryptoCapCount=0 secure=0 loginId= UnicodeName:  retriedVideo=0FromTag=ToTag=CallId= UAPortFlag=0 wantDTMFRecep=1 provOOB=0 supp DTMF=1 DTMF Cfg=1 DTMF PT=0 DTMF reqMed=1 isPrefAltScript=0 audioPtyId=0 doNotAppendLineCSS=0 flushCapIns=0ccBearCap.l=0ccBearCap.itc=0ccBearCap.itr=0hasLocationCACInfo =0 lineId.directoryNumber=pi=0si1 lineId.partition=

097863504| 2012/05/09 13:30:50.660| 001| SdlSig    | CcSetupInd                            | tcc_idle0                     | Cdcc(1,100,175,821)             | Cc(1,100,176,1)                 | (1,100,158,1).1-(*:10.109.0.5)          | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]CI=25431354 CI.branch=0  pli.plid=65 pli.l=1 pli.pl=5FDataType=0opId=0ssType=0invokeId=0resultExp=0 pi.piid=0 pi.l=0 pi2.piid=30 pi2.l=0 pi3.piid=30 pi3.l=0 cgPart= cgPat= AAR=tn=0npi=9nd=2162pi=1si0 cgpnVM= cgpnVMCSS= cgpnVMPNum= DD=pi=0si1 cdPart= cdPat= cdpn=tn=0npi=0nd=5221300pi=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=1 devType=7 devCap=50273240 bc.l=3 bc.itr=1 bc.itc=0 bc.trm=0 maxForwards=70 featurePriority=1 nonTargetPolicy=0 linkedCi=0 IWFDI=0mTransitCounterInfo.isPresent= 0mTransitCounterInfo.transCount= 0

097863505| 2012/05/09 13:30:50.660| 001| Created   |                                       |                               | MatrixControl(1,100,143,826)    | Cdcc(1,100,175,821)             |                                         | NumOfCurrentInstances: 1

097863506| 2012/05/09 13:30:50.660| 001| SdlSig    | AddPartyReq                           | await_command                 | MatrixControl(1,100,143,826)    | Cdcc(1,100,175,821)             | (1,100,158,1).1-(*:10.109.0.5)          | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]

097863507| 2012/05/09 13:30:50.660| 001| SdlSig    | AddRes                                | tcc0_await_setup_da           | Cdcc(1,100,175,821)             | MatrixControl(1,100,143,826)    | (1,100,158,1).1-(*:10.109.0.5)          | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]

097863508| 2012/05/09 13:30:50.660| 001| SdlSig    | DaReq                                 | wait                          | Da(1,100,170,1)                 | Cdcc(1,100,175,821)             | (1,100,158,1).1-(*:10.109.0.5)          | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0] CI=25431354 Fqdn=pi=0si1 Cgpn=tn=0npi=9nd=2162pi=1si0 DialedNum=tn=0npi=0nd=5221300pi=0si1 requestID=0 DigitAnalysisComplexity=0

097863509| 2012/05/09 13:30:50.661| 001| SdlSig    | DaRes                                 | setup_da                      | Cdcc(1,100,175,821)             | Da(1,100,170,1)                 | (1,100,158,1).1-(*:10.109.0.5)          | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]CI=25431354 Block NoPotentialMatchesExist OnNetrequestID =0

// So call is getting disconnected and Annuniciatot is engagged to play the message "call cannot be completed as dialed".

097863510| 2012/05/09 13:30:50.661| 001| SdlSig    | CcDisconnReq                          | restart0                      | H225D(1,100,159,5)              | Cdcc(1,100,175,821)             | (1,100,158,1).1-(*:10.109.0.5)          | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]CI=25431354 CI.branch=0  clearType=0 c.l=1 c.cid=8 c.cs=0 c.lc=0 c.r=0 cv=1FDataType=0opId=0ssType=0invokeId=0resultExp=0 OnBehalf=Device rfr=0 rdDestPart= rdDestPatt= rdDestCdpn=pi=0si1 unModRDDestCdpn=pi=0si1 redDestName=locale: 1 Name:  UnicodeName:  pi: 0

097863511| 2012/05/09 13:30:50.661| 001| SdlSig    | CcDisconnReq                          | call_initiated1               | H225Cdpc(1,100,160,228)         | H225D(1,100,159,5)              | (1,100,158,1).1-(*:10.109.0.5)          | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]CI=25431354 CI.branch=0  clearType=0 c.l=1 c.cid=8 c.cs=0 c.lc=0 c.r=0 cv=1FDataType=0opId=0ssType=0invokeId=0resultExp=0 OnBehalf=Device rfr=0 rdDestPart= rdDestPatt= rdDestCdpn=pi=0si1 unModRDDestCdpn=pi=0si1 redDestName=locale: 1 Name:  UnicodeName:  pi: 0

097863512| 2012/05/09 13:30:50.662| 001| SdlSig    | SsInsertMediaReq                      | wait                          | Cc(1,100,176,1)                 | H225Cdpc(1,100,160,228)         | (1,100,158,1).1-(*:10.109.0.5)          | [R:NP - HP: 0, NP: 1, LP: 0, VLP: 0, LZP: 0 DBP: 0] SsType= 0 SsKey= 0 SsNode= 1 SsParty= 25431354 AnnList.locale =1 AnnList.tone121 EndOfAnnAck1 MediaResourceType7annPlayMode1

// Make sure you have a RP for this number 5221300, assign it to the partition of Incoming css of Side B H323 GW.

rramlal@fj-icl.com Wed, 05/09/2012 - 18:07

Thanks for the response and all the assistance thus far

The strange thing is that the router is forwarding 85221300 so i am wondering why the call manager is seeing only 5221300. The user at site A is dialling (55221300), the pbx is only sending 5221300 to the router. In order to match the RP to site B which is (85221300), a translation pattern was used on the dial-peer to add 8 to seven digits coming into the router. From the debugs 85221300 is being sent to the call manager but the call manager is only seeing seven digits. The significant digits on the h323 gatway for this site is set to 8.

Would it be possible for a translation pattern cause this? I have attached a dial number analyser results and this matches the correct pattern once the eight digits are coming through.

I have attached also the running configs and debug ccapi voip inout when 2162 (site A) calls 85221300. Is the translation rule working as it should be?

Paolo Bevilacqua Wed, 05/09/2012 - 23:15

Since you're using H.323, I'd recommend you configure the call routing for PBX-to-PBX calls to be direct without going to the CM at all.

Correct Answer
marmugam Sat, 05/12/2012 - 16:51

Hi rramlal,

You are right about the number which is passed to CCM, it is indeed "85221300"

// From the setup.

05/09/2012 13:30:25.602 CCM|In  Message -- H225SetupMsg -- Protocol= H225Protocol|

05/09/2012 13:30:25.602 CCM|Ie - H225BearerCapabilityIe -- IEData= 04 03 80 90 A3 |

05/09/2012 13:30:25.602 CCM|Ie - H225CallingPartyIe -- IEData= 6C 06 09 80 32 31 36 32 |

05/09/2012 13:30:25.602 CCM|Ie - Q931CalledPartyIe -- IEData= 70 09 80 38 35 32 32 31 33 30 30 |

// But during DA the 8 is stripped, and rest of the digits are sent. It cannot be any translation-pattern issue, as in the setup, we do see the correct digits and it didnt even pass the Digit analysis results. So GW setting is changing it. Only place I can think of is "significant digits".

05/09/2012 13:30:25.611 CCM|H225Cdpc::getDefCcSetupInd Overlapflag 1 sendingComplete 152|

05/09/2012 13:30:25.611 CCM|H225Cdpc - before parsing IVRDN. cdpn=5221300 cgpn=2162 rdn=|

05/09/2012 13:30:25.612 CCM|Cdcc - (0000820) - storeDchanCrp - secure capability on side 0 is (1,0)|

05/09/2012 13:30:25.612 CCM|Cdcc::preliminaryProcessCcSetupInd: precLvl=5|

05/09/2012 13:30:25.612 CCM|Digit Analysis: wait_DaReq: Matching Legacy Numeric, digits=5221300|

05/09/2012 13:30:25.613 CCM|Digit analysis: wait_DaReq - cepn=[] BlockFlag=[1]|<CLID::GoRTTCluster>

05/09/2012 13:30:25.613 CCM|Digit Analysis: getDaRes - voiceMailCallingSearchSpace=[]|

// I am suspecting the below reason, I think you have significant digits misconfigured. Can you change it "all". Save the configuration, and reset the gateway and test the call. Make sure to have Partition of RP 85221300 associated to Incoming CSS of H323 GW.


In the Device--Gateway(h323)----> Call Routing Information - Inbound Calls---->Significant digits

Actions

Login or Register to take actions

This Discussion

Posted May 8, 2012 at 8:15 PM
Stats:
Replies:7 Avg. Rating:5
Views:822 Votes:0
Shares:0

Related Content

Discussions Leaderboard

Rank Username Points
1 21,026
2 15,047
3 10,314
4 7,999
5 4,856
Rank Username Points
120
90
75
67
51