For 4 calls using G729 you would provision (24 * 3) + 40 = 112kbps. The reason is when a call is made from a HQ phone to a BR1 phone UCM knows that G729 is being used based on Region but until the Called Party ANSWERS the call UCM is unaware of the sampling rate to be used in the call.
As a result UCM assumes the worst case scenario which is 10ms. By worst case we mean the sampling rate that consumes the most bandwidth. IP/UDP/RTP: 40 bytes G729 (10ms): 10 bytes Packets per second: 100 Bits per bytes: 8 (40+10) * 8 * 100 = 40kbps After the call has been ANSWERED then UCM adjusts the amount of bandwidth RSVP has reserved since by default the sampling rate is 20ms. IP/UDP/RTP: 40 bytes G729 (20ms): 20 bytes Packets per second: 50 Bits per bytes: 8 (40+20) * 8 * 24 = 24kbps Debug ip rsvp signaling will show the above occurring. As a best practice Cisco recommends that you use the ACTUAL bandwidth required in all cases except for one of the calls which should use the worst case scenario. If you have 10 calls over the WAN 9 calls should assume the actual bandwidth and the nth (10th) call should use the worst case scenario. -- Vik Malhi CCIE #13890 Senior Technical Instructor - IPexpert, Inc. Telephone: +1.810.326.1444 Fax: +1.810.454.0130 Mailto: [email protected] Join our free online support and peer group communities: http://www.IPexpert.com/communities IPexpert - The Global Leader in Self-Study, Classroom-Based, Video-On-Demand and Audio Certification Training Tools for the Cisco CCIE R&S Lab, CCIE Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and CCIE Storage Lab Certifications. From: Bas Janssen <[email protected]> Date: Wed, 18 Nov 2009 18:06:41 +0100 To: OSL Group <[email protected]> Subject: [OSL | CCIE_Voice] Qustion v3 volume 1 lab 10 Hi, At this moment I am working on lab 10, rsvp based location in combination with LLQ I notice that I use 51000bps for one call from 5002 to 1002, codec is G729. I don't understand the reason for this. I am also confused about the solution in the Proctor Guide. The PG states that you have to provision 2 x 24 (26)+ 40Kbit for LLQ, however the SRND CUCM v7 page 3-65 states that you have to provision 3 x 24 + 40 for four calls. So with two calls I expect 1 x 24+40 What is the correct answer here? If I consider the output then the PG answer is the correct one. Unfortunately I can't test with a second call, because the T1 from BR1 pod 15 does not work. Has anybody seen this before? Am I overlooking something? regards, Bas BR1-RTR#sh int s0/0/1:0 Serial0/0/1:0 is up, line protocol is up Hardware is GT96K Serial MTU 1500 bytes, BW 1536 Kbit/sec, DLY 20000 usec, reliability 255/255, txload 8/255, rxload 1/255 Encapsulation FRAME-RELAY IETF, loopback not set Keepalive set (10 sec) CRC checking enabled LMI enq sent 1294, LMI stat recvd 1293, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE segmentation inactive FR SVC disabled, LAPF state down Broadcast queue 0/64, broadcasts sent/dropped 1645/0, interface broadcasts 1426 Last input 00:00:02, output 00:00:00, output hang never Last clearing of "show interface" counters 03:35:44 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 1000 bits/sec, 0 packets/sec 30 second output rate 52000 bits/sec, 100 packets/sec 9141 packets input, 1443899 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 1 giants, 0 throttles 1 input errors, 1 CRC, 0 frame, 0 overrun, 0 ignored, 1 abort 473238 packets output, 31062966 bytes, 0 underruns 0 output errors, 0 collisions, 7 interface resets 0 unknown protocol drops 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions Timeslot(s) Used:1-24, SCC: 1, Transmitter delay is 0 flags BR1-RTR#sh sccp con sess_id conn_id stype mode codec ripaddr rport sport 33559461 33554549 mtp sendrecv pass_th 192.168.10.22 28216 18130 33559461 33554547 mtp sendrecv pass_th 10.10.200.3 17360 18938 Total number of active session(s) 1, and connection(s) 2 BR1-RTR#sh policy-map int s0/0/1:0.1 Serial0/0/1:0.1: DLCI 101 - Service-policy output: AutoQoS-Policy-UnTrust queue stats for all priority classes: queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 0/0 Class-map: AutoQoS-VoIP-RTP-UnTrust (match-any) 150468 packets, 9629952 bytes 30 second offered rate 51000 bps, drop rate 0 bps Match: protocol rtp audio 150468 packets, 9629952 bytes 30 second rate 51000 bps Priority: 65 kbps, burst bytes 1600, b/w exceed drops: 0 QoS Set dscp ef Packets marked 150468 BR1-RTR#sh ip rsvp int interface rsvp allocated i/f max flow max sub max Se0/0/1:0 ena 24K 1152K 1152K 0 Se0/0/1:0.1 ena 24K 80K 80K 0 Lo0 ena 0 80K 80K 0 BR1-RTR# Windows Live: Make it easier for your friends to see what you¹re up to on Facebook. <http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/so cial-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_2:092009 > _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
