- VoiceOps - lists.voiceops.org

Verizon Business inbound SIP issues?
by compuwizz＠gmail.com Nov. 3, 2010

Nov. 3, 2010

Is anyone seeing problems with VZB's inbound DIDs? We're getting about 1 out of every 6 calls failing with a message "This number has been disconnected". It started yesterday and is ongoing today. We opened a ticket but haven't heard back yet. ~Jared

3 4

Question about Packet Jitter
by David_Hiers＠adp.com Nov. 2, 2010

Nov. 2, 2010

Before you get down into the weeds with the math... All the ITU docs that I've read portray the "network" as set of "non-rtp-aware, forward-as-fast-as-you-can router-type-things that probably have some qos capability". The "edge" is implicitly defined as the first occurrence of a jitter buffer. As near as I can tell, there are no rtp jitter buffers in an ITU "network" for which all this fancy math applies. If you transcode, scrub media with a ditech pvp, or otherwise implement anything that knows it should generate an rtp stream by sending a packet every X milliseconds, the ITU math is bounded by that device. If the SBC in your example transcodes or has a jitter/loss-concealment buffer, it *is* the edge, and you cannot average the link jitters as described in the ITU docs. 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 -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Jim Dalton Sent: Friday, October 29, 2010 6:43 AM To: 'Schwarz, Albrecht (Albrecht)'; voiceops at voiceops.org Subject: Re: [VoiceOps] Question about Packet Jitter > VoIP performance experts should be familiar with > > - ITU-T Y.1541 concerning IPDV (IP packet delay variation = jitter); > there are many sections on IPDV, particularily also on "aggregated > PDV"; > [JD wrote:] ITU-T Y.1541 "Amendment 1: New Appendix X - An example showing how to calculate IPDV across multiple sections" addresses my question. Thank you, Jim D. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops 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.

2 1

Strange attacks over the weekend
by sjur＠usken.no Nov. 1, 2010

Nov. 1, 2010

Hi, We in the Honeynet Project has been following this for the last 4-5 months. We call it sundayddr because of the User-Agent. Ben in Australia has written more about it here: http://honeynet.org.au/ I have also written about it here (back in July) http://www.usken.no/2010/07/using-botnets-to-do-sip-scanning/ It is a botnet client with both a SSH and a SIP scanner (based on SIPVicious by Sandro Gauci) (www.sipvicious.org) Most infected machines doing this scanning are located in China contact me if you need any more information. cheers sjur www.usken.no

1 0

Strange attacks over the weekend
by sil＠infiltrated.net Nov. 1, 2010

Nov. 1, 2010

Sorry for the cross posting to two lists, but I thought everyone on both lists might benefit from the message(*cough*rambling*) So yesterday, I had a honeypot host "open to the world." Not one "block this country" rule on the machine. Normally throughout the past months I've seen maybe 1 or 2 attacks in parallel, but yesterday was different. I butchered up a perl script to block on the fly as opposed to blocking out entire countries and was surprised to see I managed to accumulate 1600+ hosts. Not *that* big of a deal until I started going through some of the logs... I'm a bit puzzled because I see hundreds of attacks in parallel (literally 100-200 connections from different netblocks at the same time) so I'm thinking... "VoIP Based Botnet?" Anyhow, still parsing through the wonderful bucketload of logs this morning. Anyone else see massive activity begininng 10/31? -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 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

5 12

Fraud
by zavoid＠gmail.com Nov. 1, 2010

Nov. 1, 2010

Has anyone ever run into this international fraud before or have any idea who runs it? The various numbers(blocks of numbers) in various countries being called all answered by an IVR with the following message. "Thank you for calling dial to win application, where you can win fabulous prizes every week. The long you hold the line the bigger is your chance to win. For every minute you hold the line you will collect one lucky hit. The more lucky hits the bigger chance to win. Now we will generate a unique pin code for you, your unique pin code is Xxxxxxxxxx Please note down you have collected one lucky hit for this one minute so please hold on and you will get a lucky hit for every minutes. This is a international lottery running successfully in 50 countries of the world. Please hold the line to get next lucky hit and continues????????? Any leads are appreciated. We've blocked all the offending numbers of course. Sent from my iPhone.

3 2

Question about Packet Jitter
by hch＠sipster.com Oct. 30, 2010

Oct. 30, 2010

There's always the RTP/RTCP RFC 3550. See section 6.4.1, interarrival jitter subsection for generating RTCP jitter stats. There's even sample code to implement this in Appendix A.8 Howard Hart Ooma Operations On 10/29/2010 05:15 AM, Jim Dalton wrote: >> Jitter is an average measure of what's >> essentially noise (random variations in the arrival times of packets >> from a mean), and so I'd expect - for two jitter sources in series >> producing average jitter of j1 and j2 respectively - the overall jitter >> to be sqrt(j1^2 + j2^2). >> >> Intuitively, a packet which is late as a result of the first jitter >> source might then be further delayed or delivered early by the second - >> so just summing the average jitter values isn't appropriate. >> >> --Dave >> > [JD wrote:] Very good point. The relationship of overall jitter to be > sqrt(j1^2 + j2^2) makes sense. However, I am having trouble working through > a proof of the math. Any suggestions of a reference on jitter that might > address this? > > Many thanks for your insight, > > Jim D. > > >> -----Original Message----- >> From: voiceops-bounces at voiceops.org [mailto:voiceops- >> bounces at voiceops.org] On Behalf Of David Knell >> Sent: Friday, October 29, 2010 1:37 AM >> To: voiceops at voiceops.org >> Subject: Re: [VoiceOps] Question about Packet Jitter >> >> On Thu, 2010-10-28 at 16:26 -0400, Scott Berkman wrote: >> >>> The only portion missing is the jitter through the SBC itself, which >>> >> really >> >>> should be negligible. Assuming that is 0, your equation below would >>> >> be >> >>> correct. >>> >> I think I'd disagree with this. Jitter is an average measure of what's >> essentially noise (random variations in the arrival times of packets >> from a mean), and so I'd expect - for two jitter sources in series >> producing average jitter of j1 and j2 respectively - the overall jitter >> to be sqrt(j1^2 + j2^2). >> >> Intuitively, a packet which is late as a result of the first jitter >> source might then be further delayed or delivered early by the second - >> so just summing the average jitter values isn't appropriate. >> >> --Dave >> >> >>> -----Original Message----- >>> From: voiceops-bounces at voiceops.org [mailto:voiceops- >>> >> bounces at voiceops.org] >> >>> On Behalf Of Jim Dalton >>> Sent: Thursday, October 28, 2010 8:34 AM >>> To: voiceops at voiceops.org >>> Subject: [VoiceOps] Question about Packet Jitter >>> >>> I have a question about calculating jitter. Consider the call >>> >> diagram >> >>> below. >>> A SIP call flows from the source device to the Session Border >>> >> Controller >> >>> (SBC) >>> to the destination device. All RTP packets are proxied through the >>> >> SBC. >> >>> +========+ +=====+ >>> >> +=============+ >> >>> | Source | Ingress Call Leg | SBC | Egress Call Leg | Destination >>> >> | >> >>> | Device |------------------->| |------------------>| Device >>> >> | >> >>> +========+ +=====+ >>> >> +=============+ >> >>> Jitter Src to SBC >>> -------------------> >>> >>> Jitter Source to Destination >>> ---------------------------------------------> >>> >>> If the packet jitter is known for the Ingress Call Leg from the >>> >> source to >> >>> SBC and for end to end packet flow from the source to the >>> >> destination, is it >> >>> possible to calculate jitter for the Egress Call Leg from the SBC to >>> >> the >> >>> destination device? >>> >>> I do not think the following relationship is accurate. >>> (jitter Source to Destination) less (jitter Src to SBC) = (jitter SBC >>> >> to >> >>> Destination) >>> >>> Can anyone provide some guidance on this question? >>> >>> Thank you, >>> >>> Jim Dalton >>> VoIP Least Cost Routing, Analysis, Billing >>> 1.404.526.6053 >>> www.TransNexus.com >>> >>> >>> >>> _______________________________________________ >>> 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 >>> >>> >> -- >> David Knell, Director, 3C Limited >> T: +44 20 3298 2000 >> E: dave at 3c.co.uk >> W: http://www.3c.co.uk >> >> _______________________________________________ >> 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

Question about Packet Jitter
by albrecht.schwarz＠alcatel-lucent.com Oct. 29, 2010

Oct. 29, 2010

VoIP performance experts should be familiar with - ITU-T Y.1541 concerning IPDV (IP packet delay variation = jitter); there are many sections on IPDV, particularily also on "aggregated PDV"; - IETF PMOL, ... IP performance metrics - IETF AVT, ... RFC's for RTCP XR (RFC 3611, 5093) and ietf drafts on work in progress RTCP XR metrics -Albrecht > -----Original Message----- > From: voiceops-bounces at voiceops.org > [mailto:voiceops-bounces at voiceops.org] On Behalf Of Jim Dalton > Sent: Freitag, 29. Oktober 2010 14:15 > To: 'David Knell'; voiceops at voiceops.org > Subject: Re: [VoiceOps] Question about Packet Jitter > > > Jitter is an average measure of what's essentially noise (random > > variations in the arrival times of packets from a mean), and so I'd > > expect - for two jitter sources in series producing average > jitter of > > j1 and j2 respectively - the overall jitter to be sqrt(j1^2 + j2^2). > > > > Intuitively, a packet which is late as a result of the first jitter > > source might then be further delayed or delivered early by > the second > > - so just summing the average jitter values isn't appropriate. > > > > --Dave > > [JD wrote:] Very good point. The relationship of overall jitter to be > sqrt(j1^2 + j2^2) makes sense. However, I am having trouble > working through a proof of the math. Any suggestions of a > reference on jitter that might address this? > > Many thanks for your insight, > > Jim D. > > > -----Original Message----- > > From: voiceops-bounces at voiceops.org [mailto:voiceops- > > bounces at voiceops.org] On Behalf Of David Knell > > Sent: Friday, October 29, 2010 1:37 AM > > To: voiceops at voiceops.org > > Subject: Re: [VoiceOps] Question about Packet Jitter > > > > On Thu, 2010-10-28 at 16:26 -0400, Scott Berkman wrote: > > > The only portion missing is the jitter through the SBC > itself, which > > really > > > should be negligible. Assuming that is 0, your equation > below would > > be > > > correct. > > > > I think I'd disagree with this. Jitter is an average measure of > > what's essentially noise (random variations in the arrival times of > > packets from a mean), and so I'd expect - for two jitter sources in > > series producing average jitter of j1 and j2 respectively - the > > overall jitter to be sqrt(j1^2 + j2^2). > > > > Intuitively, a packet which is late as a result of the first jitter > > source might then be further delayed or delivered early by > the second > > - so just summing the average jitter values isn't appropriate. > > > > --Dave > > > > > -----Original Message----- > > > From: voiceops-bounces at voiceops.org [mailto:voiceops- > > bounces at voiceops.org] > > > On Behalf Of Jim Dalton > > > Sent: Thursday, October 28, 2010 8:34 AM > > > To: voiceops at voiceops.org > > > Subject: [VoiceOps] Question about Packet Jitter > > > > > > I have a question about calculating jitter. Consider the call > > diagram > > > below. > > > A SIP call flows from the source device to the Session Border > > Controller > > > (SBC) > > > to the destination device. All RTP packets are proxied > through the > > SBC. > > > > > > +========+ +=====+ > > +=============+ > > > | Source | Ingress Call Leg | SBC | Egress Call Leg | > > > | Destination > > | > > > | Device |------------------->| |------------------>| Device > > | > > > +========+ +=====+ > > +=============+ > > > Jitter Src to SBC > > > -------------------> > > > > > > Jitter Source to Destination > > > ---------------------------------------------> > > > > > > If the packet jitter is known for the Ingress Call Leg from the > > source to > > > SBC and for end to end packet flow from the source to the > > destination, is it > > > possible to calculate jitter for the Egress Call Leg from > the SBC to > > the > > > destination device? > > > > > > I do not think the following relationship is accurate. > > > (jitter Source to Destination) less (jitter Src to SBC) = (jitter > > > SBC > > to > > > Destination) > > > > > > Can anyone provide some guidance on this question? > > > > > > Thank you, > > > > > > Jim Dalton > > > VoIP Least Cost Routing, Analysis, Billing > > > 1.404.526.6053 > > > www.TransNexus.com > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > -- > > David Knell, Director, 3C Limited > > T: +44 20 3298 2000 > > E: dave at 3c.co.uk > > W: http://www.3c.co.uk > > > > _______________________________________________ > > 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

Question about Packet Jitter
by scott＠sberkman.net Oct. 29, 2010

Oct. 29, 2010

The only portion missing is the jitter through the SBC itself, which really should be negligible. Assuming that is 0, your equation below would be correct. However, unless you are trying to place blame, the only jitter that really matters is the end to end since if the jitter buffer at the far end overflows, you have problem regardless of the origin of the jitter (OK, I am assuming you are not trying to do something with the RTP at any intermediate point). If you need to check for jitter through the SBC you should be able to take traces on each side and compare the inter-arrival timings. -Scott -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Jim Dalton Sent: Thursday, October 28, 2010 8:34 AM To: voiceops at voiceops.org Subject: [VoiceOps] Question about Packet Jitter I have a question about calculating jitter. Consider the call diagram below. A SIP call flows from the source device to the Session Border Controller (SBC) to the destination device. All RTP packets are proxied through the SBC. +========+ +=====+ +=============+ | Source | Ingress Call Leg | SBC | Egress Call Leg | Destination | | Device |------------------->| |------------------>| Device | +========+ +=====+ +=============+ Jitter Src to SBC -------------------> Jitter Source to Destination ---------------------------------------------> If the packet jitter is known for the Ingress Call Leg from the source to SBC and for end to end packet flow from the source to the destination, is it possible to calculate jitter for the Egress Call Leg from the SBC to the destination device? I do not think the following relationship is accurate. (jitter Source to Destination) less (jitter Src to SBC) = (jitter SBC to Destination) Can anyone provide some guidance on this question? Thank you, Jim Dalton VoIP Least Cost Routing, Analysis, Billing 1.404.526.6053 www.TransNexus.com _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

4 3

Question about Packet Jitter
by anorexicpoodle＠gmail.com Oct. 28, 2010

Oct. 28, 2010

If the SBC is holding all media, is there a reason it cannot simply report what the jitter on the egress leg was and skip the derived jitter equation? This is a simple enough trick for Acme, and I cannot imagine most of the other vendors wouldn't have similar functionality. On Thu, 2010-10-28 at 08:34 -0400, Jim Dalton wrote: > I have a question about calculating jitter. Consider the call diagram > below. > A SIP call flows from the source device to the Session Border Controller > (SBC) > to the destination device. All RTP packets are proxied through the SBC. > > +========+ +=====+ +=============+ > | Source | Ingress Call Leg | SBC | Egress Call Leg | Destination | > | Device |------------------->| |------------------>| Device | > +========+ +=====+ +=============+ > Jitter Src to SBC > -------------------> > > Jitter Source to Destination > ---------------------------------------------> > > If the packet jitter is known for the Ingress Call Leg from the source > to SBC and for end to end packet flow from the source to the destination, > is it possible to calculate jitter for the Egress Call Leg from the SBC > to the destination device? > > I do not think the following relationship is accurate. > (jitter Source to Destination) less (jitter Src to SBC) = (jitter SBC to > Destination) > > Can anyone provide some guidance on this question? > > Thank you, > > Jim Dalton > VoIP Least Cost Routing, Analysis, Billing > 1.404.526.6053 > www.TransNexus.com > > > > _______________________________________________ > VoiceOps mailing list > VoiceOps at voiceops.org > https://puck.nether.net/mailman/listinfo/voiceops

3 3

Question about Packet Jitter
by Jim.Dalton＠TransNexus.com Oct. 28, 2010

Oct. 28, 2010

I have a question about calculating jitter. Consider the call diagram below. A SIP call flows from the source device to the Session Border Controller (SBC) to the destination device. All RTP packets are proxied through the SBC. +========+ +=====+ +=============+ | Source | Ingress Call Leg | SBC | Egress Call Leg | Destination | | Device |------------------->| |------------------>| Device | +========+ +=====+ +=============+ Jitter Src to SBC -------------------> Jitter Source to Destination ---------------------------------------------> If the packet jitter is known for the Ingress Call Leg from the source to SBC and for end to end packet flow from the source to the destination, is it possible to calculate jitter for the Egress Call Leg from the SBC to the destination device? I do not think the following relationship is accurate. (jitter Source to Destination) less (jitter Src to SBC) = (jitter SBC to Destination) Can anyone provide some guidance on this question? Thank you, Jim Dalton VoIP Least Cost Routing, Analysis, Billing 1.404.526.6053 www.TransNexus.com

1 0