March 2011 - h323plus - lists.packetizer.com

crash when SessionID=0
by Marek Domaracky 13 Jun '11

13 Jun '11

Hi, I'm working on H.239 implementation and find out that devices might ask SessionID=0 for a new video channel. In particular I did a test with Mirial. I was checking the thread http://lists.packetizer.com/pipermail/h323plus/2009-December/001269.html and it's mentioned that the SessionID=0 is invalid. I know it's not following the standard as for RTPSession the range is from 1..255, but for compatibility, don't you think we should allow it? I did a test call from Mirial to Tandberg and Tandberg didn't have a problem with it. The lines involved are rtp.cxx from PAssert(id > 0 && id < 256, PInvalidParameter); to PAssert(id >= 0 && id < 256, PInvalidParameter); and h323.cxx // We must have a valid sessionID if (sessionID < 1 || sessionID > 255) to if (sessionID < 0 || sessionID > 255) Thanks, Marek

8 18

Re: [h323plus] [Openh323gk-users] Compile failure in h323plus library
by Jan Willamowius 21 Mar '11

21 Mar '11

PS: It turns out, I should have done a fresh compile. ;-) One of Simon's changes to PTLib has been reverted out on Friday, breaking H323Plus. Until we have checked out whether H323Plus or PTLib will adapt, you can comment out the 'mark' parameter on the offending line 588 in codec.cxx: if (rawDataChannel->Write(data, length /*, mark */)) Regards, Jan Jan Willamowius wrote: > Hi Robert, > > I also run H323Plus and PTLib from CVS and I don't see that error. > > I would suggest you try a fresh > > make clean ; ./configure ; make optnoshared > > for all libs. > > Regards, > Jan > > -- > Jan Willamowius, jan(a)willamowius.de, http://www.gnugk.org/ > > > Robert Kulagowski wrote: > > This is with latest svn of ptlib and cvs of h323plus: > > > > > > rkulagow@usilwdvcgk01:~/h323plus$ make debugnoshared > > make DEBUG=1 P_SHAREDLIB=0 default_target > > make[1]: Entering directory `/home/rkulagow/h323plus' > > make[1]: Leaving directory `/home/rkulagow/h323plus' > > make -C src debugnoshared > > make[1]: Entering directory `/home/rkulagow/h323plus/src' > > make DEBUG=1 P_SHAREDLIB=0 default_target > > make[2]: Entering directory `/home/rkulagow/h323plus/src' > > [CC] codecs.cxx > > codecs.cxx: In member function Boolean H323Codec::WriteRaw(void*, PINDEX, void*) > > codecs.cxx:588: error: no matching function for call to > > Channel::Write(void*&, PINDEX&, void*&) > > home/rkulagow/ptlib/include/ptlib/channel.h:418: note: candidates are: > > virtual PBoolean PChannel::Write(const void*, PINDEX) > > /home/rkulagow/ptlib/include/ptlib/channel.h:702: note: > > virtual PBoolean PChannel::Write(const std::vector<iovec, > > std::allocator<iovec> >&) > > /home/rkulagow/ptlib/include/ptlib/videoio.h: At global scope: > > /home/rkulagow/ptlib/include/ptlib/videoio.h:1165: warning: > > Plugin_PVideoInputDevice_FakeVideo_loaderdefined but not used > > /home/rkulagow/ptlib/include/ptlib/videoio.h:1172: warning: > > Plugin_PVideoInputDevice_FFMPEG_loaderdefined but not used > > /home/rkulagow/ptlib/include/ptlib/videoio.h:1176: warning: > > Plugin_PVideoInputDevice_YUVFile_loaderdefined but not used > > /home/rkulagow/ptlib/include/ptlib/pluginmgr.h:167: warning: > > FactoryLoader::PluginLoaderStartup_loaderdefined but not used > > make[2]: *** [/home/rkulagow/h323plus/lib/obj_d_s/codecs.o] Error 1 > > make[2]: Leaving directory `/home/rkulagow/h323plus/src' > > make[1]: *** [debugnoshared] Error 2 > > make[1]: Leaving directory `/home/rkulagow/h323plus/src' > > make: *** [debugnoshared] Error 2 -- Jan Willamowius, jan(a)willamowius.de, http://www.gnugk.org/

