Menu
▾
▴
openh323-devel — Discussion on enhancements and development issues with the OpenH323 library
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(94) |
Jul
(31) |
Aug
(27) |
Sep
(21) |
Oct
(29) |
Nov
(25) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(4) |
Dec
(2) |
| 2007 |
Jan
|
Feb
(1) |
Mar
(5) |
Apr
(139) |
May
(103) |
Jun
(67) |
Jul
(47) |
Aug
(106) |
Sep
(99) |
Oct
(53) |
Nov
(38) |
Dec
|
| 2008 |
Jan
(6) |
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(3) |
Jul
(5) |
Aug
(2) |
Sep
(8) |
Oct
(2) |
Nov
|
Dec
(2) |
| 2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Andrea M. <and...@ho...> - 2014-04-14 07:19:35
|
Hi there! http://www.fargo.su/_comment.youtube.com?pecugiwum=2169868&efuniv=158750 |
|
From: Andrea M. <and...@ho...> - 2014-04-14 06:47:38
|
Hey there! http://www.volumebank.com/_comment.youtube.com?kjcytugj=7791074&njquguxy=213277 |
|
From: Paul C. <pa...@vo...> - 2011-02-23 21:25:36
|
Hi, Jan! Thanks for this change, it helps to be able to use unpatched libraries. Paul On Wednesday 23 February 2011 07:13:01 pm Jan Willamowius wrote: > Paul, > > I absolutely agree that the application settings should not be > overwritten after OnSendSignalSetup() and made the change in the > H323Plus CVS. > > Regards, > Jan > > Paul Chitescu wrote: > > Hello all! > > > > While trying to add code in Yate to set some important parameters - for > > the telephony business - I noticed my changes are overwritten by OpenH323 > > / H323Plus. > > > > I reimplemented H323Connection::OnSendSignalSetup() and changed the Q.931 > > fields in setupPDU. Unfortunately the following code (in h323.cxx) undoes > > my changes: > > > > > > if (!OnSendSignalSetup(setupPDU)) > > return EndedByNoAccept; > > > > // Do this again (was done when PDU was constructed) in case > > // OnSendSignalSetup() changed something. > > setupPDU.SetQ931Fields(*this, TRUE); > > setupPDU.GetQ931().GetCalledPartyNumber(remotePartyNumber); > > > > > > > > Is there any solid reason why setupPDU.SetQ931Fields(*this, TRUE) is > > called? Its default parameters are overwriting the type, plan, > > presentation and screening of the numbers. I also need to set separate > > type of number on caller and called party numbers. > > > > My plan is to patch OpenH323 / H323Plus to delete the extra > > SetQ931Fields(). Do you see any unintended consequences of such a change? > > > > Regards, > > > > Paul Chitescu |
|
From: Jan W. <ja...@wi...> - 2011-02-23 17:13:10
|
Paul, I absolutely agree that the application settings should not be overwritten after OnSendSignalSetup() and made the change in the H323Plus CVS. Regards, Jan Paul Chitescu wrote: > Hello all! > > While trying to add code in Yate to set some important parameters - for the > telephony business - I noticed my changes are overwritten by OpenH323 / > H323Plus. > > I reimplemented H323Connection::OnSendSignalSetup() and changed the Q.931 > fields in setupPDU. Unfortunately the following code (in h323.cxx) undoes my > changes: > > > if (!OnSendSignalSetup(setupPDU)) > return EndedByNoAccept; > > // Do this again (was done when PDU was constructed) in case > // OnSendSignalSetup() changed something. > setupPDU.SetQ931Fields(*this, TRUE); > setupPDU.GetQ931().GetCalledPartyNumber(remotePartyNumber); > > > > Is there any solid reason why setupPDU.SetQ931Fields(*this, TRUE) is called? > Its default parameters are overwriting the type, plan, presentation and > screening of the numbers. I also need to set separate type of number on caller > and called party numbers. > > My plan is to patch OpenH323 / H323Plus to delete the extra SetQ931Fields(). > Do you see any unintended consequences of such a change? > > Regards, > > Paul Chitescu > > -- Jan Willamowius, ja...@wi..., http://www.gnugk.org/ |
|
From: Paul C. <pa...@vo...> - 2011-02-23 17:00:35
|
Hello all!
While trying to add code in Yate to set some important parameters - for the
telephony business - I noticed my changes are overwritten by OpenH323 /
H323Plus.
I reimplemented H323Connection::OnSendSignalSetup() and changed the Q.931
fields in setupPDU. Unfortunately the following code (in h323.cxx) undoes my
changes:
if (!OnSendSignalSetup(setupPDU))
return EndedByNoAccept;
// Do this again (was done when PDU was constructed) in case
// OnSendSignalSetup() changed something.
setupPDU.SetQ931Fields(*this, TRUE);
setupPDU.GetQ931().GetCalledPartyNumber(remotePartyNumber);
Is there any solid reason why setupPDU.SetQ931Fields(*this, TRUE) is called?
Its default parameters are overwriting the type, plan, presentation and
screening of the numbers. I also need to set separate type of number on caller
and called party numbers.
My plan is to patch OpenH323 / H323Plus to delete the extra SetQ931Fields().
Do you see any unintended consequences of such a change?
Regards,
Paul Chitescu
|
|
From: Anish K. K. <ani...@ne...> - 2009-01-08 10:15:07
|
Dear all,
I compiled ffmpeg with x264 support. I took these packages from svn.
After that I compiled opal-3.4.2 by
./configure --disable-h323 --enable-plugins
By doing so i didn't got h.264 enabled. When the configure script got
finished it is displaying
H.261 : yes
H.263 : yes
H.263+ : no
H.264 : no
What is the correct procedure to make H.264 : yes?
For getting out of this I edited the makefile
opal-3.4.2/plugins/Makefile
In it I changed HAVE_H264=no to HAVE_H264=yes
By doing so the opal got compiled and I got the following plugins in
lib/opal-3.4.2/codecs/video directory
h261-vic_video_pwplugin.so
h263-ffmpeg_video_pwplugin.so
h264_video_pwplugin_helper
h264_video_pwplugin.so
But when I am using simpleopal only the following video codecs are
obtained
H.261,H.261-CIF,H.261-QCIF,RFC4175_YCbCr-4:2:0,RFC4175_RGB
For running simpleopal I exported the PWLIBPLUGINDIR and OPALPLUGINDIR
Please tell me where I am wrong and how to run simpleopal using h264
Thanks in advance,
Anish
|
|
From: Robert J. <rob...@bi...> - 2008-12-16 23:40:22
|
OpenH323 is EXTREMELY old and has long been deprecated. The new OPAL system (http://www.opalvoip.org) replaced it several years ago. I have personally used OPAL on embedded systems so I know the cross compiling works there. Robert Jongbloed OPAL/OpenH323/PTLib Architect and Co-founder. > -----Original Message----- > From: Obelix [mailto:ob...@ya...] > Sent: Tuesday, 2 December 2008 10:43 PM > To: ope...@li... > Subject: [Openh323-devel] Compilation error of pwLib / openH323 / > ohphone > > Hello, > > I'm trying to cross compile for a PowerPC603-E this sources > and I have a problem to the last step :( > > It's for a embedded card with a 2.6.9 kernel and I don't need video > support. > > Thanks a lot for your help ! > > --------------------------------------------------------------------- > ------------------------------ > Compilation of pwLib 1.10.2 : > ./configure > --prefix=/home/apps/h323/pwlib/install > --exec-prefix=/home/apps/h323/pwlib/install > --build=powerpc-linux --target=powerpc-linux --host=i586- > mandrake-linux > --disable-plugins --disable-v4l2 --disable-resolver -- > disable-sasl > --disable-openldap --disable-openssl --disable-expat -- > disable-ipv6 > --disable-qos --disable-sdl --disable-video --disable-shm- > video > --disable-alsa --disable-memcheck > CC=ppc_60x-gcc CPLUS=ppc_60x-g++ AR=ppc_60x-ar > RANLIB=ppc_60x-ranlib > CXX=ppc_60x-g++ INSTALL=install ENDIAN=PBIG_ENDIAN > > => no problem > --------------------------------------------------------------------- > ------------------------------ > > --------------------------------------------------------------------- > ------------------------------ > Compilation of openH323 1.18.0 : > ./configure > --prefix=/home/apps/h323/openh323/install > --exec-prefix=/home/apps/h323/openh323/install > --build=powerpc-linux --target=powerpc-linux --host=i586- > mandrake-linux > --disable-asntracing --disable-video > --enable-embeddedgsm --enable-rfc2190avcodec --enable- > h263avcodec > CC=ppc_60x-gcc CPLUS=ppc_60x-g++ AR=ppc_60x-ar > RANLIB=ppc_60x-ranlib > CXX=ppc_60x-g++ INSTALL=install ENDIAN=PBIG_ENDIAN > > => no problem > --------------------------------------------------------------------- > ------------------------------ > > --------------------------------------------------------------------- > ------------------------------ > Compilation of ohPhone 1.4.5 : > make opt > > => problem > ppc_60x-g++ -o obj_linux_ppc_n/ohphone > -L/home/apps/h323/pwlib/lib > -L/home/apps/h323/openh323/lib > ./obj_linux_ppc_n/main.o > -lh323_linux_ppc_n > -lpt_linux_ppc_r > -lpthread > -ldl > ./obj_linux_ppc_n/main.o(.text+0x185c): In function > `MyH323EndPoint::Initialise(PConfigArgs&, int, int)': > : undefined reference to `H323PluginCodecManager::GetMediaFormats()' > collect2: ld returned 1 exit status > --------------------------------------------------------------------- > ------------------------------ > > > > > --------------------------------------------------------------------- > --------- > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, > Nevada. > The future of the web can't happen without you. Join us at MIX09 to > help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitm > ix.com/ > _______________________________________________ > Openh323-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openh323-devel |
|
From: Obelix <ob...@ya...> - 2008-12-02 11:42:37
|
Hello,
I'm trying to cross compile for a PowerPC603-E this sources
and I have a problem to the last step :(
It's for a embedded card with a 2.6.9 kernel and I don't need video support.
Thanks a lot for your help !
---------------------------------------------------------------------------------------------------
Compilation of pwLib 1.10.2 :
./configure
--prefix=/home/apps/h323/pwlib/install
--exec-prefix=/home/apps/h323/pwlib/install
--build=powerpc-linux --target=powerpc-linux --host=i586-mandrake-linux
--disable-plugins --disable-v4l2 --disable-resolver --disable-sasl
--disable-openldap --disable-openssl --disable-expat --disable-ipv6
--disable-qos --disable-sdl --disable-video --disable-shm-video
--disable-alsa --disable-memcheck
CC=ppc_60x-gcc CPLUS=ppc_60x-g++ AR=ppc_60x-ar RANLIB=ppc_60x-ranlib
CXX=ppc_60x-g++ INSTALL=install ENDIAN=PBIG_ENDIAN
=> no problem
---------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------
Compilation of openH323 1.18.0 :
./configure
--prefix=/home/apps/h323/openh323/install
--exec-prefix=/home/apps/h323/openh323/install
--build=powerpc-linux --target=powerpc-linux --host=i586-mandrake-linux
--disable-asntracing --disable-video
--enable-embeddedgsm --enable-rfc2190avcodec --enable-h263avcodec
CC=ppc_60x-gcc CPLUS=ppc_60x-g++ AR=ppc_60x-ar RANLIB=ppc_60x-ranlib
CXX=ppc_60x-g++ INSTALL=install ENDIAN=PBIG_ENDIAN
=> no problem
---------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------
Compilation of ohPhone 1.4.5 :
make opt
=> problem
ppc_60x-g++ -o obj_linux_ppc_n/ohphone
-L/home/apps/h323/pwlib/lib
-L/home/apps/h323/openh323/lib
./obj_linux_ppc_n/main.o
-lh323_linux_ppc_n
-lpt_linux_ppc_r
-lpthread
-ldl
./obj_linux_ppc_n/main.o(.text+0x185c): In function `MyH323EndPoint::Initialise(PConfigArgs&, int, int)':
: undefined reference to `H323PluginCodecManager::GetMediaFormats()'
collect2: ld returned 1 exit status
---------------------------------------------------------------------------------------------------
|
|
From: dansukcu <dan...@tt...> - 2008-10-20 08:00:02
|
Hi, I want to split two different audio from voip so that one goes to left and the other goes to right ear of the headphone. Has anyone implemented something like this before or got any suggestions? Thanks, Cuneyt |
|
From: dansukcu <dan...@tt...> - 2008-10-20 07:55:20
|
Hi, I want to split two different audio from voip so that one goes to left and the other goes to right ear of the headphone. Has anyone implemented something like this before or got any suggestions? Thanks, Cuneyt |
|
From: info <in...@sa...> - 2008-09-24 14:26:32
|
Dear all, This is to let you know that Salyens Ltd. is now accepting applications for a free license of our video codecs. These video codecs have been used in 3G video streaming applications since 2003, and commercially deployed by 3G operators and 3G service providers in both Europe and Asia. They offer interoperability with all recent and older 3G mobile phones, and an excellent video quality. While Salyens Ltd. has contributed source code to the PwLib/OpenH.323/Opal set of libraries in the past, mostly in the area of video, sadly some contractual obligations prevent us to do so again today. But with the recent Final Release of Opal v3.2 "Barnard", we chose to provide our video codecs - free of charge - as a binary Opal Codec plugin for Windows, Linux and Mac OSX (x86) for Opal based 3G video streaming applications. We are also looking at further contributions of source code in the area of audio (e.g. a Nellymoser ASAO codec plugin that was built with the same Final Release of Opal v3.2 "Barnard") if anyone is interested. We feel that the 3G video streaming market is now mature enough and want to popularize services for which the current pricing structure proved inadequate. By providing our video codecs for free, we intend to help lower the entry cost for new entrants into this market and help propel novel services. "Where is the catch?", you would say. To summarize... - These video codecs are licensed, free of charge, for use with Opal based 3G video streaming applications. That is, your application has to support calling to/from 3G video mobile phones, and be marketed as such. - Your application should be aimed at public deployment (internal/private endeavours need not apply) - You are to guarantee that no 3G video mobile phone end-user is located in the United Kingdom of Great Britain. [For example, your application could check at call setup the phone number's country code and manipulate media formats so as to select either the Salyens video codecs or any of the other video codecs already present in Opal.] - You have to be a corporate entity (government or individual need not apply) We will consider all applications based on the above criteria. The latest version of these video codecs was built with the Final Release of Opal v3.2 "Barnard", although it is known to work with older and newer versions of Opal. A new official build is scheduled every 4 months, or earlier if any major milestone is reached. Assistance and support are prioritized, thus the licensees of the aforementioned free offer may consider entering into an extended support agreement for use of these video codecs in a critical environment. Naturally, we would also welcome your licensing - for an upgrade price - our other video codecs targeted at professional video conferencing solutions, and offering interoperability with equipment from major manufacturers (e.g. Polycom, RADVision, Tandberg) in addition to 3G mobile phones. Or our customizable endpoint applications for Windows (ActiveX, MFC) and Linux that make use of the same professional video codecs. But if all you need is video streaming to/from 3G video mobile phones and other OpenH323/Opal endpoints, then the aforementioned free offer is perfectly sufficient. For further details and all enquiries: in...@sa... Best regards, The Salyens team. |
|
From: info <in...@sa...> - 2008-09-24 10:15:54
|
Dear all, This is to let you know that Salyens Ltd. is now accepting applications for a free license of our video codecs. These video codecs have been used in 3G video streaming applications since 2003, and commercially deployed by 3G operators and 3G service providers in both Europe and Asia. They offer interoperability with all recent and older 3G mobile phones, and an excellent video quality. While Salyens Ltd. has contributed source code to the PwLib/OpenH.323/Opal set of libraries in the past, mostly in the area of video, sadly some contractual obligations prevent us to do so again today. But with the recent Final Release of Opal v3.2 "Barnard", we chose to provide our video codecs - free of charge - as a binary Opal Codec plugin for Windows, Linux and Mac OSX (x86) for Opal based 3G video streaming applications. We are also looking at further contributions of source code in the area of audio (e.g. a Nellymoser ASAO codec plugin that was built with the same Final Release of Opal v3.2 "Barnard") if anyone is interested. We feel that the 3G video streaming market is now mature enough and want to popularize services for which the current pricing structure proved inadequate. By providing our video codecs for free, we intend to help lower the entry cost for new entrants into this market and help propel novel services. "Where is the catch?", you would say. To summarize... - These video codecs are licensed, free of charge, for use with Opal based 3G video streaming applications. That is, your application has to support calling to/from 3G video mobile phones, and be marketed as such. - Your application should be aimed at public deployment (internal/private endeavours need not apply) - You are to guarantee that no 3G video mobile phone end-user is located in the United Kingdom of Great Britain. [For example, your application could check at call setup the phone number's country code and manipulate media formats so as to select either the Salyens video codecs or any of the other video codecs already present in Opal.] - You have to be a corporate entity (government or individual need not apply) We will consider all applications based on the above criteria. The latest version of these video codecs was built with the Final Release of Opal v3.2 "Barnard", although it is known to work with older and newer versions of Opal. A new official build is scheduled every 4 months, or earlier if any major milestone is reached. Assistance and support are prioritized, thus the licensees of the aforementioned free offer may consider entering into an extended support agreement for use of these video codecs in a critical environment. Naturally, we would also welcome your licensing - for an upgrade price - our other video codecs targeted at professional video conferencing solutions, and offering interoperability with equipment from major manufacturers (e.g. Polycom, RADVision, Tandberg) in addition to 3G mobile phones. Or our customizable endpoint applications for Windows (ActiveX, MFC) and Linux that make use of the same professional video codecs. But if all you need is video streaming to/from 3G video mobile phones and other OpenH323/Opal endpoints, then the aforementioned free offer is perfectly sufficient. For further details and all enquiries: in...@sa... Best regards, The Salyens team. |
|
From: Jan W. <ja...@wi...> - 2008-09-04 23:53:40
|
Hi Andriy,
I've been bitten by this change, too. You have to detect the PWLib
version and put and #ifdef around the delete.
This is the code GnuGk uses:
// define hasDeletingSetStream for PWLib >= 1.11.2
#if PWLIB_MAJOR == 1
#if PWLIB_MINOR >= 11
#if PWLIB_BUILD >= 2
#define hasDeletingSetStream 1
#endif
#endif
#endif
...
#ifndef hasDeletingSetStream
delete logstream
#endif
Regards,
Jan
Andriy Pylypenko wrote:
> Hi,
>
> I'm using an Asterisk with chan_h323 module which is based on openh323.
> After upgrading to pwlib 1.12 I started to experience crashes during
> loading and unloading that module. The problem isn't stopper but is
> quite annoying so I've made an investigation and found out that the
> crash occurs in the following code:
>
> if (logstream) {
> PTrace::SetLevel(0);
> PTrace::SetStream(&cout);
> delete logstream; // APPLICATION CRASHES HERE
> logstream = NULL;
> }
>
> And here is the code from PTraceInfo::SetStream:
>
> void SetStream(ostream * newStream)
> {
> [skip]
> if (stream != &cerr && stream != &cout)
> delete stream;
> stream = newStream;
>
> However the pwlib prior 1.12.0 didn't delete the old stream:
>
> void PTrace::SetStream(ostream * s)
> {
> #ifndef __NUCLEUS_PLUS__
> if (s == NULL)
> s = &cerr;
> #endif
>
> if (PTraceMutex == NULL)
> PTraceStream = s;
> else {
> PWaitAndSignal m(*PTraceMutex);
> PTraceStream = s;
> }
> }
>
> IMHO this API change is too serious to be allowed without any
> compatibility shims.
>
> --
> Kind regards,
> Andriy Pylypenko
--
Jan Willamowius, ja...@wi..., http://www.gnugk.org/
|
|
From: Robert J. <rob...@bi...> - 2008-09-04 23:38:25
|
Fixed last night. Also, please move to the opalvoip mailing lists, the old openh323 ones are deprecated. Robert Jongbloed OPAL/OpenH323/PTLib Architect and Co-founder. > -----Original Message----- > From: ope...@li... [mailto:openh323- > dev...@li...] On Behalf Of Vyacheslav Frolov > Sent: Friday, 5 September 2008 3:22 AM > To: ope...@li... > Subject: [Openh323-devel] UpdateMediaFormat() recursive loop > > OpalMediaStream::UpdateMediaFormat() and > OpalMediaPatch::UpdateMediaFormat() > infinitely call each other (SVN 3 Sep version). > > 2008/09/04 20:34:18.930 H225 Caller:0xb79efbb0 H323RTP Attempting to > set dynamic RTP payload type: 96 > > #0 0x00b86626 in std::num_put<char, std::ostreambuf_iterator<char, > std::char_traits<char> > >::_M_group_int () from > /usr/lib/libstdc++.so.6 > #1 0x00b86ab7 in std::num_put<char, std::ostreambuf_iterator<char, > std::char_traits<char> > >::_M_pad () from /usr/lib/libstdc++.so.6 > #2 0x00b963d1 in std::num_put<char, std::ostreambuf_iterator<char, > std::char_traits<char> > >::_M_insert_int<long> () from > /usr/lib/libstdc++.so.6 > #3 0x00b9648f in std::num_put<char, std::ostreambuf_iterator<char, > std::char_traits<char> > >::do_put () from /usr/lib/libstdc++.so.6 > #4 0x00b9be6a in std::ostream::operator<< () from > /usr/lib/libstdc++.so.6 > #5 0x00ae1427 in PTime::AsString () from > /home/frolov/OpenH323/ptlib/lib/libpt_linux_x86_r.so.2.3-beta1 > #6 0x00ae473b in PTrace::Begin () from > /home/frolov/OpenH323/ptlib/lib/libpt_linux_x86_r.so.2.3-beta1 > #7 0x0808d7d9 in OpalMediaPatch::UpdateMediaFormat () > #8 0x004a2aa5 in OpalMediaStream::UpdateMediaFormat () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #9 0x004a75cd in OpalMediaPatch::Sink::UpdateMediaFormat () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #10 0x0808d87b in OpalMediaPatch::UpdateMediaFormat () > .......... > #3419 0x004a75cd in OpalMediaPatch::Sink::UpdateMediaFormat () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3420 0x0808d87b in OpalMediaPatch::UpdateMediaFormat () > #3421 0x004a2aa5 in OpalMediaStream::UpdateMediaFormat () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3422 0x0808d83f in OpalMediaPatch::UpdateMediaFormat () > #3423 0x004a2aa5 in OpalMediaStream::UpdateMediaFormat () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3424 0x004a75cd in OpalMediaPatch::Sink::UpdateMediaFormat () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3425 0x0808d87b in OpalMediaPatch::UpdateMediaFormat () > #3426 0x004a2aa5 in OpalMediaStream::UpdateMediaFormat () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3427 0x0808d83f in OpalMediaPatch::UpdateMediaFormat () > #3428 0x004a2aa5 in OpalMediaStream::UpdateMediaFormat () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3429 0x0075c017 in H323_RealTimeChannel::SetDynamicRTPPayloadType () > from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3430 0x00758e0e in H323_RTP_UDP::OnReceivedAckPDU () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3431 0x0075a35b in H323_RTPChannel::OnReceivedAckPDU () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3432 0x0075a1d9 in H323_RealTimeChannel::OnReceivedAckPDU () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3433 0x0074da25 in H245NegLogicalChannel::HandleOpenAck () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3434 0x0074ea7a in H245NegLogicalChannels::HandleOpenAck () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3435 0x00733301 in H323Connection::OnH245Response () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3436 0x007330b3 in H323Connection::HandleControlPDU () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3437 0x0073f7cd in H323Connection::HandleControlData () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3438 0x0072ff11 in H323Connection::HandleTunnelPDU () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3439 0x007373ca in H323Connection::HandleSignalPDU () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3440 0x0073755b in H323Connection::HandleSignallingChannel () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3441 0x00731766 in H323Connection::StartOutgoing () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3442 0x0073fd4c in H323Connection::StartOutgoing_PNotifier::Call () > from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3443 0x00ae3376 in PSimpleThread::Main () from > /home/frolov/OpenH323/ptlib/lib/libpt_linux_x86_r.so.2.3-beta1 > #3444 0x00ac8b20 in PThread::PX_ThreadStart () from > /home/frolov/OpenH323/ptlib/lib/libpt_linux_x86_r.so.2.3-beta1 > #3445 0x001163ae in start_thread () from /lib/tls/libpthread.so.0 > #3446 0x00cd7aee in clone () from /lib/tls/libc.so.6 > > ********************************************************************* > ********************************** > This message and any attachments (the "message") are confidential and > intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. Orange Business Services > shall not be liable for the message if altered, changed or > falsified. If you are not the intended addressee of this message, > please cancel it immediately and inform > the sender. > ********************************************************************* > ********************************** > > --------------------------------------------------------------------- > ---- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Openh323-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openh323-devel |
|
From: Robert J. <ro...@vo...> - 2008-09-04 23:30:35
|
Fixed last night. Also, please move to the opalvoip mailing lists, the old openh323 ones are deprecated. Robert Jongbloed OPAL/OpenH323/PTLib Architect and Co-founder. > -----Original Message----- > From: ope...@li... [mailto:openh323- > dev...@li...] On Behalf Of Vyacheslav Frolov > Sent: Friday, 5 September 2008 3:22 AM > To: ope...@li... > Subject: [Openh323-devel] UpdateMediaFormat() recursive loop > > OpalMediaStream::UpdateMediaFormat() and > OpalMediaPatch::UpdateMediaFormat() > infinitely call each other (SVN 3 Sep version). > > 2008/09/04 20:34:18.930 H225 Caller:0xb79efbb0 H323RTP Attempting to > set dynamic RTP payload type: 96 > > #0 0x00b86626 in std::num_put<char, std::ostreambuf_iterator<char, > std::char_traits<char> > >::_M_group_int () from > /usr/lib/libstdc++.so.6 > #1 0x00b86ab7 in std::num_put<char, std::ostreambuf_iterator<char, > std::char_traits<char> > >::_M_pad () from /usr/lib/libstdc++.so.6 > #2 0x00b963d1 in std::num_put<char, std::ostreambuf_iterator<char, > std::char_traits<char> > >::_M_insert_int<long> () from > /usr/lib/libstdc++.so.6 > #3 0x00b9648f in std::num_put<char, std::ostreambuf_iterator<char, > std::char_traits<char> > >::do_put () from /usr/lib/libstdc++.so.6 > #4 0x00b9be6a in std::ostream::operator<< () from > /usr/lib/libstdc++.so.6 > #5 0x00ae1427 in PTime::AsString () from > /home/frolov/OpenH323/ptlib/lib/libpt_linux_x86_r.so.2.3-beta1 > #6 0x00ae473b in PTrace::Begin () from > /home/frolov/OpenH323/ptlib/lib/libpt_linux_x86_r.so.2.3-beta1 > #7 0x0808d7d9 in OpalMediaPatch::UpdateMediaFormat () > #8 0x004a2aa5 in OpalMediaStream::UpdateMediaFormat () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #9 0x004a75cd in OpalMediaPatch::Sink::UpdateMediaFormat () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #10 0x0808d87b in OpalMediaPatch::UpdateMediaFormat () > .......... > #3419 0x004a75cd in OpalMediaPatch::Sink::UpdateMediaFormat () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3420 0x0808d87b in OpalMediaPatch::UpdateMediaFormat () > #3421 0x004a2aa5 in OpalMediaStream::UpdateMediaFormat () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3422 0x0808d83f in OpalMediaPatch::UpdateMediaFormat () > #3423 0x004a2aa5 in OpalMediaStream::UpdateMediaFormat () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3424 0x004a75cd in OpalMediaPatch::Sink::UpdateMediaFormat () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3425 0x0808d87b in OpalMediaPatch::UpdateMediaFormat () > #3426 0x004a2aa5 in OpalMediaStream::UpdateMediaFormat () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3427 0x0808d83f in OpalMediaPatch::UpdateMediaFormat () > #3428 0x004a2aa5 in OpalMediaStream::UpdateMediaFormat () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3429 0x0075c017 in H323_RealTimeChannel::SetDynamicRTPPayloadType () > from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3430 0x00758e0e in H323_RTP_UDP::OnReceivedAckPDU () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3431 0x0075a35b in H323_RTPChannel::OnReceivedAckPDU () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3432 0x0075a1d9 in H323_RealTimeChannel::OnReceivedAckPDU () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3433 0x0074da25 in H245NegLogicalChannel::HandleOpenAck () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3434 0x0074ea7a in H245NegLogicalChannels::HandleOpenAck () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3435 0x00733301 in H323Connection::OnH245Response () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3436 0x007330b3 in H323Connection::HandleControlPDU () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3437 0x0073f7cd in H323Connection::HandleControlData () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3438 0x0072ff11 in H323Connection::HandleTunnelPDU () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3439 0x007373ca in H323Connection::HandleSignalPDU () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3440 0x0073755b in H323Connection::HandleSignallingChannel () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3441 0x00731766 in H323Connection::StartOutgoing () from > /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3442 0x0073fd4c in H323Connection::StartOutgoing_PNotifier::Call () > from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 > #3443 0x00ae3376 in PSimpleThread::Main () from > /home/frolov/OpenH323/ptlib/lib/libpt_linux_x86_r.so.2.3-beta1 > #3444 0x00ac8b20 in PThread::PX_ThreadStart () from > /home/frolov/OpenH323/ptlib/lib/libpt_linux_x86_r.so.2.3-beta1 > #3445 0x001163ae in start_thread () from /lib/tls/libpthread.so.0 > #3446 0x00cd7aee in clone () from /lib/tls/libc.so.6 > > ********************************************************************* > ********************************** > This message and any attachments (the "message") are confidential and > intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. Orange Business Services > shall not be liable for the message if altered, changed or > falsified. If you are not the intended addressee of this message, > please cancel it immediately and inform > the sender. > ********************************************************************* > ********************************** > > --------------------------------------------------------------------- > ---- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Openh323-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openh323-devel |
|
From: Vyacheslav F. <v.f...@or...> - 2008-09-04 17:24:50
|
OpalMediaStream::UpdateMediaFormat() and OpalMediaPatch::UpdateMediaFormat() infinitely call each other (SVN 3 Sep version). 2008/09/04 20:34:18.930 H225 Caller:0xb79efbb0 H323RTP Attempting to set dynamic RTP payload type: 96 #0 0x00b86626 in std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::_M_group_int () from /usr/lib/libstdc++.so.6 #1 0x00b86ab7 in std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::_M_pad () from /usr/lib/libstdc++.so.6 #2 0x00b963d1 in std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::_M_insert_int<long> () from /usr/lib/libstdc++.so.6 #3 0x00b9648f in std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::do_put () from /usr/lib/libstdc++.so.6 #4 0x00b9be6a in std::ostream::operator<< () from /usr/lib/libstdc++.so.6 #5 0x00ae1427 in PTime::AsString () from /home/frolov/OpenH323/ptlib/lib/libpt_linux_x86_r.so.2.3-beta1 #6 0x00ae473b in PTrace::Begin () from /home/frolov/OpenH323/ptlib/lib/libpt_linux_x86_r.so.2.3-beta1 #7 0x0808d7d9 in OpalMediaPatch::UpdateMediaFormat () #8 0x004a2aa5 in OpalMediaStream::UpdateMediaFormat () from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 #9 0x004a75cd in OpalMediaPatch::Sink::UpdateMediaFormat () from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 #10 0x0808d87b in OpalMediaPatch::UpdateMediaFormat () .......... #3419 0x004a75cd in OpalMediaPatch::Sink::UpdateMediaFormat () from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 #3420 0x0808d87b in OpalMediaPatch::UpdateMediaFormat () #3421 0x004a2aa5 in OpalMediaStream::UpdateMediaFormat () from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 #3422 0x0808d83f in OpalMediaPatch::UpdateMediaFormat () #3423 0x004a2aa5 in OpalMediaStream::UpdateMediaFormat () from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 #3424 0x004a75cd in OpalMediaPatch::Sink::UpdateMediaFormat () from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 #3425 0x0808d87b in OpalMediaPatch::UpdateMediaFormat () #3426 0x004a2aa5 in OpalMediaStream::UpdateMediaFormat () from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 #3427 0x0808d83f in OpalMediaPatch::UpdateMediaFormat () #3428 0x004a2aa5 in OpalMediaStream::UpdateMediaFormat () from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 #3429 0x0075c017 in H323_RealTimeChannel::SetDynamicRTPPayloadType () from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 #3430 0x00758e0e in H323_RTP_UDP::OnReceivedAckPDU () from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 #3431 0x0075a35b in H323_RTPChannel::OnReceivedAckPDU () from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 #3432 0x0075a1d9 in H323_RealTimeChannel::OnReceivedAckPDU () from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 #3433 0x0074da25 in H245NegLogicalChannel::HandleOpenAck () from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 #3434 0x0074ea7a in H245NegLogicalChannels::HandleOpenAck () from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 #3435 0x00733301 in H323Connection::OnH245Response () from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 #3436 0x007330b3 in H323Connection::HandleControlPDU () from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 #3437 0x0073f7cd in H323Connection::HandleControlData () from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 #3438 0x0072ff11 in H323Connection::HandleTunnelPDU () from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 #3439 0x007373ca in H323Connection::HandleSignalPDU () from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 #3440 0x0073755b in H323Connection::HandleSignallingChannel () from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 #3441 0x00731766 in H323Connection::StartOutgoing () from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 #3442 0x0073fd4c in H323Connection::StartOutgoing_PNotifier::Call () from /home/frolov/OpenH323/opal/lib/libopal_linux_x86_r.so.3.3-beta1 #3443 0x00ae3376 in PSimpleThread::Main () from /home/frolov/OpenH323/ptlib/lib/libpt_linux_x86_r.so.2.3-beta1 #3444 0x00ac8b20 in PThread::PX_ThreadStart () from /home/frolov/OpenH323/ptlib/lib/libpt_linux_x86_r.so.2.3-beta1 #3445 0x001163ae in start_thread () from /lib/tls/libpthread.so.0 #3446 0x00cd7aee in clone () from /lib/tls/libc.so.6 ******************************************************************************************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. Orange Business Services shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ******************************************************************************************************* |
|
From: Carl C. <CCa...@ma...> - 2008-09-04 16:32:04
|
I am out of the office Sept 2-5. If you need assistance during that time, you can contact Lloyd at lhe...@hi.... |
|
From: Andriy P. <bam...@gm...> - 2008-09-04 10:42:32
|
Hi,
I'm using an Asterisk with chan_h323 module which is based on openh323.
After upgrading to pwlib 1.12 I started to experience crashes during
loading and unloading that module. The problem isn't stopper but is
quite annoying so I've made an investigation and found out that the
crash occurs in the following code:
if (logstream) {
PTrace::SetLevel(0);
PTrace::SetStream(&cout);
delete logstream; // APPLICATION CRASHES HERE
logstream = NULL;
}
And here is the code from PTraceInfo::SetStream:
void SetStream(ostream * newStream)
{
[skip]
if (stream != &cerr && stream != &cout)
delete stream;
stream = newStream;
However the pwlib prior 1.12.0 didn't delete the old stream:
void PTrace::SetStream(ostream * s)
{
#ifndef __NUCLEUS_PLUS__
if (s == NULL)
s = &cerr;
#endif
if (PTraceMutex == NULL)
PTraceStream = s;
else {
PWaitAndSignal m(*PTraceMutex);
PTraceStream = s;
}
}
IMHO this API change is too serious to be allowed without any
compatibility shims.
--
Kind regards,
Andriy Pylypenko
|
|
From: Robert J. <rob...@bi...> - 2008-08-19 08:43:24
|
OK, fixed in trunk. Why it was that way for RTEMS and not every other platform is beyond me! Robert Jongbloed OPAL/OpenH323 Architect and Co-founder. > -----Original Message----- > From: ope...@li... [mailto:openh323- > dev...@li...] On Behalf Of Thien Nguyen > Sent: Tuesday, 19 August 2008 6:03 PM > To: ope...@li... > Subject: [Openh323-devel] Bug : PRandom::Number() is not thread-safe > with VC++ compiler. > > Dear OpenH323 developers, > > With VC++ compiler ( and some other compilers), the static object at > block scope is not thread-safe. > > http://blogs.msdn.com/oldnewthing/archive/2004/03/08/85901.aspx > > > Therefore, the following method is not thread-safe. > > // pwlib/src/ptclib/random.cxx > > unsigned PRandom::Number() > { > #ifndef P_RTEMS > static PMutex mutex; // <-- not thread-safe > #endif > PWaitAndSignal wait(mutex); > > static PRandom rand; > return rand; > } > > Here is a "error" scenario : > > a. First thread comes and try to initialize the static object > "PMutex mutex" but not finish this task. > > b. Second thread comes and thinks that the static object PMutex > mutex was initialize. Therefore, it excecutes "PWaitAndSignal > wait(mutex)" : bug will happen because the mutex is not completely > initialized. > > Suggestion : move "static PMutex mutex;" into file scope. > > Thank for reading. > > > > --------------------------------------------------------------------- > ---- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Openh323-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openh323-devel |
|
From: Thien N. <thi...@ya...> - 2008-08-19 08:02:42
|
Dear OpenH323 developers, With VC++ compiler ( and some other compilers), the static object at block scope is not thread-safe. http://blogs.msdn.com/oldnewthing/archive/2004/03/08/85901.aspx Therefore, the following method is not thread-safe. // pwlib/src/ptclib/random.cxx unsigned PRandom::Number() { #ifndef P_RTEMS static PMutex mutex; // <-- not thread-safe #endif PWaitAndSignal wait(mutex); static PRandom rand; return rand; } Here is a "error" scenario : a. First thread comes and try to initialize the static object "PMutex mutex" but not finish this task. b. Second thread comes and thinks that the static object PMutex mutex was initialize. Therefore, it excecutes "PWaitAndSignal wait(mutex)" : bug will happen because the mutex is not completely initialized. Suggestion : move "static PMutex mutex;" into file scope. Thank for reading. |
|
From: Simon H. <s....@pa...> - 2008-07-26 05:03:34
|
Maninder
The call flow is a follows
When registering
endpoint Gatekeeper other gatekeeper
GCF -->|
|<--- GRQ
RRQ -->|
|<--- RCF
When placing a call
ARQ -->|
LRQ --->|
|<--- LCF
|<-- ACF
You can use GnuGk to test the functionality of a H323 gatekeeper. It was
based on OpenH323 and has now migrated to H323plus.
Simon
-----Original Message-----
From: ope...@li...
[mailto:ope...@li...]On Behalf Of maninder
reddy
Sent: Monday, 21 July 2008 8:03 PM
To: ope...@li...
Subject: [Openh323-devel] Regarding Receiving LRQ Messages From GK
Hello Sir ,
This is Venkatesh , I am working with OpenH323 Stack and i
face the following problem,
Firstly openH323 gets registered with the gate keeper by sending GRQ
followed by RRQ messages (it also receives reply grom GK). But later when it
receives LRQ message from the Gatekeeper , the corresponding function in
H323 stack is not getting invoked.
I also doubt if any settings needs to be made in the stack for receiving
LRQ messages(like when you set DisableH245Tunneling to TRUE H245Tunneling
will be disabled.)
I would like to know the function in stack that must get invoked when we
receive LRQ message from Gatekeeper , so that i can trace the flow further .
Also I would like to know name of the thread , which is continously
listening for messages from GK.
Thanks in Advance.
Thanks and Regards,
A.Venkatesh.
The information contained in this electronic message and any attachments
to this message are intended for the exclusive use of the addressee(s) and
may contain proprietary, confidential or privileged information. If you are
not the intended recipient, you should not disseminate, distribute or copy
this e-mail. Please notify the sender immediately and destroy all copies of
this message and any attachments contained in it. Contact your Administrator
for further information.
|
|
From: Robert J. <rob...@bi...> - 2008-07-25 23:52:02
|
First, OpenH323 is now deprecated, please move to the OPAL lists at http://sourceforge.net/projects/opalvoip The version numbers are usually in sync: PTLib 2.2.1 goes with OPAL 3.2.1 and PTLib 2.2.2 goes with OPAL 3.2.2 PWLib 1.10.2 is VERY old. It has no hope of working with current OPAL. Get the latest versions from the new Source Forge project. Robert Jongbloed OPAL/OpenH323 Architect and Co-founder. From: ope...@li... [mailto:ope...@li...] On Behalf Of Manh Phan Thi Sent: Wednesday, 2 July 2008 8:04 PM To: ope...@li... Subject: [Openh323-devel] FW: Problem with building Opal Hi, I want to ask two questions. Can you help me? 1. First, I want to know which Pwlib's version is compatible with which Opal's version? 2. I built pwlib-v1_10_2 successfully. After that, I build opal-v2_2_1 , but not success! **. I build OPAL_lib file successfully. **. When building OPAL_dll file, there are some errors as below : --------------------Configuration: OPAL_dll - Win32 Debug-------------------- Merging exported library symbols MergeSym version 1.4.0 on Windows XP by Equivalence No changes to symbols. Compiling resources... Compiling... dllmain.cxx Linking... opald.def : error LNK2001: unresolved external symbol _filter_dc_notch opald.def : error LNK2001: unresolved external symbol _fixed_point opald.def : error LNK2001: unresolved external symbol _kiss_fft opald.def : error LNK2001: unresolved external symbol _kiss_fft_alloc opald.def : error LNK2001: unresolved external symbol _kiss_fft_cleanup opald.def : error LNK2001: unresolved external symbol _kiss_fft_stride opald.def : error LNK2001: unresolved external symbol _kiss_fftr opald.def : error LNK2001: unresolved external symbol _kiss_fftr_alloc opald.def : error LNK2001: unresolved external symbol _kiss_fftri opald.def : error LNK2001: unresolved external symbol _spx_cos opald.def : error LNK2001: unresolved external symbol _spx_fft opald.def : error LNK2001: unresolved external symbol _spx_fft_destroy opald.def : error LNK2001: unresolved external symbol _spx_fft_float opald.def : error LNK2001: unresolved external symbol _spx_fft_init opald.def : error LNK2001: unresolved external symbol _spx_ifft opald.def : error LNK2001: unresolved external symbol _spx_ifft_float ..\..\lib/opald.lib : fatal error LNK1120: 16 unresolved externals LINK : fatal error LNK1141: failure during build of exports file Error executing link.exe. opald.dll - 18 error(s), 0 warning(s) I know that the cause is in Project-> Settings-> Link. But I don't know exactly. Help me fix it! Thanks you so much, Manh Phan |
|
From: Robert J. <rob...@bi...> - 2008-07-25 23:43:50
|
First, OpenH323 is now deprecated, please move to the OPAL project at http://sourceforge.net/projects/opalvoip or the H323Plus project at http://sourceforge.net/projects/h323plus . Second, LRQ is usually used for client to gatekeeper or gatekeeper to gatekeeper, it is very strange that you would be getting it from gatekeeper to client. Building support into an application is possible but a fair bit of work. In 8 years no one has ever needed it before! Robert Jongbloed OPAL/OpenH323 Architect and Co-founder. From: ope...@li... [mailto:ope...@li...] On Behalf Of maninder reddy Sent: Monday, 21 July 2008 8:03 PM To: ope...@li... Subject: [Openh323-devel] Regarding Receiving LRQ Messages From GK Hello Sir , This is Venkatesh , I am working with OpenH323 Stack and i face the following problem, Firstly openH323 gets registered with the gate keeper by sending GRQ followed by RRQ messages (it also receives reply grom GK). But later when it receives LRQ message from the Gatekeeper , the corresponding function in H323 stack is not getting invoked. I also doubt if any settings needs to be made in the stack for receiving LRQ messages(like when you set DisableH245Tunneling to TRUE H245Tunneling will be disabled.) I would like to know the function in stack that must get invoked when we receive LRQ message from Gatekeeper , so that i can trace the flow further . Also I would like to know name of the thread , which is continously listening for messages from GK. Thanks in Advance. Thanks and Regards, A.Venkatesh. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it. Contact your Administrator for further information. |
|
From: maninder r. <man...@ta...> - 2008-07-21 09:58:44
|
Hello Sir ,
This is Venkatesh , I am working with OpenH323 Stack and i face the following problem,
Firstly openH323 gets registered with the gate keeper by sending GRQ followed by RRQ messages (it also receives reply grom GK). But later when it receives LRQ message from the Gatekeeper , the corresponding function in H323 stack is not getting invoked.
I also doubt if any settings needs to be made in the stack for receiving LRQ messages(like when you set DisableH245Tunneling to TRUE H245Tunneling will be disabled.)
I would like to know the function in stack that must get invoked when we receive LRQ message from Gatekeeper , so that i can trace the flow further . Also I would like to know name of the thread , which is continously listening for messages from GK.
Thanks in Advance.
Thanks and Regards,
A.Venkatesh.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.
Contact your Administrator for further information.
|
|
From: Manh P. T. <pt...@tm...> - 2008-07-02 10:04:54
|
Hi,
I want to ask two questions. Can you help me?
1. First, I want to know which Pwlib's version is compatible with which
Opal's version?
2. I built pwlib-v1_10_2 successfully. After that, I build opal-v2_2_1 , but
not success!
**. I build OPAL_lib file successfully.
**. When building OPAL_dll file, there are some errors as below
:
--------------------Configuration: OPAL_dll - Win32
Debug--------------------
Merging exported library symbols
MergeSym version 1.4.0 on Windows XP by Equivalence
No changes to symbols.
Compiling resources...
Compiling...
dllmain.cxx
Linking...
opald.def : error LNK2001: unresolved external symbol _filter_dc_notch
opald.def : error LNK2001: unresolved external symbol _fixed_point
opald.def : error LNK2001: unresolved external symbol _kiss_fft
opald.def : error LNK2001: unresolved external symbol _kiss_fft_alloc
opald.def : error LNK2001: unresolved external symbol _kiss_fft_cleanup
opald.def : error LNK2001: unresolved external symbol _kiss_fft_stride
opald.def : error LNK2001: unresolved external symbol _kiss_fftr
opald.def : error LNK2001: unresolved external symbol _kiss_fftr_alloc
opald.def : error LNK2001: unresolved external symbol _kiss_fftri
opald.def : error LNK2001: unresolved external symbol _spx_cos
opald.def : error LNK2001: unresolved external symbol _spx_fft
opald.def : error LNK2001: unresolved external symbol _spx_fft_destroy
opald.def : error LNK2001: unresolved external symbol _spx_fft_float
opald.def : error LNK2001: unresolved external symbol _spx_fft_init
opald.def : error LNK2001: unresolved external symbol _spx_ifft
opald.def : error LNK2001: unresolved external symbol _spx_ifft_float
..\..\lib/opald.lib : fatal error LNK1120: 16 unresolved externals
LINK : fatal error LNK1141: failure during build of exports file
Error executing link.exe.
opald.dll - 18 error(s), 0 warning(s)
I know that the cause is in Project-> Settings-> Link. But I
don't know exactly.
Help me fix it!
Thanks you so much,
Manh Phan
|
20 messages has been excluded from this view by a project administrator.