Re: [VoiceOps] One Way Audio - Frontier Comm (Los Angeles area)

[Glen Gerhard via VoiceOps]

Hi Mike,

I think you said that any ICMP packets would be noticed, do you monitor 
the gateway connections as well?


I've seen some devices that send out relatively small TTL values and it 
can result in one way audio that is customer path specific. As mentioned 
before SIP/TLS is not a true VPN and the audio UDP will be hop counted 
across the Frontier network. They should send back an ICMP message when 
they droop the packet.


Just one more thing to check.  Good luck.

~Glen

On 3/10/2024 9:28, Mike Hammett via VoiceOps wrote:
I haven't been able to attribute it to malice or ignorance yet, just 
that it happens.




-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com



Midwest Internet Exchange
http://www.midwest-ix.com




*From: *"Alex Balashov via VoiceOps" 
*To: *"VoiceOps" 
*Sent: *Saturday, March 9, 2024 7:57:33 AM
*Subject: *Re: [VoiceOps] One Way Audio - Frontier Comm (Los Angeles area)

No, it's true, consider me appropriately humbled. I underappreciated 
the nuance of this issue. I thought we were talking about something 
closer to the physicality of networks, not packet 
inspection/filtering/etc.


-- Alex

> On 9 Mar 2024, at 08:11, James Cloos  wrote:
>
>> "AB" == Alex Balashov writes:
>
>>> I don't trust last mile networks to reliably deliver SIP calls. I 
usually end up putting them into VPNs, TLS, etc.

>
> AB> VPNs and TLS make last-mile networks more reliable? :-)
>
> on the vpn side, wireguard (which runs over udp) certainly does.
>
> I imagine ipsec sometimes can, too.  but wg is easier.
>
> -JimC
> --
> James Cloos 
>            OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc

--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800

___
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




OpenPGP_0x762F3FD00C668A3C.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] 3cx

[Glen Gerhard via VoiceOps]

Some info in this link:

https://arstechnica.com/information-technology/2023/03/massive-supply-chain-attack-with-ties-to-north-korea-hits-users-of-3cx-voice-app/

~Glen


On 3/30/2023 09:38, Carlos Alvarez via VoiceOps wrote:

Cortex XDR picked this up and blocked it, not sure about others.


On Mar 30, 2023 at 9:09:54 AM, Brian Turnbow via VoiceOps 
 wrote:

Hello everyone,
I know a lot of people use/sell 3cx, a lot of our customers do.. So 
am posting here to advise everyone


https://www.3cx.com/blog/news/desktopapp-security-alert/



___
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


--
Glen Gerhard
g...@cognexus.net
858.324.4536

Cognexus, LLC
P.O.Box 12083
San Diego, CA 92039



OpenPGP_0x762F3FD00C668A3C.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Passing the Voiceops torch

[Glen Gerhard via VoiceOps]

Thanks David. Your work helped all us in large and small ways.

~Glen

On 2/14/2023 17:45, jjones--- via VoiceOps wrote:

Thanks for your leadership David.

jj

Sent from my iPhone


On Feb 14, 2023, at 5:02 PM, Mike Johnston via VoiceOps  
wrote:

On January 2, 2023, David Hiers wrote:

Hi everyone,
Thank you all for your contributions to voiceops over the years, you quite 
literally make the voiceops distro what it is.
With the coming of 2023, it’s about time to pass the voiceops torch to the next 
generation.  If you’d like to pick up the domain name and such, please contact 
me off list.
Happy New Year to all,
David Hiers

The torch has been passed.  David has transferred the voiceops.org domain name 
over to me, and I am now hosting the DNS and landing page on $DAYJOB servers.  
The actual mailing list is still hosted at puck.nether.net.

And thank you, David, for your years of work to the voiceops list.  Much of 
what we do is so niche, it can be hard to find the resources we need anywhere 
else.  Just look at the DTMF thread from yesterday!

So let's all give a big thanks to David!


I'll leave you with a few quotes from way way back in the archives.


On July 30, 2009, David Hiers wrote:
"Mr. Watson -- come here -- I want to see you."
On August 5, 2009, Mark R Lindsey wrote:
At IPTComm a couple of years ago, Jonathan Rosenberg stood up and said  the big 
problem was the walled gardens that are telcos and ITSPs. We  carriers just 
aren't passing traffic via VoIP. Even Cisco customers  aren't passing traffic 
within their own company; you'd have a BTS over  here and a BTS over there, 
owned by the same Cable MSO, passing  traffic via ISUP.

That was back in 2009.  That is, sadly, still the case for many telcos, both 
large and small.

And here are some excellent words from anorexicpoodle, written on October 21, 
2009:

Since we, collectively, are steering one of the industries driving up
individual utilization of the IPV4 address space as well as being one of
the most sensitive to NAT which is the only way through which IPV4 has
been sustained as long as it has; it seems like a worthy exercise to
discuss our own, and the industries preparedness to adopt IPV6. Has anyone out 
there had any experience using any of the open source
platforms (OpenSIPS, Asterisk, SIPPY etc) with native IPV6? It seems
like these projects are the best equipped right now to handle this move
since they rely heavily on the network stack of the underlying OS. Are there 
any endpoints or other CPE that anybody has had luck getting
to work over native IPV6?
So far I am unaware of any carrier grade (meaning it costs a lot of
money) softswtch platforms that are ready for this, or seem like they
would be without a multi-year effort. Anybody out there that can
enlighten us on this one?


Sincerely,
Mike Johnston
___
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


--
Glen Gerhard
g...@cognexus.net
858.324.4536

Cognexus, LLC
P.O.Box 12083
San Diego, CA 92039



OpenPGP_0x762F3FD00C668A3C.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] STIR for intra-net calls

[Glen Gerhard]

Yes, you also need the ID headers in order to pass RCD. Most customers will 
(hopefully) be expecting to see this on calls someday.  

~Glen


> On Jun 27, 2022, at 15:01, Nathan Anderson  wrote:
> 
> Alex Balashov wrote:
> 
>> Or are we talking about customers who do get the full attestation headers 
>> and interrogate them?
> 
> Precisely this.  If we ever get such a customer, and if at that time we've 
> finally arrived at a world where it's expected that 100% of inbound calls [at 
> least at provider's edge] are attested, and thus this customer's expectations 
> have been calibrated to expect the same of calls that they receive via us 
> (and they're planning on dropping any inbound calls without a valid PASSporT) 
> even though they are paying us for SIP trunking and aren't a "peer" of ours, 
> if a different customer of ours calls them, are we supposed to generate & 
> transmit an Identity header for that INVITE?  It seems weird to do so, but I 
> could potentially see such a scenario playing out, eventually.
> 
> -- Nathan
> ___
> 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] STIR/SHAKEN concerns

[Glen Gerhard]

2. If your network is partially TDM and partially VOIP, have you 
experienced any issues with either of them? What are your future 
concerns since STIR/SHAKEN does not work with TDM?
This will certainly weaken the benefits of S/S since the ID Header will 
be stripped off along many paths. Out Of Band S/S is slow moving but may 
help in the long run. In the mean time it's no worse than before S/S of 
course




