Summary:	ASTERISK-19515: Need hooks for resource to leverage for NAT hole poking for media streams
Reporter:	Philip Prindeville (pprindeville)	Labels:
Date Opened:	2012-03-11 15:47:08	Date Closed:	2012-03-13 10:38:41
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Resources/NewFeature
Versions:	SVN	Frequency of Occurrence
Related Issues:
Environment:	This is applicable when Asterisk is running co-resident on a NATting gateway.	Attachments:
Description:	It is useful for Asterisk to be able to control NAT mappings for inbound media streams, whether it is running on a NATting gateway or not (as it's possible that the streams terminate on handsets that are behind a different gateway in the case where Asterisk is hosted behind the gateway or the handsets are behind a different default gateway). There are several scenarios where this might be useful: (a) Asterisk is running on a Linux gateway itself, and a resource module (e.g. res_iptc) calls into libiptc directly to open/close NAT holes; (b) Asterisk is running on a Linux gateway is in (a), and a resource module uses fork()/exec() to invoke iptables to create new open/close NAT holes (this avoids tainting Asterisk licensing); (c) Asterisk is running behind a UPnP gateway (or even on that gateway) and uses UPnP IGD calls to open/close NAT holes (this is the most flexible but lease robust mechanism); This requires Asterisk to provide 3 hooks NAT holes for media streams: (1) make a new hole (as when a SIP INVITE is seen); (2) destroy an existing hole (as when a SIP BYE is seen); (3) replace the parameters on an existing hole with new parameters (as when a SIP REDIRECT is seen to a new end-point also behind the same gateway, i.e. on the same collection of local LANs), i.e. do a make-then-break mapping; This is not only applicable to SIP, but to other protocols that support separate signalling and media streams.
Comments:	By: Philip Prindeville (pprindeville) 2012-03-11 15:53:40.060-0500 See also: https://issues.asterisk.org/view.php?id=13833 By: Philip Prindeville (pprindeville) 2012-03-11 15:54:41.045-0500 And so it's clear, I'll write the version for scenario (a) once the hooks become available... though I might need a little help debugging the test cases as I'm not a SIP guru. By: Matt Jordan (mjordan) 2012-03-13 10:38:33.980-0500 Features requests are no longer submitted to or accepted through the issue tracker. Features requests are openly discussed on the mailing lists [1] and Asterisk IRC channels and made note of by Bug Marshals. [1] http://www.asterisk.org/support/mailing-lists If you would like to submit a patch for this feature, please contact a bug marshal and we can re-open this issue. By: Philip Prindeville (pprindeville) 2012-03-13 11:48:21.730-0500 This feature was extensively discussed both on IRC and the mailing list, and the resulting Mantis bug referenced was created: http://lists.digium.com/pipermail/asterisk-dev/2008-November/035099.html It then unfortunately stalled because of feature-creep: access control lists, etc. started to creep in, etc. This was an attempt to resurrect the same bug but focus attention to what the original intention was: a way for a resource to hook into NAT hole requests for media streams.