- h323plus - lists.packetizer.com

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