- VoiceOps - lists.voiceops.org

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

Jan. 12, 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. 7, 2010

Jan. 7, 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

VoIP T38 Fax reliability
by carlos＠race.com Jan. 7, 2010

Jan. 7, 2010

Send and pray that what we say with faxing over voip lol. Carlos Alcantar Race Telecommunications, Inc. 101 Haskins Way South San Francisco, CA 94080 P: 650.649.3550 x143 F: 650.649.3551 E: carlos at race.com -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Alex Balashov Sent: Wednesday, January 06, 2010 6:36 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] VoIP T38 Fax reliability On 01/06/2010 07:15 PM, Gabriel Kuri wrote: > It seems to be hit and miss, certainly not 100%, but better than > trying to use either PCMU or PCMA over the commodity Internet for > FAXing. PCMU/PCMA might work over a local private LAN with QoS enabled > and the jitter down to almost nothing. Agreed about T.38 vs. analog pass-through. > The biggest issue I've seen > with T38 is the ATA's inability to properly negotiate a Super-G3 fax > down to G3 or slower speeds. In our experience, you need to disable > the Super-G3 feature of the FAX machine to slow it down to either 14.4 > or 9600 and disable ECM. Many of the newer FAX machines have a "VoIP > Compatibility" mode which essentially slows it down to 9600 and > disables ECM. There's been an enormous explosion of Super G3 machines in the last few years; asking users to disable SG3 is not really tenable. Fax over IP is one of those things that, like anything else, can be gotten to work passably with enough spiritual commitment. But it's just not worth it. Hand the customers some resale analog lines or what have you and be done with it. -- 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

Delay on RTP for Inbound Calls
by ujjval＠simplesignal.com Jan. 6, 2010

Jan. 6, 2010

Hi Guys; We have noticed that sometimes when calling into our DIDs (Level 3 DIDs), there is a 2-3 second lag. i.e. Cell phone caller (party A) calls into a DID (Party B) that is on our network (Broadsoft Softswitch), Party B answers and sayd 1,2,3,4,5 - but the Party A only hears 4, 5...The part i.e. 1,2,3 get cut off. Plus it is sporadic and difficult to reproduce, was wondering if folks have encountered this and any good troubleshooting techniques you can recommend. Ujjval Karihaloo

5 18