Claudio

 

Sorry for the delay in replying I have been travelling.

 

There was a typo and the TRUE in new H323TransportTCP() was unfortunately accidentally removed.

The H323TransportTCP class needs to initialized as to whether it supports TLS or not. H.245 has NO TLS support anyway however it does need to be initialized as such. You can avoid the issue completely it if you are not using TLS by compiling without the H323_TLS switch (--enable-tls=false)

 

Separate H.245 Channel is something I do not use every day (preferring H245Tunneling which is default) as it cannot be secured and is not very NAT Friendly so it was missed in testing. I have now fixed and tested the issue in the h323plus CVS.

 

 

As a side note

I do suggest that if you can avoid using it do not to use separate H.245 Channel. Unfortunately there is a lot of equipment out there that has no concept of tunneling so the option is just not there.

 

If you are using GnuGk and routing signaling then I suggest using.

[RoutedMode]

H245TunnelingTranslation=1

 

This will force H.245 to be tunneled where the remote supports it. A very convenient feature.

 

Simon

 

From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Diego Carvalho
Sent: 21 January 2014 02:03
To: h323plus@lists.packetizer.com
Subject: Re: [h323plus] H.235 sample

 

Hi Simon,

 

I work with Claudio and we are having problems with the CVS version. Inbound calls are not working.

 

The first problem is regarding the creation of the H245 channel then I saw the following change in file transports.cxx:

 

H323Transport * H323TransportTCP::CreateControlChannel(H323Connection & connection)

