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

Resending due to error.
Christian

-------- Original Message --------
Subject: Re: [Megaco] TPKT value for H.248 over TCP
Date: Wed, 14 Jan 2004 11:33:04 +1100
From: Christian Groves <Christian.Groves@ericsson.com>
To: sampathk@cisco.com
CC: 'MEGACO list' <megaco@ietf.org>
References: <000b01c3d9fa$2047be90$c80947ab@SAMPATHKW2K03>

Hello Sampath,

I'm not the author of Annex D however:  In the case where the message would be
too big the MGC could audit groups of terminations. This will return what
context the terminations are in. This is probably more useful than just the
context IDs.

Regards, Christian

Sampath Komanduri wrote:

> 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 RFC
>     1006 <http://www.faqs.org/rfcs/rfc1006.html>, 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