[c-nsp] Question about ip rtp header-compression

[Ziv Leyes]

The problem is I'm not using NONE of the possible queuing strategies at all right now! So why the line can't just use the whole 2Mb for RTP?
My question wasn't about if you want to dedicate a specific bandwidth with some QoS policy then you'll be obviously limited to 75% or 80% of the total bandwidth, because the router needs to save some bandwidth for the rest. I'm talking about if there's a limitation on the bandwidth utilization that the ip rtp header-compression can use, even before implementing any queuing strategy or policy.


Ziv

-----Original Message-----
From: Adrian Chadd [mailto:adrian at creative.net.au]
Sent: Tuesday, February 05, 2008 1:11 PM
To: Ziv Leyes
Cc: [c-nsp]
Subject: Re: [c-nsp] Question about ip rtp header-compression

Well, Satellite IP is a fun task in itself to get right.

I'd suggest looking at QoS policy/class maps and getting yourself up to scratch
on the different methods of queueing that are available.

There's plenty of good documentation on QoS and the Cisco Way Of Doing It
on the Cisco website. Go look for policy-map and class-map.




Adrian

On Tue, Feb 05, 2008, Ziv Leyes wrote:
> Hi,
> I have a problem I can't figure out myself.
> I have two 7206VXR connected between them with serial interface over satellite. The bandwidth is 2Mb (clockrate of the controller shows 2047212 on both sides)
> This link is exclusively used for VoIP, and the ip rtp header compression is activated on both sides with a very nice successful statistics, such as 99% hit ratio and around 2,50-3,00 efficiency improvement factor.
> The customer still complains about several VoIP packet loss, and in the line graphs you can see the line never exceeds the 1500-1600 Kb.
> I wanted to try to improve the rtp traffic so I thought about using "ip rtp priority 13000 16383 2000" just to give it a try, but it gave an error saying "IP RTP: Not enough bandwidth: available 1500 needed 2000"
> Then I realized there is a hard limit of 1500 for the IP RTP, and I wonder, where is this limit coming from? Perhaps the changes on the queuing strategy or in the QoS in the past made the router go crazy and not to detect the real bandwidth, or there's some specific IOS limitations in order to keep some bandwidth available for other needs?
> If someone can shed light on this "mystery" I'll be more than glad to hear!
> Thanks,
> Ziv
>
>
>
>
>
> ************************************************************************************
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
> ************************************************************************************
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

--
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -





************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************





 
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************