6.1.  Usage of DOT in digitmaps

Issue:

Digit maps allow the specification of a "." DOT in a digit map. This DOT indicates that the preceding element may be repeated zero or more times. The example in 7.1.14.9/[ITU-T H.248.1] shows its usage: 9011 + up to 15 digits is denoted by "9011x." However there has been some confusion over whether the preceding element to the DOT has to be matched for a successful digit map completion. I.e. for the above example is "9011" a successful match? This question has been posted to the IETF Megaco mailing list on two previous occasions previously: (29/09/2008, "Megaco question about interpretation of dot in a digitmap") and (16/05/2007, "DOT in H.248 Digit map syntax"). The reply on both those occasions was the key word is "repetitions" and that there must be at least occurrence of the preceding element. I.e. In the above example "90112" would result in a successful match but "9011" would not.

Reference:

AVD-4448

[Begin Correction]

7.1.14.3 DigitMap syntax

The formal syntax of the DigitMap is described by the DigitMap rule in the formal syntax description of the protocol (see Annexes A and B). A DigitMap, according to this syntax, is defined either by a string or by a list of strings. Each string in the list is an alternative event sequence, specified either as a sequence of DigitMap symbols or as a regular expression of DigitMap symbols. These DigitMap symbols, the digits "0" through "9" and letters "A" through a maximum value depending on the signalling system concerned, but never exceeding "K", correspond to specified events within a package which has been designated in the Events Descriptor on the termination to which the DigitMap is being applied. (The mapping between events and DigitMap symbols is defined in the documentation for packages associated with channel-associated signalling systems such as DTMF, MF, or R2. Digits "0" through "9" must be mapped to the corresponding digit events within the signalling system concerned. Letters should be allocated in logical fashion, facilitating the use of range notation for alternative events.)

The letter "x" is used as a wildcard, designating any event corresponding to symbols in the range "0"-"9". The string may also contain explicit ranges and, more generally, explicit sets of symbols, designating alternative events any one of which satisfies that position of the DigitMap. Finally, the dot symbol "." stands for one occurrence and zero or more repetitions of the event selector (event, range of events, set of alternative events, or wildcard) that precedes it. As a consequence of the third timing rule above, inter-event timing while matching a terminal dot symbol uses the short timer by default.

In addition to these event symbols, the string may contain "S" and "L" inter-event timing specifiers and the "Z" duration modifier. "S" and "L" respectively indicate that the MG should use the short (S) timer or the long (L) timer for subsequent events, overriding the timing rules described above. If an explicit timing specifier is in effect in one alternative event sequence, but none is given in any other candidate alternative, the timer value set by the explicit timing specifier must be used. If all sequences with explicit timing controls are dropped from the candidate set, timing reverts to the default rules given above. If used inside a range notation, the S and L specifiers shall be ignored. Finally, if conflicting timing specifiers are in effect in different alternative sequences, the long timer shall be used.

A "Z" designates a long duration event: placed in front of the symbol(s) designating the event(s) which satisfy a given digit position, it indicates that that position is satisfied only if the duration of the event exceeds the long-duration threshold. The value of this threshold is assumed to be provisioned in the MG, but, like the T, L, and S timers, can be overridden by specification within the DigitMap. If the Z specifier is not followed by a digit (0-9 or A-K), then the MG shall reject the digitmap as invalid procedure. When used in a range notation, the Z specifier applies solely to the immediately following digit. When used immediately prior to a range, the Z modifier applies to all digits in the range (thereby requiring a match in the range to be long duration).

[End Correction]

6.2.  Updated ABNF reference

Issue:	H.248.1 contains a reference to RFC2234 for ABNF syntax. This RFC has been obsoleted. The latest definition of ABNF is RFC 5234 which is also known as STD 68. The updates to the RFC are mainly with regards to its use with email. There are no changes that effect H.248 encoding.
Reference:	Discussions resulting from H.248.66 (COM16-C.351).

[Begin Correction]

2 References

The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.

…​

[IETF RFC 2234] IETF RFC 2234 (1997), Augmented BNF for Syntax Specifications: ABNF.

