Dear All,
I support the principle that only one H.225 call signalling message should
be sent per TPKT. Firstly I believe it was agreed between early
implementers that this is the way they would work. Secondly, even though it
is possible to send multiple PER messages per TPKT there are other reasons
why this is not totally desirable. In our case of working on a high volume
GK, we only need to process a fraction of H.245 messages. If there is only
one message per TPKT we can easily work out …
[View More]what the message is by looking
at the first few bytes. However, if there are multiple messages per packet
we have no choice but to decode each and every message. In most cases this
represents a totally unnecessary processing overhead and is therefore best
avoided.
Pete
=============================================
Pete Cordell
pete(a)tech-know-ware.com
=============================================
-----Original Message-----
From: Paul Long <Plong(a)SMITHMICRO.COM>
To: 'h323implementors(a)imtc.org' <h323implementors(a)imtc.org>
Cc: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com>
Date: 30 June 1999 17:53
Subject: RE: PDU & ASN parser
>Guntram,
>
>I raised this issue over a year ago. In addition, H.225.0 does not address
>this issue regarding RAS (it does regarding call signaling), so I suppose
one
>could pack multiple RAS messages per unreliable-transport PDU. As you say,
it
>doesn't make sense to pack messages, and I don't think anyone does it. We
>should probably add something like the following to section 6.1 of the next
>revision of H.225.0.
>
>"When messages are sent on the H.225.0 RAS channel, only one whole message
>shall be sent within the boundaries defined by the transport; there shall
be
>no fragmentation of H.225.0 RAS messages across transport PDUs."
>
>We should also insert the indicated text, below, into existing text in the
>same section.
>
>"When messages are sent on the reliable H.245 control channel, >>>exactly
one
>message should be sent but<<< more than one message may be sent within the
>boundaries defined by the reliable transport PDU as long as whole messages
are
>sent;"
>
>Paul Long
>Smith Micro Software, Inc.
>
> -----Original Message-----
> From: Guntram Diehl [SMTP:gdiehl@innovaphone.com]
> Sent: Wednesday, June 30, 1999 4:14 AM
> To: 'Bancroft Scott'; 'Srikanth Nayani'
> Cc: 'h323implementors(a)imtc.org'
> Subject: RE: PDU & ASN parser
>
> Yes this can be done, but does any implementation actually do it? Why
> would anyone want to do this, it just saves 4 bytes tpkt header per
> additional H.245 message and it does not change the fragmentation of
>the
> whole thing by IP.
>
> Or is there another reason why this was specified in the standard this
> way?
>
> Guntram
>
> -----Original Message-----
> From: Bancroft Scott [mailto:baos@OSS.COM]
> Sent: Wednesday, June 30, 1999 3:54 AM
> To: Srikanth Nayani
> Cc: h323implementors(a)imtc.org
> Subject: Re: PDU & ASN parser
>
>
> On Tue, 29 Jun 1999, Srikanth Nayani wrote:
>
> > In the H.225 document chapter 6 mentions that multiple messages
>can be
> > sent over the reliable H.245 control channel within the boundaries
>of the
> > reliable transport channel . Does that mean that two H.245 PDUs
>encoded
> > using PER and whose total encoded length is within the boundary of
>the
> > H.245 TCP channel can be merely concatenated and sent as a single
>payload
> > of the H.245 TCP channel.
> > If so how does a ASN.1 decoder know that there are two
>messages in the
> > payload and the offset at which the second message starts.
>
> An PER decoder does not know that there are two messages in the
>payload.
> It does know where the first message ends, so the location of the next
> message can be derived from this knowledge.
>
>
>------------------------------------------------------------------------
> --
> Bancroft Scott Toll Free
> :1-888-OSS-ASN1
> Open Systems Solutions, Inc.
> International:1-609-987-9073
> baos(a)oss.com Tech Support
> :1-732-249-5107
> http://www.oss.com Fax
> :1-732-249-4636
>
>
>------------------------------------------------------------------------
> -
> for list subscription instructions,
> send email to h323implementors-request(a)imtc.org with text "info"
>
>
>-------------------------------------------------------------------------
> for list subscription instructions,
> send email to h323implementors-request(a)imtc.org with text "info"
>-------------------------------------------------------------------------
>for list subscription instructions,
>send email to h323implementors-request(a)imtc.org with text "info"
>
>
[View Less]
Paul,
Could we run into problems with some country actually using the extension
field? (I think the US always defines it to be zero.) I don't see any other
alternative, though.
Paul Long
Smith Micro Software, Inc.
-----Original Message-----
From: Paul E. Jones [SMTP:paul.jones@TIES.ITU.INT]
Sent: Monday, June 28, 1999 9:31 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: New T.35
Folks,
As many of you know, the latest T.35 …
[View More]document supports more than 254
country
codes. In the newest document, T.35 says that one or two octets may
be used
to indicate the country code. If the first octet contains 1111 1111,
the
second octet will contain the country code.
Unfortunately, the syntax in H.245 does not utilize extension markers,
so
there is no place to hold second octet for the country code.
Therefore, I
would like to propose that, both for H.225.0 and H.245, we change the
comments in the ASN.1 from:
t35CountryCode INTEGER(0..255), -- country, as per T.35
t35Extension INTEGER(0..255), -- assigned nationally
manufacturerCode INTEGER(0..65535), -- assigned nationally
to the following
t35CountryCode INTEGER(0..255), -- country, as per T.35 Annex A
t35Extension INTEGER(0..255), -- assigned nationally, unless
the
-- t35CountryCode is 1111 1111,
in
-- which case this field shall
-- contain the country code
found
-- in T.35 Annex B
manufacturerCode INTEGER(0..65535), -- assigned nationally
This may be a perversion of the t35Extension field, but we have a
limited
number of options if we wish to support the usage of two octets for a
country code in H.245.
What are your opinions?
Best Regards,
Paul
[View Less]
