- VoiceOps - lists.voiceops.org

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

Aug. 23, 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

Crazy bouncy month
by jjackson＠aninetworks.net Aug. 20, 2010

Aug. 20, 2010

We use smokeping to display rtt and loss history and i use mtr quite a bit to monitor paths but ive heard from certain networks (level3) that mtr doesnt display the real path. -----Original Message----- From: David Hiers <hiersd at gmail.com> Sent: Friday, August 20, 2010 11:30 AM To: Beth Johnson <bethjohnson5060 at gmail.com> Cc: voiceops at voiceops.org <voiceops at voiceops.org> Subject: Re: [VoiceOps] Crazy bouncy month Come to think of it, I've been more annoyed in the past month or so... Anyone know of a tool that can maintain/display a traceroute-like history? Not all network problems cause bgp route updates, and would be nice to monitor traffic paths to peers for possible correlation of path changes to SIP events. David On Fri, Aug 20, 2010 at 6:50 AM, Beth Johnson <bethjohnson5060 at gmail.com> wrote: > 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 > > > _______________________________________________ > VoiceOps mailing list > VoiceOps at voiceops.org > https://puck.nether.net/mailman/listinfo/voiceops > > _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

2 1

Crazy bouncy month
by twolf＠voipnettechnologies.com Aug. 20, 2010

Aug. 20, 2010

We have a tool called pathview...shows paths,changes along way including tag changes Sent from my Windows? phone. -----Original Message----- From: Joseph Jackson <jjackson at aninetworks.net> Sent: Friday, August 20, 2010 1:28 PM To: David Hiers <hiersd at gmail.com>; Beth Johnson <bethjohnson5060 at gmail.com> Cc: voiceops at voiceops.org <voiceops at voiceops.org> Subject: Re: [VoiceOps] Crazy bouncy month We use smokeping to display rtt and loss history and i use mtr quite a bit to monitor paths but ive heard from certain networks (level3) that mtr doesnt display the real path. -----Original Message----- From: David Hiers <hiersd at gmail.com> Sent: Friday, August 20, 2010 11:30 AM To: Beth Johnson <bethjohnson5060 at gmail.com> Cc: voiceops at voiceops.org <voiceops at voiceops.org> Subject: Re: [VoiceOps] Crazy bouncy month Come to think of it, I've been more annoyed in the past month or so... Anyone know of a tool that can maintain/display a traceroute-like history? Not all network problems cause bgp route updates, and would be nice to monitor traffic paths to peers for possible correlation of path changes to SIP events. David On Fri, Aug 20, 2010 at 6:50 AM, Beth Johnson <bethjohnson5060 at gmail.com> wrote: > 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 > > > _______________________________________________ > VoiceOps mailing list > VoiceOps at voiceops.org > https://puck.nether.net/mailman/listinfo/voiceops > > _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

1 0

Ye ole Cisco Cube CM
by sil＠infiltrated.net Aug. 14, 2010

Aug. 14, 2010

Because I don't care what ya trunk to me with (Avaya, Nortel, Cisco, Asterisk, etc), I tend to care less about the "end" user's equipment as I'm sure many here have had to do from time to time. (Interops with Avaya one day, Nortel the next, intertwined with CCM here, Asterisk there). Anyhow, was doing an interop with someone and they CUCM was sending 491's. Figured I'd ask here since I believe someone must have a "oh yea... that stupid thing..." response. The scenario: Caller (Cisco Equipment) --> Their Network --> The Interweb --> My network --> so on... Caller --> My phone --> I pick up --> Their phone disconnects, immediate CANCEL 491 SIP? Caller --> CCM --> Router --> My SBC --> SIP/200 OK At that EXACT MOMENT of the SIP/200 OK: CCM sees SIP/481 : *Aug 10 20:38:45.295: //238407/000000000000/SIP/Call/sipSPICallInfo: Disconnect Cause (CC) : 16 Disconnect Cause (SIP) : 481 Anyone have a generic Cisco router config they'd care to share? I was fortunate enough to have them send me their end (implemented VoIP related garbage): voice call send-alert voice call carrier capacity active voice rtp send-recv voice service voip allow-connections sip to sip h323 sip bind control source-interface GigabitEthernet0/0.3 bind media source-interface GigabitEthernet0/0.3 voice class codec 1 codec preference 1 g729r8 codec preference 2 g711ulaw voice class h323 1 h225 timeout tcp establish 3 ccm-manager fallback-mgcp ccm-manager redundant-host xx.yy.z.15 ccm-manager mgcp ccm-manager music-on-hold ccm-manager config server xx.yy.z.16 ccm-manager config fax interface-type fax-mail interface GigabitEthernet0/0.3 description Voice VLAN encapsulation dot1Q 3 ip address xx.yy.z.1 255.255.255.0 ip helper-address vv.vv.v.v4 ip pim sparse-dense-mode ip cgmp no cdp enable dial-peer voice 9000 voip description ** Outbound 10-digit ** preference 1 destination-pattern 1[2-9]......... session protocol sipv2 session target ipv4:this.is.me.at.33 session transport udp fax-relay ecm disable no vad sip-ua call-manager-fallback max-conferences 8 ip source-address xx.yy.z.1 port 2000 max-ephones 48 max-dn 48 transfer-pattern 503....... default-destination 2000 voicemail xxxxxxxxxx SIP Messages: (ala ngrep ;)) U this.is.my.ip.33:5060 -> this.is.their.ip.131:5060 SIP/2.0 200 OK v: SIP/2.0/UDP this.is.their.ip.131:5060;branch=z9hG4bK1E3E f: "SIP Test DID"<sip:1503xxxyyyy at this.is.their.ip.131>;tag=2633AAF8-1A7C t: <sip:1212aaabbbb at this.is.my.ip.33>;tag=4483814b840cda0de9102ed591a599fc i: 15E4B9A3-A3F611DF-91EEFF90-66FF34BF at this.is.their.ip.131 CSeq: 101 INVITE m: <sip:+1212aaabbbb at this.is.my.ip.33:5060;transport=udp> c: application/sdp l: 111 v=0 o=- 58501 5850100 IN IP4 this.is.my.ip.38 s=- c=IN IP4 this.is.my.ip.38 t=0 0 m=audio 18168 RTP/AVP 0 18 U this.is.their.ip.131:57731 -> this.is.my.ip.33:5060 CANCEL sip:1212aaabbbb at this.is.my.ip.33:5060 SIP/2.0 Via: SIP/2.0/UDP this.is.their.ip.131:5060;branch=z9hG4bK1E3E From: "SIP Test DID" <sip:1503xxxyyyy at this.is.their.ip.131>;tag=2633AAF8-1A7C To: <sip:1212aaabbbb at this.is.my.ip.33>;tag=4483814b840cda0de9102ed591a599fc Date: Tue, 10 Aug 2010 20:38:36 GMT Call-ID: 15E4B9A3-A3F611DF-91EEFF90-66FF34BF at this.is.their.ip.131 CSeq: 101 CANCEL Max-Forwards: 70 Timestamp: 1281472724 Reason: Q.850;cause=16 Content-Length: 0.. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E

