- h323plus - lists.packetizer.com

General WorkPlan for H323plus
by Simon Horne 25 Dec '07

25 Dec '07

Guys As you are aware the focus of H323plus is about the plus (new features/services) and less about architecture redesign allowing existing applications to be upgraded/improved without requiring wholesale code changes yet still have access to the latest and greatest features like H.239, H.350 etc. With the exception of the upcoming upgrade to PTLib 2.x we hope to continue in that vain. As most of you are aware I also have commitments to GnuGk and PacPhone so I am spread thin at the best of times but at the moment it is quite accute. I have 5 documents to be presented to the ITU meeting in Korea in January as well as other work which I hope to make an announcement on in the new year. Here are some the current work items. Migration to ptlib 2.x (ETA January) which has been previously discussed. Addition of GnuGK NAT Traversal. (ETA 1 week) This will allow the H323plus based applications to natively traverse NATs using GnuGk. The code has been tried and tested and working with PacPhone for over a year, I have just tidy up it and added better documentation. Note this is not the ITU standard method which is H.460.18/19. H.235.6. (ETA January) This is the defacto standard for H.323 Media encryption with support with polycom PVX, Tandberg and Codian. Thanks heaps to bian xuegong for helping sort it out. There is some new work at the ITU upgrading the encryption from AES128 to AES256 so hopefully that will be included. File Transfer. (ETA January) This is really cool. This allows the transfer of files via TFTP encaptulated in RTP frames allowing lightweight data transfer without the need for the T.120 framework overhead. Since it uses RTP it can use existing NAT Traversal mechanisms like GnuGk to traverse NATs. I am putting forward a submission to the ITU on this so watch out for that. H.460.presence (ETA Feburary) I have a submission to the ITU for scalable presence system I have been working on for sometime. I hope to have this finalised and committed by Feb. H.460.MMS (ETA ?) Multimedia Messaging. This is also up for submission to the ITU. This is a companion and extension on H.460.tm (Text Messaging) which is in the extensions directory of the CVS. There is an exciting year ahead for h323plus. Simon

1 0

H323plus and ptlib 2.x?
by Adam Williamson 25 Dec '07

25 Dec '07

So, second question :) I've now got h323plus built and in the distro. But it doesn't build against ptlib 2.x, only ptlib / pwlib 1.12. This means I have a fairly ugly mess of packages in Mandriva right now - separate packages for ptlib 2.x and pwlib 1.12 which conflict in lots of fun ways. I need both as current Opal wants ptlib 2.x, but h323plus wants pwlib / ptlib 1.12... I guess h323plus will be migrated to build okay against ptlib 2.x, right? Is there an ETA on this? Thanks! -- adamw

3 3

Trouble building h323plus with GCC 4.2.2
by Adam Williamson 25 Dec '07

25 Dec '07

Hi, there. I'm looking at migrating Mandriva from openh323 to h323plus, but I'm getting several errors trying to build it. Building against pwlib 1.12.0. The first set of errors is as follows: g++ -fPIC -D_REENTRANT -fno-exceptions -Wall -fPIC -DPIC -DNDEBUG -DPTRACING -I/home/adamw/rpm/BUILD/h323plus/include -I/usr/share/pwlib//include -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fexceptions -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables -DLDAP_DEPRECATED -c /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx -o /home/adamw/rpm/BUILD/h323plus/lib/obj_linux_x86_r/h350.o /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:69:1: error: pasting "(" and "commObject" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:69:1: error: pasting "(" and "commObject" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:69:1: error: pasting ")" and "commObject" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:69:1: error: pasting "(" and "commObject" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:69:1: error: pasting "commObject" and ")" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:69:1: error: pasting "<" and "commObject" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:69:1: error: pasting ">" and "commObject" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:69:1: error: pasting "(" and "commObject" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:69:1: error: pasting "&" and "commObject" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:69:1: error: pasting "(" and "commObject" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:80:1: error: pasting "(" and "commURIObject" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:80:1: error: pasting "(" and "commURIObject" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:80:1: error: pasting ")" and "commURIObject" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:80:1: error: pasting "(" and "commURIObject" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:80:1: error: pasting "commURIObject" and ")" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:80:1: error: pasting "<" and "commURIObject" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:80:1: error: pasting ">" and "commURIObject" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:80:1: error: pasting "(" and "commURIObject" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:80:1: error: pasting "&" and "commURIObject" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:80:1: error: pasting "(" and "commURIObject" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:101:1: error: pasting "(" and "H323Identity" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:101:1: error: pasting "(" and "H323Identity" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:101:1: error: pasting ")" and "H323Identity" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:101:1: error: pasting "(" and "H323Identity" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:101:1: error: pasting "H323Identity" and ")" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:101:1: error: pasting "<" and "H323Identity" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:101:1: error: pasting ">" and "H323Identity" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:101:1: error: pasting "(" and "H323Identity" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:101:1: error: pasting "&" and "H323Identity" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:101:1: error: pasting "(" and "H323Identity" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:114:1: error: pasting "(" and "H235Identity" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:114:1: error: pasting "(" and "H235Identity" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:114:1: error: pasting ")" and "H235Identity" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:114:1: error: pasting "(" and "H235Identity" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:114:1: error: pasting "H235Identity" and ")" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:114:1: error: pasting "<" and "H235Identity" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:114:1: error: pasting ">" and "H235Identity" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:114:1: error: pasting "(" and "H235Identity" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:114:1: error: pasting "&" and "H235Identity" does not give a valid preprocessing token /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:114:1: error: pasting "(" and "H235Identity" does not give a valid preprocessing token With the help of one of our contributors, we fixed that one with the following patch to pwlib: -------------------- --- ptlib_v1_12_0/include/ptclib/pldap.h 2007-10-18 23:22:38.000000000 -0700 +++ ptlib_v1_12_0/include/ptclib/pldap.h.new 2007-12-22 04:56:25.000000000 -0800 @@ -597,9 +597,9 @@ }; #define LDAP_Schema(name) \ -static LDAPPluginServiceDescriptor<##name##_schema> ##name##_schema_descriptor; \ -PCREATE_PLUGIN(##name##_schema, PLDAPSchema, &##name##_schema_descriptor); \ -PWLIB_STATIC_LOAD_PLUGIN(##name##_schema, PLDAPSchema); \ +static LDAPPluginServiceDescriptor<name##_schema> name##_schema_descriptor; \ +PCREATE_PLUGIN(name##_schema, PLDAPSchema, &name##_schema_descriptor); \ +PWLIB_STATIC_LOAD_PLUGIN(name##_schema, PLDAPSchema); \ //////////////////////////////////////////////////////////////////////////////////////////// ----------------- But then we get some further errors in the same macros: -------------------- /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx: In function 'void PWLibPlugin_TriggerRegister(PPluginManager*)': /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:80: error: redefinition of 'void PWLibPlugin_TriggerRegister(PPluginManager*)' /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:69: error: 'void PWLibPlugin_TriggerRegister(PPluginManager*)' previously defined here /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx: In function 'unsigned int PWLibPlugin_GetAPIVersion()': /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:80: error: redefinition of 'unsigned int PWLibPlugin_GetAPIVersion()' /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:69: error: 'unsigned int PWLibPlugin_GetAPIVersion()' previously defined here /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx: In function 'void PWLibPlugin_TriggerRegister(PPluginManager*)': /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:101: error: redefinition of 'void PWLibPlugin_TriggerRegister(PPluginManager*)' /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:69: error: 'void PWLibPlugin_TriggerRegister(PPluginManager*)' previously defined here /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx: In function 'unsigned int PWLibPlugin_GetAPIVersion()': /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:101: error: redefinition of 'unsigned int PWLibPlugin_GetAPIVersion()' /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:69: error: 'unsigned int PWLibPlugin_GetAPIVersion()' previously defined here /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx: In function 'void PWLibPlugin_TriggerRegister(PPluginManager*)': /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:114: error: redefinition of 'void PWLibPlugin_TriggerRegister(PPluginManager*)' /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:69: error: 'void PWLibPlugin_TriggerRegister(PPluginManager*)' previously defined here /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx: In function 'unsigned int PWLibPlugin_GetAPIVersion()': /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:114: error: redefinition of 'unsigned int PWLibPlugin_GetAPIVersion()' /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:69: error: 'unsigned int PWLibPlugin_GetAPIVersion()' previously defined here /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx: In member function 'BOOL H350_Session::PostNew(const PString&, const std::list<PLDAPSchema, std::allocator<PLDAPSchema> >&)': /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:226: error: 'class PLDAPSession::ModAttrib::Operation' is not a class or namespace /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx: In member function 'BOOL H350_Session::PostUpdate(const PString&, const std::list<PLDAPSchema, std::allocator<PLDAPSchema> >&)': /home/adamw/rpm/BUILD/h323plus/src/h350/h350.cxx:240: error: 'class PLDAPSession::ModAttrib::Operation' is not a class or namespace --------- which we've not yet been able to fix. Does anyone have a fix for this? Thanks. -- adamw

2 2

t38modem connecting to innovaphone IP400
by Marcus Robichon 20 Dec '07

20 Dec '07

Hi all, hope this list he correct list to ask fort he t38modem. We need the following due to virtualization of hardware: We use Hylafax as Fax solution. We try to implement t38modem to talk via H323 (T38) protocol to a innovaphone IP400 router. First we implemented the OpenH323 solution. We can connect to the innovaphone router and we can see that the router is calling. But after some seconds we get a I/O error back. Then we tried to upgrade the whole project to h323plus and the new release of t38modem (0.8.4). We tried the same but we get the same error message. Did anybody have a solution for this? Attached you get a logfile to see some "blabla" of t38modem. I cannot come along why this does not work. This is the string we are using to connect to the gatekeeper on innovaphone: t38modem -p ttyp0 -tttttt -g 172.16.25.19 -u HYLA -i 172.16.25.134 --redundancy H -P T.38-UDP --h245tunneldisable Have a nice day. Marcus Robichon

1 0

Video Codec Plugin Tutorial
by Abhishek Rohilla 19 Dec '07

19 Dec '07

H323Plus has now supported all the video codec as plugins. Can someone help me as to how to plug in video codecs into H323Plus. Earlier for H.263 we had to just add the capabilities as the codec class was there in the code. But now that thing does not work with H323Plus.

2 1

回复： H.235 AES problem continue
by Bian 11 Dec '07

11 Dec '07

