Re: [VoiceOps] CABS\Intercarrier Compensation Billing

[Tim Jackson]

For all around info+vendor selection/management, etc I highly recommend
starting with CSS:

http://csscabs.com/

--
Tim

On Thu, Jul 5, 2018 at 2:25 PM, Mike Hammett  wrote:

> Right. I got the 30k foot view (apparently short of who receives the
> bill). Looking to get a bit deeper.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
>
>
> Midwest Internet Exchange
> http://www.midwest-ix.com
>
>
>
> --
> *From: *"Alex Balashov" 
> *To: *"Mike Hammett" 
> *Cc: *voiceops@voiceops.org
> *Sent: *Thursday, July 5, 2018 2:21:43 PM
> *Subject: *Re: [VoiceOps] CABS\Intercarrier Compensation Billing
>
> Intercarrier compensation of the CABS variety is where a LEC bills the
> IXC for inter-LATA calls terminated to them by that IXC.
>
> On Thu, Jul 05, 2018 at 02:19:57PM -0500, Mike Hammett wrote:
>
> >
> > My client is asking me to setup CABS billing for them. I only really see
> this being relevant to inter-carrier compensation. Where can I find more
> resources about how that works?
> >
> > Is inter-carrier compensation is something we'd be billing the tandem
> operator or each company sending us calls?
> >
> > Note: I'm primarily a data\SIP guy, but I've been thrown into telco
> hell.
> >
> >
> >
> > -
> > Mike Hammett
> > Intelligent Computing Solutions
> > http://www.ics-il.com
> >
> >
> >
> > Midwest Internet Exchange
> > http://www.midwest-ix.com
> >
> >
>
> > ___
> > VoiceOps mailing list
> > VoiceOps@voiceops.org
> > https://puck.nether.net/mailman/listinfo/voiceops
>
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] LRN API Source

[Tim Jackson]

These guys have accurate data and are cheap:

http://www.bulk911.com/cnam.html

--
Tim

On Thu, Apr 13, 2017 at 3:48 PM, Christopher Aloi  wrote:

>
> I wrote a similar internal tool using https://www.everyoneapi.com/  We've
> been using it for a few years and have never had any issues.  I've also hit
> the API with some bulk requests and the results are great.
>
> +13212051100 <(321)%20205-1100>
> Name: Florida High Speed Internet | Internet Services
> CNAM: FLHSI
> Line Type: landline
> Line Provider: Hook Mobile (Sybase) ()
> Current Carrier: Terra Nova Telecom (382G)
> Original Carrier: tw telecom (7635)
> Location: 1311 Bedford Dr Melbourne FL 329401975
> Gender:
> Education:
> Occupation:
>
>
>
>
> On Thu, Apr 13, 2017 at 4:41 PM Nick Olsen  wrote:
>
>> Greetings all,
>>
>> We've got an internal tool that lets my NOC staff query extended LRN on
>> numbers. They use this for checking the numbers current carrier, Verifying
>> a number after it ports (In or out)..etc. This same tool also pulls CNAM
>> from a few sources so they can easily test "Wrong caller ID" tickets.
>>
>> Does anyone have any good leads on someone that has a good non-cached LRN
>> API?
>>
>> We've tried two thus far with poor results.
>>
>> 1. "CallWithUs", Real time results, But cached for 24 hours after the
>> first request. So if we wanted to check a number more then once a day, We
>> get the same results.
>>
>> 2. ThinQ. Results returned are either cached, Or perhaps outdated.
>> Querying a number after it ports returns the old LRN. Results do not update
>> until 24 hours after port. Since we have a decent bit of traffic on ThinQ,
>> And a decent relationship with them I opened a ticket to see if it could be
>> a adjusted. First was told that LRN takes 24 hours to update. And that was
>> normal. I pushed back on the obvious canned and incorrect response and they
>> "made some changes" which did nothing. Finally they admitted they could not
>> return real-time results.
>>
>> Many of my upstream carriers are using Syniverse as their LRN source. So
>> I reached out to them. Found my volume (~20 queries a day) is too low for
>> them. And they don't offer any type of HTTP API, Understandably on both
>> counts.
>>
>> Example output of our internal tool. (Queried 13212051100
>> <(321)%20205-1100>)
>>
>> Latest CNAM / LRN Lookup Refresh
>> 
>> (OPCN) CNAM FLHSI
>> (Thinq) CNAM FLHSI
>> LRN 4078675999 <(407)%20867-5999>
>> State FL
>> Rate Center ORLANDO
>> LATA 458
>> OCN 382G
>> Company TERRA NOVA TELECOM, INC. - FL
>> Request Timestamp 2017-04-13 16:40:19
>>
>> *Nick Olsen*
>> Sr. Network Engineer
>> Florida High Speed Internet
>> (321) 205-1100 x106 <(321)%20205-1100>
>> 
>>
>>  
>>
>>
>> ___
>> VoiceOps mailing list
>> VoiceOps@voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
>>
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Resporg lookup

