7 Codec definitions for IP User Data
34.229-33GPPInternet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Part 3: Abstract test suite (ATS)Release 17TSUser Equipment (UE) conformance specification
7.1 Introduction
SIP is a text-based protocol, thus the message exchange between the UE and the SS are pure character strings. In the TTCN-3 ATS the messages are structured and optimized to take the advantage of TTCN-3 functionality, and to make the debugging and maintenance of the ATS easier.
7.2 General Aspects
IP user data for IMS conformance testing can be distinguished into:
1. text based: SIP (including SDP and XML messages), HTTP (see clause 7.4)
2. octetstring based: DHCP, DHCPv6, DNS (see clause 7.4)
In TTCN the following encoding information is used for user data:
Table 7.2-1
|
Type definitions |
Encoding |
|
SMS Types |
Tabular notated (see note 1) |
|
DHCPv4-Codec |
Tabular notated (see note 1) |
|
DHCPv6-Codec |
Tabular notated (see note 1) |
|
DNS-Codec |
Tabular notated (see note 1) |
|
SIPCodec |
(see clause 7.3) |
|
SDPCodec |
(see clause 7.3) |
|
HttpCodec |
(see clause 7.3) |
NOTE 1: Tabular notated is performed by concatenation of all the present fields in the TTCN-3 template.
NOTE 2: Encoding information is only needed for type definitions of peer-to-peer signalling; encoding of ASPs used for system configuration or as co-ordination messages between PTCs is out of scope for this document.
7.3 Requirements on abstract message syntax for IMS (SIP, SDP)
7.3.1 Type definition – Syntax / Semantic aspects
All given defined BNF grammars (e.g. the ABNF of RFC 3261) are unique. Thus the syntax tree for each syntactically correct message derived with these grammars are unique too and the parts of a message can be uniquely identified (represented) by the terminal phrase belonging to a non terminal symbol and its derivation path in the syntax tree.
The syntax tree of all given messages can be used to uniquely identify and describe the parts of the messages. The leaves are the part of every message and the nodes from the root to the leaves represent the sequence of rules to be applied to derive that part
The IMS/SIP root message type is an ordered structured type, which is represented as a record type in TTCN-3. For each grammar rule of the ABNF a TTCN-3 record type is declared with the specific name of the rule. The following rules are applied to the fields within a record:
– A non-terminal symbol is declared as a record type for this symbol.
– The order of the symbols in the rule are represented by an equal order of the fields.
– Repetitions are declared as ‘set of’ or ‘record of’ types.
– Options are represented as optional record/set fields.
– Alternatives are declared as union types.
7.3.2 Deviations of the type definition semantic
– Most of the ‘literals’ of a message (for example: the string "Via" or "v" in the message header fields) are not represented.
– The TTCN-3 charstring type is used where we stop structuring even if the ABNF uses structured types. More details found in clause 8.3.3.
– Wherever possible parts are mapped to their best type representation, e.g. DIGIT based rules are mapped to integer type not to a charstring type.
– All of the following delimiters (including preceding or following whitespace) defined by the ABNF grammar to separate the parts of a message are not represented (see note).
STAR = SWS "*" SWS ; asterisk
SLASH = SWS "/" SWS ; slash
EQUAL = SWS "=" SWS ; equal
LPAREN = SWS "(" SWS ; left parenthesis
RPAREN = SWS ")" SWS ; right parenthesis
RAQUOT = ">" SWS ; right angle quote
LAQUOT = SWS "<"; left angle quote
COMMA = SWS "," SWS ; comma
SEMI = SWS ";" SWS ; semicolon
COLON = SWS ":" SWS ; colon
LDQUOT = SWS DQUOTE; open double quotation mark
RDQUOT = DQUOTE SWS ; close double quotation mark
HCOLON = *( SP / HTAB ) ":" SWS
SP = single space
HTAB = tab
SWS = sep whitespace
NOTE: If they are present within a pure charstring they will be handled like a normal character and are still included.
– Messages which are not of interest to the test suite are left undecoded as a charstring and will not be further structured.
Further clarifications on the handling of delimiters are provided hereafter:
In many cases the TTCN-3 type definitions are of lower granularity than the BNF and the codec shall consider the TTCN type definitions only. Therefore as stated in the NOTE above the rules for handling of delimiters do not require delimiters to be blindly removed from strings but the codec shall only deal with the delimiters needed to encode/decode the TTCN-3 types; sub-structures of the BNF being mapped to TTCN-3 charstrings need to be handled in TTCN and are out of scope of the codec implementation.
Example 1:
According to the BNF Alert-Info is defined as
Alert-Info = "Alert-Info" HCOLON alert-param *(COMMA alert-param)
alert-param = LAQUOT absoluteURI RAQUOT *( SEMI generic-param )
The corresponding TTCN-3 type definition is
type record AlertInfo { FieldName fieldName (ALERT_INFO_E),
AlertInfoBody_List alertInfoBody optional }
type set of AlertInfoBody AlertInfoBody_List;
type record AlertInfoBody { charstring url,
SemicolonParam_List genericParams optional }
⇒ LAQUOT and RAQUOT are delimiters of the URI field which shall be removed by the codec in UL.
Example 2:
Some fields according to the BNF for SIP are defined as “(token LWS)/ quoted-string”, i.e. the field can be either a (case-insensitive) token or a quoted string. In general in TTCN this can be mapped
a) to a charstring or
b) to a union of two charstring (one for the token, one for the quoted string).
In case of a) the codec shall preserve the double-quotes for the quoted-string as otherwise it cannot be distinguished from a token anymore which is vital when case-sensitivity matters whereas in case of b) the double quotes shall be removed.
7.3.3 Additional requirements for codec implementations (SIP/IMS Message
The SIP/IMS codec is based on a normalized encoding which is always produced by an encoder. Decoder implementations, however, have to handle normalization before, or when constructing the structured message value, e.g. long versus compact form, whitespace compression, delimiter removal, same header grouping, etc. All these aspects will be handled in the next clause.
7.3.3.1 Differences between BNF – TTCN-3 Type Mapping
In normal cases the mapping is straight forward. Below you find the exceptions, including potential examples.
– The root message type is not a SIP-message but directly a Request or Response type which is represented as a TTCN-3 record. All Method – Message names (INVITE, BYE, ACK etc.) and all message header field names (To, From, CallID, Cseq, Via etc.) are mapped to an enumerated type in TTCN-3 to simplify the extension of new headers. During encoding, the long-form of these message header fields is always used. The respective field in the header type is restricted to values which are allowed.
|
BNF rules of RFC |
TTCN-3 Type Mapping |
|
SIP-message = Request / Response |
type record REGISTER_Request {…}, type record INVITE_Request {…}, type record PRACK_Request {…}, type record NOTIFY_Request {…}, type record UPDATE_Request {…}, … type record Response {…} |
|
Method = INVITEm |
type enumerated Method { ACK_E, BYE_E, CANCEL_E, INVITE_E, OPTIONS_E, REGISTER_E, …} |
– The structure of the message header fields are mapped to a "set " type in TTCN-3, because the order of these header fields is not mandatory. There is an Unknown Header List given in the type system to decode unknown headers with ID and Value.
|
Message-header = ( … / Contact / Content-Disposition … / Via / Warning / WWW-Authenticate / extension-header) CRLF |
type set MessageHeader { … Contact contact optional, ContentDisposition contentDisposition optional, … Via via, Warning warning optional, WwwAuthenticate wwwAuthenticate optional, UndefinedHeader_List undefinedHeader_List optional } |
– The various parameter lists defined in the BNF are mapped and combined into three different TTCN-3 sets of generic-param types. These types differ only in their name: SemicolonParam_List, AmpersandParam_List, CommaParam_List to distinguish between the relevant separators.
|
Uri-parameters = *( ";" uri-parameter) |
type set of GenericParam SemicolonParam_List; |
|
Authentication-Info = "Authentication-Info" HCOLON ainfo *(COMMA ainfo) |
type record AuthenticationInfo { FieldName fieldName(AUTHENTICATION_INFO_E), CommaParam_List ainfo } |
|
ainfo = nextnonce / response-auth / nonce-count |
type set of GenericParam CommaParam_List; |
|
Headers = "?" header *( "&" header ) |
type set of GenericParam AmpersandParam_List; |
– Any more specific parameter rule (e.g. uri-param, user-param, lr-param , digest-cln, etc.) is simplified to the generic-param rule which will be mapped as a record structure of two charstrings (ID and paramValue). This is equivalent to a token with an optional generic value (token [ EQUAL gen-value ]).
|
Digest-cln = realm / qop-options |
type record GenericParam { charstring id , charstring paramValue optional } |
– In addition to the pure charstring as a base type, the TTCN-3 type system provides base integer types which are unrestricted to the model e.g. the portField, Cseq number, maxForward digit.
|
User = 1*( unreserved telephone-subscriber as defined in RFC 2806 |
charstring |
|
password = *( unreserved |
charstring |
|
Port = 1*DIGIT |
integer |
|
Status-Code = Informational / Redirection / Success / Client-Error / Server-Error / extension-code |
integer |
– Where the same header type can appear multiple times within a message, they will be decoded as a single header field, with multiple list elements. The order of appearance of the headers will be preserved within the header list value.
|
Contact = ("Contact" / "m" ) HCOLON ( STAR / (contact-param |
type record Contact { FieldName fieldName(CONTACT_E), ContactBody contactBody } |
|
contact-param = (name-addr / addr-spec) |
type record ContactAddress { Addr_Union addressField, SemicolonParam_List contactParams optional } type union ContactBody { charstring wildcard, ContactAddress_List contactAddresses } Used in type set of ContactAddress ContactAddress_List; |
– The BNF (clause 7.3.1 Header Field Format RFC 3261 [16]) specifies that several WWW or Proxy Authentication/Authorization headers should not be combined into a single header; however they will be decoded into such in the codec. If these need to be sent downlink then a new, ‘raw’ (pure charstring) message type will be introduced.
|
Authorization = "Authorization" HCOLON credentials |
type record Authorization { FieldName fieldName(AUTHORIZATION_E), Credentials body } |
|
Credentials = ("Digest" LWS digest-response) / other-response |
type union Credentials { CommaParam_List digestResponse, OtherAuth otherResponse } |
– The different schemes (sip, sips, tel, fax, absoluteUri) in the SIP URI are all handled via the same type definition. The union “UriComponents” can be enhanced to support further specific URI formats. Nevertheless it is possible to use the “other” branch of “UriComponents” for any other URI format in which case the charstring shall contain the URI without the scheme and the first “:”.
|
Request-URI = SIP-URI with SIP-URI = "sip:" [ userinfo ] and SIPS-URI = "sips:" and absoluteURI = scheme ":" ( hier-part / opaque-part ) |
type record SipUriComponents { // sip-uri acc. To RFC 3261 [16] cl. 19.1 UserInfo userInfo optional, HostPort hostPort } type record TelUriComponents { // tel-uri acc. To RFC 3966 [38] charstring subscriber } type record UrnUriComponents { // urn-uri acc. To RFC 2141 [39] charstring namespaceId, // e.g. "service" charstring namespaceSpecificString // e.g. "sos" } type union UriComponents { SipUriComponents sip, // scheme: "sip" or sips" TelUriComponents tel, // scheme: "tel" UrnUriComponents urn, // scheme: "urn" charstring other } type record SipUrl { charstring scheme, UriComponents components, SemicolonParam_List urlParameters optional, AmpersandParam_List headers optional }type record SipUrl { charstring scheme, UserInfo userInfo optional, HostPort hostPort, SemicolonParam_List urlParameters optional, AmpersandParam_List headers optional } |
– Universal charstrings shall be supported by the codec especially for the Display name in the URI.
– For downlink messages the len field in the ContentLength header is always set to 0 by TTCN; in case of the SIP message containing a message body SS shall replace the value by the actual length of the encoded message body (see clause 7.3.4).
– According to the SIP type definitions there are many ‘charstring’ fields being optional in records;
⇒ in UL the decoder shall map missing information by setting the respective field to omit rather than by assigning an empty string (“”).
– type union Addr_Union
As in ‘NameAddr’ the field ‘displayName’ is optional in the first place the two branches of ‘Addr_Union’ are equivalent when there is no ‘displayName’; nevertheless in UL the decoder shall use the branch ‘nameAddr’ if – and only if – the address information is surrounded by ‘<’ and ‘>’ (what is needed at least when there is a display name followed by the address information)
– Ipv6 address in URI
When an Ipv6 address is used as hostname in a SIP URI it is typically surrounded by ‘[‘ and ‘]’ what is matter of the codec: in DL the codec shall add ‘[‘ and ‘]’ when needed, in UL the ‘[‘ and ‘]’ shall be removed i.e. in the ‘host’ field of the SipUriComponents’ hostPort there shall be no ‘[‘ or ‘]’ at the beginning or at the end.
7.3.3.2 URL Encoding
Several fields or parameters in SIP headers require URL encoding (e.g. Contact header, Accept-Contact header). In TTCN there is no encoding rule defined for URL encoding and there is no specific type definition for URL encoded strings. For that reason URL encoding/decoding is not a matter of codec implementation but shall be done in TTCN.
7.3.4 Additional requirements for codec implementations (Message Body)
The message body of a SIP message may contain the message of other protocols (SDP, SMS, etc.) and can be represented e.g. by XML. Therefore the type definitions for these protocols can be TTCN-3 as well as XSD definitions.
As in principle the message body of a SIP message may host any XSD definition, SIP and XSD definitions are decoupled:
To avoid import of all potential XSD definitions the XML body of SIP messages is defined as a charstring. This requires a two-stage encoding and decoding: In DL an XML message needs to be encoded in TTCN first before it gets put in the message body of a SIP message, in UL the XML message contained in the message body needs to be explicitly decoded in TTCN. By defining the XML message body as a charstring the SIP definitions are independent from any XSD definitions and a specific XSD definition needs to be known only when it is really used.
An SDP message may be contained in the message body itself or in a MIME message. In both cases the SDP message is represented as charstring in the SIP message and as for XML a two-stage encoding and decoding is applied in TTCN. This allows explicit fail assignments in case of syntactically incorrect SDP messages when syntactical correctness is a test requirement.
NOTE: Test specifications (e.g. TS 34.229-1 [5]) define the criteria for syntactical correctness and codec implementations follow these criteria.
In detail the message body for SIP messages is defined as:
|
type charstring XmlBody; type charstring SdpBody; type union MessageBody { SdpBody sdpMessageBody XmlBody xmlBody, MIME_Message mimeMessageBody, charstring sipfrag, charstring textplain, SimpleMsgSummary simpleMsgSummary, octetstring smsMessage }; |
|
NOTE: In contrast to SIP and SDP definitions which are commonly defined by ETSI the definition of the message body is project specific i.e. other IMS test projects at ETSI may use different definitions of the message body. |
7.3.5 Additional requirements for codec implementations (SDP Body)
The Session Description Protocol is defined in RFC 4566.
– The ‘type’ fields (such as ‘v’ and ‘o’ are not represented).
– For the defined attributes, the att-field is also not represented (e.g. ‘curr’ is not represented in SDP_attribute_curr).
– The Messages which are not of interest to a test suite are left undecoded as a charstring and will not be further structured.
7.3.5.1 Differences between BNF – SDP Type Mapping
In normal cases the mapping is straight forward. Below are the exceptions which differ.
– The numerical fields in the origin-field, the time-field and the timezone field have been defined as charstring because they may not fit into a 32-bit signed integer.
|
BNF Rules of RFC 4566 |
TTCN 3 Type Mapping |
|
origin = username sess-id sess-version nettype addrtype unicast-address |
type record SDP_Origin { charstring username, charstring session_id, charstring session_version, charstring net_type, charstring addr_type, charstring addr } |
|
time-fields = start-time stop-time repeat-fields [ zone-adjustments] |
type record SDP_time_field { charstring start_time, charstring stop_time } |
|
zone-adjustments = time typed-time |
type record SDP_timezone { charstring adjustment_time, SDP_typed_time offset } |
– The zone-adjustments field in the time-fields has been included as an additional field in the top-level message definition.
|
BNF Rules of RFC 4566 |
TTCN 3 Type Mapping |
|
session-description = proto-version origin-field session-name-field information-field uri-field email-fields phone-fields connection-field bandwitdh-fields time-fields key-fields attribute-fields media-descriptions |
type record SDP_Message { integer protocol_version, SDP_Origin origin, charstring session_name, charstring information optional, charstring uri optional, SDP_email_list emails optional, SDP_phone_list phone_numbers optional, SDP_connection connection optional, SDP_bandwidth_list bandwidth optional, SDP_time_list times, SDP_timezone_list timezone_adjustments optional, SDP_key key optional, SDP_attribute_list attributes optional, SDP_media_desc_list media_list optional |
|
time-fields = start-time stop-time repeat-fields [ zone-adjustments] |
type record SDP_time { SDP_time_field time_field, SDP_repeat_list time_repeat optional } |
– The mappings for the email-address, phone-number and connection-address fields have been simplified.
|
BNF Rules of RFC 4566 |
TTCN 3 Type Mapping |
|
email-address = address-and-comment / dispname-and-address / addrspec |
type record SDP_contact { charstring addr_or_phone, charstring disp_name optional } |
|
phone-number = email-safe / email-safe "<" phone ">" / phone |
type record SDP_contact { charstring addr_or_phone, charstring disp_name optional } |
|
connection-address = multicast-address / unicast-address |
type record SDP_conn_addr { charstring addr, integer ttl optional, integer num_of_addr optional } |
7.3.5.2 Defined attributes
The SDP_attribute type is defined as a union of the following attribute types. There is an unknown attribute given to decode undefined attributes with a name and value.
|
SDP Attribute |
TTCN 3 Type Mapping |
|---|---|
|
cat |
type record SDP_attribute_cat { charstring attr_value } |
|
charset |
type record SDP_attribute_charset { charstring attr_value } |
|
conf |
type record SDP_attribute_curr { charstring preconditionType, charstring statusType, charstring direction } |
|
curr |
type record SDP_attribute_curr { charstring preconditionType, charstring statusType, charstring direction } |
|
des |
type record SDP_attribute_des { charstring preconditionType, charstring strength, charstring statusType, charstring direction } |
|
fmtp |
type record SDP_attribute_fmtp { charstring attr_value } |
|
framerate |
type record SDP_attribute_framerate { charstring attr_value } |
|
inactive |
type record SDP_attribute_inactive { } |
|
keywds |
type record SDP_attribute_keywds { charstring attr_value } |
|
lang |
type record SDP_attribute_lang { charstring attr_value } |
|
orient |
type record SDP_attribute_orient { charstring attr_value } |
|
ptime |
type record SDP_attribute_ptime { charstring attr_value } |
|
quality |
type record SDP_attribute_quality { charstring attr_value } |
|
recvonly |
type record SDP_attribute_recvonly { } |
|
rtcp |
type record SDP_attribute_rtcp { charstring attr_value } |
|
rtpmap |
type record SDP_attribute_rtpmap { charstring attr_value } |
|
sdplang |
type record SDP_attribute_sdplang { charstring attr_value } |
|
sendrecv |
type record SDP_attribute_sendrecv { } |
|
sendonly |
type record SDP_attribute_sendonly { } |
|
Tool |
type record SDP_attribute_tool { charstring attr_value } |
|
Type |
type record SDP_attribute_type { charstring attr_value } |
|
Unknown |
type record SDP_attribute_tool { charstring name, charstring attr_value optional } |
7.3.6 Additional requirements for codec implementations (HTTP)
For HTTP the same types and header are used as for SIP.
⇒ Rules and requirements are applicable as defined for SIP in clause 7.3.
7.3.7 Additional requirements for codec implementations (XML)
XML data schema is used in IMS conformance testing according to ETSI ES 201 873-9. No further requirements are necessary.
7.4 Requirements for codec implementations (DHCP, DNS)
The DHCP/DNS codec converts TTCN descriptions into/from octet streams as specified in the RFCs. The TTCN type defintions for DHCP/DNS types closely follow the data formats defined in the corresponding RFCs (RFC 1035, RFC 1533, RFC 2131, RFC 3315, RFC 3319 and RFC 3361).