[cisco-voip] User Inadvertently Reaches Intercom

[Nick Matthews]

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