- VoiceOps - lists.voiceops.org

Comcast VoIP degradation
by nick.crocker＠gmail.com March 13, 2014

March 13, 2014

Has anyone been seeing voice degradation reports coming in from customers using Comcast DIA? We have several complaints that have came in the last week or so and the commonality it Comcast. Tracing out to the customer sites we are directly peered with L3 which drops the traffic straight into Comcast, we are picking up an additional 20-30ms or so once on Comcast but the latency varies quite a bit once in the Comcast network. Anyone on from Comcast available to talk offline? Regards, Nick

2 1

Timing slips on subrate DS1s on CT3
by abalashov＠evaristesys.com March 9, 2014

March 9, 2014

Hi, I was hoping I could pick someone's brain here about an issue that has me stumped. Customer has a Cisco AS5400 (non-XM) with a channelised T3 from $MAJORTELCO. The 28 subrate DS1s are just PRIs, no NFAS, just 23B+1D on every DS1. Like so: controller T3 6/0 framing m23 clock source line t1 1-28 controller ! controller T1 6/0:1 framing esf pri-group timeslots 1-24 ! controller T1 6/0:2 framing esf pri-group timeslots 1-24 ! [and so on] They were having some Q.931 messaging issues that were ultimately traced to timing slips on the DS1s. And yes, there are timing slips indeed: VOIPGW-1#show controllers T1 6/0:1 T1 6/0:1 is up. Applique type is Channelized T1 No alarms detected. alarm-trigger is not set Soaking time: 3, Clearance time: 10 AIS State:Clear LOS State:Clear LOF State:Clear Version info of slot 6: HW: 768, PLD Rev: 1 Framer Version: 0x28 Manufacture Cookie Info: EEPROM Type 0x0001, EEPROM Version 0x01, Board ID 0x01, Board Hardware Version 3.0, Item Number 73-4089-03, Board Revision B0, Serial Number JAB0429044D, PLD/ISP Version <unset>, Manufacture Date 14-Jul-2000. Framing is ESF, Clock Source is Line. Data in current interval (579 seconds elapsed): 0 Line Code Violations, 0 Path Code Violations 579 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins 579 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs $MAJORTELCO says this is because we're not taking recovering clock from the line. But we quite clearly are: "Framing is ESF, Clock Source is Line." In fact, this IOS release (Version 12.4(7g)) doesn't seem to give me a way to change that even if I wanted to. This subcommand: controller T3 6/0 t1 1 clock source internal ... would be the normal way to do it, but the only subcommand that exists for 't1 X' is 'controller'. There are no PM errors on the T3 itself: T3 6/0 is up. Applique type is Channelized T3 No alarms detected. Framing is M23, Line Code is B3ZS, Clock Source is Line Data in current interval (750 seconds elapsed): 0 Line Code Violations, 0 P-bit Coding Violation 0 C-bit Coding Violation, 0 P-bit Err Secs 0 P-bit Severely Err Secs, 0 Severely Err Framing Secs 0 Unavailable Secs, 0 Line Errored Secs 0 C-bit Errored Secs, 0 C-bit Severely Errored Secs So, what's the deal? Where are these timing slips on the DS1s coming from? -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/

6 14

Verizon RTO POP
by jared＠compuwizz.net March 3, 2014

March 3, 2014

Anyone else see their Verizon RTO location VPN go down besides me? Its still down at the moment for us. Regards, Jared Geiger

1 0

Fraud
by John＠InteleChoice.us Feb. 26, 2014

Feb. 26, 2014

I am new to your site. I was looking in the Archives and saw in November 2013 there were some of you who experienced fraud. We had a an Avaya IP Office customers system who got hit pretty bad. The customer is treating the fraudulent calls like credit card fraud and not taking any responsibility. Does anyone have any advice on how to persuade the customer take this issue seriously? His bill was racked up pretty good. Strangely and coincidentally Avaya came out with a security bulletin the end of December 2013 on this same issue. I tried to contact Avaya with no response. It seems as though someone has built a sniffer for the Avaya IP Offices and gleaning their registrations.

11 12