3. My biggest complaint as a residential consumer is that caller ID no 
longer shows up like it did. Unless I have the number in my phone, I 
only see something along the lines of Scam Likely or a phone number 
with no caller ID. I find this quite irritating since it prevents me 
from determining if its a friend whose carrier hasn't implemented it 
yet or an actual scammer. Anyone else have complaints about what 
information is being passed?
As Paul said this is a function of the CVT and your carrier. RCD might 
help a little although the CVT will still control the CNAM delivery display.




7. One of my greatest concerns I have about the September 
implementation is that carriers will get no warning if/when they are 
going to be blocked. I haven't seen anything that states a terminating 
carrier or intermediate carrier has to give a warning muchless 
disclose that they will start blocking another carrier's traffic. 
Maybe there is a hotline to call if your traffic is being blocked 
unjustly, but I haven't heard of any. Have you? Normal routing issues 
are already a nightmare to deal with. Hopefully this will not make it 
worse or just another method for anti-competitive carriers to take out 
their competition!
You need to monitor you calls for Cause Code 608s. Although it's not 
always passed end-end the tracking is helpful and you won't know until 
the calls are being rejected.




8. The last question leads me to the next one. I know there are some 
carriers using their underlying carrier's certificate so they didn't 
register for the Robocall Mitigation Database. I didn't recommend 
this, but I heard through the grapevine some consultants / underlying 
carriers did. If those who didn't sign up for the Robocall Mitigation 
Database have legitimate traffic shut down, what will happen to all 
their legitimate customers? Will they be out of service until the ITG 
gets around to figuring it out? Has anyone heard of a plan to address 
the impact on consumers displaced by this?
It sounds a bit like Delegated Certs before they're adopted. I wouldn't 
want to bet my business that those calls will go through for long.




Good luck,

~Glen

Cognexus, LLC
7891 Avenida Kirjah
San Diego, CA 92037

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Fake Voicemail Anti-Robocall Tactics

[Glen Gerhard]

  
  
Hopefully Stir/Shaken will make this a moot point.
  Calvin, are you saying that a 608 is the recommended response for
  a call that is being rejected due to S/S attestation or CVT
  reasons?
  
  ~Glen

On 2/16/2021 8:19 AM, Calvin Ellison
  wrote:


  
  Today we received a notice from one of our
underlying carriers that included the following statement:



  
* If a
customer spoofs an ANI that they do not own, the clec's
can forward to call to a voiceless Voicemail which appears to be
FAS.
  
  
  
  Is there any legal device that actually supports this
practice? I'm looking for a specific statute, FCC rule,
precedent in a judicial ruling, or the like.
  
  
  The FCC has ruled that the SIP 608 response code is to be
used for signaling when a call is rejected. I doubt the FCC
or FTC has ruled that terminating carriers are permitted to
cause loss of trust and revenue between upstream
intermediate and originating carriers.
  

  

  

  

  

  
  
  
  
  Regards,



  Calvin
  Ellison
Systems Architect
calvin.elli...@voxox.com
+1 (213) 285-0555

---
voxox.com 
5825 Oberlin Drive, Suite 5
San Diego, CA 92121
  
  

  

  

  

  

  

  

  
  
  
  ___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops


    
    -- 
Glen Gerhard
g...@cognexus.net
858.324.4536

Cognexus, LLC
7891 Avenida Kirjah
San Diego, CA 92037
  

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Voice peering

[Glen Gerhard]

  
  
I concur on the ENUM solution being obsolete. Sure
  it was better than TCAP, but not as flexible as a 302. Its appeal
  originally was a centralized phone number ownership lookup but it
  was never deployed that way; DNS is too slow at updating
  information and too open to DDOS attacks.
  
  So without centralized and up to date information no one cares how
  you route anymore. You're expected to do it yourself and they
  don't (shouldn't) trust anything you pass them. A SIP trunk is all
  you need and all of them are treated pretty much the
  same(untrusted, measured, usage based on performance and cost).
  
  But if you want accurate billing/routing you need to check the LNP
  yourself either via a nightly download from NPAC or as a SIP based
  service from Neustar or others. The costs are not much for either
  depending on your traffic volume and type.
  
  ~Glen

On 1/5/2021 9:17 AM, Alex Balashov
  wrote:

From
  my perspective as an implementor down in the weeds, ENUM is just a
  failure-prone moving part and a source of unnecessary complexity
  at this point. DNS is not a particularly good transport vehicle
  for data queries. As far as I can tell, the industry went in that
  direction at the time it did because it was the more performant
  option at the time, which is a commentary on the sad state of SIP
  stacks early on.
  
  
  Most folks realised a long time ago that SIP redirects are a lot
  more flexible for data queries, and doesn't require a parallel
  infrastructure of unrelated DNS componentry whose operational
  support demands nonoverlapping technical competencies. ENUM as a
  routing query mechanism has fallen into considerable neglect in
  some of the major softswitch & SBC platforms, as far as I can
  tell. I distinctly remember severe performance issues with ENUM a
  few years ago on one of the most well-known SBC platforms (ahem);
  when the vendor was contacted about it, the response was kind of,
  "Why would someone still use that?"
  
  
  But, of course, that doesn't mean the peering provider landscape
  has caught up.
  
  
  -- Alex
  
  
  On 1/5/21 8:57 AM, Ross Tajvar wrote:
  
  
  Based on this presentation [0] from
Comcast, they are interconnecting with their biggest voice peers
via SIP rather than SS7. They appear to use ENUM for route
selection. I'm sure others are doing this too, though I can't
find anything public.


I'm interested if anyone has more info on how this works. I'm
guessing participants maintain their own private ENUM servers
and just trust each other? As far as I know the only way to
validate number ownership is via an LNP dip, which would be
expensive to do for every call.


I would like to be able to consume a service like that, at least
in an outbound direction; as a small operator, I'm sure
convincing large carriers to trust my ENUM server would be very
difficult. But having a greater degree of interconnectedness
(and mostly importantly avoiding TDM) seems like a good thing.


Does anyone have experience with this sort of thing?


Thanks,

Ross


[0]
https://silo.tips/download/voice-peering-interworking-sip-and-bgp



___

VoiceOps mailing list

VoiceOps@voiceops.org

https://puck.nether.net/mailman/listinfo/voiceops
    

  
  
  


-- 
Glen Gerhard
g...@cognexus.net
858.324.4536

Cognexus, LLC
7891 Avenida Kirjah
San Diego, CA 92037
  

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

[VoiceOps] Information required for a Traceback investigation

[Glen Gerhard]

  
  
Regarding the Stir/Shaken enforcement but I'm
  wondering what information I need to store in case of a Traceback
  request?
  
  On the OSP I presume just the normal CDR information is enough
  (along with the offline vetting info). But for the TSP is there
  value in keeping the Passport information to indicate the inbound
  attestation and response from the CA?
  
  I'm wondering if I'll ever need to justify the attestation level I
  present on a call, or for blocking it?
  
  Thanks,
  
  ~Glen
    
-- 
Glen Gerhard
g...@cognexus.net

  

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] STIR/SHAKEN for call centers

[Glen Gerhard]

  
  
Sounds like a good plan to me. It might help to
  figure out a few test call paths to verify the verstats directly.
  
  IMHO much of the S/S technology will be overshadowed by the
  analytics providers in terms of call presentation/blocking. 
  
  That said, S/S will be helpful to law agencies in tracking
  malicious intent groups. This alone makes it worth the effort. A
  lot of the work /benefit takes place at the vetting of corporate
  ownership. S/S also provides Rich Call Data which replaces the
  pathetic CNAM.
  
  The Delegated Certs extension will help with the call center
  attestations but is still a ways off. Then you need your SBCs and
  PBXs to support it.
  
  SIPNOC is next week and it's usually helpful.
  https://www.sipforum.org/news-events/sipnoc-2020-overview/#topics
  
  
  ~Glen

On 12/2/2020 1:49 PM, Patrick Labbett
  wrote:


  
  
Hello, I'm
  looking for guidance/feedback on the impact of STIR/SHAKEN on
  the call center and answering service industries. Very few are
  interconnected VoIP service providers themselves. 


Specifically,
  customers of these industries often desire the call center
  utilize their company phone number when contacting their
  employees or customers for an improved end-user experience. 


The worry is
  that STIR/SHAKEN will be implemented in a way that causes
  these "spoofed" calls (that have legitimate
  business relationships in place) to be marked as such or
  eventually blocked as STIR/SHAKEN tightens it's grip on
  malicious intent. 


Here is my
  understanding of the situation: As a customer of an
  Originating carrier, the Call Center's outbound calls will be
  signed by their Originating carrier's STIR/SHAKEN certificate
  - so as long as the SIP Identity header isn't modified in
  transit and the certificate is validated on the Terminating
  side, everything should continue to work normally for us as
  end users. So this is largely the carrier's problem, and not
  the call centers.


However, it's
  not clear (to me) how the Attestation aspect of things will
  work (and if it even effects the typical customer): 

  
Does just
  being a customer of the Originating Carrier give the Call
  Center's calls Full Attestation?
As a call
  center, if spoofing a number not owned/in inventory, would
  that be Partial Attestation?
Does the
  owner/location of the spoofed number matter, i.e. :

  Partial Attestation: Number owned by Originating
carrier, but not by customer making call
  Gateway Attestation: Number not owned by Originating
carrier (and by extension not owned by customer making
the call)

Will
different Terminating carriers treat Attestation
designations differently?
Is this largely a framework that carriers will
  implement some day in the future?
  
  Am I way
overthinking this? (Yes.) 
  
  
  Thank you
in advance for any perspective you can offer, or resources
you can direct me to. 
  
  
  My
personal plan of attack for call centers:
  

  Document permission and business use case for numbers
spoofed on behalf of customers
  That's it - that's the whole plan. 
  

Aside from making sure my carriers know I exist and
  that I have permission to use those numbers, what else is
  there?


  
  -Patrick
Labbett

  
  
  
  ___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops



-- 
Glen Gerhard
g...@cognexus.net
858.324.4536

Cognexus, LLC
7891 Avenida Kirjah
San Diego, CA 92037
  

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Question about SS7 routing

[Glen Gerhard]

he same way.by dedicated trunk
  group / tandem area.
  
  
  
  
  MARY LOU CAREY
  
  BackUP Telecom Consulting
  
  Office: 615-791-9969
  
  Cell: 615-796-
  
  
  On 2020-09-02 04:46 PM, Ross Tajvar wrote:
  
  Hi all,


I'm trying to understand how routing works in SS7-land. I am
familiar

with portability, and I know (at least in the US) the first step
in

routing a call is doing an LNP dip to get the LRN.


However, it looks like addresses in MTP3 are "point codes" (PCs)
which

are assigned to switches. Calls are set up with ISDN-UP, which
is

transported via MTP3. So in order for a call to be set up, the

destination switch's PC must be known. How is the destination PC

determined from the destination LRN?


Thanks,

Ross

___

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
  


-- 
Glen Gerhard
g...@cognexus.net
858.324.4536

Cognexus, LLC
7891 Avenida Kirjah
San Diego, CA 92037
  

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Toll Free Caller ID

[Glen Gerhard]

  
  
That's probably up to the ULC contract but my
  expectation would be Indeterminate Jurisdiction.
  
  ~Glen

On 5/14/2020 10:33, Calvin Ellison
  wrote:


  
  
On Thu, May 14, 2020 at 10:02 AM Glen Gerhard
  <g...@cognexus.net>
  wrote:


  
 I agree with Paul. From what I know
the 8YY ANIs are handled like any other ANI.
  
  
  
  
  Are underlying carriers treating these as indeterminate, or
  given their own jurisdiction and rates? 
  
  
  
  ___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops


    
    -- 
Glen Gerhard
g...@cognexus.net
858.324.4536

Cognexus, LLC
7891 Avenida Kirjah
San Diego, CA 92037

  

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Toll Free Caller ID

[Glen Gerhard]

  
  
I agree with Paul. From what I know the 8YY ANIs are
  handled like any other ANI.
  
  ~Glen

On 5/14/2020 9:08, Paul Timmins wrote:


  
  

  What's the news on using TFN as a caller ID?
  
People have been doing it for years

  
  Does this require a local charge number in P-Charge-Info
or P_Asserted_Identity or elsewhere?
  
It does if you want calling other toll-free numbers or
  911 to work, otherwise it doesn't really matter.

  
  Has the FCC or anyone else approved TFN as ANI?
  
Does anyone need to?

  
  Is TF ANI supported for STIR/SHAKEN?
  
If you have the certs, you can attest to whatever you
  want. It's designed to create accountability for
  originating carriers, not police numbering formats.

  

  
  
  
  On 5/14/20 11:56 AM, Oren Yehezkely
wrote:
  
  

Calvin,
  
  
  I wonder if you got any insight to this question?
  
  
  Regards,
  Oren
  



  On Tue, May 12, 2020 at 5:01
PM Calvin Ellison <calvin.elli...@voxox.com>
wrote:
  
  

  It looks like Somos is pushing TFN CNAM, press
release below from Mar 30, 2020. I've always
understood TF ANI to be invalid. 
  
  
  
  What's the news on using TFN as a caller ID?
  Does this require a local charge number in
P-Charge-Info or P_Asserted_Identity or elsewhere?
  Has the FCC or anyone else approved TFN as ANI?
  Is TF ANI supported for STIR/SHAKEN?


https://www.prnewswire.com/news-releases/toll-free-caller-id-information-helps-hhs-get-critical-phone-calls-answered-301031714.html  
  

  

  

  

  

  
  
  
  
  Regards,



  Calvin
  Ellison
Senior Voice Operations
Engineer
calvin.elli...@voxox.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

  
  
  
  
  
  ___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops



-- 
Glen Gerhard
g...@cognexus.net
858.324.4536

Cognexus, LLC
7891 Avenida Kirjah
San Diego, CA 92037

  

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Post-Port Activation Delay

[Glen Gerhard]

  
  
