Summary:	ASTERISK-10319: Separate RTP pool for remote vs. local connections
Reporter:	James McCoy (jamessan)	Labels:
Date Opened:	2007-09-17 10:25:58	Date Closed:	2011-06-07 14:03:06
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/RTP
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) remotertp.diff ( 1) remotertp-chan_sip.diff
Description:	Currently, Asterisk only has the notion of a single pool of RTP ports.  In my setup (and I doubt this is uncommon), I have phones using my Asterisk system from both the local network and remote network.  I'd like to be able to limit the number of calls that can be made to/from the remote network since my Asterisk system isn't very powerful and local<->remote calls require Asterisk acting as a middle-man for the entirety of the call.  This isn't a problem with local<->local calls because the phones REINVITE to each other and don't involve Asterisk except for SIP signaling. Simply limiting Asterisk's current RTP pool isn't an option because I don't want to impose an artificial limitation on how many local calls can be made.  Restricting the number of ports that are forwarded to Asterisk from my firewall also isn't an option as the RTP port is chosen at random and if Asterisk chooses one that I haven't forwarded, part of the audio stream is lost. To address this, I've created a patch for rtp.{c,h} which has allows the user to specify remotertpstart/remotertpend along with the rtpstart/rtpend options in rtp.conf.  I've also patched chan_sip.c to use the remote RTP pool when it detects that the call leg it is processing is an external call.
Comments:	By: Tilghman Lesher (tilghman) 2007-11-01 15:12:05 Why not simply use callgroups (i.e. the GROUP* dialplan functions) to limit a particular class of calls? By: James McCoy (jamessan) 2007-11-01 16:03:56 That's an interesting idea.  I'll have to look into whether I can easily differentiate between remote and local users in our setup. The bigger issue which I didn't mention in my initial report is that my setup uses UPnP to attempt mapping ports on the router for RTP.  With the current single RTP pool Asterisk, how many ports get configured on the router determines how many calls can be made, whether they're purely local<->local or involve a remote leg.  If I configure Asterisk to use the number of RTP ports that's acceptable to support the number of local<->local calls, then I risk Asterisk trying to use a port that wasn't mapped on the router and therefore losing voicepath. The above patches fix this problem as I can tell Asterisk "I got N ports for remote calls and you can use M ports for local calls." By: Tilghman Lesher (tilghman) 2007-11-01 16:19:13 It's an interesting concept.  I'm just not sure how useful it would be to other users.  It seems to be very specialized to your unique environment, and I think GROUP functionality is more suited to these types of limits. By: Jason Parker (jparker) 2007-11-05 17:10:00.000-0600 This method is also very chan_sip specific. I would have to agree with Corydon, that this doesn't seem like it would be very useful outside of your setup. By: Joshua C. Colp (jcolp) 2007-11-06 10:39:35.000-0600 I'm agreeing with Corydon and Qwell on this. I believe it can be accomplished using groups, and the proposed patch seems very specialized. Suspended for now, peace!