Fraud
by mylists＠battleop.com Feb. 25, 2014

Feb. 25, 2014

I'm pretty sure it would ruffle some feathers around here if I sent that list out into the public domain. I can tell you that we basically go thought the rate deck and filter anyone that's above X amount per minute and then throw in countries where customer's hacked PBX's send calls to. It's not the most scientific method but it's the most complaint free method. Richey From: John Curry [mailto:telecom7 at gmail.com] Sent: Monday, February 24, 2014 4:21 PM To: 'My List Account'; voiceops at voiceops.org Subject: RE: [VoiceOps] Fraud Would you mind sharing your hi toll rate destination dial plan? From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of My List Account Sent: Monday, February 24, 2014 1:48 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] Fraud Maybe I am missing something here but why does the carrier that delivers the fraudulent traffic to the Telco that's in on the fraud pay the Telco that's in on the fraud for the calls that are delivered to their network? Seems pretty simple, if you cut off their revenue stream they won't have a reason to continue. I guess we all know there is no incentive for them to stop this practice because it's a big cash cow for everyone except for the poor end user who is left holding the bag. Our default dial plan won't let you dial these destinations so we don't have a real issue with this abusive traffic. Most of our customers who use international go with one of our filtered dial plans that let them dial most of the world except for known fraudulent and high toll rate destinations. Richey From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Ryan Delgrosso Sent: Saturday, February 22, 2014 11:48 AM To: voiceops at voiceops.org Subject: Re: [VoiceOps] Fraud In most cases you will lose this customer. They don't see this as their responsibility (i.e. the credit card fraud defense) but the reality is their equipment was compromised due to their negligence. If the customer is reasonable offer them your cost on the damages so its just a passthrough. Otherwise you can take them to court or just send them to collections. BTW while many will advocate fraud detection and mitigation systems here, its been my experience (we wrote our own fraud system that out-performs our upstream carriers by hours) that if you detect fraud on a customer like this, and shut it down in minutes, and mitigate what could have been thousands of dollars in damage due to their mis-configured systems, reducing it to just tens or hundreds they will often still fight that amount and deny responsibility. The fraud system protects you, and by extension the customer, but the customers don't see it that way. -Ryan On 02/19/2014 02:09 PM, John Curry wrote: I am new to your site. I was looking in the Archives and saw in November 2013 there were some of you who experienced fraud. We had a an Avaya IP Office customers system who got hit pretty bad. The customer is treating the fraudulent calls like credit card fraud and not taking any responsibility. Does anyone have any advice on how to persuade the customer take this issue seriously? His bill was racked up pretty good. Strangely and coincidentally Avaya came out with a security bulletin the end of December 2013 on this same issue. I tried to contact Avaya with no response. It seems as though someone has built a sniffer for the Avaya IP Offices and gleaning their registrations. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

2 1

VoIP passive monitoring appliances or software - any recommendations?
by ml＠knight-networks.com Feb. 24, 2014

Feb. 24, 2014

$DAY_JOB is at a national ISP/NSP where we resell VoIP services. We do peering with the VoIP carrier at one of our remote POP's. We are looking for a better way to be able to monitor the handoff of those calls to our carrier over that peering link. We have quite a bit of instrumentation within our walled garden to tell us about call quality. We can monitor our QOS policies to ensure packets aren't being dropped by intermediate routers. If the customer uses our routers to terminate their SIP session, we can pull call quality stats from those routers as well. We can also use our own office telephones to make and receive test telephone calls, and we can of course run Wireshark captures from the switches to which those phones are connected. However, we can't say for certain that the customer's RTP traffic actually made it on the wire connecting us to the VoIP provider, nor can we say that the traffic is being transmitted and received properly. The peering link is connected to a Cisco 12k router on our side, so there is no way (afaik) to mirror the port, as on a switch. For the moment, I am envisioning that we'll need to deploy a server running Wireshark to the remote POP. It will need two network interfaces; one connected to a management network, the other a capture interface. The capture interface will connect to a network tap, and the network tap connected in-line between our router and the patch panel. Wireshark is probably adequate for what we need. But I'm wondering if there is any software or an appliance that would do the job better. Given the usual details - calling number, called number, date and time - we want to be able to quickly inspect traffic and dig into the details of the stream. Do we see any missing packets from the media stream? What is the MOS score of a particular call? Do we see any missing packets coming from us? Any missing packets from the provider? Alerting on bad call quality would be a nice-to-have addition. Any recommendation would be appreciated. Thanks in advance. -Brian Knight