…​

[IETF RFC 5234] IETF RFC 5234 (2008), Augmented BNF for Syntax Specifications: ABNF.

[End Correction]

6.3.  Reserve Properties clarifications

Issue:	There has been some confusion with regards to the behaviour of property overspecification and the use of ReserveValue and ReserveGroup. Clarifying text is added to clause 7.1.7 on the relation between the concepts. The note in clause 7.1.8.2.3.2 is related to ReserveGroup=True and thus should be placed in clause 7.1.8.2.3.3.
Reference:	COM16-C.686

[Begin Correction]

7.1.7 LocalControl Descriptor

1. Overview
   The LocalControl Descriptor contains the Mode Property, the ReserveGroup and ReserveValue Properties and properties of a termination (defined in packages) that are stream specific, and are of interest between the MG and the MGC. Values of properties may be specified as in clause 7.1.1.

2. Mode Property (for directionality control)
   The allowed values for the Mode Property are "SendOnly", "RecvOnly", "SendRecv", "Inactive" and "LoopBack". "SendOnly", "RecvOnly" and "LoopBack" are with respect to the exterior of the context, so that, for example, a stream set to mode = "SendOnly" does not pass received media into the context. When a stream is set to "LoopBack" on a termination, media received (Local Descriptor) on the termination will be looped back to the sending side (Remote Descriptor) of the termination and no media is passed between that termination and other terminations in the context. The looped back media shall be sent according to the Remote Descriptor. The default value for the Mode Property is "Inactive". Signals and events are not affected by the Mode Property. Statistics may or may not be affected by the Mode property depending on the semantic of the statistic. For example: if the Mode was set to "SendOnly" and the Octet Received Statistic was set, then the statistic would not be affected. If the Octet Sent Statistic was set, then it would be affected by the mode. The LocalControl Mode Property takes precedence over any mode specified in the Local and Remote Descriptors. However, duplication and use of mode information in the SDP should be avoided. Due to the default of LocalControl Mode Property being "Inactive", if mode information was added to the Local and Remote Descriptor SDP and the LocalControl Mode was not explicitly sent, the effective mode would still be inactive.

3. Reserve Properties (for resource handling control)

   The boolean-valued Reserve Properties, ReserveValue and ReserveGroup, of a termination indicate what the MG is expected to do when it receives a Local and/or Remote Descriptor.

   If the value of a Reserve Property is "True", the MG shall reserve resources for all alternatives specified in the Local and/or Remote Descriptors for which it currently has resources available. It shall respond with the alternatives for which it reserves resources. If it cannot support any of the alternatives, it shall respond with a reply to the MGC that contains empty Local and/or Remote Descriptors. If media begins to flow while more than a single alternative is reserved, media packets may be sent or received on any of the alternatives and must be processed, although only a single alternative may be active at any given time.

   If the value of a Reserve Property is False, the MG shall choose one of the alternatives specified in the Local Descriptor (if present) and one of the alternatives specified in the Remote Descriptor (if present). as per the behaviour associated with "overspecification" (see clause 7.1.1, list item 3). If the MG has not yet reserved resources to support the selected alternative, it shall reserve the resources. If, on the other hand, it already reserved resources for the termination addressed (because of a prior exchange with ReserveValue and/or ReserveGroup equal to "True"), it shall release any excess resources it reserved previously. Finally, the MG shall send a reply to the MGC containing the alternatives for the Local and/or Remote Descriptor that it selected. If the MG does not have sufficient resources to support any of the alternatives specified, it shall respond with Error Code 510 ("Insufficient resources").

   The default value of ReserveValue and ReserveGroup is "False". More information on the use of the two Reserve Properties is provided in clause 7.1.8.

4. Descriptor usage

   A new setting of the LocalControl Descriptor completely replaces the previous setting of that descriptor in the MG. Thus, to retain information from the previous setting, the MGC must include that information in the new setting. If the MGC wishes to delete some information from the existing descriptor, it merely resends the descriptor (in a Modify Command) with the unwanted information stripped out.

   NOTE 1 – The Mode Property is also known as "StreamMode" in the encoding definitions in Annexes A and B. These terms are interchangeable within ITU-T H.248.