Simon, The diffie-hellman is used to exchange shared secret which is then used to encrypt sessionKey. The sessionKey is used to encrypt media then. The secret shared (the key) I have got from standard key exchange procedure is equal to "H.235 encryption check code" displayed by PVX UI. It's difficult to think polycom using private mechanism. That means polycom cannot interoperate with other endpoints in standard way. The sharedSecret field within the H235Key structure uses the following fields: • algorithmOID: set to "X", "X1" for the 56-bit RC2-compatible, set to "Y", "Y1" for 56-bit DES or set to "Z", "Z1" for 168-bit Triple-DES or set to "Z3" for 128-bit AES. NOTE 1 – The session key encryption algorithm is the same as the negotiated media encryption algorithm. ( here is the answer? ) Each entity shall take appropriate least significant bits from the common shared Diffie-Hellman secret for the key encryption key (master key); i.e., the 56 least significant bits of the Diffie-Hellman secret for OID "X", OID "X1", OID "Y1" or OID "Y" and the 168 least significant bits of the Diffie-Hellman secret for OID "Z", OID "Z1" or OID "Z2" and the 128 least significant bits of the Diffie-Hellman secret for OID "Z3" or OID "Z2", see also Table 6. ( here is the answer? ) bian ----- 原始邮件 ---- 发件人： Simon Horne <s.horne(a)packetizer.com> 收件人： Bian <bianxg(a)yahoo.cn>; H323plus <h323plus(a)lists.packetizer.com> 已发送： 2007/12/11(周二), 下午8:58:15 主题： RE: [h323plus] H.235 AES problem continue Bian Polycom is not using H.235.6 key exchange and most certainly not using diffie-hellman. It is using symmetric key AES encryption which is AFAIK is NOT standard. The key material is encrypted using a private mechanism. Let me explain what this is > algorithmOID = 2.16.840.1.101.3.4.1.2 > // <"OID_Z3" which means using AES 128 CBC mode > paramS = { > // means IV is 0 > } > encryptedSessionKey = 16 octets { > c7 36 02 5c b7 ae b0 cc 97 c8 af bb d5 72 0f 19 AlgorithmOID has nothing to do with the encryptedSessionKey. The AlgorithmOID notifies the remote what cipher to use DES 3DES or AES. This is standard identifier. Basically this tells the remote to use AES. encryptionSessionKey is encrypted using an non-public known secret method. The only way you are going to decrypt this is if you know how the key is encrypted. AFAIK only polycom can provide you that information. It is not public knowledge. Simon ___________________________________________________________ 天生购物狂，狂抢购物券，你还等什么！ http://cn.mail.yahoo.com/promo/taobao20/index.php

1 0

H.235 AES problem continue
by Bian 11 Dec '07

11 Dec '07

Hi I have finished call procedure of H.235 and get same H.235 encryption check code with PVX. (See attach) This is the shared secret(PVX only display 8 bytes long, whereas the h.235.6 indicate 16 bytes long see below). As slave, local endpoint receive OpenLogicalChannel rerquest, which has a parameter H235_V3KeySyncMaterial. The param content is as below: { algorithmOID = 2.16.840.1.101.3.4.1.2 // <"OID_Z3" which means using AES 128 CBC mode paramS = { // means IV is 0 } encryptedSessionKey = 16 octets { c7 36 02 5c b7 ae b0 cc 97 c8 af bb d5 72 0f 19 .6.\.........r.. } } Then local endpoint begin to decrypt sessionKey from encryptedSessionKey using shared secret. But decryption is failed. Can anyone help to analyse where is the wrong. The below is piece of code decrypting sessionKey (using openssl-0.9.8g) ret = EVP_DecryptInit(&ctx, EVP_aes_128_cbc(), NULL, NULL); PAssert(ret, PLogicError); ret = EVP_CIPHER_CTX_set_key_length(&ctx, 16); PAssert(ret, PLogicError); ret = EVP_DecryptInit(&ctx, EVP_aes_128_cbc(), key, NULL); // IV is null here . key is same as PVX's H.235 encryption check code (PVX only display 8 bytes) PAssert(ret, PLogicError); ret = EVP_DecryptUpdate(&ctx, buffer, &outl, (unsigned char *)in.GetPointer(), 16);// but the "outl" returned is 0 which shall be 16 here I think. len += outl; ret = EVP_DecryptFinal(&ctx, buffer+len, &outl); // return 0 here, means error is found (Each entity shall take appropriate least significant bits from the common shared Diffie-Hellman secret for the key encryption key (master key); i.e., the 56 least significant bits of the Diffie-Hellman secret for OID "X", OID "X1", OID "Y1" or OID "Y" and the 168 least significant bits of the Diffie-Hellman secret for OID "Z", OID "Z1" or OID "Z2" and the 128 least significant bits of the Diffie-Hellman secret for OID "Z3" or OID "Z2", see also Table 6.) Bian ___________________________________________________________ 天生购物狂，狂抢购物券，你还等什么！ http://cn.mail.yahoo.com/promo/taobao20/index.php

2 1

Re: [h323plus] Errors while compliling PTLIB 1.12.0
by JF NP 04 Dec '07

04 Dec '07

Thank you for your fast response, Simon. I put that path, following PWLIB build instructions, but the problem stills. Any ideas?? ----- Mensaje original ---- De: Simon Horne <s.horne(a)packetizer.com> Para: JF NP <jfnp090274(a)yahoo.es> CC: H323plus <h323plus(a)lists.packetizer.com> Enviado: lunes, 3 de diciembre, 2007 22:28:17 Asunto: RE: [h323plus] Errors while compliling PTLIB 1.12.0 DIV { MARGIN:0px;} Make sure you put the pwlib/include path in the VC++ Directories include directory. In VS 2003 Menu tools > options > under projects in the options window > VC++ Directories. Simon -----Original Message----- From: h323plus-bounces(a)lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com]On Behalf Of JF NP Sent: Tuesday, December 04, 2007 2:15 AM To: h323plus(a)lists.packetizer.com Subject: [h323plus] Errors while compliling PTLIB 1.12.0 Hi, When I try to compile PTLib (1.12.0) on a computer running Windows XP using VS 2003, I get the following errors (see below, after system configuration), can anybody help me?? This is what configure reports: Located Direct Sound Support at c:\archivos de programa\microsoft directx sdk (june 2007)\ Located DNS Resolver at c:\archivos de programa\microsoft visual studio .net 2003\vc7\platformsdk\ Located IPv6 Support at c:\archivos de programa\microsoft visual studio .net 2003\vc7\platformsdk\include\ Located QoS Support at c:\archivos de programa\microsoft visual studio .net 2003\vc7\platformsdk\include\ Located ODBC support at c:\archivos de programa\microsoft visual studio .net 2003\vc7\platformsdk\include\ Searching D:\ Located Open SSL at d:\desarrollo\veediaplatform\externaldependencies\openssl-0.9.7e\ Located Open SSL AES at d:\desarrollo\veediaplatform\externaldependencies\openssl-0.9.7e\ Features: Version enabled Byte Order enabled Semaphore Support enabled Plugin Support enabled DNS Resolver enabled Cyrus SASL DISABLED Open LDAP DISABLED due to absence of feature sasl Open SSL enabled Open SSL AES enabled Windows Open SSL DISABLED due to presence of feature openssl Windows Open SSL AES DISABLED due to absence of feature winssl Expat XML DISABLED Windows Expat XML DISABLED VXML DISABLED due to absence of feature expat|winexpat Jabber DISABLED due to absence of feature expat|winexpat XMLRPC DISABLED due to absence of feature expat|winexpat SOAP DISABLED due to absence of feature expat|winexpat Speech API DISABLED IPv6 Support enabled QoS Support enabled Simple DirectMedia Layer DISABLED Video Support enabled ASN Support enabled STUN Support enabled pipe channel Support enabled DTMF encoding/decoding support enabled WAV file support enabled SOCKS protocol support enabled FTP protocol support enabled SNMP protocol support enabled Telnet protocol support enabled remote connection support enabled Serial Support enabled POP3/SMTP Support enabled HTTP Support enabled HTTP service Support enabled Config file protocol support enabled Socket aggregation support enabled Video file support enabled Sound support enabled Direct Sound Support enabled ODBC support enabled Errors: ..\..\..\include\ptlib\pprocess.h(819) : error C2143: syntax error : missing ';' before '<' ..\..\..\include\ptlib\plugin.h(81) : error C2516: 'PFactory' : is not a legal base class ..\..\..\include\ptlib\pprocess.h(819) : see declaration of 'PFactory' ..\..\..\include\ptlib\plugin.h(115) : see reference to class template instantiation 'PDevicePluginFactory<_Abstract_T,_Key_T>' being compiled ..\..\..\include\ptlib\plugin.h(81) : error C2143: syntax error : missing ',' before '<' ..\..\..\include\ptlib\plugin.h(84) : error C2516: 'PFactory' : is not a legal base class ..\..\..\include\ptlib\pprocess.h(819) : see declaration of 'PFactory' ..\..\..\include\ptlib\plugin.h(84) : see reference to class template instantiation 'PDevicePluginFactory<_Abstract_T,_Key_T>::Worker' being compiled ..\..\..\include\ptlib\plugin.h(84) : error C2143: syntax error : missing ',' before '<' ..\..\..\include\ptlib\plugin.h(84) : error C2039: 'WorkerBase' : is not a member of 'operator``global namespace''' ..\..\..\include\ptlib\pfactory.h(475) : error C2904: 'PFactory' : name already used for a template in the current scope ..\..\..\include\ptlib\pprocess.h(819) : see declaration of 'PFactory' ..\..\..\include\ptlib\pfactory.h(475) : error C2920: redefinition : 'PFactory' : template class has already been declared as 'typedef int PFactory' ..\..\..\include\ptlib\pfactory.h(475) : see declaration of 'PFactory' ..\..\..\include\ptlib\pprocess.h(819) : see declaration of 'PFactory' ¿Chef por primera vez? - Sé un mejor Cocinillas. Entra en Yahoo! Respuestas. ______________________________________________ ¿Chef por primera vez? Sé un mejor Cocinillas. http://es.answers.yahoo.com/info/welcome

1 0

Automated answering machine for H.323 and SIP
by Craig Southeren 03 Dec '07

03 Dec '07

To all, A new automated test tool has been deployed for both H.323 and SIP users. We have made available different numbers that will provide different functions, such as the server time, your IP address, and echo test, in either SIP or H.323, and in a wide variety of codecs (G.711, Speex, ILBC etc) Numbers are available for SRV-enabled and non-SRV-enabled clients, and for with both numeric and text IDs. The numbers are all of the form: prot:dest@host where: prot = sip or h323 dest = time, addr, echo, tone, 2337, 8463 8063 or 3246 host = opalvoip.net (for SRV-enabled clients) or sip.opalvoip.net or h323.opalvoip.net the destinations are: time or 8463 announce the current server time addr or 2337 announce the clients (your) address tone or 8063 play a three element tone echo or 3246 enter an echo test For example, the destination h323:3246@opalvoip.net is a H.323 based echo test for a non-SRV client BTW: if you are wondering where the numbers come from, look for how to spell "time", "addr", "echo" and "tone" on a standard keypad! All this information is also in the Opal Wiki at: http://www.opalvoip.org/wiki/index.php?n=Main.AnsweringMachine 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 0

