One of the core functions provided by [ITU-T H.248.1] is the ability to define "H.248 Packages" which extend the capabilities of the protocol without modifying the protocol syntax. Properties, signals, events and statistics (known as ITU-T H.248 elements) may be defined via packages.

An ITU-T H.248 package template allows the definition of properties, signals, events and statistics in a stand-alone manner independent of other packages. Alternatively, it allows the package definition to inherit the properties, signals, events and statistics of another package and then add additional ITU-T H.248 elements or values to existing elements. ITU-T H.248's package extension mechanism allows for a nested inheritance, i.e., C can extend B which can extend A. However, in a package definition, the "extends" relationship is only between two packages: a base package and an extended package. Thus, whether a package is deemed a base or an extended package is determined from this perspective. The terms "base package" and "extended package" are defined in clause 3.2.

For efficient communication between a media gateway controller (MGC) and a media gateway (MG), the two entities should agree on a common set of packages and how they will be used. Currently, this agreement is achieved by the MGC learning the list of packages and package versions that the MG supports through an audit of the packages descriptor and/or the use of profiles. The MGC should then refrain from using any package that the MG does not support.

This mechanism, while simple and robust, suffers from several limitations:

– The MGC cannot ask the MG to stop using certain package IDs. Where the MGC/MG utilize extension packages, whilst the MGC may only support the use of extended package IDs, the MG may, however, reply with a base package ID. This may cause parsing errors. Likewise the MGC may only support the use of base package IDs for the base elements and extended package IDs for the extended elements; however, the MG may reply using only the extended package ID for both elements. The MGC has no way to prevent this.

– The packages descriptor does not expose the relationship between base packages and extended packages supported by the MG. As explained under clause 6.2.3 of [ITU-T H.248.1], some scenarios may cause an MG to encode package elements using a base package ID even when the MGC only implements the extended package, and vice versa.

– The MGC cannot ask the MG to stop using packages that the MGC does not support. The existence of such packages will not prevent the MG from correctly processing requests sent by the MGC. However, elements belonging to these packages may appear in replies generated by the MG (for example, in replies to an AuditValue.req of a complete descriptor). These extra elements will unnecessarily increase the size of the replies, thus contributing to the signalling overhead.

This Recommendation defines a new package that aims to resolve the above shortcomings. This package allows the MGC to determine the relationship between the base and extended packages as well as to determine/set which package ID (base and/or extended) will be used (published) in commands. It also allows the MGC to suppress the use of certain packages on the MG.