- VoiceOps - lists.voiceops.org

Call established before audio path
by nick＠flhsi.com June 13, 2014

June 13, 2014

+1 I saw this on incoming calls to an IVR off the PSTN. If I immediately started playing media, The caller wouldn't get the first little bit. Our fix for this was inserting a 1 second wait after answering the channel. Prior to playing the IVR message. Never seen this on an outbound call. Or inbound to a human. Generally, The human element inserts this same 1 second wait as they lift the receiver. Put it to their ear..Say hello...etc. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Eric Wieling" <EWieling at nyigc.com> Sent: Friday, June 13, 2014 1:08 PM To: "Brian Taylor" <briant at socket.net>, "voiceops at voiceops.org" <voiceops at voiceops.org> Subject: Re: [VoiceOps] Call established before audio path In my experience allow reinvites / directmedia, etc will cause a short delay in setting up audio. -----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Brian Taylor Sent: Friday, June 13, 2014 12:07 PM To: voiceops at voiceops.org Subject: [VoiceOps] Call established before audio path We have customers who are reporting that when people call into them that the beginning of the greeting is not being heard. It appears that the phones think the call is ready before there is a complete audio path. We see this the most on calls that come in from the PSTN. Long distance or toll free calls are the worst. We have a Broadworks system that uses Lucent 5010 (Telica) switches for the connections to the PSTN. The symptom seems to be very similar for all of our PSTN connections, to multiple carriers. I'm just curious if anyone has any experience with this problem, or if anyone has any suggestions to get to the bottom of the issue. Any assistance or inspiration would be greatly appreciated. Thank you, Brian Taylor Socket Telecom, LLC brian at socket.net _______________________________________________ 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

Quality: Required. QoS: Never.
by lindsey＠e-c-group.com June 12, 2014

June 12, 2014

