August 2010 - VoiceOps - lists.voiceops.org

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

Bandwidth.com - 503 Concurrency Limit Reached
by gmina＠connectfirst.com Aug. 4, 2010

Aug. 4, 2010

Anyone else seeing Bandwidth.com starting to return "503 Concurrency Limit Reached" from their upstream carriers? Started about 2 hours ago and appears to be getting worse.

1 0

RTP Delay issue with Level 3 Viper and Asterisk based devices
by ujjval＠simplesignal.com Aug. 3, 2010

Aug. 3, 2010

On Viper we have noticed customers using Asterisk based PBX sometimes have a delay of about 4-8 secs before the Customer actually hears the calling party once they answer the call. In the past we have moved a bunch of TNs over to Level 3 Vector to resolve the issue. Anyone aware of these issues and what causes them. I am assuming some RTP SSRC, timestamp, Seq number issue. But I have a trace on which everything seems OK, but no audio for first 5 secs.... Appreciate your thoughts/feedback on this.

1 0

Bad/not unique SIP Call-ID GUIDs
by abalashov＠evaristesys.com Aug. 3, 2010

Aug. 3, 2010

Hi everyone, Am I the only one to run into an unusually high share of duplicate Call-IDs? A SIP Call-ID is supposed to be a GUID (Globally Unique Identifier), and RFC 3261 is quite clear on just how unique it needs to be. From 8.1.1.4: In a new request created by a UAC outside of any dialog, the Call-ID header field MUST be selected by the UAC as a globally unique identifier over space and time unless overridden by method-specific behavior. All SIP UAs must have a means to guarantee that the Call-ID header fields they produce will not be inadvertently generated by any other UA. [...] Use of cryptographically random identifiers (RFC 1750 [12]) in the generation of Call-IDs is RECOMMENDED. Implementations MAY use the form "localid at host". Call-IDs are case-sensitive and are simply compared byte-by-byte. Using cryptographically random identifiers provides some protection against session hijacking and reduces the likelihood of unintentional Call-ID collisions. In theory, this means that no other SIP message series initiated by any other UA anywhere, ever should have that same identifier. In practice, that's a pretty tall order to absolutely logically guarantee by algorithmic means. However, it's certainly possible to get pretty close, from a probabilistic perspective. The use of a highly effective cryptographic digest function coupled with time and/or RTC-seeded pseudorandom values coupled with some sort of host-specific values should result, in the form of a composite, in a very unique value. It is with this understanding in mind that pretty much all CDRs in our least cost routing and other SIP service delivery solutions are keyed off of the Call-ID. The Call-ID is the search key on our CDR tables, and for a variety of logical and performance reasons has a unique constraint on the index. Call-IDs are also used in any situation requiring the organisation of calls into a single-key hash or tree structure of some description. We use them because they're the only "unique" element that conveniently persists across all SIP messages that we would want to logically group together, irrespectively of whether the message is a request, a reply, whether it's an initial or an in-dialog request, etc. They're easy to extract from the message body, and just about anything that operates on SIP messages at a relatively low level exposes some interface by which one can extract the Call-ID. Anything else would rely on implementing an additional, uniform composite hash function of some kind in many different, unrelated software components that all utilise the same database backing, IPC, etc. That's what they're supposed to be used for. Call-IDs are GUIDs, and GUIDs make great keys. Long story short, the problem I've been running into recently is that a surprisingly high number of CDRs generated by certain customers using our solutions are bounced by the database because of Call-ID collisions. I think the quotation from the scrolls above quite clearly spells out that this is singularly the fault of the UACs involved, and while I won't name any names publicly, there are certainly some vendors in particular on whom I have my eye. Nevertheless, it is presenting an accounting problem for us and some of our ITSP customers. I'd be curious to know if anyone else has run into it, and what solutions you may have adopted to deal with it. Thanks! -- 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/

3 4