We're not connected to PacWest but have seen very similar things with Verizon
in the past. It was usually that they turned up a new gateway and started
sending calls from it. We would not have a route back to then so they would
overflow to another gateway (the second call) but never CANCEL'd the
+1 for that answer, David. It went beyond accurate and was "accurate with
style."
On Jun 16, 2014, at 10:07 AM, "Hiers, David" wrote:
That handles the IVR case, sure, but the harried, highly-caffeinated
receptionist with a headset that can strike the "answer" button like a cobra
remains a p
True, especially when capturing on the device (versus from a mirror port).
Possible MTU size issue?
On Jun 21, 2014, at 11:58 AM, Ujjval Karihaloo wrote:
wireshark can show chksum incorrectly at times.
Ujjval K
> On Jun 21, 2014, at 9:37 AM, Jay Ashworth wrote:
>
> I have a client using
It may not be "the most advanced" but I'm not sure I agree with your "POTS
replacement" assessment either. We have many, many enterprise customers and BW
suits them just fine.
On Aug 19, 2014, at 7:11 AM, Alex Balashov wrote:
The idea that Broadsoft is "the most advanced softswitch out there
Anyone have a good test number (200 without a preceding 18x) in PSTN? The one I
used to use no longer works.
Thanks,
Pete
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
Anyone out there using Puppet to help manage their Broadsoft servers? Any
conflicts or issues? Any feedback appreciated.
Thanks,
Pete
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
riginal message ----
From: Peter E
Date: 05/12/2014 22:57 (GMT+02:00)
To: VoiceOps
Subject: [VoiceOps] Broadsoft / Puppet
Anyone out there using Puppet to help manage their Broadsoft servers? Any
conflicts or issues? Any feedback appreciated
The intercept feature can also be used to stop fraud or as a temporary shutoff
for non-payment, which may be why your wholesaler isn't exposing it to you.
On Dec 16, 2014, at 10:57 PM, Jay Hennigan wrote:
> On 12/16/14, 6:20 PM, Colton Conor wrote:
> I don't think I have this option from our
We've had the same problem. Most go through, but maybe 5-10% get blocked. We've
tried several carriers and spoken to couple more and it seems to be an industry
problem. Started having conversations with Primus but never bothered to cross
the finish line because it seemed like there wasn't a solu
Anyone in the group from or have a technical contact at Lighthouse Cablevision?
Could really use some help in Connecticut.
Thanks in advance
Pete
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
It is not exclusive to Broadsoft, at least from a Polycom perspective. It's a
config parameter which tells the phone to SUBSCRIBE/NOTIFY to the network/PBX.
What other pbx's respond to it, though, I'm not sure.
Search the Polycom docs for "serverFeatureControl"
HTH,
Pete
On Apr 1, 2015, at 8:
I agree with Shripal, it is doable in broadworks. Depending on the model of
VVX, though, your performance may vary. It seems they are using a lesser chip,
probably to get the price down, and their performance suffers when hit with too
many simultaneous messages. So, a small SCA environment with
Thanks Tim. Very helpful. Exactly what I needed to know. We've gotten several
complaints today in the Philly metro area.
On May 14, 2015, at 16:33, Tim Glen wrote:
For the past hour or so, from Philadelphia I’ve gotten a fast busies and
echoing when calling VZW numbers in S Jersey.
Tim
We had similar issues with Verizon late last week. Most complaints were
originating from cell phones, terminating in mid-Atlantic. Verizon closed our
ticket this morning with NTF and we were unable to duplicate it again.
On May 18, 2015, at 13:07, Tim Donahue wrote:
Hi all,
We have a client
I stand corrected. Verizon didn't say NTF, they said they resolved it but were
not specific on how.
On May 18, 2015, at 13:07, Tim Donahue wrote:
Hi all,
We have a client complaining that calls to the 818 area code are failing with a
"No circuits available" message. The only common link we
Well said Alex. Service providers require support for the *whole* product and
that is where open source solutions may falter.
I don't necessarily agree with the notion that the big-brands don't integrate.
We do a ton of integration with Broadsoft, both with software that we've
written and 3rd p
I assume this was directed at me? I guess you missed the part where I said I am
a fan of open source technologies.
On Jun 20, 2015, at 15:39, Peter Beckman wrote:
Better not use SIP, it is an open standard.
Better not use DNS and BIND, it's both an open standard and open source.
Better not
I'm looking for Java software developers with experience writing large-scale
SIP applications. Looking for a full-time hire.
If you or someone you know is looking for such an opportunity please contact me
off-list. Or if someone knows of a better list to post this please point me in
that direct
You're preaching to the choir, Mark. As a company, for BYOD, we take a stance
of, we'll supply the SIP credentials but we won't support the device. But
anyone in an operations role knows what that really means -- do whatever it
takes to get them working and happy.
I'll share your comments with
Wouldn't is be cause code 1, unallocated number?
http://www.dialogic.com/webhelp/img1010/10.5.2/webhelp/General_Reference/def_sip-ss7_cc.htm
On Oct 20, 2015, at 21:38, Alex Balashov wrote:
Hello,
Are there ISUP cause codes for disconnected numbers? And if so, do there exist
established map
Agree. 503 has become badly misused.
On Oct 20, 2015, at 22:48, Alex Balashov wrote:
Thanks. And I'm guessing the best one can hope for from a SIP termination
provider is an ambiguous 404, or, more likely, a 503, which seems to have
become misused an opaque, catch-all epithet for any and all
For what it's worth, here's the RFC that maps the codes:
https://tools.ietf.org/html/rfc3398
On Oct 20, 2015, at 21:38, Alex Balashov wrote:
Hello,
Are there ISUP cause codes for disconnected numbers? And if so, do there exist
established mappings for them to SIP?
I've never seen this pre
Not usually an issue for us. Occasionally an intermediate carrier hosted a
number at one time and didn't u provision it when they lost the customer, but
that's fairly rare these days. So I agree, 404's are fairly reliable for us.
On Oct 21, 2015, at 13:46, Alex Balashov wrote:
Can't a 404 some
Anyone have a sales contact at voipmonitor they can share or should I just go
through their webpage?
Feel free to reply on or off-list.
Thanks,
Pete
On Nov 20, 2015, at 16:33, Gavin Henry wrote:
On 20 Nov 2015 21:15, "Calvin Ellison" wrote:
>
> Yup! Remote probes solved a couple challenge
This is a really interesting idea, Mark. I only have a high-level understanding
of Bitcoin but it definitely seems very similar to what we're talking about as
for number ownership. It doesn't completely answer the trust question but
there's definitely something here...
On Dec 7, 2015, at 16:54,
In this scenario:
NANPA -> Level3 -> reseller A -> reseller B -> reseller C -> end-user
Only reseller C and the end user knows where the chain ends. So, what about
some OSPF-like mechanism? Let's say that in this scenario Level3 has direct
connections with both resellers A and C. It would know
Well, I think that's where Mark's Bitcoin-ish idea comes in. I'm sure he can
explain it better than I can.
On Dec 8, 2015, at 00:35, Peter Beckman wrote:
Reseller C and the end user knows where the chain ends, but how do WE know
that reseller C and end-user are honest?
We're in the middle of a trial of voipmonitor so this topic is timely as we're
crushing the lab boxes and therefore don't trust any of the stats it is
currently showing (MOS, PDD, etc).
If you're capturing sip + rtp headers and you have a need (plus permission) to
record full rtp for a single
Thanks Matt
On Feb 11, 2016, at 21:47, Matt Ladewig wrote:
If you have the base config set to record rtp headers only, then you can add a
specific capture rule under “capture rules” to override the base config. Set
RTP to ON in the rule.
From: Peter E [mailto:peeip...@gmail.com]
Sent
Keep beating that drum, Anthony. Have you tried voipmonitor? You might be
surprised.
On Feb 11, 2016, at 22:21, Anthony Orlando wrote:
Empirix Peter. Empirix
Sent from my iPhone
> On Feb 11, 2016, at 8:37 PM, Peter E wrote:
>
> We're in the middle of a trial of voipmonitor
Bouncing up and down over the last half hour or so…
On Mar 11, 2016, at 18:31, Nathan Anderson wrote:
This message has no content.___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
It's not as clear but it's still quite acceptable and in low bandwidth
scenarios, one could argue, the quality can be better because you don't drop
packets where you might with higher bandwidth codecs.
On Mar 11, 2016, at 19:03, Robert Johnson wrote:
> On 03/11/2016 03:50 PM, Alex Balashov w
President, Client Services
Star Telecom | www.startelecom.ca | SIP Based Services for Contact Centers
-Original Message-
From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Peter E
Sent: Friday, March 11, 2016 7:14 PM
To: Robert Johnson
Cc: voiceops@voiceops.org
S
I've seen this behavior before with another carrier where they send an invite
from the original gateway and when they don't get a response they overflow to
another gate way before the first call is killed and therefore The phone rings
twice but only the second call can get answered.
On Mar 17,
I like the idea. Perhaps people would be more willing to share their
experiences if there were a message board or other place to maintain anonymity?
On Mar 19, 2016, at 12:42, Tim Linn wrote:
Ryan,
This is a great discussion to start. I can't contribute at this time, but I
certainly plan on g
Being directly connected is indeed better -- faster with fewer points of
failure -- but is not infallible. It just means you're fewer AS hops away. If
you use a carrier and they are attacked, chances are you're going to be
impacted in some way, regardless if you are directly connected. Even the
com.ca | SIP Based Services for Contact Centers
| LinkedIn
-Original Message-
From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Alex
Balashov
Sent: Thursday, March 17, 2016 10:53 PM
To: voiceops@voiceops.org
Subject: Re: [VoiceOps] VoIP Innovations reliability
On 03/17/20
Ouch, that was painful to read. I can't imagine having lived it.
When in doubt, dig for Cisco documents because CxO's all know and trust the
brand. I'll forward whatever I can find.
On Mar 25, 2016, at 19:55, Aaron C. de Bruyn wrote:
I'll try to make this short: I am an IT contractor for "Co
bill.
On Mar 25, 2016, at 20:10, Peter E wrote:
Ouch, that was painful to read. I can't imagine having lived it.
When in doubt, dig for Cisco documents because CxO's all know and trust the
brand. I'll forward whatever I can find.
On Mar 25, 2016, at 19:55, Aaron C. de Bruyn wr
Here's one. It's obviously CM centric, but covers most of the points you're
after:
http://www.cisco.com/c/dam/en_us/about/ciscoitatwork/downloads/ciscoitatwork/pdf/Cisco_IT_Case_Study_IP_Telephony_Management.pdf
On Mar 25, 2016, at 19:55, Aaron C. de Bruyn wrote:
I'll try to make this short:
Here's a decent (short) article about security:
http://www.scmagazine.com/simple-best-practices-for-voip/article/207273/
On Mar 25, 2016, at 19:55, Aaron C. de Bruyn wrote:
I'll try to make this short: I am an IT contractor for "Company X" that has
~26 offices around the western US. We are p
Here's an article from a system integrators point of view:
http://www.scmagazine.com/simple-best-practices-for-voip/article/207273/
On Mar 25, 2016, at 19:55, Aaron C. de Bruyn wrote:
I'll try to make this short: I am an IT contractor for "Company X" that has
~26 offices around the western US
Agree regarding NFV. It's a pretty big topic.
Oracle (Acme) is playing catch-up but also has a solution now. Haven't played
with it (or Somus, Sansay) yet so I can't render an opinion.
On Apr 6, 2016, at 21:58, Ryan Delgrosso wrote:
They have more than a buzzword for this, its a whole movement
It's been a decade since I've touched SS7, and I barely remember what I had for
breakfast, so it's like it's all new to me again.
From what I read, it sounds like there may be a "proxy" function that can be
injected which would bring both endpoints back to you so you can record both
legs. The 6
M BLT..
On May 6, 2016, at 10:39, Ivan Kovacevic wrote:
Troubleshooting an RLT issue for a client and would like to short-cut the usual
Tier1, Tier2, Tier3 dance, since most of the low level techs don’t know RLT
from a BLT (sandwich).
Thx.
Best Regards,
Ivan Kovacevic
Vice Pres
Hey gang,
We currently use a software product called 8MS
(http://www.csfcorp.com/products/8ms/) as our interface into SMS-800. Besides
the native SMS interface, does anyone use competing products? Opinions?___
VoiceOps mailing list
VoiceOps@voiceops.or
You can use Watson as a service direct from IBM.
http://www.ibm.com/watson/developercloud/speech-to-text.html
On Sep 14, 2016, at 13:16, Aryn Nakaoka 808.356.2901
wrote:
AT&T is shutting down "Watson" Speech to Text API... does anyone have a similar
platform?
- cost was very inexpensive $
No issues here (yet).
Downdetector shows something is up but not nearly what it looked like 2 weeks
ago.
On Oct 17, 2016, at 11:26, David Wessell wrote:
Is anyone having issues with SIP traffic from Level3 in ATL and Dallas? I'm
starting to get reports of audio issues and the MTR's to the L3
+1 on this response.
We watch our metrics closely so we can measure when something begins to move in
the wrong direction. We ultimately had to stop paying attention to 503's
because of their casual interpretation of the RFC's intention of 5xx responses.
It seems like we need a new "Not Now I Ha
The SIP protocol already has some built in reliability techniques built in
(timers, retransmission) for which TCP is usually used. Yes, TCP is a bit more
resource intensive due to the TCP overhead. But the biggest reason I prefer UDP
is for failover/redundancy. In the event of a system failure/f
We've been battling Verizon on this because they won't terminate 833 for us.
They claim it's not part of the product we buy from them. I'm calling B.S.
since they accept 844 through 888. Nevertheless, for now they aren't taking it
but Level3 does. We're paying extra while we work it out but at l
I realize this is a bit of a fishing expedition, but is anyone seeing an recent
increase of all circuits busy conditions over the last week or know of any PSTN
trunk capacity problems?
Unfortunately, I can't be more specific because we are seeing an uptick but
doesn't seem isolated to any one o
Not sure what that means but I'm LOL'ing.
On Sep 21, 2017, at 15:36, Alex Balashov wrote:
On Thu, Sep 21, 2017 at 03:31:45PM -0400, Peter E wrote:
> I realize this is a bit of a fishing expedition, but is anyone seeing
> an recent increase of all circuits busy conditions ov
I agree with Ryan and Alex. Your ROI on an LCR platform will be long, and
Thinq is a good choice.
On Sep 6, 2018, at 10:02, Dave Sill wrote:
All,
I’m interested in learning about current best practices regarding LCR in the
CLEC context (~2M minutes / month of LD traffic). What software/v
54 matches
Mail list logo
