- VoiceOps - lists.voiceops.org

Edgewater Networks Contact
by tim.donahue＠gmail.com March 21, 2014

March 21, 2014

Hi all, Sorry for the noise. We have been trying to get in contact with Edgewater Networks, but haven't had any success through their published phone number or email address. I am hoping that someone here can provide a direct contact within the sales department at Edgewater. We are located in New England if this helps locate the correct person to speak with. Thank you, Tim Donahue

1 0

Linefeed in CNAM data?
by nick＠flhsi.com March 21, 2014

March 21, 2014

OpenCNAM (free) doesn't let you query everything from what I understand. Here's the paste from our internal tool that queries both openCNAM (Paid) and "Call with us". Looks fine to me.. (CWUS) CNAM: Neilsen Paul (OPCN) CNAM: SKYPE CALLER LRN: 16617480993 State: CA Ratecenter: BKFD MAIN LATA: 734 OCN: 649C Company: NEUTRAL TANDEM CA Type: CLEC Last Request: 03-21-2014 10:34:58 Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Nathan Anderson" <nathana at fsr.com> Sent: Thursday, March 20, 2014 12:36 AM To: "Carlos Alvarez" <Carlos at thresholdcommunications.com>, "voiceops at voiceops.org" <voiceops at voiceops.org> Subject: Re: [VoiceOps] Linefeed in CNAM data? ??? That's...wrong. I'm not a customer, but given that they have a "free" option, I decided to try an OpenCNAM query for that number and got this: 'CNAM for phone "+16617480240" is currently unavailable for Hobbyist Tier users.' What? Their site says nothing about lookups for certain numbers only being avaiable on the "pro" tier. What is up with this particular phone number?? -- Nathan On Wednesday, March 19, 2014 8:15 PM, Carlos Alvarez <mailto:Carlos at thresholdcommunications.com> wrote: > I get Neilsen Paul from OpenCNAM. > > ________________________________________ > From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of Nathan > Anderson <nathana at fsr.com> > Sent: Wednesday, March 19, 2014 6:12 PM > To: 'voiceops at voiceops.org' > Subject: [VoiceOps] Linefeed in CNAM data? > > Our CNAM lookup provider is sending us name data for one particular > number that includes a linefeed in it. It's possible that it's their > mistake and that this particular number's CNAM data doesn't actually have > this character in it, but it raises the question: is this a legal > character? > > The number in question is a SkypeOut gateway: 661-748-0240 -- I'd be > curious to know what other people are seeing on a CNAM lookup for this. > What we are getting is "SKYPE USER\nSKYPE USER". And, actually, now that > I think about it, this can't possibly be the actual value since I believe > CNAM is limited to 15 characters. So I'll talk to our provider about > this. (This is the only number that we have seen anything like this > with.) > > BTW, it turns out that when Asterisk sends an INVITE and the > CALLERID(name) value has been stuffed with a string that contains a > newline, it decides to send this in the headers: > > From: "SKYPE USER\ > SKYPE USER" <sip:6617480240 at 192.0.2.1> > > ...so it includes the linefeed (ASCII 10) in the string, but tries to > escape it with a '\' (which is not entirely unprecedented). An Asterisk > box on the receiving end of that INVITE, however, will completely ignore > the INVITE...it won't log an error and doesn't bother dignifying it with > a response, probably because it sees that as two separate lines (it > doesn't concatenate two lines that are separated by a '\') and the second > line all by itself looks like garbage/wouldn't make sense to a SIP dialog > parser. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

1 0

Linefeed in CNAM data?
by nathana＠fsr.com March 20, 2014

March 20, 2014