1 0

[Fwd: Re: Silk codec support]
by Łukasz Czekierda 17 Mar '11

17 Mar '11

Dear Simon, Robert and all H323Plus Team, Thanks for your very fast answer. I have successfully built ptlib, h323plus (1.22) with silk codec and simple. I put silk_ptplugin.dll, iLBC_ptplugin.dll and gsm0610_ptplugin.dll into c:\pwlib_plugins (then also to c:\ptlib_plugins). Simple runs OK on XP and Windows 7, quality of G.711 and iLBC (both 13k and 15k) is good, but neither gsm nor silk work. There are some static, MOS is about 1... Additionally, simple app logs SKP_Silk_Encode returned -4 every few seconds. Am I doing anything wrong? Regards, Łukasz -------- Wiadomość oryginalna -------- Robert I have checked the code into the h323plus CVS. There is no official ITU Generic identifier yet so it is using a Packetizer Identifer for the moment. You can contact me offlist to discuss. Simon -----Original Message----- From: h323plus-bounces(a)lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Robert Jongbloed Sent: Wednesday, January 12, 2011 9:26 AM To: h323plus(a)lists.packetizer.com Subject: Re: [h323plus] Silk codec support I added SILK to OPAL a couple of months back. Unfortunately it was SIP only as I did not know what the H.245 encoding is for SILK, if any. Now that I see there is at least a proposed standard, this should be able to be finished in a few minutes. It would be really nice if the two systems could use the same code for this. Robert Jongbloed OPAL/OpenH323/PTLib Architect and Co-founder. > -----Original Message----- > From: h323plus-bounces(a)lists.packetizer.com [mailto:h323plus- > bounces(a)lists.packetizer.com] On Behalf Of Simon Horne > Sent: Tuesday, 11 January 2011 9:32 PM > To: 'Łukasz Czekierda' > Cc: h323plus(a)lists.packetizer.com > Subject: Re: [h323plus] Silk codec support > > Lukasz > > The issue is there is no definition of Silk in H.323 > > I wrote a submission to the ITU at the last meeting for inclusion > http://wftp3.itu.int/av-arch/avc-site/2009-2012/1011_Res/AVD-3994.zip > > The stumbling block is that SILK has defined dynamic payloads for each > bitrate for interop with Skype. In H.323 you cannot tell the remote > what payload to send, the remote will tell you want it will send. This > becomes an > issue if you are bridging to skype. There is a work around (submitted > by Avaya for a different issue but same meeting) to include in the > OLCack the payload that you expect the remote to send you. > > I have a development H.323 silk plugin (8k and 16k bitrate) and I will > commit them after the next stable release as it requires audio > capability merging which needs to be committed. The idea is there is 1 > silk capability > for the different bitrates (rather than a capability for each bitrate) > and you negotiate the actual bitrate by merging your local caps with > the caps in > the TCS. > > Simon > > > -----Original Message----- > From: h323plus-bounces(a)lists.packetizer.com > [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Lukasz Czekierda > Sent: Tuesday, January 11, 2011 7:42 PM > To: h323plus(a)lists.packetizer.com > Subject: [h323plus] Silk codec support > > Dear H.323Plus team, > > I have a question regarding support for skype's silk codec. Do you > plan to support it soon? Maybe you have already started development/integration? Do > you expect any obstacles? > > Best regards, > Łukasz Czekierda

2 2

Dropped H323 packets
by Dennis Muhlestein 16 Mar '11

16 Mar '11