[End Correction]

[Begin Correction]

7.1.8.2.3 Resource reservation rules for ReserveValue and ReserveGroup properties

Subject to the above rules, subsequent action depends on the values of the ReserveValue and ReserveGroup Properties in LocalControl.

7.1.8.2.3.1 ReserveValue = "False" AND ReserveGroup = "True"

If ReserveGroup is "True", the MG reserves the resources required to support as many as possible of the requested property group alternatives that it can currently support.

7.1.8.2.3.2 ReserveValue = "True" AND ReserveGroup = "False"

If ReserveValue is "True", the MG reserves the resources required to support as many as possible of the requested property value alternatives that it can currently support.

NOTE: If a Local or Remote Descriptor contains multiple groups of properties, and ReserveGroup is "True", then the MG is requested to reserve resources so that it can decode or encode the media stream according to any of the alternatives. For instance, if the Local Descriptor contains two groups of properties, one specifying packetized ITU-T G.711 A-law audio and the other ITU-T G.723.1 audio, the MG reserves resources so that it can decode one audio stream encoded in either ITU-T G.711 A-law format or ITU-T G.723.1 format. The MG does not have to reserve resources to decode two audio streams simultaneously, one encoded in ITU-T G.711 A-law and one in ITU-T G.723.1. The intention for the use of ReserveValue is analogous.

7.1.8.2.3.3 ReserveValue = "True" OR ReserveGroup = "True"

If ReserveGroup is "True" or ReserveValue is "True", then the following rules apply:

• If the MG has insufficient resources to support all alternatives requested by the MGC, and the MGC requested resources in both Local and Remote, the MG should reserve resources to support at least one alternative each within Local and Remote.

• If the MG has insufficient resources to support at least one alternative within a Local (Remote) Descriptor received from the MGC, it shall return an empty Local (Remote) in response.

• In its response to the MGC, when the MGC included Local and Remote Descriptors, the MG shall include Local and Remote Descriptors for all groups of properties and property values it reserved resources for. If the MG is incapable of supporting at least one of the alternatives within the Local (Remote) Descriptor received from the MGC, it shall return an empty Local (Remote) Descriptor.

• If the Mode Property of the LocalControl Descriptor is "RecvOnly", "SendRecv", or "LoopBack", the MG must be prepared to receive media encoded according to any of the alternatives included in its response to the MGC.

NOTE: If a Local or Remote Descriptor contains multiple groups of properties, and ReserveGroup is "True", then the MG is requested to reserve resources so that it can decode or encode the media stream according to any of the alternatives. For instance, if the Local Descriptor contains two groups of properties, one specifying packetized ITU-T G.711 A-law audio and the other ITU-T G.723.1 audio, the MG reserves resources so that it can decode one audio stream encoded in either ITU-T G.711 A-law format or ITU-T G.723.1 format. The MG does not have to reserve resources to decode two audio streams simultaneously, one encoded in ITU-T G.711 A-law and one in ITU-T G.723.1. The intention for the use of ReserveValue is analogous.

7.1.8.2.3.4 ReserveValue = "False" AND ReserveGroup = "False"

If ReserveGroup is "False" and ReserveValue is "False", then the MG should apply the following rules to resolve Local and Remote to a single alternative each:

• The MG chooses the first alternative in Local for which it is able to support at least one alternative in Remote.

• If the MG is unable to support at least one Local and one Remote alternative, it returns Error Code 510 ("Insufficient resources").

• The MG returns its selected alternative in each of Local and Remote.

  NOTE 2 – The above rules allow the MG to prioritize the selection of the same codec in both the Local and Remote Descriptors; however, it also permits the MG to choose different codecs in each descriptor.

A new setting of a Local or Remote Descriptor completely replaces the previous setting of that descriptor in the MG. Thus, to retain information from the previous setting, the MGC must include that information in the new setting. If the MGC wishes to delete some information from the existing descriptor, it merely resends the descriptor (in a Modify Command) with the unwanted information stripped out.