回复：回复：回复： Does H323plus support H.235
by Bian 03 Dec '07

03 Dec '07

See 8.6/H.235.6 The sharedSecret field within the H235Key structure uses the following fields: • algorithmOID: set to "X", "X1" for the 56-bit RC2-compatible, set to "Y", "Y1" for 56-bit DES or set to "Z", "Z1" for 168-bit Triple-DES or set to "Z3" for 128-bit AES. NOTE 1 – The session key encryption algorithm is the same as the negotiated media encryption algorithm. The shared secret is not used directly to encrypt the key exchange material to generate the cipher for media encryption, but used to enctypt the session key. Session key is then used to encrypt media. So, I think we can connect PVX or codian using AES through a standard way. However, Need some work to test this thought. Bian ----- 原始邮件 ---- 发件人： Simon Horne <s.horne(a)packetizer.com> 收件人： Bian <bianxg(a)yahoo.cn>; H323plus <h323plus(a)lists.packetizer.com> 已发送： 2007/12/1(周六), 下午8:16:20 主题： RE: [h323plus] 回复：回复： Does H323plus support H.235 The shared secret is used to encrypt the key exchange material to generate the cipher for media encryption. If the shared secret was public knowledge then anyone can intercept the key exchange and generate a key to decrypt the media. So unless Polycom or Codian wish to share that proprietry secret there is no way to connect via AES. Simon > -----Original Message----- > From: h323plus-bounces(a)lists.packetizer.com > [mailto:h323plus-bounces@lists.packetizer.com]On Behalf Of Bian > Sent: Saturday, December 01, 2007 11:19 AM > To: H323plus > Subject: [h323plus] 回复：回复： Does H323plus support H.235 > > > Simon > > I think PVX's key exchange mechanism is in a standard way. PVX > and Codian MCU can connect using AES. > > But I don't know how the shared secret is used to produce the session key. > > > Bian > > > -----Original Message----- > >Bian > > >No PacPhone AES uses a different key exchange mechanism to PVX. > Polycom uses > >a proprietry method. They should still connect unencrypted. > > >Simon > > > -----Original Message----- > > From: Bian [mailto:bianxg@yahoo.cn] > > Sent: Wednesday, November 28, 2007 12:35 PM > > To: Simon Horne > > Subject: 回复： [h323plus] Does H323plus support H.235 > > > > > > Simon > > > > I test PccPhone with PVX, but the AES is not opened. Does > > PacPhone can interoperate with PVX using AES? > > > > > > Bian > > > > > ___________________________________________________________ > 进入雅虎游戏嘉年华，赢取液晶显示器！ > http://cn.mail.yahoo.com/promo/carnival07/ ___________________________________________________________ 进入雅虎游戏嘉年华，赢取液晶显示器！ http://cn.mail.yahoo.com/promo/carnival07/

3 2

Errors while compliling PTLIB 1.12.0
by JF NP 03 Dec '07

03 Dec '07

Hi, When I try to compile PTLib (1.12.0) on a computer running Windows XP using VS 2003, I get the following errors (see below, after system configuration), can anybody help me?? This is what configure reports: Located Direct Sound Support at c:\archivos de programa\microsoft directx sdk (june 2007)\ Located DNS Resolver at c:\archivos de programa\microsoft visual studio .net 2003\vc7\platformsdk\ Located IPv6 Support at c:\archivos de programa\microsoft visual studio .net 2003\vc7\platformsdk\include\ Located QoS Support at c:\archivos de programa\microsoft visual studio .net 2003\vc7\platformsdk\include\ Located ODBC support at c:\archivos de programa\microsoft visual studio .net 2003\vc7\platformsdk\include\ Searching D:\ Located Open SSL at d:\desarrollo\veediaplatform\externaldependencies\openssl-0.9.7e\ Located Open SSL AES at d:\desarrollo\veediaplatform\externaldependencies\openssl-0.9.7e\ Features: Version enabled Byte Order enabled Semaphore Support enabled Plugin Support enabled DNS Resolver enabled Cyrus SASL DISABLED Open LDAP DISABLED due to absence of feature sasl Open SSL enabled Open SSL AES enabled Windows Open SSL DISABLED due to presence of feature openssl Windows Open SSL AES DISABLED due to absence of feature winssl Expat XML DISABLED Windows Expat XML DISABLED VXML DISABLED due to absence of feature expat|winexpat Jabber DISABLED due to absence of feature expat|winexpat XMLRPC DISABLED due to absence of feature expat|winexpat SOAP DISABLED due to absence of feature expat|winexpat Speech API DISABLED IPv6 Support enabled QoS Support enabled Simple DirectMedia Layer DISABLED Video Support enabled ASN Support enabled STUN Support enabled pipe channel Support enabled DTMF encoding/decoding support enabled WAV file support enabled SOCKS protocol support enabled FTP protocol support enabled SNMP protocol support enabled Telnet protocol support enabled remote connection support enabled Serial Support enabled POP3/SMTP Support enabled HTTP Support enabled HTTP service Support enabled Config file protocol support enabled Socket aggregation support enabled Video file support enabled Sound support enabled Direct Sound Support enabled ODBC support enabled Errors: ..\..\..\include\ptlib\pprocess.h(819) : error C2143: syntax error : missing ';' before '<' ..\..\..\include\ptlib\plugin.h(81) : error C2516: 'PFactory' : is not a legal base class ..\..\..\include\ptlib\pprocess.h(819) : see declaration of 'PFactory' ..\..\..\include\ptlib\plugin.h(115) : see reference to class template instantiation 'PDevicePluginFactory<_Abstract_T,_Key_T>' being compiled ..\..\..\include\ptlib\plugin.h(81) : error C2143: syntax error : missing ',' before '<' ..\..\..\include\ptlib\plugin.h(84) : error C2516: 'PFactory' : is not a legal base class ..\..\..\include\ptlib\pprocess.h(819) : see declaration of 'PFactory' ..\..\..\include\ptlib\plugin.h(84) : see reference to class template instantiation 'PDevicePluginFactory<_Abstract_T,_Key_T>::Worker' being compiled ..\..\..\include\ptlib\plugin.h(84) : error C2143: syntax error : missing ',' before '<' ..\..\..\include\ptlib\plugin.h(84) : error C2039: 'WorkerBase' : is not a member of 'operator``global namespace''' ..\..\..\include\ptlib\pfactory.h(475) : error C2904: 'PFactory' : name already used for a template in the current scope ..\..\..\include\ptlib\pprocess.h(819) : see declaration of 'PFactory' ..\..\..\include\ptlib\pfactory.h(475) : error C2920: redefinition : 'PFactory' : template class has already been declared as 'typedef int PFactory' ..\..\..\include\ptlib\pfactory.h(475) : see declaration of 'PFactory' ..\..\..\include\ptlib\pprocess.h(819) : see declaration of 'PFactory' ______________________________________________ ¿Chef por primera vez? Sé un mejor Cocinillas. http://es.answers.yahoo.com/info/welcome

2 1

PTLib change to ANSI bool
by Craig Southeren 03 Dec '07

03 Dec '07

To all, As previously announced, the trunk revision of PTLib has been changed to use ANSI bool instead of int BOOL. A summary of the changes, and the reasons and ramifications of them, can found in the Opal wiki at: http://www.opalvoip.org/wiki/index.php?n=Main.BoolChanges 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 0

回复：回复： Does H323plus support H.235
by Bian 01 Dec '07

01 Dec '07

Simon I think PVX's key exchange mechanism is in a standard way. PVX and Codian MCU can connect using AES. But I don't know how the shared secret is used to produce the session key. Bian > -----Original Message----- >Bian >No PacPhone AES uses a different key exchange mechanism to PVX. Polycom uses >a proprietry method. They should still connect unencrypted. >Simon > -----Original Message----- > From: Bian [mailto:bianxg@yahoo.cn] > Sent: Wednesday, November 28, 2007 12:35 PM > To: Simon Horne > Subject: 回复： [h323plus] Does H323plus support H.235 > > > Simon > > I test PccPhone with PVX, but the AES is not opened. Does > PacPhone can interoperate with PVX using AES? > > > Bian > ___________________________________________________________ 进入雅虎游戏嘉年华，赢取液晶显示器！ http://cn.mail.yahoo.com/promo/carnival07/

2 1

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

Question about interoperability of asterisk and GnuGk
by Giulio Gaio 15 Nov '07

15 Nov '07

Hi, I wonder if is it possible to register Asterisk as an endpoint to openh323 gatekeeper (GnuGk) because i want to merge the feature of an PBX ( asterisk ) in a h323 zone. More precisely, I'm working around an heterogeneous network (it' s a campus' network) in witch to an h323 MCU endpoint had to have the capability to be connected in both: - external PSTN via Cisco Gw users, - internal h323 users registered to GnuGK - user handled by an asterisk PBX. (You can imagine that theese are users from a minor building of the faculty that don't share the LAN of the main building). --- but this point isn't yet clear If some one can help me (Can asterisk register to GnuGK in some way), or tell me this is impossible, Thank you very much. Giulio ___________________________________ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html

5 5

Re: [h323plus] [Opalvoip-devel] Custom Video Frame Size
by Simon Horne 14 Nov '07

14 Nov '07

