- VoiceOps - lists.voiceops.org

SIP Compatible Door Phone
by tim.donahue＠gmail.com March 22, 2011

March 22, 2011

Hi all, We recently got a requirement from a client that needs a door phone that will work with the SIP PBX that we recently installed. I came across the product below for a SIP door phone from Valcom, but I can't find any documentation on Valcom's site. http://superphonestore.com/product_info.php?products_id=7279&cPath=364 Does anyone have good experiences with a door phone that works well with SIP PBX's, preferably with some decent documentation on the web and native SIP vs. using an FXS or FXO and connecting to an analog door phone. Thank you, Tim

5 4

PRI loss/level settings - DTMF issues
by jay＠west.net March 18, 2011

March 18, 2011

On 3/18/11 3:35 PM, Tim Donahue wrote: > Jay, > > We have seen this with the Adtran TA900 series boxes before. Have you > checked that the lbo parameter is set appropriately in the t1 interface > settings? This fixed has fixed echo problems for us in the past. I think we're talking apples and oranges here. LBO controls the level of the digital T1 signal itself. Problems here will show up as CRC or other T-1 errors. The characteristics of the TDM audio encoded in the T-1 in terms of echo, DTMF, etc. are not going to be affected by LBO at all. As long as the T-1 receiver sees the 1.544 Mbits/s stream of ones and zeros, the dB level of the T1 bitstream won't have any effect on level of the u-law DTMF or voice encoded therein. Within the Adtran for FXS lines, and within the Shoretel for the PRI B-channels, there is a configurable level setting for transmit and receive. This is an adjustment in the form of a digital pad or volume control that adjusts the DSP going from the analog to the digital realm and will affect the volume of the signal heard at the earpiece or sent from the mouthpiece. For example, a milliwatt test tone will be measured at the same level at the other end regardless of LBO on the T-1 but will be affected by the configurable gain settings on the FXS or PRI. >From my old Bell-head days, there were standards in the form of a "Loss and level plan" for PBXs connecting to the network to ensure that voice levels are audible and don't result in blasting or "singing". I seem to recall that customer PBXs are recommended for -6 to the network and -3 from the network but can't locate that spec. (This is way different from the -16 and +7 from 0 TLP carrier levels for those of us who have been around for a while...) The Shoretel is currently at +/-0 dB in both directions, and the other party reports that the voice coming from the Shoretel seems noticeably loud. I'm of the opinion to just set it to -6 and -3 and see what happens but was hoping for some verification from the community that this is a reasonable approach. > Other than that, the only reliable solution we have found when these > sort of problems crop up is installing a more configurable box, such as > the Audiocodes Mediant 1000. More expensive, definitely, but we have > replaced 3 or 4 Adtrans that were having problems ranging from echo, to > DTMF not registering properly or duplicating digits, that were deployed > at client sites and the Audiocodes has always been able to fix the > problems they were having. If the main difference is the ability to tweak the levels, we have that in the Shoretel itself. > If you do happen find a solution for controlling the levels on the > Adtran T1 interfaces, I'd love to know what it is. I have contacted > Adtran's support a few times about it and I haven't gotten any > confirmation about if it is possible out of them yet. T-1 signal levels, use LBO. Voice gain from handsets to the T-1 is adjustable on the FXS/FXO interface config. Voice gain to a CAS/PRI, to the best of my knowledge, isn't settable on a TA900. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV

1 0

PRI loss/level settings - DTMF issues
by jay＠west.net March 18, 2011

March 18, 2011

We are having some issues with doubled DTMF digits from a customer dialing into conference bridges, etc. Scenario: Shoretel PBX -> PRI -> Adtran TA900 -> SIP trunk. We are using G711/RFC2833. The problem is intermittent, about 5% of calls or less, read-back of received digits shows occasional doubled digits, almost always DTMF "1". We were able to duplicate the issue with the Shoretel system going out a conventional TDM PRI as well, but the customer and the conferencing vendor and the customer tend to blame the problem on "the VoIP system". It is very intermittent and DTMF works fine most of the time. The Shoretel itself sends only a short burst out the PRI regardless of the length of time the DTMF key is held. Comments from voice users on the receiving end are that the Shoretel caller's voice seems "hot". The Adtran has settings to adjust level on FXS but not on PRI. The Shoretel does have adjustments, presently set to 0 dB. It is my recollection from the old Bell/Mitel days that there should be padding on T1/PRI trunks but I can't find a spec. From memory I want to say -6 transmit and -3 receive but Google is failing me on finding this documented. Is there a standard loss/level best practice for this? The fact that the issue occasionally occurs on the TDM trunks leads me to think that the SIP RFC2833 conversion is not to blame and that perhaps there is acoustic coupling between the tone played out the phone's speaker being picked up by the microphone that padding would help. Any suggestions would be appreciated. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV

2 3

(no subject)
by mwiles＠akabis.com March 18, 2011