[End Correction]

7.1.  Updated ABNF reference

Issue:	H.248.9 contains a reference to RFC4234 for ABNF syntax. This RFC has been obsoleted. The latest definition of ABNF is RFC 5234 which is also known as STD 68. The updates to the RFC are mainly with regards to its use with email. There are no changes that effect H.248 encoding.
Reference:	Discussions resulting from H.248.66 (COM16-C.351).

[Begin Correction]

Bibliography

[b-IETF RFC 2279]

IETF RFC 2279 (1998), UTF-8, a transformation format of ISO 10646.

[b-IETF RFC 2326]

IETF RFC 2326 (1998), Real Time Streaming Protocol (RTSP).

[b-IETF RFC 2805]

IETF RFC 2805 (2000), Media Gateway Control Protocol Architecture and Requirements.

[b-IETF RFC 4234 5234]

IETF RFC 4234 5234 (2005 2008), Augmented BNF for Syntax Specifications: ABNF.

[b-UN M.49]

United Nations (1999), Standard Country or Area Codes for Statistical Use Revision 4 Sales No. 98.XVII.9.

[b-W3C EMMA]

W3C (2009), EMMA: Extensible Multimodal Annotation markup language.

[End Correction]

8.1.  Packet types subject to detection logic

Issue:

The context of H.248.40 usage was apparently fairly straightforward when H.248.40 was developed in 2006/07. Since that time some weaknesses (from specification perspective) have been observed, primarily related to following three items: The definition of the adid/ipstop event itself (in clause 6.2.1) is lacking the precise semantics related to the detection condition. This information is contained in the scope section (clause 1). Notion of "application data", leading to the question that there might be potentially application (protocol) specific detection conditions. Notion of "IP data packet", hence there are obviously also IP control packets? Is there any relation to H.248 media flow and H.248 control flow components? These should be clarified.

Reference:

AVD-4426

[Begin Proposed Correction]

1 Scope

This Recommendation allows a media gateway controller to request the media gateway to detect that after a certain period of time no Internet protocol application data has flowed on a particular termination/stream. The ability to detect if Internet protocol application data flow has stopped or has not started is useful to avoid dead lock in latching scenarios and also may be of use to detect hanging bearers.

This Recommendation defines an event which is related to one or more IP 2-tuples[strike] . An individual 2-tuple is given by <IP address, IP port> of an IP flow of a H.248 stream or termination. The set of conditions for inactivity detection is related to IP packet arrival and/or departure events for all 2-tuples of a stream/termination. The condition of packet arrivals or departures respectively is controlled via a dedicated parameter (called "direction").

It has to be noted that there might be typically more detection conditions on top of the pure observation of "IP transport endpoint" (given by IP 2-tuple) activity. The entire detection conditions are effectively given by the stream/termination specific lookup key (clause 3.1.2/[ITU-T H.248.79]), which defines the particular packet-to/from-Context delivery process, according clause 6/[ITU-T H.248.79]. Appendix IV provides some examples for traffic components which would match (or not) such lookup keys.

The flexibility of inactivity detection logic configurations allows the usage of H.248.40 for various applications (see also appendices I to III).

6 Application data inactivity detection package

Package Name

Application data inactivity detection package

Package ID

adid (0x009c)

Description

This package enables the MGC to be notified when the MG has detected that no IP application data flow has been detected on a termination/stream.
The condition of packet arrivals or departures respectively is controlled via a dedicated parameter (called "direction").

Version

1

Extends

None

…​

Appendix IV

Examples for IP application data traffic
(This appendix does not form an integral part of this Recommendation)

The ipstop event related detection logic for application data inactivity is based on the observation of the n-tuple, given by stream/termination specific lookup key.

Such a condition comprises following IP traffic components, such as:

• ALL IP packets related to a H.248 media flow and H.248 control flow components

• Bearer and service specific examples:

  • RTP session: RTCP and RTP, and not only RTP

  • T.38 session: e.g. all UDPTL/UDP packets in case of T.38-over-UDP

  • XoTCP: all TCP packets

  • WWW services: all HTTP/TCP packets

  • Streaming service: e.g., RTSP, RTP, RTCP

  • WebRTC service: all UDP packets (for audio, video, text, data, security key exchange, RTCP XR, etc)