I would expect that mobile providers would have up
  to date porting information, regardless of how you initiate the
  port.
  
  Apparently the some of the ones you tested on use a nightly
  update, so as Matt said, you will just have to wait.
  
  ~Glen

On 1/23/2020 8:55, Matthew Yaklin
  wrote:


  
  
  
Isn't this a case of the "sloppy" providers using a LNP cache
system on their switch and you simply have to wait for it to
expire out for each number? Once it expires they will redip for
the proper LRN and calls flow normally...
  

  
  
I guess it happens to me but I simply ignore it.. it will fix
itself. I normally do ports in the evening and that way we have
a solid 12 plus hours before they open the next morning.
  

  
  
Or did I misread the question and gave a terrible answer?
  

  
  
Matt
  

  
  

  
Matthew Yaklin
  
Network Engineer
  
FirstLight
  
359
  Corporate Drive │ Portsmouth, NH 03801
  
Mobile 603-845-5031
  
myak...@firstlight.net |
www.firstlight.net
  
This email may contain
  FirstLight confidential and/or privileged
  information. If you are not the intended
  recipient, you are directed
  
not to read, disclose or
  otherwise use this transmission and to immediately
  delete same. Delivery of this message is not
  intended
  
to waive any applicable
  privileges.
  

  
  
  From:
  VoiceOps  on behalf of
  Mike Hammett 
  Sent: Thursday, January 23, 2020 11:42 AM
  To: voiceops 
  Subject: [VoiceOps] Post-Port Activation Delay
 
  
  
I would like to preface this email by
  saying that I know that iconnectiv is managing ports now,
  but we just have the old Neustar portal working as the
  front end because I haven't had time to learn how all this
  stuff works so that I can properly train our employees on
  how to use the new portal.
  
  
  Undo business. Our people that manage the porting
  currently go into the neustar portal and activate a port.
  At that time, some carriers immediately start using bus.
  However, some carriers will still send traffic to the
  losing provider for some amount of time after that.
  Sometimes that is okay, sometimes it is not. I assume that
  there is not a darn thing that I can do about how quickly
  someone else decides to look up the number to see that it
  has been ported.
  
  However, can someone explain to me how common this is and
  what providers arnone for being sloppy? For example, last
  night we did a port at 9 pm. A test call that we did to a
  forwarding number that would have bounced through AT&T
  ILEC went through fine every time. Calls that would have
  gone through a variety of cell providers was extremely Hit
  or Miss, Even from the same operator.
  
  
  I apologize for any misused words. I was using voice to
  text and editing that on my phone can be difficult.
  
  
  
  -
  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

  
  
  
  ___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops


    
-- 
Glen Gerhard
g...@cognexus.net
858.324.4536

Cognexus, LLC
7891 Avenida Kirjah
San Diego, CA 92037

  

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] STIR/SHAKEN Discussion: Will it help?

[Glen Gerhard]

  
  
I certainly hope that unlike CALEA all the work is
  used for some decent benefit. People misrepresenting ANIs should
  be able to blocked which is a major problem today.
  
  As noted the delegated certs will let a company send the call out
  to any carrier they choose, not just the one supplying the ANI. In
  the meantime though it certainly helps the major carriers.
  
  At least it is an opportunity to also promote eCNAM which IMHO is
  an overdue feature.
  
  ~Glen

On 12/19/2019 12:32, Alex Balashov
  wrote:


  I do not think the fact that S/S poses the problem you raise is an accident. Nor do I think that the lopsided consequences of most other solutions enthusiastically supported by incumbents and large industry actors are an accident. Think CALEA. 

—
Sent from mobile, with due apologies for brevity and errors.


  
On Dec 19, 2019, at 2:13 PM, Peter Beckman  wrote:

AT&T is now using STIR/SHAKEN (incorrectly James Bonded as SHAKEN/STIR in
the article) to identify calls with Full Attestation as "Verified" on
select Android phones.

https://www.engadget.com/2019/12/18/att-call-validation-displays/

Thankfully they note, as this discussion was intended to highlight, "This
doesn't guaranteed that someone calling from a real number is above-board,
either. It could still be a robocaller, a scammer or a telemarketer."

I'm concerned that smaller carriers are going to be hurt by STIR/SHAKEN
being implemented by large carriers who own both their numbers and the end
users, whereas smaller carriers need to get numbers and termination from
different carriers to achieve competitive rates.

Beckman



  On Thu, 19 Dec 2019, mgraves mstvp.com wrote:

My impression is that it will eventually allow for very efficient traceback, since the info will be carried in the call. It will effectively have a complete trace embedded.

What happens with that info is another matter entirely. We can presume that it will be used to good effect, but that may be optimistic. Traceback info is being generated now. Rarely does it result in anything tangible.

Michael Graves
mgra...@mstvp.com
o: (713) 861-4005
c: (713) 201-1262
sip:mgra...@mjg.onsip.com


From: VoiceOps  On Behalf Of Glen Gerhard
Sent: Thursday, December 19, 2019 11:59 AM
To: voiceops@voiceops.org
Subject: Re: [VoiceOps] STIR/SHAKEN Discussion: Will it help?

Peter,

the initial rollout of S/S does not include delegated certificates. It's being rushed so at least basic call blocking/tracing can be done by tier one carriers. It is usable in the limited design but doesn't cover all use cases. Using the public CA is still the work in progress from my understanding.

Delegated certs is a much more complex call flow and has potential holes in the vetting process of the call flow chain. It has to allow for a customer to pass the call through several App/CPAAS providers before hitting the telco operators so the number of companies that need to be properly vetted for ownership and right to use information is MUCH larger.

I think eventually it will be effective in cutting down the number of rogue callers and catching the ones that are egregious offenders.

~Glen

On 12/18/2019 21:09, Peter Beckman wrote:
On Tue, 17 Dec 2019, Calvin Ellison wrote:


If you want to keep up to date on this, join the ATIS IP NNI and SIP Forum
mailing lists. You'll see frequent notifications as the policy and protocol
documents get updated.

On Tue, Dec 17, 2019 at 3:49 PM Peter Beckman  wrote:


In my case, we use different termination carriers than our origination
carriers in many situations. If we are authorized to use a DID for
CallerID, but it is not from the termination carrier, how does the
termination carrier know to set the attestation to full?

This one of the things being worked out. There are frameworks for
certificate delegation and TN authorization, but I can't speak to the
details.

Awesome to hear Calvin. I was under the impression that the STIR/SHAKEN
standard had been ratified by the participating carriers and they were
moving forward. I have not seen anything about cert delecation and TN
authorization in the technical specs.

Is STIR/SHAKEN not really completed and ready for deployment yet? The FCC
and larger carriers seem to be moving forward with test implementations
without of TN authorization and delegation.

Beckman
---
Peter Beckman  Internet Guy
beck...@angryox.com http://www.angryox.com/
---
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops



--

Glen Gerhard

g...@cognexus.net

858.324.4536



C

Re: [VoiceOps] STIR/SHAKEN Discussion: Will it help?

[Glen Gerhard]

  
  
