cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2095
Views
5
Helpful
13
Replies

Paging/Intercom feature with

snared04drummer
Level 1
Level 1

I have a client who had a paging feature set up by a previous third party company, and I'm trying to get some more information on exactly how this is working.

 

As far as I can tell, they have a pair of Cisco 881's set up, each with 2-4 FXS ports installed, that have have an Autoattendant DN set for each.  When they dial any of these extensions from inside, it opens up an intercom line to certain parts of the building.

 

This is where my information ends, and I'm not sure where to get started reading about this, or how to modify it, etc.

 

More specifically, I'd like to know how to modify it to have it page different devices, etc.

 

Can anyone provide some more information on how this works, or point me towards some documentation?

1 Accepted Solution

Accepted Solutions

Wilson Samuel
Level 7
Level 7

Hi,

There are basically 2 types of Paging "interfaces" or "systems"

1. IP Based (SIP Trunks usually) e.g. Singlewire products

2. Trunk Based (FXO/FXS/ISDN based) e.g. Bogen, Valcom etc

 

In either case, there is a Route Pattern towards the Paging System and is configured on them what all devices will be paged once the Call is routed to the Paging system.

In your case, it appears to be trunk based (it is my way of classifying them, please dont quote me on that), hence an FXS link.

Most of the times, it is where we as Cisco UC engineers finish our work and let the Audio/Visual techs take over ( the people who install over head speaker / music system etc), however Cisco guys (us) and A/V guys need to cordinate how exactly the paging will work .i.e. if you are creating #7970 they should also have something configured on their end else it wont work :-)

 

In case of IP Based trunks (e.g. Singlewire Informacast) it is mostly us who configure the Paging Server as well, however the end devices (e.g. regular over head speakers etc) are the responsibility of the A/V  guys, more over we will need to work with Route/Switch guys to make sure that Multicasting works across the board, as that is the protocol on which the paging works (all IP Phones etc)

 

HTH

View solution in original post

13 Replies 13

Wilson Samuel
Level 7
Level 7

Hi,

There are basically 2 types of Paging "interfaces" or "systems"

1. IP Based (SIP Trunks usually) e.g. Singlewire products

2. Trunk Based (FXO/FXS/ISDN based) e.g. Bogen, Valcom etc

 

In either case, there is a Route Pattern towards the Paging System and is configured on them what all devices will be paged once the Call is routed to the Paging system.

In your case, it appears to be trunk based (it is my way of classifying them, please dont quote me on that), hence an FXS link.

Most of the times, it is where we as Cisco UC engineers finish our work and let the Audio/Visual techs take over ( the people who install over head speaker / music system etc), however Cisco guys (us) and A/V guys need to cordinate how exactly the paging will work .i.e. if you are creating #7970 they should also have something configured on their end else it wont work :-)

 

In case of IP Based trunks (e.g. Singlewire Informacast) it is mostly us who configure the Paging Server as well, however the end devices (e.g. regular over head speakers etc) are the responsibility of the A/V  guys, more over we will need to work with Route/Switch guys to make sure that Multicasting works across the board, as that is the protocol on which the paging works (all IP Phones etc)

 

HTH

Thanks for the information.

 

However, I don't see any Route Patterns that reference the paging numbers.  Other than the Device -> Gateway -> Endpoints screens, I have found no configuration for these at all.  I'm at quite a bit of a loss.

Hi,

What type of Voice GW you have where FXS Cards are configured for Paging?

Just fyi, FXS (in case of MGCP) has no need of them, however if it is FXO card, then you may need it

HTH

There is a picture of the configuration.  It's a Cisco 881, look like the following link, except it has a separate card for the FXS ports:

 

http://img.router-switch.com/productimages/Routers/v/CISCO881-K9/CISCO881-K9.jpg

Hi

So because this is an FXS Port, it works just like a Registered Phone (861) is phone number / Ext Number hence you dont need a Route Pattern

