June 2011 - VoiceOps - lists.voiceops.org

Equipment Sale.
by alejandro＠amerimex.com June 15, 2011

June 15, 2011

All, We are AmeriMex Communications Corp. CLEC based in Roswell, GA, we have three collos in AT&T's GA area (Roswell, Cumming and Gainsville), we have Adtran TA3000 and TA5000 installed and working with capacity of 500 POTS in each one of those COs. Roswell equipment also supports T1s. We are selling all equipment if you are interested please contact us. alejandro at amerimex.com Thanks, <outbind://25/AmeriMexSignature_files/image001.jpg> Alejandro Caipa IT Director 1007 Mansell Road Suite A Roswell GA 30076 Direct Dial: 678.832.6220 alejandro at amerimex.com www.amerimex.com

2 1

ACME behaviour with Bad NAT Firewalls
by ujjval＠simplesignal.com June 10, 2011

June 10, 2011

Hi All: We have seen many PBX NAT?ed behind a Firewall that does not do the Sip ALG correctly. Most cases putting the Private IP in the Contact header and the ACME responds back to the Private IP. Example call inbound to the PBX, the PBX sends a 200 OK (as call is answered) with a Private IP in the contact header. ACME sends the ACK back to the Private IP blackholing it. I have seen SBC?s that do adjust to the Layer 3 IP:port if they notice Private IPs in the SIP signaling. Is there a setting on ACME to do that? Thx, UK

6 8

Polycom ghost ringing
by peeip989＠gmail.com June 7, 2011

June 7, 2011

