- VoiceOps - lists.voiceops.org

Cisco 7940s dialplan
by ujjval＠simplesignal.com Jan. 18, 2010

Jan. 18, 2010

We are seeing some Cisco 7940s autodial a "$" sign after being offhook for about 4-5 secs, They are running 8-12 load and downloading all the config files from our config server, Anyone has a remedy for that. Its driving me nuts...

3 6

SBC and routing solutions
by blair＠fx.net.nz Jan. 14, 2010

Jan. 14, 2010

Hi Guys, I'm wondering if the list can help me out a bit, just looking for some ideas really. I have been messing about with this voip stuff for years, but got given an actual network to manage last year, and trying to figure out the best way to clean it up. I really need some community input on Best-Practice for a few design/architectural ideas - Probably stuff you take for granted, but for small fry like me it's difficult to get my head around having not really done this stuff before :) Currently I run a small voip network comprised of some SER boxes with custom modules for accounting and authentication, a couple of AS5300 gateways, and a SIP interconnect with our primary upstream. I'm trying to envision what would be needed to add a little more functionality to this network, and potentially simplify provisioning, accounting and debugging. We have no SBC in the network currently, and just pass SIP packets around, with media flowing either directly to/from the 5300s or to the upstream's SBC. This presents us with problems if we want to add another upstream, we need to get the customers to update their ACLs, and if we want to translate numbers or mess with SIP packets, SER is not really very good at that. I've been talking with ACME about some 3800s as an SBC, but I'm not really sure whether they could take over the full functionality of the current network, and whether I'd need to get some custom management interfaces written to manage route tables etc on the ACME, or if the inbuilt interfaces are good-enough. I guess my question comes in really the form of experience with similar situations - I know a lot of you out there have ACME SBCs in place, do you use it to authenticate sessions directly with the customers, or do you generally have some kind of soft switch sitting in front handling all of that? If so, what kind of soft switches are you running for small volumes of calls - I don't want to be paying $100k for something that OpenSIPS is probably capable of with a little custom development (or can it do everything off-the-shelf these days?) Also wondering CDR wise, at what point in your network do you pull your CDRs and generate bills from- the ACME will create radius start/stop records, but can it attach billing information to those radius records or am I going to have to bolt something on the end of that as well? Wondering rate-table wise if it is best to have a central table somewhere which gets used for generating billing info, and if you have some kind of interface your customers can check current rates? I guess just looking for people who have done this before, what have you found that works and what doesn't, so I can avoid it and save myself some time going down a dead-end road :) Thanks for any assistance, and offlist replies are of course welcome. Sorry for the slightly all-over-the place questions too. Regards, Blair Harrison

1 0

Call Recording Laws in the US
by beckman＠angryox.com Jan. 13, 2010

Jan. 13, 2010

So I've been thinking about call recording laws recently and wanted to get some feedback. 1. As an ITSP, are we held liable for enabling our customers to potentially illegally record a phone call in states where all-party notification is required? Or is it solely on the party who did the illegal recording? 2. Interstate phone calls get tricky -- it may be legal for single-party notification in the originating or terminating state, but illegal in the other. 3. When a California resident has a California phone number (a state which requires all-party notification and consent of call recording) receives a call when physically in Oregon, which law applies -- CA or OR? Assuming the caller is in a single-party consent state. Makes things kinda difficult -- I guess it is simply easier for the ITSP to say "hey, you can record, but follow the laws." and hope we don't get mixed up in it. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------

4 3

Oracle security alert (US CERT TA10-012A)
by hiersd＠gmail.com Jan. 13, 2010

Jan. 13, 2010

