Partager via

2.2 Message Syntax

  • Article

The SIP SERVICE message and response message syntax are specified in [IETFDRAFT-SIPSOAP-00] section 4.0. Depending on the type of QoE metrics being published, the SIP SERVICE message that is used for this protocol MUST include either an application/vq-rtcpxr+xml Content-Type  header or an application/ms-cqf+xml Content-Type. The content is formatted as a Multipurpose Internet Mail Extensions (MIME) type SIP SERVICE message.

QoE Monitoring Agent will process the request only when the request URI is one of the following.

  • SIP URI of QoE. Each pool has a SIP URI for QoE (also known as QoE GRUU).

  • SIP URI of the pool in which QoE Monitoring Agent is hosted

  • Request URI is same to TO header. In this case, the request will be sent to home pool of the target user, and the QoE Monitoring Agent hosted on the home pool will process it.

The subsequent sections follow the product behavior specified in footnote<1>.

Each section contains a detailed specification of the XML schema to which QoE payloads MUST conform. Each element is described in a subsection, along with the child elements and attributes for that element. For each element, the following information is listed:

  • Element information: Element type and a description of the element.

  • Child elements: Name, type, availability, and description. If a child element is marked as not available, it is shown in the XML schema, but not populated by the protocol client. This protocol only includes descriptions for elements that are published by protocol clients. If a child element is marked as not supported for a specific product version, the QoE Monitoring Agent will return an error code as described in section 3.2.

  • Attributes (if any): Element ID, type, required, availability, description, and unit. If an attribute is marked as required, it MUST be present in the XML document. If an attribute is marked as not available, it is shown in the XML schema, but not populated by the protocol client. This protocol only includes descriptions for attributes that are published by protocol clients.

All string types defined within these sections are encoded in Unicode. Unless otherwise stated, if the string exceeds the number of characters specified within [], the value will be truncated. All values SHOULD be formatted as invariant culture.