(Notes below from the SIPNOC 2014 BOF on VoIP quality over the public Internet.) 1. Introduction Customers want quality voice and video. This can be readily provided using engineered links -- i.e., paths that prioritize, reserve, or otherwise guarantee that the real-time voice and video packets will be delivered within the required timing constraints. But because of the wonderful cost reductions of Internet bandwidth, customers would prefer to get the quality voice and video services across the Internet, and not be forced to buy a special link to get that quality. At SIP Forum's SIPNOC 2014, we held a BoF "Birds of a Feather" session and Google Hangout to discuss ways to make Voice and Video via the Internet have better quality. We also had a conversation on the VoiceOps mailing list about this subject. The notes below reflect the comments made by folks in both fora. Editor: Mark R Lindsey, SMTS with ECG, lindsey at e-c-group.com, tel:+12293160013 http://ecg.co/lindsey 2. Terminology "Customer" refers to the customer of the ITSP. "CPE" (Customer Premise Equipment) refers to equipment installed a customer's site. In the context of this discussion, all CPE is for use exclusively by the Customer at whose site it is hosted. "ISP" refers to Internet Service Providers. In this context, both the ITSP and the Customer purchase service from an ISP to connect to the Internet and thereby communicate with one another over the Internet. "ITSP" refers to an "Internet Telephony Service Provider"; but in general it's any provider of Real Time, Interactive, N-way (N>1), Human media sessions. "OTT" (Over the Top) and "BYOB" (Bring Your Own Broadband) refer to a method of delivering servie where connection between the ITSP and the Customer is done over the public Internet, as opposed to a link where guarantees of performance are provided. 3. Miscellaneous Observations 3.1. Some methods of improving the media experience across the Internet are going to be more expensive than others. Some are thus going to be most applicable to larger customer sites, while others can be efficiently applied even to individual users/customers. 3.2. One major OTT/BYOB carrier reported seeing that some major companies (apparently ISPs) appears to be de-prioritizing VoIP traffic, making it work worse than typical IP traffic. 4. Detection methods 4.1. Individual Calls 4.1.1. RTCP or RTCP-XR received from individual calls 4.1.2. Monitoring of packets via a box in the middle (e.g., ITSP Border Element / SBC, or CPE edge device) 4.1.3. RTCP Extended data sent via SIP 4.2. Customer Sites 4.2.1. ICMP ping of customer all sites to detect which customer sites are having problems (and by extension, which customers' ISPs are having problems). 4.2.2. Test calls to the customer site, e.g., to a loopback function 5. Quality Improvement Techniques 5.1. Involving multiple ISPs 5.1.1. Multiple ISPs or IP Peering Points at ITSP 5.1.1.1. Maximum number to increase number of options to reach customers. 5.1.1.2. Ability to manually tune routing to an ITSP customer that has a static public IP address, to avoid a particular ISP that is having problems. Example: End customer is on ISP 3. ITPS uses ISP 3 and ISP 3. Dispute or routing problem between ISP 3 and ISP 1 causes poor performance. So ITSP changes routing so that traffic destined to customer always exits ITSP network via ISP 2. 5.1.1.3. Advertise smaller blocks of IP space with BGP path preferences to control how customers' traffic enters the network; i.e., try to groom all VoIP traffic to enter on the ITSP's via the better ISP du jour. 5.1.1.4. On the ITSP border elements (e.g., SBC) assign different IP addresses that route in exclusively via a single ISP. E.g., SBC has customer-facing IP 1 that is only advertised via ISP 1, and a separate customer-facing IP 2 that is advertised only via ISP 2. Then configure Customer A SIP CPE to REGISTER via either IP 1, with SRV failover to IP 4. Then for Customer B, it may be better for them to register via IP 2 with failover to IP 1. 5.1.2. Multiple ISPs at Customer Premise. Use one ISP as a preferred option at the customer premise, then failover to another if the first one is too degraded as measured by SLA monitoring in the CPE router. 5.2. Codecs 5.2.1. Traditional codecs 5.2.2.1. G.729 instead of G.722 or G.711, simply to reduce the bandwidth required. 5.2.2. Adaptive Codecs 5.2.2.1. AMR / AMR-WB. Popular with vendors to implement, but relatively expensive because of Intellectual Property Fees. 5.2.2.2. Opus. Generally considered equal or superior to AMR-WB, but newer and thought to be considered immature by vendors. 5.2.3. Media Transport tricks. 5.2.3.1. Packetization Time (ptime) changes. It *might* be possible to reduce packet loss by reducing the packets/second rate of a media stream, but any reduction in packet loss will bring a proportionate increase in payload delivery. Much of the equipment in use won't support ptime != 20 ms. 5.2.3.2. Media over TCP. WebRTC includes Media over TCP. There are studies showing that media over TCP, e.g., in TCP-based VPNs, improve something. But this probably means that jitter buffers are maximized. The group's outspoken views are that that using today's codecs over TCP is likely to make delay much worse. [http://www.voip-info.org/wiki/view/VOIP+and+VPN] claims that a study by Sirrix (a German security firm) reported no ill effects of VPNs on VoIP, but the study is no longer online. 5.3. Changing call path mid-call. Detect the problem (e.g., via RTCP) then re-INVITE to change the media flow to another IP address that uses a different routing path from the customer. 5.4. Customer Premise Equipment 5.4.1. Use a device at Customer Premise that can prioritize Voice traffic as it exits the VoIP CPE going toward PE router. This can be done with an application-aware device (SIP ALG) or via DSCP marking and prioritization. 5.4.1. Use a device at Customer Premise that can manage the PE-to-CE (ITSP to CPE) TCP flows to ensure that TCP flows slow down enough to allow the RTP flows. This likely requires an ALG, or, at least, a device that can recognize the distinct RTP flows that it is trying to protect. 5.5. Traditional QoS 5.5.1. Use QoS prioritization in the core of the network. 5.5.2. Use QoS prioritization at the customer premise, even though the link between ITSP and Customer is not protected. And use a QoS policy at the customer premise that matches what's in use in the core. 5.5.3. Strip DSCP markings as packets arrive from untrusted networks, i.e., ISPs and customer sites outside your control. 5.6. Miscellaneous Recommendations. 5.6.1. Avoid messing with the media as much as possible; in particular minimize codec conversions. 5.6.2. Stay on the same network end-to-end, whenever possible. E.g., if you have customers that connect to you using Comcast at their customer premise, then try to connect the ITSP border element to Comcast. 6. Contributors Alex Balashov, Everiste Systems Chris Boyd, Gizmo Partners Chris Brown, ACS Alaska Frank Bulk, Premier Communications Ryan Delgrosso Jim Gast, TDS Telecom Gavin Henry, Suretec Jesse Howard, Shoretel Faisal Imtiaz, Snappy Telecom Eric Jastak Brandon Lehmann, BitRadius Mark R Lindsey, ECG Anthony Orlando Gernot Scheichl, Edgewater Networks Dan York Other anonymous participants in the SIPNOC BoF Session, June 11, 2014. Other anonymous participants in the VoiceOps discussion, June, 2014

