The remotely (or locally-)powered router approach makes sense, but creates a way to the inside that has to be protected.
The risks of that approach is that someone learns or leaks the information about the phone number - or maybe somebody calls in by mistake (or through wardialing, à la Wargames) - and the router is left powered.
So I'd say that
- the router cannot be powered just by "a phone call". At the very least
the device has to recognize the calling number(s) and/or the contents of
a SMS with a password (that will have to be maintained and updated as
all other passwords).
- as an improvement of the above, the SMS might also specify the IP range
to accept inbound connections from.
- whatever happened has to be logged, and possibly checked against a registry
or schedule of maintenance checks, so that an anomaly can be detected.
- 20 minutes of call is not so big a load of data. The router might then
also log and store the whole traffic, just in case.
With off-the-shelf components, a SMS dial-in system can be set up with the hardware equivalent of a PC, a SMS board/modem, a relay board, and a router, that has a list of allowed phone numbers. In this scenario the router would be powered on at all times (for firewall programming, maintenance, firmware updates and such routine checks), but the connection to the outside would be physically disconnected through the relay board. The workflow would be:
- the SMS board receives a SMS
- the "guardian" system analyzes the SMS and validates the sender number,
the text contents and the requested IP range
- the "guardian" system performs diagnostic checks on the router and
builds and uploads the new route
- the "guardian" system opens a SSH shell on the router interface
- the relay board physically connects the router inbound data line
- the user from the allowed IP range can now access the SSH login
- the "guardian" system monitor the connection for timeouts, problems, and other anomalies. There should also be a maximum time after which the router is disconnected no matter what. And finally, when "disconnected", the guardian would check that the route is indeed physically down by interrogating the router diagnostics.
(If one wanted, the "guardian" system could even be made up of two independent systems, one with all of the above except the SSH server, the other acting as a firewall to the inside of the network. The first system could then sniff all of the traffic and there could be no way of accessing it except from a local console)
UPDATE Most of the above is (almost) readily available using scripting on an Android device offering an access point. A SMS from an approved source will activate the data link, the WiFi access point and a DynDNS update. Then an IP will become available to run a shell (and a VPN) on, albeit the data speed would be limited to that available to the telephone carrier.