Oracle is used in many of the commercial voip systems, and they just released a big security patch bundle. There is a pretty big pile of 3rd party software jammed into the various platforms. Broadsoft has around 40 different parties listed in thier "thrid-party acknowledgement" list. How closely do you monitor this kind of thing? With good architecture and other controls, you can keep most of the vulnerable code fairly well isolated from The Wild, but China, Inc can be pretty persistent when they get curious (just ask google: http://www.google.com/search?q=google+china !). Thanks, David

1 0

RHEL nm watchdog kernel panic
by ujjval＠simplesignal.com Jan. 11, 2010

Jan. 11, 2010

Has anyone seen a broadsoft server on a ibm blade center running RHEL 5.x crash with this error Kernel panic not syncing nmi watchdog Sent from my iphone

4 5

VoIP T38 Fax reliability
by jrandall＠comwave.net Jan. 8, 2010

Jan. 8, 2010

I never actually got the reply from Ujjval so I'm going to reply to this thread. My experience with the FCS-BAD problems has typically been related to TDM problems not relating to VoIP or T.38 in any way. While it is possible that a buggy T.38 stack might cause all sorts of unexpected issues, FCS is related to framing and I've seen this issue resolved in certain media gateways by ensuring that the TDM clocking on the media gateway cards is tuned properly. One thing people often forget is that faxing doesn't even work 100% in the PSTN. Line noice, interference, etc. all contribute to failures. These types of failures are simply propagated through the T.38 stack into the UDPTL signaling. For your issues with not receiving DIS I would try and perform a G711u bypass fax call and export the audio from the RTP through Wireshark and listen to the analog signaling handshake exchange to see if the fax machines are even properly communicating at a basic level. If you have PSTN bearer tracing capabilities you could also perform a T.38 test call and listen to see if the initial fax signaling tones are sent and acknowledged at the analog side. Hope this is helpful, Justin -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Alex Balashov Sent: Thursday, January 07, 2010 12:55 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] VoIP T38 Fax reliability Been there, done that, got the t-shirt. Main problem I ran into is that (1) Super G3 detection doesn't work on many switches, and (2) even the ones on which it does work there is not a vendor-neutral way to pass that knowledge through to the terminating gateway, and (3) T.38 support at Super G3 speeds is lacking in most implementations at this time. Between this and the problems you mention, it's just not worth it. Seriously, it's one of the least Pareto-optimal propositions in the entire business. Just sell them analog lines. I've actually managed to convert a few customers - even steadfastly traditional, paper-intensive ones - to using fast doc scanners + e-mail. :-) On 01/07/2010 12:47 PM, Ujjval Karihaloo wrote: > Correct, I have been able to get around INVITE glare etc...by tweaking ATA > configs, however the problem mainly lies in UDPTL T3/T38 signaling in > the RTP, E.g. TAs keep sending no signal msgs to the Provider and they > don't sends a DIS back and it then just re-invites for G711 > Pass-though...and that never works... > > I have also seen FCS-BAD (HDLC frame signal) coming from the Provider > when UDPTL data is sent. > > *From:* Justin Randall [mailto:jrandall at comwave.net] > *Sent:* Thursday, January 07, 2010 10:40 AM > *To:* Ujjval Karihaloo; voiceops at voiceops.org > *Subject:* RE: [VoiceOps] VoIP T38 Fax reliability > > Faxing over T.38 from experience has certainly been a better experience > than over G711u bypass. Of course there are some implementations of T.38 > that interoperate with each other better than others. My experience with > AudioCodes, Linksys/Sipura, and Grandstream has been very positive. > > One of the common potential problems with either approach is the > behaviour of the signaling in response to which end (caller, callee, or > both) of the session is responsible for initiating the re-INVITE for > T.38. When supporting wholesale customers it is not always possible to > configure the behaviour of the ATAs/IADs and the only way to ensure fax > will at least always be "detected" is to have one of endpoint > gateways/ATAs/IADs detect fax as the caller and the callee. The next fun > piece to tackle once that's configured is to ensure that all endpoints > properly support handling SIP 491 Request Pending response codes to > avoid a race condition which can cause INVITE "glare" if one endpoint is > configured to detect faxes and re-INVITE for both caller and callee and > the other is set to detect faxes and re-INVITE on either. > > Regards, > > Justin > > ------------------------------------------------------------------------ > > *From:* voiceops-bounces at voiceops.org > [mailto:voiceops-bounces at voiceops.org] *On Behalf Of *Ujjval Karihaloo > *Sent:* Wednesday, January 06, 2010 7:01 PM > *To:* voiceops at voiceops.org > *Subject:* [VoiceOps] VoIP T38 Fax reliability > > I know this a thorn in everyones flesh, I would like to know of > experiences with T38 Voip Faxing. We have had good and bad. Those that > don't work just don't and they don't even want to troubleshoot and just > switch over to an Analog line for Fax. We mostly use AudioCodes and > Sipura T38 ATAs. > > Any of you folks do T38 and whats the experience like. > > > > _______________________________________________ > VoiceOps mailing list > VoiceOps at voiceops.org > https://puck.nether.net/mailman/listinfo/voiceops -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

1 0

VoIP T38 Fax reliability
by ujjval＠simplesignal.com Jan. 8, 2010

Jan. 8, 2010

I know this a thorn in everyones flesh, I would like to know of experiences with T38 Voip Faxing. We have had good and bad. Those that don't work just don't and they don't even want to troubleshoot and just switch over to an Analog line for Fax. We mostly use AudioCodes and Sipura T38 ATAs. Any of you folks do T38 and whats the experience like.

6 7

Vitelity down?
by beckman＠angryox.com Jan. 8, 2010

Jan. 8, 2010

I can't get to Vitelity via Cox, Verizon or Level3. Can anyone else also confirm the outage? Anyone at Vitelity on the list for an update? --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------

1 0

VoIP T38 Fax reliability
by jrandall＠comwave.net Jan. 7, 2010

Jan. 7, 2010

Faxing over T.38 from experience has certainly been a better experience than over G711u bypass. Of course there are some implementations of T.38 that interoperate with each other better than others. My experience with AudioCodes, Linksys/Sipura, and Grandstream has been very positive. One of the common potential problems with either approach is the behaviour of the signaling in response to which end (caller, callee, or both) of the session is responsible for initiating the re-INVITE for T.38. When supporting wholesale customers it is not always possible to configure the behaviour of the ATAs/IADs and the only way to ensure fax will at least always be "detected" is to have one of endpoint gateways/ATAs/IADs detect fax as the caller and the callee. The next fun piece to tackle once that's configured is to ensure that all endpoints properly support handling SIP 491 Request Pending response codes to avoid a race condition which can cause INVITE "glare" if one endpoint is configured to detect faxes and re-INVITE for both caller and callee and the other is set to detect faxes and re-INVITE on either. Regards, Justin _____ From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Ujjval Karihaloo Sent: Wednesday, January 06, 2010 7:01 PM To: voiceops at voiceops.org Subject: [VoiceOps] VoIP T38 Fax reliability I know this a thorn in everyones flesh, I would like to know of experiences with T38 Voip Faxing. We have had good and bad. Those that don't work just don't and they don't even want to troubleshoot and just switch over to an Analog line for Fax. We mostly use AudioCodes and Sipura T38 ATAs. Any of you folks do T38 and whats the experience like.

4 3

Skype gateways? Anyone using them?
by jtodd＠loligo.com Jan. 6, 2010

Jan. 6, 2010

I've been asked to throw something out here on the list to see if anyone is using a Skype gateway of some sort. I know that quite a few people do trunk Skype into their existing TDM PBX platforms for connection to customer service lines, or for the odd road warrior who needs access to a DISA trunk. But is this widespread? Are the companies making the "hardware" units making reliable equipment? Does any carrier think that Skype calls through or into their network is a viable business in some way, or is it always a threat? Yes, Digium does offer a Skype software package that could be considered "competitive", but I'm actually somewhat interested to know if anyone is doing significant amounts of Skype trunking into their other TDM or VoIP networks. I'd welcome open discussion of this, since it's kind of an interesting operational question. If you feel like it, you can answer this short survey, too - http://bit.ly/skype-gateways http://www.voip-info.org/wiki/view/Skype+Gateways JT disclaimer: it seems relevant to say that this is usually my .sig: --- John Todd email:jtodd at digium.com Digium, Inc. | Asterisk Open Source Community Director 445 Jan Davis Drive NW - Huntsville AL 35806 - USA direct: +1-256-428-6083 http://www.digium.com/

2 1