- VoiceOps - lists.voiceops.org

Best termination rates to Alaska?
by dane＠corp.sonic.net Sept. 8, 2010

Sept. 8, 2010

Anyone have suggestions for Alaska? They're very expensive through our current route, over $0.30/min. -Dane

1 0

Vitelity Down
by beckman＠angryox.com Sept. 4, 2010

Sept. 4, 2010

Since about 9:36am EDT this morning, Vitelity has been down due to what looks like a major routing issue. Connectivity has come back occassionally only to go down again. This is affecting all origination, termination and any and all web services they provide. I am unable to get to their website, portal or API. I do know that they are working on it. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------

1 1

Verizon Direcory listsing
by matthew＠corp.crocker.com Sept. 2, 2010

Sept. 2, 2010

Hello, The bane of my existence as a small CLEC is dealing with Verizon LSI. I have a terrible time submitting complex whitepage & directory listing orders. Does anyone know of a company that can provide an easier to use interface and/or process DL/DA orders with Verizon North (Verizon-MA)? -Matt -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 http://www.crocker.com P: 413-746-2760

1 0

Level3 Vector Network - Inbound Failover
by gmina＠connectfirst.com Sept. 1, 2010

Sept. 1, 2010

I am currently setting up Level3 as a provider of SIP Toll-Free services. I am hearing from my account team that they don't have any option other than their BusyNoAnswer option to failover from one SIP IP (on my side) to another. If I send back a 486 or there is a timeout they can failover to a second trunk. Unfortunately, they can't decouple the 486 and timeout scenarios. and that doesn't work, because 486 is a normal non-error condition on my network and I wouldn't want the call to be re-presented to another location just because the first location sent a BUSY. I have asked them if they can failover on 5XX errors or internally generated 408, but they seem to think they are unable to do anything like this. Anyone have any experience with Level3 in this scenario? Thanks, Geoff

3 4

Check out my photos on Facebook
by invite+zrdoior6fhzf＠facebookmail.com Aug. 27, 2010

Aug. 27, 2010

I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. Thanks, Jared To sign up for Facebook, follow the link below: http://www.facebook.com/p.php?i=6215424&k=44DY43SQT55G6C1GTK46VTTYRWKAVYVAP… Already have an account? Add this email address to your account: http://www.facebook.com/n/?merge_accounts.php&e=voiceops%40voiceops.org&c=9… ======================================= voiceops at voiceops.org was invited to join Facebook by Jared Geiger. If you do not wish to receive this type of email from Facebook in the future, please follow the link below to unsubscribe. http://www.facebook.com/o.php?k=dd2ed3&u=100001475923705&mid=2e23f14G5af368… Facebook, Inc. P.O. Box 10005, Palo Alto, CA 94303

1 0

Level 3 inbound RTP issues
by ujjval＠simplesignal.com Aug. 26, 2010

Aug. 26, 2010

We are receiving reports of random RTP cut-out issues with Level 3 inbound traffic. We are investigating - wanted to check with the group if anyone else is having the same issues starting about 245pm MST

1 0

ATT Mobility SS7 Uggggh!
by clec＠cygnustel.com Aug. 24, 2010

Aug. 24, 2010

Hello all, When an ATT Mobility customer calls into our switch the call is dropped. The ss7 trace looks like this: ISUP IN 81N0 01 1 10 24 IAM 15:10:40 NATR OF CONN: B.00010000 BITS BA: .NO_SAT_CIRC BITS DC: .NO_COT_REQD BIT E : .INCO_HALF_ECHO 15:10:40 FWD CALL IND: B.00100000 B.00010001 BIT A : .NATIONAL_CALL BITS CB: .NO_END_MTHD BIT D : .NO_INTERWK 15:10:40 BIT E : .NO_INDICAT BIT F : .ISDN_USER_PART BITS HG: .ISUP_PREFERED BIT I : .ISDN BIT M : .NUM_TRANS 15:10:40 CLG PTY CTGY: ORDINARY SUB 15:10:40 USER SVCE INFO: CODE STD: B.00 .CCITT_CODE_STD XFER CAP: B.00000 .SPEECH_TRANSFER XFER MODE: B.00 .CKT_TRANSFER XFER RATE: B.10000 .64KB_SEC USER PROT ID: B.0100010 15:10:40 ISUP OUT 81N0 01 1 10 24 ANM 15:10:40 ISUP IN 81N0 01 1 10 24 REL 15:10:40 LOC LOLO B.0010 CODE B.00 CAUSE INVC 100 15:10:40 ISUP OUT 81N0 01 1 10 24 RLC 15:10:40 How can there be an 'invalid coding' on an ANM message?! They have had 7 days now to fix this and I haven't been able to get any sort of response from them. We have customers screaming at us about this. Any ideas? -Eric

2 1

"...but it works with Packet8"
by d＠d-man.org Aug. 23, 2010

Aug. 23, 2010

