09-01-2021 07:35 AM
I have single number reach setup on CUCM version 12.5. If I call my four digit extension from another internal phone both the desk phone and my cell phone rings. However, if my desk phone's DID is called from an external number, only my desk phone rings.
Solved! Go to Solution.
09-03-2021 10:46 AM
I looked at the trace file you sent and here is what I think:
Maren
-------------------------------------
These lines say that CUCM recognizes the RDP as a target for the incoming call
27501212.001 |14:54:59.845 |AppInfo |LineCdpc(43095): -dispatchToAllDevices-, sigName=CcSetupReq, device=SEP009E1EAD0A95 27501212.002 |14:54:59.845 |AppInfo |LineCdpc(43095): -dispatchToAllDevices-, sigName=CcSetupReq, device=81434xxx9515_krutledge_RDP
The RDP is identified as an off-net device
27501215.002 |14:54:59.846 |AppInfo |SIPStationD(424567) - The new call has ccSetupReq.isOffNetDevice=1 Remembering this in the call entry table.
CUCM Determines that no barriers (permissions, availability, etc.) exist preventing the call to the off net number:
27501216.007 |14:54:59.846 |AppInfo |SNRD::wait_CcSetupReq (0000037) Caller[434xxx2381] is allowed to call [81434xxx9515]
The CUCM has done permissions checks and checks for things like CFDAll/CTI/etc and declared that the call can go to the RDP
Then CUCM creates the internal anchor for the call that is to go out to the RDP
27501217.003 |14:54:59.846 |AppInfo |CMUtility isCTIRemoteDestinationActive: For remdest [81434xxx9515], isCTIRDAssociated=0, isRDDActive=0, isRDPAssociated=1 27501217.004 |14:54:59.846 |AppInfo |DbMobility:initRemDest: device pkid [05512005-4085-711f-4373-9f9f461ca553], profile pkid [dadcdef4-ca8b-eef4-5757-8dd662c31221], isDualmode [0], isCumc [0], isSmartPhone [0], isSiplineDevice [0] 27501217.005 |14:54:59.846 |AppInfo |DbMobilityRemDestTable:initRemDest: initialized a remdest [81434xxx9515] 27501217.006 |14:54:59.846 |AppInfo |DbMobility - RemDest dump: cnumber = 81434xxx9515, devicePkid = 05512005-4085-711f-4373-9f9f461ca553, remDestProfilePkidStr = dadcdef4-ca8b-eef4-5757-8dd662c31221, isMobilePhone = 1, isDualMode = 0, isSmartPhone = 0, isSNREnabled= 1, answerTooSoonTimer = 1500, answerTooLateTimer = 20000, delayBeforeRingingCellTimer = 1500, userId = krutledge, timeZoneIndex = 0, requireThirdPartyRegistration = 0, blockIncomingCallsWhenRoaming = 0, homeNetworkID = , description = krutledge_RD, url = , SNRVMAvoidancePolicy = 0, DvorVMAPolicy = 0 27501217.007 |14:54:59.846 |AppInfo |DbMobilityRemDestTable:initMobilityUser: -- created mobility user 27501217.008 |14:54:59.846 |AppInfo |DbMobility - User dump: userId = krutledge, isIVREnabled = 0, maxDeskPickupWaitTime = 10000, userLocale = 1, userHasSpecificLocale = true 27501217.009 |14:54:59.846 |AppInfo |CellProxy( 1164) - StartTransition - cellNum=81434xxx9515, dn=6720, blended uri=, smart=0, mobile=1, dualmode=0, snrEnabled=1, answer2Soon=1500, answer2Late=20000, callScreenTimer=4000, delayBFRing=1500, rerouteCSS=1c67e757-84c4-4a7d-984b-14944b1edf46, userLocale=1, deskPickup=10000, mDialingPid= (0, 0, 0), is3G=0, associatedUserLocale=1, defaultUserLocale=1, mSnrdFeatureType=0
This section is the digit analysis section where CUCM has picked a Route Pattern to egress the call.
Note that the caller ID is your cell number and is not altered:
27501232.009 |14:54:59.849 |AppInfo |Digit analysis: patternUsage=5 27501232.010 |14:54:59.849 |AppInfo |Digit analysis: match(pi="2", fqcn="", cn="434xxx2381",plv="5", pss="PA_Internal:PA_VoiceMail:MainCampus_Emergency:PA_MainCampus_Local:PA_MainCampus_TollFree:PA_MainCampus_Service:PA_MainCampus_LD", TodFilteredPss="PA_Internal:PA_VoiceMail:MainCampus_Emergency:PA_MainCampus_Local:PA_MainCampus_TollFree:PA_MainCampus_Service:PA_MainCampus_LD", dd="81434xxx9515",dac="0") 27501232.011 |14:54:59.849 |AppInfo |Digit analysis: analysis results 27501232.012 |14:54:59.849 |AppInfo ||PretransformCallingPartyNumber=434xxx2381 |CallingPartyNumber=434xxx2381 |DialingPartition=PA_MainCampus_LD |DialingPattern=8.1[2-9]XX[2-9]XXXXXX |FullyQualifiedCalledPartyNumber=81434xxx9515 <output omitted>
Route List is identified (RL/RG/GW selection is later)
27501235.003 |14:54:59.849 |AppInfo |SMDMSharedData::findLocalDevice - Name=RL_MainCampus1 Key=0ba17960-d719-42c5-ad62-7a05acc0343a isActvie=1 Pid=(1,173,2) found
Selections from the RL/RG/GW selection process...
. . 27501333.003 |14:55:01.356 |AppInfo |RouteList - RouteListName=''RL_MainCampus1'' CallableEndPointName=''0ba17960-d719-42c5-ad62-7a05acc0343a'' routeListEnabled=''1'' . . 27501333.008 |14:55:01.356 |AppInfo |RouteListCdrc - RouteGroup count = 1 27501333.009 |14:55:01.356 |AppInfo |RouteListCdrc - Device count = 2 . . 27501336.000 |14:55:01.356 |SdlSig |DmPidRes |select_facility |RouteListCdrc(1,100,172,9723) |DeviceManager(1,100,53,1) |1,100,251,21.70801^172.16.xxx.27^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] Cepn=1b7ea81b-3e9e-59e1-329b-53ffb04bf797 Id=0 ccmType=7 DeviceName=S0/SU1/DS1-0@<name of mgcp gw>.ialr.org Pid=1,100,109,7,
Process to extend an MGCP-based call to the gateway is initialized:
27501336.005 |14:55:01.356 |AppInfo |RouteListCdrc::executeRouteAction: EXTEND_CALL_TO_CURRENT_MEMBER -- Success 27501337.000 |14:55:01.356 |SdlSig |CcSetupReq |restart0 |MGCPpn9d(1,100,109,7) |RouteListCdrc(1,100,172,9723) |1,100,251,21.70801^172.16.xxx.27^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] CI=22722821 CI.branch=16778380 sBPL.plid=65 sBPL.l=1 sBPL.pl=5 sBPL.msd=0 FDataType=0 opId=0 ssType=0 SsKey=0 invokeId=0 resultExp=F bpda=F pi.piid=0 pi.l=0 pi2.piid=30 pi2.l=0 pi3.piid=30 pi3.l=0 FQCGPN=pi=0si1 preXCgpn=tn=2npi=1ti=1nd=434xxx2381pi=0si3 cgPart= cgPat= cgpn=tn=2npi=1ti=1nd=434xxx2381pi=1si3 cgpnVM= unXCgpn=tn=2npi=1ti=1nd=434xxx2381pi=1si0 cName=locale: 1 Name: HARRIS TIJUANA UnicodeName: pi: 0 DD=tn=0npi=1ti=1nd=6720pi=0si1 origDD=tn=0npi=1ti=1nd=6720pi=0si1 preXCdpn=tn=0npi=0ti=1nd=1434xxx9515pi=0si0 preXTagsList=ACCESS-CODE:SUBSCRIBER preXPosMatchList=8:1434xxx9515 cdPart=1e9957e1-8c99-466d-a85d-9e4604bdd2e2 cdPat=8.1[2-9]XX[2-9]XXXXXX cdpn=tn=0npi=0ti=1nd=1434xxx9515pi=0si0 cdpnVMbox= localPatternUsage=2 connectedPatternUsage=2 itrPart= itrPat= LRPart=c988fa7a-68a7-4832-8295-5e54b1b811ba LRPat=6720 LR=tn=0npi=0ti=1nd=14347666700pi=0si1 LRVM= LRName=locale: 1 Name: Kevin Rutledge UnicodeName: Kevin Rutledge pi: 0 FQOCpdn=ti=1nd=4347666720pi=0si1 fFQLRNum=ti=1nd=14347666700pi=0si1 oPart=c988fa7a-68a7-4832-8295-5e54b1b811ba oPat=6720 oCpdn=tn=0npi=0ti=1nd=14347666700pi=0si1 oCdpnVM= oRFR=335 oName=locale: 1 Name: Kevin Rutledge UnicodeName: Kevin Rutledge pi: 0 ts=SUBSCRIBER posMatches=6720 withTags= withValues= rdn.l=0IpAddrMode=0 ipAddrType=0 ipv4=0.0.0.0:0 region=RE_MainCampus capCount=10 ctiActive=F ctiFarEndDev=2 ctiCCMId=1 cgPtyDev=S0/SU1/DS1-0@<name of mgcp gw>.ialr.org callInst=1 confCallInst=0 OLF=1Supp DTMF=1DTMF Cfg=1DTMF Payload=()isOffNetDev=T bc.l=1 bc.itr=1 bc.itc=0 bc.trm=0 bc.tm=0 maxForwards=70 cgpnMaskedByRedirect=F callingDP=1b1b9eb6-7803-11d3-bdf0-00108302ead1 featCallType=0 callingUserId= UnicodeName: muteEnabled=0 associatedCallCI=0 featurePriority=1 nonTargetPolicy=0 unconsumedDigits= suppressMOH=F numPlanPkid =0b8f62be-3c52-7b58-2a1b-1b50322eb142 networkDomain= bitMask=0 SetupReason=0 routeClass=1 LmSyncAlertingCallType=0 sideACmDeviceType=7 protected=0 ControlProcessType=1 tokens=0 isPresent=F transitCount=0 geolocInfo={geolocPkid=, filterPkid=, geolocVal=, devType=7} locPkid=c23c00f1-1561-4f47-8127-4d3f67ff758c locName=LO_MainCampus deductBW=F fateShareId=StandAloneCluster:22722820 videoTrafficClass=Unspecified oFromAnalogDvc=F bridgeParticipantID= callingUsr= remoteClusterID= isEMCCDevice=F lHPMemCEPN= cHPMemCEPN= isParamSet=FTransparentData=null CanSupportSIPTandN=false TransId=0 AllowBitMask=0x0 UserAgentOrServer= OrigDDName=locale: 1 Name: UnicodeName: pi: 0 mCallerId= mCallerName= TrustRxId=T mIsMultiForkingEnabled=FLatentCaps=null icidVal= icidGenAddr= oioi= tioi= ptParams= receivedPAID= routeHdr= routeCepn= requestURI= routeHeaderURI=pi=0si1 PCVFlag=F originallyHadISUP=F isIMSFinalRoute=F IMSMode=0 SideABibEnabled= 0 isCgpnNonPreemptable=F isCdpnNonPreemptable=F origDP=1b1b9eb6-7803-11d3-bdf0-00108302ead1 lastRedirectingDP=1b1b9eb6-7803-11d3-bdf0-00108302ead1 originalLRG= lastRedirectingLRG= nwLoc=0 rstr= FarEndDeviceName= ReferredByUri= Session-ID: ;remote=1b7ea81b3e9e59e1329b53bd22722820 hdrMOH=0 CAL={v=ffffffff, m=ffffffff, tDev=F, res=F, devType=0} External Presentation Info [ pi=0si1locale: 1 Name: UnicodeName: pi: 0 mIsCallExternal=F ] origPi=0 27501337.001 |14:55:01.356 |AppInfo |MGCPpn9d:restart0_CcSetupReq - S0/SU1/DS1-0@<name of mgcp gw>.ialr.org My Region=RE_MainCampus, Other Side Region=RE_MainCampus 27501337.002 |14:55:01.356 |AppInfo |ViprUtils:isViprAllowed Device =S0/SU1/DS1-0@<name of mgcp gw>.ialr.org UseIMEForOutboundCall=false
.
.
27501337.005 |14:55:01.357 |Created | | |MGCPpn9cuser(1,100,108,19291) |MGCPpn9d(1,100,109,7) | |NumOfCurrentInstances: 3
27501337.006 |14:55:01.357 |AppInfo |MGCPpn9d - initPortInfo: portInfo[22] endpoint=S0/SU1/DS1-0/23@<name of mgcp gw>.ialr.org, ci=22722821, globalCallId=480790
Connection request sent to the MGCP Gateway:
27501357.001 |14:55:01.360 |AppInfo |MGCPHandler send msg SUCCESSFULLY to: 172.16.xxx.27 CRCX 108767 S0/SU1/DS1-0/23@<name of mgcp gw>.ialr.org MGCP 0.1 C: D0000000015ab905000000F500000192 X: 17 L: p:20, a:PCMU, s:off, t:b8 M: recvonly R: D/[0-9ABCD*#] Q: process,loop
Okay from Gateway:
27501361.000 |14:55:01.365 |AppInfo |MGCPHandler received msg from: 172.16.xxx.27 200 108767 OK I: A07B v=0 c=IN IP4 172.16.xxx.27 m=audio 10446 RTP/AVP 0 100 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194
CUCM generates the Q931 message that the MGCP gateway should send over the D-Channel:
27501369.000 |14:55:01.366 |SdlSig |PriNi2Setup |wait |MGCPBhHandler(1,100,89,1) |MGCPpn9cuser(1,100,108,19291) |1,100,251,21.70801^172.16.xxx.27^* |[R:N-H:0,N:2,L:0,V:0,Z:0,D:0] 00000000 00900000 7b090000 ac10701b 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 27501369.001 |14:55:01.366 |AppInfo | 27501369.002 |14:55:01.366 |AppInfo |Out Message -- PriSetupMsg -- Protocol= PriNi2Protocol 27501369.003 |14:55:01.366 |AppInfo |Ie - Ni2BearerCapabilityIe IEData= 04 03 80 90 A2 27501369.004 |14:55:01.366 |AppInfo |Ie - Q931ChannelIdIe IEData= 18 03 A9 83 97 27501369.005 |14:55:01.366 |AppInfo |Ie - Q931DisplayIe IEData= 28 0F 48 41 52 52 49 53 20 54 49 4A 55 41 4E 41 20 27501369.006 |14:55:01.366 |AppInfo |Ie - Q931CallingPartyIe IEData= 6C 0C 21 83 34 33 34 3x 3x 3x 32 33 38 31 27501369.007 |14:55:01.366 |AppInfo |Ie - Q931CalledPartyIe IEData= 70 0C 80 31 34 33 34 3x 3x 3x 39 35 31 35 27501369.008 |14:55:01.366 |AppInfo |MMan_Id= 0. (iep= 0 dsl= 9000 sapi= 0 ces= 0 IpAddr=1b7010ac IpPort=2427) 27501369.009 |14:55:01.366 |AppInfo |IsdnMsgData2= 08 02 01 92 05 04 03 80 90 A2 18 03 A9 83 97 28 0F 48 41 52 52 49 53 20 54 49 4A 55 41 4E 41 20 6C 0C 21 83 34 33 34 34 32 39 32 33 38 31 70 0C 80 31 34 33 34 35 34 37 39 35 31 35 27501369.010 |14:55:01.366 |AppInfo |MGCPBhHandler - Sending BhHdr: 0004 0000 0010 9000 0001 003c
CUCM generates the Q931 message that the MGCP gateway should send over the D-Channel:
27501369.000 |14:55:01.366 |SdlSig |PriNi2Setup |wait |MGCPBhHandler(1,100,89,1) |MGCPpn9cuser(1,100,108,19291) |1,100,251,21.70801^172.16.xxx.27^* |[R:N-H:0,N:2,L:0,V:0,Z:0,D:0] 00000000 00900000 7b090000 ac10701b 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 27501369.001 |14:55:01.366 |AppInfo | 27501369.002 |14:55:01.366 |AppInfo |Out Message -- PriSetupMsg -- Protocol= PriNi2Protocol 27501369.003 |14:55:01.366 |AppInfo |Ie - Ni2BearerCapabilityIe IEData= 04 03 80 90 A2 27501369.004 |14:55:01.366 |AppInfo |Ie - Q931ChannelIdIe IEData= 18 03 A9 83 97 27501369.005 |14:55:01.366 |AppInfo |Ie - Q931DisplayIe IEData= 28 0F 48 41 52 52 49 53 20 54 49 4A 55 41 4E 41 20 27501369.006 |14:55:01.366 |AppInfo |Ie - Q931CallingPartyIe IEData= 6C 0C 21 83 34 33 34 3x 3x 3x 32 33 38 31 27501369.007 |14:55:01.366 |AppInfo |Ie - Q931CalledPartyIe IEData= 70 0C 80 31 34 33 34 3x 3x 3x 39 35 31 35 27501369.008 |14:55:01.366 |AppInfo |MMan_Id= 0. (iep= 0 dsl= 9000 sapi= 0 ces= 0 IpAddr=1b7010ac IpPort=2427) 27501369.009 |14:55:01.366 |AppInfo |IsdnMsgData2= 08 02 01 92 05 04 03 80 90 A2 18 03 A9 83 97 28 0F 48 41 52 52 49 53 20 54 49 4A 55 41 4E 41 20 6C 0C 21 83 34 33 34 34 32 39 32 33 38 31 70 0C 80 31 34 33 34 35 34 37 39 35 31 35 27501369.010 |14:55:01.366 |AppInfo |MGCPBhHandler - Sending BhHdr: 0004 0000 0010 9000 0001 003c
Note the Q931CalledPartyIe and the Q931allingPartyIE line and the way that the numbers are expressed.
The last 10/11 pairs of numbers are a 3+ActualNumber - So it is sending 1-434-xxx-9515 and CLID 434xxx2381
27501369.006 |14:55:01.366 |AppInfo |Ie - Q931CallingPartyIe IEData= 6C 0C 21 83 34 33 34 3x 3x 3x 32 33 38 31
27501369.007 |14:55:01.366 |AppInfo |Ie - Q931CalledPartyIe IEData= 70 0C 80 31 34 33 34 3x 3x 3x 39 35 31 35
So as of right now the call has been outdialed to the PSTN over the PRI. However the call is rejected:
(Note, in particular, the part where it says: "Sending CcRejInd, with the cause code (1)")
27501389.001 |14:55:01.461 |AppInfo |MGCPBhHandler 172.16.xxx.27 - TCP msg available from Device 27501389.002 |14:55:01.461 |AppInfo |MGCPBhHandler - Receiving BhHdr: 0004 0000 0011 9000 0001 0009 27501389.003 |14:55:01.461 |AppInfo | 27501389.004 |14:55:01.461 |AppInfo |In Message -- PriDisconnectMsg -- Protocol= PriNi2Protocol 27501389.005 |14:55:01.461 |AppInfo |Ie - Q931CauseIe -- IEData= 08 02 82 81 27501389.006 |14:55:01.461 |AppInfo |MMan_Id= 0. (iep= 0 dsl= 9000 sapi= 0 ces= 0 IpAddr=1b70xxac IpPort=2427) 27501389.007 |14:55:01.461 |AppInfo |IsdnMsgData1= 08 02 81 92 45 08 02 82 81 27501390.000 |14:55:01.461 |SdlSig |PriNi2Disconn |restart0 |MGCPpn9d(1,100,109,7) |MGCPBhHandler(1,100,89,1) |1,100,251,21.70803^172.16.xxx.27^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] 00000000 00900000 7b090000 ac10701b 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 01000000 27501391.000 |14:55:01.461 |SdlSig |PriNi2Disconn |outgoing_call_proceeding3 |MGCPpn9cuser(1,100,108,19291) |MGCPpn9d(1,100,109,7) |1,100,251,21.70803^172.16.xxx.27^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] 00000000 00900000 7b090000 ac10701b 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 01000000 27501391.001 |14:55:01.461 |AppInfo |SPROC analyzeMsgtransCause MessageTransCause.ms = 0, MessageTransCause.ieid = 0, PriTsp.protocol = 10, MCStatus = 0 27501391.002 |14:55:01.461 |AppInfo |MGCPpn9cuser - sendCcDisconnInd, Q931Cause.cv:1, CcDisconnInd.c.cv:1 27501392.000 |14:55:01.461 |SdlSig |CcDisconnInd |idle |RouteListControl(1,100,173,2) |MGCPpn9cuser(1,100,108,19291) |1,100,251,21.70803^172.16.xxx.27^* |[R:N-H:0,N:1,L:0,V:0,Z:0,D:0] CI=22722821 CI.branch=16778380 c.l=2 c.cid=8 c.cs=0 c.lc=2 c.r=0 cv=1 globalDisconnect=F FDataType=0 opId=0 ssType=0 SsKey=0 invokeId=0 resultExp=F bpda=FTransparentData=null CanSupportSIPTandN=false TransId=0 AllowBitMask=0x0 UserAgentOrServer= OrigDDName=locale: 1 Name: UnicodeName: pi: 0 mCallerId= mCallerName= TrustRxId=T mIsMultiForkingEnabled=F CAL={v=ffffffff, m=ffffffff, tDev=F, res=F, devType=0} CAL={v=fffffff6, m=ffffffff, tDev=F, res=F, devType=0} 27501393.000 |14:55:01.461 |SdlSig |DSetCallPhase |restart0 |MGCPpn9d(1,100,109,7) |MGCPpn9cuser(1,100,108,19291) |1,100,251,21.70803^172.16.xxx.27^* |[R:N-H:0,N:1,L:0,V:0,Z:0,D:0] CallPhase=CALL_CLEARING 27501394.000 |14:55:01.461 |SdlSig |CcDisconnInd |call_proceeding |RouteListCdrc(1,100,172,9723) |RouteListControl(1,100,173,2) |1,100,251,21.70803^172.16.xxx.27^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] CI=22722821 CI.branch=16778380 c.l=2 c.cid=8 c.cs=0 c.lc=2 c.r=0 cv=1 globalDisconnect=F FDataType=0 opId=0 ssType=0 SsKey=0 invokeId=0 resultExp=F bpda=FTransparentData=null CanSupportSIPTandN=false TransId=0 AllowBitMask=0x0 UserAgentOrServer= OrigDDName=locale: 1 Name: UnicodeName: pi: 0 mCallerId= mCallerName= TrustRxId=T mIsMultiForkingEnabled=F CAL={v=ffffffff, m=ffffffff, tDev=F, res=F, devType=0} CAL={v=fffffff6, m=ffffffff, tDev=F, res=F, devType=0} 27501394.001 |14:55:01.461 |AppInfo |RouteListCdrc::checkQ931CauseCode - configuration is empty 27501394.002 |14:55:01.461 |AppInfo |RouteListCdrc::call_proceeding_CcDisconnInd - The call cannot be re-routed, forwarding CcDisconnInd to Cc 27501394.003 |14:55:01.461 |AppInfo |RouteListCdrc::sendCcRejInd - Sending CcRejInd, with the cause code (1), to RouteListControl because all devices are busy/stopped.
CUCM Sends a Delete Connection Request to the MGCP GW
27501407.000 |14:55:01.461 |SdlSig |MGCPDeleteConnection |restart0 |MGCPpn9d(1,100,109,7) |MGCPpn9cuser(1,100,108,19291) |1,100,251,21.70803^172.16.xxx.27^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] - portNum= 23 DLCX 0 27501408.000 |14:55:01.461 |SdlSig |MGCPDeleteConnection |restart0 |MGCPedpc(1,100,104,243) |MGCPpn9d(1,100,109,7) |1,100,251,21.70803^172.16.xxx.27^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] S0/SU1/DS1-0/23@<name of mgcp gw>.ialr.org - portNum= 23 DLCX 0 27501409.000 |14:55:01.461 |SdlSig |MGCPDeleteConnection |wait |MGCPHandler(1,100,90,1) |MGCPedpc(1,100,104,243) |1,100,251,21.70803^172.16.xxx.27^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] S0/SU1/DS1-0/23@<name of mgcp gw>.ialr.org - portNum= 23 DLCX 0 27501409.001 |14:55:01.461 |AppInfo |MGCPHandler send msg SUCCESSFULLY to: 172.16.xxx.27 DLCX 108768 S0/SU1/DS1-0/23@<name of mgcp gw>.ialr.org MGCP 0.1 C: D0000000015ab905000000F500000192 I: A07B X: 17 S:
OK Response from the GW
27501410.000 |14:55:01.465 |AppInfo |MGCPHandler received msg from: 172.16.xxx.27 250 108768 OK P: PS=0, OS=0, PR=0, OR=0, PL=0, JI=0, LA=0
CUCM creates and sends the Q931 release to end the call:
27501419.000 |14:55:01.465 |SdlSig |PriNi2Rel |wait |MGCPBhHandler(1,100,89,1) |MGCPpn9cuser(1,100,108,19291) |1,100,251,21.70803^172.16.xxx.27^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] 00000000 00900000 7b090000 ac10701b 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 01000000 27501419.001 |14:55:01.465 |AppInfo | 27501419.002 |14:55:01.465 |AppInfo |Out Message -- PriReleaseMsg -- Protocol= PriNi2Protocol 27501419.003 |14:55:01.465 |AppInfo |Ie - Q931CauseIe IEData= 08 02 82 93 27501419.004 |14:55:01.465 |AppInfo |MMan_Id= 0. (iep= 0 dsl= 9000 sapi= 0 ces= 0 IpAddr=1b7010ac IpPort=2427) 27501419.005 |14:55:01.465 |AppInfo |IsdnMsgData2= 08 02 01 92 4D 08 02 82 93 27501419.006 |14:55:01.465 |AppInfo |MGCPBhHandler - Sending BhHdr: 0004 0000 0010 9000 0001 0009
Relase complete received from the PRI D-Channel:
27501420.003 |14:55:01.478 |AppInfo | 27501420.004 |14:55:01.478 |AppInfo |In Message -- PriReleaseCompleteMsg -- Protocol= PriNi2Protocol 27501420.005 |14:55:01.478 |AppInfo |MMan_Id= 0. (iep= 0 dsl= 9000 sapi= 0 ces= 0 IpAddr=1b7010ac IpPort=2427) 27501420.006 |14:55:01.478 |AppInfo |IsdnMsgData1= 08 02 81 92 5A 27501421.000 |14:55:01.478 |SdlSig |PriNi2RelComplete |restart0 |MGCPpn9d(1,100,109,7) |MGCPBhHandler(1,100,89,1) |1,100,251,21.70804^172.16.xxx.27^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] 00000000 00900000 7b090000 ac10701b 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 01000000 27501422.000 |14:55:01.478 |SdlSig |PriNi2RelComplete |release_request19 |MGCPpn9cuser(1,100,108,19291) |MGCPpn9d(1,100,109,7) |1,100,251,21.70804^172.16.xxx.27^* |[R:N-H:0,N:1,L:0,V:0,Z:0,D:0] 00000000 00900000 7b090000 ac10701b 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 01000000 27501422.001 |14:55:01.478 |AppInfo |SPROC analyzeMsgtransCause MessageTransCause.ms = 0, MessageTransCause.ieid = 0, PriTsp.protocol = 10, MCStatus = 0 27501423.000 |14:55:01.478 |SdlSig |DStopConf |stop_indication |MGCPpn9cuser(1,100,108,19291) |MGCPpn9d(1,100,109,7) |1,100,251,21.70804^172.16.xxx.27^* |[R:N-H:0,N:1,L:0,V:0,Z:0,D:0] varChannelStatus=0 27
Analysis:
==========
The Cause Code = 1 is "unknown number". Since we know that the called party is right, it must be the calling party that is at issue.
My assessment is that your service provider is rejecting the call because the caller-id is not associated with the PRI.
As confirmation of that, here is the digit analysis of a CallForwardAll call, coming from an outside caller, sent back to the PSTN.
Note that the Route Pattern used is the same pattern, but in a different partition, than the one used for SNR.
And, importantly, that the caller-id is being overridden with the main number for your organization:
------------------------------------------
27507592.009 |15:01:52.600 |AppInfo |Digit analysis: patternUsage=5 27507592.010 |15:01:52.600 |AppInfo |Digit analysis: match(pi="2", fqcn="", cn="4804370946",plv="5", pss="CallForward_PT:PA_Internal", TodFilteredPss="CallForward_PT:PA_Internal", dd="812486721570",dac="0") 27507592.011 |15:01:52.600 |AppInfo |Digit analysis: analysis results 27507592.012 |15:01:52.600 |AppInfo ||PretransformCallingPartyNumber=480xxx0946 |CallingPartyNumber=434xxx6700 |DialingPartition=CallForward_PT |DialingPattern=8.1[2-9]XX[2-9]XXXXXX |FullyQualifiedCalledPartyNumber=81248xxx1570
So, my suggestion is that you try changing the Rerouting Calling Search Space for one of your SNR targets to the CSS that contains the CallForward_PT and see if that fixes the problem.
09-01-2021 08:07 AM
Is this just you or is it all SNR users?
The most common reason for this behavior is that a Rerouting Calling Search Space is not set on the Remote Destination Profile. Note that the "Calling Search Space" is used for Mobile Voice Access calls and the Rerouting Calling Search Space is used for SNR calls.
Maren
09-01-2021 08:43 AM
Thank you for replying. It is all SNR users. I have a rerouting calling search space. It is the same as my calling search space.
09-01-2021 08:52 AM - edited 09-01-2021 10:42 PM
If the configuration in CM for Mobile Connect is correct the next thing to check is if the call hits your voice gateway and if it sends the call out to your service provider and what reply you get.
Likely it could be that the service provider do not allow the call as they often do not support that you send the calling number as from an external party. In these cases the SP would simply disallow the call. However there are options for how to get this to work.
Once you know if this is what’s going on we can look at what options you have to sort this out.
09-01-2021 09:02 AM
I suspect @Roger Kallberg is correct. You didn't say what kind of PSTN connection you have, so I am going to guess it is SIP. You would likely see some kind of decline in the output of "debug ccsip mess" in that gateway. The provider might accept the call if you enable the sending of redirecting info on the SIP trunk. That could have other unintended consequences, so be ready for that if you try that.
09-01-2021 09:58 AM
I figured, but it's good to check.
I would assume, then, that the SNR RRCS has access to a PSTN route pattern that matches the format of the Remote Destinations.
As suggested elsewhere, the next thing to do is see if the call is reaching your PSTN gateway and what the dialed-number format it.
Not all service providers will allow non-circuit-related CLID to be used when placing an outbound call, so you may have to change the CLID of the SNR call to a main number or something if that is the issue.
And, as Roger mentioned, not all service providers will allow calls to be hairpinned.
Check the gateway first and see what sorts of error messages are showing. Or, you can pull the CallManager Service trace file and look there if you don't want to run a debug on your router.
Let us know what you find and we will do what we can to help.
Maren
09-02-2021 05:42 AM
Good morning. I pulled the CM service trace file. There's a lot of information here. I'm not sure what I am looking for...
09-02-2021 05:53 AM
It is a lot to take in! You can start by importing the file into TranslatorX. Then locate the call in question and follow the call progression. To see if the call is being sent to the gateway, look for an INVITE with your SNR destination going to the gateway. That will show if it is getting that far.
You may need to dig into the trace file itself to see the CUCM decision-making process. If you post the file, along with the originating number, the internal DN and the target destination number we can help you find that. (Or, you can attach it in a PM to me if you are uncomfortable posting it publicly.)
Maren
09-03-2021 10:46 AM
I looked at the trace file you sent and here is what I think:
Maren
-------------------------------------
These lines say that CUCM recognizes the RDP as a target for the incoming call
27501212.001 |14:54:59.845 |AppInfo |LineCdpc(43095): -dispatchToAllDevices-, sigName=CcSetupReq, device=SEP009E1EAD0A95 27501212.002 |14:54:59.845 |AppInfo |LineCdpc(43095): -dispatchToAllDevices-, sigName=CcSetupReq, device=81434xxx9515_krutledge_RDP
The RDP is identified as an off-net device
27501215.002 |14:54:59.846 |AppInfo |SIPStationD(424567) - The new call has ccSetupReq.isOffNetDevice=1 Remembering this in the call entry table.
CUCM Determines that no barriers (permissions, availability, etc.) exist preventing the call to the off net number:
27501216.007 |14:54:59.846 |AppInfo |SNRD::wait_CcSetupReq (0000037) Caller[434xxx2381] is allowed to call [81434xxx9515]
The CUCM has done permissions checks and checks for things like CFDAll/CTI/etc and declared that the call can go to the RDP
Then CUCM creates the internal anchor for the call that is to go out to the RDP
27501217.003 |14:54:59.846 |AppInfo |CMUtility isCTIRemoteDestinationActive: For remdest [81434xxx9515], isCTIRDAssociated=0, isRDDActive=0, isRDPAssociated=1 27501217.004 |14:54:59.846 |AppInfo |DbMobility:initRemDest: device pkid [05512005-4085-711f-4373-9f9f461ca553], profile pkid [dadcdef4-ca8b-eef4-5757-8dd662c31221], isDualmode [0], isCumc [0], isSmartPhone [0], isSiplineDevice [0] 27501217.005 |14:54:59.846 |AppInfo |DbMobilityRemDestTable:initRemDest: initialized a remdest [81434xxx9515] 27501217.006 |14:54:59.846 |AppInfo |DbMobility - RemDest dump: cnumber = 81434xxx9515, devicePkid = 05512005-4085-711f-4373-9f9f461ca553, remDestProfilePkidStr = dadcdef4-ca8b-eef4-5757-8dd662c31221, isMobilePhone = 1, isDualMode = 0, isSmartPhone = 0, isSNREnabled= 1, answerTooSoonTimer = 1500, answerTooLateTimer = 20000, delayBeforeRingingCellTimer = 1500, userId = krutledge, timeZoneIndex = 0, requireThirdPartyRegistration = 0, blockIncomingCallsWhenRoaming = 0, homeNetworkID = , description = krutledge_RD, url = , SNRVMAvoidancePolicy = 0, DvorVMAPolicy = 0 27501217.007 |14:54:59.846 |AppInfo |DbMobilityRemDestTable:initMobilityUser: -- created mobility user 27501217.008 |14:54:59.846 |AppInfo |DbMobility - User dump: userId = krutledge, isIVREnabled = 0, maxDeskPickupWaitTime = 10000, userLocale = 1, userHasSpecificLocale = true 27501217.009 |14:54:59.846 |AppInfo |CellProxy( 1164) - StartTransition - cellNum=81434xxx9515, dn=6720, blended uri=, smart=0, mobile=1, dualmode=0, snrEnabled=1, answer2Soon=1500, answer2Late=20000, callScreenTimer=4000, delayBFRing=1500, rerouteCSS=1c67e757-84c4-4a7d-984b-14944b1edf46, userLocale=1, deskPickup=10000, mDialingPid= (0, 0, 0), is3G=0, associatedUserLocale=1, defaultUserLocale=1, mSnrdFeatureType=0
This section is the digit analysis section where CUCM has picked a Route Pattern to egress the call.
Note that the caller ID is your cell number and is not altered:
27501232.009 |14:54:59.849 |AppInfo |Digit analysis: patternUsage=5 27501232.010 |14:54:59.849 |AppInfo |Digit analysis: match(pi="2", fqcn="", cn="434xxx2381",plv="5", pss="PA_Internal:PA_VoiceMail:MainCampus_Emergency:PA_MainCampus_Local:PA_MainCampus_TollFree:PA_MainCampus_Service:PA_MainCampus_LD", TodFilteredPss="PA_Internal:PA_VoiceMail:MainCampus_Emergency:PA_MainCampus_Local:PA_MainCampus_TollFree:PA_MainCampus_Service:PA_MainCampus_LD", dd="81434xxx9515",dac="0") 27501232.011 |14:54:59.849 |AppInfo |Digit analysis: analysis results 27501232.012 |14:54:59.849 |AppInfo ||PretransformCallingPartyNumber=434xxx2381 |CallingPartyNumber=434xxx2381 |DialingPartition=PA_MainCampus_LD |DialingPattern=8.1[2-9]XX[2-9]XXXXXX |FullyQualifiedCalledPartyNumber=81434xxx9515 <output omitted>
Route List is identified (RL/RG/GW selection is later)
27501235.003 |14:54:59.849 |AppInfo |SMDMSharedData::findLocalDevice - Name=RL_MainCampus1 Key=0ba17960-d719-42c5-ad62-7a05acc0343a isActvie=1 Pid=(1,173,2) found
Selections from the RL/RG/GW selection process...
. . 27501333.003 |14:55:01.356 |AppInfo |RouteList - RouteListName=''RL_MainCampus1'' CallableEndPointName=''0ba17960-d719-42c5-ad62-7a05acc0343a'' routeListEnabled=''1'' . . 27501333.008 |14:55:01.356 |AppInfo |RouteListCdrc - RouteGroup count = 1 27501333.009 |14:55:01.356 |AppInfo |RouteListCdrc - Device count = 2 . . 27501336.000 |14:55:01.356 |SdlSig |DmPidRes |select_facility |RouteListCdrc(1,100,172,9723) |DeviceManager(1,100,53,1) |1,100,251,21.70801^172.16.xxx.27^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] Cepn=1b7ea81b-3e9e-59e1-329b-53ffb04bf797 Id=0 ccmType=7 DeviceName=S0/SU1/DS1-0@<name of mgcp gw>.ialr.org Pid=1,100,109,7,
Process to extend an MGCP-based call to the gateway is initialized:
27501336.005 |14:55:01.356 |AppInfo |RouteListCdrc::executeRouteAction: EXTEND_CALL_TO_CURRENT_MEMBER -- Success 27501337.000 |14:55:01.356 |SdlSig |CcSetupReq |restart0 |MGCPpn9d(1,100,109,7) |RouteListCdrc(1,100,172,9723) |1,100,251,21.70801^172.16.xxx.27^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] CI=22722821 CI.branch=16778380 sBPL.plid=65 sBPL.l=1 sBPL.pl=5 sBPL.msd=0 FDataType=0 opId=0 ssType=0 SsKey=0 invokeId=0 resultExp=F bpda=F pi.piid=0 pi.l=0 pi2.piid=30 pi2.l=0 pi3.piid=30 pi3.l=0 FQCGPN=pi=0si1 preXCgpn=tn=2npi=1ti=1nd=434xxx2381pi=0si3 cgPart= cgPat= cgpn=tn=2npi=1ti=1nd=434xxx2381pi=1si3 cgpnVM= unXCgpn=tn=2npi=1ti=1nd=434xxx2381pi=1si0 cName=locale: 1 Name: HARRIS TIJUANA UnicodeName: pi: 0 DD=tn=0npi=1ti=1nd=6720pi=0si1 origDD=tn=0npi=1ti=1nd=6720pi=0si1 preXCdpn=tn=0npi=0ti=1nd=1434xxx9515pi=0si0 preXTagsList=ACCESS-CODE:SUBSCRIBER preXPosMatchList=8:1434xxx9515 cdPart=1e9957e1-8c99-466d-a85d-9e4604bdd2e2 cdPat=8.1[2-9]XX[2-9]XXXXXX cdpn=tn=0npi=0ti=1nd=1434xxx9515pi=0si0 cdpnVMbox= localPatternUsage=2 connectedPatternUsage=2 itrPart= itrPat= LRPart=c988fa7a-68a7-4832-8295-5e54b1b811ba LRPat=6720 LR=tn=0npi=0ti=1nd=14347666700pi=0si1 LRVM= LRName=locale: 1 Name: Kevin Rutledge UnicodeName: Kevin Rutledge pi: 0 FQOCpdn=ti=1nd=4347666720pi=0si1 fFQLRNum=ti=1nd=14347666700pi=0si1 oPart=c988fa7a-68a7-4832-8295-5e54b1b811ba oPat=6720 oCpdn=tn=0npi=0ti=1nd=14347666700pi=0si1 oCdpnVM= oRFR=335 oName=locale: 1 Name: Kevin Rutledge UnicodeName: Kevin Rutledge pi: 0 ts=SUBSCRIBER posMatches=6720 withTags= withValues= rdn.l=0IpAddrMode=0 ipAddrType=0 ipv4=0.0.0.0:0 region=RE_MainCampus capCount=10 ctiActive=F ctiFarEndDev=2 ctiCCMId=1 cgPtyDev=S0/SU1/DS1-0@<name of mgcp gw>.ialr.org callInst=1 confCallInst=0 OLF=1Supp DTMF=1DTMF Cfg=1DTMF Payload=()isOffNetDev=T bc.l=1 bc.itr=1 bc.itc=0 bc.trm=0 bc.tm=0 maxForwards=70 cgpnMaskedByRedirect=F callingDP=1b1b9eb6-7803-11d3-bdf0-00108302ead1 featCallType=0 callingUserId= UnicodeName: muteEnabled=0 associatedCallCI=0 featurePriority=1 nonTargetPolicy=0 unconsumedDigits= suppressMOH=F numPlanPkid =0b8f62be-3c52-7b58-2a1b-1b50322eb142 networkDomain= bitMask=0 SetupReason=0 routeClass=1 LmSyncAlertingCallType=0 sideACmDeviceType=7 protected=0 ControlProcessType=1 tokens=0 isPresent=F transitCount=0 geolocInfo={geolocPkid=, filterPkid=, geolocVal=, devType=7} locPkid=c23c00f1-1561-4f47-8127-4d3f67ff758c locName=LO_MainCampus deductBW=F fateShareId=StandAloneCluster:22722820 videoTrafficClass=Unspecified oFromAnalogDvc=F bridgeParticipantID= callingUsr= remoteClusterID= isEMCCDevice=F lHPMemCEPN= cHPMemCEPN= isParamSet=FTransparentData=null CanSupportSIPTandN=false TransId=0 AllowBitMask=0x0 UserAgentOrServer= OrigDDName=locale: 1 Name: UnicodeName: pi: 0 mCallerId= mCallerName= TrustRxId=T mIsMultiForkingEnabled=FLatentCaps=null icidVal= icidGenAddr= oioi= tioi= ptParams= receivedPAID= routeHdr= routeCepn= requestURI= routeHeaderURI=pi=0si1 PCVFlag=F originallyHadISUP=F isIMSFinalRoute=F IMSMode=0 SideABibEnabled= 0 isCgpnNonPreemptable=F isCdpnNonPreemptable=F origDP=1b1b9eb6-7803-11d3-bdf0-00108302ead1 lastRedirectingDP=1b1b9eb6-7803-11d3-bdf0-00108302ead1 originalLRG= lastRedirectingLRG= nwLoc=0 rstr= FarEndDeviceName= ReferredByUri= Session-ID: ;remote=1b7ea81b3e9e59e1329b53bd22722820 hdrMOH=0 CAL={v=ffffffff, m=ffffffff, tDev=F, res=F, devType=0} External Presentation Info [ pi=0si1locale: 1 Name: UnicodeName: pi: 0 mIsCallExternal=F ] origPi=0 27501337.001 |14:55:01.356 |AppInfo |MGCPpn9d:restart0_CcSetupReq - S0/SU1/DS1-0@<name of mgcp gw>.ialr.org My Region=RE_MainCampus, Other Side Region=RE_MainCampus 27501337.002 |14:55:01.356 |AppInfo |ViprUtils:isViprAllowed Device =S0/SU1/DS1-0@<name of mgcp gw>.ialr.org UseIMEForOutboundCall=false
.
.
27501337.005 |14:55:01.357 |Created | | |MGCPpn9cuser(1,100,108,19291) |MGCPpn9d(1,100,109,7) | |NumOfCurrentInstances: 3
27501337.006 |14:55:01.357 |AppInfo |MGCPpn9d - initPortInfo: portInfo[22] endpoint=S0/SU1/DS1-0/23@<name of mgcp gw>.ialr.org, ci=22722821, globalCallId=480790
Connection request sent to the MGCP Gateway:
27501357.001 |14:55:01.360 |AppInfo |MGCPHandler send msg SUCCESSFULLY to: 172.16.xxx.27 CRCX 108767 S0/SU1/DS1-0/23@<name of mgcp gw>.ialr.org MGCP 0.1 C: D0000000015ab905000000F500000192 X: 17 L: p:20, a:PCMU, s:off, t:b8 M: recvonly R: D/[0-9ABCD*#] Q: process,loop
Okay from Gateway:
27501361.000 |14:55:01.365 |AppInfo |MGCPHandler received msg from: 172.16.xxx.27 200 108767 OK I: A07B v=0 c=IN IP4 172.16.xxx.27 m=audio 10446 RTP/AVP 0 100 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194
CUCM generates the Q931 message that the MGCP gateway should send over the D-Channel:
27501369.000 |14:55:01.366 |SdlSig |PriNi2Setup |wait |MGCPBhHandler(1,100,89,1) |MGCPpn9cuser(1,100,108,19291) |1,100,251,21.70801^172.16.xxx.27^* |[R:N-H:0,N:2,L:0,V:0,Z:0,D:0] 00000000 00900000 7b090000 ac10701b 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 27501369.001 |14:55:01.366 |AppInfo | 27501369.002 |14:55:01.366 |AppInfo |Out Message -- PriSetupMsg -- Protocol= PriNi2Protocol 27501369.003 |14:55:01.366 |AppInfo |Ie - Ni2BearerCapabilityIe IEData= 04 03 80 90 A2 27501369.004 |14:55:01.366 |AppInfo |Ie - Q931ChannelIdIe IEData= 18 03 A9 83 97 27501369.005 |14:55:01.366 |AppInfo |Ie - Q931DisplayIe IEData= 28 0F 48 41 52 52 49 53 20 54 49 4A 55 41 4E 41 20 27501369.006 |14:55:01.366 |AppInfo |Ie - Q931CallingPartyIe IEData= 6C 0C 21 83 34 33 34 3x 3x 3x 32 33 38 31 27501369.007 |14:55:01.366 |AppInfo |Ie - Q931CalledPartyIe IEData= 70 0C 80 31 34 33 34 3x 3x 3x 39 35 31 35 27501369.008 |14:55:01.366 |AppInfo |MMan_Id= 0. (iep= 0 dsl= 9000 sapi= 0 ces= 0 IpAddr=1b7010ac IpPort=2427) 27501369.009 |14:55:01.366 |AppInfo |IsdnMsgData2= 08 02 01 92 05 04 03 80 90 A2 18 03 A9 83 97 28 0F 48 41 52 52 49 53 20 54 49 4A 55 41 4E 41 20 6C 0C 21 83 34 33 34 34 32 39 32 33 38 31 70 0C 80 31 34 33 34 35 34 37 39 35 31 35 27501369.010 |14:55:01.366 |AppInfo |MGCPBhHandler - Sending BhHdr: 0004 0000 0010 9000 0001 003c
CUCM generates the Q931 message that the MGCP gateway should send over the D-Channel:
27501369.000 |14:55:01.366 |SdlSig |PriNi2Setup |wait |MGCPBhHandler(1,100,89,1) |MGCPpn9cuser(1,100,108,19291) |1,100,251,21.70801^172.16.xxx.27^* |[R:N-H:0,N:2,L:0,V:0,Z:0,D:0] 00000000 00900000 7b090000 ac10701b 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 27501369.001 |14:55:01.366 |AppInfo | 27501369.002 |14:55:01.366 |AppInfo |Out Message -- PriSetupMsg -- Protocol= PriNi2Protocol 27501369.003 |14:55:01.366 |AppInfo |Ie - Ni2BearerCapabilityIe IEData= 04 03 80 90 A2 27501369.004 |14:55:01.366 |AppInfo |Ie - Q931ChannelIdIe IEData= 18 03 A9 83 97 27501369.005 |14:55:01.366 |AppInfo |Ie - Q931DisplayIe IEData= 28 0F 48 41 52 52 49 53 20 54 49 4A 55 41 4E 41 20 27501369.006 |14:55:01.366 |AppInfo |Ie - Q931CallingPartyIe IEData= 6C 0C 21 83 34 33 34 3x 3x 3x 32 33 38 31 27501369.007 |14:55:01.366 |AppInfo |Ie - Q931CalledPartyIe IEData= 70 0C 80 31 34 33 34 3x 3x 3x 39 35 31 35 27501369.008 |14:55:01.366 |AppInfo |MMan_Id= 0. (iep= 0 dsl= 9000 sapi= 0 ces= 0 IpAddr=1b7010ac IpPort=2427) 27501369.009 |14:55:01.366 |AppInfo |IsdnMsgData2= 08 02 01 92 05 04 03 80 90 A2 18 03 A9 83 97 28 0F 48 41 52 52 49 53 20 54 49 4A 55 41 4E 41 20 6C 0C 21 83 34 33 34 34 32 39 32 33 38 31 70 0C 80 31 34 33 34 35 34 37 39 35 31 35 27501369.010 |14:55:01.366 |AppInfo |MGCPBhHandler - Sending BhHdr: 0004 0000 0010 9000 0001 003c
Note the Q931CalledPartyIe and the Q931allingPartyIE line and the way that the numbers are expressed.
The last 10/11 pairs of numbers are a 3+ActualNumber - So it is sending 1-434-xxx-9515 and CLID 434xxx2381
27501369.006 |14:55:01.366 |AppInfo |Ie - Q931CallingPartyIe IEData= 6C 0C 21 83 34 33 34 3x 3x 3x 32 33 38 31
27501369.007 |14:55:01.366 |AppInfo |Ie - Q931CalledPartyIe IEData= 70 0C 80 31 34 33 34 3x 3x 3x 39 35 31 35
So as of right now the call has been outdialed to the PSTN over the PRI. However the call is rejected:
(Note, in particular, the part where it says: "Sending CcRejInd, with the cause code (1)")
27501389.001 |14:55:01.461 |AppInfo |MGCPBhHandler 172.16.xxx.27 - TCP msg available from Device 27501389.002 |14:55:01.461 |AppInfo |MGCPBhHandler - Receiving BhHdr: 0004 0000 0011 9000 0001 0009 27501389.003 |14:55:01.461 |AppInfo | 27501389.004 |14:55:01.461 |AppInfo |In Message -- PriDisconnectMsg -- Protocol= PriNi2Protocol 27501389.005 |14:55:01.461 |AppInfo |Ie - Q931CauseIe -- IEData= 08 02 82 81 27501389.006 |14:55:01.461 |AppInfo |MMan_Id= 0. (iep= 0 dsl= 9000 sapi= 0 ces= 0 IpAddr=1b70xxac IpPort=2427) 27501389.007 |14:55:01.461 |AppInfo |IsdnMsgData1= 08 02 81 92 45 08 02 82 81 27501390.000 |14:55:01.461 |SdlSig |PriNi2Disconn |restart0 |MGCPpn9d(1,100,109,7) |MGCPBhHandler(1,100,89,1) |1,100,251,21.70803^172.16.xxx.27^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] 00000000 00900000 7b090000 ac10701b 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 01000000 27501391.000 |14:55:01.461 |SdlSig |PriNi2Disconn |outgoing_call_proceeding3 |MGCPpn9cuser(1,100,108,19291) |MGCPpn9d(1,100,109,7) |1,100,251,21.70803^172.16.xxx.27^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] 00000000 00900000 7b090000 ac10701b 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 01000000 27501391.001 |14:55:01.461 |AppInfo |SPROC analyzeMsgtransCause MessageTransCause.ms = 0, MessageTransCause.ieid = 0, PriTsp.protocol = 10, MCStatus = 0 27501391.002 |14:55:01.461 |AppInfo |MGCPpn9cuser - sendCcDisconnInd, Q931Cause.cv:1, CcDisconnInd.c.cv:1 27501392.000 |14:55:01.461 |SdlSig |CcDisconnInd |idle |RouteListControl(1,100,173,2) |MGCPpn9cuser(1,100,108,19291) |1,100,251,21.70803^172.16.xxx.27^* |[R:N-H:0,N:1,L:0,V:0,Z:0,D:0] CI=22722821 CI.branch=16778380 c.l=2 c.cid=8 c.cs=0 c.lc=2 c.r=0 cv=1 globalDisconnect=F FDataType=0 opId=0 ssType=0 SsKey=0 invokeId=0 resultExp=F bpda=FTransparentData=null CanSupportSIPTandN=false TransId=0 AllowBitMask=0x0 UserAgentOrServer= OrigDDName=locale: 1 Name: UnicodeName: pi: 0 mCallerId= mCallerName= TrustRxId=T mIsMultiForkingEnabled=F CAL={v=ffffffff, m=ffffffff, tDev=F, res=F, devType=0} CAL={v=fffffff6, m=ffffffff, tDev=F, res=F, devType=0} 27501393.000 |14:55:01.461 |SdlSig |DSetCallPhase |restart0 |MGCPpn9d(1,100,109,7) |MGCPpn9cuser(1,100,108,19291) |1,100,251,21.70803^172.16.xxx.27^* |[R:N-H:0,N:1,L:0,V:0,Z:0,D:0] CallPhase=CALL_CLEARING 27501394.000 |14:55:01.461 |SdlSig |CcDisconnInd |call_proceeding |RouteListCdrc(1,100,172,9723) |RouteListControl(1,100,173,2) |1,100,251,21.70803^172.16.xxx.27^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] CI=22722821 CI.branch=16778380 c.l=2 c.cid=8 c.cs=0 c.lc=2 c.r=0 cv=1 globalDisconnect=F FDataType=0 opId=0 ssType=0 SsKey=0 invokeId=0 resultExp=F bpda=FTransparentData=null CanSupportSIPTandN=false TransId=0 AllowBitMask=0x0 UserAgentOrServer= OrigDDName=locale: 1 Name: UnicodeName: pi: 0 mCallerId= mCallerName= TrustRxId=T mIsMultiForkingEnabled=F CAL={v=ffffffff, m=ffffffff, tDev=F, res=F, devType=0} CAL={v=fffffff6, m=ffffffff, tDev=F, res=F, devType=0} 27501394.001 |14:55:01.461 |AppInfo |RouteListCdrc::checkQ931CauseCode - configuration is empty 27501394.002 |14:55:01.461 |AppInfo |RouteListCdrc::call_proceeding_CcDisconnInd - The call cannot be re-routed, forwarding CcDisconnInd to Cc 27501394.003 |14:55:01.461 |AppInfo |RouteListCdrc::sendCcRejInd - Sending CcRejInd, with the cause code (1), to RouteListControl because all devices are busy/stopped.
CUCM Sends a Delete Connection Request to the MGCP GW
27501407.000 |14:55:01.461 |SdlSig |MGCPDeleteConnection |restart0 |MGCPpn9d(1,100,109,7) |MGCPpn9cuser(1,100,108,19291) |1,100,251,21.70803^172.16.xxx.27^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] - portNum= 23 DLCX 0 27501408.000 |14:55:01.461 |SdlSig |MGCPDeleteConnection |restart0 |MGCPedpc(1,100,104,243) |MGCPpn9d(1,100,109,7) |1,100,251,21.70803^172.16.xxx.27^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] S0/SU1/DS1-0/23@<name of mgcp gw>.ialr.org - portNum= 23 DLCX 0 27501409.000 |14:55:01.461 |SdlSig |MGCPDeleteConnection |wait |MGCPHandler(1,100,90,1) |MGCPedpc(1,100,104,243) |1,100,251,21.70803^172.16.xxx.27^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] S0/SU1/DS1-0/23@<name of mgcp gw>.ialr.org - portNum= 23 DLCX 0 27501409.001 |14:55:01.461 |AppInfo |MGCPHandler send msg SUCCESSFULLY to: 172.16.xxx.27 DLCX 108768 S0/SU1/DS1-0/23@<name of mgcp gw>.ialr.org MGCP 0.1 C: D0000000015ab905000000F500000192 I: A07B X: 17 S:
OK Response from the GW
27501410.000 |14:55:01.465 |AppInfo |MGCPHandler received msg from: 172.16.xxx.27 250 108768 OK P: PS=0, OS=0, PR=0, OR=0, PL=0, JI=0, LA=0
CUCM creates and sends the Q931 release to end the call:
27501419.000 |14:55:01.465 |SdlSig |PriNi2Rel |wait |MGCPBhHandler(1,100,89,1) |MGCPpn9cuser(1,100,108,19291) |1,100,251,21.70803^172.16.xxx.27^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] 00000000 00900000 7b090000 ac10701b 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 01000000 27501419.001 |14:55:01.465 |AppInfo | 27501419.002 |14:55:01.465 |AppInfo |Out Message -- PriReleaseMsg -- Protocol= PriNi2Protocol 27501419.003 |14:55:01.465 |AppInfo |Ie - Q931CauseIe IEData= 08 02 82 93 27501419.004 |14:55:01.465 |AppInfo |MMan_Id= 0. (iep= 0 dsl= 9000 sapi= 0 ces= 0 IpAddr=1b7010ac IpPort=2427) 27501419.005 |14:55:01.465 |AppInfo |IsdnMsgData2= 08 02 01 92 4D 08 02 82 93 27501419.006 |14:55:01.465 |AppInfo |MGCPBhHandler - Sending BhHdr: 0004 0000 0010 9000 0001 0009
Relase complete received from the PRI D-Channel:
27501420.003 |14:55:01.478 |AppInfo | 27501420.004 |14:55:01.478 |AppInfo |In Message -- PriReleaseCompleteMsg -- Protocol= PriNi2Protocol 27501420.005 |14:55:01.478 |AppInfo |MMan_Id= 0. (iep= 0 dsl= 9000 sapi= 0 ces= 0 IpAddr=1b7010ac IpPort=2427) 27501420.006 |14:55:01.478 |AppInfo |IsdnMsgData1= 08 02 81 92 5A 27501421.000 |14:55:01.478 |SdlSig |PriNi2RelComplete |restart0 |MGCPpn9d(1,100,109,7) |MGCPBhHandler(1,100,89,1) |1,100,251,21.70804^172.16.xxx.27^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] 00000000 00900000 7b090000 ac10701b 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 01000000 27501422.000 |14:55:01.478 |SdlSig |PriNi2RelComplete |release_request19 |MGCPpn9cuser(1,100,108,19291) |MGCPpn9d(1,100,109,7) |1,100,251,21.70804^172.16.xxx.27^* |[R:N-H:0,N:1,L:0,V:0,Z:0,D:0] 00000000 00900000 7b090000 ac10701b 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 01000000 27501422.001 |14:55:01.478 |AppInfo |SPROC analyzeMsgtransCause MessageTransCause.ms = 0, MessageTransCause.ieid = 0, PriTsp.protocol = 10, MCStatus = 0 27501423.000 |14:55:01.478 |SdlSig |DStopConf |stop_indication |MGCPpn9cuser(1,100,108,19291) |MGCPpn9d(1,100,109,7) |1,100,251,21.70804^172.16.xxx.27^* |[R:N-H:0,N:1,L:0,V:0,Z:0,D:0] varChannelStatus=0 27
Analysis:
==========
The Cause Code = 1 is "unknown number". Since we know that the called party is right, it must be the calling party that is at issue.
My assessment is that your service provider is rejecting the call because the caller-id is not associated with the PRI.
As confirmation of that, here is the digit analysis of a CallForwardAll call, coming from an outside caller, sent back to the PSTN.
Note that the Route Pattern used is the same pattern, but in a different partition, than the one used for SNR.
And, importantly, that the caller-id is being overridden with the main number for your organization:
------------------------------------------
27507592.009 |15:01:52.600 |AppInfo |Digit analysis: patternUsage=5 27507592.010 |15:01:52.600 |AppInfo |Digit analysis: match(pi="2", fqcn="", cn="4804370946",plv="5", pss="CallForward_PT:PA_Internal", TodFilteredPss="CallForward_PT:PA_Internal", dd="812486721570",dac="0") 27507592.011 |15:01:52.600 |AppInfo |Digit analysis: analysis results 27507592.012 |15:01:52.600 |AppInfo ||PretransformCallingPartyNumber=480xxx0946 |CallingPartyNumber=434xxx6700 |DialingPartition=CallForward_PT |DialingPattern=8.1[2-9]XX[2-9]XXXXXX |FullyQualifiedCalledPartyNumber=81248xxx1570
So, my suggestion is that you try changing the Rerouting Calling Search Space for one of your SNR targets to the CSS that contains the CallForward_PT and see if that fixes the problem.
09-13-2021 06:44 AM - edited 09-13-2021 06:53 AM
The cool job!
09-13-2021 07:16 AM
@Maren Mahoney Just WOW what an answer! Really above and beyond!
09-13-2021 07:20 AM
Call me crazy, but I truly enjoy rummaging around in log files. It's sort of like math...the answer is always in there somewhere if you look long enough.
Maren
09-02-2021 02:30 AM
Hi,I would like to implement this feature.Can you share some documents?
09-02-2021 03:30 AM - edited 09-02-2021 03:47 AM
As a starting point have a look in the online configuration guide in CM. Under Device Menu > About Remote Destination Setup you’ll find information that pertains to this.
Worth knowing is that Mobile Connect, or SNR as it’s more known as, can be setup for TCT and BOT devices by using a Mobile Identity configuration in CM.
The difference between SNR with the legacy RDP and TCT/BOT is that on the later Jabber or new Webex application will dynamically disable/enable the connection to send the call to the remote destination number, often a mobile number, based on registration status of the TCT/BOT device.
09-02-2021 03:33 AM
Thanks Roger.I will check it out
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