March 18, 2011

Does anyone have experience with VoIP Innovations (www.voipinnovations.com)? Thanks! Mark

5 4

SMS Provider
by abarratt＠socket.net March 17, 2011

March 17, 2011

This is a little off-subject, but thought that because of the underlying SS7 it would qualify. :-D Wondering if anyone out there is purchasing SMS access from a "clearinghouse" such as Sybase or Syniverse/Verisign? Any recommendations? We're looking to develop a paging service for schools, governments, etc. We'd like it to be a Full Long-Code (10 Digit) from our existing number resources... may also have interest in Short-Code (5-6 Digit) SMS for commercial use. Another option would be leasing the services from say Sprint or Verizon as an MVNO -- but don't know if we're ready to go down the road of being a cellular reseller (yet). The Email Gateway is an option, albeit a messy one, as you have to keep track of who's network the end-user's cellphone is on, which could probably be done via an LNP DIP, but we'd rather interface directly to the SMS network. Two way would be pretty bad using this as well. -- Adam E Barratt Sales Engineer SOCKET (573) 817-0000 abarratt at socket.net 1-800-SOCKET-3 www.socket.net ********************************************************************** Privacy Notice: The information in this message is confidential and may be legally privileged. It is intended for use only by the individual or entity to which it is addressed. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. If you have received this e-mail in error please notify the sender immediately and delete it from your system without copying or forwarding. **********************************************************************

4 3

VoIP Abuse Take Two (or three, maybe even 4-5)
by sil＠infiltrated.net March 17, 2011

March 17, 2011

For those looking for a different type of blacklist or at least one that makes sense, please be sure to browse the VoIP Abuse Black List as things are a slightly different now. VABL looks up an attacker's information via Shadowserver's lookup and appends three new fields: type of attacker, address and the letters VABL (so one can know where and how it ended up on being blacklisted) and a number dialed (when appropriate.) The type of attacker field may make the biggest difference to those who decide to use this list. There are two specific entries that will appear: BRU, ADN and COM. BRU means that the host attempted to bruteforce a PBX while COM signifies that the attacker managed to compromise either a honeypot or a live machine. ADN is when an attacker places a call and is short for Attacker Dialing Numbers. Whenever you see an entry with ADN, there will be an additional field at the end with the number dialed by the attacker appended to it. Here are three entries, a COM (someone who accessed a honeypot with a valid account), a bruteforcer and an ADN (an attacker who accessed a compromised account and tried to place a call the number dialed is pre-pended) 85.214.23.191 | COM | VABL | 6724 | 85.214.0.0/16 | STRATO | DE | STRATOSERVER.NET | STRATO RECHENZENTRUM BERLIN 41.232.96.220 | ADN | VABL | 8452 | 41.232.96.0/22 | TE | EG | TEDATA.NET | AFRINIC | 011251912121891 93.126.35.12 | BRU | VABL | 44375 | 93.126.0.0/18 | AISDP | IR | - | ASMANFARAZ SEPAHAN ISDP Anyhow, the list is maintained as a text file and is updated accordingly (once per day depending on my schedule). VABL explained: http://www.infiltrated.net/index.php?option=com_content&view=article&id=17&… VABL list http://www.infiltrated.net/vabl.txt Potential scripting... wget -qO - infiltrated.net/vabl.txt|\ grep [0-9] | awk '{print "insert your favorite firewall rule against this whole netblock "$9}' wget -qO - infiltrated.net/vabl.txt|\ grep [0-9] | awk '{print "insert your favorite firewall rule against this one host "$9}' Depending on one's POV, COM and ADNs are the ones to keep an eye one. These are actually making connections as opposed to checking if a door is opened. I know I've stated it before, typically I see this: bruteforce --> fire off sipvicious looking for an account attacker --> logs into an account (this IP is RARELY if ever in any bruteforce logs) What I find sort of funny is that today I see an attacker I guess doing research: (attacker trying to make a call to 0112522200044) 41.34.68.219 | ADN | VABL | 8452 | 41.32.0.0/12 | TE | EG | - | TE DATA | 0112522200044 Attacker researching I guess asterisk + voip + security or so $ awk '/host-41.34.68.219.tedata.net/{print $1,$4,$5,$6,$7,$8,$9,$11}' access_log | head -n 1 host-41.34.68.219.tedata.net [17/Jan/2011:13:50:46 -0600] "GET /asterisk-ips.html HTTP/1.1" 200 "http://voipsecurityblog.typepad.com/marks_voip_security_blog/2009/07/a-scri…" -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 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

3 2

Verizon and E.164
by CCurry＠telovations.com March 17, 2011

March 17, 2011

