<div dir="ltr">Thanks Nathan for the lookup number! It does exactly what I wanted. I'll update my notes.<div><br></div><div>~Jared</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 16, 2016 at 4:01 PM, Kraig Beahn <span dir="ltr"><<a href="mailto:kraig@enguity.com" target="_blank">kraig@enguity.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Looks like <a href="http://800forall.com" target="_blank">800forall.com</a> is run by CSF Corporation, which, if i'm not mistaken has a mechanized interface to SMS/800. <div><br></div><div>Can't remember what CSF's mechanized or "automated query pricing" was at the time (and probably couldn't disclose it anyway, due to NDA's) but if you compare it to SMS/800's direct MGI costs, i'm pretty sure you get the idea of where the "pricing model", at least at the time, hence why better interfaces don't exist.<div><br></div><div><b><u><font color="#ff0000">Non-Recurring Charges</font></u></b></div><div>$342,884.00 - Mechanized Generic Interface Testing, per Resp Org Company </div><div>$212,015.00 - Initial Installation Testing, Per Interface, Per Resp Org Company</div><div><br></div><div><b><u><font color="#ff0000">Recurring SMS/800 Charges</font></u></b></div><div>$512.77 - SMS/800 MGI Access - Per Port </div><div><br></div><div>We had evaluated implementing a mechanized SMS/800 interface ourselves to develop a CNAM-like query system to use in our regular call-flow and transition systems back in 2002ish, reevaluated such in 2006ish and the cost "just to talk to someone" was in-line with what it would cost to interface directly to NASDAQ's trading systems for monetary transfer purposes. </div><div><br></div><div>If the cost either direct via the SMS/800 API or through a mechanized API aggregator like CSF would come down to more realistic "interface costs", I think they would see a significant increase in query volume, and in turn, overall revenue. It would be a great tool that, in my opinion, would become more widely integrated into not only the TFN transfer process, but day-to-day per-call transactional activities, as well.</div><div><br></div><div>-Just a thought<img src="https://t.yesware.com/t/eb6d9d6b31412045cb763bde159eae39bedfa8b8/d5a7c896f79a915d0742d143d30e7b7f/spacer.gif" style="border:0px;width:0px;min-height:0px;overflow:hidden" width="0" height="0"><img src="http://t.yesware.com/t/eb6d9d6b31412045cb763bde159eae39bedfa8b8/d5a7c896f79a915d0742d143d30e7b7f/spacer.gif" style="border:0px;width:0px;min-height:0px;overflow:hidden" width="0" height="0">, if anyone is interested in revisiting the concept, assuming the cost as subsided dramatically, please reach out to me, directly.<font face="yw-eb6d9d6b31412045cb763bde159eae39bedfa8b8-d5a7c896f79a915d0742d143d30e7b7f--to"></font></div><div><br></div><div>---------------</div><div><b>From the SMS/800 Tariff F.C.C. No 1:</b></div><div><br></div><div><b>3.3.3 </b>Mechanized Generic Interface (MGI) Access Requirements<br></div><div><br></div><div><div>The Resp Orgs may also elect to interface with the SMS/800 on a mechanized basis. The SMS/800 Mechanized Generic Interface (MGI) facilitates the transfer of number administration and customer record administration data between SMS/800 and other Operations Systems (OSs) belonging to the Resp Org in order to support the various operations functions performed by SMS/800. The interface is a two-way interface in the sense that data will flow to and from an  S. The SMS/800 to OS interface consists of five protocol layers: (1) the physical layer; (2) the link layer; (3) the packet layer; (4) a User Application Layer (UAL); and (5) the User Program Layer (UPL). The physical, packet, and link layers comprise the Transport Service, which provides an error-free communication path for the transfer of data between sites. It relieves application layers of any concern about the way in which reliable data transfer is achieved. UAL  provides the Application Service functionality, which performs the necessary high-level protocol functions not supplied by the Transport Service. The functionality includes request/reply correlation, site-to-site confirmation, message  queuing, message priority, message segmentation, and system or link failure/recovery. The UPL is concerned with the specific application messages themselves. </div></div><div><br></div><div>---------------<br></div><div><br></div><div>Lastly - For the daringly creative developer types of our community, Telcordia also has a document (#SR-4959) which fully describes the SCP-SMS/800 TCP/IP Interface Specifications.</div><div><br></div><div><br></div></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Mon, May 16, 2016 at 6:12 PM, Tim Jackson <span dir="ltr"><<a href="mailto:jackson.tim@gmail.com" target="_blank">jackson.tim@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><a href="http://www.800forall.com/" target="_blank">http://www.800forall.com/</a><br><div><br></div><div>Seems to return the right RespOrgs..</div><div><br></div><div>--</div><div>Tim</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Mon, May 16, 2016 at 5:08 PM, Jared Geiger <span dir="ltr"><<a href="mailto:jared@compuwizz.net" target="_blank">jared@compuwizz.net</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">I used to use the Ameritech Resporg line to get the Resporg ID for a number to use for porting. After that number went away, I used a website. However now instead of the ID, the website returns the Company Name.<div><br></div><div>Are there any public lookups for the Resporg ID left?</div><span><font color="#888888"><div><br></div><div>~Jared</div></font></span></div>
<br></div></div>_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div dir="ltr"><img src="http://cdn.enguity.com/eng/enguity-kraig-beahn-signature.png"><br></div></div>
</font></span></div>
<br>_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
<br></blockquote></div><br></div>