July 2010 - VoiceOps - lists.voiceops.org

Contract development referral
by bethjohnson5060＠gmail.com July 21, 2010

July 21, 2010

Can anyone refer a good contract development company? We are interested in developing call control apps using the best of xsi, ccxml, vxml, etc, and are looking for an experienced development team. -B

4 3

VZN outages?
by David_Hiers＠adp.com July 19, 2010

July 19, 2010

Anyone having trouble with Verizon this morning? We're seeing a few scattered completion issues. Thanks, 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 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

Verizon
by rruiz＠hbcorporate.com July 15, 2010

July 15, 2010

Hello, I'm new to this list but, I'd like to know if anyone has a contact number for a Verizon/MCI Metro NOC in MS? We've identified a Verizon/MCI Metro number in MS that's call forwarded to one of our customer's toll free. Our end user is receiving multiple calls from MS residents who are calling the Verizon/MCI Metro number and are mistaking like terminated on our clients toll free. I'd like to speak with a switch tech to undo the forwarding. Any help would be appreciated. Thanks, Rafael Ruiz Hunt Telecom

2 1

Voxeo
by David_Hiers＠adp.com July 15, 2010

July 15, 2010

Hi, Is anyone running Voxeo? 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 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

The peer of my peer is my peer?
by lindsey＠e-c-group.com July 14, 2010

July 14, 2010

The great thing about the vocalized approach is that it maintains the telephony application passed down to us by AT&T. But the tragedy is great, too. We're all working so hard to limit ourselves to the telephony of 1990: -- No video. -- No better-than-g711u audio. -- No distributed presence. -- No simple file transfer (which means you're stuck supporting fax machines). -- No easy conference control (moderation, floor control, remote mute, etc). -- No location conveyance ("Bring me a large pepperoni pizza. Goodbye."). -- No simple authentication. -- No encryption. -- No easy relocation of handsets. Geoff, anorexicpoodle, and Paul are all arguing for a sober approach: "The job of the network is to ensure people can carry on voice conversations, so the network should do anything necessary to ensure this occurs." So we centralize all our control into a few central, core devices that act a lot like the 1ESS of 1965. But we're all using technology designed by an entirely different mindset. All through the VoIP RFCs, you get the idea that the job of the network is to allow endpoints to interconnect however they want. Only by pushing intelligence to the leaf nodes of the network can you have scalable distributed applications. We are selling the services that customers know they want. But please don't pretend that that the network we're building is the final answer for IP-based telecommunications, or even the most interesting realization of VoIP technologies. On 7/13/10 5:51 PM, Geoff Mina wrote: > If you are acting as an ITSP for Customer A and Customer B, I would > venture to say that it is your responsibility to normalize the media > between the two. Either proxying the rtp and transcoding on-net or > hairpining to the PSTN would both be acceptable. > > Not doing so will result in inconsistent and unexpected behavior for > your customers, and that never makes anyone happy. On 7/13/10 5:18 PM, anorexicpoodle wrote: > I cant imagine them not just routing this through a media server and > trans-coding between the disparate parties. On 7/13/10 5:04 PM, Paul Timmins wrote: > If any of my current suppliers did this, I'd scream bloody murder until > they fixed it or made it go away. If a provider lets people choose their > own settings, I fully expect them to transcode it for us. Anything less is > a bug. > > -Paul > > >> Every so often this issue comes up, and I want to get a read on it from >> other VOIP resellers... >> >> Consider a couple of unrelated VOIP resellers that peer with a carrier >> like L3. Both can interop with L3 using strict SIP and RTP settings (max >> forwards, g729 only, 10ms ptime, whatever). Both are free to select >> mutually incompatible settings. For instance, reseller A can chose 729 >> only, and reseller B can choose 711 only. L3 will connect both to the >> PSTN without any trouble. >> >> Everything is good until they try to call each other. Then the mutually >> incompatible settings will break calls or render predicted usage patterns >> invalid. Sure, you're still signaling to a L3 SIP server, but some the >> information in the SIP/SDP packets that you receive is controlled by the >> other reseller. >> >> How often do you see problems related to the peer of your peer? >> >> >> >> >> 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 >> >> >> >> 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. >> _______________________________________________ >> 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 >

5 5

The peer of my peer is my peer?
by mh＠markholloway.com July 14, 2010

July 14, 2010

