Now, I have no available MXP for tests :( but when I had it I found out the way to open extended video channel : 1. Send Generic request 2. Wait for Generic response 3. Send Generic Indication 4. Send OLC(extended video channel) with sessionID = 0 (!) 5. Send miscellatiousIndication LogicalChannelActive

18 августа 2010 г. 18:17 пользователь Marek Domaracky domarack@cern.chнаписал:

Hi Igor,

I'm testing as well with MXP and in my case MXP sending always 33 and higher. So far I had a problem only with the Mirial. What I have so far is just one way channel from the device to my application. Are you opening extended video form your application to the MXP? If I understand correctly if you send OLC with sessionID != 0 Tandberg will reject? Thanks,

Marek

On 08/18/2010 03:42 PM, Igor Pavlov wrote:

I wnat to enlarge... When Tandberg (MXP) sends extended video channel, it sends sessionID=0, and only in OLCAck it accept actual sessionID. If send OLC for extended video with sessionID != 0 than Tandberg MXP sends OLCReject (InvalidSessionID).

2010/8/18 Marek Domaracky domarack@cern.ch

...

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.htmland 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

-- Игорь Павлов

I'm not familiar with CVS, and haven't ever did patch... If you instruct me, than I can sent it to you tommorow.

18 августа 2010 г. 19:30 пользователь Marek Domaracky domarack@cern.chнаписал:

OK I see. So far I implement the other way. I already sent the patch to Simon, but I don't know if he put it to CVS. If you are interested, I can send you the patch. Would it be possible to get the patch from you for the changes you did in h323plus lib? Thanks,

Marek

On 08/18/2010 04:38 PM, Igor Pavlov wrote:

Now, I have no available MXP for tests :( but when I had it I found out the way to open extended video channel :

1. Send Generic request
2. Wait for Generic response
3. Send Generic Indication
4. Send OLC(extended video channel) with sessionID = 0 (!)
5. Send miscellatiousIndication LogicalChannelActive

18 августа 2010 г. 18:17 пользователь Marek Domaracky domarack@cern.chнаписал:

...

Hi Igor,

I'm testing as well with MXP and in my case MXP sending always 33 and higher. So far I had a problem only with the Mirial. What I have so far is just one way channel from the device to my application. Are you opening extended video form your application to the MXP? If I understand correctly if you send OLC with sessionID != 0 Tandberg will reject? Thanks,

Marek

On 08/18/2010 03:42 PM, Igor Pavlov wrote:

I wnat to enlarge... When Tandberg (MXP) sends extended video channel, it sends sessionID=0, and only in OLCAck it accept actual sessionID. If send OLC for extended video with sessionID != 0 than Tandberg MXP sends OLCReject (InvalidSessionID).

2010/8/18 Marek Domaracky domarack@cern.ch

...

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.htmland 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

...

Thanks,

Marek

-- Игорь Павлов

-- Игорь Павлов

Marek,

your patch didn't go into the CVS, yet. Please post your it to this mailing list. That gives more people a chance to look at it or put it into the CVS.

Thanks, Jan

Marek Domaracky wrote:

OK I see. So far I implement the other way. I already sent the patch to Simon, but I don't know if he put it to CVS. If you are interested, I can send you the patch. Would it be possible to get the patch from you for the changes you did in h323plus lib? Thanks,

Marek

On 08/18/2010 04:38 PM, Igor Pavlov wrote:

...

Now, I have no available MXP for tests :( but when I had it I found out the way to open extended video channel :

1. Send Generic request
2. Wait for Generic response
3. Send Generic Indication
4. Send OLC(extended video channel) with sessionID = 0 (!)
5. Send miscellatiousIndication LogicalChannelActive

18 августа 2010 г. 18:17 пользователь Marek Domaracky <domarack@cern.ch mailto:domarack@cern.ch> написал:

Hi Igor,

I'm testing as well with MXP and in my case MXP sending always 33
and higher. So far I had a problem only with the Mirial.
What I have so far is just one way channel from the device to my
application. Are you opening extended video form your application
to the MXP?
If I understand correctly if you send OLC with sessionID != 0
Tandberg will reject?
Thanks,

Marek




On 08/18/2010 03:42 PM, Igor Pavlov wrote:

...

I wnat to enlarge...
When Tandberg (MXP) sends extended video channel, it sends
sessionID=0, and only in OLCAck it accept actual sessionID.
If send OLC for extended video with sessionID != 0 than Tandberg
MXP sends OLCReject (InvalidSessionID).

2010/8/18 Marek Domaracky <domarack@cern.ch
<mailto:domarack@cern.ch>>

    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






-- 
Игорь Павлов

-- Игорь Павлов

Marek

Sorry for the delay, yes I have your patch and am testing with a wide range of equipment. I will make the commit to the CVS today.

I too saw the sessionID= 0 issue with Mirial. Will apply the patch.

Simon

-----Original Message----- From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Marek Domaracky Sent: Thursday, August 19, 2010 1:41 AM To: Jan Willamowius Cc: h323plus@lists.packetizer.com Subject: Re: [h323plus] crash when SessionID=0

Hi,

you can find the patch in the attachment. Thanks,

Marek

There has been some improvement in bandwidth management in the current CVS.

There are 2 parts 1 what we limit what we send and what we request the remote to limit to.

When setting the local bandwidth this can be set by your derived H323Connection::OpenVideoChannel function ie codec->SetMaxBitRate() .

To set the remote there is an improved function H323Connection::SetInitialBandwidth(H323Capability::MainTypes & captype, int bitRate) Which you can call when you instance the connection object which will limit the bandwidth of all advertised capabilities in the TCS to the value you specify and that should limit the bandwidth the remote requests in the OLC and hence what it will send.

Simon

-----Original Message----- From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of kcooi12345 Sent: Wednesday, October 27, 2010 7:20 PM To: h323plus@lists.packetizer.com Subject: [h323plus] Call Rate Issue using H323plus

Hi All,

Does anyone know how to set the call rate for a conference?

In my H.323 application that use h323plus library, it use 384 kbits by default to create a conference. I have try to use function SetInitialBandwidth(51200)for 512kbits call rate, but it also fails.

Thanks.

Kc

The codec definition (in the plugin) sets the upper BitRate limit for the codec. if you set a targetbitrate higher that the maxbitRate from the plugin codec then it is ignored.

For instance H.263 CIF will not exceed the 384k set in the codec definition. To fix just change the maxbitrate value in the plugin codec.

Simon

From: kc ooi [mailto:kcooi12345@gmail.com] Sent: Thursday, October 28, 2010 8:49 PM To: Simon Horne Cc: h323plus@lists.packetizer.com Subject: Re: [h323plus] Call Rate Issue using H323plus

Hi Simon and h323plus members,

I manage to get it work in the situation where SetInitialBandwidth is set to video type and less than 384kbits.

The other terminal will be notified and sending video below the limit.

But it fail when I set more than 384kbits, for example 512kbits or 1Mbits.

Is there a default value that defines the limit?

Thanks.

On Thu, Oct 28, 2010 at 9:01 AM, Simon Horne s.horne@packetizer.com wrote:

There has been some improvement in bandwidth management in the current CVS.

There are 2 parts 1 what we limit what we send and what we request the remote to limit to.

When setting the local bandwidth this can be set by your derived H323Connection::OpenVideoChannel function ie codec->SetMaxBitRate() .

To set the remote there is an improved function H323Connection::SetInitialBandwidth(H323Capability::MainTypes & captype, int bitRate) Which you can call when you instance the connection object which will limit the bandwidth of all advertised capabilities in the TCS to the value you specify and that should limit the bandwidth the remote requests in the OLC and hence what it will send.

Simon

-----Original Message----- From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of kcooi12345 Sent: Wednesday, October 27, 2010 7:20 PM To: h323plus@lists.packetizer.com Subject: [h323plus] Call Rate Issue using H323plus

Hi All,

Does anyone know how to set the call rate for a conference?

In my H.323 application that use h323plus library, it use 384 kbits by default to create a conference. I have try to use function SetInitialBandwidth(51200)for 512kbits call rate, but it also fails.

Thanks.

Kc

You should use

SetVideoFrameSize(H323Capability::xxxMPI)

to set only one of the definitions.

I am not sure why you are receiving 384k with the H.264 plugin since that value is not set in the plugin. You will need to send a trace to work out what exactly is going on.

Simon

From: kc ooi [mailto:kcooi12345@gmail.com] Sent: Friday, October 29, 2010 6:23 PM To: Simon Horne Cc: h323plus@lists.packetizer.com Subject: Re: [h323plus] Call Rate Issue using H323plus

Hi Simon and h323plus members,

I am sure my H.264 codec definition(in the plugin) was set to 768kbps.

Also, I only load H.264 plugin in my H.323 application, no H.261 and no H.263.

When I do tracing on the changes on my MaxbitRate,

I notice that if i set 512kbps by calling the H323Connection::SetIntialBandwidth(),

this function will set the new value into each format in my plugin (H.264 QCIF, H.264 CIF, H.264 4CIF) since it is true for 512< 768.

The problem is when I trace bandwidth value in H323Channel::SetInitialBandwidth(), I find that It deduce 384kbps in total bandwidth of the overall bandwidth this system have. Not 512kbps.

which step is going wrong?

Thanks.

On Thu, Oct 28, 2010 at 8:09 PM, Simon Horne s.horne@packetizer.com wrote:

Kc

The codec definition (in the plugin) sets the upper BitRate limit for the codec. if you set a targetbitrate higher that the maxbitRate from the plugin codec then it is ignored.

For instance H.263 CIF will not exceed the 384k set in the codec definition. To fix just change the maxbitrate value in the plugin codec.

Simon

From: kc ooi [mailto:kcooi12345@gmail.com] Sent: Thursday, October 28, 2010 8:49 PM To: Simon Horne Cc: h323plus@lists.packetizer.com Subject: Re: [h323plus] Call Rate Issue using H323plus

Hi Simon and h323plus members,

I manage to get it work in the situation where SetInitialBandwidth is set to video type and less than 384kbits.

The other terminal will be notified and sending video below the limit.

But it fail when I set more than 384kbits, for example 512kbits or 1Mbits.

Is there a default value that defines the limit?

Thanks.

On Thu, Oct 28, 2010 at 9:01 AM, Simon Horne s.horne@packetizer.com wrote:

There has been some improvement in bandwidth management in the current CVS.

There are 2 parts 1 what we limit what we send and what we request the remote to limit to.

When setting the local bandwidth this can be set by your derived H323Connection::OpenVideoChannel function ie codec->SetMaxBitRate() .

To set the remote there is an improved function H323Connection::SetInitialBandwidth(H323Capability::MainTypes & captype, int bitRate) Which you can call when you instance the connection object which will limit the bandwidth of all advertised capabilities in the TCS to the value you specify and that should limit the bandwidth the remote requests in the OLC and hence what it will send.

Simon

-----Original Message----- From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of kcooi12345 Sent: Wednesday, October 27, 2010 7:20 PM To: h323plus@lists.packetizer.com Subject: [h323plus] Call Rate Issue using H323plus

Hi All,

Does anyone know how to set the call rate for a conference?

In my H.323 application that use h323plus library, it use 384 kbits by default to create a conference. I have try to use function SetInitialBandwidth(51200)for 512kbits call rate, but it also fails.

Thanks.

Seq 2 is out of order and is ignored. A frame buffer/sequencer would fix the problem and this is on the to-do list.

Simon

-----Original Message----- From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of kcooi12345@gmail.com Sent: 13 June 2011 18:42 To: h323plus@lists.packetizer.com Subject: [h323plus] RTP Issue using H323plus

Dear H323plus Member,

Recently, I found a RTP issue that happened in H323plus v.1.22.0(The version I used).

During all the testing, I used wireshark to capture RTP video packets and check for its timestamps, sequence numbers and other information.

whenever the received RTP video packets is coming in unorder sequence number(eg. seq 0, seq 1, seq 3, seq 2, seq 4, and etc), the received packets that passed to video codec(eg. H.264 codec) for decoding will be seq 0, seq 1, seq 3, and seq 4 and etc.

The RTP packet with seq 2 will be missing(not passed to decoder for decoding) if seq 3 which is larger is received before this.

Anyone knows why this happened?

Thanks.