November 2007 - h323plus - lists.packetizer.com

Does H323plus support H.235
by Bian 27 Nov '07

27 Nov '07

ToAll, Does anyone have experience implementing H.235 AES using h.323plus? Where can I begin? Regrads, Bian ___________________________________________________________ @yahoo.cn 新域名、无限量，快来抢注！ http://mail.yahoo.cn/

1 0

Re: [h323plus] Migration to ANSI bool in PTLib
by Craig Southeren 27 Nov '07

27 Nov '07

Simon Horne wrote: > To All > > I had requested slightly more time but alas :( > > h323plus (in conjunction with GnuGk) will migrate over the next week or so. > If you are using the PTLIB TRUNK please compile for backward compatibility > until Jan and I have completed h323plus and GnuGk translation. To assist, we'll try not to do much to PTLib until you are migrated. This means the development snapshot will be good for you to use. > Our apologies for not be able to co-ordinate this a little better. Thanks for your efforts - it is much appreciated :) Craig ----------------------------------------------------------------------- Craig Southeren Post Increment – VoIP Consulting and Software craigs(a)postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren(a)hotmail.com Mobile: +61 417231046 Jabber: craigs(a)jabber.org "Science is the poetry of reality." Richard Dawkins

1 1

Migration to ANSI bool in PTLib
by Craig Southeren 27 Nov '07

27 Nov '07

To all, As described previously, PTLib is about to migrate the internal type PBoolean the ANSI type "bool". This will affect all member functions that use BOOL parameters and are overrides of standard PTLib and Opal functions. The reasons for this are to improve efficiency, and to improve compatibility with other libraries. Backwards compatibility is supported as follows: - The Unix configure option "--disable-ansi-bool" will enable the old "int BOOL" behaviour - The presence of the symbol P_USE_STANDARD_CXX_BOOL will indicate the new ANSI bool is being used, while the presence of P_USE_INTEGER_BOOL will indicate the old "int BOOL" behavior is in effect. - The new type PBoolean is be defined as either "bool" or "int" as required. The plan for migration to the new code will be in two steps: 1. A snapshot of the SVN current development trunk will be created, that does not include the PBoolean changes (PTLib 2.1.1/Opal 3.1.1) 2. We will then merge the PBoolean changes into the SVN head. This will be (PTLib 2.1.2/Opal 3.1.2) We'd like to do this in the next few days so we can move on to other pressing merge issues (yes Hannes - we are desperate to get your changes in! :) Please email opalvoip-devel(a)lists.sourceforge.net if you have any further questions or issues. Craig

1 0

Re: [h323plus] Visual Studio Express 2008
by Simon Horne 20 Nov '07

20 Nov '07

Jan I have CC'd this to the h323plus list. This is great to have Visual Studio 2008 support. If you get a chance send me the compile errors and will see if we can patch ptlib. :) Simon > -----Original Message----- > From: openh323gk-developer-bounces(a)lists.sourceforge.net > [mailto:openh323gk-developer-bounces@lists.sourceforge.net]On Behalf Of > Jan Willamowius > Sent: Wednesday, November 21, 2007 8:03 AM > To: openh323gk-developer(a)lists.sourceforge.net > Subject: [Openh323gk-developer] Visual Studio Express 2008 > > > Hi, > > for all those who want to try the new Express 2008: > I just compiled PWLib 1.12.0, H323Plus (CVS) and GnuGk (CVS) without > any issues. Just follow the instructions for Express 2005 and let 2008 > convert the build project. > > The only problem I ran into was the PWLib detected the TextToSpeech > API, but couldn't compile the PWlib support for it, so I had to > manually disable it. Your milage on this may vary. > > Regards, > Jan > > -- > Jan Willamowius, jan(a)willamowius.de, http://www.gnugk.org/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________________ > > List: Openh323gk-developer(a)lists.sourceforge.net > Archive: > http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk -developer Homepage: http://www.gnugk.org/

2 1

Re: [h323plus] Introducing PBoolean - API change alert!!!
by Jan Willamowius 20 Nov '07

20 Nov '07

Hi, I guess making the change won't be very hard for GnuGk and we've already started using STL wherever possible. The one thing I'm concerend about is to keep backward compatibility with older PWLib releases. Some people use really old OpenH323/PWLib versions to compile GnuGk and would prefer to keep them. Currently we look at the version numbers to see which features are available. So if we can simply define PBoolean back to BOOL for the old releases, I'm fine with the change. If you add config options to change what kind of bool PTLib uses, please give us a config symbol so we can detect what to define PBoolean to. Regards, Jan -- Jan Willamowius, jan(a)willamowius.de, http://www.willamowius.de/

3 3

Improved QoS support in H323plus
by Simon Horne 19 Nov '07

19 Nov '07

To All I have updated QoS support in H323plus. DSCP (Diffserv) is now enabled by default (if compiled with DNS support). Transport QoS is now also negotiated between the parties during the capability exchange with the higher QoS value given precedence over the lower value for both direction media flow. The default values for DSCP are 46 (guaranteed) for audio and 26 (controlled load) for Video. You can change these by calling statics H323AudioCapability::SetDSCPvalue() and H323VideoCapability::SetDSCPvalue() from your application. You can also turn off the feature via a new function H323EndPoint::DisableH245QoS(). Simon No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.0/1137 - Release Date: 2007/11/18 5:15 PM

2 2

More background on changing BOOL to bool
by Craig Southeren 19 Nov '07

19 Nov '07

To all, Here is some background information on the proposed change of BOOL to bool. We're trying to move PTLib closer to the C++ standard, including STL, because that has many advantages. Not only will it reduce the size of the code, and increases compatibility with other libraries, but it will leverage off the enormous investment that other developers have made into the standard libraries and will increase the usefulness of PTLib by making the API less "proprietary" To do this, PTLib will require several changes. None of these will come without pain, but it is my personal opinion that the advantages will outweigh the disadvantages. These changes are: - Change BOOL to bool - Change PString to use std::string in some way - Change PArray to use std::vector, PDictionary to use std::map etc The change from BOOL to bool is probably the biggest change. We're hoping that the rest of the changes can be done transparently, but I think it is inevitable that there will be some API tweaks required. I'd be interested in hearing people's opinions on these thoughts, especially if the general consensus is that it is not worthwhile. Craig ----------------------------------------------------------------------- Craig Southeren Post Increment – VoIP Consulting and Software craigs(a)postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: craig_southeren(a)hotmail.com Mobile: +61 417231046 Jabber: craigs(a)jabber.org "Science is the poetry of reality." Richard Dawkins

3 3

Re: [h323plus] Introducing PBoolean - API change alert!!!
by Simon Horne 18 Nov '07

18 Nov '07

Robert Can you explain exactly in simple english 1. What you have changed. I assume it's changing every BOOL to PBOOLEAN in ptlib? 2. So everyone in every program derived from ptlib/pwlib has to change their program or when they compile against upcoming releases of ptlib their program will no longer function properly. Is that correct? For what benefit? Compile time checks? moving from BOOL to ANSI bool? Though I have always wondered why BOOL was used in place of bool and globally replacing in h323plus is fairly easy however for the community as a whole who have developed complex applications from these libraries it's going to be extremely painful as backward compatibility is broken and worse with C++ virtual they will not even notice it has even occurred until they run the program. Not a very good situation at all. For this reason I STRONGLY STRONGLY recommend you don't make this change. IMHO it is something inherent with pwlib/ptlib and far too painful this late in the game (after 10+ years?) for minimal benefit for everyone involved. But of course, it already has been decided and the community have a week to agree and then it's done. This is what is truely unfortunate. Simon -----Original Message----- From: h323plus-bounces(a)lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com]On Behalf Of Robert Jongbloed Sent: Monday, November 19, 2007 9:31 AM To: Opalvoip-devel(a)lists.sourceforge.net; h323plus(a)lists.packetizer.com Subject: [h323plus] Introducing PBoolean - API change alert!!! If you have written any programs based on PTLib/OpenH323/H323plus/OPAL, please read this, IT'S IMPORTANT!! Adam Butcher from Selex Communications submitted patches a while ago to change BOOL to PBoolean. The reason was so that PBoolean could be defined as the ANSI standard bool type and we get a whole pile of beneficial compile time checks. The process found a couple of places where a function had a BOOL return type but integer (tri-state) values were being returned! Well, Craig and I had thought of this for a while as being a "good thing" to do, but lack of time has always been an issue. Now, as we have been presented with all the hack work, it seems that this is it's time. Of course things are NEVER easy. The change has a nasty API issue that can silently stop user programs from working. It revolves around my #1 pet hate in C++, if you change the signature of a virtual function, overrides silently no longer override the virtual. For example: //------ in the library class OpalXXX { virtual void SomeFunction( PBoolean ); }; //------- in some unchanged dependent code in another application class MyXXX : public OpalXXX { virtual void SomeFunction( BOOL ); }; The function MyXXX::SomeFunction() will not be called as it should be. And the stupid compiler (NONE of the compilers) give any warnings or indication there is an issue. Way back in the preliminary versions of C++ they did have a keyword "override" which would do exactly what we want, error if the base class does not have the function being overridden as virtual. The original designers (Stroustrup et al) took out, for presumably good reasons, though I cannot for the life of me think what! There is even a number proposals, e.g. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2108.html, to put a variants of it back and Microsoft have even done so, http://msdn2.microsoft.com/en-us/library/41w3sh1c.aspx, on their latest compiler. Anyway we have to deal with existing compilers and this problem is really insidious, but we think the gains are worth the pain. And we have provided a work around for people. So, what we need from you guys is please check out the PTLib and OPAL in the branches: https://opalvoip.svn.sourceforge.net/svnroot/opalvoip/ptlib/branches/Bo oleanChange https://opalvoip.svn.sourceforge.net/svnroot/opalvoip/opal/branches/Boo leanChange and compile your programs against it. Now by default it will use the ANSI bool form of PBoolean, so any overrides of PTLib or OPAL functions must be changed to use PBoolean instead of BOOL. For those not using MFC, this is really easy, just do a complete search and replace everywhere of BOOL to PBoolean (or better yet, just bool) and that should do the job. Oh, you might like to search and replace TRUE to true and FALSE to false while you are at it, though you don't HAVE to do that. Now, for those that simply do not wish to make these changes, we have a backward compatibility option: use the --disable-ansi-bool option with configure (both Unix and Win32) and PBoolean is defined as BOOL instead of bool. This should (in theory) be 100% compatible with the previous signatures. So no changes to applications based on PTLib need be made. But we need you guys to CHECK THAT THIS IS OK! We are currently proposing to merge it into the trunk on Monday 26th of November, we are happy to extend that if asked, but will not wait forever, the back merging is really painful! P.S. A random note to developers, the PBoolean is only there for backward compatibility. It is recommended that any NEW functions all just use the bool keyword. Use lowercase true and false too. P.P.S. Sorry about all the shouting ... J Robert Jongbloed OPAL/OpenH323 Architect and Co-founder.

2 1

Introducing PBoolean - API change alert!!!
by Robert Jongbloed 18 Nov '07

18 Nov '07

If you have written any programs based on PTLib/OpenH323/H323plus/OPAL, please read this, IT'S IMPORTANT!! Adam Butcher from Selex Communications submitted patches a while ago to change BOOL to PBoolean. The reason was so that PBoolean could be defined as the ANSI standard bool type and we get a whole pile of beneficial compile time checks. The process found a couple of places where a function had a BOOL return type but integer (tri-state) values were being returned! Well, Craig and I had thought of this for a while as being a "good thing" to do, but lack of time has always been an issue. Now, as we have been presented with all the hack work, it seems that this is it's time. Of course things are NEVER easy. The change has a nasty API issue that can silently stop user programs from working. It revolves around my #1 pet hate in C++, if you change the signature of a virtual function, overrides silently no longer override the virtual. For example: //------ in the library class OpalXXX { virtual void SomeFunction( PBoolean ); }; //------- in some unchanged dependent code in another application class MyXXX : public OpalXXX { virtual void SomeFunction( BOOL ); }; The function MyXXX::SomeFunction() will not be called as it should be. And the stupid compiler (NONE of the compilers) give any warnings or indication there is an issue. Way back in the preliminary versions of C++ they did have a keyword "override" which would do exactly what we want, error if the base class does not have the function being overridden as virtual. The original designers (Stroustrup et al) took out, for presumably good reasons, though I cannot for the life of me think what! There is even a number proposals, e.g. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2108.html, to put a variants of it back and Microsoft have even done so, http://msdn2.microsoft.com/en-us/library/41w3sh1c.aspx, on their latest compiler. Anyway we have to deal with existing compilers and this problem is really insidious, but we think the gains are worth the pain. And we have provided a work around for people. So, what we need from you guys is please check out the PTLib and OPAL in the branches: https://opalvoip.svn.sourceforge.net/svnroot/opalvoip/ptlib/branches/Boolean Change https://opalvoip.svn.sourceforge.net/svnroot/opalvoip/opal/branches/BooleanC hange and compile your programs against it. Now by default it will use the ANSI bool form of PBoolean, so any overrides of PTLib or OPAL functions must be changed to use PBoolean instead of BOOL. For those not using MFC, this is really easy, just do a complete search and replace everywhere of BOOL to PBoolean (or better yet, just bool) and that should do the job. Oh, you might like to search and replace TRUE to true and FALSE to false while you are at it, though you don't HAVE to do that. Now, for those that simply do not wish to make these changes, we have a backward compatibility option: use the --disable-ansi-bool option with configure (both Unix and Win32) and PBoolean is defined as BOOL instead of bool. This should (in theory) be 100% compatible with the previous signatures. So no changes to applications based on PTLib need be made. But we need you guys to CHECK THAT THIS IS OK! We are currently proposing to merge it into the trunk on Monday 26th of November, we are happy to extend that if asked, but will not wait forever, the back merging is really painful! P.S. A random note to developers, the PBoolean is only there for backward compatibility. It is recommended that any NEW functions all just use the bool keyword. Use lowercase true and false too. P.P.S. Sorry about all the shouting ... J Robert Jongbloed OPAL/OpenH323 Architect and Co-founder.

1 0

OpenAM now available in H323plus CVS
by Simon Horne 18 Nov '07

18 Nov '07

Guys Just a quick note that openAM has now been updated and available in the h323plus CVS. I would like to thank Jan Willamwius for the contribution and hopefully in the not too distant future we can tweak it to provide video voicemail for GnuGk. :-) Simon ----------------------- Simon Horne Principal Maintainer h323plus library www.h323plus.org h323:s.horne@packetizer.com

1 0