Out $\text{of the}$ scope of adid logic are:

• ICMP/IP packets

• IP packets related to IP routing protocols (e.g., OSPF/IP packets)

[End Proposed Correction]

9.1.  Rate policing clarifications

Issue:

H.248.53 does not specifically discuss relevant traffic components of an IP flow as part (or not) of traffic policy, e.g. when considering IP bearer traffic policing (clause 9.4/H.248.53 and applied packages from clauses 7 and 8). Following basic issue was observed: A single or multiple IP flow(s) associated to an H.248 stream/termination could be basically divided in two IP traffic portions: IP application data traffic related to the communication application itself, i.e., with end-to-end significance; and IP-based control traffic along the bearer path, with purpose of NAT traversal, authentication procedures, bearer control protocol for (segmented) IP transport connections (e.g., TCP segment), bearer control protocol for (segmented) IP security sessions, etc., i.e., without end-to-end significance (rather type hop-to-hop). Both traffic portions provide following difference from H.248 Context point of view: the e2e traffic (1) is going through the Context, and traffic (2) is terminated by a SEP. That's an important distinction concerning traffic policing, which has originally only e2e traffic (1) in scope, but not (2) (in our understanding).

Reference:

AVD-4427

[Begin Proposed Correction]

6 Traffic management package

Package name

Traffic management package

Package ID

tman (0x008d)

Description

This package allows traffic descriptors to be defined for a stream and allows policing to be explicitly enabled. Version 1 is defined for a single traffic flow per H.248 stream. Version 2 supports multiple traffic flows per H.248 stream.
Traffic related to the control (establishment, maintenance or release) of a H.248 flow is excluded from traffic policing. E.g. RTCP flows are still included.

Version

2

Extends

None.

…​

8 Packet size package

Package name

Packet size package

Package ID

pacs (0x00c9)

Description

This package defines a property for the maximum allowed packet size. Such a traffic parameter may be used for traffic policing. This package is typically used for "media-agnostic" ephemeral terminations (Note 1), and/or when provisioning is insufficient (Note 2).

NOTE 1 – The MG may not be aware of the media type/format behind an IP termination (e.g., a MG implementing the ETSI_BGF profile according to [b-ETSI ES 283 018]). It is impossible for such a MG to derive or estimate the maximum possible packet size from information elements of the media descriptor.

NOTE 2 – The provisioning possibility is excluded for multimedia applications with different packet size distribution functions for the various media components.
This package defines also a property for the minimum policed unit, which is also typically used for traffic policing.

Traffic related to the control (establishment, maintenance or release) of a H.248 flow is excluded from traffic policing. E.g. RTCP flows are still included.

Version

1

Extends

tman version 1

[End Proposed Correction]

10.1.  Superfluous reference

Issue:	ITU-T H.248.69 contains a reference to IETF RFC 4976 however it is not used in the main text. Therefore the reference can be removed.
Reference:	AVD-4397

[Begin Proposed Correction]

2 References

The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.

[ITU-T H.248.1]

Recommendation ITU-T H.248.1 (2005), Gateway control protocol: Version 3.

[ITU-T H.248.7]

Recommendation ITU-T H.248.7 (2004), Gateway control protocol: Generic announcement package.

[ITU-T H.248.9]

Recommendation ITU-T H.248.9 (2005), Gateway control protocol: Advanced media server packages.

[ITU-T H.248.19]

Recommendation ITU-T H.248.19 (2004), Gateway control protocol: Decomposed multipoint control unit, audio, video and data conferencing packages.

[ITU-T H.248.43]

Recommendation ITU-T H.248.43 (2008), Gateway control protocol: Packages for gate management and gate control.

[ITU-T H.248.47]

Recommendation ITU-T H.248.47 (2008), Gateway control protocol: Statistic conditional reporting package.

[IETF RFC 2822]

IETF RFC 2822 (2001), Internet Message Format.

