[cisco-voip] Can we know which CUCM setting has modified the DNIS from CUCM SDL Traces?
ciscozest
ciscozest at gmail.com
Mon Aug 23 22:20:38 EDT 2010
Thanks to all responds,
I had figured out the cause of the prefix. It is set in the CallManager
advance service parameter. This is not granular/good way to add the prefix
though.
cheers,
Denny
On Tue, Aug 24, 2010 at 12:19 AM, Ryan Ratliff <rratliff at cisco.com> wrote:
> Agreed, SDL traces are not likely going to be of any use for something
> like this.
>
> The key to knowing what is changing your number is seeing where in the
> process of a call the number changes.
>
> The first place you will see a called number is in digit analysis (DA).
> For example:
> 05/04/2010 11:06:23.614 CCM|Digit analysis: match(pi="2", fqcn="5551234",
> cn="5551234",plv="5", pss="pt_internal", TodFilteredPss="pt_internal", *
> dd="5554321"*,dac="0")
>
> This represents the DaReq signal sent in an SDL trace (DA request).
> Basically the calling, called numbers, list of partitions (derived from the
> calling device/line CSS), and the tod filtered list of partitions.
>
> Next you will see the DA results (assuming there are no potential matches,
> and a pattern was matched). This is derived from the DaRes SDL signal.
> 05/04/2010 11:06:23.614 CCM|Digit analysis: analysis results
> 05/04/2010 11:06:23.614 CCM||PretransformCallingPartyNumber=5551234
> |CallingPartyNumber=55512345
> |DialingPartition=pt_internal
> |*DialingPattern=5554321*
> |FullyQualifiedCalledPartyNumber=5554321
>
> There will be many more lines below this, all starting with the '|'
> character. This information will include things like intercepts,
> translation pattern details (if digit analysis complexity is enabled), etc.
>
> The first place you will see the called party number change is between the
> DaReq and DaRes. Take this example:
>
> 05/04/2010 11:06:23.614 CCM|Digit analysis: match(pi="2", fqcn="5551234",
> cn="5551234",plv="5", pss="pt_internal", TodFilteredPss="pt_internal", *
> dd="5554321"*,dac="0")
>
> 05/04/2010 11:06:23.614 CCM|Digit analysis: analysis results
> 05/04/2010 11:06:23.614 CCM||PretransformCallingPartyNumber=5551234
> |CallingPartyNumber=55512345
> |DialingPartition=pt_internal
> |*DialingPattern=5559999*
> |FullyQualifiedCalledPartyNumber=5559999
>
> Here in the initial DA the number dialed (dd=) is 5554321. When the DA
> results are shown the called party number has changed to 5559999. The only
> thing that can transform the number like this is a translation pattern.
>
> Pretty much every other method of manipulating numbers either tells you in
> the traces what it is doing (ie transformation patterns) or the point in the
> call flow where the number changes tells you where it has to be happening.
> If the number in DA results is 10 digits but the number sent to the gateway
> is 11 then you are looking at a route pattern or route list that had a
> prefix on it. If the number was one thing in an outbound SIP Invite or
> H.225 Setup but another number when it left the voice gateway then you are
> looking at transforms on the router.
>
> -Ryan
>
> On Aug 23, 2010, at 8:35 AM, Pavan wrote:
>
> Can you post SDI as well ?
>
> Sent from my phone. Please pardon the fat
>
> On Aug 23, 2010, at 6:50 AM, ciscozest <ciscozest at gmail.com> wrote:
>
> Yes I did but it did not give me the answer. :(
>
> On 23/08/2010 8:23 PM, Dennis Heim wrote:
>
> Have you tried using dialed number analyzer as a starting point?
>
>
>
> Dennis Heim
> Network Voice Engineer
> CDW Advanced Technology Services
> 11711 N. Meridian Street, Suite 225
> Carmel, IN 46032
>
> 317.569.4255 Office
> 317.569.4201 Fax
> 317.694.6070 Cell
>
> <dennis.heim at cdw.com>dennis.heim at cdw.com
> <http://www.cdw.com/content/solutions/unified-communications/>
> cdw.com/content/solutions/unified-communications/
>
>
>
>
>
> *From:* <cisco-voip-bounces at puck.nether.net>
> cisco-voip-bounces at puck.nether.net [ <cisco-voip-bounces at puck.nether.net>
> mailto:cisco-voip-bounces at puck.nether.net<cisco-voip-bounces at puck.nether.net>]
> *On Behalf Of *ciscozest
> *Sent:* Monday, August 23, 2010 2:01 AM
> *To:* cisco-voip mailinglist
> *Subject:* [cisco-voip] Can we know which CUCM setting has modified the
> DNIS from CUCM SDL Traces?
>
>
>
> I am learning how to read CUCM SDL traces. My aim here is to find out which
> CUCM config/ parameter has added prefix ‘0’ to the calling party number. I
> did the call from 0752223300 but for some reason the called party phone
> showed the number as 00752223300. I have checked the MGCP gateway and
> translation pattern but no luck. I am using CUCM 6.1.3. Can anyone enlighten
> me please? The call reference ID is 36462310. Sorry for the long output
> below. thanks
>
>
>
> | start |
> RSVPSession(2,100,32,4381232) |
>
> RSVPSession(2,100,32,4381232) | (2,100,32,4381232).1-(*:*) |
> [R:HP - HP: 0,
>
> NP: 1, LP: 0, VLP: 0, LZP: 0 DBP: 0]
>
> 460123505| 2010/08/23 15:03:38.126| 002| SdlSig |
>
> RSVPRegisterReq | await_init |
> RSVPSession
>
> (2,100,32,4381232) | RSVPSessionMgr(2,100,30,1) |
> (2,100,133,1).15084883-
>
> (*:172.25.31.3) | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]CI=
> 36462309 Branch= 0
>
> reg=REG_QBCI cap=15 loc=3 MRGL=MRG_QBCI_Hardware:MRG_CCM:MRG_MOH PrecLev=5
> VCall=0 VCapa=0
>
> regiState=0 medReq=0 dataCapFl=2
>
> 460123506| 2010/08/23 15:03:38.126| 002| SdlSig |
>
> RSVPRegisterRes | restart0 |
> MGCPpn9d
>
> (2,100,123,184) | RSVPSession(2,100,32,4381232) |
> (2,100,133,1).15084883-
>
> (*:172.25.31.3) | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]CI=
> 36462309 Branch= 0
>
> resvSta=0 rsvpPol=0 vCall=0 RSVPAgent: confID =0 ci =0 capCt =0 reg=
> mtpType =2 agentCt =0
>
> agentAllo =0 DevCap=0
>
> 460123507| 2010/08/23 15:03:38.126| 002| SdlSig | RSVPRegisterRes
>
> | await_rsvp_reg_res |
> MGCPpn9cuser(2,100,124,994997) |
>
> MGCPpn9d(2,100,123,184) | (2,100,133,1).15084883-(*:172.25.31.3) |
> [R:NP - HP: 0,
>
> NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]CI= 36462309 Branch= 0 resvSta=0
> rsvpPol=0 vCall=0
>
> RSVPAgent: confID =0 ci =0 capCt =0 reg= mtpType =2 agentCt =0 agentAllo
> =0 DevCap=0
>
> 460123508| 2010/08/23 15:03:38.126| 002| SdlSig-Q |
> PriEuroSetup |
>
> null0 | MGCPpn9cuser(2,100,124,994997) |
> MGCPpn9d(2,100,123,184)
>
> | (2,100,133,1).15084883-(*:172.25.31.3) |
>
> 460123509| 2010/08/23 15:03:38.126| 002|
>
> SdlSig | CcRegisterPartyA |
> wait | Cc
>
> (2,100,176,1) | MGCPpn9cuser(2,100,124,994997) |
> (2,100,133,1).15084883-
>
> (*:172.25.31.3) | [R:NP - HP: 0, NP: 1, LP: 0, VLP: 0, LZP: 0 DBP:
> 0]CI=36462309
>
> CI.branch=0 CSS=5f96bc83-582a-b65b-e5ea-f7c5202aeee2 cssIns=0 aarCSS=
> aarDev=1 FQDN=pi=0si1
>
> CallRef=2450 OLC=0 Name=locale: 1 Name: UnicodeName: pi: 0 encodeType=10
> ConnType=3
>
> XferMode=
> ConnTime=0 nwLoc=OffNet ta.ip=0 ta.port=0 region=REG_QBCI capCount=15
> devType=7
>
> mixerCId=0 mediaReq=0 portToPort.loc=3
> MOH.MRGL=MRG_QBCI_Hardware:MRG_CCM:MRG_MOH
>
> MOH.userHoldID=1 MOH.netHoldID=1 MOH.supp=0
> devName=S0/SU0/DS1-0 at qbci-3825-vg1-
>
> <http://1a.qbci.org.au/>1a.QBCI.org.au <http://1a.qbci.org.au/>ctiActive=0 ctiFarEndDev=2 ctiCCMId=2 devCepn= activeCaps=0 VideoCall=0
>
> VideoCap=0 dataCap=2 devCap=0 CryptoCapCount=0 secure=1 loginId=
> UnicodeName:
>
> retriedVideo=0FromTag=ToTag=CallId= UAPortFlag=0 wantDTMFRecep=1 provOOB=0
> supp DTMF=1 DTMF
>
> Cfg=1 DTMF PT=0 DTMF reqMed=0 isPrefAltScript=0 audioPtyId=0
> doNotAppendLineCSS=0
>
> flushCapIns=0ccBearCap.l=0ccBearCap.itc=0ccBearCap.itr=0hasLocationCACInfo
> =0
>
> 460123510|
>
> 2010/08/23 15:03:38.127| 002| Created
> | |
>
> | Cdcc(2,100,175,4383470) |
> Cc(2,100,176,1) |
>
> | NumOfCurrentInstances: 209
>
> 460123511| 2010/08/23
>
> 15:03:38.127| 002| SdlSig | Start |
> start
>
> | Cdcc(2,100,175,4383470) | Cdcc(2,100,175,4383470)
> |
>
> (2,100,175,4383470).1-(*:*) | [R:HP - HP: 0, NP: 2, LP: 0, VLP:
> 0, LZP: 0 DBP:
>
> 0]
>
> 460123512| 2010/08/23 15:03:38.127| 002| SdlSig |
> CcSetupInd
>
> | wait | Cc(2,100,176,1) |
> MGCPpn9cuser
>
> (2,100,124,994997) | (2,100,133,1).15084883-(*:172.25.31.3) | [R:NP - HP:
> 0, NP: 1, LP: 0,
>
> VLP: 0, LZP: 0 DBP: 0]CI=36462309 CI.branch=0 pli.plid=65 pli.l=1
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100824/af93b8f7/attachment.html>
More information about the cisco-voip
mailing list