Robert Firstly I would like to thankyou for the fantastic work you did on upgrading the initial Video Plugin work on the openH323_plugins branch. On to this discussion. I asked a specific question on the removal of the frame size constraints in the encoder of the plugin codec. Now I don't want to break anything so from your indepth response about YUV files and SIP exchange example. I will assume its important so I will just leave it as it is for Opal. :-) Regards Simon -----Original Message----- From: h323plus-bounces(a)lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com]On Behalf Of Robert Jongbloed Sent: Wednesday, 7 November 2007 2:15 PM To: Opalvoip-devel(a)lists.sourceforge.net Cc: 'H323plus' Subject: Re: [h323plus] [Opalvoip-devel] Custom Video Frame Size > -----Original Message----- > From: Simon Horne [mailto:s.horne@packetizer.com] .... > Getting back to the initial question. I want to move forward with > H.239 > support in h323plus so can I remove the fixed frame size constraints > from > the video plugins so the project can move forward or if that's not > recommended then, as I don't want to have different versions of the > video > plugins that break interoperability, can I put in a compiler > directive to > get us out of a pickle? Once these opal architectural glitches are > resolved > then the directive can be removed. I am confused, the underlying system in OPAL has never really had any "fixed size" constraints. There are two OpalMediaOptions for width and height and they can be any value. Now come CODECS can only do fixed sizes, eg H.261, and that was part of the complexity Matthias and I were struggling with. > I really am confused on the codec issues, and the discrete video > sizes with > H.261/H.263 and the generic capabilities etc. The way this is done in > H323plus is to detect the capabilities of the video device at > application > startup via the changes I made in the ptlib videodevice factory which > allows > the device capability list to be exposed without instantaneousing the > device. You use the device capabilities list to determine the maximum > frame > size available for the device so in this way you can detect and > support HD > webcams etc. There is a H323Endpoint function that then goes through > and > removes all the capabilities unsupported for that particular webcam. > Easy! If I am reading this right, you are using the capabilities of the camera, which is used for transmit channels, to determine the H.323 capabilities which controls the RECEIVE channels. Surely the capability should use the VideoOutputDevice? Or is this for transmitVideo capabilities only? Also, but what happens if you have a camera that only reports being able to do 320x240? Not sure this happens much anymore, but older cameras certainly used to. Again, if I am reading what you said right, you would not get H.261 or H.263 at all as they can't do that resolution. > On the OpenVideoChannel function callback the user can then set the > frame > size and fps on the wire. This sets the header height/width fields of > the > YUV420 frame which then goes back into the plugin codec to resize the > codec. > This is how it used to work in OpenH323 and it works just fine. The > problem > you refer to is, I guess, an open Opal issue perhaps?. Given recent events I would be VERY careful about gibes like this. Here is the problem as I see it, library neutral ... Leaving out for the moment the added complexity of requiring symmetric codecs, the receive and transmit video streams are completely independent. Let's start with the receiver; there are three entities at work: Video output device capabilities User/Application preferences Codec fundamentals As a rule most output devices can do any resolution/frame rate, however it is possible with the YUVFile driver to indicate that it MUST be a size, e.g. using the filename "fred_qcif.yuv". The User/Application may also have restrictions, most common is for PDA's where the screen size is such that you want to prevent 4CIF etc. The Codec fundamentals are the most complicated as they may just be a maximum (via profile/level for H.264/MPEG4 and CustomPictureFormat for H.263+) or a set of discrete values as required by H.261 and H.263. The presented capabilities sent to the remote must be derived from the above. I am not presenting a solution yet, just trying to state the problem in as complete a form as possible. For the transmit side we have four entities: Video input device capabilities User/Application preferences Codec fundamentals Remote capabilities So, when selecting our specific video parameters we want to try and get as close to the user preference as possible given the constraints indicated by the other three entities. One more random point: the Codec fundamentals are only known by the plug-in. So, the result of a long discussion with Matthias (and others, but Matthias was the main person) we came up with a first cut solution. To simplify matters an assumption that the video devices can be told to go to any resolution is made. As we have the PColourConverter functionality which (mostly) can do scale/crop as it converts, I think that is fair. Then we introduce the concept of "normalised" OpalMediaOptions and "custom" OpalMediaOptions. The normalised options are things like min/max width/height and the custom options are things like profile/level, or "QCIF MPI". Then two functions are to be added to the plug in to set the options in an instance from normalised to custom, and back from custom to normalised options. In the process the plug-in can also apply any other rules it might have, such as discrete sizes. And here is the sequence that I am stealing from the other thread describing how all the OpalMediaOptions get tweaked as they pass through the system: OK, nothing better than a concrete example: Media format on start up from a H.263 plug-in: Max Frame Width = 1408 Max Frame Height = 1152 Min Frame Width = 144 Min Frame Height = 96 Frame Width = 352 Frame Height = 288 Max Bit Rate = 384000 Target Bit Rate = 384000 Frame Time = 3000 SQCIF MPI = 1 QCIF MPI = 1 CIF MPI = 2 4CIF MPI = 3 16CIF MPI = 4 Annex D = 1 Then the user alters the following: Max Frame Width = 640 Max Frame Height = 480 Frame Width = 320 Frame Height = 240 Max Bit Rate = 128000 Frame Time = 6000 Then just before making a call the above, after user adjustment, is sent to the plug-in "from_normalised_options" function, the plug-in returns: Max Frame Width = 352 Max Frame Height = 288 Min Frame Width = 144 Min Frame Height = 96 Frame Width = 176 Frame Height = 144 Max Bit Rate = 128000 Target Bit Rate = 128000 Frame Time = 6000 SQCIF MPI = 2 QCIF MPI = 2 CIF MPI = 2 4CIF MPI = 5 16CIF MPI = 5 Annex D = 1 Note that as this particular H.263 implementation cannot do custom frame sizes, so all the frame sizes are adjusted appropriately. Some MPI's are set to an illegally large value (required for merging to work) and the new frame rate has made the MPI's that are left change upward. This is encoded to: m=video 5002 RTP/AVP 34 a=rtpmap:34 h263/90000 a=fmtp:34 CIF=2;QCIF=2;SQCIF=2;D=1 The remote replies: m=video 5002 RTP/AVP 34 a=rtpmap:34 h263/90000 a=fmtp:34 CIF=3;4CIF=3 I deliberately tried to be a "rude" UA and return a frame size that was never offered to make sure it all works. OPAL then constructs the following from the SDP: Max Frame Width = 640 Max Frame Height = 480 Min Frame Width = 144 Min Frame Height = 96 Frame Width = 320 Frame Height = 240 Max Bit Rate = 128000 Target Bit Rate = 128000 Frame Time = 6000 SQCIF MPI = 5 QCIF MPI = 5 CIF MPI = 3 4CIF MPI = 3 16CIF MPI = 5 Annex D = 0 Many of the above values are irrelevant at this stage and just inherited from the master format. OPAL then merges the sent options with the received options to get: Max Frame Width = 352 Max Frame Height = 288 Min Frame Width = 144 Min Frame Height = 96 Frame Width = 176 Frame Height = 144 Max Bit Rate = 128000 Target Bit Rate = 128000 Frame Time = 6000 SQCIF MPI = 5 QCIF MPI = 5 CIF MPI = 3 4CIF MPI = 5 16CIF MPI = 5 Annex D = 0 Here the MaxMerge operator adjusts the MPI's, and the AndMerge operator turns off Annex D. This is then passed to the plug-in "to_normalised_options" getting: Max Frame Width = 352 Max Frame Height = 288 Min Frame Width = 352 Min Frame Height = 288 Frame Width = 352 Frame Height = 288 Max Bit Rate = 128000 Target Bit Rate = 128000 Frame Time = 9009 SQCIF MPI = 5 QCIF MPI = 5 CIF MPI = 3 4CIF MPI = 5 16CIF MPI = 5 Annex D = 0 Where the Frame Size settles on its only possible value, and Frame Time gets adjusted to 10fps due to CPI MPI being 3. These options are then sent to the codec using set_codec_options and also merged with the YUV320P options so it can be used by the grabber. Robert Jongbloed OPAL/OpenH323 Architect and Co-founder.

3 2

Asterisk chan_h323 now available supporting H323plus
by Simon Horne 13 Nov '07

13 Nov '07

To All Asterisk chan_h323 has been successfully tested with h323plus and will be migrating their H.323 support from OpenH323 to the h323plus stack. Thanks goes to Vlasis Hatzistavrou for assisting with the migration. (mostly ptlib pprocess issues) Simon ----------------------- Simon Horne Principal Maintainer h323plus library www.h323plus.org h323:s.horne@packetizer.com

1 0

H323plus v1.19.7 (Linux) released
by Simon Horne 13 Nov '07

13 Nov '07

To All A new development release for h323plus for linux is available for download. This version fixes some small compilayion bugs with the H.230 code in the v1.19.6 release. Simon ----------------------- Simon Horne Principal Maintainer h323plus library www.h323plus.org h323:s.horne@packetizer.com

1 0

H323AudioCodec::SetRawDataHeld
by Sébastien Annedouche 12 Nov '07

12 Nov '07

