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. Are there any public lookups for the Resporg ID left? ~Jared
http://www.800forall.com/ Seems to return the right RespOrgs.. -- Tim On Mon, May 16, 2016 at 5:08 PM, Jared Geiger <jared at compuwizz.net> wrote:
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.
Are there any public lookups for the Resporg ID left?
~Jared
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Looks like 800forall.com is run by CSF Corporation, which, if i'm not mistaken has a mechanized interface to SMS/800. 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. *Non-Recurring Charges* $342,884.00 - Mechanized Generic Interface Testing, per Resp Org Company $212,015.00 - Initial Installation Testing, Per Interface, Per Resp Org Company *Recurring SMS/800 Charges* $512.77 - SMS/800 MGI Access - Per Port 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. 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. -Just a thought, if anyone is interested in revisiting the concept, assuming the cost as subsided dramatically, please reach out to me, directly. --------------- *From the SMS/800 Tariff F.C.C. No 1:* *3.3.3 *Mechanized Generic Interface (MGI) Access Requirements 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. --------------- 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. On Mon, May 16, 2016 at 6:12 PM, Tim Jackson <jackson.tim at gmail.com> wrote:
Seems to return the right RespOrgs..
-- Tim
On Mon, May 16, 2016 at 5:08 PM, Jared Geiger <jared at compuwizz.net> wrote:
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.
Are there any public lookups for the Resporg ID left?
~Jared
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
--
Thanks Nathan for the lookup number! It does exactly what I wanted. I'll update my notes. ~Jared On Mon, May 16, 2016 at 4:01 PM, Kraig Beahn <kraig at enguity.com> wrote:
Looks like 800forall.com is run by CSF Corporation, which, if i'm not mistaken has a mechanized interface to SMS/800.
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.
*Non-Recurring Charges* $342,884.00 - Mechanized Generic Interface Testing, per Resp Org Company $212,015.00 - Initial Installation Testing, Per Interface, Per Resp Org Company
*Recurring SMS/800 Charges* $512.77 - SMS/800 MGI Access - Per Port
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.
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.
-Just a thought, if anyone is interested in revisiting the concept, assuming the cost as subsided dramatically, please reach out to me, directly.
--------------- *From the SMS/800 Tariff F.C.C. No 1:*
*3.3.3 *Mechanized Generic Interface (MGI) Access Requirements
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.
---------------
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.
On Mon, May 16, 2016 at 6:12 PM, Tim Jackson <jackson.tim at gmail.com> wrote:
Seems to return the right RespOrgs..
-- Tim
On Mon, May 16, 2016 at 5:08 PM, Jared Geiger <jared at compuwizz.net> wrote:
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.
Are there any public lookups for the Resporg ID left?
~Jared
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
--
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
I asked the same question on here a few years back and got a good response: http://puck.nether.net/pipermail/voiceops/2012-December/003797.html Options have changed a little bit...888-509-9399, option 1, 2, (area code -- I use 313), 2. -- Nathan From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Jared Geiger Sent: Monday, May 16, 2016 3:09 PM To: VoiceOps Subject: [VoiceOps] Resporg lookup 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. Are there any public lookups for the Resporg ID left? ~Jared
participants (4)
-
jackson.tim＠gmail.com -
jared＠compuwizz.net -
kraig＠enguity.com -
nathana＠fsr.com