11 13

Fraud
by John＠InteleChoice.us Feb. 24, 2014

Feb. 24, 2014

Would you mind sharing your hi toll rate destination dial plan? From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of My List Account Sent: Monday, February 24, 2014 1:48 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] Fraud Maybe I am missing something here but why does the carrier that delivers the fraudulent traffic to the Telco that's in on the fraud pay the Telco that's in on the fraud for the calls that are delivered to their network? Seems pretty simple, if you cut off their revenue stream they won't have a reason to continue. I guess we all know there is no incentive for them to stop this practice because it's a big cash cow for everyone except for the poor end user who is left holding the bag. Our default dial plan won't let you dial these destinations so we don't have a real issue with this abusive traffic. Most of our customers who use international go with one of our filtered dial plans that let them dial most of the world except for known fraudulent and high toll rate destinations. Richey From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Ryan Delgrosso Sent: Saturday, February 22, 2014 11:48 AM To: voiceops at voiceops.org Subject: Re: [VoiceOps] Fraud In most cases you will lose this customer. They don't see this as their responsibility (i.e. the credit card fraud defense) but the reality is their equipment was compromised due to their negligence. If the customer is reasonable offer them your cost on the damages so its just a passthrough. Otherwise you can take them to court or just send them to collections. BTW while many will advocate fraud detection and mitigation systems here, its been my experience (we wrote our own fraud system that out-performs our upstream carriers by hours) that if you detect fraud on a customer like this, and shut it down in minutes, and mitigate what could have been thousands of dollars in damage due to their mis-configured systems, reducing it to just tens or hundreds they will often still fight that amount and deny responsibility. The fraud system protects you, and by extension the customer, but the customers don't see it that way. -Ryan On 02/19/2014 02:09 PM, John Curry wrote: I am new to your site. I was looking in the Archives and saw in November 2013 there were some of you who experienced fraud. We had a an Avaya IP Office customers system who got hit pretty bad. The customer is treating the fraudulent calls like credit card fraud and not taking any responsibility. Does anyone have any advice on how to persuade the customer take this issue seriously? His bill was racked up pretty good. Strangely and coincidentally Avaya came out with a security bulletin the end of December 2013 on this same issue. I tried to contact Avaya with no response. It seems as though someone has built a sniffer for the Avaya IP Offices and gleaning their registrations. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

1 0

[VOIPSEC] Tackling VoIP fraud, new idea
by David.Hiers＠adp.com Feb. 24, 2014

Feb. 24, 2014

The key is vetting the participants. Even the feds have a hard time with that... David -----Original Message----- From: Voipsec [mailto:voipsec-bounces at voipsa.org] On Behalf Of Mark Collier Sent: Friday, February 21, 2014 12:44 To: J. Oquendo Cc: voiceops at voiceops.org; voipsec at voipsa.org; Peter Beckman Subject: Re: [VOIPSEC] [VoiceOps] Tackling VoIP fraud, new idea I like the idea of the list and will participate Mark D. Collier Chief Technology Officer/VP Engineering Securelogix Corporation 13750 San Pedro San Antonio, Texas 78232 (210) 863-9001 www.SecureLogix.com www.voipsecurityblog.com > On Feb 21, 2014, at 12:23 PM, "J. Oquendo" <sil at infiltrated.net> wrote: > >> On Fri, 21 Feb 2014, Sergey Kolesnichenko wrote: >> >> Why dont't you want to speak about tactics here openly? >> > > Common sense. This is a public list, and there is no way for me to > determine the intentions of anyone who is a subscriber to the list. It > is a KNOWN fact, that criminals subscribe to security mailing lists > such as Bugtraq, Full Disclosure and others. Not for the sake of > lending a helping hand, but for other means. Much similar to malware > authors who run their malware through VirusTotal to see if anything is > going to detect it. > > On a private list, there is the accountability factor to equate. > Someone subscribed using a corporate email address. > Therefore SOME form of vetting took place. > > > -- > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > J. Oquendo > SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM > > "Where ignorance is our master, there is no possibility of real peace" > - Dalai Lama > > 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF > > _______________________________________________ > Voipsec mailing list > Voipsec at voipsa.org > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org _______________________________________________ Voipsec mailing list Voipsec at voipsa.org http://voipsa.org/mailman/listinfo/voipsec_voipsa.org 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, please notify us immediately by e-mail and delete the message and any attachments from your system.