Peter,
  
  the initial rollout of S/S does not include delegated
  certificates. It's being rushed so at least basic call
  blocking/tracing can be done by tier one carriers. It is usable in
  the limited design but doesn't cover all use cases. Using the
  public CA is still the work in progress from my understanding.
  
  Delegated certs is a much more complex call flow and has potential
  holes in the vetting process of the call flow chain. It has to
  allow for a customer to pass the call through several App/CPAAS
  providers before hitting the telco operators so the number of
  companies that need to be properly vetted for ownership and right
  to use information is MUCH larger.
  
  I think eventually it will be effective in cutting down the number
  of rogue callers and catching the ones that are egregious
  offenders.
  
  ~Glen
  

On 12/18/2019 21:09, Peter Beckman
  wrote:

On
  Tue, 17 Dec 2019, Calvin Ellison wrote:
  
  
  If you want to keep up to date on this,
join the ATIS IP NNI and SIP Forum

mailing lists. You'll see frequent notifications as the policy
and protocol

documents get updated.


On Tue, Dec 17, 2019 at 3:49 PM Peter Beckman
 wrote:


  In my case, we use different
  termination carriers than our origination
  
    carriers in many situations. If we are authorized to use a
  DID for
  
    CallerID, but it is not from the termination carrier, how
  does the
  
    termination carrier know to set the attestation to full?
  
  


This one of the things being worked out. There are frameworks
for

certificate delegation and TN authorization, but I can't speak
to the

details.

  
  
   Awesome to hear Calvin. I was under the impression that the
  STIR/SHAKEN
  
   standard had been ratified by the participating carriers and they
  were
  
   moving forward. I have not seen anything about cert delecation
  and TN
  
   authorization in the technical specs.
  
  
   Is STIR/SHAKEN not really completed and ready for deployment yet?
  The FCC
  
   and larger carriers seem to be moving forward with test
  implementations
  
   without of TN authorization and delegation.
  
  
  Beckman
  
---
  
  Peter Beckman 
  Internet Guy
  
  beck...@angryox.com
  http://www.angryox.com/
  
---
  
  ___
  
  VoiceOps mailing list
  
  VoiceOps@voiceops.org
  
  https://puck.nether.net/mailman/listinfo/voiceops
  
    

-- 
Glen Gerhard
g...@cognexus.net
858.324.4536

Cognexus, LLC
7891 Avenida Kirjah
San Diego, CA 92037

  

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] CLEC - STIR/SHAKEN

[Glen Gerhard]

  
  
Yes, I believe that is the case today. In the new
  "delegated certificate" model the VoIP provider (or CPaaS
  provider) will be provided a certificate from the OCN that is used
  for the ANI. This delegated certificate will give the downstream
  carriers A level Attestation for the calls regardless of where the
  outbound calls are originated.
  
  Ultimately it is the originating Enterprise that needs to be
  traceable from the terminating carrier. Once this relationship
  chain has been vetted the certificates can be delegated and used
  at call set up time. NetNumber has a service for brokering the
  Certificates but the spec is not fully adopted to my knowledge.
  
  Another proposal at ATIS is to have the sending CNAM (and expanded
  eCNAM) validated with a similar vetted relationship and
  certificate chain. Ultimately this may be more useful for both the
  Enterprise and the Callee than just the ANI.
  
  ~Glen
  

On 8/16/2019 11:40, Mary Lou Carey
  wrote:

So
  it sounds to me like you just have to be a certified carrier to
  get a STIR/SHAKEN certificate. That means either a CLEC, 
  Wireless, or Interconnected VOIP Carrier. The VOIP carriers that
  are not certified by the FCC as Interconnected VOIP carriers
  cannot be assigned an OCN.
  
  
  MARY LOU CAREY
  
  BackUP Telecom Consulting
  
  Office: 615-791-9969
  
  Cell: 615-796-
  
  
  On 2019-08-16 01:32 PM, Calvin Ellison wrote:
  
  As explained to me by TransNexus, the
Certificate Authorities will

most likely require an OCN. VoIP carriers with their own
numbering

resources already have their IPES category OCN. It's also
possible

they might only require a SPID.


Regards,


CALVIN ELLISON

Senior Voice Operations Engineer

calvin.elli...@voxox.com

+1 (213) 285-0555


---

VOXOX.COM [1]

5825 Oberlin Drive, Suite 5

San Diego, CA 92121


On Fri, Aug 16, 2019 at 8:02 AM Dovid Bender


wrote:


Alex,
  
  
  You would think so. From what I understand you will need to be
  a LEC
  
  to get a cert.
  
  
  On Fri, Aug 16, 2019 at 10:33 AM Alex Balashov
  
   wrote:
  
  
  If non-LEC VoIP providers can direct
own numbering resources now,

it follows that they should be able to partake of
STIR/SHAKEN.


—

Sent from mobile, with due apologies for brevity and errors.


On Aug 16, 2019, at 9:16 AM, Dovid
  Bender 
  

wrote:


  
  As I understand it if one wants to get a cert for STIR
  shaken
  

you need to become a CLEC. Anyone have a how to/contacts for

companies that make this effortless and easy?


  
  
  ___
  
  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
  



Links:

--

[1] http://www.voxox.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
  
    
    
-- 
Glen Gerhard
g...@cognexus.net
858.324.4536

Cognexus, LLC
7891 Avenida Kirjah
San 

Re: [VoiceOps] RTP Proxy TTL Behavior

[Glen Gerhard]

  
  
Hi Jeff,
  
  The B2BUA is a signaling function, not necessarily an IP layer
  function. Yes, some SBCs may give you the ability to modify the
  TTL but I'd look more at the Gateway/IP Phone configuration.
  
  What is the TTL being sent out by the end device? Some of those
  are defaulted to absurdly low TTL, I've seen as low as 16. In
  general that is where they configuration should be changed.
  
  ~Glen
  

On 2/11/2019 7:04, Jeff Anderson wrote:


  
  We are occasionally running into a situation where
our IP Header TTL expires in transit for RTP streams. It has
been our observation that our SBC B2BUA that anchors media is
not resetting the TTL on RTP packets but is on SIP packets.


Is there a standard expected behavior for how SBC B2BUA
  with media anchoring might handle RTP packets? I would have
  thought if it resets the SIP packet TTL it would also reset
  the RTP packet TTL.


Thoughts?
  
  
  
  ___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops


    
    -- 
Glen Gerhard
g...@cognexus.net
858.324.4536

Cognexus, LLC
7891 Avenida Kirjah
San Diego, CA 92037

  

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] ANIs flagged as telemarketer/spammer/scammer

[Glen Gerhard]