Hi, my question might be stupid but can someone explain why a mutex is used in the SetRawDataHeld method : BOOL H323AudioCodec::SetRawDataHeld(BOOL hold) { PTimedMutex m; m.Wait(50); // wait for 50ms to avoid current locks IsRawDataHeld = hold; m.Wait(50); // wait for 50ms to avoid any further locks return TRUE; } I have another problem concerning codecs. Codecs sleep during read and write (within ReadRaw et WriteRaw) keeping rawChannelMutex locked and they lok it again immediately after signalling. I encouter thread starvations (or at least very long time before getting method called) when I try to call addFilter or SwapChannel on a running codec. This behavior can, for instance, prevent me from holding a call. Does anyone have this same problem ? Thanks for your help, Sebastien

2 5

How PString can be converted into CString
by Jaffar Hussain 09 Nov '07

09 Nov '07

Hi Simon ,Craig and Voip community, How PString can be converted into CString and CString to PString in _UNICODE mode compilation? Any help with example will be ppreciated... Jaffar __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

OpalCall Concept Question
by bxg 07 Nov '07

07 Nov '07

Hi all, I have just read opal code for a while. The concept of OpalCall puzzles me. The OpalCall is not existed in OpenH323 project. It's easy to think OpalCall as a gateway between H.323 and SIP connection, however how does this concept applied to OpenMCU. In the conference environment, How can OpalCall represent a conference or in the other words, how to implement conference using OPAL stack? Can you give me some advice？ Thks. Regards, Bian

3 7

Re: [h323plus] [Opalvoip-devel] [Openh323-devel] opalvoip vs h323plus
by Craig Southeren 07 Nov '07

07 Nov '07

..deleted > >> H323plus has a completely different focus to that of OpalVoIP and is >> designed to undertake advanced H.323 development (hence the plus) and >> unleach the full potential of what H.323 is capable of where are >> OpalVoIP is >> more of a generalist which to date has focused a lot of their >> attention (of >> late) on SIP. Here is a specific question for those people using OpenH323 (and now H323Plus) instead of OPAL. What would have to changed in, or added to, OPAL in order for you to move from OpenH323 (other than all of H.45x and H.46x stuff we are already committed to migrating) ? In other words, if you configure Opal with only H.323 support (which you can do now by running "./configure --disable-sip --disable-iax", what makes it so different from OpenH323 that it is worth splitting our joint efforts and maintaining two codebases? If you can answer this question, I promise that the Opal project will do it's very best to fulfill the requirements so we can all work on one codebase rather than two. 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

5 9

Re: [h323plus] [Opalvoip-devel] Custom Video Frame Size
by Simon Horne 07 Nov '07

07 Nov '07

I have CC'd this to the h323plus list. Robert Getting back to the initial question. I want to move forward with H.239 support in h323plus so can I remove the fixed frame size constraints from the video plugins so the project can move forward or if that's not recommended then, as I don't want to have different versions of the video plugins that break interoperability, can I put in a compiler directive to get us out of a pickle? Once these opal architectural glitches are resolved then the directive can be removed. I really am confused on the codec issues, and the discrete video sizes with H.261/H.263 and the generic capabilities etc. The way this is done in H323plus is to detect the capabilities of the video device at application startup via the changes I made in the ptlib videodevice factory which allows the device capability list to be exposed without instantaneousing the device. You use the device capabilities list to determine the maximum frame size available for the device so in this way you can detect and support HD webcams etc. There is a H323Endpoint function that then goes through and removes all the capabilities unsupported for that particular webcam. Easy! On the OpenVideoChannel function callback the user can then set the frame size and fps on the wire. This sets the header height/width fields of the YUV420 frame which then goes back into the plugin codec to resize the codec. This is how it used to work in OpenH323 and it works just fine. The problem you refer to is, I guess, an open Opal issue perhaps?. The "Extended Video Channel" is different to Hannes work in Opal. ExtendedVideoCapability is a type of Video capability which contains a subset of capabilites designed to be used for the likes of H.239. There is a flag I have added to the codec definitions in the video plugins which marks the codecs to be loaded into this subset group. Hannes's work is on having multiple primary video windows which is not related in H.239. The secondary or "Extended" video capability is opened via a function with sends a H.245 OLC and returns a channel number which you can then use to close the channel. Since each channel has a unique channel number, multiple video windows can be opened/closed on the fly. There is a working example of this in simple in applications directory in the H323plus CVS. This type of concept opens the way to develop more advanced concepts like telepresence where you can allocate 3 or more different video input for each secondary channel. Since all this is done on a secondary video capability, existing interoperability on the primary video is ensured and no existing architectural changes in h323plus are required. Simon -----Original Message----- From: opalvoip-devel-bounces(a)lists.sourceforge.net [mailto:opalvoip-devel-bounces@lists.sourceforge.net]On Behalf Of Robert Jongbloed Sent: Tuesday, 6 November 2007 6:00 AM To: Opalvoip-devel(a)lists.sourceforge.net Subject: Re: [Opalvoip-devel] Custom Video Frame Size > -----Original Message----- > From: opalvoip-devel-bounces(a)lists.sourceforge.net [mailto:opalvoip- > devel-bounces(a)lists.sourceforge.net] On Behalf Of Simon Horne ... > There was some private discussion a few weeks back on setting custom > video > frame sizes in Opal. I should probably summarise the result of that discussion and post the general list. > Currently looking at the video plugins (H.263 > for > instance) only predefined standard frame sizes are allowed (I added a > few > more BTW :) ). Now with H.239 application sharing that is just not > going to > happen. I can just comment out the frame size checking to allow > custom sizes > into the encoder, and get things to work in H323plus but I thought > I'd check > here before commiting stuff that breaks Opal. :) There is a branch where I started to implement the results of that huge long thread. Unfortunately I found a show stopper with OpalMediaFormat where I needed it to be polymorphic, but all through OPAL and H323plus is it used in such a way that breaks polymorphism, e.g. code like: ... function(const OpalMediaFormat & videoFormat) { OpalMediaFormat newFormat = videoFormat; Which, if videoFormat an instance of OpalVideoFormat, that type is lost in the copy constructor, including the correct virtual functions needed for video. This I need to fix, and soon ... > On a side note honestly I cannot see how to set a custom frame size > in Opal. > Well that's not true, I can see how you can do it, if you know what > the > frame size is in advance but with H.239 the frame size is determined > by the > dimensions of the image capture (of course that changes when you > resize the > window) and also how do you get access to the videoInput device at > creation > to set the window handle for the Input device to grab so it can set > the > capture size in the first place. Maybe someone with more knowledge on > this > topic might be able to assist. :( OK, this sounds like you are talking about changing the size of the transmitted video in mid flight, correct? That is one of the reasons why every internal RTP frame for raw video (of type "YUV420P") has a small structure at the top with x,y,width,height in it. It should be theoretically possible for the video source to change the resolution of the generated video on a frame by frame basis. The code does this now setting the width/height from PVideoInputDevice::GetFrameSize() before handing to codec. Now, your comments do raise an interesting point that is not yet allowed for, and that is how to deal with codecs that inherently only do discrete sizes such as H.261 and H.263. My understanding is all the others H.263+, H.264, MPEG4 part 2, Theora (?) can all do anything so I don't think they are an issue. Not sure how to address this one, first thought is a OpalMediaOption (readonly) which indicates if dynamic resize is possible, if not then something (OpalVideoConverter?) needs to scale/crop the image. More thought needed on that one. > For background in H323plus I created a new function > OpenExtendedVideoChannel() to allow the user access to create and > set, > within the application input device (vidinput_app.h now in ptlib), > the > window handle to capture, then retrieve the application frame size > from the > input device so you can (if necessary) scale the actual frame size on > the > wire. Is an "Extended Video Channel" a similar in concept to what Hannes was doing with his OpalMediaType? The ability to open more than one video channel in a call? > I really would like to get some input on how you can envision this > stuff to > work in opal so when it comes time (or someone has the time) to port > this > stuff it will be a straight forward affair and not either a H.239 > code or > architectural mashup. My experience has been that video is never straightforward, there is always some gotcha there. Especially, resolving the "old way" that H.261 and H.263 use (a million options in H.245) and the "new way" (profile/level) codecs such as MPEG4 and H.264 seem to be doing it now, is proving to be hideous. :-( Robert Jongbloed OPAL/OpenH323 Architect and Co-founder. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opalvoip-devel mailing list Opalvoip-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opalvoip-devel

3 3

AC_CHECK_FILE "unsuitable" for cross compiling
by Peter Nixon 06 Nov '07

06 Nov '07

Can someone please remove the use of AC_CHECK_FILE from configure.ac as it breaks cross compiling.. See: http://opalvoip.svn.sourceforge.net/viewvc/opalvoip/opal/trunk/configure.ac… Regards -- Peter Nixon http://peternixon.net/

2 1

Question about new ASN compiler
by Craig Southeren 06 Nov '07

06 Nov '07

To all, Some time ago, an independent group of developers created a new ASN compiler based on the original code provided released by OPAL/OpenH323. This code created by this compiler has been used in several commercial projects that I have been involved in, and it definitely works. The big advantage is that the code created by this compiler is MUCH smaller at run-time that the original OPAL/H.323 code. As in ten times smaller. The big disadvantage is that the code created by this compiler is very different from the code created by the old compiler. The code uses C++ templates heavily, and there is no way to make it look similar. Robert and I have not considered introducing this new compiler to date because of the problems it would cause. But, we would like to hear the opinions of other people about this code. If the general consensus is that people would like to see it used, then we will put in the work to make it happen. If the general consensus is that people do think it is worth the hassle, then we will stop worrying about it :) I've copied this message to both the h323plus and GnuGk lists as this decision has obvious ramifications for both projects 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

6 5

Re: [h323plus] Using H323+ for Asterisk's chan_h323
by Simon Horne 04 Nov '07

04 Nov '07

Plamen GnuGk has been test compiled with h323plus. Your error looks strange as it seems to like the code 2 lines above 656 which is identical . I suggest you look at code to see if you have not accidently modified something particularily look at gk_const.h as well as RasTbl.cxx:658 I have fixed the warning message. Simon -----Original Message----- From: Plamen Petkov [mailto:plamen@bg-tel.com] Sent: Friday, 26 October 2007 2:57 AM To: Simon Horne Subject: Re: [h323plus] Using H323+ for Asterisk's chan_h323 Hello, I try to compile Gnugk with H323plus. That is the result: RasTbl.cxx:658: error: no matching function for call to `H460_FeatureOID::Add(const char[2], H460_FeatureContent)' /root/openh323/include/h460/h4601.h:969: note: candidates are: H460_FeatureParameter& H460_FeatureOID::Add(const PString&, H460_FeatureContent&) RasTbl.cxx: In member function `void CallTable::OnQosMonitoringReport(const PString&, const endptr&, H4609_QosMonitoringReportData&)': RasTbl.cxx:2790: warning: unused variable 'addr' make[1]: *** [obj_linux_x86_r/RasTbl.o] Error 1 Regards: Plamen ----- Original Message ----- From: "Simon Horne" <s.horne(a)packetizer.com> To: <vhatz(a)kinetix.gr>; <h323plus(a)lists.packetizer.com> Sent: Thursday, October 25, 2007 6:44 PM Subject: Re: [h323plus] Using H323+ for Asterisk's chan_h323 > > Vlasis > > I am not sure what chan_h323 looks like but there should be no need to > have > timerChangePipe I think this is a left over from very old code. > > Have a look at simple in the CVS > http://h323plus.cvs.sourceforge.net/h323plus/applications/simple/ > to see how to define the PProcess > > Simon > > -----Original Message----- > From: h323plus-bounces(a)lists.packetizer.com > [mailto:h323plus-bounces@lists.packetizer.com]On Behalf Of Vlasis > Hatzistavrou (KTI) > Sent: Thursday, 25 October 2007 10:36 PM > To: h323plus(a)lists.packetizer.com > Subject: [h323plus] Using H323+ for Asterisk's chan_h323 > > > Hello all, > > I have been trying to compile chan_h323 with H323. It seems that I am > almost done, although I get the following error: > > g++ -DNDEBUG -I../../include -include > ../../include/asterisk/autoconfig.h -fPIC -DP_USE_PRAGMA -D_REENTRANT > -fno-exceptions -Wall -fPIC -DPIC -DNDEBUG > -I/Downloads/h323p/ptlib_v1_12_0/include -DPTRACING > -I/Downloads/h323p/h323plus/include -Os -pipe -felide-constructors > -Wreorder -c ast_h323.cxx -o ast_h323.o > ast_h323.cxx: In destructor `virtual MyProcess::~MyProcess()': > ast_h323.cxx:194: error: `timerChangePipe' was not declared in this scope > make[2]: *** [ast_h323.o] Error 1 > make[1]: *** [h323/libchanh323.a] Error 2 > make: *** [channels] Error 2 > > > I went through the PWLib 1.12.0, and there is no occurrence of > "timerChangePipe". In previous versions of PWLib "timerChangePipe" was > used in quite a few places in the code. > > I googled it, but I still don't know what it does. > > If I comment it out in the destructor MyProcess::~MyProcess() it > compiles, but the channel driver segfaults as soon as it is loaded... > > -- > Best regards, > Vlasis Hatzistavrou. > >

2 7

Re: [h323plus] [Openh323-devel] [Openh323gk-developer] [Opalvoip-devel]opalvoip vs h323plus
by Simon Horne 04 Nov '07

04 Nov '07

Robert Let me clear something up. GnuGk has numerous new features with the h323plus library over the openh323 library including H.350 LDAP, H.341 SNMP and numereous H.460 features including H.460.9 real-time Qos measurements, H.460.followme and the latest H.460 NAT Traversal technology P2Pnat Media and Presence implementation which should be available in the v2.2.8 release. The project is continuing it's evolutionary development just fine without the need for Opal. I wish to caution you on misleading people. Opal currently, as far as I know, has no additional H.323 features over the existing openh323 library (aside the video plugins support) unless I'm mistaken looking at the SVN I can't see anything new?. While h323plus which has been developed over the last 12 months as a branch of openh323 and has a substantial array, as mentioned previously, of new features http://www.h323plus.org/standards/ most of which are not currently available in OpalVoIP. Now, as I said before, you are quite welcome to port any of these ideas to Opal but to infer the latest wizzbang H.323 stuff is in Opal (at least at the moment) is being misleading... I carefully remind you that the decision to fork Opal out of OpenH323 was yours and Craig's decision and you did so with your eyes wide open and the subsequent malee that has ensued as a result is something we will all have to live and deal with. On that note, I strongly suggest, as I hinted before, we bring this discussion to a permanent close. Simon -----Original Message----- From: openh323-devel-bounces(a)lists.sourceforge.net [mailto:openh323-devel-bounces@lists.sourceforge.net]On Behalf Of Robert Jongbloed Sent: Sunday, 4 November 2007 1:44 PM To: 'Discussion on enhancements and development issues with the OpenH323 library' Cc: h323plus(a)lists.packetizer.com; Opalvoip-devel(a)lists.sourceforge.net Subject: Re: [Openh323-devel] [Openh323gk-developer] [Opalvoip-devel]opalvoip vs h323plus > -----Original Message----- > From: openh323-devel-bounces(a)lists.sourceforge.net [mailto:openh323- > devel-bounces(a)lists.sourceforge.net] On Behalf Of Jan Willamowius .... > The main point for GnuGk is that there is very little to be gained > from > a move to OPAL. Its not that I dislike anything thats in there, we > just > don't need 90% of the framework OPAL provides. .... And that is fine, you can stay with OpenH323. There are two classes of legacy user: ones such as GnuGk for which OpenH323 v1.18 does exactly what they want and they need no more features. Except maybe the odd bug fix, the code is as it is. The second class are people with ongoing application development are in continuous need of the "next new thing" in the feature list. These are the people we were hoping to make OPAL sufficiently attractive, due to its new whiz bang wonder gizmos, to convert to OPAL from OpenH323. Oh, and suppose there is a third class of those who have not yet started their project. They should have no reason not to use OPAL. We don't want them to have a reason. And a major reason for moving OPAL to a its own project was not to "fork" the code, but to reduce the confusion between OpenH323 and OPAL. I will reiterate what I and Craig have been saying all along: we are NOT abandoning OpenH323 completely. We just have not been doing any NEW work there as it is a duplication of effort. It is more akin to Ethereal and Wireshark, Ethereal is what it is at that point of time and all new stuff is in Wireshark. It is not, and never was, intended that this be a true "fork" where A goes it's way and B goes theirs. This is the whole reason why I am so disappointed with the ensuing result. Remember, this whole thread started with someone asking the question "Should I use OpenH323 or OPAL, which is better?", a fair question but one that I did not want anyone to have to ask. Robert Jongbloed OPAL/OpenH323 Architect and Co-founder. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Openh323-devel mailing list Openh323-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openh323-devel

3 2

Re: [h323plus] [Opalvoip-devel] [Openh323-devel][Openh323gk-developer] opalvoip vs h323plus
by Simon Horne 04 Nov '07

04 Nov '07

Robert As I asked before. This discussion is officially closed. Craig and yourself made a decisive decision with full knowledge of the large amount of new work I was currently doing in OpenH323 and the effect that decision would have on numerous other projects such as GnuGk. The result of that decision is something we all have to deal with. Simon -----Original Message----- From: opalvoip-devel-bounces(a)lists.sourceforge.net [mailto:opalvoip-devel-bounces@lists.sourceforge.net]On Behalf Of Robert Jongbloed Sent: Sunday, 4 November 2007 3:25 PM To: 'Discussion on enhancements and development issues with the OpenH323 library' Cc: h323plus(a)lists.packetizer.com; Opalvoip-devel(a)lists.sourceforge.net Subject: Re: [Opalvoip-devel] [Openh323-devel][Openh323gk-developer] opalvoip vs h323plus > -----Original Message----- > From: opalvoip-devel-bounces(a)lists.sourceforge.net [mailto:opalvoip- > devel-bounces(a)lists.sourceforge.net] On Behalf Of Simon Horne ... > Let me clear something up. GnuGk has numerous new features with the > h323plus > library over the openh323 library including H.350 LDAP, H.341 SNMP > and > numereous H.460 features including H.460.9 real-time Qos > measurements, > H.460.followme and the latest H.460 NAT Traversal technology P2Pnat > Media > and Presence implementation which should be available in the v2.2.8 > release. > The project is continuing it's evolutionary development just fine > without > the need for Opal. OK, that was a misinterpretation by me when Jan said he did not need 90% of OPAL code. I extrapolated that to mean he did not use much of OpenH323 either. And I was unaware that they have been using the "plus" branch, I incorrectly assumed they were on the trunk. > I wish to caution you on misleading people. Oh, now things are getting nasty. When accusations like this happen it is certainly time for the discussion to stop. > Opal currently, as far as > I > know, has no additional H.323 features over the existing openh323 > library > (aside the video plugins support) unless I'm mistaken looking at the > SVN I > can't see anything new?. While h323plus which has been developed over > the > last 12 months as a branch of openh323 and has a substantial array, > as > mentioned previously, of new features > http://www.h323plus.org/standards/ > most of which are not currently available in OpalVoIP. And why are they not in OPAL? Because effort is divided between two libraries. > Now, as I said before, you are quite welcome to port any of these > ideas to > Opal but to infer the latest wizzbang H.323 stuff is in Opal (at > least at > the moment) is being misleading... That is not what I meant. I did not mention OpenH323 features explicitly. And if things had gone the way I had originally envisioned with all new development being in OPAL then this statement would be 100% true. As it is, it is only true for non-H.323 features. > I carefully remind you that the decision to fork Opal out of OpenH323 > was There is that work "fork" again, even though I have tried hard to remove it from perceptions. The real fork happened FOUR YEAR AGO. The move to a different repository is just admin. > On that note, I strongly suggest, as I hinted > before, > we bring this discussion to a permanent close. Agreed. But accusations of deliberately misleading people could not go unanswered. Robert Jongbloed OPAL/OpenH323 Architect and Co-founder. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opalvoip-devel mailing list Opalvoip-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opalvoip-devel

1 0

Re: [h323plus] [Opalvoip-devel] [Openh323-devel] opalvoip vsh323plus
by Simon Horne 04 Nov '07

04 Nov '07

Peter I certainly don't know what the fuss is about. Opal has already really good H.323 support but you cannot *make* people or *conjole* people to migrate. H.323 is a very low priority these days with a lot of projects and many projects may just want to continue their existing code base then h323plus will do that (aka Asterisk (chan_h323),GnuGk etc), others like you are indicating might want to migrate to opal to include SIP or they might just go off and get any one of the dozens and dozens of quality SIP stacks out there. There are others who are using their own SIP stack who just want to add a H.323 stack which might be opal or h323plus or even ooh323. h323plus exists because there is a need of it, all the new work in h323plus is MPL 1.1 so you don't have to worry about licensing issues, want MPL ok, what GPL ok too, just go cherry pick what you want and leave whatever you don't, I'm not fussy. If you want a bit of support for it, then I'm willing to assist with direct enquiries. If you don't think any of it's relevent then forget it even exists and just use whatever you are using. But saying I should do this and that.... Sure everyone wants SIP so go use openser or the dozens of other quality SIP stacks, if you also need H.323 support use Asterisk or FreeSwitch or YATE or this little great project called Opal. Opal is a tiny small fish in a huge ocean. How is me moving to Opal going to change anything except cut off H.323 support for some of the bigger open source projects which relied on OpenH323 for there support, sure they can move to opal but honestly they'll probably just let (like they have been doing) their H.323 support stagnate. Just as with Asterisk and GnuGK I'm happy in assisting updating existing codebases from openh323 to h323plus. Easy, we went though the process last week with both projects. H323plus is meant to be project neutral (anyone can use it), it's a drop in replacement for openh323 and I still intend (where possible) to be highly compatible with opal so if your not ready to migrate then h323plus or cannot see a business case to do it, then it is there until you decide to (if ever) to migrate. You can pull out any of the new code and drop it straight into opal, I certainly will not be standing in anybodies way. With respect to any other projects that may occur they will be the same format so they too will be a neutral stand alone project library which probably be more suited to the asterisk channel type model rather than the more integrated Opal model. I really want to bring this whole discussion to an end. For the majority of people it has little relevence. For the rest, it is as it is. let's move on. Simon -----Original Message----- From: opalvoip-devel-bounces(a)lists.sourceforge.net [mailto:opalvoip-devel-bounces@lists.sourceforge.net]On Behalf Of Peter Nixon Sent: Saturday, 3 November 2007 11:13 PM To: opalvoip-devel(a)lists.sourceforge.net Cc: h323plus(a)lists.packetizer.com; GNU Gatekeeper Developer; Discussion on enhancements and development issues with the OpenH323 library Subject: Re: [Opalvoip-devel] [Openh323-devel] [h323plus] opalvoip vsh323plus On Sat 03 Nov 2007, Peter Robinson wrote: > Hi All, > > I've been a user of openh323/opal and on the mailings lists since very > early on when gnomemeeting was in the early 0.x releases and have > watched it all evolve, even contributing minor patches and testing on > ocasion. > > There are a number of things that disurb me about this whole "we've > been orphaned" deal. > > OPAL as it stands has been in development for years, it was > essentially openh323 version 2. Just like gnomemeeting was renamed to > ekiga to reflect the fact that it wasn't just aimed solely at gnome, > openh323's name was changed to reflect the fact that it didn't just > support h323, and as a result was essentially version 2. It was > advertised as such for years. > > Simon there is certainly currently more development of the SIP side of > opal at the moment but I see that is the case for 2 reasons. firstly > the H323 support was very stable and established, and secondly the > people doing the H323 development was being done one openh323. The > OPAL H323 side of things wouldn't stagnate as long as there's > developers. And if you and everyone else were to develop on openh323 > version 2 (OPAL) there wouldn't be missing features because you'd only > have to do the work once. And the only reason the H323 features would > stagnate is if the devs working on it and the maintainers of the H323 > portion of the code (you and others) moved onto other things. That > would give everyone better features on all three protocols currently > supported... and any others that come along. > > I'm sure if the opal project had remained named openh323 and called v2 > with new apis when they added sip support and later renamed there > wouldn't be this disparate uncessary separation and code divergence > and H323 would get nice features like the latest codecs developed by > craig, robert and co and SIP would get some of the great features you > and others develop for openh323 with very little effort. > > This community is too small for all the in fighting that I'm seen > between all the various developers over the years. Way more than a lot > of the other projects I follow, I was just reading through this thread over my Saturday morning coffee and thought I should write a reply. Then I got this this email which very nicely sumarises almost everything I wanted to say. I do have one thing to add however. I have known both Simon and Craig (and the gnugk and ekiga people) for several years now and have had the pleasure of being involved in some spirited face to face discussions over that time. I respect you all and consider you all friends. Simon, with that caveat, I would like to say that I think it is a good thing for h323plus to exist given the state of the openh323 "project" but I heartily wish that its goal was more of a "maintenence mode" project than an actively developed alternative to OPAL. I have heard your reasons for continuing development on openh323/h323plus instead of OPAL several times before and I have to say that I was never fully convinced, however recent events have made me ever less sure. Three months, I made the transition from owner of my own company, to a new position as RnD Director for a VoIP CPE vendor. This has given me a different perspective on things, given that I had always been involved in the "large" side of VoIP deployments where you have gigabytes of disk space and ram and a very different development environment, time to market requirements and market realities. The fact is, despite incompatibilities, functionality gaps and all wisdom to the contrary, SIP is the current market standard for VoIP CPEs. If I told my CEO that I wanted to build a H.323 only CPE he would tell me to reconsider, or reconsider my position at the company. On the other hand, if I can build a SIP device, then deliver H.323 functionality practically for "free" by using OPAL then I can build either an "advanced" model with both SIP and H.323 support (It would cost more due to the required flash and ram increase), or an alternate H.323 firmware for the "standard" device. This, as H.323 proponent, is good for you, and this is a major reason for me to pick OPAL as the stack to develop on, otherwise I would just as likely pick one of the many other very good open source SIP stacks available, and I would never even consider doing the work to develop completely independent H.323 support using h323plus. Please spend a moment to consider "new" users like my company, and not only the temporary difficulties that some old users (like gnugk for example) would face porting from openh323 to opal. The VoIP industry is far from done, and as you know, there are new protocols coming out like AMS and others which I hope one day will also be available as part of OPAL also. I think the decision to do new development in h323plus is a little short sighted, because it makes using your wonderfull new features (and I really mean that) difficult for new VoIP developers due to the hurdle of learning and using another library for H.323 in addition to whatever library they already use for SIP (Or IAX or AMS or whatever), and the even bigger hurdle of deciding to add H.323 support in the first place! Consider also, what you will do when AMS is released.. You will at some point outgrow the existing openh323 design and API and be forced to refactor things at which point you will likely end up with something a lot like OPAL :-) Please, consider doing your future h323 development on OPAL! I really believe that you will end up with a lot more people using your code (and H.323) in the long term. -- Peter Nixon http://peternixon.net/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opalvoip-devel mailing list Opalvoip-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opalvoip-devel