[IETF RFC 3339]

IETF RFC 3339 (2002), Date and Time on the Internet: Timestamps.

[IETF RFC 3860]

IETF RFC 3860 (2004), Common Profile for Instant Messaging (CPIM).

[IETF RFC 3862]

IETF RFC 3862 (2004), Common Presence and Instant Messaging (CPIM): Message format.

[IETF RFC 3986]

IETF RFC 3986 (2005), Uniform Resource Identifier (URI): Generic Syntax.

[IETF RFC 4021]

IETF RFC 4021 (2005), Registration of Mail and MIME Header Fields.

[IETF RFC 4975]

IETF RFC 4975 (2007), The Message Session Relay Protocol (MSRP).

[IETF RFC 4976]

IETF RFC 4976 (2007), Relay Extensions for the Message Session Relay Protocol (MSRP).

[IETF RFC 5228]

IETF RFC 5228 (2008), Sieve: An Email Filtering Language.

[End Proposed Correction]

11.1.  Updated reference

Issue:	The remaining IETF draft < draft-ietf-mmusic-sdp-cs-21> in the Bibliography has been published as RFC and could be corrected in the Recommendation.
Reference:	AVD-4650

[Begin Proposed Correction]

1 Scope

Recommendation ITU-T H.248.80 describes the interworking of the SDP described by the "Revised SDP Offer/Answer (O/A) model" with ITU-T H.248. The "Revised SDP Offer/Answer model" is characterized by the following documents:

• SDP capability negotiation (SDPCapNeg) defined in [IETF RFC 5939]

• SDP media capabilities negotiation (MediaCapNeg) defined in [IETF RFC 6871]

  NOTE – The support of miscellaneous capabilities negotiation in the Session Description document [b-IETF RFC 7006] and Extension for PSTN bearers [b-IETF SDPCS RFC 7195] is for further study.

This Recommendation describes the relationship between the ITU-T H.248 group concept and the revised SDP offer/answer model concepts of actual and potential configurations. It provides guidelines for the inter-working between SDPCapNeg and normal ITU-T H.248.1 procedures. Rather than focussing on the SDPCapNeg procedures in the context of session handling, this Recommendation concentrates on mapping the between ITU-T H.248.1 and the SDP Capability negotiation framework SDP syntax. For interactions between the functions of SDPCapNeg and different SDP attributes, see [IETF RFC 5939] and associated IETF documents.

This Recommendation also discusses the support of [IETF RFC 6871] by ITU-T H.248.

In order to address several deficiencies in interworking between SDPCapNeg and [IETF RFC 6871] and ITU-T H.248 this Recommendation defines two packages that allow a more optimized support of the revised SDP offer/answer procedures on MGCs that also support ITU-T H.248.

[End Proposed Correction]

[Begin Proposed Correction]

Bibliography

[b-ITU-T G.711]

Recommendation ITU-T G.711 (1988), Pulse code modulation (PCM) of voice frequencies.

[b-ITU-T G.729]

Recommendation ITU-T G.729 (1996), Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear prediction (CS-ACELP).

[b-ITU-T H.263]

Recommendation ITU-T H.263 (2005), Video coding for low bit rate communication.

[b-ITU-T H.264]

Recommendation ITU-T H.264 (2012), Advanced video coding for generic audiovisual services.

[b-ITU-T V.152]

Recommendation ITU-T V.152 (2010), Procedures for supporting voice-band data over IP networks.

[b-IETF RFC 3264]

IETF RFC 3264 (2002), An Offer/Answer Model with the Session Description Protocol (SDP).

[b-IETF RFC 7006]

IETF RFC 7006 (2013), Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP).

[b-IETF SDPCS RFC 7195]

IETF RFC 7195 (2014) draft-ietf-mmusic-sdp-cs-21 (2013), Session Description Protocol (SDP) Extension for Setting up Audio and Video Media Streams over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN). http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-23

[End Proposed Correction]

12.1.  Incorrect reference

Issue:	ITU-T H.248.83, clause 1 makes reference to a 3GPP reference point. The named the reference point "Mn" provides a reference to [b-3gpp TS 29.232] which is in fact the specification for the "Mc" reference point. The reference point name needs to be corrected.
Reference:	COM16-C.470