I've been battling for some time go get all my call flows working with H323. A constantly re-appearing issue is that the kernel is dropping packets for part of the H323 protocol. The offending code is in nf_conntrack_h323_main.c I'll make one call, and the call will work, but the next the kernel will drop packets. I've worked around a number of these issues, but this one is stumping me currently. Call flow: Call a hold server through a gatekeeper (H.460.18/19 because we're NATted) Hold server transfers to another machine and call is completed. Problem: 1st call works. At transfer, Facility message is sent from hold server back to gatekeeper, gatekeeper forwards to phone. phone computer adds IP address of target phone even though that call is placed through a gatekeeper. Expect table has ip addresses of target phone and gatekeeper. 2nd call phone drops facility packet at transfer and call fails. Kernel message (I added a couple debugging messages just to be sure) <7>[ 312.181335] nf_ct_q931: process_q931 facility. <7>[ 312.181579] nf_ct_q931: Facility <4>[ 312.181915] nf_ct_q931: packet dropped <0>[ 312.182037] nf_ct_Q.931: dropping packetIN=eth0 OUT= MAC=38:e7:d8:7a:20:99:00:0b:86:42:1b:40:08:00:45:00:00:8b:3b:e1:40:00:3d:06:54:c4:0a:14:91:10:0a:14:07:90:06:b8:d1:a1:23:92:8b:34:1c:c5:d6:c4:80:18:00:fb:7b:9e:00:00:01:01:08:0a:1e:30:fe:d0:ff:ff:ff:b2:03:00:00:57:08:02:e0:b0:62:1c:00:7e:00:49:05:26:d0:06:00:08:91:4a:00:04:00:0a:14:91 SRC=10.20.145.16 DST=10.20.7.144 LEN=139 TOS=0x00 PREC=0x00 TTL=61 ID=15329 DF PROTO=TCP SPT=1720 DPT=53665 SEQ=596806452 ACK=482727620 WINDOW=251 RES=0x00 ACK PSH URGP=0 OPT (0101080A1E30FED0FFFFFFB2) Attached network trace 65.37.255.198 is the hold server. 10.20.145.16 is my test gatekeeper. 10.20.7.144 is my test phone. Here is what the expect table looks like after the 1st call: 235 l3proto = 2 proto=17 src=10.20.145.16 dst=10.20.7.144 sport=0 dport=5024 235 l3proto = 2 proto=17 src=10.20.145.16 dst=10.20.7.144 sport=0 dport=5025 229 l3proto = 2 proto=17 src=10.20.145.16 dst=10.20.7.144 sport=0 dport=5023 229 l3proto = 2 proto=17 src=10.20.145.16 dst=10.20.7.144 sport=0 dport=5022 229 l3proto = 2 proto=17 src=10.20.7.144 dst=10.20.145.16 sport=0 dport=6769 215 l3proto = 2 proto=6 src=10.20.145.16 dst=10.20.7.144 sport=0 dport=1720 PERMANENT 234 l3proto = 2 proto=6 src=10.20.7.144 dst=10.20.145.16 sport=0 dport=1720 PERMANENT 235 l3proto = 2 proto=17 src=10.20.145.16 dst=10.20.7.144 sport=0 dport=5027 234 l3proto = 2 proto=6 src=10.20.7.144 dst=10.20.145.12 sport=0 dport=1720 235 l3proto = 2 proto=17 src=10.20.145.16 dst=10.20.7.144 sport=0 dport=5026 The 2nd to bottom line I believe is the offending line. Perhaps h323 conntrack doesn't know about gatekeepers, or perhaps we could do something else to avoid this, but so far I haven't found a solution. Any thoughts? Bug? Kernel 2.6.32.17. Unfortunately, I don't have control over the target platform and this module will be used so I'm trying to find some way around this on the software side. Perhaps there is a way to send a fake packet that will clear the entry or something. I'm wondering if I can do anything on the h323 side in terms of PDUs I send that might persuade the kernel to drop the entry from the expect table. Thanks Dennis

2 3