bly 2/3rds
  of unfamiliar numbers, including quite legitimate ones, show
  up as "Scam Likely" — I know that's come up on the list
  before. AT&T displays "Telemarketer"; do they do it that
  way too, or do they use a Google Android feature for that
  which they enable as part of their carrier defaults for
  carrier-issued phones? What about other carriers and Android?
  
  > 
  > As far as I know, Apple don't do anything like this. Do
  people with iPhones just not receive this "service"? How does
  that work?
  > 
  > Asking where the central, or the most influential
  authority lies and who provides it goes to the heart of the
  real question, which is: what can a legitimate business do if
  their number has been blacklisted this way? As I understand
  it, the maintainers of these lists, along with the criteria
  for getting on them, are elusive and inscrutable, and there's
  really no recourse and no appeals process. I furthermore
  understand that this has led to the widespread approach of
  rotating ANIs, but that's a losing battle; they get flagged
  too. I imagine it won't be long before the criteria for "Scam
  Likely" are just "number appears to call lots of numbers in
  this rate centre and otherwise hasn't been around very long".
  > 
  > But this is all just conjecture on my part; I really
  don't know much about how my carrier, anyone's carrier, or
  some BigCo that's behind my mobile OS decides that a call is a
  "telemarketer" or "scam" call. If anyone can shed some light
  on how this really works and what, if anything can be done
  about it, I would be most appreciative.
  > 
  > --
  > 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
  > 
  >
  --
  > This message and any attachments are intended only for
  the use of the addressee and may contain information that is
  privileged and confidential. If the reader of the message is
  not the intended recipient or an authorized representative of
  the intended recipient, you are hereby notified that any
  dissemination of this communication is strictly prohibited. If
  you have received this communication in error, notify the
  sender immediately by return email and delete the message and
  any attachments from your system.
  
  -- 
  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



-- 
Glen Gerhard
g...@cognexus.net
858.324.4536

Cognexus, LLC
7891 Avenida Kirjah
San Diego, CA 92037

  

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Wireless Carrier Lookups: CNAM DIPS

[Glen Gerhard]

  
  
SLIGHTLY OFF TOPIC:
  
  Lately I've been getting calls to my Tmobile cell phone with CNAMs
  such as Scam Likely and Nuisance Call.  Even without the CNAM I
  know they are call centers so don't pick up, but I'm wondering who
  assigns that CNAM?  I'd expect Tmobile to dip the CNAM but doubt
  the official database would flag the number this way. If it's
  coming from the call center app it's pretty funny. I don't know
  anywhere else along the call path it would be changed.
  
  ~Glen
  
  

On 3/26/2018 8:05 AM, Eric Wieling
  wrote:

I use
  data24-7.com
  
  
  Request:
  
  
https://api.data24-7.com/v/2.0?user=&pass=&out=json&api=C&p1=18504901495&addfields=sms_address,mms_address,ocn
  
  
  Response:
  
  {
  
    "response": {
  
      "results": [
  
    {
  
      "status": "OK",
  
      "number": "18504901495",
  
      "wless": "y",
  
      "carrier_name": "Verizon Wireless",
  
      "carrier_id": "5",
  
      "country": "United States",
  
      "sms_address": "8504901...@vtext.com",
  
      "mms_address": "8504901...@vzwpix.com",
  
      "ocn": "6006"
  
    }
  
      ]
  
    }
  
  }
  
  
  
  
  On 03/26/2018 09:29 AM, Shripal Daphtary wrote:
  
  everyoneapi.com might be useful.


Thanks,


Shripal


On Mar 26, 2018, at 9:14 AM, Ivan
  Kovacevic  wrote:
  
  
  Hi Everyone,
  
  
  We are looking for an API provider for real-time carrier
  lookups.
  
  Specifically because we need to determine the Canadian
  wireless carrier
  
  (Rogers, Bell, Telus, etc.) to know where to direct a text
  message.
  
  
  I see Twillio has a real-time API, but it's quite pricy. When
  I looked at
  
  this about a decade ago, Telcordia used to have monopoly on
  this type of
  
  data, hoping things have changed.
  
  
  Thanks in advance.
  
  
  Ivan Kovacevic
  
  VP Client Services
  
  STAR TELECOM
  
  www.startelecom.ca
  
  
  -- 
  
  
  NOTE: This email message and any attachments are for the sole
  use of the
  
  intended recipient(s) and may contain confidential and/or
  privileged
  
  information. Any unauthorized review, use, disclosure or
  distribution is
  
  prohibited. If you are not the intended recipient, please
  contact the
  
  sender by replying to this email, and destroy all copies of
  the original
  
  message.
  
  ___
  
  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] SIP return message on misdials - 487 or 500/503 or ?

[Glen Gerhard]

  
  
Hi Erick,
  
  the only carrier who knows the number is invalid is the LEC/CLEC
  that owns the block.  They probably will send back a 404 Not Found
  or 604 in most cases.  However unless you are directly connected
  to them you may not get that response returned to you.  The
  intermediate carriers will generally be configured to return a 503
  in case of any failure.
  
  Also the Cancels you see may be due to the termination carrier
  playing an inband ring media that is a tri-tone "your call cannot
  be completed as dialed" message.  Since it is during the ring
  phase the caller (or dialer app) will Cancel the call resulting in
  a 487 cause code.  For dialer apps this is a benefit since the
  good ones will recognize the tri-tone and remove the number from
  their calling list.
  
  ~Glen


On 10/5/2015 9:19 AM, Erick Bergquist
  wrote:


  Thanks for the replies.

On the cause 41 I get a 503 which matches up.

Getting cause 63 back for the ones where I see SIP 500 Internal Server
Failure which is default behavior.

 I guess I'm good then, just wish I wouldn't see 5xx level for
mis-dials. Yes, the numbers are valid E164 formatted numbers for US
which the provider wants to see in that format.   I can't call these
numbers from other sytems either so they are indeed bad, un-allocated
numbers.


Thanks, Erick

On Mon, Oct 5, 2015 at 10:51 AM, Jay Hennigan  wrote:

  
On 10/5/15 8:16 AM, Erick Bergquist wrote:


  
Hello,

Just trying to get idea of what is normal on what providers should
return for a misdial, bad unknown number, etc.

On one provider, I get a CANCEL and a 487 Request Terminated on mis-dials.

On another provider, I get a 503 Service Unavailable and a 500
Internal Service Error back.




It depends. CANCEL and 487 Request Terminated typically comes from the
originator and means that you hung up before the call completed. Carrier was
in post-dial delay and hadn't returned anything (yet).

503 means that the carrier can't or won't process the call. Could be a
misdial where the number can't be parsed as in not enough or too many
digits, prefix starts with 1 or 0, etc. Could also be that you tried to dial
a valid number that the carrier doesn't handle, such as international,
900/976, etc. Could also mean that you didn't pay your bill or are coming
from an IP address that isn't a customer of that carrier.

For a number that is in the correct format but isn't in service, you might
see 503 or also 404 or 604.

500 internal service error is usually a technical problem with the carrier
and not a misdial.

Different carriers map ISDN/SS7 cause codes to SIP differently. See:

https://www.google.com/search?q=isdn+cause+code+to+sip+mapping

--
Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

___
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] Preventing calls to cell phones with guaranteed accuracy

[Glen Gerhard]

  
  
The official NPAC database is always up to date and
  is available from Neustar (for now) commercially on a per dip or
  per monthly charge.  You can pull down the updates every 15
  minutes to ensure the data is up to date for you network or you
  can just send them a dip for every call (Invite with 302 return).
  
  The NPAC members can get a nightly pull for the DB which means it
  is up to 24 hours of date, but normally that is accurate enough
  for wholesale providers.  Due to the large liability issues, for
  your application you should go with the 15 minute updates or
  direct Neustar dips.
  
  ~Glen
  

