Liaison Statement



COM 16 – ILS 15 – E


STUDY PERIOD 2001-2004


English only

Original: English


1, 3/16 ( WP 2/16 )

Geneva, 16-26 November 2004



IMTC – 3G-324M Activity Group


LS on Clarification on Maximum CCSRL-SDU Size



ITU-T SG 16 - Questions 1 & 3/16


SG 16 Chairman (on behalf of IMTC)


IMTC – 3G-324M Activity Group




November 2004


J. A. Polizotto

IMTC Secretariat

2400 Camino Ramon, Suite 375

San Ramon, CA 94583, USA

Tel: +1.650.328.0194

Fax: +1.650.618.2799



Albert Wong

Dilithium Networks Inc

California, USA

Tel:   +1-415-9251100

Fax:   +1-415-9252277



Sebastian Purreiter

Siemens AG


Tel:   +49-89-722-55921

Fax:   +49-89-722-59070



IMTC 3G-324M Activity Group (AG) would like to thank Q.1,3/16 for your Liaison Statement (LS) response with document number Q1C18.

According to the discussion outcome of our AG, your view of the original intent that “the CCSRL-SDU should have been limited to 2048 bytes in size, and the CCSRL-PDU should have been limited to 256 bytes in size” is inline with our thinking.

Our AG has also conducted some history search on the past SG meetings and has the following findings:

We found some relevant information on the topics that are related to from a contribution at the Eibsee meeting in December 1997.  

•  The document numbered Q11-C-63R2 was the original proposal of CCSRL to the existing H.324 Annex C.   The text of which is identical to the content of the existing H.324 Annex C.

•  From the investigation, the CCSRL was built on the idea of AL4, which was also proposed in the same Eibsee meeting as document Q11-C-48.   The content in the document Q11-C-48 mentioned that “The proposed control field structure would allow AL-SDUs to be partitioned into 256 segments and a maximum window size of 64.” as extracted from 2.2/Q11-C-48.

•  We also found an email correspondence as in Attachment 1 sourced from the same person proposing Q11-C-48.   The particular comment of interest is highlighted in bold letter in the attachment.   It mentions that “ One arbitrary edit I had to make was to set the maximum number number of segments in the CCSRL, and I more or less copied AL4 by seeting it to 255 segments. ”    This would indicate the possible original intention of the CCSRL-SDU size in question.

Hence, it is likely that the wording in the existing H.324 Annex C (02/2003) intends to refer to the maximum number of CCSRL-SDU segments to be 256 instead of the CCSRL-SDU size.

However, we believe in either interpretation, the existing content as indicated in H.324 (02/2003) will result in direct interpretation of the CCSRL-SDU maximum size as 256 octets.   Implementors could have followed this interpretation.

Therefore, this also comes to our concern with the effect of the existing deployed H.324/M systems if they have interpreted “the maximum size of CCSRL-SDUs shall be 256 octets”.   On this topic, we would like to raise that:

  1. At this stage, it would be relatively difficult to cover testing to all existing H.324/M system regarding to the compliance of the maximum CCSRL-SDU size.
  2. We believe that as of today, H.324/M systems is mostly popularly used for 3G environment globally as H.324/M is adopted and modified by 3GPP as 3G-324M.
  3. Many 3G-324M systems generate H.245 MultimediaSystemControlPDU messages of the size within 256 octets.   So far, we have not come across with systems constructing CCSRL-SDUs greater than 256 octets by default.
  4. There could also be another possibility that some existing deployed H.324/M may not have adopted the unintentional interpretation of the CCSRL-SDU size.   In this situation, interoperability issue can still occur even if we do not take any action.
  5. New H.324/M systems are necessary to be compliant with the corrected statements.


In view of the above statements, we identify three possible approaches:

Approach 1 :   Do nothing.   Explanation to the H.324 recommendation or its implementer guide may be made to clarify the confusion.

But this is likely to hamper the possible original intention and the efficiency of the CCSRL procedure.

Approach 2 :     Recommend making correction to the existing context in C., but in a later timeframe when all existing commercial terminals can be validated without this interoperability issue.   Explanation to the H.324 recommendation or its implementer guide may be made to clarify the existing confusion, the intended meaning and recommendation to implementers.

For making the correction to the last sentence of point 1 in C., there are three possibilities:

  1. To correct the statement as “the maximum size of CCSRL-SDU segments that a CCSRL receiver can accept shall be 256 octets”.
  2. To correct the statement as “the maximum number of CCSRL-SDU segments that a CCSRL receiver can accept shall be 256”.
  3. To remove the statement “the maximum size of CCSRL-SDUs that a CCSRL receiver can accept shall be 256”.

This approach could take relatively long time and at the end, we could find out some existing H.324/M system having adopted the unintentional interpretation.

Approach 3 :   Define an extension of the existing standard to remedy the editorial error.

In this approach, the CCSRL-SDU size will not be restricted to 256 octets.   This would require extension of the LS field definition or equivalent and this area is for further study.

In the extension, the three possibilities to the last sentence of point 1 in C. are identical to Approach 2.

This would be a better approach such that it does not break the interoperability while this can be adopted in a shorter timeframe.



In view of the above, we would initially recommend Approach 2 with the adoption of the possibility 1.   At this stage, we suggest to allow further time for investigation and evaluate the situation in the future meetings.


Our Activity Group approves unanimously to the above recommendation.


Attachment 1


Date: Thu, 11 Dec 1997 04:45:51 -0500 (EST)
From: Timor Kadir
Subject: Re: Alternative solution to control channel problem
To: ,
Comments: ( Received on from client,  sender )

Hi Simao,

Great stuff...

I think its probably ok to leave the segmentation layer without a sequence number, since as Tom says , SRP is stop and wait and V.42 is very secure ( so long as the parameters are set correctly). In the interests of simplicity and likelihood of getting the standard approved in Jan, I would agree to use this proposal.  The only thing people may wish to think about is to add the AL3 CRC check onto the end of the H.245 message.  I gather that sending invalid packets to H.245 is not a good idea.  I don't think it would require a protocol description; just a reference to the correct section of H.223 (AL3) - the same way we did in AL4 and just a description something like :

'the receiving entity should use the CRC to detect correct receipt of all the segments for each packet'

Just a thought..

also you said:
One arbitrary edit I had to make was to set the maximum number number of segments in the CCSRL, and I more or less copied AL4 by seeting it to 255 segments. This will allow a 2048 byte message to be segmentable in as pieces as small as 9 bytes, which should allow the capability exchange over the worst channels we support.

if we don't have a sequence number we don't have to set a maximum number of segments I correct in thinking this ???

thanks again..

ps. there was no attached doc and also the ftp directory didn't exist ...