[cisco-voip] secondary dialtone on @ route patterns (weird behaviour)
Mac GroupStudy
mac.groupstudy at gmail.com
Tue Aug 3 15:38:21 EDT 2010
Wow, this is a long and convoluted discussion. I would like to add this:
with the secondary dial-tone happening late in the dial string that should
simply mean that there is an overlap between numbers with "provide outside
dial-tone" and numbers without it. For example, if I have patterns that
looks like these it would cause the outside dial tone to occur after the 5th
digit was pressed: RP1: 91803, RP2: 9.1803XXXXXX. The system doesn't know if
I am dialing the 5 digit number that begins with 9 or an outside number that
begins with 9. Once it discovers it after the 3 is dialed it would then
playback outside dial-tone.
Mac
On Tue, Aug 3, 2010 at 3:04 PM, Wes Sisk <wsisk at cisco.com> wrote:
> 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><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> <lelio at uoguelph.ca>
> *To: *"Ryan Ratliff" <rratliff at cisco.com> <rratliff at cisco.com>
> *Cc: *"Mike Norton" <mikenorton at pwsd76.ab.ca> <mikenorton at pwsd76.ab.ca>,
> "cisco-voip voyp list" <cisco-voip at puck.nether.net><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> <rratliff at cisco.com>
> To: "Lelio Fulgenzi" <lelio at uoguelph.ca> <lelio at uoguelph.ca>
> Cc: "Mike Norton" <mikenorton at pwsd76.ab.ca> <mikenorton at pwsd76.ab.ca>,
> "cisco-voip voyp list" <cisco-voip at puck.nether.net><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<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 listcisco-voip at puck.nether.nethttps://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/76a7be9b/attachment.html>
More information about the cisco-voip
mailing list