Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

IPMA - serious problems when multiple shared lines at remote site

CallManager 4.1(3) at a central site, trying to simultaneously ring IPMA assistants which are in shared line mode at a remote site.

Because there are 10 lines at the remote office, CallManager causes a burst of SCCP messages, exceeding the reserved bandwith. As a result some messages get dropped or delivered out of order (due to TCP retransmission). This causes erratic behavior among the remote assistants' IP phones.

1) Is this a known problem with a fix?

2) What are the design guidelines about maximum number of “remote site” IPMA assistants that can be in shared line mode?

3) How much bandwidth (for SCCP signaling messages) must be allocated per IPMA assistant, in shared line mode, at a remote site ?

  • IP Telephony

Re: IPMA - serious problems when multiple shared lines at remote

If you check SRND guide we have some calculations for SCCP traffic.')">')">')">

Scroll down to the section titled:

Considerations for Shared Line Appearances

The main idea here is that 100 phones will each require about 4

packets (assuming SCCP, and 6.x). That is 400 packets generated quasi-

simultaneously by the UCM server (assuming they are all in the same

device pool). By default, your WAN interface will be able to accept 64

of those packets (coming in at 100, or 1000Mbps). The time it takes to

serialize 1 packet may be more than the time it takes CUCM to generate


So the tail end of the 400 packet train will be dropped. Enevtually re-

transmitted, yes, but perhaps too late to avoid the perception of some

phones "lagging" in their response to UCM stimuli: they may ring late,

not ring at all if another phone picks up rapidly and all ringing is

cancelled, they may even re-register if the re-xmit sequences exceed

allowable limits.

Increasing the queue depth is the only weapon. Increasing BW is less

effective, unless you can approach the BW that connects CUCM servers

to the WAN router.

Few Shared line restrictions

1) Do not use shared lines for Cisco Unified Communications Manager

Attendant Console pilot points or hunt group members. The phone that

acts as the attendant console supports shared lines.

2) Do not use shared-line appearances on any Cisco Unified IP Phone that

requires autoanswer capability and do not turn on auto answer for a

shared-line appearance.

3) Do not configure shared-line appearances on the primary lines of the

phones; for example, if two phones have a shared-line appearance, only

one of the phones should have the primary line configured as shared (the

other phone should have the secondary line configured as shared).

Barge, cBarge, and Privacy work with shared lines only.

4) Cisco recommends that you do not configure shared lines for Cisco

Unified IP Phones, H.323 clients, and MGCP POTS phones; likewise, Cisco

recommends that you do not configure shared lines for H.323 clients and

MGCP POTS phones. If you configure the same shared-line appearance for a

H.323 client, a MGCP POTS phone, for example, NetMeeting, and a Cisco

Unified IP Phone, you cannot use the hold/resume feature on the H.323

client or MGCP POTS phone.

5) Cisco recommends that you do not configure shared lines for Cisco

Unified IP Phones 7905, 7912, 7940, and 7960 that are running SIP

because these phones cannot pick up held calls on shared lines nor can

they use the shared-line features Single Button Barge/cBarge, Barge,

cBarge, and Privacy.

6) Cisco Unified IP Phones 7906, 7911, 7941, 7961, 7970, and 7971 that

are running SIP have the capability of supporting multiple lines with

the same directory number in different partitions. However, configuring

and using other SIP phones with multiple lines with the same directory

number is not supported.

With info provided you should be able to answer your questions, its bot really IPMA dependant but shared line and BW issue.

The shared line may not be the best design for your remote sites, you may think in other strategy like Line group with non-broadcats algorithm.

You can contact PDI team which should be able to help you in the Design of the site.


New Member

Re: IPMA - serious problems when multiple shared lines at remote

Thanks for the detailed response. I agree that this is a shared line and limited bandwith issue..

1) What is “Line group with non-broadcast algorithm”?

- Is this a method we can utilize on the CallManager 4.1?

- Where can I find documentation about it?

1) You mention "increasing the queue depth as ... weapon". How can we calculate the minimum amount of queue depth we need?


New Member

Re: IPMA - serious problems when multiple shared lines at remote


I am experiencing a similar issue whereby i have a two remote sites on the same cluster (6.X) and a shared line amongst 10 phones. Of the 10 phones, one phone is located at a remote site and the other 9 are on the same site. The 9 phones ring simultaneously but the one at the other remote site will not. I have checked the CSS & PT etc its all correct.

In your post you listed the recommendations from Cisco regarding shared lines, is there a document i can find this information as i cannot see it in any of the above, thanks.

New Member

Re: IPMA - serious problems when multiple shared lines at remote

I found it..

This widget could not be displayed.