[Tim Jackson]

http://www.800forall.com/

Seems to return the right RespOrgs..

--
Tim

On Mon, May 16, 2016 at 5:08 PM, Jared Geiger  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@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Suspect NPANXX question

[Tim Jackson]

I only see 1 carrier with this route as of today in all of our decks.

Looking back through the past month or so of traffic, I can't find any
attempts to this prefix.. A quick google of it seems to show a lot of
scams calling from this prefix anyway.


On Tue, Aug 4, 2015 at 11:33 AM, Ryan Delgrosso  wrote:
> All,
> We have seen a Caribbean NPANXX (1-268-762) advertised to us from a US tier
> 1 vendor. It has drawn a large amount of fraudulent traffic.
>
> We first saw this prefix pop up in this vendors rate decks in April. Going
> back to the start of the year I cannot find it in any revision of the LERG
> though, and no other vendor I have offers routes/pricing to this prefix.
>
> Does anybody know whats going on here?
>
> Shouldn't any zone 1 prefix exist in the LERG months prior to going live, or
> at the very least within some reasonable time after showing up for live
> traffic?
>
> Does this smell like highjacking to anyone else?
>
> All our vendor will tell is they are getting the route from another T1
> vendor, but in my 20+ connected peers I cannot find another occurrence.
>
>
> Any help or guidance is much appreciated. Feel free to reply on or off list.
>
> -Ryan
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Grandstream ATAs for Faxing

[Tim Jackson]

Sadly people still need outbound fax.. Just wait until you have that
user with an ATA and a fax machine faxing their fax->email service 40+
times a day to get documents via email..

--
Tim

On Tue, Sep 9, 2014 at 8:33 AM, Victor Chukalovskiy
 wrote:
> An alternate route is to put you fax DIDs on a centralized fax-2-email
> platform. Thereby avoiding any ATA-related hassles.
>
> If done properly, will give you very satisfactory fax success rates
>
>
> On 14-09-09 10:39 AM, Jamey wrote:
>>
>> Hello,
>> We having been utilizing Grandstream ATAs (HT70X and GXW400X) as analog
>> hand offs with our Hosted Services built on the Broadworks platform and
>> Sansay's SBC.  We've had regular trouble when using them with fax and credit
>> card machines.  We support t38 but have often gone to g711 pass-through.
>> Echo cancellation is disabled. We've tested them with the various jitter
>> buffer lengths, Rx/Tx setting adjustments and various impedance values.  The
>> results seem very inconsistent.  This is site to site as well as
>> inconsistent results at the same site.  The faxing/credit card transmissions
>> will work for a period of time and then begin failing without any changes.
>>
>> We are a CLEC who control the QoS from device out to the PSTN. We've found
>> that replacing the ATA with a Adtran TA90X usually corrects the issues but
>> this is not a cost effective solution.
>>
>> Anyone have similar experiences with Grandstream ATAs?  Anyone have
>> reliable VoIP faxing with their ATAs? If anyone has been successful
>> integrating the Grandstreams, I would be interested in knowing what config
>> changes you've made from their default.  Which models you've used with which
>> firmware?
>>
>> Anyone have other ATA's that seem to work well for faxing and credit card
>> machines?  We'd like to keep our offering to as few manufacturers as
>> possible that can offer 2, 4, 8+ FXS ports.
>>
>> Thanks for any and all recommendations.
>>
>> Jamey
>> Socket Telecom
>> ___
>> VoiceOps mailing list
>> VoiceOps@voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
>
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Grandstream ATAs for Faxing

[Tim Jackson]

We've had "OK" success with Cisco SPA112 ATAs.. I only say OK because
there are a ton of caveats to it.. Any re-invite towards the ATA
results in a momentary audio pause (just silence in the RTP, no RTP
loss, awesome).. Provisioning? Need a signed cert from Cisco to
support HTTPs.. LLDP-MED support seems to still be broken even in the
latest releases..

