Single Number Reach not working for external calls

[tijuanach]

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. 

[Maren Mahoney]

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

[tijuanach]

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. 

[Roger Kallberg]

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.

[Elliot Dierksen]

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.

[Maren Mahoney]

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

[tijuanach]

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... 

[Maren Mahoney]

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

[Maren Mahoney · Accepted solution]

I looked at the trace file you sent and here is what I think:

• Analysis: Your service provider is blocking the SNR call because the caller ID (your cell) is not associated with the PRI.
• Suggestion: Change the Rerouting Calling Search Space to the one that you use for Call Forward All (containing the CallForward_PT). The 8.11-digits route pattern in that partition overrides the caller ID with the main number of your organization.

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.

[Sergey 1907]

The cool job!

[Roger Kallberg]

@Maren Mahoney Just WOW what an answer! Really above and beyond!

[Maren Mahoney]

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

[collinks2]

Hi,I would like to implement this feature.Can you share some documents?

[Roger Kallberg]

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.

[collinks2]

Thanks Roger.I will check it out