[Begin Proposed Correction]

1 Scope

There has been a trend towards virtualized or cloud-based networks where a physical device or network hosts several virtual instances meeting the needs of different customers. Different service models exist, usually utilizing the terminology "x – as a service (xASS)", e.g., platform as a service (PAAS) and infrastructure as a service (IAAS).

A common aspect of the different cloud service models is that a certain set of resources is allocated (via an operations and maintenance (O&M) system) based on a set of customer requirements. These requirements may detail the applications, libraries, data, memory, processing resources, storage, and associated configuration settings.

One of the main concepts of ITU-T H.248 is the use of the virtual media gateway (VMG). This allows multiple VMG instances per physical media gateway (MG). Each VMG is treated as a separate MG instance and thus has its own control association and set of resources, configurations, etc. Thus, it has similarities to cloud virtualization concepts.

ITU-T H.248 is largely silent on provisioning resources for VMGs, apart from clause 11.1 of [ITU-T H.248.1], which states that the mechanism for allocating terminations to VMGs is a management method outside the scope of [ITU-T H.248.1]. Whilst the provisioning of terminations is out of the scope of ITU-T H.248, it does have the "ITU-T H.248 Profile" concept. Profiles specify what options associated with [ITU-T H.248.1] have been used. Appendix III of [ITU-T H.248.1] provides an example profile template showing the information that can be derived from the profile ID. ITU-T H.248 profiles, when used by a virtual media gateway (VMG), indicate what ITU-T H.248 elements can be used. Profiles have been defined by several standards development organizations (e.g., 3GPP, ETSI TISPAN, MSF) and several vendors to define the ITU-T H.248 functionality of certain interfaces.

ITU-T H.248 provides an abstraction model for an MGC to access and control physical resources on an MG without having to address these physical resources. The concepts of Contexts, Terminations, Streams and Descriptors are used. Whilst terminations are typically statically provisioned, the underlying resources may be statically or dynamically allocated between the VMGs. The physical resources may relate to the central processing unit (CPU), digital signal processor (DSP), memory, storage, or power use. So whilst the ITU-T H.248 options defined by an ITU-T H.248 Profile are related to these resources, there is not a one–to-one mapping due to the abstraction layer. Some form of provisioning is required to assign the physical resources to a VMG instance.

ITU-T H.248 allows an MG and MGC to negotiate the use of a certain profile (functionality set) via the use of the ServiceChangeProfile parameter (see clause 7.2.8.1.5 of [ITU-T H.248.1]). An example profile is the Mc reference point n interface (profile name: threegbicsn) defined by [b-3GPP TS 29.232]. However, this does not identify a particular resource profile. The MGC cannot deduce from the profile name how resources are provisioned on the (V)MG. The set of provisioned resources could be tied to the media gateway identity (ITU-T H.248 Mid) but this unnecessarily ties the transport network configuration to the MG hardware configuration. Many ITU-T H.248 packages specify a default of "provisioned" for the elements defined by the package. It is assumed that these are co-ordinated via other provisioning means (e.g., SNMP MIBs). As an ITU-T H.248 MG can be provisioned with different sets of resources per ITU-T H.248 Profile Name and/or Mid another form of correlation identity between the MGC and MG to coordinate what has been provisioned is required.

This identifier can be used by network operators as a pointer to a set of provisioned configuration data. Upon reception of the identifier, the MGC can uniquely identify the provisioned defaults and other configuration data and then request (V)MG resources accordingly.

This Recommendation defines functionality that allows an MG to indicate to an MGC what media gateway instance is in use. It also allows an MGC to audit an MG to determine the MG instance in use. This Recommendation utilises a ServiceChangeExtension parameter that allows the MG instance to be reported during an initial ServiceChange command exchange. An ITU-T H.248 package is defined to allow an MGC to audit packages to determine if the MG instance functionality is supported. It also allows the auditing of a root Termination property to determine the MG instance.

[End Proposed Correction]