Our CNAM lookup provider is sending us name data for one particular number that includes a linefeed in it. It's possible that it's their mistake and that this particular number's CNAM data doesn't actually have this character in it, but it raises the question: is this a legal character? The number in question is a SkypeOut gateway: 661-748-0240 -- I'd be curious to know what other people are seeing on a CNAM lookup for this. What we are getting is "SKYPE USER\nSKYPE USER". And, actually, now that I think about it, this can't possibly be the actual value since I believe CNAM is limited to 15 characters. So I'll talk to our provider about this. (This is the only number that we have seen anything like this with.) BTW, it turns out that when Asterisk sends an INVITE and the CALLERID(name) value has been stuffed with a string that contains a newline, it decides to send this in the headers: From: "SKYPE USER\ SKYPE USER" <sip:6617480240 at 192.0.2.1> ...so it includes the linefeed (ASCII 10) in the string, but tries to escape it with a '\' (which is not entirely unprecedented). An Asterisk box on the receiving end of that INVITE, however, will completely ignore the INVITE...it won't log an error and doesn't bother dignifying it with a response, probably because it sees that as two separate lines (it doesn't concatenate two lines that are separated by a '\') and the second line all by itself looks like garbage/wouldn't make sense to a SIP dialog parser. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com

3 2

Linefeed in CNAM data?
by nathana＠fsr.com March 19, 2014

March 19, 2014

??? That's...wrong. I'm not a customer, but given that they have a "free" option, I decided to try an OpenCNAM query for that number and got this: 'CNAM for phone "+16617480240" is currently unavailable for Hobbyist Tier users.' What? Their site says nothing about lookups for certain numbers only being avaiable on the "pro" tier. What is up with this particular phone number?? -- Nathan On Wednesday, March 19, 2014 8:15 PM, Carlos Alvarez <mailto:Carlos at thresholdcommunications.com> wrote: > I get Neilsen Paul from OpenCNAM. > > ________________________________________ > From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of Nathan > Anderson <nathana at fsr.com> > Sent: Wednesday, March 19, 2014 6:12 PM > To: 'voiceops at voiceops.org' > Subject: [VoiceOps] Linefeed in CNAM data? > > Our CNAM lookup provider is sending us name data for one particular > number that includes a linefeed in it. It's possible that it's their > mistake and that this particular number's CNAM data doesn't actually have > this character in it, but it raises the question: is this a legal > character? > > The number in question is a SkypeOut gateway: 661-748-0240 -- I'd be > curious to know what other people are seeing on a CNAM lookup for this. > What we are getting is "SKYPE USER\nSKYPE USER". And, actually, now that > I think about it, this can't possibly be the actual value since I believe > CNAM is limited to 15 characters. So I'll talk to our provider about > this. (This is the only number that we have seen anything like this > with.) > > BTW, it turns out that when Asterisk sends an INVITE and the > CALLERID(name) value has been stuffed with a string that contains a > newline, it decides to send this in the headers: > > From: "SKYPE USER\ > SKYPE USER" <sip:6617480240 at 192.0.2.1> > > ...so it includes the linefeed (ASCII 10) in the string, but tries to > escape it with a '\' (which is not entirely unprecedented). An Asterisk > box on the receiving end of that INVITE, however, will completely ignore > the INVITE...it won't log an error and doesn't bother dignifying it with > a response, probably because it sees that as two separate lines (it > doesn't concatenate two lines that are separated by a '\') and the second > line all by itself looks like garbage/wouldn't make sense to a SIP dialog > parser.

2 1

Carrier to Carrier Support Contact List?
by dthompson＠esi-estech.com March 14, 2014

March 14, 2014

Figured I'd ask here first instead of taking it upon myself to compile a list of carrier to carrier support contact numbers. Does anyone have a list that they can send me? Getting sick and tired to trying to explain to a front line support person that my customer is having problems calling their customers due to some misconfiguration on their side. I'm typically bounced around 3-5 times between departments and I may get help or I may not. David Thompson Network Services Support Technician (O) 858.357.8794 (F) 858-225-1882 (E) dthompson at esi-estech.com (W) www.esi-estech.com

3 2

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