- VoiceOps - lists.voiceops.org

Odd network problem with SIP
by jra＠baylink.com June 24, 2014

June 24, 2014

----- Original Message ----- > From: "Frank Bulk" <frnkblk at iname.com> > Except, by definition, jitter is ping-response (latency) deviation. In > calculus terms, jitter is the derivative (change in rate) of latency. I was assuming that jitter had to do with the sliding of packets around WRT strict isochronous positioning -- specifically, packets arriving out of sequence, because they are so late. That's not what jitter means in VoIP? :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

3 4

Odd network problem with SIP
by jra＠baylink.com June 21, 2014

June 21, 2014

I have a client using the Spitfire dialler on Win7 to dial via SIP to a carrier called VoxTelecom; I infer they're a virtual carrier because the SIP goes to their Sonus SBC at a single IP, but the media sessions go all over creation. The client has been having completion trouble, and the dialler folks said "crappy circuit; too much jitter and packet loss", tested from the dialler using PingPlotter. I don't think it was jitter, I think it was ping response deviation; PingPlotter doesn't appear to actually test jitter. But to tick the boxes, I had road runner out; they replaced a ubee D2 modem with their New Hawtness Arris D3 modem; no change. All his analog measurements were pristine, he told me. So next step, check the router. Log in to the Fortigate 40D; control panel won't paint properly. This *may* have been an IE10 compatibility mode red-herring, but I temporarily swapped it for a 20C, which I could talk to. Set up the inbound DNATs for udp/5060 SIP and upd/49152-49252 RTP. Ran some calls. They're not seeing my ACK after they send me an SDP. They get the invite, but not the ACK. I send RTP, but they don't bother cause they think the call's not set up yet. Wireshark on the dialler... that ACK packet *has a bad IP header checksum*. Not the earlier packets; just the ACK. Huh? So, assume it's the OS, somehow; reboot. 65 Windows updates and an hour later... Set everything back up, and run more test calls. This time, the Invite has a bad IP header checksum. Look at clock, 6pm EDT. Give up, go home. I'm going to go back to the original router Monday morning, and check the compatibility mode theory, but has anyone ever seen "just certain sent packets show up with a bad IP header checksum, as monitored on-machine"? (I know that the original 40D router might well *have* a problem, and that the checksum thing is orthogonal to the original problem -- since older pcaps show clean setups -- but at least I can confirm I have the NATs configured right.) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

5 5

Asterisk Inconsistently sending RTP for deterministic set of orig DIDs
by beckman＠angryox.com June 19, 2014

June 19, 2014

I'm dealing with a strange situation and I'm hoping there might be someone who can see an easy answer. 1. When a call comes into Asterisk, we answer the call and send a SIP 200 OK. Then we play an audio clip, then bridge the call to a Dial() with the 'r' option to play ringing to the origination side of the call. This works with all of Carrier B's DIDs and most of Carrier A's DIDs. The RTP streams start sending as soon as we answer() the inbound call. 2. For other DIDs, we answer() and send a 200 OK and do not play any audio but bridge the call directly to a Dial(). The audio is still passed to the caller and they hear ringing generated from Asterisk, not locally. 3. For the problem DIDs we are working on right now, they all look like #2 but no audio is passed to the caller, and the RTP stream is not sent (based on tcpdumps). However when the Dial()ed call leg answers, the RTP stream begins (inconsistently, but that's another issue). Because this issue is happening with just a small subset of DIDs on one specific carrier of ours, and that we have made NO changes to our Asterisk configuration or our AGI that handles calls, and that the same AGI handles all inbound calls the same way, I'm looking for any troubleshooting advice I can find. This started very suddenly after several years of no issues three days ago. My Asterisk server has enough inodes, very few open files (no where close to ulimit levels), and no indication that there are any problems. There are no limitations on inbound or outbound ports for RTP (no firewall rules restricting that traffic). Reinvites are not enabled. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------

2 2

Adtran Help
by david＠ringfree.biz June 18, 2014

June 18, 2014

I have an adtran 912 that I'm seeing one way audio on origination calls (very intermittently). I'm exporting pcap's from the machine to a tftp server over the internet. But the 912 runs out of memory and pauses the pcap process and thus far I haven't been able to get a single decent pcap to show the carrier. I've been on with Adtran support and their answer is to put the tftp server closer to the adtran so that exports finish faster. I'm doing that and will have it done in the am. However I thought I'd ask if there's a magic process that anyone has found for getting good pcaps from these devices. They seem to work well, but troubleshooting is a bitch. You can even log the debug. You have to keep a damn terminal open and hit a key every 4 minutes to not disconnect. Thanks David -- -- www.ringfree.biz 828-575-0030

7 10

Canadian SIP Trunk Providers
by ciscoplumber＠gmail.com June 14, 2014

June 14, 2014

> > Hi Jeff > > Are you looking for a partner to originate Canadian TF and DID traffic or > LD term or both? > > Thanks > > Ivan > Looking to both originate and terminate. Thanks. On Fri, Jun 13, 2014 at 4:55 PM, Ivan Kovacevic < ivan.kovacevic at startelecom.ca> wrote: > Hi Jeff > > Are you looking for a partner to originate Canadian TF and DID traffic or > LD term or both? > > Thanks > > Ivan > On Jun 13, 2014 5:50 PM, "Jeff Anderson" <ciscoplumber at gmail.com> wrote: > >> I work for a service provider that sells SIP trunking services. We are >> looking at adding a Canadian SIP peering partner. >> >> Does anyone have a list of the major players in this space that would be >> a good place to start our research? >> >> Thanks, >> >> Jeff >> >> _______________________________________________ >> VoiceOps mailing list >> VoiceOps at voiceops.org >> https://puck.nether.net/mailman/listinfo/voiceops >> >>

1 0

Canadian SIP Trunk Providers
by ciscoplumber＠gmail.com June 13, 2014

June 13, 2014

I work for a service provider that sells SIP trunking services. We are looking at adding a Canadian SIP peering partner. Does anyone have a list of the major players in this space that would be a good place to start our research? Thanks, Jeff

3 2

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