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. And see here for current known issues.

New Member

SIP / RTP voice limitation over a Frame-relay link ???


I am trying to determine a PVC link-line limitation between 2 frame-relay sites utilizing SIP/RTP traffic.

- We use an i3 gateway in facility A which passes SIP/rtp traffic to a receiving end audio gateway at facility B.

- There is a frame T1 at facility A with a single PVC going to a frame T1 at facility B.

- The CIR across this PVC is 1024Kbps.

- We configured policy routing to limit only RTP traffic between the 2 SIP end devices. (only RTP udp traffic traverses the PVC between facility A & B)

- We are running RTP header compression on both routers A&B.

From utilization over a 6-month period, I've noticed so far we average 27 persistent connections and between 450Kbps - 560Kbps of total PVC link utilization which includes in/outbound traffic.

We'd like to determine how many more users we can accomodate on the PVC without overtaxing the PVC. Should I follow an 80% rule and not exceed 80% of our current 1024Kbps CIR or should I not exceed 80% of the total 1544 T1 link?

We think we are getting about 23.8Kbps per user on a call.


Re: SIP / RTP voice limitation over a Frame-relay link ???


Firstly you will need to watch the CPU utilization on your Routers. Cisco don't recommend using cRTP header compression on links greater than 768k. You will need to disable it if the CPU goes above 75%.

Second, are you using Frame-Relay traffic shaping? You should be shaping to the CIR. If so the recommendation is to allocate 75% of the configured bandwidth.

I'm guessing you are using g.729a and using a 30ms sample size, if so the traffic per call sounds about right.

New Member

Re: SIP / RTP voice limitation over a Frame-relay link ???

We are using codec g723.1.

What do you mean by frame-relay traffic shaping to the CIR at 75%. Do you have an example of the config?

My processor one of the routers is between 20% to 35%. on facility A and a consistent 40% on facility B.


Re: SIP / RTP voice limitation over a Frame-relay link ???

2 seperate issues.

1. The increased call volume will increase the CPU utilization, when using RTP header compression, Cisco don't recommend using it on links above 768k. However next generation platforms such as 3700 series seem to handle the load much better than their predecessors. If it gets to high your Routers could crash!

2. Generally most frame-relay providers supply a CIR and or a EIR/PIR, this allows you to burst periodically to a max rate, only if the network is not experiencing congestion. Unless you purchased a service where the PEAK rate = COMMITTED rate, then the PIR is usually double the CIR.

Voice traffic can't use the frame network's peak or bursting ability since it is unpredictable. So you should shape the PVC to CIR which you can garantee.

See the following config

map-class frame-relay voip

frame-relay cir 256000

frame-relay bc 2560

frame-relay be 0

frame-relay mincir 256000

no frame-relay adaptive-shaping

frame-relay fair-queue

frame-relay fragment 250

frame-relay ip rtp priority 16384 16380 210

interface Serial5/0

ip address

no ip directed-broadcast

encapsulation frame-relay

no ip mroute-cache

load-interval 30

clockrate 1007616

frame-relay traffic-shaping

frame-relay interface-dlci 100

class voip

frame-relay ip rtp header-compression

frame-relay intf-type dce

In this example, RTP packets on PVC 100 with UDP ports in the range 16384 to 32764 will be matched and given strict priority service.

Configure a bandwidth that allows room for Layer 2 headers. The bandwidth allocation takes into account the payload plus the IP, UDP, and RTP headers but does not account for Layer 2 headers. Allowing 25 percent bandwidth for other overhead is conservative and safe.

The sum of all bandwidth allocation for voice and data flows on an interface cannot exceed 75 percent of the total available bandwidth, unless you change the default maximum reservable bandwidth. To change the maximum reservable bandwidth, use the max-reserved-bandwidth command on the interface.

check out this url

CreatePlease to create content