March 2014 - VoiceOps - lists.voiceops.org

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

March 20, 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 15, 2014

March 15, 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 10, 2014

March 10, 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