1 0

FW: [Sipnoc14-attendees] Quality Voice on QoS-Free Internet / OTT / BYOB? 6:00pm US/Eastern
by eckelcu＠cisco.com June 12, 2014

June 12, 2014

Resending now that I have subscribed the list. On 6/11/14, 8:52 PM, "Charles Eckel (eckelcu)" <eckelcu at cisco.com> wrote: >Hi Mark, > >Thanks for arranging the BOF and leading the discussion. I found it >insightful and in some cases quite enlightening. Please do share the link >to the paper you mentioned on VPNs. >Those interested in the challenges around identifying and prioritizing >traffic, particularly when it is encrypted, may be interested in the >following draft: >http://tools.ietf.org/html/draft-conet-aeon-problem-statement-00 > >It focus on the problem space without offering a solution. I have some >thoughts on solutions. Our discussion on inspecting STUN packets and >pulling info from them is one such idea. >I?m happy to discuss in more detail. I will be around tomorrow, or you can >shoot me an e-mail anytime. > >Cheers, >Charles > >On 6/11/14, 10:21 AM, "Mark R Lindsey" <lindsey at e-c-group.com> wrote: > >>v=0 >>o=lindsey 1402495442 1 in IP4 216.128.202.68 >>s=SIPNOC BOF >>i=BOF Meeting on maximizing voice quality over QoS Free Internet. Google >>Hangout at URI below. >>u=http://ecg.co/sipnoc2014 >>e=lindsey at e-c-group.com (Mark Lindsey) >>p=+1 229 316 0013 >>t=3611498400 3611502000 >>c=IP IP4 127.0.0.1 >> >>How do you maximize voice quality via the Internet? Help us figure it >>out. >> >>We'd all rather do Voice and Video across QoS-Engineered networks. But >>what happens when we have to support customers over the Internet? >> >>The VoiceOps crowd (http://www.voiceops.org) gave us tons of great ideas >>to start this discussion. Join the BOF Meeting tonight online or in >>person, and help us find the best. >> >> TIME: 6:00pm-7:00pm US/Eastern June 11, 2014 >> >> IN PERSON: SIPNOC 2014, Hyatt Dulles >> >> ONLINE: Google Hangout link here: http://ecg.co/sipnoc2014 >> >> >> >> >>>>> mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey >> >> >>_______________________________________________ >>sipnoc14-attendees mailing list >>sipnoc14-attendees at sipforum.org >>http://sipforum.org/mailman/listinfo/sipnoc14-attendees >

1 0

CVE-2014-3427 CRLF Injection and CVE-2014-3428 XSS Injection in Yealink VoIP Phones
by joquendo＠e-fensive.net June 12, 2014

June 12, 2014