2 1

Re: [h323plus] [Opalvoip-devel] [Openh323-devel] opalvoip vsh323plus
by Robert Jongbloed 04 Nov '07

04 Nov '07

> -----Original Message----- > From: opalvoip-devel-bounces(a)lists.sourceforge.net [mailto:opalvoip- > devel-bounces(a)lists.sourceforge.net] On Behalf Of Michel Stempin .... > split to > a different site as a general purpose library:) We actually did discuss this! :-) In the end we decided that making OPAL any more complicated to get and build than it already is (it's hard enough now) was less desirable than having a separate SF project for PTLib. We did stop short of actually integrating the two libraries completely, for precisely the reason that there are people using PTLib on its own. So, having it as a sub-project of opalvoip was the compromise ... Robert Jongbloed OPAL/OpenH323 Architect and Co-founder.

1 0

Re: [h323plus] [Opalvoip-devel] [Openh323-devel] opalvoip vs h323plus
by Simon Horne 03 Nov '07

03 Nov '07

Hannes I completely understand your point and from our offlist discussions I have been very supportive of getting some of these ideas like the a common H.460 framework base and H.239 into Opal. It would be good to have these kind of H.460 features like NAT and also the myriad of other H.460 extensions like text messaging (h460.tm), follow me, click to call, presence (h460.presence in development with PacPhone and GnuGk) which are available in h323plus into Opal. I very much look forward to that close working relationship into the future. Simon -----Original Message----- From: opalvoip-devel-bounces(a)lists.sourceforge.net [mailto:opalvoip-devel-bounces@lists.sourceforge.net]On Behalf Of Hannes Friederich Sent: Saturday, 3 November 2007 7:30 PM To: Discussion on enhancements and development issues with the OpenH323 library Cc: h323plus(a)lists.packetizer.com; Opalvoip-devel(a)lists.sourceforge.net Subject: Re: [Opalvoip-devel] [Openh323-devel] opalvoip vs h323plus Simon, On 03.11.2007, at 10:26, Simon Horne wrote: > > Robert > > I hate to be blunt but I would like to point out a few facts. > > The decision to fork Opal to OpalVoIP was purely yours and craigs. > Nobody > forced you to make the fork and you guys did it very much with your > eyes > wide open. You knew very well what new work I was doing in openH323 > as well > as the numerous projects such as Asterisk,Yate,GnuGk, PacPhone etc > rely on > OpenH323 for their H.323 support and that support would be > disrupted if not > lost with the abrupt move to OpalVoIP. There was a flurry of > "concerned" > private emails on the topic and was actively discussed on the days > leading > up to your public announcement. The fact that all those features aren't ported to Opal (yet) is not lack of interest but mainly lack of time. I think Craig and others pointed this out as well. I myself am very interested to have a full- featured H.323 stack in Opal, and I am willing to do some of the porting work myself, but right now I am struggling to find even time to work on my main project, XMeeting. I have to admit I never really worked with the OpenH323 stack, but as much as I can tell, Opal not only offers multiple protocol stacks but also a better software architecture design. This itself should make it a reason to port the applications above to Opal. However, as long as most H.323-related work is done in OpenH323/H323Plus, the two projects continue to diverge, making it harder to switch to Opal later on. I think that the developers of Opal / OpenH323 should put more pressure on the projects mentioned above to migrate to Opal. I know it is hard to convince someone to fund such porting work, as there is no direct financial benefit for the funder, but at some point the cost of maintaining "backwards" compatibility by far exceeds the benefits of having this backwards compatibility. One should not only focus the projects one is interested in, but also consider the OpenH323 community and what's best for that community as a whole. However, I will by no means criticize your project split-off, as I can fully understand your motivation for doing this. ...deleted... Hannes ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opalvoip-devel mailing list Opalvoip-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opalvoip-devel

1 0

Re: [h323plus] [Openh323-devel] opalvoip vs h323plus
by Simon Horne 03 Nov '07

03 Nov '07

Robert I hate to be blunt but I would like to point out a few facts. The decision to fork Opal to OpalVoIP was purely yours and craigs. Nobody forced you to make the fork and you guys did it very much with your eyes wide open. You knew very well what new work I was doing in openH323 as well as the numerous projects such as Asterisk,Yate,GnuGk, PacPhone etc rely on OpenH323 for their H.323 support and that support would be disrupted if not lost with the abrupt move to OpalVoIP. There was a flurry of "concerned" private emails on the topic and was actively discussed on the days leading up to your public announcement. The decision to start h323plus was made in part in response to your decision and to ensure continuation of support for these "orphaned" projects and also to ensure the new work I was doing in OpenH323 saw the light of day. It became impossible to do in openh323, although I had made several public gestures to taking over the OpenH323 project, I never received any response from anybody on the topic so I was forced to take the action I did. Facts remain there has been little new H.323 work in Opal aside from the video plugin work with majority of that focus been on the SIP side which is completely understandable as this has been your prime focus. For instance, the new H.264 and MPEG4 codecs in the Opal repository didn't even have H.323 support. (Well not completely true, I'm testing H.264 code and will get to the MPEG4 shortly) To be honest, the H.323 support in Opal is currently at the level of about openH323 v1.18 meanwhile over the last 12 months I have been diligently adding H.230,H.239,H.249,H.341,H.350,H.460.x etc to the openH323 plugins branch (abit with Roberts paid (from somebody) support for the video plugins :) ) with the an aim to have that work ported to Opal when you guys were ready, nobody has EVER contacted me on doing this to date (aside from Hannes) and the offer is still there and I certainly welcome you to do so. Nothing at all changes that. As you are aware I still commit changes to ptlib and the opal plugins in OpalVoIP SVN and you are very much welcomed to take any of the new H323plus work and add it to OpalVoIP. I don't understand, Although the desire to make a smaller ASN.1 footprint is a completely fantastic idea but why do you want to effectively exclude such a large number of projects which currently rely on OpenH323 (now h323plus) or basically force these projects to recode to Opal. In many respects there is no compelling business case (or benefit) for these projects to move to Opal but more importantly, politics may be the deciding factor as unlike openH323, Opal may be seen as a competitor especially on the SIP side and with the current demand for H.323 very low they might just abandon any new H.323 work altogether. This is my greatest fear. The purpose of h323plus is to continue on from your (and craig's) fantastic work on OpenH323 and the unique neutral place OpenH323 had in the marketplace and develop it further with app sharing, conference controls etc,(hence the + in h323plus) and make that available to the widest audience possible, continuing the history of being the one really good advanced open source H.323 stack which everyone has relied on for so many years. Simon -----Original Message----- From: openh323-devel-bounces(a)lists.sourceforge.net [mailto:openh323-devel-bounces@lists.sourceforge.net]On Behalf Of Robert Jongbloed Sent: Saturday, 3 November 2007 11:33 AM To: 'Discussion on enhancements and development issues with the OpenH323 library'; h323plus(a)lists.packetizer.com; Opalvoip-devel(a)lists.sourceforge.net Subject: Re: [Openh323-devel] opalvoip vs h323plus Sigh, I know I should not do this but .... > -----Original Message----- > From: openh323-devel-bounces(a)lists.sourceforge.net [mailto:openh323- > devel-bounces(a)lists.sourceforge.net] On Behalf Of Simon Horne > Sent: Sunday, 28 October 2007 3:19 PM ... > There are dozens of very popular open source stacks like asterisk and > Yate > that rely on openH323 for their H.323 support. With the migration to > Opal > this support is hampered as openH323 was seen as a component where as > OpalVoIP may be viewed a little differently. My greatest fear is that > H.323 > support in these projects would stagnate or be dropped entirely which > would > be a major loss. Hence the maintaining of that support in H323plus. And this is my greatest fear as well. Unfortunately when the primary champions of the H.323 protocol decide NOT to use the OPAL environment, they are going a long way to ensuring that this WILL be the case. > H323plus has a completely different focus to that of OpalVoIP and is > designed to undertake advanced H.323 development (hence the plus) and > unleach the full potential of what H.323 is capable of where are > OpalVoIP is > more of a generalist which to date has focused a lot of their > attention (of > late) on SIP. True, because much as I hate SIP as a protocol, we can't ignore it. Many consumers of OpenH323 (YATE, Asterisk, etc) have SIP as well, they just use someone else's stack. > Now saying that, it does not mean the work in H323plus > cannot > be ported across to OpalVoIP or visa versa. Case in point the Video > Plugins > from Opal (which Robert did a lot of work on) and the plan to port > the app > sharing H.239 to Opal (which I authored). The H323plus stack is built > off > ptlib and uses the same audio/video plugins which I still actively > assist in > maintaining. Yes, but as time goes on and the stacks continue to diverge, this gets harder and harder. For example, one idea Craig and I have toyed with is changing the ASN.1 PER system to use the iii compiler. This reduces the code footprint by a staggering amount. Literally an order of magnitude, a 3 megabyte executable being reduced to less than 300 kilobytes. This involves changing (in a semi-automatic way) thousands of lines of code. However, once that is done any porting between the two is ten times harder as diff's can no longer be used on files that used to be 95% identical. We don't know if we would do this or not, but maintaining the ability to port between OpenH323 and OPAL becomes a factor against in the decision making process. > The real question is not which is better but which better suits your > needs. > If you are starting a new project and need to support SIP with > quality H.323 > support then use OpalVoIP. If you have an existing project or don't > require > SIP but need advanced H.323 features such as app sharing, HD Video, > conference controls, LDAP, SNMP then you should consider H323plus. And therein lies the problem. What if someone wants both? They shouldn't need to choose. There is really no technical reason for it. If you use OPAL and just use H.323 (i.e. only create an H323EndPoint and not a SIPEndPoint), that should be IDENTICAL to using OpenH323. Once upon a time it was! The "generalist"/"specialist" argument not a good one IMHO. OPAL is a LIBRARY, as with any library you use as much or as little as you need and ignore the rest. .... > I certainly wish them all the best. However the move does have its > downside > as projects such as GnuGk, YATE, Asterisk are forced to migrate their > H.323 > support or let it stagnate (which is my greatest fear) which was the > prime > motivating force for h323plus. As I said before, if you were working on OPAL, then the H.323 within it would never stagnate. It is to my everlasting regret that I never could get around to producing a "porting guide" from OpenH323 to OPAL. A nice, detailed recipe on the API changes that need to be tweaked. There are already examples of dual mode applications in the contrib directory now and not THAT much changes. If I had managed to produce such a document then I do not think this would have been an issue. I say this because I believe the REAL reason applications such as GnuGk etc have not moved to OPAL is that the authors did not know, nor want to expend valuable time figuring out, how to change their applications to use the new API. I do not blame these people in the slightest for that decision. The fault is mine in not producing sufficient information to make it easy. However, that fundamental mistake several year ago has caused a juggernaut to move on. It is probably now impossible for OPAL to ever have the same functionality as OpenH323 as the likelihood of us having time to port the code is small (we need to earn a living), and the likelihood of someone paying for it is even smaller. I know if I was an application writer with requirements for H.323 with the extras and needed SIP too, I would be using OpenH323 and some other SIP stack such as oSIP/Vocal/reSIProcate etc. So, I believe the divergence will continue and this makes me profoundly sad. Robert Jongbloed OPAL/OpenH323 Architect and Co-founder. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Openh323-devel mailing list Openh323-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openh323-devel

