RE: [Megaco] TPKT value for H.248 over TCP

Kevin,

That's correct.
But to find the beginning and end of packets H.248 uses TPKT Version 3 (RFC
1006)
which has a header (4 bytes) followed by the H.248 msg. The TPKT  header
has 2 byte length field, using which we can only send a h248 msg of size <
65531 bytes
(the TPKT two bytes length includes the TPKT header length of 4 bytes).

Thanks
Raju

> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
> Kevin Boyle
> Sent: Wednesday, January 14, 2004 12:25 PM
> To: sampathk@cisco.com; 'MEGACO list'
> Subject: RE: [Megaco] TPKT value for H.248 over TCP
>
>
> I was under the impression that TCP segmented large packets automatically.
> Is that not the case?
>
> Kevin
>
>
>
>   _____
>
> From: Sampath Komanduri [mailto:sampathk@cisco.com]
> Sent: Tuesday, January 13, 2004 12:25 PM
> To: 'MEGACO list'
> Subject: RE: [Megaco] TPKT value for H.248 over TCP
>
>
> Could the author of Annex D pls. respond?
>
> Thanks,
> Sampath
>
> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
> Sampath Komanduri
> Sent: Tuesday, January 06, 2004 8:16 PM
> To: 'MEGACO list'
> Subject: [Megaco] TPKT value for H.248 over TCP
> Importance: High
>
>
> Hi List,
> I am not sure if this question was already raised in the list. If it was,
> pls. point me to the discussion and the consensus.
>
> According to ANNEX D of H.248.1 protocol, "TPKT, according to
> <http://www.faqs.org/rfcs/rfc1006.html> RFC 1006, SHALL be used
> to delineate
> messages within the TCP stream". RFC 1006 limits the size of TPDU
> to 65524.
> Replicating the relevant text here for convenience:
>
> ***************************************************
>      "A TPKT consists of two parts:  a packet-header and a TPDU.
>       The format of the header is constant regardless of the type
> of packet.
>       The format of the packet-header is as follows:
>
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |      vrsn     |    reserved   |          packet length        |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       where:
>
>       vrsn                         8 bits
>
>       This field is always 3 for the version of the protocol described in
> this memo.
>
>       packet length                16 bits (min=7, max=65535)
>
>       This field contains the length of entire packet in octets, including
> packet-header.
>       This permits a maximum TPDU size of 65531 octets.
>       Based on the size of the data transfer (DT) TPDU, this permits a
> maximum
>       TSDU size of 65524 octets."
> *********************************************************
>
> This causes an issue. Based on the wildcard level of Audit and the
> descriptors involved, this size could easily exceed 64K size
> (especially if
> MG and MGC are using Long text format and white spaces in the
> messages). In
> few cases, it is possible to return an error code (533: Response exceeds
> maximum transport PDU size).
> However, in some cases returning 533 is not an option.
> Consider for example the following scenario: After an association is
> DISCONNECTED, MGC may want to get the list of non-null contexts on the
> gateway using the following command (pls. ignore if there is any
> mistake in
> the message and reply construct):
>
> !/1 [10.102.2.201]:4000 T=3700003{C=*{AV=ROOT{AT{}}}}
> !/1 ABCD_MG P=3700003{C=1{AV=C{*}},C=2{AV=C{*}},C=3{AV=C{*}},
> ....and so on}
>
> In the best case (i.e. no white-space, no audit descriptor and short
> format), this allows for an MG to have only 5000 active contexts on the
> card. Anything more (or any variation in the audit command) will
> reduce the
> number of active contexts that an MG can have even with TCP as
> the transport
> option.
> Responding with 533 is not an option here since that would leave MG-MGC in
> state from where there is no elegant way out (at least from H.248
> protocol).
>
> How do the gurus' on list suggest we solve this issue? Couple of
> ideas that
> come to mind are:
>
> 1.	Define a Bulk-Audit Package/scheme: As was done for MGCP, define a
> Bulk-Audit package/scheme especially with support for
>     RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]" and
>     NumericalRange     = 1*(DIGIT) [ "-" 1*(DIGIT) ].
>     This will certainly reduce the cases and scenarios when
> MG/MGC will run
> into the issue under discussion but may not eliminate it.
>
> 2.	Add more information on W- Audit support in the protocol.
>
> 3.	Introduce RFC 1006 modification (with version field 4) such that
> "packet length" of packet header in TPKT is 32 bits as opposed to
> 16 bits.
>
> 4.	Combination of the above schemes.
>
> 5.	Anything else?
>
> Pls. advice on how this problem can be solved?
>
> Thanks,
> Sampath
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco