Re: [Openpbx-dev] G.729 licensing project
Jac Barben wrote: All: Because G.729 is so important to my world, I've contacted each of Intel and Sipro. For the benefit of others that may need licensing here are the costs and contacts: Intel: http://www.intel.com/cd/software/products/asmo-na/eng/download/locations/index.htm#perflib $199 one time and $80 a year. This part is trivial. :-) Sipro: http://sipro.com Sipro is handling the G.729/G.723 patents for all those that claim have claimed ownership: France Telecom, Mitsubishi, Electric Corporation, Nippon Telephone and Telegraph Corporation,Universite de Sherbrooke (The G.729 Consortium), NEC and Nokia. Typically Sipro charges an annual fee per port of use. The killer here is the minimum - 1000 ports. Your entry fee is: US $9,884. Its worse than that. NEC and Nokia are not actually represented by Sipro, and you must pay them separately. All Sipro do is tell you who you need to contact. NEC and Nokia want about as much as Sipro, so you can more or less double the prices Sipro quote. Unless something has changed recently, the price you quote is an illusion brought on by the confusing way they present things. I seem to remember it works out somewhat higher, and then you double it for the NEC and Nokia part. I'm pretty certain that I'm going to have to step up to these costs. To that end, I am thinking of building a library of the Intel/Sipro work for use with OpenPBX and distributing the libraries for commercial use, as permitted by the Intel/Sipro licensing, at a fee similar to the structure defined by Digium. Is there any interest here or am I the only one with commercial use plans? We know this needs sorting out. A telephony platform without G.729 just won't fly at this time. The Freeswitch people have the same issue, and we hope we can work with them to a mutual solution. There is a company, whose web site name I forgot, which is providing G.729 for small users like us. There web site makes it look like they are dead, but the Freeswitch guys have been in touch with them, and it seems they are still active. Since we have plenty to do right now, I've just been waiting to see what Freeswitch dredges up as a workable solution. We intend to support these things through pipes, with the transcoder running as a separate process. That completely avoids licencing issues with our pure GPL core, and the overhead is no big deal when you compare it against the compute cost of the codec. Regards, Steve ___ Openpbx-dev mailing list Openpbx-dev@openpbx.org http://lists.openpbx.org/mailman/listinfo/openpbx-dev
Re: [Openpbx-dev] T.38/RxFax - T38 Versions other than zero not working.
Hi Matthew, Matthew O Connor wrote: Hi, I'm using OpenPbx as a fax endpoint for a T.38 gateway that I am building here at Calyptech. I noticed that I could fax to OpenPbx using an SDP T38FaxVersion of 0 but not of 1 or higher. After some investigation it appears that at the sip level the T38FaxVersion is recorded but it isn't passed down to the rxFax. I modified the rxfax_exec to force the T38FaxVersion to 1 and presto I could now send faxes to OpenPbx with a T38FaxVersion of 1. I Added the following lines to apps/app_rxfax.c : ... Line 369 t38_terminal_init(t38, calling_party, t38_tx_packet_handler, chan); Line 370 new // MOCO - SET T38 TO VERSION 1 FOR TESTING. Line 371 new t38_set_t38_version(t38, 1); Line 372 span_log_set_message_handler(t38.logging, span_message); ... I am using version 1.2_rc3. In order to get other versions of t38 working the version has to be set via the t38_set_t38_version function. I'm not sure of the mechanism of passing the version number down from SIP into the rxFax application. Anyway I hope this helps. BTW - Great application guys, keep up the great work. Thanks for reporting that. Can you tell me what you are using that supports version 1 or higher? The reason we haven't notice this bug is because most things today only support version 0. Regards, Steve ___ Openpbx-dev mailing list Openpbx-dev@openpbx.org http://lists.openpbx.org/mailman/listinfo/openpbx-dev
Re: [Openpbx-dev] more names
Leo Ann Boon wrote: CtRiX wrote: Terry Moore-Read wrote: After asking to quote a bit better... So drop GNU to avoid confusion with FSF Projects but keep weaver so it can be confused with an Adobe product ? It's probably best to keep away from derivations of trademarked names all together. Weaver has nothing to do with Dreamweaver and related trademarks as well as Point has nothing to do with powerpoint and related trademarks as well as Fox has nothing to do with firefox or firebird and related trademarks. We are not dropping GNU because it creates confusion, but because we have nothing to do with them. The comparison with Adobe is silly because we are not renaming openpbx to AdobePBX. How about VoxToaster? The toaster part seems OK. There used to be various toaster products from various companies, so I don't think anyone has a hold on that. I'm not so happy with the vox part. Its too voice specific. Steve ___ Openpbx-dev mailing list Openpbx-dev@openpbx.org http://lists.openpbx.org/mailman/listinfo/openpbx-dev
Re: [Openpbx-dev] Suggestion
Max CtRiX wrote: Leo Ann Boon wrote: Steve Dover wrote: Stiletto - A Switch Blade. ___ Tag line: 'A stab in the heart of proprietary phone systems'. Domain Name:STILETTO.ORG Created On:16-Jul-2001 10:55:46 UTC Last Updated On:07-Jul-2006 21:29:15 UTC Expiration Date:16-Jul-2007 10:55:43 UTC Ah, why let practicality get in the way of a great idea. :-) Steve ___ Openpbx-dev mailing list Openpbx-dev@openpbx.org http://lists.openpbx.org/mailman/listinfo/openpbx-dev
Re: [Openpbx-dev] more names - why?
Hi David, David Sugar wrote: Steve, perhaps you could explain for me why they would wish to change one already confusing and contested moniker for another... While I have not followed it closely, and I certainly have no issue with any of the work the ?formerly? openpbx (the one that is not the voicetronix openpbx) project does, I fail to see how it would further serve their purpose to be confused instead with GNU Telephony, our PBX work, etc. I only very recently heard about this, but I was hoping you could explain this to me and how this could happen. We are quite happy working in freedom on free telephony software, services, and component libraries in GNU Telephony, many of which are maintained as official GNU packages. While we certainly do not wish to involve ourselves in other projects uninvited, when some group chooses or appears to confusingly represent themselves as us, I feel I must respond to that in some manner. At the very least, it would seem to me to be simple common courtesy to have asked how we might feel about it first. I'm sorry this has happened. Names were supposed to be vetted for basic suitability before being put forward for voting - e.g. a web search for who else might be using the name. The gnu in gnupbx clearly makes this unacceptable, without any need for a web search, and it should never have reached this stage. Steve ___ Openpbx-dev mailing list Openpbx-dev@openpbx.org http://lists.openpbx.org/mailman/listinfo/openpbx-dev
Re: [Openpbx-dev] more names
Ariel Monaco wrote: - Original Message - From: Roy Sigurd Karlsbakk [EMAIL PROTECTED] To: OpenPBX.org Developers Mailing List openpbx-dev@openpbx.org; OpenPBX.org Users Mailing List - Non-Commercial Discussion openpbx-users@openpbx.org Sent: Wednesday, March 07, 2007 7:01 AM Subject: [Openpbx-dev] more names hi all after discussing the name suggestion 'gnupbx' on IRC, it was noted, correctly, that this should not be regarded an option, since openpbx is not part of FSF. It would be like naming the project AsteriskPBX or ApachePBX. What do we need to be part of the FSF? Is this really relevant? Highly relevant. Apart from any legal issues, like trademarks, its damned rude to just try to associate what you do with something successful, by choosing a related name. Secondly, if would want to put PBX in the name you are very myopic. So gnupbx is composed of two parts, neither of which is a good match for what we want. I suggest we drop that name and let the voting go on with the other candidates Why drop a name people is voting? They may be voting, but are they thinking? I think too many of those voting have no stake in choosing a good name. They are just drive by pollers. Talking to other serious contributors, we'll just walk away if something as poorly considered as gnupbx is chosen. Its that simple. Steve ___ Openpbx-dev mailing list Openpbx-dev@openpbx.org http://lists.openpbx.org/mailman/listinfo/openpbx-dev
Re: [Openpbx-dev] Name Changes...
Bruno Wolff III wrote: On Fri, Feb 23, 2007 at 11:17:00 +0100, Ming-Wei Shih [EMAIL PROTECTED] wrote: If you have a name candidate, please to not make it public until the domain name is secured. Note if you are worried about this you arlso need to be careful about checking to see if a domain name is available. If you check with a registry, there are somne shady registries that get to see the request and may buy the name on speculation if you don't buy it right away. Checking to see if there is an NS record for a domain should give you a pretty good idea about its availablity and seems less like to come to the attention of speculators. Yep. I've experienced this. Do a query on some crazy name, and within a few hours it will be taken. Steve ___ Openpbx-dev mailing list Openpbx-dev@openpbx.org http://lists.openpbx.org/mailman/listinfo/openpbx-dev
Re: [Openpbx-dev] Name Changes...
Sam Bingner wrote: I dislike CallWeaver, I dislike the association with DreamWeaver but otherwise I like it. I dislike the name dreamweaver. I dislike its association with something orderly and well designed, rather than spaghetti. Let's try to make callweaver a more seemly use of the term weave :-) Seriously, the choice had nothing to do with that. Think switching fabric, and not bloatware. Steve ___ Openpbx-dev mailing list Openpbx-dev@openpbx.org http://lists.openpbx.org/mailman/listinfo/openpbx-dev
Re: [Openpbx-dev] Name Changes...
Alexander Lopez wrote: In addition to the other weavers don't forget Basketweaver. We could in turn change: Queues= Baskets Jitter= Under Water interference Dropped Frames= Holes On a serious note. This is going to be a difficult name change in a democracy. I would open voting for limited time and just forge ahead. A name is not as important as a good product. Once good products exist, people will not care what it is called. CallWeaver is fine with me. Although a Call is synonymous with a Voice Call I would move toward something like MediaWeaver. As it does more than voice. Does call imply voice to anyone else? It certainly didn't to me. That's one of the reasons I chose it. People were throwing around ideas like talk, which were very voice specific. openpbx is basically about calls, whether they be voice, video or whatever. SMS would be a borderline case. Regards, Steve ___ Openpbx-dev mailing list Openpbx-dev@openpbx.org http://lists.openpbx.org/mailman/listinfo/openpbx-dev
Re: [Openpbx-dev] rfc4733?
Roy Sigurd Karlsbakk wrote: hi has anyone looked into this? http://www.rfc-editor.org/rfc/rfc4733.txt it seems nortel has worked out a better way to do dtmf than the old rfc2833 The DTMF in 4733 isn't really any different. Its all sorts of other stuff which had been changed or added between 2833 and 4733. A 2833 implementation should be generally a sub-set of a 4733 one. Steve ___ Openpbx-dev mailing list Openpbx-dev@openpbx.org http://lists.openpbx.org/mailman/listinfo/openpbx-dev
Re: [Openpbx-dev] Wideband Support
Marc Olivier Chouinard wrote: I dont know, the basic problem I beleive is getting our hand on a good codec There are at least 2 good wideband codecs immediately available - G.722 in spandsp, and wideband speex. Steve ___ Openpbx-dev mailing list Openpbx-dev@openpbx.org http://lists.openpbx.org/mailman/listinfo/openpbx-dev
Re: [Openpbx-dev] More on Cluecon
Justin Tunney wrote: On Wednesday 09 August 2006 15:14, Esben Stien wrote: Openpbx [..] opens the doors to REAL VOIP. For me, this means lossless FLAC codec, 24bit, 96kHz. I have no use for interfacing to anything but SIP, really. That would be great if you could figure out how to turn a whole recording studio in to a giant telephone. So that's what people are jamming our phone lines really means. :-) Steve ___ Openpbx-dev mailing list Openpbx-dev@openpbx.org http://lists.openpbx.org/mailman/listinfo/openpbx-dev
Re: [Openpbx-dev] More on Cluecon
Daniel Swarbrick wrote: bkml wrote: SIP is not my idea of a unified call model either and it won't be for a variety of reasons. There is a proven standard already out there, it's called Q.931 and that should be the yardstick. You're lucky if all your installations are within reach of ISDN. Some of mine aren't, and the availability of IP-based WAN options nearly always exceeds ISDN availability - whether that be frame-relay, leased line, xDSL, wireless, laser... voice is pretty easy to move, once it's in an IP packet. And voip is the reason why most of us are interested in this project, is it not? I think you miss the point. The ISDN call model, embodied in Q.931, is a superset of all the other call models. Any form of telephony today will fit into the ISDN (which is also the SS7) call model. No other call model can say that. H.323 is Q.931 based. SIP is just a hacked up abortion, but it is nowadays trying hard to be like ISDN. MGCP is a misconception designed to support a twisted gateway/switch model within a ISDN based world. Of course, if you prefer to use TDM protocols, there is a project that was originally designed to do just that, and still suffers from a fairly TDM-centric design... ;-) Sure, SIP has its problems, and different implementations of it have different problems at that... but it's rapidly becoming the de facto standard for voip. The mere fact that Cisco Call Manager v5 seems to give at least equal importance to SIP as it does to their own SCCP, speaks volumes. Heck, even some telcos are starting to use IP WANs with a voip to E1 converter at the CPE, going into legacy PBXs, and thus eliminating the need for adding more PRI linecards in their exchanges. It's probably only a matter of time before they simply offer a SIP trunk and be done with it. Regards, Steve ___ Openpbx-dev mailing list Openpbx-dev@openpbx.org http://lists.openpbx.org/mailman/listinfo/openpbx-dev
Re: [Openpbx-dev] T38 issues
Max CtRiX wrote: Hi, I have tried to use the latest snapshots of SpanDSP to make T38 termination work. I managed to compile everything. The whole thing requires some modifications to configure.ac, codec_g.726 (conflicts with new spandsp) and of course, app_txfax and app_rxfax. I have managed to get some results. In particular: No fax received. Only 1 fax transmitted (great result!) I have collected some logs here: http://projects.navynet.it/t38/1/ File tx2-ok is the log of the only one which worked well. Now, I do not have the background to understand what is going wrong, but it seems to me that udptl OR spandsp does not manage very well sequence numbers. Do you have any hints ? Thanks, Max I just committed a few changes to trunk related to this. The logging in udptl.c isn't that useful for analysing detailed problems. There were sequence numbers, and packet type fields, but these contained no actual information. That information isn't knowm at the transport level. I have tidied that up now. I have also added the ability to send specified packets multiple times. T.38 terminals and gateways do this as part of their redundancy practices - its not part of the the spec, but it is something many implementations of T.38 do. My latest spandsp code can make use of this feature. I modified app_rxfax.c and app_txfax.c to work with the latest APIs in the spandsp snapshots. You need to comment out the first line in each file, or you will get the old API. The logs from your tests do not have the debug logging for app_txfax switched on. That makes them of very little value for analysis. Try the latest code, and enable txfax debug logging. Then we should be able to see what is really going on. Steve ___ Openpbx-dev mailing list Openpbx-dev@openpbx.org http://lists.openpbx.org/mailman/listinfo/openpbx-dev
Re: [Openpbx-dev] T38 termination problems
Bartek Kania wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 1 Apr 2006, Steve Underwood wrote: Max CtRiX Cetra wrote: I am trying to make T38 termination work under openpbx. I have used egnarf T38 trunk and it compiles cleanly with the latest spandsp snapshot (commiting it to mainline could be useful). snipp Here's a hint: it doesn't work is a completely useless report. :-) What does happen? What do the logs show? Does it negotiate T.38 at all? Firstly, that branch is under development.. Or, it would be if it wasn't for a lot of other things that I need to do and the fact that I haven't had the time to read the T.38 specs yet =) The T.38 spec is not that illuminating when you read it. :-) I've been testing with RxFax and trying to receive a fax using UDPTL The problems so far are: * chan_sip doesn't seem to detect the fax tones. I don't really see why, but it seems the goertzel detector doesn't detect it. WHat I found is that this check if (!hit (fax_energy = FAX_THRESHOLD) (fax_energy = DTMF_TO_TOTAL_ENERGY*s-energy) the second line never gets to be true. If I remove it it seems to detect the faxtones. But I don't understand what it does so I don't really want to remove it. Steve, if you could look at that it would be great! That sounds like the signal is disorted by the codec to the point where it lacks sufficient purity to be detected as a single tone. Which codec did you use for the audio? * A really annoying bug in chan_sip/rtp/udptl/idontknowyet causes openpbx to ignore incoming frames until it has sent the first frame itself. So RxFax doesn't receive audio / udptl at all until it has sent the first frame itself. I needed to add a PlayTones() before the call to RxFax to hear the initial fax-tones in my test-phone and via the modem. I think this is something to do with NAT handling, isn't it. I guess I could make an initial transmission, just to kick things off. If anyone has any experience with T.38 and feels like looking at it, please do so! I probably won't have the time for a while =/ You need to use a recent snapshot of spandsp. A couple of silly issues in the T.38 code were reported to me, and fixed - bits being packed in the wrong order at one point was something of a killer :-) People have reported sending faxes in both directions with a recent snapshot, but don't read too much into that. There are a lot of grey things in the T.38 spec, and further work to ensure interworking with a lot of kit that implements the T.38 spec in their own sweet way will be needed. Also, I don't expect the current code to be that robust. Its really not mature right now. The frame structure gained the sequence number of the frames a while ago. It isn't used to the fullest extent, though. For example, it should be used to define the sequence number of UDPTL frames going out, and it isn't. This is important, since to make UDPTL robust certain key frames should be repeated to minimise the risk of loss. This is not specified, but it is common and sane practice. Regards, Steve ___ Openpbx-dev mailing list Openpbx-dev@openpbx.org http://lists.openpbx.org/mailman/listinfo/openpbx-dev
Re: [Openpbx-dev] T38 termination problems
Max CtRiX Cetra wrote: Hi all, I am trying to make T38 termination work under openpbx. I have used egnarf T38 trunk and it compiles cleanly with the latest spandsp snapshot (commiting it to mainline could be useful). Imho, T38 may be the best feature for openpbx. No other open source pbx supports it so this feature may lead to a great spread of openpbx. Anyway, it compiles cleanly but it doesnot work, exactly as previous releases. Now, I have installed openpbx and commented out the following 3 lines in sip.conf t38udptlsupport=yes ; Turn on support for T.38 UDPTL t38rtpsupport=yes ; Turn on support for T.38 RTP t38tcpsupport=no; Turn on support for T.38 TCP I have tried all possible permutations of the tree but it does not work. My tests were made sending/receiving faxes through a cisco gateway or with direct connection to a starcomm gateway which supports T38. Maybe I am doing something wrong... Any hints ? On the other side, what info, log, dumps can I produce to help you solving the problem ? Here's a hint: it doesn't work is a completely useless report. :-) What does happen? What do the logs show? Does it negotiate T.38 at all? Steve ___ Openpbx-dev mailing list Openpbx-dev@openpbx.org http://lists.openpbx.org/mailman/listinfo/openpbx-dev
Re: [Openpbx-dev] where to download spandsp-0.0.3pre5
Bartek Kania wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 14 Mar 2006, Jeffrey C. Ollie wrote: On Wed, 2006-03-15 at 12:17 +0800, Leo Ann Boon wrote: Nathan C. Smith wrote: http://www.soft-switch.org/downloads/spandsp/spandsp-0.0.2pre25/ I have already compiled and install spandsp-0.0.2pre25, but openpbx configure fails with: configure: error: SpanDSP does not appear to be new enough. You must have version 0.0.3pre5 or newer to compile OpenPBX.org. It looks like the 0.0.3 versions that are required for OpenPBX.org have been deleted. You could try one of the snapshots from: http://www.soft-switch.org/downloads/snapshots/spandsp/ The snapshot from Mar 5th looks like it would work, but I haven't actually tried it yet. That snapshot will most probably not work with RxFax/TxFax/chan_fax due to some API changes. I don't know about the 0.0.2pre25 tho. I have updates for the fax-stuff that make them work (i think) with the latest snapshots in a branch. I can't test it this week but it might be time to merge them. I cleaned up some old versions on soft-switch.org and went away for a few days. Looks like I cleaned up a bit too much by mistake. Sorry. The latest snapshots of spandsp are a much better option than 0.0.3pre5. T.38 actually kinda works with the latest snapshots. I think there is no point is reinstating 0.0.3pre5, as it is rather out of date. I will, however, make a suitable version available at soft-switch.org shortly. Regards, Steve ___ Openpbx-dev mailing list Openpbx-dev@openpbx.org http://lists.openpbx.org/mailman/listinfo/openpbx-dev