Other than the annoyances there, they're actually not too bad. Good
success with T.38 (but we generally just use 711u), and no real issues
with credit card machines, etc..

--
Tim

On Tue, Sep 9, 2014 at 7:39 AM, Jamey  wrote:
> Hello,
> We having been utilizing Grandstream ATAs (HT70X and GXW400X) as analog hand
> offs with our Hosted Services built on the Broadworks platform and Sansay's
> SBC.  We've had regular trouble when using them with fax and credit card
> machines.  We support t38 but have often gone to g711 pass-through.  Echo
> cancellation is disabled.  We've tested them with the various jitter buffer
> lengths, Rx/Tx setting adjustments and various impedance values.  The
> results seem very inconsistent.  This is site to site as well as
> inconsistent results at the same site.  The faxing/credit card transmissions
> will work for a period of time and then begin failing without any changes.
>
> We are a CLEC who control the QoS from device out to the PSTN.  We've found
> that replacing the ATA with a Adtran TA90X usually corrects the issues but
> this is not a cost effective solution.
>
> Anyone have similar experiences with Grandstream ATAs?  Anyone have reliable
> VoIP faxing with their ATAs? If anyone has been successful integrating the
> Grandstreams, I would be interested in knowing what config changes you've
> made from their default.  Which models you've used with which firmware?
>
> Anyone have other ATA's that seem to work well for faxing and credit card
> machines?  We'd like to keep our offering to as few manufacturers as
> possible that can offer 2, 4, 8+ FXS ports.
>
> Thanks for any and all recommendations.
>
> Jamey
> Socket Telecom
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Hackers Crash Clay Co. Phones ...

[Tim Jackson]

I think Ryan's point here is getting data on in-progress calls into it
instead of completed calls..

AFAIK CPM basically watches the real time call logs from the CFS, and only
knows about calls once they complete.
On Aug 18, 2014 6:04 PM, "Simon Dredge"  wrote:

