[cisco-voip] User Inadvertently Reaches Intercom
David Zhars
dzhars at gmail.com
Mon Apr 26 19:31:19 EDT 2010
I never noticed those dial peers pointing to the 0/2/x ports. Interesting,
since NONE of the 0/2/x ports have ever been active. Only recently did I
turn on 0/2/0 for the paging system. I think you're right. My limited
understanding then says if someone is dialing out on the PRI and an error
occurs (for whatever reason), the 2801 will send the call out 0/2/0 as
currently configured, which would cause the overhead page to activate.
Really strange config the more I look at it! It would make more sense to
route the call out 0/1/x as those are connected to POTS lines.
Thanks everyone!
David
On Mon, Apr 26, 2010 at 2:57 PM, Nick Matthews <matthnick at gmail.com> wrote:
> I would kill dial peer 101. If you received a failure code on your
> pri, it would re route to your next dial peer. You may want to adjust
> the gatewat so it doesn't reroute on that particular error code.
>
> -nick
> On Monday, April 26, 2010, David Zhars <dzhars at gmail.com> wrote:
> > Sorry, I was substituting # so I didn't have to type "number". She does
> not dial the hash key at the end of dialing.
> > You are correct, I could not duplicate the issue when I tried calling
> (the call went right through to the end user's cell phone and the end user
> answered).
> >
> > Gateway config:
> >
> > !! Last configuration change at 10:51:37 edt Fri Apr 23 2010
> > ! NVRAM config last updated at 10:51:55 edt Fri Apr 23 2010
> > !
> > version 12.4
> > service timestamps debug datetime msec localtime
> > service timestamps log datetime msec localtime
> > service password-encryption
> > service sequence-numbers
> > !
> > hostname noname-2801
> > !
> > boot-start-marker
> > boot system flash:c2801-spservicesk9-mz.124-22.T.bin
> > boot-end-marker
> > !
> > logging message-counter syslog
> > logging buffered 4096 informational
> > enable secret 5 $1$rDeJ$wQbhfjKKM2KiBeHquZr51
> > !
> > no aaa new-model
> > clock timezone est -5
> > clock summer-time edt recurring
> > network-clock-participate wic 1
> > network-clock-select 1 T1 0/1/0
> > dot11 syslog
> > ip source-route
> > !
> > !
> > ip cef
> > no ipv6 cef
> > multilink bundle-name authenticated
> > !
> > !
> > isdn switch-type primary-ni
> > !
> > voice class codec 100
> > codec preference 1 g711ulaw
> > codec preference 2 g729br8
> > codec preference 3 g729r8
> > !
> > voice class h323 1
> > h225 timeout tcp establish 3
> > h225 display-ie ccm-compatible
> > !
> > voice-card 0
> > !
> > !
> > archive
> > log config
> > hidekeys
> > !
> > !
> > controller T1 0/1/0
> > pri-group timeslots 9-24
> > !
> > interface Vif1
> > no ip address
> > !
> > interface FastEthernet0/0
> > no ip address
> > shutdown
> > duplex auto
> > speed auto
> > !
> > interface FastEthernet0/1
> > ip address 192.168.6.229 255.255.255.0
> > speed 100
> > full-duplex
> > !
> > interface Serial0/1/0:23
> > no ip address
> > encapsulation hdlc
> > isdn switch-type primary-ni
> > isdn incoming-voice voice
> > isdn supp-service name calling
> > no cdp enable
> > !
> > ip forward-protocol nd
> > ip route 0.0.0.0 0.0.0.0 192.168.6.210
> > ip http server
> > no ip http secure-server
> > !
> > !
> > snmp-server community hiddentext RO
> > disable-eadi
> > !
> > control-plane
> > !
> > voice-port 0/0/0
> > connection plar 2002
> > description 111-222-3223
> > caller-id enable
> > !
> > voice-port 0/0/1
> > connection plar 4074
> > description 111-222-3333
> > caller-id enable
> > !
> > voice-port 0/0/2
> > echo-cancel coverage 48
> > timing hookflash-out 500
> > !
> > voice-port 0/0/3
> > echo-cancel coverage 48
> > timing hookflash-out 500
> > !
> > voice-port 0/1/0:23
> > !
> > voice-port 0/2/0
> > !
> > voice-port 0/2/1
> > !
> > voice-port 0/2/2
> > !
> > voice-port 0/2/3
> > !
> > no ccm-manager fax protocol cisco
> > !
> > no mgcp package-capability res-package
> > no mgcp package-capability fxr-package
> > no mgcp timer receive-rtcp
> > mgcp fax t38 ecm
> > !
> > dial-peer voice 7 voip
> > preference 1
> > destination-pattern 1...
> > progress_ind setup enable 3
> > voice-class codec 100
> > voice-class h323 1
> > session target ipv4:192.168.6.1
> > incoming called-number .
> > dtmf-relay h245-alphanumeric
> > ip qos dscp cs5 media
> > no vad
> > !
> > dial-peer voice 8 voip
> > preference 1
> > destination-pattern 8...
> > progress_ind setup enable 3
> > voice-class codec 100
> > voice-class h323 1
> > session target ipv4:192.168.6.1
> > incoming called-number .
> > dtmf-relay h245-alphanumeric
> > ip qos dscp cs5 media
> > no vad
> > !
> > dial-peer voice 9 voip
> > preference 1
> > destination-pattern 4...
> > progress_ind setup enable 3
> > voice-class codec 100
> > voice-class h323 1
> > session target ipv4:192.168.6.1
> > incoming called-number .
> > dtmf-relay h245-alphanumeric
> > ip qos dscp cs5 media
> > no vad
> > !
> > dial-peer voice 10 voip
> > preference 1
> > destination-pattern 2...
> > progress_ind setup enable 3
> > voice-class codec 100
> > voice-class h323 1
> > session target ipv4:192.168.6.1
> > incoming called-number .
> > dtmf-relay h245-alphanumeric
> > ip qos dscp cs5 media
> > no vad
> > !
> > dial-peer voice 100 pots
> > preference 1
> > destination-pattern 9T
> > direct-inward-dial
> > port 0/1/0:23
> > !
> > dial-peer voice 101 pots
> > preference 2
> > destination-pattern 9T
> > port 0/2/0
> > !
> > dial-peer voice 102 pots
> > preference 3
> > destination-pattern 9T
> > port 0/2/1
> > !
> > dial-peer voice 911 pots
> > preference 1
> > destination-pattern 9911
> > port 0/0/0
> > prefix 911
> > !
> > dial-peer voice 913 pots
> > preference 4
> > destination-pattern 9911
> > direct-inward-dial
> > port 0/1/0:23
> > prefix 911
> > !
> > dial-peer voice 912 pots
> > preference 3
> > destination-pattern 9911
> > port 0/0/1
> > prefix 911
> > !
> > dial-peer voice 17 voip
> > preference 1
> > destination-pattern 6...
> > progress_ind setup enable 3
> > voice-class codec 100
> > voice-class h323 1
> > session target ipv4:192.168.6.1
> > incoming called-number .
> > dtmf-relay h245-alphanumeric
> > ip qos dscp cs5 media
> > no vad
> > !
> > dial-peer voice 11 voip
> > preference 1
> > destination-pattern 3...
> > progress_ind setup enable 3
> > voice-class codec 100
> > voice-class h323 1
> > session target ipv4:192.168.6.1
> > incoming called-number .
> > dtmf-relay h245-alphanumeric
> > ip qos dscp cs5 media
> > no vad
> > !
> > dial-peer voice 55 pots
> > description Paging for Fire
> > destination-pattern *34
> > port 0/2/0
> > forward-digits all
> > !
> > !
> > num-exp 8581 4071
> > num-exp 8812 1752
> > !
> > line con 0
> > password 7 045A081206
> > login
> > line aux 0
> > line vty 0 4
> > password 7 1416111F05
> > login
> > line vty 5 15
> > password 7 070E225847
> > login
> > !
> > scheduler allocate 20000 1000
> > ntp server 192.168.6.1
> > end
> > l
> >
> > On Mon, Apr 26, 2010 at 2:44 PM, Peter Slow <peter.slow at gmail.com>
> wrote:
> > can we see the complete configuration of your gateway, please? also,
> > did you say that you were unable to reproduce this issue when you
> > tried calling?
> >
> > Also, why did your user hit the hash key at the end of dialing?
> >
> > -Peter
> >
> > On Mon, Apr 26, 2010 at 2:36 PM, David Zhars <dzhars at gmail.com> wrote:
> >> Still getting more info from my user. Here is what she said happened
> >> (twice!):
> >>
> >> She goes to dial the cell phone person. Presses 9 so she can have an
> >> outbound line. The person's cell is fairly innocuous, no 3 and 4
> together,
> >> in fact there is no 4 in the number. Once she dials the # she gets
> this
> >> sort of automated voice that says "Per this subscriber's request this
> phone
> >> cannot accept any incoming calls. Reference # MA95285". She then hears
> a
> >> beep. Thinking this is the answering machine of the cell phone, she
> starts
> >> talking, and that's when it starts going over the intercom.
> >>
> >> I have to believe that it is the cell phone that (perhaps since it won't
> >> accept any incoming calls) is being forwarded or is itself dialing a *34
> >> code, and we pick it up.
> >>
> >> I just dialed the person's cell # and the person on the other end picked
> >> right up. So I didn't even get the message about "not accepting
> incoming
> >> calls".
> >>
> >> The crosstalk thing has some merit, but like Peter says, it would seem
> like
> >> I would be having a whole lot more complaints if that was the cause.
> Plus
> >> my user made other calls to cell phones and POTS people and none of
> those
> >> went over the intercom. I have checked my end user's phone and under
> >> "recently placed calls" I can see the cell # called, there are no *34's
> >> anywhere in there. I am going to try and do a CDR report tonight and
> see if
> >> that shows anything.
> >>
> >>
> >>
> >>
> >> On Mon, Apr 26, 2010 at 1:26 PM, Norton, Mike <mikenorton at pwsd76.ab.ca>
> >> wrote:
> >>>
> >>> Another thing... did she actually hear the person’s voicemail greeting?
> Or
> >>> did she just hear the intercom system’s pre-announce tone, assume it
> was a
> >>> voicemail beep, and start talking? If it was the latter, then you might
> just
> >>> accidentally be matching the wrong route pattern somewhere.
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> 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 David Zhars
> >>> Sent: April-26-10 11:01 AM
> >>> To: Peter Slow
> >>> Cc: cisco-voip at puck.nether.net
> >>> Subject: Re: [cisco-voip] User Inadvertently Reaches Intercom
> >>>
> >>>
> >>>
> >>> What I meant was we did not hear her dialing the phone, but we heard
> her
> >>> leaving a message for this person (since the person dialed did not
> answer).
> >>> All I can think is the cell phone she was calling was forwarded to a
> *34
> >>> speed-dial or something, and somehow we picked it up.
> >>>
> >>> It was so bizarre because when it happened, we called my user and told
> her
> >>> what happened. She figured the call didn't go through, so she placed
> the
> >>> call again, and again, we heard her leaving the message over the
> intercom!
> >>> She has since tried calling other cells and POTS and none of those have
> gone
> >>> over the intercom.
> >>>
> >>> When I look at recently dialed calls, all I see are the cell # she is
> >>> calling (which has no 3 or 4 in it!!) I have never seen anything like
> this
> >>> one, but like you said, CDR might be a
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100426/031d4959/attachment.html>
More information about the cisco-voip
mailing list