2 1

H.239 support in h323plus
by Simon Horne 02 Nov '07

02 Nov '07

H.239 support is now available in h323plus. I have updated simple in the application directory of the CVS to provide a sample application. You can place a call and press 'S' to start a fake application video window and 'E' to end it. You will need the latest CVS version of the H.263 video plugin to for it to work. You can get it from the opalVoIP repository or there is a mirror in the extensions/plugins directory in the h323plus CVS. Simon ----------------------- Simon Horne Principal Maintainer h323plus library www.h323plus.org h323:s.horne@packetizer.com

1 0

h323plus v1.19.6 (Linux) Release
by Simon Horne 02 Nov '07

02 Nov '07

Guys An update has been release to fix a few issues with GnuGk http://www.h323plus.org/source/download/h323plus-v1_19_6-src.tar.gz The main download page should be updated shortly with the new link. Thanks to Jan Willamowius (GnuGk) is assisting resolving the issues and getting the release out. Simon ----------------------- Simon Horne Principal Maintainer h323plus library www.h323plus.org h323:s.horne@packetizer.com

1 0

Socket aggregation not yet implemented on Unix?
by Vlasis Hatzistavrou (KTI) 02 Nov '07

02 Nov '07

Hello, I have tried to compile H323Plus with Signaling and RTP aggregation, so I assumed that I needed to compile PTLib with socket aggregation first using "./configure --enable-sockagg" However, during the PTLib compilation I receive the message: "aggregation not yet implemented on Unix" Is there any ETA about this feature? Also, is this feature fully available on Windows? -- Best regards, Vlasis Hatzistavrou.