problem with release build of latest h323plus with suggested ptlib
by Vladimir Fekete 02 Mar '11

02 Mar '11

Hello all, when I tried to build (windows 7, visual studio 2010, x86) last h323plus - 1.22.0 01/11/2011; against suggested ptlib - 2.8.3 23/12/2010; (both taken from the h323plus page) I've got an error in h323plus "release" build 1>src\h323pluginmgr.cxx(2114): error C2039: 'FlowControl' : is not a member of 'PVideoChannel' 1> C:\work\kitchen\ptlib\include\ptlib/video.h(53) : see declaration of 'PVideoChannel' and it is true, FlowControl really is not a member of PVideoChannel in ptlib 2.8.3 (I used to compile h323plus against higher versions of ptlib (such as 2.10.0) so I did not noticed this before. I also have not found any note about this in mailing list. Does anybody ran into same problem ? Best regards, Vladimir Fekete P.S. I'm testing different versions of ptlib/opal/h323plus because I'm trying to find release code of h323's h.264 video codec which would run with opal without problems

2 1

RTP Packet Issue
by kc ooi 02 Mar '11

02 Mar '11

Dear H323plus Team members, Recently, I have found some issue when I am doing H.323 testing with polycom system (eg. PVX 8.0.2) and checked the packet traffic using wireshark. I use RTP stream analysis of wireshark for viewing the result, and I notice that every packet(which is final slice of a frame, contain Marker=1) has a status of "Incorrect timestamp". 1. Why it behave like this? 2. Does it affect the receiving site during a conference meeting? 3. Is there any timeout for RTP packet handling(like dropping packet) in h323plus? Because I found out that it cause large packet loss during the conference compare to other h.323 system on the same situation(ie. same executing environment). Btw, I have done some enhancement on MyOutput display according to the suggestion of "Simon" to one of the h323 member, to avoid dropping packet. Thanks.

3 8

Re: [h323plus] ZRTP/SRTP enabling in OPAL/H323PLUS
by Simon Horne 02 Mar '11

02 Mar '11

H323plus has a H.235 factory loader and plugin features for H.235 which it shares with GnuGk. Currently baseline support and H.235.1 (Gatekeeper registration) are implemented. No media encryption yet. H.235.6 is to come. Simon From: Opal Developer [mailto:rdk.opaldev@gmail.com] Sent: 02 March 2011 08:35 To: Simon Horne Subject: Re: [h323plus] ZRTP/SRTP enabling in OPAL/H323PLUS Hi Simon, Thank you for the reply. Does the H323plus library have any sort of security built in. I see there are H325 files in the H323 project source files. Are these enabled? Thank you for your time. On Tue, Mar 1, 2011 at 12:44 PM, Simon Horne <s.horne(a)packetizer.com> wrote: Raghudeep Currently there is no intention to support ZRTP in H323plus. The industry adopted standard H.235.6 I hope to introduce in the coming months. SRTP (H.235.8) may come later. Simon From: h323plus-bounces(a)lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Opal Developer Sent: 02 March 2011 06:20 To: h323plus(a)lists.packetizer.com; opalvoip-devel(a)lists.sourceforge.net Subject: [h323plus] ZRTP/SRTP enabling in OPAL/H323PLUS Hi All. Has anyone succedded in enabling SRTP/ZRTP in OPAL/H323plus? It seems to be disabled in OPAL currently. Can you please share thoughts? I am using the Sirius release on Windows OS and Visial Studio. Any help is greatly appreciated. Thanks and regards, Raghudeep

1 0

ZRTP/SRTP enabling in OPAL/H323PLUS
by Opal Developer 01 Mar '11

01 Mar '11

Hi All. Has anyone succedded in enabling SRTP/ZRTP in OPAL/H323plus? It seems to be disabled in OPAL currently. Can you please share thoughts? I am using the Sirius release on Windows OS and Visial Studio. Any help is greatly appreciated. Thanks and regards, Raghudeep

2 1