HTH

Ok, when you pull that up under the DN search, it only shows the associated FXS port.  Would it, as you were saying earlier, be handed off to the actual intercom configuration at that point?  Aka another team that handles that equipment?

Yes. As it is an FXS port based on an MGCP GW. the call gets handed to the configured port.

Once it is on the port, the Paging Server takes the call and you are connected :-)

HTH

What's confusing about is that the configuration on the Gateway itself is almost non-existent.  The voice ports have no configurations on them, it doesn't reference these DN's in any dial peers, etc.  

Please share the GW Config and we will be happy to help you with.

Regards

#sh run
Building configuration...


Current configuration : 2275 bytes
!
version 12.4
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
!
boot-start-marker
boot-end-marker
!
logging message-counter syslog
enable secret 5 $1$SDMe$Qr51Ir11/osu.b3CLGrV5/
!
no aaa new-model
clock timezone CST -6
clock summer-time CDT recurring
!
!
ip source-route
!
!
!
!
ip cef
ip domain name cityelm.com
!
no ipv6 cef
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
voice-card 0
!
!
!


!
!
archive
 log config
  hidekeys
!
!
!
!
!
!         
interface FastEthernet0
!
interface FastEthernet1
!
interface FastEthernet2
!
interface FastEthernet3
!
interface FastEthernet4
 ip address 10.1.20.251 255.255.255.0
 duplex auto
 speed auto
!
interface Vlan1
 no ip address
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 10.1.20.254
no ip http server
no ip http secure-server
!
!
!
!
!
!
!
!
control-plane
!
!
voice-port 0
!
voice-port 1
!
voice-port 2
!
voice-port 3
!
voice-port 4
!
ccm-manager mgcp
no ccm-manager fax protocol cisco
ccm-manager music-on-hold
ccm-manager config server 10.1.10.10  
ccm-manager config
!
mgcp
mgcp call-agent 10.1.10.10 2427 service-type mgcp version 0.1
mgcp rtp unreachable timeout 1000 action notify
mgcp modem passthrough voip mode nse
mgcp package-capability rtp-package
mgcp package-capability sst-package
mgcp package-capability pre-package
no mgcp package-capability res-package
no mgcp timer receive-rtcp
mgcp sdp simple
mgcp fax t38 inhibit
mgcp rtp payload-type g726r16 static
mgcp bind control source-interface FastEthernet4
mgcp bind media source-interface FastEthernet4
mgcp behavior g729-variants static-pt
!
mgcp profile default
!
!
!         
!
dial-peer voice 1 pots
 service mgcpapp
 port 0
!
dial-peer voice 2 pots
 service mgcpapp
 port 1
!
dial-peer voice 3 pots
 service mgcpapp
 port 2
!
dial-peer voice 4 pots
 service mgcpapp
 port 3
!
dial-peer voice 5 pots
 service mgcpapp
 port 4
!
dial-peer voice 9990 pots
 service mgcpapp
 port 0
!
!
!
line con 0
 login local
 no modem enable
line aux 0
line vty 0 4
 login local
 transport input all
!
scheduler max-task-time 5000
end

Hi,

as you can see that ports have got the "service mgcpapp" which means they are being directly controlled by CCM, hence you don't see much configuration on the GW.

all control of signaling and voice is handled by CCM

HTH

Ok, that answers one important question that I had, but it raises another:

 

Where, other than the Gateway configuration mode, and the DN's that we've talked about, is the configuration for these?  Does a user dial the DN's, and it sends that traffic out the FXS port directly to the intercom equipment, and that's where CCM's interaction ends?  Is it that simple?

Yes, that is correct.

In my experience I have never touched any of the Bogen/Valcom equipment, all I have ensured that, whatever the dialing pattern (for paging) has been agreed upon, makes the call land on that specific port (FXO / FXS) and thats where the config ends.

Then, of course we do testing and it works out of the box (provided the AV guys have done their job).