On 8/18/2015 3:04 PM, Carlos Alvarez
  wrote:


  I'm going to answer a number of messages at once,
because there were quite a few replies (thanks to all of you).


NPA-NXX filtering is already being done, and is useless. 
  So they also employ list scrubbing based on what appears to be
  old/cached LNP info or dips, and that is also insufficient
  both legally and practically.  The data sources being used in
  the industry now do not appear to comply with the law.


For anyone who is saying that you can't determine a cell
  phone due to LNP, you are wrong.  Please look up these terms
  and you will see it's very possible:  LERG, LRN, OCN  As far
  as cell phones that are turned into "home" service, that's
  fine, we don't care about false positives.  We just need to
  make sure that a cell number is never dialed by mistake.  And
  the law allows a 15 day grace period from porting.


On the "guarantee" that isn't something we'd provide, what
  I mean was simply a data source that is always accurate.  Such
  as LRN-LERG testing for every call.  The customer will accept
  ultimate responsibility.


Some people recommended third-party services both on and
  off the list.  The one concern there is again, accuracy.  If
  the list scrubbers can't get it right...then any third party
  is suspect.  Are they using cached data?  Or acquiring data
  from dubious sources?  I don't know.



    
  
  
  
On Tue, Aug 18, 2015 at 2:31 PM Glen Gerhard <ggerh...@sansay.com>
  wrote:


   Carlos,
  
  you can get a list of all NPA-NXXs that are used by cell
  carrier and use that as a starting point.  Then add to
  that the list of LRNs used by call carriers which may or
  may not be included in the first list.
  
  Then you need to dip your traffic and compare the DNIS/LRN
  to the combined list.  If the number is ported the LRN
  will match the list.  If the number is not ported and is
  cellular it will be in the list of NPA-NXX.  If not
  cellular it won't match the list.
  
  Either way if there is a match to the list then you can
  reject the call for that customer.  (I believe you are a
  Sansay customer so you can set up a route table with the
  combined list and then use it as the primary route table
  for those customers and then link to normal tables.  I can
  have our support team put together the list of current
  NPA-NXX but you'll need a LERG6 subscription to keep it
  current).
  
  Good luck,
  
  ~Glen
  
  PS this message is not copyrighted nor confidential ;-)
  
  
  
  

  
On 8/18/2015 2:14 PM, Erik Flournoy wrote:


  Derek, 


Is actually right. Legislation that blocks a
  company from auto dialing a number based on it being a
  cell phone or landline is extremely difficult to
  prosecute. Straight talk has a home service that
  essentially uses a wireless carrier backbone. I can
  pickup the base plug it in at my neighbors house or
  better yet put it in my car on a power inverter and
  wah lah my home phone is what it truly is a cell phone
  with a 110-220v power supply.  Number Portability
  would make wireline and wireless number location
  nearly impossible. Manua

Re: [VoiceOps] Preventing calls to cell phones with guaranteed accuracy

[Glen Gerhard]

  
  
Carlos,
  
  you can get a list of all NPA-NXXs that are used by cell carrier
  and use that as a starting point.  Then add to that the list of
  LRNs used by call carriers which may or may not be included in the
  first list.
  
  Then you need to dip your traffic and compare the DNIS/LRN to the
  combined list.  If the number is ported the LRN will match the
  list.  If the number is not ported and is cellular it will be in
  the list of NPA-NXX.  If not cellular it won't match the list.
  
  Either way if there is a match to the list then you can reject the
  call for that customer.  (I believe you are a Sansay customer so
  you can set up a route table with the combined list and then use
  it as the primary route table for those customers and then link to
  normal tables.  I can have our support team put together the list
  of current NPA-NXX but you'll need a LERG6 subscription to keep it
  current).
  
  Good luck,
  
  ~Glen
  
  PS this message is not copyrighted nor confidential ;-)
  
  
  
  

On 8/18/2015 2:14 PM, Erik Flournoy
  wrote:


  Derek, 


Is actually right. Legislation that blocks a company from
  auto dialing a number based on it being a cell phone or
  landline is extremely difficult to prosecute. Straight talk
  has a home service that essentially uses a wireless carrier
  backbone. I can pickup the base plug it in at my neighbors
  house or better yet put it in my car on a power inverter and
  wah lah my home phone is what it truly is a cell phone with a
  110-220v power supply.  Number Portability would make wireline
  and wireless number location nearly impossible. Manual dialing
  would be the only way to prevent an auto dialer issue. 
  
  

  

  
Erik Flournoy
  808-426-4527
301-218-7325


CONFIDENTIALITY NOTICE
This e-mail message, including any attachments
from EESPRO.com - contain information which is
CONFIDENTIAL AND/OR LEGALLY PRIVILEGED. The
information is intended only for the use of the
individual named above and may not be
disseminated to any other party without written
permission. If you are not the intended
recipient, or the employee or agent responsible
for delivering the message to the intended
recipient, you are hereby notified that any
dissemination, disclosure, distribution, copying
or taking of any action in reliance on the
contents of this e-mailed information is
strictly prohibited. If you have received this
transmission in error, please immediately
notify in...@eespro.com,
and permanently delete this e-mail and the
attachments hereto, if any, and destroy any
printout thereof.  

  

  

  


On Tue, Aug 18, 2015 at 11:00 AM, Derek
  Andrew 
  wrote:
  
Isn't it impossible to decide if a number is
  a cell phone or a land line because of local number
  portability?
  
  
On Tue, Aug 18,
2015 at 2:34 PM, Matthew Crocker 
wrote:
  
  





Depending on your switch you should be able
  to build a profile for the customer and reject
  calls going to cell phone LRN providers.  


Personally, I wouldn’t take on the liability of
guaranteeing their auto-dialer only calls
landlines.   You would end up being sued if you
make a mistake.  IMHO, let them manually dial or
find a list scrubbing company that actually
works.

  
—
  
  
  Matthew
Crocker
  

Re: [VoiceOps] Which Softswitch?

[Glen Gerhard]

  
  
I'll reply to the list since it seems of general
  interest.  My company makes C4 Softswitches but I'll stick with
  general recommendations.
  
  Common commercial manufacturers include ourselves, GenBand, Sonus,
  Oracle, Switchray (aka Mera), Kamalio, Cataleya and others.  Most
  of these will cover your short list of requirement.
  
  However you may also look for other relatively important features
  since your Softswitch investment will last a long time and your
  network requirements can change.  Common other features to look at
  or plan for include:
  
  1.    Access/Subscriber side SBC functions for hosted C4/PBXs like
  Broadsoft.
  2.    DOS/DDOS detection and mitigation.
  3.    Fault tolerance or HA operation (ie, stateful switchovers).
  4.    LCR and/or billing applications to control off net routing.
  (another whole world of features exist on this subject)
  5.    TLS/SRTP support.  
  6.    Good monitoring applications for performance alerts and
  troubleshooting.
  7.    Transcoding support.
  8.    VM deployment options.
  
  The debate about the value of open source is ongoing and subject
  to change.  Alex addressed this subject well but it is worth
  noting that some large carriers are embracing open source
  solutions so that they can modify the functionality themselves. 
  Alternatively many small carrier select open source so they can
  save money on capex costs although this will normally lead to
  higher opex costs for management.
  
  On the subject of OS I would recommend staying with Linux and
  avoid a Microsoft solution.  The real time nature of media
  handling seems to be problematic for Windows although potentially
  the Intel DPDK technology may mitigate some of these problems.
  
  Best regards,
  
  ~Glen
   
  