Hence the Acme 9200 to the rescue. On Jul 13, 2010, at 2:04 PM, Paul Timmins wrote: > If any of my current suppliers did this, I'd scream bloody murder until > they fixed it or made it go away. If a provider lets people choose their > own settings, I fully expect them to transcode it for us. Anything less is > a bug. > > -Paul > >> Every so often this issue comes up, and I want to get a read on it from >> other VOIP resellers... >> >> Consider a couple of unrelated VOIP resellers that peer with a carrier >> like L3. Both can interop with L3 using strict SIP and RTP settings (max >> forwards, g729 only, 10ms ptime, whatever). Both are free to select >> mutually incompatible settings. For instance, reseller A can chose 729 >> only, and reseller B can choose 711 only. L3 will connect both to the >> PSTN without any trouble. >> >> Everything is good until they try to call each other. Then the mutually >> incompatible settings will break calls or render predicted usage patterns >> invalid. Sure, you're still signaling to a L3 SIP server, but some the >> information in the SIP/SDP packets that you receive is controlled by the >> other reseller. >> >> How often do you see problems related to the peer of your peer? >> >> >> >> >> 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 >> >> >> >> 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. >> _______________________________________________ >> 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

3 4

Bandwidth.com Wholesale opinions?
by jared＠compuwizz.net July 13, 2010

July 13, 2010

I'm talking with them to start setting up a wholesale sip trunk with them. The rates look great. In the past it seems they were mainly a Level3 reseller. However now that they are a CLEC, have they mixed in other carriers as well? Whats the general opinion of them? I see from today's thread they only are a SIP proxy and don't touch the media so I may have ON-net issues with their customers every now and then. Are there any other complaints or compliments for them? ~Jared Geiger

3 4

ATT Wireless Dropped Calls
by clec＠cygnustel.com July 12, 2010

July 12, 2010

By the time I had our switch vendor on the phone Friday everything was working fine and I couldn't make it error. May never know but at least now I know how to get the ss7 captures. On Sun, July 11, 2010 8:12 am, Yeager, Charles wrote: > Timing between IAM and ACM? 180 vs. 183? > > > ________________________________________ > From: voiceops-bounces at voiceops.org [voiceops-bounces at voiceops.org] On > Behalf Of Frank Bulk [frnkblk at iname.com] > Sent: Wednesday, July 07, 2010 9:24 PM > To: 'Eric Hiller'; voiceops at voiceops.org > Subject: Re: [VoiceOps] ATT Wireless Dropped Calls > > What does the SS7 signaling look like for that call? > > Frank > > -----Original Message----- > From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] > On Behalf Of Eric Hiller > Sent: Wednesday, July 07, 2010 8:20 PM > To: voiceops at voiceops.org > Subject: [VoiceOps] ATT Wireless Dropped Calls > > This is a strange issue I just found out about, not sure how long it has > been happening. Apparently any ATT Wireless calls that come into our > system (an possibly just those that terminate into asterisk via sip(only > complaints so far)) are dropped. Our switch is connected to ATT Wireless > over ISUP/SS7 trunks and the calls are coming out as SIP. Asterisk gets a > SIP INVITE from the switch, then responds with a 100 Trying and a 200 OK, > The switch then sends an ACK and then a BYE. The ATT Wireless customer > just hears beep beep beep call lost. > > Any ideas? It doesn't happen 100% of the time, but the vast majority. Also > a Wait(1) in asterisk before answering doesn't seem to make any > difference? > > Thanks for any ideas! > -Eric > > _______________________________________________ > 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

ATT Wireless Dropped Calls
by clec＠cygnustel.com July 11, 2010

July 11, 2010

This is a strange issue I just found out about, not sure how long it has been happening. Apparently any ATT Wireless calls that come into our system (an possibly just those that terminate into asterisk via sip(only complaints so far)) are dropped. Our switch is connected to ATT Wireless over ISUP/SS7 trunks and the calls are coming out as SIP. Asterisk gets a SIP INVITE from the switch, then responds with a 100 Trying and a 200 OK, The switch then sends an ACK and then a BYE. The ATT Wireless customer just hears beep beep beep call lost. Any ideas? It doesn't happen 100% of the time, but the vast majority. Also a Wait(1) in asterisk before answering doesn't seem to make any difference? Thanks for any ideas! -Eric

5 4

Level3 woes
by sil＠infiltrated.net July 9, 2010

July 9, 2010

We've all seen it... Influx of "wth is going on" ... Just got a quick boost of "can't dial out, can't receive calls.." and other "niceties" from clients. Common denominator Level3. Anyone seeing anything similar" (10:40ish - now(sporadically)) -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 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

4 4