{

  H323TransportTCP * tcpTransport = new H323TransportTCP(endpoint, localAddress, /*there was a TRUE here */);

 

Why this was changed? 

 

When I put the TRUE back the execution proceeded but then failed in another point. Then I saw that it seems one of the TLS related variables is set even though I was not using TLS. I think the problem is in the same file at:

 

PBoolean H323TransportTCP::SecureAccept()

{

#ifdef H323_TLS

#if PTLIB_VER < 2120

    ssl_st * m_ssl = ssl;

#endif

    if (m_ssl)

 

It seems the variable m_ssl is set so the SecureAccept function ends up returning false thus terminating the call. I could not find where this variable is set and we had to disable TLS to make inbound calls work again. I think the issue is reproducible with the simple example. I appreciate any help. Thanks.

 

On Thu, Jan 16, 2014 at 9:02 AM, Cláudio Palludetti <cpalludetti@daitangroup.com> wrote:

Simon,

This will certainly help a lot.

Thanks

Claudio


On 16/01/2014, at 00:44, Simon Horne <s.horne@spranto.com> wrote:

> Claudio
>
> Update:
> H323_ExternalRTPChannel with encryption support has been added to the CVS.
>
> There is a new wrapper channel for H323_ExternalRTPChannel called
> H323SecureChannel which handles all the key exchange and media
> encryption/decryption if required.
>
> Simon
>
> -----Original Message-----
> From: h323plus-bounces@lists.packetizer.com
> [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Simon Horne
> Sent: 14 January 2014 05:07
> To: 'Cláudio Palludetti'; 'Jan Willamowius'; h323plus@lists.packetizer.com
> Subject: Re: [h323plus] H.235 sample
>
> Claudio
>
> Yes the current H.235 Implementation does not take into account the use of
> external RTP channel. I will put that on my TODO list to fix before the next
> release.
>
> Simon
>
> -----Original Message-----
> From: h323plus-bounces@lists.packetizer.com
> [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Cláudio
> Palludetti
> Sent: 13 January 2014 22:12
> To: Jan Willamowius; h323plus@lists.packetizer.com
> Subject: Re: [h323plus] H.235 sample
>
> Jan,
>
> Thank you.
>
> I had some progress towards establishing a H.235 call but it is falling when
> it tries to open the logical channel.
> So my question is: Is it possible to use H.235 along with external channels?
> I'm asking this because H323RealTimeCapability::CreateChannel calls
> connection.CreateRealTimeLogicalChannel (where you can provide your own
> external channel subclass) but H323SecureRealTimeCapability::CreateChannel
> creates a new H323SecureRTPChannel (it does not call any function where you
> could return your own subclass). When I don't use H.235 I get the following
> log:
>
> 2014/01/09 11:25:10.435 3         h323.cxx(4289) H323 Selecting
> G.711-uLaw-64k <1>
> 2014/01/09 11:25:10.435 3      h323neg.cxx(542) H245 Opening channel: T-101
> 2014/01/09 11:25:10.435 4     h323caps.cxx(3265) H323 FindCapability: 102
> 2014/01/09 11:25:10.435 4     h235caps.cxx(379) H235RTP Cloning Capability:
> G.711-uLaw-64k
> 2014-01-09:11.25.10 (8970) CltApp   DEBUG   (H323ClientConnection.cpp:357)
> Creating transmitter audio channel (G.711-uLaw-64k).
>
> The last one is from my subclass.
>
> When I try to use H.235 I get:
>
> 2014/01/09 15:55:00.655 3         h323.cxx(4289) H323 Selecting
> G.711-uLaw-64k <1>
> 2014/01/09 15:55:00.655 3      h323neg.cxx(542) H245 Opening channel: T-101
> 2014/01/09 15:55:00.655 4     h323caps.cxx(3265) H323 FindCapability: 102
> 2014/01/09 15:55:00.655 3     h323caps.cxx(3269) H323 Found capability:
> SecCapability [2] <102>
> 2014/01/09 15:55:00.656 4       osutil.cxx(189) PWLib File handle high water
> mark set: 37 PUDPSocket
> 2014/01/09 15:55:00.656 4       osutil.cxx(189) PWLib File handle high water
> mark set: 38 PUDPSocket
> 2014/01/09 15:55:00.656 2          rtp.cxx(1581) RTP_UDP Session 1 created:
> 192.168.14.43:5000-5001 ssrc=3823145998
> 2014/01/09 15:55:00.656 2          rtp.cxx(1314) RTP Adding session RTP_UDP
> 2014/01/09 15:55:00.656 4     h235caps.cxx(379) H235RTP Cloning Capability:
> G.711-uLaw-64k #
> 2014/01/09 15:55:00.656 3     channels.cxx(654) H323RTP Transmitter created
> using session 1
> 2014/01/09 15:55:00.656 4     h235chan.cxx(149) H235RTP OnSendingPDU
> 2014/01/09 15:55:00.656 3     channels.cxx(472) H323RTP OnSendingPDU
> 2014/01/09 15:55:00.656 3      h323rtp.cxx(134) RTP OnSendingPDU
> 2014/01/09 15:55:00.657 3       codecs.cxx(1247) Codec G711 uLaw encoder
> created for at 64k, frame of 160 samples
> 2014/01/09 15:55:00.657 5      osutils.cxx(2219) PTLib Created read/write
> mutex 0x7f85e4006b78
> 2014/01/09 15:55:00.657 5      osutils.cxx(2219) PTLib Created read/write
> mutex 0x7f85e4011398
> 2014/01/09 15:55:00.657 3       h323ep.cxx(2543) Codec Opened sound channel
> "Null Audio" for recording at 8000 samples/second using 2x320 byte buffers.
> 2014/01/09 15:55:00.657 1     channels.cxx(716) LogChan Transmit thread
> aborted (open fail) for G.711-uLaw-64k # <1>
>
> I appreciate any help. Thanks in advance.
>
> Claudio
>
> -----Original Message-----
> From: h323plus-bounces@lists.packetizer.com
> [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Jan Willamowius
> Sent: quarta-feira, 2 de outubro de 2013 10:50
> To: h323plus@lists.packetizer.com
> Subject: Re: [h323plus] H.235 sample
>
> Hi Claudio,
>
> take a look at the provided sample application "Simple".
> When you start it with command line argument "-m 128", it will do H.235 AES
> 128 media encryption.
>
> Regards,
> Jan
>
> --
> Jan Willamowius, Founder of the GNU Gatekeeper Project EMail  :
> jan@willamowius.de
> Website: http://www.gnugk.org
> Support: http://www.willamowius.com/gnugk-support.html
>
> Relaxed Communications GmbH
> Frahmredder 91
> 22393 Hamburg
> Geschäftsführer: Jan Willamowius
> HRB 125261 (Amtsgericht Hamburg)
> USt-IdNr: DE286003584
>
>
> Cláudio Palludetti wrote:
>> Hi,
>>
>> We are developing an H.323 EP  and we need to use the H.235.
>> Is there any example using this?
>> We are using h323plus V1.24.0 and we enabled the H.235.
>>
>> Thanks
>>
>> Claudio
>
>
>
>
>
>