cRTP

I am early on in my UC learning but I have a question concerning cRTP that I have not seen addressed in the books I am reading. If anyone can answer here that would be great. I am wondering if cRTP provides such extreme bandwidth savings when using low bandwidth codecs such as G729 or iLBC then is there a reason not to implement it? Are there cons associated with cRTP? CPU utilization seems unlikely to me but possibly it has to check header against a table then strip header info before forwarding which would be CPU intensive? Maybe it has an error percentage that needs to be considered?

TIA

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

shodown

cRTP was needed when there were lower bandwith (less than T1) links. Today its not really used as the savings aren't worth the cost of processor cycles.

MichaelCook

Would it not be valuable even today to allow more concurrent voice sessions on existing wan connections? Or is it a case where you are more likely to max out CPU too quickly?

tokhss

simply not worth the cpu load as showdown was saying.. WAN connections are not super $$ as they used to be... at the very least, if your lucky, FiOS is around and getting 50/50 wan connection for a less than a couple hundred bucks is still amazing.

now if you have some crappy dsl connection with 768k up.. then cRTP will def save a good amount of data. Frame-relay also comes to mind .. where i work, we still have a lot of customers on 512k , T1/E1 links. bleh!

shodown

MichaelCook wrote: »

Would it not be valuable even today to allow more concurrent voice sessions on existing wan connections? Or is it a case where you are more likely to max out CPU too quickly?

Wan connections are getting faster and Faster. A lot of people are even doing there Voice Between site over the internet. It's just something that feel by the wayside.

MichaelCook

Thanks for the replies tokhss and shodown. Your points make a great deal of sense and are greatly appreciated.