I've been testing SimplePlus and Ekiga on a C2C connection to a Polycom h/w device over the LAN. I've run into the following 2 issues with both of the applications: 1. the device only shows a broken static video frame every once in a while 2. the device closes the signalling channel right after receiving the first message Both issues seem to be have the same underlying cause: the messages and samples are not packetized according to the ITU H.225.0 standard. More specifically, my understanding of H.225.0:2006 section 6.1 and appendix IV seem to require all messages to fit in a non-fragmented datagram. However, when I add 1 video codec (H.261) and 6 audio codecs (G.722, G.722.2, GSM06.10, GSM-AMR, Speex), the first message (which contains the codec list) grows beyond 2 KiB and ends up fragmented and rejected by the h/w device. Also, the video keyframes produce media samples larger than the network's MTU and end up fragmented and the fragments are no longer macroblock-aligned and are dropped by the receiving h/w device (as showed by the device's real-time log). Every once in a while, the beginning of a keyframe is fragmented on a macroblock boundary and the device accepts that part of a frame, which is displayed partly broken (the picture is incomplete) and stays there until the next accidental valid paclet (if ever). I am in no way an expert on H.323, so my understanding of what is going on may be incorrect. If so, what can I do to correct this observed behavior? -- Alessandro

From: "Simon Horne" <s.horne@packetizer.com> Date: Sunday 07 November 2010 05:38

I suggest turning off FastStart and H245inSetup. Almost all video conferencing equipment don't use it and some older equipment do not handle the setup message with Fast Connect elements. Ie NetMeeting etc.

Thank you, disabling fast start solved the connection issue. However, the video is still broken: "Sbit/Ebit Mismatch". Do you know whether the packetization of the H.261 video created by Vic's codec actually follows the macroblock boundaries? -- Alessandro

All, We have a request from a client to be able to use an external H323 Gatekeeper, without registering with that gatekeeper. In brief they are requesting that ARQ/DRQ messages only are sent to the GK and no RRQ/IRR. I have started to look into overriding the H323Gatekeeper class and providing a new gatekeeper (via SetAssignedGatekeeper() with a m_needToRegister=0) but am not certain if [a] this is the correct way to do this [b] whether there is an easier method or [c] whether the requirement can be met with h323plus (or is actually valid). Your comments would be much appreciated. Many thanks Mark

Many thanks, much appreciated. On 10 Nov 2010, at 13:18, Simon Horne wrote:

Mark

Don't use SetAssignedGatekeeper() this function required H.323v6 compliance which most endpoints don't support. Use AlternateGatekeeper instead.

AS far as I am aware it is not valid to only handle ARQ/DRQ and not the registration tho' I would need to read the standard to be certain. GnuGk which is based on H323plus has the ability to handle unregistered calls. It does so by creating a listener on TCP 1720 and rewriting the destination address (much like an ARQ/ACF function) of the setup message and forwarding on the Call signaling messages to the required destination. There is no registration, all calls are made to the same address and the gatekeeper interprets the destination field to determine where to route the call. The client dials destination@{gk ip} or {g kip}##destination and the gatekeeper does the rest.

I would suggest creating a TCP 1720 listener and creating a lightweight endpoint and H323Connection and rewriting addresses and forwarding on the H.225 Messages.

Simon

-----Original Message----- From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Mark Fawcett Sent: Wednesday, November 10, 2010 8:13 PM To: h323plus@lists.packetizer.com Subject: [h323plus] Using a gatekeeper without registration ARQ/DRQ messages only

All,

We have a request from a client to be able to use an external H323 Gatekeeper, without registering with that gatekeeper. In brief they are requesting that ARQ/DRQ messages only are sent to the GK and no RRQ/IRR.

I have started to look into overriding the H323Gatekeeper class and providing a new gatekeeper (via SetAssignedGatekeeper() with a m_needToRegister=0) but am not certain if [a] this is the correct way to do this [b] whether there is an easier method or [c] whether the requirement can be met with h323plus (or is actually valid).

Your comments would be much appreciated.

Many thanks

Mark

Mark Fawcett Managing Director +44 (0)7976 240171 (M) +44 (0)8454 336886 (x1001) (L) www.noakesltd.co.uk Noakes Limited, Registration #06920566 (England & Wales), 2 Berkeley Close, Northampton, NN1 5BJ

Alessandro You are correct there is no way to pass to the codec the max RTP size. At the time I found no particular need to. If the plugin receives a parameter 9 (max-nal-unit-size) in the OLC it will limit the PDU size to the indicated value. By Default the payload size for H.264 is 1400 meaning the PDU size is 1400 + header(12) . You can change this in enc-ctx.cxx #define H264_PAYLOAD_SIZE 1400 #define H264_SINGLE_NAL_SIZE 1400 Make sure you set the parameter 9 in the plugin definition to force the remote to send that size too. Simon -----Original Message----- From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Alessandro Angeli Sent: Thursday, November 11, 2010 11:37 AM To: h323plus@lists.packetizer.com Subject: [h323plus] max RTP PDU size .1. It looks to me like proper packetization is left to the encoder and that the max PDU size is actually outputDataSize, computed in h323pluginmgr.cxx!H323PluginVideoCodec::Read() by asking the encoder through CallCodecControl(GET_OUTPUT_DATA_SIZE_CONTROL). However I can not seem to find a way for the application to specify a different max PDU size (a lower one in my case) or even a way to tell the encoder of such a choice (there is no SET_OUTPUT_DATA_SIZE_CONTROL). Is it possible to limit the max PDU size? .2. In h323pluginmgr.cxx!CallCodecControl(), wouldn't it make more sense to pass the normalized codecControls->name to (*codecControls->control) instead of name? After, you are doing a case-insensitive comparison. -- Alessandro