2 2

Re: [h323plus] [Openh323-devel] help in creating WhiteBoard application using Opal
by Simon Horne 30 Oct '07

30 Oct '07

FYI opal is now opalVoIP and openH323 is continuing on as H323plus. OpenH323 (the project "in general" is no longer being actively developed. T.120 support in Opal is at the same level it as it is in OpenH323 very very basic. There is a project on sourceforge which has been abandoned for many many years based on OpenH323. http://sourceforge.net/projects/opent120/ T.120 development in general has pretty much stopped for various reasons including NAT issues. It uses TCP and you cannot easily use STUN, H.460.18/19 or emerging NAT technologies like P2Pnat to traverse NATs. That does not mean T.120 development has ceased. In h323plus www.h323plus.org we have added H.239 support or extended video to perform the same operation as T.120 app/whiteboarding would perform except over UDP so it can traverse NATs. It utilises the existing video plugin codecs to create a secondary video channel for the purpose of App Sharing. This work is continuing with the addition of app sharing controls such as H.249 collaberaton controls (remote userinputs, mouse movements and keystrokes). T.124 or Generic conference controls has also been resurrected and is being tunnelled through H.245 to perform "next generation" remote MCU control functionality such as Inviting and ejecting participants, Floor and chair controls and eventually the ability to introduce H.239 apps directly into conferences as presentations. If anyone would like to participate and/or contribute to this work then please let me know. Simon -----Original Message----- From: openh323-devel-bounces(a)lists.sourceforge.net [mailto:openh323-devel-bounces@lists.sourceforge.net]On Behalf Of Vishak V. Kurup Sent: Monday, 29 October 2007 3:08 PM To: openh323-devel(a)lists.sourceforge.net Subject: [Openh323-devel] help in creating WhiteBoard application using Opal Hi, I am Vishak. I want to develop a white board application for linux using gtk. I heard that whiteboard applications use T.120 protocol. T.120 protocol is in the stack of Opal. So can any one please tell me how create a whiteboard application. Regards

2 1

Re: [h323plus] [Openh323-devel] opalvoip vs h323plus
by Hugo Pereira 28 Oct '07

28 Oct '07

Greetings, I have just read the history post about OPAL. I was already very impressed about the work of Craig and Robert. now i am even more! :) Spite In that text OPAL seens to be the successor of openh323, now this last has reemerged in the form of h323plus. - Does this new and enhanced protocol stack is is better? - What are the advantages/disadvantages of using one or another? - Are now these projects competing with each other? These are a few questions that question the existence of both projects simultaneously.

2 1

opalvoip vs h323plus
by Hugo Pereira 27 Oct '07

27 Oct '07

Greetings, OpenH323 has branched into two distinct projects: opalvoip and h323plus. However each of these projects are best? Both of their based protocols (H323 and SIP) is well known in he videoconference worldwide. Because opalvoip supports both SIP and H323 i could point this project better than h323plus. Am i right? Best regards, Hugo Pereira

1 0

HD Video support in H323plus
by Simon Horne 26 Oct '07

26 Oct '07

Just a quick note: H323 plus now supports HD video. The necessary changes have been made in the ptlib library. Simon ----------------------- Simon Horne Principal Maintainer h323plus library www.h323plus.org h323:s.horne@packetizer.com

1 0

Using H323+ for Asterisk's chan_h323
by Vlasis Hatzistavrou (KTI) 25 Oct '07

25 Oct '07

Hello all, I have been trying to compile chan_h323 with H323. It seems that I am almost done, although I get the following error: g++ -DNDEBUG -I../../include -include ../../include/asterisk/autoconfig.h -fPIC -DP_USE_PRAGMA -D_REENTRANT -fno-exceptions -Wall -fPIC -DPIC -DNDEBUG -I/Downloads/h323p/ptlib_v1_12_0/include -DPTRACING -I/Downloads/h323p/h323plus/include -Os -pipe -felide-constructors -Wreorder -c ast_h323.cxx -o ast_h323.o ast_h323.cxx: In destructor `virtual MyProcess::~MyProcess()': ast_h323.cxx:194: error: `timerChangePipe' was not declared in this scope make[2]: *** [ast_h323.o] Error 1 make[1]: *** [h323/libchanh323.a] Error 2 make: *** [channels] Error 2 I went through the PWLib 1.12.0, and there is no occurrence of "timerChangePipe". In previous versions of PWLib "timerChangePipe" was used in quite a few places in the code. I googled it, but I still don't know what it does. If I comment it out in the destructor MyProcess::~MyProcess() it compiles, but the channel driver segfaults as soon as it is loaded... -- Best regards, Vlasis Hatzistavrou.

2 1

H323Plus 1.19.5 released
by Simon Horne 24 Oct '07

24 Oct '07

To All Just a quick note the first H323Plus development release is now available for download H323Plus 1.19.5 can be downloaded from http://www.h323plus.org/source/ or http://sourceforge.net/project/showfiles.php?group_id=194599 Pwlib 1.12 is also available (mirror of openH323 release) Audio/Video Plugins (Mirror of OpalVoIP release) The number system will be a continuation of the OpenH323 number system with 1.20 being the first stable release. Special OpenH323 Transition Notes: Video is now plugins so you will need to remove references to the existing H.261 and H.263 libraries and all codecs are now loaded via AddAllCapabilities() Check you video input and output device code functions correctly as there are some improvements in ptlib which might affect the video display. Only H.261 & H.263 are supported with this release. H.264,MPEG4 are to come. DirectShow for Windows is not supported (yet) for VS 2003 & VS 2005. Of course you can direct your questions to the H323Plus mailing list. Simon

1 0