Thanks Paul and Scott. I am not a SS7 guru by no means and the NOA may help. I need to do a trace to see what I am sending to verizon to insure I am sending NOA of national. ________________________________________ From: voiceops-bounces at voiceops.org [voiceops-bounces at voiceops.org] On Behalf Of voiceops-request at voiceops.org [voiceops-request at voiceops.org] Sent: Wednesday, March 16, 2011 4:50 PM To: voiceops at voiceops.org Subject: VoiceOps Digest, Vol 21, Issue 11 Send VoiceOps mailing list submissions to voiceops at voiceops.org To subscribe or unsubscribe via the World Wide Web, visit https://puck.nether.net/mailman/listinfo/voiceops or, via email, send a message with subject or body 'help' to voiceops-request at voiceops.org You can reach the person managing the list at voiceops-owner at voiceops.org When replying, please edit your Subject line so it is more specific than "Re: Contents of VoiceOps digest..." Today's Topics: 1. (no subject) (Mark Wiles) 2. Re: Verizon and E.164 (Paul Timmins) ---------------------------------------------------------------------- Message: 1 Date: Wed, 16 Mar 2011 16:38:50 -0400 From: "Mark Wiles" <mwiles at akabis.com> To: <voiceops at voiceops.org> Subject: [VoiceOps] (no subject) Message-ID: <033201cbe41a$29064330$7b12c990$@com> Content-Type: text/plain; charset="us-ascii" Does anyone have experience with VoIP Innovations (www.voipinnovations.com)? Thanks! Mark

1 0

Verizon and E.164
by l_mysterioso＠yahoo.com March 16, 2011

March 16, 2011

What type of product are you using for SS7 to/from SIP translation? There is a good chance that your SS7 to SIP translation device may have the ability to manipulate ANI and DNIS as required. In the application we use on our net the M3UA server manages E.164 vs 10 Digit National decisions quite well. Also, do you plan to use this SS7 route for any international termination? If not, it might be as simple as limiting all calls over that trunk group to 10 digit ANI/DNIS outbound then prefix a (+)1 on the inbound. Thanks, Spencer *From:* voiceops-bounces at voiceops.org > [mailto:voiceops-bounces at voiceops.org] *On Behalf Of *Chet Curry > *Sent:* Wednesday, March 16, 2011 12:58 PM > *To:* voiceops at voiceops.org > *Subject:* [VoiceOps] Verizon and E.164 > > Many carriers request that you send sip messaging using E.164 > compliant #'s. We have a TDM/SS7 peering to Verizon and we tried > sending calls to them with the "Calling" # in E.164 format. > > Unfortunately they see the call as International because there is a 1 > prepending the 10 digit #. This makes no sense to me as international > starts as 011. Has anyone had this issue with Verizon or any other > carrier?

1 0

Verizon and E.164
by CCurry＠telovations.com March 16, 2011

March 16, 2011

Many carriers request that you send sip messaging using E.164 compliant #'s. We have a TDM/SS7 peering to Verizon and we tried sending calls to them with the "Calling" # in E.164 format. Unfortunately they see the call as International because there is a 1 prepending the 10 digit #. This makes no sense to me as international starts as 011. Has anyone had this issue with Verizon or any other carrier? [cid:image001.png at 01CBE3D9.54AE5270]

3 2

Verizon and E.164
by CCurry＠telovations.com March 16, 2011

March 16, 2011

This is SS7 so there is no SBC in the mix. We have a path to fix it yet my concern is they are not accepting E.164 properly and was curious how many other SS7 peers have this same issue From: Alihan Arica [mailto:alihanarica at yahoo.com] Sent: Wednesday, March 16, 2011 3:34 PM To: Chet Curry Subject: Re: [VoiceOps] Verizon and E.164 Hi Chet, I believe that you can ask them to strip off the preceeding 1 and/or +1 from the incoming INVITE request on their Session Border Controller; I am pretty sure that your signal first hits their Session Border Controller and these boxes have such ability. Sorry, I can not provide further more information since I don't like to commend any architecture that I did not work on before. Hope this helps! ________________________________ Alihan Arica Overland Park, KC, USA --- On Wed, 3/16/11, Chet Curry <CCurry at telovations.com<mailto:CCurry at telovations.com>> wrote: From: Chet Curry <CCurry at telovations.com<mailto:CCurry at telovations.com>> Subject: [VoiceOps] Verizon and E.164 To: "voiceops at voiceops.org<mailto:voiceops at voiceops.org>" <voiceops at voiceops.org<mailto:voiceops at voiceops.org>> Date: Wednesday, March 16, 2011, 11:57 AM Many carriers request that you send sip messaging using E.164 compliant #?s. We have a TDM/SS7 peering to Verizon and we tried sending calls to them with the ?Calling? # in E.164 format. Unfortunately they see the call as International because there is a 1 prepending the 10 digit #. This makes no sense to me as international starts as 011. Has anyone had this issue with Verizon or any other carrier? [cid:image001.png at 01CBE3F5.53C652B0] -----Inline Attachment Follows----- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<http://us.mc393.mail.yahoo.com/mc/compose?to=VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops

1 0