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:
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.
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.
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.
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.
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.8.1.2.2/H.324, 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.8.1.2.2/H.324,
there are three possibilities:
To correct the statement as “the maximum size of CCSRL-SDU segments that
a CCSRL receiver can accept shall be 256 octets”.
To correct the statement as “the maximum number of CCSRL-SDU segments that
a CCSRL receiver can accept shall be 256”.
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.8.1.2.2/H.324 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.
Conclusion
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: ,
Cc:
Comments: ( Received on motgate.mot.com from client mothost.mot.com, 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 ...am I correct in thinking this ???
thanks again..
ps. there was no attached doc and also the ftp directory didn't exist ...