I. ADVISORY CVE-2014-3427 CRLF Injection in Yealink VoIP Phones CVE-2014-3428 XSS vulnerabilities in Yealink VoIP Phones Date published: 06/12/2014 Vendor Contacted: 05/08/2014 II. BACKGROUND Yealink is a manufacturer of VoIP and Video products. To minimize noise read more at: http://www.yealink.com/Companyprofile.aspx III. DESCRIPTION There are CRLF Injection and XSS vulnerabilities in Yealink VoIP telephones. Validated on Firmware Version 28.72.0.2 Hardware Version 28.2.0.128.0.0.0 CRLF Injection (Header Splitting) proof of concept: Request GET /servlet?linepage=1&model=%0d%0a%20 ANYTHING I WANT GOES HERE &p=dsskey&q=load HTTP/1.1 In the above request, attackers can shove in code, webpages, etc. In my tests, I have used javascript, redirects, and even an entire web page shoved into the CRLF vulnerable inputs. ----- The XSS vulnerability GET /servlet?jumpto=dsskey&model=%22%20onmouseover%3dprompt%28 1337 %29%20badpuppy%3d%22&p=login&q=loginForm HTTP/1.1 Typical Cross Site Scripting. IV. SOLUTION Minimize accessibility to the phone's interface. V. VENDOR CONTACT AND RESPONSE 05/08/2014 E-mailed security at yealink.com (bounced) 05/08/2014 Created an account on Yealink's forum and sent message (no response for weeks) 05/26/2014 Response via e-mail from Yealink 05/26/2014 Replied to vendor I would disclose in June 06/01/2014 Reached back out to vendor for update 06/08/2014 Reached back out to vendor for update 06/11/2014 Rouched out one last time... Crickets 06/12/2014 Advisory VI. TOOLS USED Burpsuite, WVS, Firefox -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF

1 0

Pacwest Issues
by LRiemer＠bestline.net June 11, 2014

June 11, 2014

We've had complaints from customers this morning where they get multiple calls around the same time with no audio from the same number. After comparing the call records for different customers, they all lead to Pacwest. Anyone seeing similar issues? It's like the calls are being retried from Pacwest but appear as separate new calls to us. Seen multiples of 3 to 5 calls. Started around 8:30-9am central. Thanks, Lee

2 1

Quality Voice on QoS-Free Internet / OTT / BYOB? 6:00pm US/Eastern
by lindsey＠e-c-group.com June 11, 2014

June 11, 2014

v=0 o=lindsey 1402495442 1 in IP4 216.128.202.68 s=SIPNOC BOF i=BOF Meeting on maximizing voice quality over QoS Free Internet. Google Hangout at URI below. u=http://ecg.co/sipnoc2014 e=lindsey at e-c-group.com (Mark Lindsey) p=+1 229 316 0013 t=3611498400 3611502000 c=IP IP4 127.0.0.1 How do you maximize voice quality via the Internet? Help us figure it out. We'd all rather do Voice and Video across QoS-Engineered networks. But what happens when we have to support customers over the Internet? The VoiceOps crowd (http://www.voiceops.org) gave us tons of great ideas to start this discussion. Join the BOF Meeting tonight online or in person, and help us find the best. TIME: 6:00pm-7:00pm US/Eastern June 11, 2014 IN PERSON: SIPNOC 2014, Hyatt Dulles ONLINE: Google Hangout link here: http://ecg.co/sipnoc2014 >>> mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey

1 0

High Quality, Reliable Voice via the Internet / SIPNOC
by lindsey＠e-c-group.com June 10, 2014

June 10, 2014

At SIPNOC this week, we're having a "Birds of a Feather" session on delivering quality voice services across the public Internet. A few techniques to make voice across the Internet better: 1. For packets from the ITSP to the customer: override the default BGP routing to choose an alternate route 2. Increase the ptime from 20 ms to 30-40 ms to reduce packet-drop exposure 3. EdgeWater brings us this one: actively manage TCP streams from Internet to CPE to provide better quality for Voice. So what OTHER techniques are there? Which techniques don't work? Yeah, it's the Internet. It's going to have failures. You're going to have bad days. But surely there are ways to improve the odds. >>> mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey

13 17

Test Emal.
by faisal＠snappytelecom.net June 9, 2014

June 9, 2014

Test...Test.. Please ignore. Thanks. Faisal Imtiaz

1 0

unsubscribe
by keith＠gogreencloud.com June 9, 2014

June 9, 2014

1 0

Pacwest down for anyone else?
by carlos＠race.com June 8, 2014

June 8, 2014

is pacwest down for anyone else???

6 7