Hi folks, We provide a fully redundant VoIP service to our customers where they hook up two cheap Internet connections to our special little box and we load-balance / failover across them. We have been running into periodic issues with SIP ALG and such typical VoIP crippling technologies when hooking up our equipment, requiring us to get into the client's router and turn off SIP ALG (or Cisco "fix-up" features). Specifically we have issues with 2Wire devices, which are very very popular. We've been assuming this is standard/par-for-the-course behavior. We have a partner who is reselling our service and he has asked me a few times why our service requires any tweaks at all. He is literally replacing Packet8 phones with our service. We are utilizing the old Packet8 phones so it is not a model and unlikely a firmware issue. Something we are doing in our way of configuring these phones is fundamentally different then Packet8. The reseller feels we should not have to mess with the clients router. I'm starting to think he has a valid point. So, my question is, why does Packet8 work so well behind so many firewalls? I don't think their Aastra firmware is all that different then stock Aastra firmware. So my thoughts are: - They might be using TCP signaling for SIP call setup instead of UDP? - They might be ignoring the contents of SIP packets and rewrites and using rather "aggressive" settings on the switch side to figure out routing based solely on network headers (we use the actual SIP packets) - They force rport? I'm just guessing at this point, but the reseller has a valid point - we should be able to compete with this directly. Let me know your thoughts or if you have any advice on best-practices for setting up Aastras (and other phones) to behave nicely across firewalls that have SIP ALG *enabled*. Sorry if this is a lame or too broad a question. Any tips & tricks you've used are helpful. Thanks much, Darren Schreiber Co-Founder - VoIP, Inc. - (415) 886-7900 www.2600hz.org - Free VoIP Software www.voipkb.com - FreeSWITCH Trainings

13 22

"...but it works with Packet8"
by jim＠californiatelecom.com Aug. 21, 2010

Aug. 21, 2010

Are you running with an SBC? Darren Schreiber <d at d-man.org> wrote: >So do how do we get to where we "don't tweak"? Again, as Packet8 being the reference point, they seem to run into this problem very infrequently now from what I can tell... > >- Darren > > >On Aug 21, 2010, at 11:16 AM, Jim Gurol wrote: > >Darren, > >I had a similar issues when moving customers from one platform to another. >One had an SBC, one didn't. The one with SBC controller handled these NAT >problems without any tweaks, while the one without the SBC, sometimes needed >tweaking on customer CPE. > >Jim Gurol >California Telecom >www.californiatelecom.com<http://www.californiatelecom.com> > > >-----Original Message----- >From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] >On Behalf Of Darren Schreiber >Sent: Saturday, August 21, 2010 10:15 AM >To: VoiceOps at voiceops.org >Subject: [VoiceOps] "...but it works with Packet8" > >Hi folks, >We provide a fully redundant VoIP service to our customers where >they hook up two cheap Internet connections to our special little box and we >load-balance / failover across them. We have been running into periodic >issues with SIP ALG and such typical VoIP crippling technologies when >hooking up our equipment, requiring us to get into the client's router and >turn off SIP ALG (or Cisco "fix-up" features). Specifically we have issues >with 2Wire devices, which are very very popular. We've been assuming this is >standard/par-for-the-course behavior. > >We have a partner who is reselling our service and he has asked me >a few times why our service requires any tweaks at all. He is literally >replacing Packet8 phones with our service. We are utilizing the old Packet8 >phones so it is not a model and unlikely a firmware issue. Something we are >doing in our way of configuring these phones is fundamentally different then >Packet8. The reseller feels we should not have to mess with the clients >router. I'm starting to think he has a valid point. > >So, my question is, why does Packet8 work so well behind so many >firewalls? I don't think their Aastra firmware is all that different then >stock Aastra firmware. So my thoughts are: >- They might be using TCP signaling for SIP call setup instead of UDP? >- They might be ignoring the contents of SIP packets and rewrites and using >rather "aggressive" settings on the switch side to figure out routing based >solely on network headers (we use the actual SIP packets) >- They force rport? > >I'm just guessing at this point, but the reseller has a valid point >- we should be able to compete with this directly. > >Let me know your thoughts or if you have any advice on >best-practices for setting up Aastras (and other phones) to behave nicely >across firewalls that have SIP ALG *enabled*. Sorry if this is a lame or too >broad a question. Any tips & tricks you've used are helpful. > >Thanks much, > >Darren Schreiber >Co-Founder - VoIP, Inc. - (415) 886-7900 www.2600hz.org - Free VoIP Software >www.voipkb.com - FreeSWITCH Trainings > > >_______________________________________________ >VoiceOps mailing list >VoiceOps at voiceops.org >https://puck.nether.net/mailman/listinfo/voiceops > >

1 0

Crazy bouncy month
by bethjohnson5060＠gmail.com Aug. 20, 2010

Aug. 20, 2010

Hi Groupers, This has been a wild month over here. Our peer SBC has been lit up with alarms with bounces from this peer or that. We'll lose one gateway from a peer for a minute or so, then it'll come right back up. Sometimes the SIP bounce is accompanied with a BGP route flap, sometimes not. It almost always happens late at night, but a few sneak in during the day. We've got plenty of redundancy to cover the events, so ASR remains high. Part of our root-cause analysis is seeking an uderstanding of the experiences of similar networks, so I need to ask... Is anyone else seeing a general increase in internet-based peer bounces? -B

6 7