7 9

Voice DDOS ?
by ivan.kovacevic＠startelecom.ca Feb. 24, 2014

Feb. 24, 2014

Hi Folks, We are seeing something strange coming across our network. A disconnected client TFN is receiving 30,000+ calls per hour (all failing). The ANIs being used are dummy ANIs 17029983416 (no answer) and 16469820093 (recording saying "no routes found"). This is not affecting our network, although it's causing the upstream provider a bit of grief. Not sure why someone would do this.... We are about to remove the CICs at the sms800 level, but just wondering if anyone has come across something similar? Thanks, Ivan

4 5

[VOIPSEC] Tackling VoIP fraud, new idea
by beckman＠angryox.com Feb. 21, 2014

Feb. 21, 2014

I don't mind, but some believe that letting the fraudsters in on our techniques allows them to have more information in order to circumvent our roadblocks. If there was a private list, technical implementations could be spoken of without tipping our hand in public forums for fraudsters to counter. Beckman On Fri, 21 Feb 2014, Sergey Kolesnichenko wrote: > Why dont't you want to speak about tactics here openly? > > > 2014-02-21 19:51 GMT+02:00 Peter Beckman <beckman at angryox.com>: > >> Email sucks for this. I don't want to read an email about something hours >> or days after the issue is happening and have to do something manually to >> protect my infrastructure. >> >> This seems like something that should be an API in which trusted people can >> access. >> >> But then you have concerns about trust of the data. Do I trust your >> reasoning for an IP block? Do I even get to see your evidence? >> >> Honestly I don't need a list or an API to block stuff. >> >> HOWEVER, if this can become a private discussion list to talk about >> methods, techniques and tactics that we can all implement in order to >> prevent telecom/SIP/VoIP fraud on our own, THAT I'd be interested in. >> >> Beckman >> >> >> >> On Fri, 21 Feb 2014, J. Oquendo wrote: >> >> On Fri, 21 Feb 2014, Sergey Kolesnichenko wrote: >>> >>> One more mailing list? :-) I'm sure it is a bad idea. I'm working for a >>>> company to protect it from VoIP related attacks, but you will never have >>>> gurantess that I will not be using the data in a private list to attack >>>> someone as a private individual :-) it is a security hole in a private >>>> list >>>> about VoIP security... >>>> >>>> >>> I disagree with it being a bad idea. There is never any >>> guarantees in life. The purpose for a private list, is it >>> protects COMPANIES data. There is a trust mechanism in the >>> sense that should/if/when someone wants to contest data, >>> I can go back based on checksum to determine WHO submitted >>> what. I HIGHLY doubt, someone would throw away their >>> reputation, and or damage company reputation by submitting >>> falsified data. >>> >>> >>> -- >>> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ >>> J. Oquendo >>> SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM >>> >>> "Where ignorance is our master, there is no possibility of >>> real peace" - Dalai Lama >>> >>> 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF >>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF >>> _______________________________________________ >>> VoiceOps mailing list >>> VoiceOps at voiceops.org >>> https://puck.nether.net/mailman/listinfo/voiceops >>> >>> >> ------------------------------------------------------------ >> --------------- >> Peter Beckman Internet Guy >> beckman at angryox.com >> http://www.angryox.com/ >> ------------------------------------------------------------ >> --------------- >> > _______________________________________________ > Voipsec mailing list > Voipsec at voipsa.org > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org > --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------

1 0