[cisco-voip] secondary dialtone on @ route patterns (weird behaviour)
Lelio Fulgenzi
lelio at uoguelph.ca
Tue Aug 3 15:40:19 EDT 2010
yeah, i'm talking more about misconfigured phones from our end. some of the CSS's look similar (some don't) - i'm surprised with the number of mistakes made. *shrug*
---
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Cooking with unix is easy. You just sed it and forget it.
- LFJ (with apologies to Mr. Popeil)
From: "Wes Sisk" <wsisk at cisco.com>
To: "Lelio Fulgenzi" <lelio at uoguelph.ca>
Cc: "Ryan Ratliff" <rratliff at cisco.com>, "Mike Norton" <mikenorton at pwsd76.ab.ca>, "cisco-voip voyp list" <cisco-voip at puck.nether.net>
Sent: Tuesday, August 3, 2010 3:04:37 PM
Subject: Re: [cisco-voip] secondary dialtone on @ route patterns (weird behaviour)
possibly a little less intuitive but what about setting autoregistered devices to use a specific css. in that css have a partition that contains a translation pattern that is just X with urgent priority (in CM older versions all TP are urgent priority by default).
User experience should be that the translation pattern is matched (and selected) when the first digit (any digit) is dialed.
/Wes
On Tuesday, August 03, 2010 2:56:03 PM, Lelio Fulgenzi <lelio at uoguelph.ca> wrote:
For the interest of the archives...
It turned out two things were at play here, 7 digit dialing and a 0 translation in the <none> partition. By adding a specific route filter on my @ route pattern, I was able to get the desired results, i.e. no extra dialtone. These specific filters basically said area code exists, local area code exists, etc.
Now I just have to get all the DNs out of the none partition (including the 0) and I think that will fix things up.
I liked the idea of having numbers in the <none> partition that way if a phone was mis-configured, they could at least dial for help.
Oh well.
---
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Cooking with unix is easy. You just sed it and forget it.
- LFJ (with apologies to Mr. Popeil)
From: "Lelio Fulgenzi" <lelio at uoguelph.ca>
To: "Ryan Ratliff" <rratliff at cisco.com>
Cc: "Mike Norton" <mikenorton at pwsd76.ab.ca> , "cisco-voip voyp list" <cisco-voip at puck.nether.net>
Sent: Monday, February 8, 2010 1:24:17 PM
Subject: Re: [cisco-voip] secondary dialtone on @ route patterns (weird behaviour)
he he he
i'll definitely look at using DNA to see if I'm hitting any onnet patterns.
---
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Cooking with unix is easy. You just sed it and forget it.
- LFJ (with apologies to Mr. Popeil)
----- Original Message -----
From: "Ryan Ratliff" <rratliff at cisco.com>
To: "Lelio Fulgenzi" <lelio at uoguelph.ca>
Cc: "Mike Norton" <mikenorton at pwsd76.ab.ca> , "cisco-voip voyp list" <cisco-voip at puck.nether.net>
Sent: Monday, February 8, 2010 1:20:54 PM GMT -05:00 US/Canada Eastern
Subject: Re: [cisco-voip] secondary dialtone on @ route patterns (weird behaviour)
That's what we call "fixing" vs "resolving" a problem :)
-Ryan
On Feb 8, 2010, at 1:17 PM, Lelio Fulgenzi wrote:
Ya know, it's interesting you bring that solution up. A few years back when I tried this, that's exactly what I did, a blank translation with 9 prefix. But that was it.
I'll have to try that out and see how it works.
---
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Cooking with unix is easy. You just sed it and forget it.
- LFJ (with apologies to Mr. Popeil)
----- Original Message -----
From: "Mike Norton" < mikenorton at pwsd76.ab.ca >
To: "Lelio Fulgenzi" < lelio at uoguelph.ca >, "Ryan Ratliff" < rratliff at cisco.com >
Cc: "cisco-voip voyp list" < cisco-voip at puck.nether.net >
Sent: Monday, February 8, 2010 1:08:40 PM GMT -05:00 US/Canada Eastern
Subject: RE: [cisco-voip] secondary dialtone on @ route patterns (weird behaviour)
What fixed it for me was in the partition that’s called PLAR9_PT in your case, I created a second translation pattern. This second translation pattern has no actual pattern – i.e., it is blank. Provide outside dial tone is checked and called party prefix digits is 9. On the other translation pattern(s) in this partition (you used “@”, I used a few [2-9]XXXXXX-style patterns), provide outside dial tone is NOT checked but called party prefix digits is still set to 9.
I don’t know why that worked or what I was smoking when I thought to try it, but it does the job. Going off-hook immediately results in “outside” dial tone.
--
Mike Norton
I.T. Support
Peace Wapiti School Division No. 76
Helpdesk: 780-831-3080
Direct: 780-831-3076
From: cisco-voip-bounces at puck.nether.net [ mailto:cisco-voip-bounces at puck.nether.net ] On Behalf Of Lelio Fulgenzi
Sent: February-05-10 8:07 AM
To: Ryan Ratliff
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] secondary dialtone on @ route patterns (weird behaviour)
There are a few in there, but none that match the patterns I'm using. It's odd. very odd. We'll see what the DNA turns up.
---
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Cooking with unix is easy. You just sed it and forget it.
- LFJ (with apologies to Mr. Popeil)
----- Original Message -----
From: "Ryan Ratliff" < rratliff at cisco.com >
To: "Lelio Fulgenzi" < lelio at uoguelph.ca >
Cc: "cisco-voip voyp list" < cisco-voip at puck.nether.net >
Sent: Friday, February 5, 2010 10:00:42 AM GMT -05:00 US/Canada Eastern
Subject: Re: [cisco-voip] secondary dialtone on @ route patterns (weird behaviour)
Don't forget the none partition, that every CSS has access to.
-Ryan
On Feb 5, 2010, at 9:48 AM, Lelio Fulgenzi wrote:
The thing is, the phone has access to only one partition with one translation, the @ translation.
I suspect because I can't mark the translation as offnet, it thinks it's an onnet number?
Funny thing is, if I just dial the number and stop before the tone would change, and wait, it errors out. So there's nothing else to match.
We're going to install the DNA at the next maintenance window.
---
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Cooking with unix is easy. You just sed it and forget it.
- LFJ (with apologies to Mr. Popeil)
----- Original Message -----
From: "Ryan Ratliff" < rratliff at cisco.com >
To: "Lelio Fulgenzi" < lelio at uoguelph.ca >
Cc: "cisco-voip voyp list" < cisco-voip at puck.nether.net >
Sent: Friday, February 5, 2010 9:38:59 AM GMT -05:00 US/Canada Eastern
Subject: Re: [cisco-voip] secondary dialtone on @ route patterns (weird behaviour)
Your traces are right on. The key with outsideDialtone is that it will be played only when every potential match has the option set to play it.
In your example you dial 1 and get PotentialMatchesExist. This combined with the fact that at your next digit you see ExclusivelyOffnetPotentialMatchesExist and you get outside dialtone tells you that there is some internal pattern being matched that starts with a 1 and doesn't include a 2 as the second digit.
Unless you can dig around and find it your best bet is to install Dialed Number Analyzer and see what it shows you for potential matches when you dial 1 from that phone.
-Ryan
On Feb 4, 2010, at 7:39 PM, Lelio Fulgenzi wrote:
p.s. CCM 4.1(3)
---
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Cooking with unix is easy. You just sed it and forget it.
- LFJ (with apologies to Mr. Popeil)
----- Original Message -----
From: "Lelio Fulgenzi" < lelio at uoguelph.ca >
To: "cisco-voip voyp list" < cisco-voip at puck.nether.net >
Sent: Thursday, February 4, 2010 6:50:11 PM GMT -05:00 US/Canada Eastern
Subject: secondary dialtone on @ route patterns (weird behaviour)
OK - Back to me trying to get phones to be able to dial off-campus without pressing 9. I am able to get things to work, but the secondary dial tone behaviour is odd. I'm hoping somebody can shed some light before I call the TAC.
Setup:
• phone w/ PLAR9_CSS on the device
• PLAR9_CSS contains PLAR9_PT partition with "@" route pattern described below
• "@" translation with 9 prefix digits w/PLAR9_Translation_CSS
• PLAR9_Translation_CSS contains existing partitions w/ 9.@ route patterns
• 9.@ route patterns are both block and route (device/line approach)
• all the existing route patterns have the provide outside dialtone checked
• partitions are:
• UoGSys_OffNet_Local_PT (for blocks)
• UoGDev_Bus_NDP_PT (for allows - site specific client specific)
• UoGDev_Def_PT (for allows - site specific)
• UoGSys_Dev_Def_PT (for allows - system wide)
The issue is this, when I dial a number the following happens, dial tone stops with the first digit, and then changes to outside dialtone somewhere during the call, then stops with the next digit.
Regardless of whether Provide Outside Dial Tone is checked or unchecked, I get the same behaviour. The only difference is when the secondary dial-tone hits. Worse case scenario is when I press 0, I get secondary dial tone until connected to the operator.
I have Digit Analysis Complexity set to Standard, so I don't see the translation matching, but what I do see it matching is the patterns in partitions listed above for long distance (blocking). I would have thought before it tried to match anything, it would wait until interdigit timeout or it matched a real number.
I'm guessing a straight @ pattern with no filter on 7digit numbers isn't helping, but I'm still not understanding why the delay in secondary dialtone when i'm not asking for secondary dial tone.
Here are some trace snippets:
blocked long distance call (1-905-851-2XXX - dialtone stops a 1 and changes at 2)
here's me pressing "1" and dialtone stops, with potentialMatches=PotentialMatchesExist. This continues until I press "2"
02/04/2010 18:05:50.851 CCM|StationInit: (0011284) KeypadButton kpButton=1.|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448172846><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:05:50.867 CCM|StationD(11284): StationCtiD - StationKeypadButton|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448172846><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:05:50.867 CCM|StationCdpc(882402): StationCtiCdpc - StationOutputStopTone to send ToneChangeNotify CH=4|68505030|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448172846><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:05:50.867 CCM|StationCdpc(882402): StationCtiCdpc - StationKeypadButton CH=4|68505030 CmSsFeature=1 ReasonForRedirection=0 OnBehalfOf=Device CallReason=1 CallState=5|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448172846><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:05:50.867 CCM|StationCdpc(882402): StationCtiCdpc - GenerateCallStateEvent CH=4|68505030 CallState=5 CmSsFeature=1 CallReason=1 CallStateChangeCause=0 RIU=0 CallSelectStatus=0 AuxiliaryData=0 Privacy=0 Feature=137 LRP= LRPName=|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448172846><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:05:50.867 CCM|StationCtiCdpc : GenerateCallStateEvent - CgPnPi=0 CgpnNamePi=1 CdpnPi=0 CdpnNamePi=0 OCdpnPi=0 OCdpnNamePi=0 LRPPi=0 LRPName=0|<CLID::UOGCCM105-Cluster><NID::10.104.96.104>
02/04/2010 18:05:50.867 CCM|StationD: (0011284) StopTone.|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448172846><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:05:50.867 CCM|StationD: (0011284) SelectSoftKeys instance=1 reference=68505030 softKeySetIndex=6 validKeyMask=ffffffff.|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448172846><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:05:50.867 CCM|Digit analysis: wait_DaReq - cepn=[] BlockFlag=[1]|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448172846><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:05:50.867 CCM|Digit Analysis: getDaRes - voiceMailCallingSearchSpace=[]|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448172846><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:05:50.867 CCM|Digit analysis: match(pi="1",fqcn="5198244120", cn="59999", plv="5", pss="UoGTEST_UoGDev_Bus_PLAR_To9_Local_PT", TodFilteredPss="UoGTEST_UoGDev_Bus_PLAR_To9_Local_PT", dd="1",dac="0")|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448172846><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:05:50.867 CCM|Digit analysis: potentialMatches=PotentialMatchesExist|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448172846><IP::10.104.25.19><DEV::SEP000F2470F3B1>
Now, as I press "2", dialtone changes because exclusive offnet matches exist? but they're all offnet!
02/04/2010 18:05:53.257 CCM|StationInit: (0011284) KeypadButton kpButton=2.|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448173127><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:05:53.257 CCM|StationD(11284): StationCtiD - StationKeypadButton|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448173127><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:05:53.257 CCM|Digit analysis: wait_DaReq - cepn=[] BlockFlag=[1]|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448173127><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:05:53.257 CCM|Digit Analysis: getDaRes - voiceMailCallingSearchSpace=[]|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448173127><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:05:53.257 CCM|Digit analysis: match(pi="1",fqcn="5198244120", cn="59999", plv="5", pss="UoGTEST_UoGDev_Bus_PLAR_To9_Local_PT", TodFilteredPss="UoGTEST_UoGDev_Bus_PLAR_To9_Local_PT", dd="19058512",dac="0")|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448173127><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:05:53.257 CCM|Digit analysis: potentialMatches=ExclusivelyOffnetPotentialMatchesExist|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448173127><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:05:53.257 CCM|LineCdpc(744902): -dispatchToAllDevices-, sigName=CcNotifyReq, device=SEP000F2470F3B1|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448173127><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:05:53.257 CCM|StationD(11284): StationCtiD - CcNotifyReq CI=68505030|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448173127><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:05:53.257 CCM|StationCdpc(882402): StationCtiCdpc - CcNotifyReq CH=4|68505030 CmSsFeature=1 ReasonForRedirection=0 OnBehalfOf=Device CallReason=1|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448173127><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:05:53.257 CCM|StationCdpc(882402): StationCtiCdpc - sendGlobalCallHandleChangeNotify CH=4|68505030 CmSsFeature=1 CallReason=1|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448173127><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:05:53.257 CCM|StationCdpc(882402): StationCtiCdpc - isAlertingToneOn Q931Signal.l=1 Q931Signal.sv=109|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448173127><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:05:53.257 CCM|StationCdpc(882402): StationCtiCdpc - StationOutputStartTone to send ToneChangeNotify CH=4|68505030 CmSsFeature=1 ReasonForRedirection=0 OnBehalf=Device CallReason=1 CallState=5|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448173127><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:05:53.257 CCM|StationD: (0011284) StartTone tone=34(OutsideDialTone), direction=0.|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448173127><IP::10.104.25.19><DEV::SEP000F2470F3B1>
and then, when i dial a local number, i see the following:
allowed local call (519-821-6XXX - dialtone stops a 5 and changes at 6)
02/04/2010 18:20:59.954 CCM|StationInit: (0011284) KeypadButton kpButton=6.|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM|StationD(11284): StationCtiD - StationKeypadButton|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM|Digit Analysis: getDaRes - voiceMailCallingSearchSpace=[]|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM|Digit analysis: match(pi="1", fqcn="5198244120", cn="59999",plv="5", pss="UoGTEST_UoGDev_Bus_PLAR_To9_Local_PT", TodFilteredPss="UoGTEST_UoGDev_Bus_PLAR_To9_Local_PT", dd="5198216",dac="0")|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM|Digit analysis: analysis results|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM||PretransformCallingPartyNumber=59999
|CallingPartyNumber=5198244120
|DialingPartition=UoGDev_Def_PT
|DialingPattern=9.@
|FullyQualifiedCalledPartyNumber=5198216
|DialingRoutePatternRegularExpression=(9)([2-9]X[02-9])(XXXX)
|DialingWhere=(LOCAL-AREA-CODE DOES-NOT-EXIST AND INTERNATIONAL-ACCESS DOES-NOT-EXIST AND LONG-DISTANCE-OPERATOR DOES-NOT-EXIST AND TRANSIT-NETWORK-ESCAPE DOES-NOT-EXIST AND LOCAL-DIRECT-DIAL DOES-NOT-EXIST AND LONG-DISTANCE-DIRECT-DIAL DOES-NOT-EXIST)
|PatternType=National
|PotentialMatches=ExclusivelyOffnetPotentialMatchesExist
|DialingSdlProcessId=(0,0,0)
|PretransformDigitString=95198216
|PretransformTagsList=ACCESS-CODE:OFFICE-CODE:SUBSCRIBER
|PretransformPositionalMatchList=9:519:8216
|CollectedDigits=5198216
|UnconsumedDigits=
|TagsList=OFFICE-CODE:SUBSCRIBER
|PositionalMatchList=519:8216
|VoiceMailbox=
|VoiceMailCallingSearchSpace=
|VoiceMailCallingSearchSpace=
|VoiceMailPilotNumber=
|AlertingName=
|RouteBlockFlag=RouteThisPattern
|RouteBlockCause=0
|InterceptPartition=
|InterceptPattern=
|InterceptWhere=
|InterceptSdlProcessId=(0,0,0)
|InterceptSsType=0
|InterceptSsKey=0
|OverlapSendingFlagEnabled=0
|WithTags=
|WithValues=
|CallingPartyNumberPi=Allowed
|ConnectedPartyNumberPi=NotSelected
|CallingPartyNamePi=NotSelected
|ConnectedPartyNamePi=NotSelected
|CallManagerDeviceType=NoDeviceType
|PatternPrecedenceLevel=Routine
|CallableEndPointName=[9ED26A67-FF56-402A-BE57-6AA8814819A5]
|PatternNodeId=[0ED210E5-2816-4292-9BDD-53D37DDADC82]
|AARNeighborhood=[]
|AlternateMatches= Information Not Available
|TranslationPatternDetails= Information Not Available
|OffNetPattern=OffNetOutsideDialtone=
|DeviceOverride=|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM|Digit analysis: callableEPName [{9ED26A67-FF56-402A-BE57-6AA8814819A5}] sent to device manager|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM|DeviceManager::star_DmPidReq - RequestName={9ED26A67-FF56-402A-BE57-6AA8814819A5} LookupName={9ED26A67-FF56-402A-BE57-6AA8814819A5}|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM|DeviceManager::findDeviceInfoGivenKey - Key={9ED26A67-FF56-402A-BE57-6AA8814819A5} Not In List|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM|DeviceManager::findDeviceInfoGivenKey - Key={9ED26A67-FF56-402A-BE57-6AA8814819A5} Not In List|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM|DeviceManager::findRemoteInfo - Name=UoGDev_OffNet_Local_NoModification_RL Key={9ED26A67-FF56-402A-BE57-6AA8814819A5}Pid=(9,105,24)|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM|Digit analysis: daResEntry found.|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM|Digit analysis: wait_DmPidRes - Name=[{9ED26A67-FF56-402A-BE57-6AA8814819A5}] cmDeviceType=[AccessDevice] Pid=RouteListControl(9,100,105,24)|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM|Digit analysis: wait_DmPidRes- Partition=[UoGDev_Def_PT] Pattern=[9.@] Where=[(LOCAL-AREA-CODE DOES-NOT-EXIST AND INTERNATIONAL-ACCESS DOES-NOT-EXIST AND LONG-DISTANCE-OPERATOR DOES-NOT-EXIST AND TRANSIT-NETWORK-ESCAPE DOES-NOT-EXIST AND LOCAL-DIRECT-DIAL DOES-NOT-EXIST AND LONG-DISTANCE-DIRECT-DIAL DOES-NOT-EXIST)],cmDeviceType=[AccessDevice], OutsideDialtone =[1], DeviceOverride=[0], PID=RouteListControl(9,100,105,24)|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM|LineCdpc(745155): -dispatchToAllDevices-, sigName=CcNotifyReq, device=SEP000F2470F3B1|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM|StationD(11284): StationCtiD - CcNotifyReq CI=68505529|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM|StationCdpc(882671): StationCtiCdpc - CcNotifyReq CH=4|68505529 CmSsFeature=1 ReasonForRedirection=0 OnBehalfOf=Device CallReason=1|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM|StationCdpc(882671): StationCtiCdpc - CcNotifyReq CH=4|68505529 CmSsFeature=1 ReasonForRedirection=0 OnBehalfOf=Device CallReason=1|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM|StationCdpc(882671): StationCtiCdpc - sendGlobalCallHandleChangeNotify CH=4|68505529 CmSsFeature=1 CallReason=1|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM|StationCdpc(882671): StationCtiCdpc - sendGlobalCallHandleChangeNotify CH=4|68505529 CmSsFeature=1 CallReason=1|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM|StationCdpc(882671): StationCtiCdpc - isAlertingToneOn Q931Signal.l=1 Q931Signal.sv=109|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM|StationCdpc(882671): StationCtiCdpc - isAlertingToneOn Q931Signal.l=1 Q931Signal.sv=109|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM|StationCdpc(882671): StationCtiCdpc - StationOutputStartTone to send ToneChangeNotify CH=4|68505529 CmSsFeature=1 ReasonForRedirection=0 OnBehalf=Device CallReason=1 CallState=5|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM|StationCdpc(882671): StationCtiCdpc - StationOutputStartTone to send ToneChangeNotify CH=4|68505529 CmSsFeature=1 ReasonForRedirection=0 OnBehalf=Device CallReason=1 CallState=5|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
02/04/2010 18:20:59.954 CCM|StationD: (0011284) StartTone tone=34(OutsideDialTone), direction=0.|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::4,100,119,1.448274868><IP::10.104.25.19><DEV::SEP000F2470F3B1>
---
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Cooking with unix is easy. You just sed it and forget it.
- LFJ (with apologies to Mr. Popeil)
_______________________________________________
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/20100803/f0a2e052/attachment.html>
More information about the cisco-voip
mailing list