On 6/20/2015 11:21 AM, Ryan Finnesey
  wrote:


  
  
  
  
  

  I
also need to select a softwitch shortly.   I can  understand
why some may   reply off list but if you would not mind
posting a summary it would be much appreciated.




Sent from my Windows Phone


  
  From:
  Greg Lipschitz
  Sent:
  ‎6/‎20/‎2015 2:40 AM
  To:
  voiceops@voiceops.org
  Subject:
  [VoiceOps] Which Softswitch?
  

  
  
  Hi All,

We are in the process of going down the path of deploying
our own Softswitch infrastructure to transition away from
purchasing from SIP Trunk providers and moving to getting
CTS direct from VoIP Carriers.

There seems to be a lot of solutions out on the market and
weeding out the "Built on Asterisk" / "Built on Freeswitch"
with little or no support vs Commercial Supported solutions
is proving to be difficult.

There are the "leaders" (or strong marketing companies) such
as Broadsoft & Metaswitch - but what I am trying to
uncover is what else is great out there that may not have
the exposure but is worth looking at.

What we are looking for...

1. Class 4 Softswitch
2. Geographical Redundancy (Active - Active)
3. Preferably not built on Freeswitch or Asterisk (Not
saying they're bad just tired of OpenSource for Core
products)
4. Must have commercial support available (preferably during
Australian hours)
5. Windows or Linux doesn't phase us - we have skill set on
both platforms.

Happy to hear the good, the bad, the ugly, the war stories
so that we can get some real world feedback on what's out
there, what works, what doesn't and hopefully not make the
same mistakes that others have already made.

Offlist replies are perfectly fine if you don't wish to
discuss on-list.

Thanks in advance and enjoy the rest of your weekend! :)

Cheers,

Greg


Greg Lipschitz | Director | The Summit Group
E: g...@thesummitgroup.com.au  W: www.thesummitgroup.com.au
The Summit Group (Australia) Pty Ltd | P: 1300 049 749 |
Level 1, 39 Railway Road, Blackburn  VIC  3130
The Summit Group (USA) LLC | P: 321 216 3844 | Suite 561,
40E Main Street, Newmark  DE 19711
Postal:  P.O. Box 3225, Doncaster East  VIC  3109


  

Re: [VoiceOps] Toll Free as Outbound CLID

[Glen Gerhard]

  
  
Hi Shripal,
  
  normally calls with TF CLIDs are just billed as Indeterminant
  Jurisdiction.   If your rate sheets don't specify IJ calls then it
  is generally the higher of the two rates.
  
  ~Glen
  
  

On 4/20/2015 8:38 AM, Shripal Daphtary
  wrote:


  thanks Ivan, 


i was just told that its not that we CANT do it on the
  bworks, but we don't b/c currently can't bill for it if the
  clid is a TFN. 
  
  
On Mon, Apr 20, 2015 at 11:36 AM, Ivan
  Kovacevic 
  wrote:
  

  
Hi
Shri,
 
In
Canada it is mandated by the CRTC and most carriers
pass it through when we send it. Most of our
US-bound traffic uses TF CLI which seems to come
across. So as far as we are aware, using TF as CLI
is not an issue. 
 
Best
Regards,
 
Ivan
Kovacevic
Vice President, Client Services
Star
Telecom | www.startelecom.ca
| SIP Based Services for Contact Centers 
 
From: VoiceOps [mailto:voiceops-boun...@voiceops.org]
On Behalf Of Shripal Daphtary
Sent: Monday, April 20, 2015 11:13 AM
To: VoiceOps@voiceops.org
Subject: [VoiceOps] Toll Free as Outbound
CLID

  
 

  Hello everyone, 
  
 
  
  
i'm just wondering if there
  is a legal/regulatory issue with having a TFN
  as the outbound CLID for a customer on our
  hosted platform(s).  
  
  
 
  
  
On the broadworks, the
  system won't even allow for it.  However, on
  our M6, it doesn't really care.
  
  
 
  
  
thanks
  
  
 
  
  
Shri 
  
  
 
  
  
 
  

  

  

  


  
  
  
  
  ___
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] Fraud Management

[Glen Gerhard]

  
  
Hi Shaun,
  
  most systems work off CDR files (or Radius or Diameter steams) so
  are proprietary in what products they support (http://oculeus.com
  is one such system).  There are some products that are
  auto-learning based on SIP monitoring so are device independent. 
  http://tollshield.com is one of them and builds a network profile
  over several week to understand "normal" traffic patterns.  It can
  alert on variations of those patterns.  These systems requires
  monitoring ports whereas the CDR approach does not need SPAN
  ports.
  
  Also there is a difference between systems that can alert on fraud
  on ones that can proactively shut off service to suspect devices. 
  The proactive ones are usually device specific and more expensive
  and raise the risk of false positives.  
  
  Regards,
  
  ~Glen
  

On 1/29/2015 11:19 PM, Shaun Gill
  wrote:


  
  

  Hi Brad,

  
  
  
  Neither - We are not using a product at this stage; using a
combination of routing profiles (BSFT) and originating source
IPs to block suspect traffic.
  
  
  Regards,
  Shaun
  
  
  

  From: Brad Anouar 
  Date: Friday 30 January
  2015 3:07 AM
  To: Shaun Gill 
  Cc: Jay Cox ,
  "voiceops@voiceops.org"
  
  Subject: Re: [VoiceOps]
  Fraud Management




  
Shaun,
  
  
  Have you used the SIP or CDR based product?


  On Thu, Jan 29, 2015 at 3:26 PM,
Shaun Gill 
  
wrote:

  

  
Noted – I will be checking this out Jay.

  
  

  


  
From: Jay
Cox 
Date: Wednesday
28 January 2015 3:44 PM
To: Shaun
Gill , "voiceops@voiceops.org"

Subject: RE:
[VoiceOps] Fraud Management
  
  
  
  

  
Shaun:
 
I
have used the TransNexus solution for a
long time.
 

  Jay Cox
  Mobile 
  314
910 7242

 

  
From: VoiceOps [mailto:voiceops-boun...@voiceops.org]
On Behalf Of Shaun Gill
Sent: Wednesday, January 28,
2015 2:37 AM
To: voiceops@voiceops.org
Subject: [VoiceOps] Fraud
Management
  

 

  

  Hi Guys,


   


  Trying to get a feel
  for what fraud systems are out
  there for VoIP service providers;
  primarily using terrestrial
  mediums (such as metroE; diginet)
  with clients interconnecting via
  IP PBXs, voice gateways and IP
  phones.

  


  We have had fraud to
  international premium destinations