6 5

The peer of my peer is my peer?
by David_Hiers＠adp.com Aug. 10, 2010

Aug. 10, 2010

Every so often this issue comes up, and I want to get a read on it from other VOIP resellers... Consider a couple of unrelated VOIP resellers that peer with a carrier like L3. Both can interop with L3 using strict SIP and RTP settings (max forwards, g729 only, 10ms ptime, whatever). Both are free to select mutually incompatible settings. For instance, reseller A can chose 729 only, and reseller B can choose 711 only. L3 will connect both to the PSTN without any trouble. Everything is good until they try to call each other. Then the mutually incompatible settings will break calls or render predicted usage patterns invalid. Sure, you're still signaling to a L3 SIP server, but some the information in the SIP/SDP packets that you receive is controlled by the other reseller. How often do you see problems related to the peer of your peer? David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 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.

9 15

Valid number testing
by jared＠compuwizz.net Aug. 5, 2010

Aug. 5, 2010

Does anyone know of a service that I can send a full +1 number to and get a response as to if its an assigned number or not? I know I can test against the LERG, but I was hoping to test if its an active number or not. I figure this can be done with SS7, but that would be costly for me to setup and do. Anyone have any tips? ~Jared

5 7

Valid number testing
by abalashov＠evaristesys.com Aug. 5, 2010

Aug. 5, 2010

Paul's telcodata.us stuff certainly takes the trouble out of it, especially for the price. If you don't have in-house expertise in transforming large data sets in Perl, etc., probably the best way to go. -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ On Aug 5, 2010, at 12:24 PM, Paul Timmins <paul at timmins.net> wrote: > On 08/05/2010 11:57 AM, Naushit Sakarvadia wrote: >> >> Alex, >> >> This is great info I was looking for ,but I could not find a page >> where you can download all info in single page, you need to >> download for each State/Area Code combination. May be someone >> needs to write perl script :) to import everything in database . > > I sell this data for money at http://www.telcodata.us - It's not > very expensive and certainly easier than writing a script. :) > >> Plus , I was also looking for NPAC data , where I can find ported >> numbers out of the blocks. Anyone know of any good source? > > You can basically only get this from the NPAC or the LSMSs, and you > have to have an NPAC user agreement > > https://ncc.neustar.biz/ccs/ > > Anyone who has a user agreement (and thus has access to the data) is > required to verify you have one before allowing you access. > >> Is there anything I can barter for this data? Any tips? >> >> Thanks, >> Naush. >> >> >> >> >> From: Alex Balashov <abalashov at evaristesys.com> >> To: Jared Geiger <jared at compuwizz.net> >> Cc: "voiceops at voiceops.org" <voiceops at voiceops.org> >> Sent: Thu, August 5, 2010 11:26:10 AM >> Subject: Re: [VoiceOps] Valid number testing >> >> I would import list of assigned pooled blocks from Neustar/National >> Pooling (nationalpooling.org) into a database, then import a list >> of assigned NANPA 10,000 blocks from them (nanpa.com) and roll >> your own. That's all anyone else would be selling you anyway, more >> or less. >> >> -- >> Alex Balashov - Principal >> Evariste Systems LLC >> 1170 Peachtree Street >> 12th Floor, Suite 1200 >> Atlanta, GA 30309 >> Tel: +1-678-954-0670 >> Fax: +1-404-961-1892 >> Web: http://www.evaristesys.com/ >> >> On Aug 5, 2010, at 10:58 AM, Jared Geiger <jared at compuwizz.net> >> wrote: >> >> > Does anyone know of a service that I can send a full +1 number to >> and >> > get a response as to if its an assigned number or not? I know I can >> > test against the LERG, but I was hoping to test if its an active >> > number or not. >> > >> > I figure this can be done with SS7, but that would be costly for >> me to >> > setup and do. >> > >> > Anyone have any tips? >> > >> > ~Jared >> > _______________________________________________ >> > VoiceOps mailing list >> > VoiceOps at voiceops.org >> > https://puck.nether.net/mailman/listinfo/voiceops >> _______________________________________________ >> VoiceOps mailing list >> VoiceOps at voiceops.org >> https://puck.nether.net/mailman/listinfo/voiceops >> >> >> _______________________________________________ >> VoiceOps mailing list >> VoiceOps at voiceops.org >> https://puck.nether.net/mailman/listinfo/voiceops >> >

2 1