Multiple RTP pools for Asterisk
In Asterisk’s current state, it supports one RTP pool from which it selects a random pair of ports (RTP and RTCP) for each leg of a call. As part of a project at work, we need Asterisk to support multiple pools of RTP ports — specifically one pool for local calls and one pool for calls which have a leg on an external network. The reasoning behind this being that local calls only funnel their RTP traffic through Asterisk for a short amount of time and then the phones re-INVITE each other, cutting Asterisk out of the picture. Since there’s so little involvement with Asterisk for local calls, we’re ok with having a fairly large pool of RTP ports available (and therefore calls that can be initiated) without worrying about stressing our Asterisk system.
This isn’t the case when we have a call involving a remote leg, where all RTP traffic is running through the Asterisk system. Since we want to have a large RTP pool for local calls and RTP pairs are chosen randomly, we’re unable to simply use a firewall to limit how many connections can be made to the system. Doing so would risk having the external phone instructed to use a firewalled port and therefore lose half of the audio stream.
To address this, I submitted a patch for Asterisk to have a concept of two RTP pools. I left the current pool and its configuration alone and added the ability to optionally specify a “remote” pool. The patch comes in two parts. The first enables configuring the remote RTP pool (specified by the remotertpstart and remotertpend config vars in rtp.conf) as well as providing new functions to create an ast_rtp struct using the remote pool. By default, everything acts as before — the remote pool is the same as the local pool. The second part changes chan_sip to make use of the new remote RTP pool if it detects a remote leg and localnet/externip are set in sip.conf.
Since I think this functionality could be useful outside of my work environment and I’m fairly new to fiddling with Asterisk’s internals, I’d appreciate any feedback on the patch itself and/or actual usage of the feature. As implied above, my patches will only affect SIP calls. Support for other channels would have to be added (if it makes sense).