13.1.  Updated reference

Issue	Two of the IETF drafts in the Bibliography have been published as IETF RFCs. The references should be updated.
Reference:	AVD-4601

[Begin Proposed Correction]

III.3.1 RTP-agnostic application level metrics

Example metrics:

These examples are based on the pure application data stream at receiver side:

• Unimpaired seconds [b-IETF rtcp-xr-conc RFC 7294]

• Concealed seconds [b-IETF rtcp-xr-conc RFC 7294]

• Severely concealed seconds [b-IETF rtcp-xr-conc RFC 7294]

• Unimpaired seconds [b-IETF rtcp-xr-conc RFC 7294]

• Frame impairment statistics summary [b-IETF RFC 7004].

The following example relates to FAX-over-IP using [ITU-T T.38] in T.38-over-RTP transport mode and an ITU-T H.248 IP termination enabled with the IP FAX package [ITU-T H.248.2]:

• Pages transferred defined by ITU-T H.248 statistic ipfax/pagestrans; is an application level metric due to data object 'page' and RTP-agnostic due to independence of RTP header information.

Statistics of RTP application data package [ITU-T H.248.58] (again due to RTP payload relation only (application data) but independence of RTP header information):

• RTP payload octets sent and

• RTP payload octets received.

III.3.2 RTP-aware application level metrics

For these metrics the measurement function must be media format aware based on the RTP payload type codepoint in contrast to the examples of clause III.3.1.

Example metrics:

• MOS value (attributed by MOS type and calculation method) [b-IETF RFC 7266 rtcp-xr-qoe]

• Signal level [IETF RFC 3611]

• Noise level [IETF RFC 3611]

• Residual echo return loss [IETF RFC 3611]

• R factor [IETF RFC 3611]

• External R factor [IETF RFC 3611]

• End system delay [b-IETF RFC 6843] (virtual internal round-trip delay in topology RTP end system; it is an application level metric due to inclusion of encoding/decoding delays).

[End Proposed Correction]

[Begin Proposed Correction]

Bibliography

[b-ITU-T H.248.xnq]

(Expired) Draft of Recommendation ITU-T H.248.xnq (2005), Gateway control protocol: Extended network quality metrics packages for next generation networks (NGNs). Document AVD-2773 from WP2/16 Rapporteur Meeting (Geneva 28 November – 2 December 2005). http://ftp3.itu.int/av-arch/avc-site/2017-2020/0511_Gen/AVD-2773.zip

…​

[b-IETF RFC 7005]

IETF RFC 7005 (2013), RTP Control Protocol (RTCP) Extended Report (XR) Block for De-Jitter Buffer Metric Reporting.

[b-IETF rtcp-xr-qoe RFC 7266]

IETF RFC 7266 (06/2014) draft-ietf-xrblock-rtcp-xr-qoe (expected in 2014), RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting. https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-qoe/

[b-IETF rtcp-xr-conc RFC 7294]

IETF RFC 7294 (07/2014) draft-ietf-xrblock-rtcp-xr-conceal (expected in 2014), RTCP XR Report Block for Concealment metrics Reporting on Audio Applications. https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-loss-conceal/

[End Proposed Correction]

14.1.  Updated reference

Issue:	RFC 7667 "RTP topologies" obsoletes RFC 5117, the baseline RFC of H.248.88. RFC 7667 was published after the publication of H.248.88.
Reference:	COM16-C.1054

[Begin Proposed Correction]

7.2.2 Other RTP topologies

The high-level RTP topology models according to [b-IETF RFC 5117] have evolved since the publication of this RFC (in 2008) in terms of more detailed information (e.g., semantic clarifications), evaluation of whether the number of existing models can be reduced and the identification of new RTP topology models (see also [b-IETF rtp-topo RFC 7667]). This clause provides descriptions of such new/extended models.

[End Proposed Correction]

[Begin Proposed Correction]

Bibliography

…​

[b-IETF rtp-topo RFC 7667]

IETF draft-ietf-avtcore-rtp-topologies-update IETF RFC 7667, RTP Topologies. http://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update

[End Proposed Correction]