> Heya, Ryan - It's SAS-like - But proactive analysis rather than reactive
> analytics. It'll trigger immediately (in real-time) on an anomaly,
> informing the operator that action is required so they can take necessary
> action.
>
> Cheers,
>
>
> Simon.
>
> -Original Message-
> From: Ryan Delgrosso [mailto:ryandelgro...@gmail.com]
> Sent: Monday, August 18, 2014 4:32 PM
> To: Simon Dredge
> Cc: voiceops@voiceops.org
> Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones ...
>
> Simon,
> I think the gotcha with CPM in this scenario is its a great tool for
> determining "this has happened" but not so great for building a mitigation
> solution.
>
> Is CPM driven off of CDR's or off of the SAS datastream or some other
> source?
>
> If its CDR driven you will be blind to this problem because you wont be
> measuring calls that are rejected due to lack of capacity(no cdr cut).
> If its driven off of SAS data you will get the missed/incomplete call
> stats but at the cost of speed (multiple orders of magnitude more data than
> CDR's)
>
> It would be interesting to hear if this perhaps uses a different
> datasource. Perhaps there is a facility in perimeta that informs this
> better than CFS data sources.
>
> -Ryan
>
> On 8/18/2014 3:36 PM, Simon Dredge wrote:
> > I know many meta-users like the new-ish call pattern monitor. It uses
> weighted profiling benchmarking algos similar to NBAD:
> >
> > http://www.metaswitch.com/sites/default/files/Metaswitch-Call-Pattern-
> > Monitor.pdf
> >
> > Cheers,
> >
> >
> > Simon.
> >
> >
> > -Original Message-
> > From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of
> > Ryan Delgrosso
> > Sent: Monday, August 18, 2014 1:53 PM
> > To: ECG - Mark Lindsey
> > Cc: voiceops@voiceops.org
> > Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones ...
> >
> > I dunno that's a slippery slope. Im not a proponent of putting
> management of your network services into someone elses hands, especially
> things like this where the service provider should have visibility into
> what they are or are not admitting.
> >
> > Agreed on your synopsis of call admission control, the border should be
> able to make these decisions rapidly, freeing up softswitch resources to
> actually serve customers.
> >
> > This sounds like good territory for an acme SPL plugin, possibly in
> > conjunction with this enum extension
> > http://tools.ietf.org/html/draft-kaplan-enum-source-uri-00
> unfortunately i dont see a clear path for this in the TDM world but my
> exposure there is limited. It would seem like a good solution might be
> using ENUM (with source URI) to build statistics centrally based on
> calling/called numbers and then forcing the ENUM response once thresholds
> are hit to illicit an appropriate decline message for flagged invites with
> a retry-after interval allowing you to effectively throttle specific call
> scenarios assuming your origination carriers will behave correctly.
> >
> > 2 of the examples we discussed previously were:
> >
> > 1: Social media death star. Justin biebers (or anyone else with millions
> of rabid followers) twitter account  (53.7M followers) gets hacked and
> attacker tweets "Call this number for free tickets" or similar.
> >
> > 2: T-DOS using stolen sip accounts effectively turning other service
> providers into a death star. More damage per source number (higher CPS than
> social media per attacker but less distributed source). This one seems much
> easier to create given the ease with which stolen sip accounts can be
> acquired, and harder to mitigate if the stolen accounts support callerID
> spoofing.
> >
> > Both of these situations are exacerbated by LCR resellers creating at
> times 10-20 invites from 1 due to route advancing when the destination is
> truly congested, which gets worse when the LCR resellers in turn have
> resellers in route etc etc.
> >
> > Of course any solution needs to have provisions for conveying congestion
> control to the originating network so they stop route advancing.
> >
> >
> > I think this has commercial viability for access providers protecting
> > their customers business interests and for implementers designing
> > solutions but perhaps not so much in a carrier to carrier capacity
> > (beyond appropriate support of signaling congestion control).
> >
> >
> > On 8/18/2014 12:48 PM, Mark R Lindsey wrote:
> >> Ryan, does it seem as though TDoS will be most effectively addressed by
> the origination companies?  i.e., the guys with the TDM trunks to the local
> tandems, such as incumbents, Verizon, Level(3).
> >>
> >> It seems to me that some use of statistics could probably make
> reasonable guesses about whether a given PSTN origination call is like

Re: [VoiceOps] Polycom Voice Quality Monitoring (VQ Mon) with Hosted Solutions

[Tim Jackson]

Meta wraps it all up into their troubleshooting platform, SAS, and makes
this data available. There are also some other lacking (IMHO) ways you can
poll VQM data from the CFS by "network" or network node which could be
helpful if your subscribers are pretty static.

There's supposed to have a lot of improvements coming out from them soon,
but the raw data is there and you could do some interesting things with it
in near real time today..

My thoughts are currently to do real time VQM stats monitoring into
ElasticSearch or possibly Graphite/Carbon or another TSDB for better
visibility, but having the data is really the key here.

One source for all VQM data is very <3..
On Aug 11, 2014 5:25 PM, "Colton Conor"  wrote:

> So how does this compare to the solutions Edgewater networks or Adtran's
> Voice Quality Monitoring? We are thinking about using lower cost Mikrotik
> or Ubiquiti networks routers, but they lack the Voice Quality Monitoring
> features Adtran and Edgewater provide. If the Polycom phone with VQ Mon and
> the hosted Softswitch could provide this information I think it would be
> helpful.
>
>
> On Mon, Aug 11, 2014 at 7:11 PM, Tim Jackson 
> wrote:
>
>> Metaswitch will collect this and wrap it up into the VQM stats it
>> calculates for each call (including the local DSP stats if one is
>> involved on the MG for TDM -> IP or IP -> IP)..
>>
>> I'm pretty sure their SBC can provide some information from this in
>> CDRs as well..
>>
>> On Mon, Aug 11, 2014 at 4:59 PM, Colton Conor 
>> wrote:
>> > Recently we have been using Polycom phones, and paid the additional $2
>> for
>> > the VQ Mon license.VQmon is an embedded agent that supports the RTCP XR
>> > (RFC3611) and SIP Voice Quality Reporting (RFC6035) protocols, and is
>> able
>> > to report the impact of transient IP problems on user perceived quality.
>> >
>> > Does Broadsoft and/or Acme Packet SBCs collect this information, and
>> report
>> > on it? Today we are using MOS scores from the routers (Adtran and
>> > Edgewater), but the per phone monitoring sounds like a better solution
>> as it
>> > is at the users hearing level.
>> >
>> > Are any hosted platforms using this information for anything useful? Or
>> the
>> > VQMon a bad or not widely implemented solution?
>> >
>> > ___
>> > VoiceOps mailing list
>> > VoiceOps@voiceops.org
>> > https://puck.nether.net/mailman/listinfo/voiceops
>> >
>>
>
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Polycom Voice Quality Monitoring (VQ Mon) with Hosted Solutions

[Tim Jackson]

Metaswitch will collect this and wrap it up into the VQM stats it
calculates for each call (including the local DSP stats if one is
involved on the MG for TDM -> IP or IP -> IP)..

I'm pretty sure their SBC can provide some information from this in
CDRs as well..

On Mon, Aug 11, 2014 at 4:59 PM, Colton Conor  wrote:
> Recently we have been using Polycom phones, and paid the additional $2 for
> the VQ Mon license.VQmon is an embedded agent that supports the RTCP XR
> (RFC3611) and SIP Voice Quality Reporting (RFC6035) protocols, and is able
> to report the impact of transient IP problems on user perceived quality.
>
> Does Broadsoft and/or Acme Packet SBCs collect this information, and report
> on it? Today we are using MOS scores from the routers (Adtran and
> Edgewater), but the per phone monitoring sounds like a better solution as it
> is at the users hearing level.
>
> Are any hosted platforms using this information for anything useful? Or the
> VQMon a bad or not widely implemented solution?
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Multi Tenant Commercial Softswitch Besides Broadsoft

[Tim Jackson]

As far as tricks with a cell client, Accession from Metaswitch is
pretty slick there..

No real SMS integration yet (but you can easily add this since
Accession supports XMPP)..



On Tue, Jul 29, 2014 at 9:12 AM, Colton Conor  wrote:
> To be a little more specific, at minimum the platform should have the
> following:
> A device manager for phones for automated provisioning and firmware updates
> Integrated SMS Functionality
> Integrate Cell Phone functionality. I guess an app that allows use of your
> cell phone as an extension, and not just a soft client. Any platform can use
> Bria!
> All the standard features that Broadsoft at least provides.
> Advanced fraud detection!
>
>
>
> On Tue, Jul 29, 2014 at 9:41 AM, Colton Conor 
> wrote:
>>
>> What carrier and service provider multitenant softswitch and pbx systems
>> are on the market today besides Broadsoft? We use a Broadsoft solution
>> today. We like the redundancy that Broadsoft offers, and the fact that it
>> just works. However, they are starting to seriously lack features, and there
>> are too many Broadsoft competitors. We are finding that our Broadsoft
>> offering is no different than Comcast, Verizon, or other local providers
>> that offer Broadsoft services to.
>>
>> We are really looking for something that integrates well for the mobile
>> worker. The ability to use their cell phone with the service is key for us.
>> The day's of clients buying $300 Polycom IP phones are slowing down.
>> However, people understand the value and are willing to spend $600 on a
>> smartphone.
>>
>> What commercial solutions are there?
>
>
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Solving port blocking issue @ softphone

[Tim Jackson]

Ditto.. We use TCP/443 without any real issues..

On Thu, Jun 26, 2014 at 10:20 AM, Mark R Lindsey  wrote:
> Do you think "Seemingly random" is really important? I've had good luck with
> TCP/443 for SIP.
>
 m...@ecg.co +1-229-316-0013 http://ecg.co/lindsey
>
> On Jun 26, 2014, at 11:57 , Ryan Delgrosso  wrote:
>
> Add 2 or 3 more seemingly random ports for the SBC to listen on. Also add
> them in TCP.
>
> have the softphone use DNS naptr records to order UDP then TCP srv records,
> and in each SRV record offer the same proxy with different ports. This will
> cause the softphone to try multiple ports on UDP then multiple ports on TCP
> until it finds success.
>
> If the softphone doesn't support NAPTR, then you can use SRV only but you
> lose the ability to try different transports. If it doesnt support SRV
> records, find another softphone.
>
> -Ryan
>
>
> On 6/26/2014 7:34 AM, Feby Francis wrote:
>
> 
> Experts,
>
> I have a customer who travels a lot and uses our softphone offering, I need
> a solution to overcome the situations when the port 5060 is blocked.
>
> Is there any work around to solve the port blocking problems? We use
> standard 5060 on the SBC and my switch vendor is Broadsoft.
>
>
> Thanks for all the help and advices,
> Feby Francis
>
>
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops