- VoiceOps - lists.voiceops.org

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. 31, 2010

Oct. 31, 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. 29, 2010

Oct. 29, 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

Zone Telecom Reviews
by peter.w.fabian＠gmail.com Oct. 27, 2010

Oct. 27, 2010

We are looking at Zone Telecom for Termination traffic. Does anybody have any experience with Zone (good or bad). How is the voice quality, service, reliability etc? Thanks Peter Fabian | Senior Voice Engineer

2 1

DashCS for 911 in AT&T Areas
by abarratt＠socket.net Oct. 26, 2010

Oct. 26, 2010

Looking for a review here -- so if you're not comfortable replying to the board, please send me a PM. Any CLECS on here using DashCS for 911 in AT&T areas? Did they have any problems with the indirect trunking? How have your experiences been with connecting to them over the public network? Have they truly had 100% coverage as they advertise? How well is their ALI management handled -- are rejects pretty high? 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. **********************************************************************

2 1

911 Contract Language
by Marty_Sorensen＠adp.com Oct. 26, 2010

Oct. 26, 2010

Hey everyone...What type of language do your companies use for Voip 911 in your contracts? If anyone is willing to send me some examples off list, I would be appreciative. More specifically, what are your customers asked to sign off on in your customer contracts? Marty 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.

1 0

Clear 4G WiMAX and VoIP
by carlos＠televolve.com Oct. 26, 2010

Oct. 26, 2010

Anyone have customers using Clear for small/remote offices? We have a national customer that need to deploy some small offices with 1-4 handsets and 1-2 concurrent calls. Many locations can't get even DSL, or it's very low speed/quality. -- Carlos Alvarez TelEvolve 602-889-3003

7 6