There are a few possible solutions to this, depending on just how picky the hardware in question is and how much control the embedded systems give you.
My experience here comes from running a Worldgroup BBS on Windows for awhile, and from time working with TDD (as in Telecommunications Device for the Deaf)-compatible modems. I can help you on the hardware side, software-side's a little out of my league, but actually the easier part probably.
A couple key concepts here:
- Modems don't actually NEED a dial tone to dial - And many don't need voltage provided by the power line, either, and will work in what's called a 'dry line', in this case, a telephone cord run directly from modem to modem.
Other modems may require voltage on the line, which isn't difficult to do, but does raise the difficulty from "just plug it in" to "make a thing that provides voltage, and plug it in". I believe this thing (called a line simulator, for the purpose of Googling it) needs to put out 24V at about 24ma, but my electronics skills are hilariously rusty, and this link has all the details with the added advantage of not being my guesswork: http://www.jagshouse.com/modem.html
The modem dial string doesn't typically change here, but you may need to try something like "X3" in the init string to make the modem ignore dial tone state.
For this, ATX3DT0 is a perfectly viable dial string if you can't change the actual init string, but can change the dial string instead.
- AT - Attention, prefixes any modem command.
- X3 - Sets modem to ignore dialtone.
- DT - dial with DTMF touch tones (DP would dial with pulse, like a rotary phone).
- 0 (zero) just sends the digit 0 as the chosen dial type, sometimes needed to actually pick up the line and do something, on some modems.
All the receiving system needs to do is issue ATA (attention, Answer) to the modem to make it pick up and start trying to handshake. Then, it's just a matter of the connection being passed to a PPP-speaking service to relay the connection as needed. If you can get your equipment to dial into a plain line, and type ATA on an answering computer in a terminal program, get CONNECTED to display on both ends, and see text going back and forth over that connection, you would be able to leave the telephone company out of it entirely.
When I was testing with dry lines and needed to have my connection picked up, I just configured my server to pick up the line with ATA in a loop, which will try to handshake with the dialing modem until the modem's timeout value (usually 60 seconds), drop the line and display a message (I THINK it was NO CARRIER, same as when you hung up, but I may be wrong - this WAS ages ago).
Unfortunately, this is where my practical, hands-on knowledge of how to set this up ends. I've never configured or ran any sort of standalone PPP server, aside from Worldgroup, which was just set up and go. It's also ancient history, thousands of dollars at the time for the configuration we had, and not a viable solution in your case.
Odds are, the equipment there is speaking PPP, which Windows software exists to handle inbound connections for. Windows server editions almost certainly allow dial-in to with PPP and connection sharing.
The biggest complication here is there's nothing in a dry pair telling the receiving computer to answer. This is also true if you insert voltage onto the line, nothing's setting the line 'high' to indicate an incoming ring. If dialing happens on a schedule, you can configure your answering server to just pick up the line every few minutes starting slightly before the scheduled connection time (or if they're in perfect time sync, I'd answer 10 seconds after the embedded system is set to dial).
That said, a 486 could handle a dozen modems on Windows NT 3.51 back in 199x, so even if you are an all-Windows shop, Linux or other Unices are far better suited for this sort of task, and a $5 doorstop from Craigslist or Goodwill would handle this until the end of time, and would be the route I'd go.
Required just-after-submitting edit: Even if you had to deploy this to every end-user site with this embedded system (I wrote the above with the thinking that all the embedded systems were in a shared location, which is wrong on re-reading), it'd be a phoneline-less solution that just requires a stand-alone additional piece of hardware acting as a glorified dialup-to-ethernet adapter.