Back in January there were a couple of posts related to "ghost ringing" on Polycom phones. At the time the workaround seemed to be to downgrade to v3.3.0 (we're on 3.3.1). Looking at the release notes on 3.3.1 it looks like the .0 release was pretty buggy and therefore we'd rather not downgrade to it. Polycom has not acknowledged (to us) that they even know about the problem. Does anyone know if any headway has been made in actually fixing the issue?

3 8

SS7 analysis
by frnkblk＠iname.com June 7, 2011

June 7, 2011

Every once in a while we have an incoming calling issue (TDM side of the house) where we need to talk to our tandem to find out which trunk of theirs the call came in on. Most of the time we have to do that while the call is in progress, or wait till it comes in again so they have their SS7 analyzer ready. A person in our company heard from another telco who uses another tandem that it's possible for us not to involve our tandem, but discover/learn at least some part of the call path using SS7, that is, be able to see beyond our tandem. Our tandem says that's not possible, but our person says the other telco is sure about this. Anyone know either which way? Frank

1 0

SIP calls that aren't torn down
by frnkblk＠iname.com June 7, 2011

June 7, 2011

Over the last few months our softswitch has accumulated 10 "stuck" calls where there's no media traffic. From what the softswitch vendor can tell or guess, it just didn't receive a BYE to tear down the call. We know that most SIP traffic on 5060 is UDP, and UDP is connectionless. How are other vendors and systems managing such scenarios? I suggested a "no media" test where after x hours of no media, to tear down the call and log the info. Thoughts? Frank

8 18

VoiceOps Digest, Vol 24, Issue 3
by jaredball1＠gmail.com June 3, 2011

June 3, 2011

I've seen ghost ringing with broadsoft's call transfer recall feature. The scenario was that an operator transferred calls to a hunt group and when they didn't answer in time the call was recalled to the operator. The phones continued to ring even after the call was recalled. This was with broadsoft R14 and a patch to the application server resolved the issue. On Fri, Jun 3, 2011 at 4:31 PM, <voiceops-request at voiceops.org> wrote: > Send VoiceOps mailing list submissions to > voiceops at voiceops.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://puck.nether.net/mailman/listinfo/voiceops > or, via email, send a message with subject or body 'help' to > voiceops-request at voiceops.org > > You can reach the person managing the list at > voiceops-owner at voiceops.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of VoiceOps digest..." > > Today's Topics: > > 1. Re: Polycom ghost ringing (PE) > 2. Re: Polycom ghost ringing (PE) > 3. Re: Broadworks hunt group CNAME manipulation (Dag Peak) > > > ---------- Forwarded message ---------- > From: PE <peeip989 at gmail.com> > To: Brad Anouar <Brad at broadcore.com> > Date: Fri, 3 Jun 2011 15:59:16 -0400 > Subject: Re: [VoiceOps] Polycom ghost ringing > Typically Linksys (SRW or SFE), but we are also finding that customers plug > in other various stuff (which appears to be the source of the spanning > tree). > > > > > > On Fri, Jun 3, 2011 at 3:56 PM, Brad Anouar <Brad at broadcore.com> wrote: > >> Hi Pete, >> >> >> >> According to the only capture we have, you are right. Neither in-band nor >> out-of-band traffic that would cause such behavior was present. I?m going to >> go back and check to see if there was any STP activity during the time of >> the incident. It could?ve been easily ignored since we only have one >> capture. I will also check to find out if the affected clients are all using >> the same type of switch. I will then post the findings. What type of switch >> do your affected customers use? >> >> >> >> Regards, >> >> *Brad Anouar** ** *| Anywhere (310) 360-2028 | Corporate (800) 942-4700 | >> www.broadcore.com >> >> >> >> *From:* voiceops-bounces at voiceops.org [mailto: >> voiceops-bounces at voiceops.org] *On Behalf Of *PE >> *Sent:* Friday, June 03, 2011 12:27 PM >> *To:* voiceops at voiceops.org >> *Subject:* Re: [VoiceOps] Polycom ghost ringing >> >> >> >> @Christian, no, I mean that while the user is on the phone they hear the >> far end party mixed with ringback tone in their ear. >> >> >> >> @Brad, we have not correlated it with hunt groups or even on incoming >> calls. We've only been able to capture it a couple of times and the times we >> have seen it, it has coincided with a slew of spanning tree activity on the >> LAN. Could be coincidence, but I am thinking there is an >> indirect correlation. Clearly the spanning tree is not SIP (and we are not >> seeing a 180 Ringing or other message that might confuse the phone) and is >> not inband ringback in RTP, but I am thinking it might be causing the phone >> to to wig out, though this is pure speculation. We also have the same >> concerns about file structure. >> >> >> >> >> >> On Fri, Jun 3, 2011 at 3:00 PM, Brad Anouar <Brad at broadcore.com> wrote: >> >> We?ve had the same problem with FW version 3.3.1. We?ve noticed that it >> only happens when the call is terminated through a hunt group. There was >> some sort of a reINVITE that triggered a weird ring back tone in the middle >> of the call. Polycom support has acknowledged the issue and suggested to >> downgrade to 3.2.4, but as you probably know, the structure of the >> configuration files is different in the pre 3.3.x FW. The next FW version is >> scheduled to be released in July. We are still trying to come up with a work >> around. >> >> >> >> *Brad Anouar** ** *| Anywhere (310) 360-2028 | Corporate (800) 942-4700 | >> www.broadcore.com >> >> >> >> *From:* voiceops-bounces at voiceops.org [mailto: >> voiceops-bounces at voiceops.org] *On Behalf Of *Pete E >> *Sent:* Friday, June 03, 2011 10:54 AM >> >> >> *To:* voiceops at voiceops.org >> *Subject:* [VoiceOps] Polycom ghost ringing >> >> >> >> Back in January there were a couple of posts related to "ghost ringing" on >> Polycom phones. At the time the workaround seemed to be to downgrade to >> v3.3.0 (we're on 3.3.1). Looking at the release notes on 3.3.1 it looks like >> the .0 release was pretty buggy and therefore we'd rather not downgrade to >> it. Polycom has not acknowledged (to us) that they even know about the >> problem. Does anyone know if any headway has been made in actually fixing >> the issue? >> >> >> > > > > ---------- Forwarded message ---------- > From: PE <peeip989 at gmail.com> > To: "voiceops at voiceops.org" <voiceops at voiceops.org> > Date: Fri, 3 Jun 2011 17:39:24 -0400 > Subject: Re: [VoiceOps] Polycom ghost ringing > After discussing your Hunt Group theory we may have some examples that > occurred this way. We will try to validate and see if there is any > commonality there. > > What types of switches are your customers using? > > > > > On Fri, Jun 3, 2011 at 3:59 PM, PE <peeip989 at gmail.com> wrote: > >> Typically Linksys (SRW or SFE), but we are also finding that customers >> plug in other various stuff (which appears to be the source of the spanning >> tree). >> >> >> >> >> >> On Fri, Jun 3, 2011 at 3:56 PM, Brad Anouar <Brad at broadcore.com> wrote: >> >>> Hi Pete, >>> >>> >>> >>> According to the only capture we have, you are right. Neither in-band nor >>> out-of-band traffic that would cause such behavior was present. I?m going to >>> go back and check to see if there was any STP activity during the time of >>> the incident. It could?ve been easily ignored since we only have one >>> capture. I will also check to find out if the affected clients are all using >>> the same type of switch. I will then post the findings. What type of switch >>> do your affected customers use? >>> >>> >>> >>> Regards, >>> >>> *Brad Anouar** ** *| Anywhere (310) 360-2028 | Corporate (800) 942-4700| >>> www.broadcore.com >>> >>> >>> >>> *From:* voiceops-bounces at voiceops.org [mailto: >>> voiceops-bounces at voiceops.org] *On Behalf Of *PE >>> *Sent:* Friday, June 03, 2011 12:27 PM >>> *To:* voiceops at voiceops.org >>> *Subject:* Re: [VoiceOps] Polycom ghost ringing >>> >>> >>> >>> @Christian, no, I mean that while the user is on the phone they hear the >>> far end party mixed with ringback tone in their ear. >>> >>> >>> >>> @Brad, we have not correlated it with hunt groups or even on incoming >>> calls. We've only been able to capture it a couple of times and the times we >>> have seen it, it has coincided with a slew of spanning tree activity on the >>> LAN. Could be coincidence, but I am thinking there is an >>> indirect correlation. Clearly the spanning tree is not SIP (and we are not >>> seeing a 180 Ringing or other message that might confuse the phone) and is >>> not inband ringback in RTP, but I am thinking it might be causing the phone >>> to to wig out, though this is pure speculation. We also have the same >>> concerns about file structure. >>> >>> >>> >>> >>> >>> On Fri, Jun 3, 2011 at 3:00 PM, Brad Anouar <Brad at broadcore.com> wrote: >>> >>> We?ve had the same problem with FW version 3.3.1. We?ve noticed that it >>> only happens when the call is terminated through a hunt group. There was >>> some sort of a reINVITE that triggered a weird ring back tone in the middle >>> of the call. Polycom support has acknowledged the issue and suggested to >>> downgrade to 3.2.4, but as you probably know, the structure of the >>> configuration files is different in the pre 3.3.x FW. The next FW version is >>> scheduled to be released in July. We are still trying to come up with a work >>> around. >>> >>> >>> >>> *Brad Anouar** ** *| Anywhere (310) 360-2028 | Corporate (800) 942-4700| >>> www.broadcore.com >>> >>> >>> >>> *From:* voiceops-bounces at voiceops.org [mailto: >>> voiceops-bounces at voiceops.org] *On Behalf Of *Pete E >>> *Sent:* Friday, June 03, 2011 10:54 AM >>> >>> >>> *To:* voiceops at voiceops.org >>> *Subject:* [VoiceOps] Polycom ghost ringing >>> >>> >>> >>> Back in January there were a couple of posts related to "ghost ringing" >>> on Polycom phones. At the time the workaround seemed to be to downgrade to >>> v3.3.0 (we're on 3.3.1). Looking at the release notes on 3.3.1 it looks like >>> the .0 release was pretty buggy and therefore we'd rather not downgrade to >>> it. Polycom has not acknowledged (to us) that they even know about the >>> problem. Does anyone know if any headway has been made in actually fixing >>> the issue? >>> >>> >>> >> >> > > > ---------- Forwarded message ---------- > From: Dag Peak <dpeak at broadsoft.com> > To: Nelson Hicks <nelsonh at socket.net>, VoiceOps <voiceops at voiceops.org> > Date: Fri, 3 Jun 2011 16:00:44 -0700 > Subject: Re: [VoiceOps] Broadworks hunt group CNAME manipulation > Hi Nelson, R17SP3 (which just was released this week), includes new > configuration options that do what you want to do, namely not have the Hunt > Group's name prepended to the calling line ID. This is associated with > feature 113687, and is described in > ConfigurableHuntGroupNamePresentationFD-R180.pdf. > > Dag Peak > Senior Sales Engineer > dpeak at broadsoft.com > > > -----Original Message----- > From: Nelson Hicks [mailto:nelsonh at socket.net] > Sent: Friday, June 03, 2011 10:39 AM > To: VoiceOps > Subject: [VoiceOps] Broadworks hunt group CNAME manipulation > > Hello, > > We have a few hunt groups built out in BroadWorks and have noticed that > the hunt group name is prepended to the caller name when an inbound call > to the hunt group is sent to one of its members. This could be a very > useful feature, but our current hunt group customers don't want this and > the only setting I've found for it in Broadworks disables it globally. > > I've looked for options to rewrite the caller name part of the display > field, either on our SBC or the TA900 CPE, but neither seems to support > stripping off the first part of the display name and leaving the rest. > > Has anyone else already dealt with this? If so, what solution did you > end up with? > > -- > Nelson Hicks > DNS and Web Administrator > SOCKET > (573) 817-0000 > dns at socket.net > 1-800-SOCKET-3 www.socket.net > > > > > > _______________________________________________ > VoiceOps mailing list > VoiceOps at voiceops.org > https://puck.nether.net/mailman/listinfo/voiceops > >

1 0

Broadworks hunt group CNAME manipulation
by nelsonh＠socket.net June 3, 2011

June 3, 2011

Hello, We have a few hunt groups built out in BroadWorks and have noticed that the hunt group name is prepended to the caller name when an inbound call to the hunt group is sent to one of its members. This could be a very useful feature, but our current hunt group customers don't want this and the only setting I've found for it in Broadworks disables it globally. I've looked for options to rewrite the caller name part of the display field, either on our SBC or the TA900 CPE, but neither seems to support stripping off the first part of the display name and leaving the rest. Has anyone else already dealt with this? If so, what solution did you end up with? -- Nelson Hicks DNS and Web Administrator SOCKET (573) 817-0000 dns at socket.net 1-800-SOCKET-3 www.socket.net

5 4