One document matched: draft-trammell-ipfix-sip-msg-02.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<rfc category="info" docName="draft-trammell-ipfix-sip-msg-02"
ipr="trust200902">
<front>
<title abbrev="SIP Messages in IPFIX">
SIP Message Information Export using IPFIX
</title>
<author initials="B." surname="Trammell" fullname="Brian Trammell">
<organization abbrev="ETH Zurich">
Swiss Federal Institute of Technology Zurich
</organization>
<address>
<postal>
<street>Gloriastrasse 35</street>
<city>8092 Zurich</city>
<country>Switzerland</country>
</postal>
<email>trammell@tik.ee.ethz.ch</email>
</address>
</author>
<author fullname="Saverio Niccolini" initials="S." surname="Niccolini">
<organization abbrev="NEC">
NEC Laboratories Europe, NEC Europe Ltd.
</organization>
<address>
<postal>
<street>Kurfuersten-Anlage 36</street>
<city>Heidelberg</city>
<code>69115</code>
<country>Germany</country>
</postal>
<phone>+49 (0) 6221 4342 118</phone>
<email>niccolini@neclab.eu</email>
<uri>http://www.neclab.eu</uri>
</address>
</author>
<author fullname="Benoit Claise" initials="B." surname="Claise">
<organization>Cisco Systems Inc.</organization>
<address>
<postal>
<street>De Kleetlaan 6a b1</street>
<city>Diegem</city>
<region></region>
<code>1813</code>
<country>Belgium</country>
</postal>
<phone>+32 2 704 5622</phone>
<facsimile></facsimile>
<email>bclaise@cisco.com</email>
<uri></uri>
</address>
</author>
<author initials="H." surname="Kaplan" fullname="Hadriel Kaplan">
<organization abbrev="Acme Packet">Acme Packet</organization>
<address>
<postal>
<street>71 Third Ave.</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>USA</country>
</postal>
<phone></phone>
<email>hkaplan@acmepacket.com</email>
</address>
</author>
<date month="October" day="27" year="2011" />
<abstract>
<t>This draft defines a set of Information Elements and example
Templates for IP Flow Information Export (IPFIX) based on the SIP Common
Log Format data model, as well as additional useful SIP Information Elements,
to allow IPFIX export of application-layer information about SIP messages.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t><xref target="RFC5101">IPFIX</xref> provides a standardized means of
exporting flow information from IPFIX exporters to IPFIX collectors.
This allows collectors to analyze flows from one or more sources for
numerous uses, such as traffic patterns/trends, anomalies, failures,
attacks, and much more. IPFIX supports exporting data in near real-time,
in a secure manner, over multiple transports; as well as in local
storage with a defined file format. The core IPFIX information model is
maintained by IANA as a registry of Information Elements at
http://www.iana.org/assignments/ipfix/. In addition to these, which
cover many network measurement and management applications,
enterprise-specific Information Elements may be defined, scoped to an
SMI private enterprise number, for vendor-proprietary Information
Elements.</t>
<t>Session Initiation Protocol (SIP), defined by <xref
target="RFC3261"/> and its extensions, is used by many devices to
perform a rendezvous service, initiate and manage real-time
communication sessions, install and monitor state information, and more.
In many deployments, SIP messages cross multiple systems managed by the
same administrative entity, and thus providing a means of exporting and
collecting SIP message information from such systems using a standard
protocol is highly desirable.</t>
<t>This document defines a set of IPFIX Information Elements to enable
SIP devices, such as user agents and proxies, to export SIP message
information to IPFIX collectors using the IPFIX protocol. The purpose of
doing so is to enable collectors to analyze the SIP "traffic", for
similar purposes as those for any other IPFIX flows. Defining
IANA-registered (i.e., well-known) IPFIX IE fields enables IPFIX records
of SIP message information to be generated and consumed by different
vendors. Within the context of this document's IPFIX IE fields, a single
SIP message is a complete IPFIX Flow as defined in <xref
target="RFC5101"/></t>
<t>The SIPCLF Working Group has defined a <xref
target="I-D.ietf-sipclf-problem-statement">data model</xref> for logging
information about SIP messages to ASCII-based SIPCLF files. While useful
for on-box storage and analysis with ASCII-based tools, SIPCLF does not
provide a means of exporting such information, nor is that its goal.
This document borrows the data model from SIPCLF and represents these in
IPFIX Information Elements. It additionally provides examples for IPFIX
representation of the example SIP Messages provided in the SIPCLF
problem statement.</t>
<!-- <t>Specifically, this document defines new Information Elements for the
SIPCLF IPFIX file format (based on the data model detailed in <xref
target="I-D.ietf-sipclf-problem-statement"></xref>), proposes common
IPFIX Templates for this data model, uses these templates to define a
format, and presents examples of an IPFIX File logging format for
SIPCLF. For this purpose examples were taken from <xref
target="I-D.ietf-sipclf-problem-statement"></xref>, and torture tests to
demonstrate the applicability of the format to uncommon situations from
<xref target="RFC4475"></xref>. </t> -->
<!-- <section anchor="intro-ipfix" title="Introduction to IPFIX">
<t><xref target="RFC5101">IPFIX (IP Flow Export Protocol)</xref> is
an IETF Proposed Standard protocol for the export of network traffic
information. In addition to a transport-agnostic unidirectional
export protocol, it defines a simple encapsulation into <xref
target="RFC5655">files</xref> which expands its applicability into
logging and file storage. Originally designed for flows, its
flexible and extensible data model lends itself readily to any
situation involving events occurring on a network.</t>
<t>The central unit of or storage in IPFIX is the Message. An IPFIX
Message is composed of a header and one or more Sets. The header
contains metadata about the message such as its length and when it
was exported; see section 3.1 of <xref target="RFC5101"/> for
details. Each Set is prefixed by a header containing an ID, which
identifies the type of the set's contents; and the length of the
set; this is detailed in section 3.3 of <xref
target="RFC5101"/>.</t>
<t>The ID of the set refers to a Template describing each Record
within the Set. A Template is an ordered list of Information
Elements drawn from a registry covering many fields relevant to
network traffic export. New Information Elements may be added to the
IANA registry to cover new applications, and may also be defined on
the fly as enterprise-specific Information Elements, scoped to
private registries within an SMI Private Enterprise Number.</t>
<t>Templates are exported inline, alongside data, within IPFIX Sets
identified by special Set IDs. In this way, an IPFIX Message stream
is self-describing with minimal overhead in situations where the
number of records is much greater than the number of record types.
This is a feature of the SIPCLF data model, and indicates the
applicability of IPFIX to SIPCLF logging.</t>
</section> -->
<!-- <section anchor="ipfix-limits" title="Encoding and Limits">
<t>Each Information Element specifies a data type, covering most
primitives (e.g. signed and unsigned integers, floats, booleans,
strings) as well as some network-specific types (addresses,
timestamps). All types other than strings and octet arrays are
stored in network byte order. Within a Template, an Information
Element may be specified to have a fixed length or a variable
length; if the latter, the field in the Record has a length prefix
of one or three bytes. One-byte prefixes represent lengths from 0 to
254; three byte prefixes are encoded as 255 followed by an
unsigned16 in network byte order and can represent lengths from 0 to
65535. Typically, strings are stored with variable length, so IPFIX
string fields can be thought of as length-prefixed (or "Pascal")
strings. Two advantages of this encoding are that each
variable-length field in IPFIX can be skipped with one or two
comparisons (depending on the length representation), and that the
framing itself is immune to misformatted strings (e.g., with
embedded NULs).</t>
<t>Although IPFIX variable length Information Elements can
represent single values up to 65535 bytes long, there is an
additional length limit imposed by the Message format itself. Each
Message has an unsigned 16-bit length in its header; this length
includes the length of the header itself as well as any set headers,
to facilitate easy framing and deframing of messages. Since the
header is 16 bytes, and the set header 4 bytes, the minimum
per-message overhead (a message with one set containing only one
record) is 20 bytes, leading to a record limit of 65515 bytes. A
record containing a single variable-length element with 3-byte
length encoding therefore has a content limit of 65512 bytes.</t>
<t>In the common case, this limit has no practical impact. Each
field within a SIPCLF message is normally limited to 4096 bytes as
described in <xref target="sec-ie"/>; 15 such full-length fields
will fit in an IPFIX Message. However, when using IPFIX to export
extended SIPCLF information, for example dumping full SIP body
content during debugging, care needs to be taken; this is discussed
further in <xref target="sec-64k"/>.</t>
</section> -->
</section>
<section anchor="sec-ie" title="Base Information Elements for SIP Message Information Export">
<!--
<t>[EDITOR'S NOTE: This description is not compliant with the
guidelines in draft-trammell-ipfix-ie-doctors-02, and should be made
so.]</t>
<t>[EDITOR'S NOTE: This section contains 2119 language, which it
SHOULD not.]</t>
<t>This section formally defines Information Elements for SIPCLF based
on the data model defined in <xref
target="I-D.ietf-sipclf-problem-statement"></xref>.</t>
<t>The IANA IPFIX Information Elements registry available at
http://www.iana.org/assignments/ipfix/ipfix.xhtml defines a number of
Information Elements useful in representing SIP Message information in
IPFIX. These concern traditional flow key and timing information, and
appear in the table below:</t>
<texttable>
<ttcol align="left">Name</ttcol>
<ttcol align="left">Number</ttcol>
<ttcol align="left"><Type>/Description</ttcol>
<c>observationTimeSeconds</c><c>322</c><c><dateTimeSeconds>
Timestamp of the request or response represented as the number of
seconds since the Unix epoch. Used when second-level precision is adequate.</c>
<c>observationTimeMilli- seconds</c><c>323</c>
<c><dateTimeMilliseconds> Timestamp of the request or response
represented as the number of milliseconds since the Unix epoch. Used
when millisecond-level precision is required.</c>
<c>sourceIPv4Address</c><c>8</c><c><ipv4Address>
The IPv4 address of the source of the SIP message</c>
<c>sourceIPv6Address</c><c>27</c><c><ipv6Address>
The IPv6 address of the source of the SIP message</c>
<c>sourceTransportPort</c><c>7</c><c><unsigned16>
The source port number of source of the SIP message</c>
<c>destinationIPv4Address</c><c>12</c><c><ipv4Address>
The IPv4 address of the destination of the SIP message</c>
<c>destinationIPv6Address</c><c>28</c><c><ipv6Address>
The IPv6 address of the destination of the SIP message</c>
<c>destinationTransportPort</c><c>11</c><c><unsigned16>
The destination port number for the SIP message</c>
<c>protocolIdentifier</c><c>4</c><c><unsigned8>
The type of transport for the SIP message (UDP vs. TCP vs. SCTP)</c>
</texttable>
<t>In addition, we define the following Information Elements to
represent the SIP-specific mandatory fields defined in <xref
target="I-D.ietf-sipclf-problem-statement"></xref>, many themselves
taken from <xref target="RFC3261"></xref>. As these are not yet
registered with IANA, but required to support experimental
implementation during the development of this representation, these
are provisionally located within the number space assigned to Private
Enterprise Number (PEN), here registered within the private enterprise
number 35566, which belongs to one of the authors of this draft. It is
intended that these Information Elements be registered within the IANA
number space on the publication of this draft.</t>
<texttable>
<ttcol align="left">Name</ttcol>
<ttcol align="left">PEN/Number</ttcol>
<ttcol align="left"><Type>/Description</ttcol>
<c>sipObservationType</c><c>35566/419</c><c><unsigned8> The
observation type of this log entry. Denotes whether the entry was
corresponds to a SIP message received, sent, or merely seen by a
passive observer, as per the sipObservationType subregistry defined
below.</c>
<c>sipMethod</c><c>35566/402</c><c><unsigned8>
The SIP method from the CSeq header, as per the sipMethod subregistry
defined below.</c>
<c>sipFromURI</c><c>35566/404</c><c><string>
The From URI</c>
<c>sipFromTag</c><c>35566/405</c><c><string>
The From header field tag parameter value</c>
<c>sipToURI</c><c>35566/406</c><c><string>
The To URI.</c>
<c>sipToTag</c><c>35566/407</c><c><string>
The To header field tag parameter value, if present</c>
<c>sipCallId</c><c>35566/408</c><c><string>
The Call-ID header field value</c>
<c>sipSequenceNumber</c><c>35566/409</c><c><unsigned32>
The sequence number from the CSeq header.</c>
<c>sipRequestURI</c><c>35566/403</c><c><string>
The Request URI, including any parameters.</c>
<c>sipResponseStatus</c><c>35566/412</c><c><unsigned16>
The SIP response code returned upstream. The presence of this
Information Element marks a record as describing a SIP response.</c>
<c>sipServerTransaction</c><c>35566/413</c><c><string>
The transaction identifier associated with the server transaction</c>
<c>sipClientTransaction</c><c>35566/414</c><c><string>
The transaction identifier associated with the server transaction</c>
</texttable>
<t>The sipObservationType IE encodes whether the device logging the
entry was the sender or received of the message. It can take the
following four values:</t>
<texttable>
<ttcol align="left">Number</ttcol>
<ttcol align="left">Name</ttcol>
<ttcol align="left">Description</ttcol>
<c>0</c><c>unknown</c><c>The logging process does not specify the observation type.</c>
<c>1</c><c>receiver</c><c>This entry was logged by the receiver of the message.</c>
<c>2</c><c>sender</c><c>This entry was logged by the sender of the message.</c>
<c>3</c><c>passive</c><c>This entry was logged by a passive observer of the message, e.g. a passive metering process parsing the SIP message from a sniffed packet stream.</c>
</texttable>
<t>The sipMethod IE encodes the supported methods from <xref
target="RFC3261"/> as integers, by the order in which they appear in
the IANA SIP Parameters Methods registry at
http://www.iana.org/assignments/sip-parameters:</t>
<t>[EDITOR'S NOTE: this needs to be reviewed. the list here is alphabetized, and its order may change. Open question: do we create a subregistry, keep this in the IE definition, or modify the SIP registry]</t>
<texttable>
<ttcol align="left">Number</ttcol>
<ttcol align="left">Method</ttcol>
<ttcol align="left">Notes</ttcol>
<c>0 </c><c>Unknown</c><c>The logging process did not recognize the SIP method.</c>
<c>1 </c><c>ACK </c><c>defined in RFC3261</c>
<c>2 </c><c>BYE </c><c>defined in RFC3261</c>
<c>3 </c><c>CANCEL </c><c>defined in RFC3261</c>
<c>4 </c><c>INFO </c><c>defined in RFC2976</c>
<c>5 </c><c>INVITE </c><c>defined in RFC3261</c>
<c>6 </c><c>MESSAGE </c><c>defined in RFC3428</c>
<c>7 </c><c>NOTIFY </c><c>defined in RFC3265</c>
<c>8 </c><c>OPTIONS </c><c>defined in RFC3261</c>
<c>9 </c><c>PRACK </c><c>defined in RFC3262</c>
<c>10</c><c>PUBLISH </c><c>defined in RFC3903</c>
<c>11</c><c>REFER </c><c>defined in RFC3515</c>
<c>12</c><c>REGISTER </c><c>defined in RFC3261</c>
<c>13</c><c>SUBSCRIBE</c><c>defined in RFC3265</c>
<c>14</c><c>UPDATE </c><c>defined in RFC3311</c>
</texttable>
-->
<t>The following Information Elements represent SIP-specific mandatory
fields defined in <xref
target="I-D.ietf-sipclf-problem-statement"></xref>, many themselves
taken from <xref target="RFC3261"></xref>. Together with Information
Elements already available in the IPFIX IANA Information Elements
registry, these can be used to export information about SIP
Messages.</t>
<section title="sipObservationType"><t><list style="hanging"><t hangText="Description: ">
Denotes whether the entry was
corresponds to a SIP message received, sent, or merely seen by a
passive observer, as follows:
<vspace/>0: unknown: The Metering Process does not specify the observation type.<vspace/>1: receiver: The Metering Process is, or is co-located with, the receiver of the SIP message.<vspace/>2: sender: The Metering Process is, or is co-located with, the sender of the SIP message.<vspace/>3: passive: The Metering Process passively observed the SIP message.<vspace/></t><t hangText="Data Type: ">unsigned8</t><t hangText="Data Type Semantics: ">identifier</t><t hangText="PEN (provisional): ">35566 (trammell.ch)</t><t hangText="ElementId (provisional): ">419</t></list></t></section>
<section title="sipMethod"><t><list style="hanging"><t hangText="Description: ">
The SIP method from the CSeq header, encoded as per the IPFIX sipMethod subregistry.
<vspace/></t><t hangText="Data Type: ">unsigned8</t><t hangText="Data Type Semantics: ">identifier</t><t hangText="PEN (provisional): ">35566 (trammell.ch)</t><t hangText="ElementId (provisional): ">402</t></list></t></section>
<section title="sipSequenceNumber"><t><list style="hanging"><t hangText="Description: ">The sequence number from the CSeq header.<vspace/></t><t hangText="Data Type: ">unsigned32</t><t hangText="Data Type Semantics: ">identifier</t><t hangText="PEN (provisional): ">35566 (trammell.ch)</t><t hangText="ElementId (provisional): ">409</t></list></t></section>
<section title="sipRequestURI"><t><list style="hanging"><t hangText="Description: ">The SIP Request URI, including any parameters, as a UTF-8 string, escaped according to SIP rules as received by the metering process.<vspace/></t><t hangText="Data Type: ">string</t><t hangText="PEN (provisional): ">35566 (trammell.ch)</t><t hangText="ElementId (provisional): ">403</t></list></t></section>
<section title="sipFromURI"><t><list style="hanging"><t hangText="Description: ">The URI from the SIP From: header<vspace/></t><t hangText="Data Type: ">string</t><t hangText="PEN (provisional): ">35566 (trammell.ch)</t><t hangText="ElementId (provisional): ">404</t></list></t></section>
<section title="sipFromTag"><t><list style="hanging"><t hangText="Description: ">The Tag parameter value from the SIP From: header<vspace/></t><t hangText="Data Type: ">string</t><t hangText="PEN (provisional): ">35566 (trammell.ch)</t><t hangText="ElementId (provisional): ">405</t></list></t></section>
<section title="sipToURI"><t><list style="hanging"><t hangText="Description: ">The URI from the SIP To: header<vspace/></t><t hangText="Data Type: ">string</t><t hangText="PEN (provisional): ">35566 (trammell.ch)</t><t hangText="ElementId (provisional): ">406</t></list></t></section>
<section title="sipToTag"><t><list style="hanging"><t hangText="Description: ">The Tag parameter value from the SIP To: header<vspace/></t><t hangText="Data Type: ">string</t><t hangText="PEN (provisional): ">35566 (trammell.ch)</t><t hangText="ElementId (provisional): ">407</t></list></t></section>
<section title="sipCallId"><t><list style="hanging"><t hangText="Description: ">The value of the SIP Call-ID: header<vspace/></t><t hangText="Data Type: ">string</t><t hangText="PEN (provisional): ">35566 (trammell.ch)</t><t hangText="ElementId (provisional): ">408</t></list></t></section>
<section title="sipResponseStatus"><t><list style="hanging"><t hangText="Description: ">The SIP Response code. The presence of this Information Element in a SIP Message record marks it as describing a SIP response; if absent, the record describes a SIP request.<vspace/></t><t hangText="Data Type: ">unsigned16</t><t hangText="Data Type Semantics: ">identifier</t><t hangText="PEN (provisional): ">35566 (trammell.ch)</t><t hangText="ElementId (provisional): ">412</t></list></t></section>
<section title="sipServerTransaction"><t><list style="hanging"><t hangText="Description: ">The transaction identifier associated with the server transaction.<vspace/></t><t hangText="Data Type: ">string</t><t hangText="Data Type Semantics: ">identifier</t><t hangText="PEN (provisional): ">35566 (trammell.ch)</t><t hangText="ElementId (provisional): ">413</t></list></t></section>
<section title="sipClientTransaction"><t><list style="hanging"><t hangText="Description: ">The transaction identifier associated with the client transaction.<vspace/></t><t hangText="Data Type: ">string</t><t hangText="Data Type Semantics: ">identifier</t><t hangText="PEN (provisional): ">35566 (trammell.ch)</t><t hangText="ElementId (provisional): ">414</t></list></t></section>
<section title="sipMethod subregistry" anchor="sec-sipmethod">
<t>The sipMethod subregistry assigns a number to encode each of the SIP methods encoded in the Methods and Response Codes registry at http://www.iana.org/assignments/sip-parameters in a 16-bit integer Information Element. These numbers are assigned from 1 in alphabetical order for the Methods defined as of the publication time of this document; subsequent Methods added to the Methods and Response Codes registry will be added to the IPFIX sipMethod subregistry at such time they are added to the Methods and Response Codes registry, using the lowest available unassigned number at the time of addition.</t>
<texttable>
<ttcol align="left">Number</ttcol>
<ttcol align="left">Method</ttcol>
<ttcol align="left">Reference</ttcol>
<c>0</c><c>Unknown</c><c/>
<c>1</c><c>ACK</c><c><xref target="RFC3261"/></c>
<c>2</c><c>BYE</c><c><xref target="RFC3261"/></c>
<c>3</c><c>CANCEL</c><c><xref target="RFC3261"/></c>
<c>4</c><c>INFO</c><c><xref target="RFC6086"/></c>
<c>5</c><c>INVITE</c><c><xref target="RFC3261"/></c>
<c>6</c><c>MESSAGE</c><c><xref target="RFC3428"/></c>
<c>7</c><c>NOTIFY</c><c><xref target="RFC3265"/></c>
<c>8</c><c>OPTIONS</c><c><xref target="RFC3261"/></c>
<c>9</c><c>PRACK</c><c><xref target="RFC3262"/></c>
<c>10</c><c>PUBLISH</c><c><xref target="RFC3903"/></c>
<c>11</c><c>REFER</c><c><xref target="RFC3515"/></c>
<c>12</c><c>REGISTER</c><c><xref target="RFC3261"/></c>
<c>13</c><c>SUBSCRIBE</c><c><xref target="RFC3265"/></c>
<c>14</c><c>UPDATE</c><c><xref target="RFC3311"/></c>
<c>15-65535</c><c>Unassigned</c><c/>
</texttable>
</section>
</section>
<section anchor="sec-moar-ie" title="Additional Information Elements for SIP Message Information Export">
<!--
<t>[EDITOR'S NOTE: As these do not appear in the core data model for SIP-CLF, we should provide somewhat more justification for these.]</t>
<t>The following Information Elements are defined to represent
additional SIP fields which were identified as potentially useful
by the SIPCLF working group.</t>
<texttable>
<ttcol align="left">Name</ttcol>
<ttcol align="left">PEN/Number</ttcol>
<ttcol align="left"><Type>/Description</ttcol>
<c>sipAuthUsername</c><c>35566/401</c><c><string>
The SIP user name by which the user has been authenticated</c>
<c>sipContactURI</c><c>35566/410</c><c><string>
The Contact URI, possibly multiple</c>
<c>sipPaiURI</c><c>35566/411</c><c><string>
The P-Asserted-Identity URI</c>
<c>sipSessionId</c><c>35566/415</c><c><octetArray>
A 128-bit session identifier, as in <xref target="I-D.kaplan-dispatch-session-id"/></c>
<c>sipMessageSection</c><c>35566/416</c><c><octetArray>
Section of a SIP body. If a sipMessageSectionOffset is present, this section begins that many octets into the SIP body; otherwise, the section begins with the start of the SIP body.
</c>
<c>sipMessageSectionOffset</c><c>35566/417</c><c><unsigned64>
Offset of the original SIP body, in octets, from which the
sipMessageSection in this record was taken.
</c>
<c>sipMessageLength</c><c>35566/418</c><c><unsigned64>
Total length of the SIP body.
</c>
</texttable>
<t>Any of the SIP-defined string Information Elements MAY be truncated
by the logging process to support SIPCLF limits; if truncation is
supported, the limits SHOULD be user-configurable, and the maximum
limit SHOULD be 4096 bytes per field.</t>
<t>Bringing this all together, the additional Information Elements
specified for the SIPCLF data model, in <xref
target="I-D.trammell-ipfix-ie-doctors">textual IE specification
format</xref> is as follows; IE numbers appear in parentheses, IPFIX
types in angle brackets, and sizes ("v" for variable-length) in square
brackets:</t>
<figure title="Information Model" anchor="sipclf-fim">
<artwork><![CDATA[
sipAuthUsername(35566/401)<string>[v]
sipMethod(35566/402)<unsigned8>[1]
sipRequestURI(35566/403)<string>[v]
sipFromURI(35566/404)<string>[v]
sipFromTag(35566/405)<string>[v]
sipToURI(35566/406)<string>[v]
sipToTag(35566/407)<string>[v]
sipCallId(35566/408)<string>[v]
sipSequenceNumber(35566/409)<unsigned32>[4]
sipContactURI(35566/410)<string>[v]
sipPaiURI(35566/411)<string>[v]
sipResponseStatus(35566/412)<unsigned16>[2]
sipServerTransaction(35566/413)<string>[v]
sipClientTransaction(35566/414)<string>[v]
sipSessionId(35566/415)<octetArray>[16]
sipMessageSection(35566/416)<octetArray>[v]
sipMessageSectionOffset(35566/417)<unsigned64>[8]
sipMessageLength(35566/418)<unsigned64>[8]
sipObservationType(35566/419)<unsigned8>[8]
]]></artwork>
</figure>
-->
<t>[TODO frontmatter]</t>
<!-- begin xml generated from hadriel-ies.xml -->
<section title="sipContactURI"><t><list style="hanging"><t hangText="Description: ">The addr-spec URI, including any URI parameters,
of the first/top-most SIP Contact header,
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.<vspace/></t><t hangText="Data Type: ">string</t><t hangText="Data Type Semantics: "/><t hangText="PEN (provisional): ">35566</t><t hangText="ElementId (provisional): ">415</t></list></t></section>
<section title="sipRouteURI"><t><list style="hanging"><t hangText="Description: ">The addr-spec URI, including any URI parameters,
of the first/top-most SIP Route header,
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.<vspace/></t><t hangText="Data Type: ">string</t><t hangText="Data Type Semantics: "/><t hangText="PEN (provisional): ">35566</t><t hangText="ElementId (provisional): ">416</t></list></t></section>
<section title="sipPaiURI"><t><list style="hanging"><t hangText="Description: ">The addr-spec URI, including any URI parameters,
of the first/top-most SIP P-Asserted-Identity header,
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.<vspace/></t><t hangText="Data Type: ">string</t><t hangText="Data Type Semantics: "/><t hangText="PEN (provisional): ">35566</t><t hangText="ElementId (provisional): ">417</t></list></t></section>
<section title="sipPpiURI"><t><list style="hanging"><t hangText="Description: ">The addr-spec URI, including any URI parameters,
of the first/top-most SIP P-Preferred-Identity header,
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.<vspace/></t><t hangText="Data Type: ">string</t><t hangText="Data Type Semantics: "/><t hangText="PEN (provisional): ">35566</t><t hangText="ElementId (provisional): ">418</t></list></t></section>
<section title="sipPAssocURI"><t><list style="hanging"><t hangText="Description: ">The addr-spec URI, including any URI parameters,
of the first/top-most SIP P-Associated-Identity header,
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.<vspace/></t><t hangText="Data Type: ">string</t><t hangText="Data Type Semantics: "/><t hangText="PEN (provisional): ">35566</t><t hangText="ElementId (provisional): ">430</t></list></t></section>
<section title="sipPCalledPartyURI"><t><list style="hanging"><t hangText="Description: ">The addr-spec URI, including any URI parameters,
of the SIP P-Called-Party-ID header,
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.<vspace/></t><t hangText="Data Type: ">string</t><t hangText="Data Type Semantics: "/><t hangText="PEN (provisional): ">35566</t><t hangText="ElementId (provisional): ">420</t></list></t></section>
<section title="sipVia"><t><list style="hanging"><t hangText="Description: ">The value of the first/top-most Via header
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.<vspace/></t><t hangText="Data Type: ">string</t><t hangText="Data Type Semantics: "/><t hangText="PEN (provisional): ">35566</t><t hangText="ElementId (provisional): ">421</t></list></t></section>
<section title="sipAuthUsername"><t><list style="hanging"><t hangText="Description: ">The value of the username field
of the first/top-most Authorization header
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.<vspace/></t><t hangText="Data Type: ">string</t><t hangText="Data Type Semantics: "/><t hangText="PEN (provisional): ">35566</t><t hangText="ElementId (provisional): ">422</t></list></t></section>
<section title="sipSubscriptionEvent"><t><list style="hanging"><t hangText="Description: ">The value of the Event header
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.<vspace/></t><t hangText="Data Type: ">string</t><t hangText="Data Type Semantics: "/><t hangText="PEN (provisional): ">35566</t><t hangText="ElementId (provisional): ">423</t></list></t></section>
<section title="sipSubscriptionState"><t><list style="hanging"><t hangText="Description: ">The value of the Subscription-State header
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.<vspace/></t><t hangText="Data Type: ">string</t><t hangText="Data Type Semantics: "/><t hangText="PEN (provisional): ">35566</t><t hangText="ElementId (provisional): ">424</t></list></t></section>
<section title="sipExpires"><t><list style="hanging"><t hangText="Description: ">The numeric value of the expires parameter of the
first/top-most Contact header of a REGISTER request
or response, or Subscription-State header of a SUBSCRIBE
or NOTIFY request or response, or the Expires header
if the expires parameter does not exist, as
received by the metering process.<vspace/></t><t hangText="Data Type: ">unsigned32</t><t hangText="Data Type Semantics: "/><t hangText="PEN (provisional): ">35566</t><t hangText="ElementId (provisional): ">425</t></list></t></section>
<section title="sipPVisitedNetworkID"><t><list style="hanging"><t hangText="Description: ">The value of the first/top-most P-Visited-Network-ID header
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.<vspace/></t><t hangText="Data Type: ">string</t><t hangText="Data Type Semantics: "/><t hangText="PEN (provisional): ">35566</t><t hangText="ElementId (provisional): ">426</t></list></t></section>
<section title="sipPAccessNetworkInfo"><t><list style="hanging"><t hangText="Description: ">The value of the P-Access-Network-Info header
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.<vspace/></t><t hangText="Data Type: ">string</t><t hangText="Data Type Semantics: "/><t hangText="PEN (provisional): ">35566</t><t hangText="ElementId (provisional): ">427</t></list></t></section>
<section title="sipPChargingFunctionAddr"><t><list style="hanging"><t hangText="Description: ">The value of the first/top-most
P-Charging-Function-Addresses header
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.<vspace/></t><t hangText="Data Type: ">string</t><t hangText="Data Type Semantics: "/><t hangText="PEN (provisional): ">35566</t><t hangText="ElementId (provisional): ">428</t></list></t></section>
<section title="sipPChargingVector"><t><list style="hanging"><t hangText="Description: ">The value of the P-Charging-Vector header
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.<vspace/></t><t hangText="Data Type: ">string</t><t hangText="Data Type Semantics: "/><t hangText="PEN (provisional): ">35566</t><t hangText="ElementId (provisional): ">429</t></list></t></section>
<!-- end xml generated from hadriel-ies.xml -->
</section>
<section anchor="sec-templates" title="Recommended Templates for SIP Message Information Export">
<t>The SIPCLF data model represents SIP requests and SIP responses
with separate records. The following Templates are defined as
recommended base Templates for records describing requests and
responses. Optional Information Elements MAY be added to them, and the
IPv4 addresses within these Templates MUST be replaced with IPv6
addresses for logging IPv6 transport of SIP messages. A
sipServerTransaction Information Element SHOULD be added for all
messages logged by a User Agent Server, and a sipClientTransaction
Information Element SHOULD be added for all messages logged by a User
Agent Client. These templates follow the recommended fields for
request and response logging in <xref
target="I-D.ietf-sipclf-problem-statement"></xref>, and are defined
using the representation in section 9 of <xref
target="I-D.trammell-ipfix-ie-doctors"/>.</t>
<figure title="Base Request Template (IPv4)" anchor="sipclf-reqtmpl-v4">
<artwork><![CDATA[
observationTimeMilliseconds(323)[8]
sipSequenceNumber(35566/409)[4]
sourceIPv4Address(8)[4]
destinationIPv4Address(12)[4]
sourceTransportPort(7)[2]
destinationTransportPort(11)[2]
protocolIdentifier(4)[1]
sipMethod(35566/402)[1]
sipObservationType(35566/419)[1]
sipRequestURI(35566/403)[v]
sipToURI(35566/406)[v]
sipToTag(35566/407)[v]
sipFromURI(35566/404)[v]
sipFromTag(35566/405)[v]
sipCallId(35566/408)[v]
]]></artwork>
</figure>
<figure title="Base Response Template (IPv4)" anchor="sipclf-resptmpl-v4">
<artwork><![CDATA[
observationTimeMilliseconds(323)[8]
sipSequenceNumber(35566/409)[4]
sourceIPv4Address(8)[4]
destinationIPv4Address(12)[4]
sourceTransportPort(7)[2]
destinationTransportPort(11)[2]
protocolIdentifier(4)[1]
sipMethod(35566/402)[1]
sipObservationType(35566/419)[1]
sipResponseStatus(35566/412)[2]
sipToURI(35566/406)[v]
sipToTag(35566/407)[v]
sipFromURI(35566/404)[v]
sipFromTag(35566/405)[v]
sipCallId(35566/408)[v]
]]></artwork>
</figure>
<t>Note that the Information Elements in these templates are ordered to
place the fixed-length elements before the variable-length ones, which
speeds random access to fixed-length elements. However, since element
order within a record is unimportant in IPFIX, any ordering of the
mandatory Information Elements within a record MUST be accepted by a
Collecting Process as a valid SIP request or response record for that
record type.</t>
<t>The record type is determined by the presence of the
sipResponseStatus field. If present in the Template, the Template
describes a response record. If absent, it describes a request
record.</t>
</section>
<!-- <section anchor="sec-fileformat" title="IPFIX File Format for SIPCLF">
<t>Now that we have defined Information Elements to support the SIPCLF
Data Model and recommended Templates to define the records, we combine
this data model to the IPFIX File format to define the SIPCLF format
over IPFIX.</t>
<t>The IPFIX File format is defined in <xref target="RFC5655"/> as a
serialized set of IPFIX Messages containing Data Records organized in
Sets defined by Templates; these are in turn defined in <xref
target="RFC5101">the IPFIX Protocol specification</xref>. The file
format is designed to facilitate interoperability, flexibility, and
reusability among a wide variety of storage, processing, and analysis
tools.</t>
<t>A SIPCLF-IPFIX file is then defined as an IPFIX File as in <xref
target="RFC5655"/> containing Templates containing at least the
Information Elements defined in the recommended Templates above,
followed by Data Sets containing records defined by those Templates.</t>
<t>The Template mechanism provided by IPFIX allows some flexibility
here. A SIPCLF-IPFIX file writer MAY include other Information Elements
in the Templates it uses for SIP logging (for example, to add additional
information such as in the list of optional Information Elements,
above), and MAY include Templates and records described by them which do
not contain SIPCLF information; these latter records MAY be ignored by
SIPCLF file readers.</t>
<t>Some specific considerations for SIPCLF-IPFIX files are detailed in
the subsections below.</t>
<section anchor="sec-64k" title="Logging Raw SIP Messages">
<t>As noted in <xref target="ipfix-limits"/>, the IPFIX Message
format places a practical limit of 65515 bytes of content per
Message. The base templates are structured so that this limit has no
practical effect. However, SIPCLF Information Elements defined in
this document MAY also be used to dump raw header and body
information, and these may be longer than 65515 bytes. There are two
ways to address this.</t>
<t>First, as with all other elements, the raw message can be
truncated. This specification provides the sipMessageSection and
sipMessageLength Information Elements to represent this. Here, the
first N bytes of the message would be exported in the
variable-length sipMessageSection Information Element, and the total
length of the SIP body in the sipMessageLength Information Element.
A template for requests received at a UAS is shown in <xref
target="sipclf-body-base"/>.</t>
<figure title="Template for Request Record with Partial Raw Message at UAS" anchor="sipclf-body-base">
<artwork><![CDATA[
observationTimeMilliseconds(323)[8]
sipSequenceNumber(35566/409)[4]
sipMessageLength(35566/418)[4]
sourceIPv4Address(8)[4]
destinationIPv4Address(12)[4]
sourceTransportPort(7)[2]
destinationTransportPort(11)[2]
protocolIdentifier(4)[1]
sipMethod(35566/402)[1]
sipObservationType(35566/419)[1]
sipRequestURI(35566/403)[v]
sipToURI(35566/406)[v]
sipToTag(35566/407)[v]
sipFromURI(35566/404)[v]
sipFromTag(35566/405)[v]
sipCallId(35566/408)[v]
sipServerTransaction(35566/413)[v]
sipMessageSection(35566/416)[v]
]]></artwork>
</figure>
<t>For exporting large raw SIP messages, a second continuation template
is necessary, as in figure <xref target="sipclf-body-cont"/>. In this
case, a record containing the first 64k (minus the length of the other
fields) is exported using a template similar to the partial body
template above. Then additional sections of the SIP body at subsequent
specified offsets into the SIP body are exported in continuation records
in subsequent messages. The SIP message whose body is continued is
uniquely identified by the 5-tuple flow key and the observation time.
This template allows the export of up to 65487 bytes of raw SIP message
per IPFIX message (65515 message payload - 25 fixed fields - 3
sipMessageSection length).</t>
<figure title="Template for Message Continuation" anchor="sipclf-body-cont">
<artwork><![CDATA[
observationTimeMilliseconds(323)[8]
sipMessageSectionOffset(35566/417)[4]
sourceIPv4Address(8)[4]
destinationIPv4Address(12)[4]
sourceTransportPort(7)[2]
destinationTransportPort(11)[2]
protocolIdentifier(4)[1]
sipMessageSection(35566/416)[v]
]]></artwork>
</figure>
</section>
<section title="Supporting fast searches of SIPCLF log files" anchor="sec-fastseek">
<t>The order of fields in an IPFIX data record is semantically
unimportant, since the Template defines where each field in the record
is. However, note that in all the Templates defined to this point, we
have placed fixed-length fields before variable length fields. While
logging processes are free to place the Information Elements in the
Templates they export in any order, they SHOULD place fixed-length
Information Elements before variable-length Information Elements. This
increases the efficiency of both Message export and decoding, since
each fixed length field as well as the first variable-length field
have fixed offsets into the Message.</t>
<t>Random access to a field within a record (i.e., for comparison
purposes during a sequential scan) is therefore constant-time for
fixed-length fields, and requires one or two comparisons per
subsequent field for variable-length fields.</t>
<t>However, since Sets encode the length of the Set, not of the
records therein, and each Set may contain multiple records, a Set
containing records with variable-length fields must be sequentially
searched in order to find the beginning of the next Message. This
situation MAY be improved by exporting only one Record per Set: in
this case, the Set length equals the Record length minus the constant
Set header length (4), reducing the number of comparisons needed for
skipping records.</t>
</section>
</section>
-->
<section anchor="sec-example" title="Examples">
<t>This section presents several views of an example SIP messages
exported using the IPFIX templates described in this document. We
present both binary and textual forms. The tools to generate this
section are based upon the open-source <xref
target="ripfix">ripfix</xref> implementation of IPFIX, maintained by
one of the authors of this draft.</t>
<t>Here we show the IPFIX Messages generated by the situations in
sections 9.1 through 9.4 of <xref
target="I-D.ietf-sipclf-problem-statement"></xref>.</t>
<section anchor="sec-example-template" title="Base Template Export">
<t>Before exporting any Request or Response records, the Templates describing them must be exported. In this example, the templates These
Templates are derived from the base Templates as shown in <xref
target="sipclf-reqtmpl-v4"/> and <xref
target="sipclf-resptmpl-v4"/>, with the sipClientTransaction and
sipServerTransaction Information Elements appended. We use two
templates here, one each for request and response for IPv4.</t>
<t>Exporting these Templates results in the following IPFIX message,
illustrated as an annotated hexdump in <xref target="ex-template-hex"/>.</t>
<figure title="Base template message export" anchor="ex-template-hex">
<artwork><![CDATA[
0000: 00 0a 00 fc 4c c0 2a a2 00 00 00 00 00 00 30 39 ....L.*.......09
[ IPFIX message header, length 252 ]
0010: 00 02 00 ec ....
[ Template set (ID 2) header, length 236 ]
0014: 01 01 00 11 01 43 00 08 81 99 00 04 .....C......
0020: 00 00 8a ee 00 08 00 04 00 0c 00 04 00 07 00 02 ................
0030: 00 0b 00 02 00 04 00 01 81 92 00 01 00 00 8a ee ................
0040: 81 a3 00 01 00 00 8a ee 81 93 ff ff 00 00 8a ee ................
0050: 81 96 ff ff 00 00 8a ee 81 97 ff ff 00 00 8a ee ................
0060: 81 94 ff ff 00 00 8a ee 81 95 ff ff 00 00 8a ee ................
0070: 81 98 ff ff 00 00 8a ee 81 9e ff ff 00 00 8a ee ................
0080: 81 9d ff ff 00 00 8a ee ........
[ Template 257, 17 elements (v4 request) ]
0088: 01 02 00 11 01 43 00 08 .....C..
0090: 81 99 00 04 00 00 8a ee 00 08 00 04 00 0c 00 04 ................
00a0: 00 07 00 02 00 0b 00 02 00 04 00 01 81 92 00 01 ................
00b0: 00 00 8a ee 81 a3 00 01 00 00 8a ee 81 9c 00 02 ................
00c0: 00 00 8a ee 81 96 ff ff 00 00 8a ee 81 97 ff ff ................
00d0: 00 00 8a ee 81 94 ff ff 00 00 8a ee 81 95 ff ff ................
00e0: 00 00 8a ee 81 98 ff ff 00 00 8a ee 81 9e ff ff ................
00f0: 00 00 8a ee 81 9d ff ff 00 00 8a ee ............
[ Template 258, 17 elements (v4 response) ]
]]></artwork>
</figure>
</section>
<section anchor="sec-example-uacreg" title="UAC registration">
<t>Having exported templates, now we create a simple IPFIX Message
representing a UAC registration as seen from the UAC,
corresponding to example 9.1 in <xref
target="I-D.ietf-sipclf-problem-statement"></xref>. This message
contains two records, including the UAS registration request, and
the response received. This is shown in the annotated hexdump in
<xref target="ex-uacreg-hex"/>.</t>
<figure title="Message containing two log entries for UAC registration" anchor="ex-uacreg-hex">
<artwork><![CDATA[
0000: 00 0a 00 d8 4c 90 7f c1 00 00 00 00 00 00 30 39 ....L.........09
[ IPFIX message header, length 218 ]
0010: 01 01 00 6b ...k
[ Data set (ID 257) header, length 107 ]
0014: 00 00 01 29 13 66 13 93 00 00 00 01 ...).f......
0020: c6 33 64 01 c6 33 64 0a 13 c4 13 c4 11 0c 02 0f .3d..3d.........
0030: 73 69 70 3a 65 78 61 6d 70 6c 65 2e 63 6f 6d 00 sip:example.com.
0040: 00 15 73 69 70 3a 61 6c 69 63 65 40 65 78 61 6d ..sip:alice@exam
0050: 70 6c 65 2e 63 6f 6d 05 37 36 79 68 68 15 66 38 ple.com.76yhh.f8
0060: 31 2d 64 34 2d 66 36 40 65 78 61 6d 70 6c 65 2e 1-d4-f6@example.
0070: 63 6f 6d 06 63 2d 74 72 2d 31 00 com.c-tr-1.
[ Request record content ]
007b: 01 02 00 5d ...]
[ Data set (ID 258) header, length 93 ]
007f: 00 .
0080: 00 01 29 13 66 15 24 00 00 00 01 c6 33 64 0a c6 ..).f.$.....3d..
0090: 33 64 01 13 c4 13 c4 11 0c 01 00 c8 00 00 15 73 3d.............s
00a0: 69 70 3a 61 6c 69 63 65 40 65 78 61 6d 70 6c 65 ip:alice@example
00b0: 2e 63 6f 6d 05 37 36 79 68 68 15 66 38 31 2d 64 .com.76yhh.f81-d
00c0: 34 2d 66 36 40 65 78 61 6d 70 6c 65 2e 63 6f 6d 4-f6@example.com
00d0: 06 63 2d 74 72 2d 31 00 .c-tr-1.
[ Response record content ]
]]></artwork>
</figure>
<t>While this demonstrates the binary nature of the SIPCLF-IPFIX
format, and shows the content framing for this message, it is not
readable for illustration purposes. In <xref
target="ex-uacreg-rfd"/>, we run the message through the ripcollect
tool provided with ripfix to provide a more human-readable view.
Note that the sipMethod and sipObservationType are encoded according
to the registries in <xref target="sec-ie"/>.</t>
<figure title="Message containing two log entries for UAC registration" anchor="ex-uacreg-rfd">
<artwork><![CDATA[
==== message sequence 0 in domain 12345 at 2010-08-11 11:53:27 UTC ====
---- record 12345/257 ----
observationTimeMilliseconds => 2010-06-07 17:12:23 UTC
sipSequenceNumber => 1
sourceIPv4Address => 198.51.100.1
destinationIPv4Address => 198.51.100.10
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 12
sipObservationType => 2
sipRequestURI => sip:example.com
sipToURI =>
sipToTag =>
sipFromURI => sip:alice@example.com
sipFromTag => 76yhh
sipCallId => f81-d4-f6@example.com
sipClientTransaction => c-tr-1
sipServerTransaction =>
---- record 12345/258 ----
observationTimeMilliseconds => 2010-06-07 17:12:24 UTC
sipSequenceNumber => 1
sourceIPv4Address => 198.51.100.10
destinationIPv4Address => 198.51.100.1
sourceTransportPort => 5060
destinationTransportPort => 5060
sipResponseStatus => 200
protocolIdentifier => 17
sipMethod => 12
sipObservationType => 1
sipToURI =>
sipToTag =>
sipFromURI => sip:alice@example.com
sipFromTag => 76yhh
sipCallId => f81-d4-f6@example.com
sipClientTransaction => c-tr-1
sipServerTransaction =>
]]></artwork>
</figure>
</section>
<section anchor="sec-example-direct" title="Direct Call">
<t>This example demonstrates the export of a direct call from Alice
to Bob, as seen by Bob's agent, corresponding to example 9.2 in
<xref target="I-D.ietf-sipclf-problem-statement"></xref>. Here we
have four records: an INVITE received from Alice, a 180 Ringing sent
back followed by a 200 OK, and an ACK received from Alice. This is
shown in the ripfix dump in <xref target="ex-direct-ripfix"/> and
the hexdump in <xref target="ex-direct-hex"/>. In the hexdump,
message headers, set headers, and data records are separated by '|'
characters for compactness. Note here that each record has its own
data set to support high-speed seeking to a specific record, even
when two messages using the same template are adjacent in the
message.</t>
<figure title="Message containing four records for a simple call (ripfix dump)" anchor="ex-direct-ripfix">
<artwork><![CDATA[
===== message 12345/0 @2010-10-21 13:11:43 UTC (#2) =====
--- record 12345/257 (#1)---
observationTimeMilliseconds => 2010-06-07 17:12:23 UTC
sipSequenceNumber => 32
sourceIPv4Address => 198.51.100.1
destinationIPv4Address => 203.0.113.1
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 5
sipObservationType => 2
sipRequestURI => sip:bob@bob1.example.net
sipToURI => sip:bob@example.net
sipToTag =>
sipFromURI => sip:alice@example.com
sipFromTag => 76yhh
sipCallId => f82-d4-f7@example.com
sipClientTransaction => c-1-xt6
sipServerTransaction =>
--- record 12345/258 (#2)---
observationTimeMilliseconds => 2010-06-07 17:12:25 UTC
sipSequenceNumber => 32
sourceIPv4Address => 203.0.113.1
destinationIPv4Address => 198.51.100.1
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 5
sipObservationType => 1
sipResponseStatus => 180
sipToURI => sip:bob@example.net
sipToTag => b-in6-iu
sipFromURI => sip:alice@example.com
sipFromTag => 76yhh
sipCallId => f82-d4-f7@example.com
sipClientTransaction => c-1-xt6
sipServerTransaction =>
--- record 12345/258 (#3)---
observationTimeMilliseconds => 2010-06-07 17:12:26 UTC
sipSequenceNumber => 32
sourceIPv4Address => 203.0.113.1
destinationIPv4Address => 198.51.100.1
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 5
sipObservationType => 1
sipResponseStatus => 200
sipToURI => sip:bob@example.net
sipToTag => b-in6-iu
sipFromURI => sip:alice@example.com
sipFromTag => 76yhh
sipCallId => f82-d4-f7@example.com
sipClientTransaction => c-1-xt6
sipServerTransaction =>
--- record 12345/257 (#4)---
observationTimeMilliseconds => 2010-06-07 17:12:26 UTC
sipSequenceNumber => 32
sourceIPv4Address => 198.51.100.1
destinationIPv4Address => 203.0.113.1
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 1
sipObservationType => 2
sipRequestURI => sip:bob@bob1.example.net
sipToURI => sip:bob@example.net
sipToTag => b-in6-iu
sipFromURI => sip:alice@example.com
sipFromTag => 76yhh
sipCallId => f82-d4-f7@example.com
sipClientTransaction => c-1-xt6
sipServerTransaction =>
]]></artwork>
</figure>
<figure title="Message containing four records for a simple call (hexdump)" anchor="ex-direct-hex">
<artwork><![CDATA[
0000: 00 0a 02 1a 4c c0 2c b3 00 00 00 00 00 00 30 39| ....L.,.......09
0010: 01 01 00 88|00 00 01 29 13 66 13 93 00 00 00 20 .......).f.....
0020: c6 33 64 01 cb 00 71 01 13 c4 13 c4 11 05 02 18 .3d...q.........
0030: 73 69 70 3a 62 6f 62 40 62 6f 62 31 2e 65 78 61 sip:bob@bob1.exa
0040: 6d 70 6c 65 2e 6e 65 74 13 73 69 70 3a 62 6f 62 mple.net.sip:bob
0050: 40 65 78 61 6d 70 6c 65 2e 6e 65 74 00 15 73 69 @example.net..si
0060: 70 3a 61 6c 69 63 65 40 65 78 61 6d 70 6c 65 2e p:alice@example.
0070: 63 6f 6d 05 37 36 79 68 68 15 66 38 32 2d 64 34 com.76yhh.f82-d4
0080: 2d 66 37 40 65 78 61 6d 70 6c 65 2e 63 6f 6d 07 -f7@example.com.
0090: 63 2d 31 2d 78 74 36 00|01 02 00 79|00 00 01 29 c-1-xt6....y...)
00a0: 13 66 18 aa 00 00 00 20 cb 00 71 01 c6 33 64 01 .f..... ..q..3d.
00b0: 13 c4 13 c4 11 05 01 00 b4 13 73 69 70 3a 62 6f ..........sip:bo
00c0: 62 40 65 78 61 6d 70 6c 65 2e 6e 65 74 08 62 2d b@example.net.b-
00d0: 69 6e 36 2d 69 75 15 73 69 70 3a 61 6c 69 63 65 in6-iu.sip:alice
00e0: 40 65 78 61 6d 70 6c 65 2e 63 6f 6d 05 37 36 79 @example.com.76y
00f0: 68 68 15 66 38 32 2d 64 34 2d 66 37 40 65 78 61 hh.f82-d4-f7@exa
0100: 6d 70 6c 65 2e 63 6f 6d 07 63 2d 31 2d 78 74 36 mple.com.c-1-xt6
0110: 00|01 02 00 79|00 00 01 29 13 66 1c f4 00 00 00 ....y...).f.....
0120: 20 cb 00 71 01 c6 33 64 01 13 c4 13 c4 11 05 01 ..q..3d........
0130: 00 c8 13 73 69 70 3a 62 6f 62 40 65 78 61 6d 70 ...sip:bob@examp
0140: 6c 65 2e 6e 65 74 08 62 2d 69 6e 36 2d 69 75 15 le.net.b-in6-iu.
0150: 73 69 70 3a 61 6c 69 63 65 40 65 78 61 6d 70 6c sip:alice@exampl
0160: 65 2e 63 6f 6d 05 37 36 79 68 68 15 66 38 32 2d e.com.76yhh.f82-
0170: 64 34 2d 66 37 40 65 78 61 6d 70 6c 65 2e 63 6f d4-f7@example.co
0180: 6d 07 63 2d 31 2d 78 74 36 00|01 01 00 90|00 00 m.c-1-xt6.......
0190: 01 29 13 66 1d 08 00 00 00 20 c6 33 64 01 cb 00 .).f..... .3d...
01a0: 71 01 13 c4 13 c4 11 01 02 18 73 69 70 3a 62 6f q.........sip:bo
01b0: 62 40 62 6f 62 31 2e 65 78 61 6d 70 6c 65 2e 6e b@bob1.example.n
01c0: 65 74 13 73 69 70 3a 62 6f 62 40 65 78 61 6d 70 et.sip:bob@examp
01d0: 6c 65 2e 6e 65 74 08 62 2d 69 6e 36 2d 69 75 15 le.net.b-in6-iu.
01e0: 73 69 70 3a 61 6c 69 63 65 40 65 78 61 6d 70 6c sip:alice@exampl
01f0: 65 2e 63 6f 6d 05 37 36 79 68 68 15 66 38 32 2d e.com.76yhh.f82-
0200: 64 34 2d 66 37 40 65 78 61 6d 70 6c 65 2e 63 6f d4-f7@example.co
0210: 6d 07 63 2d 31 2d 78 74 36 00 m.c-1-xt6.
]]></artwork>
</figure>
</section>
<section anchor="sec-example-branch" title="Single Downstream Branch
Call">
<t>The example in <xref target="ex-branch-ripfix"/>and <xref
target="ex-branch-hex"/> demonstrates the export of a call with a
downstream branch to Bob, as seen by the proxy which the call
traverses, corresponding to example 9.3 in <xref
target="I-D.ietf-sipclf-problem-statement"></xref>. See this example
in the problem statement for more details.</t>
<figure title="Message containing ten records for a downstream branch call (ripfix dump)" anchor="ex-branch-ripfix">
<artwork><![CDATA[
===== message 12345/0 @2010-10-21 13:12:42 UTC (#2) =====
--- record 12345/257 (#1)---
observationTimeMilliseconds => 2010-06-07 17:12:23 UTC
sipSequenceNumber => 43
sourceIPv4Address => 198.51.100.1
destinationIPv4Address => 198.51.100.10
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 5
sipObservationType => 1
sipRequestURI => sip:bob@example.net
sipToURI => sip:bob@example.net
sipToTag =>
sipFromURI => sip:alice@example.com
sipFromTag => al-1
sipCallId => tr-87h@example.com
sipClientTransaction =>
sipServerTransaction => s-x-tr
--- record 12345/258 (#2)---
observationTimeMilliseconds => 2010-06-07 17:12:24 UTC
sipSequenceNumber => 43
sourceIPv4Address => 198.51.100.10
destinationIPv4Address => 198.51.100.1
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 5
sipObservationType => 2
sipResponseStatus => 100
sipToURI => sip:bob@example.net
sipToTag =>
sipFromURI => sip:alice@example.com
sipFromTag => al-1
sipCallId => tr-87h@example.com
sipClientTransaction =>
sipServerTransaction => s-x-tr
--- record 12345/257 (#3)---
observationTimeMilliseconds => 2010-06-07 17:12:24 UTC
sipSequenceNumber => 43
sourceIPv4Address => 198.51.100.10
destinationIPv4Address => 203.0.113.1
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 5
sipObservationType => 2
sipRequestURI => sip:bob@bob1.example.net
sipToURI => sip:bob@example.net
sipToTag =>
sipFromURI => sip:alice@example.com
sipFromTag => al-1
sipCallId => tr-87h@example.com
sipClientTransaction => c-x-tr
sipServerTransaction => s-x-tr
--- record 12345/258 (#4)---
observationTimeMilliseconds => 2010-06-07 17:12:25 UTC
sipSequenceNumber => 43
sourceIPv4Address => 203.0.113.1
destinationIPv4Address => 198.51.100.10
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 5
sipObservationType => 1
sipResponseStatus => 100
sipToURI => sip:bob@example.net
sipToTag => b1-1
sipFromURI => sip:alice@example.com
sipFromTag => al-1
sipCallId => tr-87h@example.com
sipClientTransaction => c-x-tr
sipServerTransaction => s-x-tr
--- record 12345/258 (#5)---
observationTimeMilliseconds => 2010-06-07 17:12:25 UTC
sipSequenceNumber => 43
sourceIPv4Address => 203.0.113.1
destinationIPv4Address => 198.51.100.10
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 5
sipObservationType => 1
sipResponseStatus => 180
sipToURI => sip:bob@example.net
sipToTag => b1-1
sipFromURI => sip:alice@example.com
sipFromTag => al-1
sipCallId => tr-87h@example.com
sipClientTransaction => c-x-tr
sipServerTransaction => s-x-tr
--- record 12345/258 (#6)---
observationTimeMilliseconds => 2010-06-07 17:12:26 UTC
sipSequenceNumber => 43
sourceIPv4Address => 198.51.100.10
destinationIPv4Address => 198.51.100.1
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 5
sipObservationType => 2
sipResponseStatus => 180
sipToURI => sip:bob@example.net
sipToTag => b1-1
sipFromURI => sip:alice@example.com
sipFromTag => al-1
sipCallId => tr-87h@example.com
sipClientTransaction => c-x-tr
sipServerTransaction => s-x-tr
--- record 12345/258 (#7)---
observationTimeMilliseconds => 2010-06-07 17:12:27 UTC
sipSequenceNumber => 43
sourceIPv4Address => 203.0.113.1
destinationIPv4Address => 198.51.100.10
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 5
sipObservationType => 1
sipResponseStatus => 200
sipToURI => sip:bob@example.net
sipToTag => b1-1
sipFromURI => sip:alice@example.com
sipFromTag => al-1
sipCallId => tr-87h@example.com
sipClientTransaction => c-x-tr
sipServerTransaction => s-x-tr
--- record 12345/258 (#8)---
observationTimeMilliseconds => 2010-06-07 17:12:27 UTC
sipSequenceNumber => 43
sourceIPv4Address => 198.51.100.10
destinationIPv4Address => 198.51.100.1
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 5
sipObservationType => 2
sipResponseStatus => 200
sipToURI => sip:bob@example.net
sipToTag => b1-1
sipFromURI => sip:alice@example.com
sipFromTag => al-1
sipCallId => tr-87h@example.com
sipClientTransaction => c-x-tr
sipServerTransaction => s-x-tr
--- record 12345/257 (#9)---
observationTimeMilliseconds => 2010-06-07 17:12:29 UTC
sipSequenceNumber => 43
sourceIPv4Address => 198.51.100.1
destinationIPv4Address => 198.51.100.10
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 1
sipObservationType => 1
sipRequestURI => sip:bob@example.net
sipToURI => sip:bob@example.net
sipToTag => b1-1
sipFromURI => sip:alice@example.com
sipFromTag => al-1
sipCallId => tr-87h@example.com
sipClientTransaction => c-x-tr
sipServerTransaction => s-x-tr
--- record 12345/257 (#10)---
observationTimeMilliseconds => 2010-06-07 17:12:29 UTC
sipSequenceNumber => 43
sourceIPv4Address => 198.51.100.10
destinationIPv4Address => 203.0.113.1
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 1
sipObservationType => 2
sipRequestURI => sip:bob@example.net
sipToURI => sip:bob@example.net
sipToTag => b1-1
sipFromURI => sip:alice@example.com
sipFromTag => al-1
sipCallId => tr-87h@example.com
sipClientTransaction => c-x-tr
sipServerTransaction => s-x-tr
]]></artwork>
</figure>
<figure title="Message containing ten log entries for a downstream branch call (hexdump)" anchor="ex-branch-hex">
<artwork><![CDATA[
0000: 00 0a 04 e1|4c c0 2c e5 00 00 00 00 00 00 30 39| ....L.,.......09
0010: 01 01 00 7e|00 00 01 29 13 66 13 93 00 00 00 2b ...~...).f.....+
0020: c6 33 64 01 c6 33 64 0a 13 c4 13 c4 11 05 01 13 .3d..3d.........
0030: 73 69 70 3a 62 6f 62 40 65 78 61 6d 70 6c 65 2e sip:bob@example.
0040: 6e 65 74 13 73 69 70 3a 62 6f 62 40 65 78 61 6d net.sip:bob@exam
0050: 70 6c 65 2e 6e 65 74 00 15 73 69 70 3a 61 6c 69 ple.net..sip:ali
0060: 63 65 40 65 78 61 6d 70 6c 65 2e 63 6f 6d 04 61 ce@example.com.a
0070: 6c 2d 31 12 74 72 2d 38 37 68 40 65 78 61 6d 70 l-1.tr-87h@examp
0080: 6c 65 2e 63 6f 6d 00 06 73 2d 78 2d 74 72|01 02 le.com..s-x-tr..
0090: 00 6c|00 00 01 29 13 66 14 c1 00 00 00 2b c6 33 .l...).f.....+.3
00a0: 64 0a c6 33 64 01 13 c4 13 c4 11 05 02 00 64 13 d..3d.........d.
00b0: 73 69 70 3a 62 6f 62 40 65 78 61 6d 70 6c 65 2e sip:bob@example.
00c0: 6e 65 74 00 15 73 69 70 3a 61 6c 69 63 65 40 65 net..sip:alice@e
00d0: 78 61 6d 70 6c 65 2e 63 6f 6d 04 61 6c 2d 31 12 xample.com.al-1.
00e0: 74 72 2d 38 37 68 40 65 78 61 6d 70 6c 65 2e 63 tr-87h@example.c
00f0: 6f 6d 00 06 73 2d 78 2d 74 72|01 01 00 89|00 00 om..s-x-tr......
0100: 01 29 13 66 18 a6 00 00 00 2b c6 33 64 0a cb 00 .).f.....+.3d...
0110: 71 01 13 c4 13 c4 11 05 02 18 73 69 70 3a 62 6f q.........sip:bo
0120: 62 40 62 6f 62 31 2e 65 78 61 6d 70 6c 65 2e 6e b@bob1.example.n
0130: 65 74 13 73 69 70 3a 62 6f 62 40 65 78 61 6d 70 et.sip:bob@examp
0140: 6c 65 2e 6e 65 74 00 15 73 69 70 3a 61 6c 69 63 le.net..sip:alic
0150: 65 40 65 78 61 6d 70 6c 65 2e 63 6f 6d 04 61 6c e@example.com.al
0160: 2d 31 12 74 72 2d 38 37 68 40 65 78 61 6d 70 6c -1.tr-87h@exampl
0170: 65 2e 63 6f 6d 06 63 2d 78 2d 74 72 06 73 2d 78 e.com.c-x-tr.s-x
0180: 2d 74 72|01 02 00 76|00 00 01 29 13 66 19 70 00 -tr...v...).f.p.
0190: 00 00 2b cb 00 71 01 c6 33 64 0a 13 c4 13 c4 11 ..+..q..3d......
01a0: 05 01 00 64 13 73 69 70 3a 62 6f 62 40 65 78 61 ...d.sip:bob@exa
01b0: 6d 70 6c 65 2e 6e 65 74 04 62 31 2d 31 15 73 69 mple.net.b1-1.si
01c0: 70 3a 61 6c 69 63 65 40 65 78 61 6d 70 6c 65 2e p:alice@example.
01d0: 63 6f 6d 04 61 6c 2d 31 12 74 72 2d 38 37 68 40 com.al-1.tr-87h@
01e0: 65 78 61 6d 70 6c 65 2e 63 6f 6d 06 63 2d 78 2d example.com.c-x-
01f0: 74 72 06 73 2d 78 2d 74 72|01 02 00 76|00 00 01 tr.s-x-tr...v...
0200: 29 13 66 1b c8 00 00 00 2b cb 00 71 01 c6 33 64 ).f.....+..q..3d
0210: 0a 13 c4 13 c4 11 05 01 00 b4 13 73 69 70 3a 62 ...........sip:b
0220: 6f 62 40 65 78 61 6d 70 6c 65 2e 6e 65 74 04 62 ob@example.net.b
0230: 31 2d 31 15 73 69 70 3a 61 6c 69 63 65 40 65 78 1-1.sip:alice@ex
0240: 61 6d 70 6c 65 2e 63 6f 6d 04 61 6c 2d 31 12 74 ample.com.al-1.t
0250: 72 2d 38 37 68 40 65 78 61 6d 70 6c 65 2e 63 6f r-87h@example.co
0260: 6d 06 63 2d 78 2d 74 72 06 73 2d 78 2d 74 72|01 m.c-x-tr.s-x-tr.
0270: 02 00 76|00 00 01 29 13 66 1c 98 00 00 00 2b c6 ..v...).f.....+.
0280: 33 64 0a c6 33 64 01 13 c4 13 c4 11 05 02 00 b4 3d..3d..........
0290: 13 73 69 70 3a 62 6f 62 40 65 78 61 6d 70 6c 65 .sip:bob@example
02a0: 2e 6e 65 74 04 62 31 2d 31 15 73 69 70 3a 61 6c .net.b1-1.sip:al
02b0: 69 63 65 40 65 78 61 6d 70 6c 65 2e 63 6f 6d 04 ice@example.com.
02c0: 61 6c 2d 31 12 74 72 2d 38 37 68 40 65 78 61 6d al-1.tr-87h@exam
02d0: 70 6c 65 2e 63 6f 6d 06 63 2d 78 2d 74 72 06 73 ple.com.c-x-tr.s
02e0: 2d 78 2d 74 72|01 02 00 76|00 00 01 29 13 66 20 -x-tr...v...).f
02f0: f0 00 00 00 2b cb 00 71 01 c6 33 64 0a 13 c4 13 ....+..q..3d....
0300: c4 11 05 01 00 c8 13 73 69 70 3a 62 6f 62 40 65 .......sip:bob@e
0310: 78 61 6d 70 6c 65 2e 6e 65 74 04 62 31 2d 31 15 xample.net.b1-1.
0320: 73 69 70 3a 61 6c 69 63 65 40 65 78 61 6d 70 6c sip:alice@exampl
0330: 65 2e 63 6f 6d 04 61 6c 2d 31 12 74 72 2d 38 37 e.com.al-1.tr-87
0340: 68 40 65 78 61 6d 70 6c 65 2e 63 6f 6d 06 63 2d h@example.com.c-
0350: 78 2d 74 72 06 73 2d 78 2d 74 72|01 02 00 76|00 x-tr.s-x-tr...v.
0360: 00 01 29 13 66 21 a4 00 00 00 2b c6 33 64 0a c6 ..).f!....+.3d..
0370: 33 64 01 13 c4 13 c4 11 05 02 00 c8 13 73 69 70 3d...........sip
0380: 3a 62 6f 62 40 65 78 61 6d 70 6c 65 2e 6e 65 74 :bob@example.net
0390: 04 62 31 2d 31 15 73 69 70 3a 61 6c 69 63 65 40 .b1-1.sip:alice@
03a0: 65 78 61 6d 70 6c 65 2e 63 6f 6d 04 61 6c 2d 31 example.com.al-1
03b0: 12 74 72 2d 38 37 68 40 65 78 61 6d 70 6c 65 2e .tr-87h@example.
03c0: 63 6f 6d 06 63 2d 78 2d 74 72 06 73 2d 78 2d 74 com.c-x-tr.s-x-t
03d0: 72|01 01 00 88|00 00 01 29 13 66 28 ac 00 00 00 r.......).f(....
03e0: 2b c6 33 64 01 c6 33 64 0a 13 c4 13 c4 11 01 01 +.3d..3d........
03f0: 13 73 69 70 3a 62 6f 62 40 65 78 61 6d 70 6c 65 .sip:bob@example
0400: 2e 6e 65 74 13 73 69 70 3a 62 6f 62 40 65 78 61 .net.sip:bob@exa
0410: 6d 70 6c 65 2e 6e 65 74 04 62 31 2d 31 15 73 69 mple.net.b1-1.si
0420: 70 3a 61 6c 69 63 65 40 65 78 61 6d 70 6c 65 2e p:alice@example.
0430: 63 6f 6d 04 61 6c 2d 31 12 74 72 2d 38 37 68 40 com.al-1.tr-87h@
0440: 65 78 61 6d 70 6c 65 2e 63 6f 6d 06 63 2d 78 2d example.com.c-x-
0450: 74 72 06 73 2d 78 2d 74 72|01 01 00 88|00 00 01 tr.s-x-tr.......
0460: 29 13 66 28 ac 00 00 00 2b c6 33 64 0a cb 00 71 ).f(....+.3d...q
0470: 01 13 c4 13 c4 11 01 02 13 73 69 70 3a 62 6f 62 .........sip:bob
0480: 40 65 78 61 6d 70 6c 65 2e 6e 65 74 13 73 69 70 @example.net.sip
0490: 3a 62 6f 62 40 65 78 61 6d 70 6c 65 2e 6e 65 74 :bob@example.net
04a0: 04 62 31 2d 31 15 73 69 70 3a 61 6c 69 63 65 40 .b1-1.sip:alice@
04b0: 65 78 61 6d 70 6c 65 2e 63 6f 6d 04 61 6c 2d 31 example.com.al-1
04c0: 12 74 72 2d 38 37 68 40 65 78 61 6d 70 6c 65 2e .tr-87h@example.
04d0: 63 6f 6d 06 63 2d 78 2d 74 72 06 73 2d 78 2d 74 com.c-x-tr.s-x-t
04e0: 72 r
]]></artwork>
</figure>
</section>
<section anchor="sec-example-fork" title="Forked Call">
<t>The example in <xref target="ex-fork-ripfix"/> and <xref
target="ex-fork-hex"/> demonstrates the export of forked call to
Bob, as seen by one of Bob's instances which forks the call
traverses, corresponding to example 9.4 in <xref
target="I-D.ietf-sipclf-problem-statement"></xref>. See this
example for more details. Note that, since Bob's first instance is
multihomed IPv4-IPv6, this example requires additional templates:
request and response templates for IPv4 to IPv6 and back, these
are shown in <xref target="ex-fork-tmpl-hex"/>.</t>
<figure title="Message containing templates for IPv4 to IPv6 requests and responses, and vice versa" anchor="ex-fork-tmpl-hex">
<artwork><![CDATA[
0000: 00 0a 01 e4 4c c0 2d 9b 00 00 00 00 00 00 30 39 ....L.-.......09
0010: 00 02 01 d4 01 05 00 11 01 43 00 08 81 99 00 04 .........C......
0020: 00 00 8a ee 00 08 00 04 00 1c 00 10 00 07 00 02 ................
0030: 00 0b 00 02 00 04 00 01 81 92 00 01 00 00 8a ee ................
0040: 81 a3 00 01 00 00 8a ee 81 93 ff ff 00 00 8a ee ................
0050: 81 96 ff ff 00 00 8a ee 81 97 ff ff 00 00 8a ee ................
0060: 81 94 ff ff 00 00 8a ee 81 95 ff ff 00 00 8a ee ................
0070: 81 98 ff ff 00 00 8a ee 81 9e ff ff 00 00 8a ee ................
0080: 81 9d ff ff 00 00 8a ee 01 06 00 11 01 43 00 08 .............C..
0090: 81 99 00 04 00 00 8a ee 00 08 00 04 00 1c 00 10 ................
00a0: 00 07 00 02 00 0b 00 02 00 04 00 01 81 92 00 01 ................
00b0: 00 00 8a ee 81 a3 00 01 00 00 8a ee 81 9c 00 02 ................
00c0: 00 00 8a ee 81 96 ff ff 00 00 8a ee 81 97 ff ff ................
00d0: 00 00 8a ee 81 94 ff ff 00 00 8a ee 81 95 ff ff ................
00e0: 00 00 8a ee 81 98 ff ff 00 00 8a ee 81 9e ff ff ................
00f0: 00 00 8a ee 81 9d ff ff 00 00 8a ee 01 07 00 11 ................
0100: 01 43 00 08 81 99 00 04 00 00 8a ee 00 1b 00 10 .C..............
0110: 00 0c 00 04 00 07 00 02 00 0b 00 02 00 04 00 01 ................
0120: 81 92 00 01 00 00 8a ee 81 a3 00 01 00 00 8a ee ................
0130: 81 93 ff ff 00 00 8a ee 81 96 ff ff 00 00 8a ee ................
0140: 81 97 ff ff 00 00 8a ee 81 94 ff ff 00 00 8a ee ................
0150: 81 95 ff ff 00 00 8a ee 81 98 ff ff 00 00 8a ee ................
0160: 81 9e ff ff 00 00 8a ee 81 9d ff ff 00 00 8a ee ................
0170: 01 08 00 11 01 43 00 08 81 99 00 04 00 00 8a ee .....C..........
0180: 00 1b 00 10 00 0c 00 04 00 07 00 02 00 0b 00 02 ................
0190: 00 04 00 01 81 92 00 01 00 00 8a ee 81 a3 00 01 ................
01a0: 00 00 8a ee 81 9c 00 02 00 00 8a ee 81 96 ff ff ................
01b0: 00 00 8a ee 81 97 ff ff 00 00 8a ee 81 94 ff ff ................
01c0: 00 00 8a ee 81 95 ff ff 00 00 8a ee 81 98 ff ff ................
01d0: 00 00 8a ee 81 9e ff ff 00 00 8a ee 81 9d ff ff ................
01e0: 00 00 8a ee ....
]]></artwork>
</figure>
<figure title="Message containing fifteen records for a forked call" anchor="ex-fork-ripfix">
<artwork><![CDATA[
===== message 12345/0 @2010-10-21 13:13:01 UTC (#3) =====
--- record 12345/257 (#1)---
observationTimeMilliseconds => 2010-06-07 17:12:23 UTC
sipSequenceNumber => 43
sourceIPv4Address => 198.51.100.1
destinationIPv4Address => 203.0.113.200
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 5
sipObservationType => 1
sipRequestURI => sip:bob@example.net
sipToURI => sip:bob@example.net
sipToTag =>
sipFromURI => sip:alice@example.com
sipFromTag => a1-1
sipCallId => tr-88h@example.com
sipClientTransaction =>
sipServerTransaction => s-1-tr
--- record 12345/258 (#2)---
observationTimeMilliseconds => 2010-06-07 17:12:24 UTC
sipSequenceNumber => 43
sourceIPv4Address => 203.0.113.200
destinationIPv4Address => 198.51.100.1
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 5
sipObservationType => 2
sipResponseStatus => 100
sipToURI => sip:bob@example.net
sipToTag =>
sipFromURI => sip:alice@example.com
sipFromTag => a1-1
sipCallId => tr-88h@example.com
sipClientTransaction =>
sipServerTransaction => s-1-tr
--- record 12345/257 (#3)---
observationTimeMilliseconds => 2010-06-07 17:12:24 UTC
sipSequenceNumber => 43
sourceIPv4Address => 203.0.113.200
destinationIPv4Address => 203.0.113.1
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 5
sipObservationType => 2
sipRequestURI => sip:bob@bob1.example.net
sipToURI => sip:bob@example.net
sipToTag =>
sipFromURI => sip:alice@example.com
sipFromTag => a1-1
sipCallId => tr-88h@example.com
sipClientTransaction => c-1-tr
sipServerTransaction => s-1-tr
--- record 12345/261 (#4)---
observationTimeMilliseconds => 2010-06-07 17:12:25 UTC
sipSequenceNumber => 43
sourceIPv4Address => 203.0.113.200
destinationIPv6Address => 2001:db8::9
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 5
sipObservationType => 2
sipRequestURI => sip:bob@bob2.example.net
sipToURI => sip:bob@example.net
sipToTag =>
sipFromURI => sip:alice@example.com
sipFromTag => a1-1
sipCallId => tr-88h@example.com
sipClientTransaction => c-2-tr
sipServerTransaction => s-1-tr
--- record 12345/258 (#5)---
observationTimeMilliseconds => 2010-06-07 17:12:25 UTC
sipSequenceNumber => 43
sourceIPv4Address => 203.0.113.1
destinationIPv4Address => 203.0.113.200
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 5
sipObservationType => 1
sipResponseStatus => 100
sipToURI => sip:bob@example.net
sipToTag => b1-1
sipFromURI => sip:alice@example.com
sipFromTag => a1-1
sipCallId => tr-88h@example.com
sipClientTransaction => c-1-tr
sipServerTransaction => s-1-tr
--- record 12345/264 (#6)---
observationTimeMilliseconds => 2010-06-07 17:12:26 UTC
sipSequenceNumber => 43
sourceIPv6Address => 2001:db8::9
destinationIPv4Address => 203.0.113.200
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 5
sipObservationType => 1
sipResponseStatus => 100
sipToURI => sip:bob@example.net
sipToTag => b2-2
sipFromURI => sip:alice@example.com
sipFromTag => a1-1
sipCallId => tr-88h@example.com
sipClientTransaction => c-2-tr
sipServerTransaction => s-1-tr
--- record 12345/264 (#7)---
observationTimeMilliseconds => 2010-06-07 17:12:26 UTC
sipSequenceNumber => 43
sourceIPv6Address => 2001:db8::9
destinationIPv4Address => 203.0.113.200
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 5
sipObservationType => 1
sipResponseStatus => 180
sipToURI => sip:bob@example.net
sipToTag => b2-2
sipFromURI => sip:alice@example.com
sipFromTag => a1-1
sipCallId => tr-88h@example.com
sipClientTransaction => c-2-tr
sipServerTransaction => s-1-tr
--- record 12345/258 (#8)---
observationTimeMilliseconds => 2010-06-07 17:12:26 UTC
sipSequenceNumber => 43
sourceIPv4Address => 203.0.113.200
destinationIPv4Address => 198.51.100.1
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 5
sipObservationType => 2
sipResponseStatus => 180
sipToURI => sip:bob@example.net
sipToTag =>
sipFromURI => sip:alice@example.com
sipFromTag => a1-1
sipCallId => tr-88h@example.com
sipClientTransaction => c-2-tr
sipServerTransaction => s-1-tr
--- record 12345/258 (#9)---
observationTimeMilliseconds => 2010-06-07 17:12:27 UTC
sipSequenceNumber => 43
sourceIPv4Address => 203.0.113.200
destinationIPv4Address => 198.51.100.1
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 5
sipObservationType => 2
sipResponseStatus => 180
sipToURI => sip:bob@example.net
sipToTag => b1-1
sipFromURI => sip:alice@example.com
sipFromTag => a1-1
sipCallId => tr-88h@example.com
sipClientTransaction => c-1-tr
sipServerTransaction => s-1-tr
--- record 12345/258 (#10)---
observationTimeMilliseconds => 2010-06-07 17:12:27 UTC
sipSequenceNumber => 43
sourceIPv4Address => 203.0.113.1
destinationIPv4Address => 203.0.113.200
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 5
sipObservationType => 1
sipResponseStatus => 200
sipToURI => sip:bob@example.net
sipToTag => b1-1
sipFromURI => sip:alice@example.com
sipFromTag => a1-1
sipCallId => tr-88h@example.com
sipClientTransaction => c-1-tr
sipServerTransaction => s-1-tr
--- record 12345/258 (#11)---
observationTimeMilliseconds => 2010-06-07 17:12:28 UTC
sipSequenceNumber => 43
sourceIPv4Address => 203.0.113.200
destinationIPv4Address => 198.51.100.1
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 5
sipObservationType => 2
sipResponseStatus => 200
sipToURI => sip:bob@example.net
sipToTag => b1-1
sipFromURI => sip:alice@example.com
sipFromTag => a1-1
sipCallId => tr-88h@example.com
sipClientTransaction => c-1-tr
sipServerTransaction => s-1-tr
--- record 12345/261 (#12)---
observationTimeMilliseconds => 2010-06-07 17:12:28 UTC
sipSequenceNumber => 43
sourceIPv4Address => 203.0.113.200
destinationIPv6Address => 2001:db8::9
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 3
sipObservationType => 2
sipRequestURI => sip:bob@bob2.example.net
sipToURI => sip:bob@example.net
sipToTag =>
sipFromURI => sip:alice@example.com
sipFromTag => a1-1
sipCallId => tr-88h@example.com
sipClientTransaction => c-2-tr
sipServerTransaction => s-1-tr
--- record 12345/264 (#13)---
observationTimeMilliseconds => 2010-06-07 17:12:28 UTC
sipSequenceNumber => 43
sourceIPv6Address => 2001:db8::9
destinationIPv4Address => 203.0.113.200
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 5
sipObservationType => 1
sipResponseStatus => 487
sipToURI => sip:bob@example.net
sipToTag =>
sipFromURI => sip:alice@example.com
sipFromTag => a1-1
sipCallId => tr-88h@example.com
sipClientTransaction => c-2-tr
sipServerTransaction => s-1-tr
--- record 12345/261 (#14)---
observationTimeMilliseconds => 2010-06-07 17:12:29 UTC
sipSequenceNumber => 43
sourceIPv4Address => 203.0.113.200
destinationIPv6Address => 2001:db8::9
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 1
sipObservationType => 2
sipRequestURI => sip:bob@bob2.example.net
sipToURI => sip:bob@example.net
sipToTag =>
sipFromURI => sip:alice@example.com
sipFromTag => a1-1
sipCallId => tr-88h@example.com
sipClientTransaction => c-2-tr
sipServerTransaction => s-1-tr
--- record 12345/264 (#15)---
observationTimeMilliseconds => 2010-06-07 17:12:30 UTC
sipSequenceNumber => 43
sourceIPv6Address => 2001:db8::9
destinationIPv4Address => 203.0.113.200
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 3
sipObservationType => 1
sipResponseStatus => 200
sipToURI => sip:bob@example.net
sipToTag =>
sipFromURI => sip:alice@example.com
sipFromTag => a1-1
sipCallId => tr-88h@example.com
sipClientTransaction => c-2-tr
sipServerTransaction => s-1-tr
]]></artwork></figure>
<figure title="Message containing sixteen log entries for a forked call" anchor="ex-fork-hex">
<artwork><![CDATA[
0000: 00 0a 07 8c 4c c0 2d 9b 00 00 00 00 00 00 30 39| ....L.-.......09
0010: 01 01 00 7e|00 00 01 29 13 66 13 93 00 00 00 2b ...~...).f.....+
0020: c6 33 64 01 cb 00 71 c8 13 c4 13 c4 11 05 01 13 .3d...q.........
0030: 73 69 70 3a 62 6f 62 40 65 78 61 6d 70 6c 65 2e sip:bob@example.
0040: 6e 65 74 13 73 69 70 3a 62 6f 62 40 65 78 61 6d net.sip:bob@exam
0050: 70 6c 65 2e 6e 65 74 00 15 73 69 70 3a 61 6c 69 ple.net..sip:ali
0060: 63 65 40 65 78 61 6d 70 6c 65 2e 63 6f 6d 04 61 ce@example.com.a
0070: 31 2d 31 12 74 72 2d 38 38 68 40 65 78 61 6d 70 1-1.tr-88h@examp
0080: 6c 65 2e 63 6f 6d 00 06 73 2d 31 2d 74 72|01 02 le.com..s-1-tr..
0090: 00 6c|00 00 01 29 13 66 14 c1 00 00 00 2b cb 00 .l...).f.....+..
00a0: 71 c8 c6 33 64 01 13 c4 13 c4 11 05 02 00 64 13 q..3d.........d.
00b0: 73 69 70 3a 62 6f 62 40 65 78 61 6d 70 6c 65 2e sip:bob@example.
00c0: 6e 65 74 00 15 73 69 70 3a 61 6c 69 63 65 40 65 net..sip:alice@e
00d0: 78 61 6d 70 6c 65 2e 63 6f 6d 04 61 31 2d 31 12 xample.com.a1-1.
00e0: 74 72 2d 38 38 68 40 65 78 61 6d 70 6c 65 2e 63 tr-88h@example.c
00f0: 6f 6d 00 06 73 2d 31 2d 74 72|01 01 00 89|00 00 om..s-1-tr......
0100: 01 29 13 66 18 a6 00 00 00 2b cb 00 71 c8 cb 00 .).f.....+..q...
0110: 71 01 13 c4 13 c4 11 05 02 18 73 69 70 3a 62 6f q.........sip:bo
0120: 62 40 62 6f 62 31 2e 65 78 61 6d 70 6c 65 2e 6e b@bob1.example.n
0130: 65 74 13 73 69 70 3a 62 6f 62 40 65 78 61 6d 70 et.sip:bob@examp
0140: 6c 65 2e 6e 65 74 00 15 73 69 70 3a 61 6c 69 63 le.net..sip:alic
0150: 65 40 65 78 61 6d 70 6c 65 2e 63 6f 6d 04 61 31 e@example.com.a1
0160: 2d 31 12 74 72 2d 38 38 68 40 65 78 61 6d 70 6c -1.tr-88h@exampl
0170: 65 2e 63 6f 6d 06 63 2d 31 2d 74 72 06 73 2d 31 e.com.c-1-tr.s-1
0180: 2d 74 72|01 05 00 95|00 00 01 29 13 66 1a 9c 00 -tr.......).f...
0190: 00 00 2b cb 00 71 c8 20 01 0d b8 00 00 00 00 00 ..+..q. ........
01a0: 00 00 00 00 00 00 09 13 c4 13 c4 11 05 02 18 73 ...............s
01b0: 69 70 3a 62 6f 62 40 62 6f 62 32 2e 65 78 61 6d ip:bob@bob2.exam
01c0: 70 6c 65 2e 6e 65 74 13 73 69 70 3a 62 6f 62 40 ple.net.sip:bob@
01d0: 65 78 61 6d 70 6c 65 2e 6e 65 74 00 15 73 69 70 example.net..sip
01e0: 3a 61 6c 69 63 65 40 65 78 61 6d 70 6c 65 2e 63 :alice@example.c
01f0: 6f 6d 04 61 31 2d 31 12 74 72 2d 38 38 68 40 65 om.a1-1.tr-88h@e
0200: 78 61 6d 70 6c 65 2e 63 6f 6d 06 63 2d 32 2d 74 xample.com.c-2-t
0210: 72 06 73 2d 31 2d 74 72|01 02 00 76|00 00 01 29 r.s-1-tr...v...)
0220: 13 66 1b c8 00 00 00 2b cb 00 71 01 cb 00 71 c8 .f.....+..q...q.
0230: 13 c4 13 c4 11 05 01 00 64 13 73 69 70 3a 62 6f ........d.sip:bo
0240: 62 40 65 78 61 6d 70 6c 65 2e 6e 65 74 04 62 31 b@example.net.b1
0250: 2d 31 15 73 69 70 3a 61 6c 69 63 65 40 65 78 61 -1.sip:alice@exa
0260: 6d 70 6c 65 2e 63 6f 6d 04 61 31 2d 31 12 74 72 mple.com.a1-1.tr
0270: 2d 38 38 68 40 65 78 61 6d 70 6c 65 2e 63 6f 6d -88h@example.com
0280: 06 63 2d 31 2d 74 72 06 73 2d 31 2d 74 72|01 08 .c-1-tr.s-1-tr..
0290: 00 82|00 00 01 29 13 66 1c f4 00 00 00 2b 20 01 .....).f.....+ .
02a0: 0d b8 00 00 00 00 00 00 00 00 00 00 00 09 cb 00 ................
02b0: 71 c8 13 c4 13 c4 11 05 01 00 64 13 73 69 70 3a q.........d.sip:
02c0: 62 6f 62 40 65 78 61 6d 70 6c 65 2e 6e 65 74 04 bob@example.net.
02d0: 62 32 2d 32 15 73 69 70 3a 61 6c 69 63 65 40 65 b2-2.sip:alice@e
02e0: 78 61 6d 70 6c 65 2e 63 6f 6d 04 61 31 2d 31 12 xample.com.a1-1.
02f0: 74 72 2d 38 38 68 40 65 78 61 6d 70 6c 65 2e 63 tr-88h@example.c
0300: 6f 6d 06 63 2d 32 2d 74 72 06 73 2d 31 2d 74 72| om.c-2-tr.s-1-tr
0310: 01 08 00 82|00 00 01 29 13 66 1f 4c 00 00 00 2b .......).f.L...+
0320: 20 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 09 ...............
0330: cb 00 71 c8 13 c4 13 c4 11 05 01 00 b4 13 73 69 ..q...........si
0340: 70 3a 62 6f 62 40 65 78 61 6d 70 6c 65 2e 6e 65 p:bob@example.ne
0350: 74 04 62 32 2d 32 15 73 69 70 3a 61 6c 69 63 65 t.b2-2.sip:alice
0360: 40 65 78 61 6d 70 6c 65 2e 63 6f 6d 04 61 31 2d @example.com.a1-
0370: 31 12 74 72 2d 38 38 68 40 65 78 61 6d 70 6c 65 1.tr-88h@example
0380: 2e 63 6f 6d 06 63 2d 32 2d 74 72 06 73 2d 31 2d .com.c-2-tr.s-1-
0390: 74 72|01 02 00 72|00 00 01 29 13 66 20 6e 00 00 tr...r...).f n..
03a0: 00 2b cb 00 71 c8 c6 33 64 01 13 c4 13 c4 11 05 .+..q..3d.......
03b0: 02 00 b4 13 73 69 70 3a 62 6f 62 40 65 78 61 6d ....sip:bob@exam
03c0: 70 6c 65 2e 6e 65 74 00 15 73 69 70 3a 61 6c 69 ple.net..sip:ali
03d0: 63 65 40 65 78 61 6d 70 6c 65 2e 63 6f 6d 04 61 ce@example.com.a
03e0: 31 2d 31 12 74 72 2d 38 38 68 40 65 78 61 6d 70 1-1.tr-88h@examp
03f0: 6c 65 2e 63 6f 6d 06 63 2d 32 2d 74 72 06 73 2d le.com.c-2-tr.s-
0400: 31 2d 74 72|01 02 00 76|00 00 01 29 13 66 21 a4 1-tr...v...).f!.
0410: 00 00 00 2b cb 00 71 c8 c6 33 64 01 13 c4 13 c4 ...+..q..3d.....
0420: 11 05 02 00 b4 13 73 69 70 3a 62 6f 62 40 65 78 ......sip:bob@ex
0430: 61 6d 70 6c 65 2e 6e 65 74 04 62 31 2d 31 15 73 ample.net.b1-1.s
0440: 69 70 3a 61 6c 69 63 65 40 65 78 61 6d 70 6c 65 ip:alice@example
0450: 2e 63 6f 6d 04 61 31 2d 31 12 74 72 2d 38 38 68 .com.a1-1.tr-88h
0460: 40 65 78 61 6d 70 6c 65 2e 63 6f 6d 06 63 2d 31 @example.com.c-1
0470: 2d 74 72 06 73 2d 31 2d 74 72|01 02 00 76|00 00 -tr.s-1-tr...v..
0480: 01 29 13 66 23 98 00 00 00 2b cb 00 71 01 cb 00 .).f#....+..q...
0490: 71 c8 13 c4 13 c4 11 05 01 00 c8 13 73 69 70 3a q...........sip:
04a0: 62 6f 62 40 65 78 61 6d 70 6c 65 2e 6e 65 74 04 bob@example.net.
04b0: 62 31 2d 31 15 73 69 70 3a 61 6c 69 63 65 40 65 b1-1.sip:alice@e
04c0: 78 61 6d 70 6c 65 2e 63 6f 6d 04 61 31 2d 31 12 xample.com.a1-1.
04d0: 74 72 2d 38 38 68 40 65 78 61 6d 70 6c 65 2e 63 tr-88h@example.c
04e0: 6f 6d 06 63 2d 31 2d 74 72 06 73 2d 31 2d 74 72| om.c-1-tr.s-1-tr
04f0: 01 02 00 76|00 00 01 29 13 66 24 60 00 00 00 2b ...v...).f$`...+
0500: cb 00 71 c8 c6 33 64 01 13 c4 13 c4 11 05 02 00 ..q..3d.........
0510: c8 13 73 69 70 3a 62 6f 62 40 65 78 61 6d 70 6c ..sip:bob@exampl
0520: 65 2e 6e 65 74 04 62 31 2d 31 15 73 69 70 3a 61 e.net.b1-1.sip:a
0530: 6c 69 63 65 40 65 78 61 6d 70 6c 65 2e 63 6f 6d lice@example.com
0540: 04 61 31 2d 31 12 74 72 2d 38 38 68 40 65 78 61 .a1-1.tr-88h@exa
0550: 6d 70 6c 65 2e 63 6f 6d 06 63 2d 31 2d 74 72 06 mple.com.c-1-tr.
0560: 73 2d 31 2d 74 72|01 05 00 95|00 00 01 29 13 66 s-1-tr.......).f
0570: 25 29 00 00 00 2b cb 00 71 c8 20 01 0d b8 00 00 %)...+..q. .....
0580: 00 00 00 00 00 00 00 00 00 09 13 c4 13 c4 11 03 ................
0590: 02 18 73 69 70 3a 62 6f 62 40 62 6f 62 32 2e 65 ..sip:bob@bob2.e
05a0: 78 61 6d 70 6c 65 2e 6e 65 74 13 73 69 70 3a 62 xample.net.sip:b
05b0: 6f 62 40 65 78 61 6d 70 6c 65 2e 6e 65 74 00 15 ob@example.net..
05c0: 73 69 70 3a 61 6c 69 63 65 40 65 78 61 6d 70 6c sip:alice@exampl
05d0: 65 2e 63 6f 6d 04 61 31 2d 31 12 74 72 2d 38 38 e.com.a1-1.tr-88
05e0: 68 40 65 78 61 6d 70 6c 65 2e 63 6f 6d 06 63 2d h@example.com.c-
05f0: 32 2d 74 72 06 73 2d 31 2d 74 72|01 08 00 7e|00 2-tr.s-1-tr...~.
0600: 00 01 29 13 66 28 3f 00 00 00 2b 20 01 0d b8 00 ..).f(?...+ ....
0610: 00 00 00 00 00 00 00 00 00 00 09 cb 00 71 c8 13 .............q..
0620: c4 13 c4 11 05 01 01 e7 13 73 69 70 3a 62 6f 62 .........sip:bob
0630: 40 65 78 61 6d 70 6c 65 2e 6e 65 74 00 15 73 69 @example.net..si
0640: 70 3a 61 6c 69 63 65 40 65 78 61 6d 70 6c 65 2e p:alice@example.
0650: 63 6f 6d 04 61 31 2d 31 12 74 72 2d 38 38 68 40 com.a1-1.tr-88h@
0660: 65 78 61 6d 70 6c 65 2e 63 6f 6d 06 63 2d 32 2d example.com.c-2-
0670: 74 72 06 73 2d 31 2d 74 72|01 05 00 95|00 00 01 tr.s-1-tr.......
0680: 29 13 66 2a 0f 00 00 00 2b cb 00 71 c8 20 01 0d ).f*....+..q. ..
0690: b8 00 00 00 00 00 00 00 00 00 00 00 09 13 c4 13 ................
06a0: c4 11 01 02 18 73 69 70 3a 62 6f 62 40 62 6f 62 .....sip:bob@bob
06b0: 32 2e 65 78 61 6d 70 6c 65 2e 6e 65 74 13 73 69 2.example.net.si
06c0: 70 3a 62 6f 62 40 65 78 61 6d 70 6c 65 2e 6e 65 p:bob@example.ne
06d0: 74 00 15 73 69 70 3a 61 6c 69 63 65 40 65 78 61 t..sip:alice@exa
06e0: 6d 70 6c 65 2e 63 6f 6d 04 61 31 2d 31 12 74 72 mple.com.a1-1.tr
06f0: 2d 38 38 68 40 65 78 61 6d 70 6c 65 2e 63 6f 6d -88h@example.com
0700: 06 63 2d 32 2d 74 72 06 73 2d 31 2d 74 72|01 08 .c-2-tr.s-1-tr..
0710: 00 7e|00 00 01 29 13 66 2c 31 00 00 00 2b 20 01 .~...).f,1...+ .
0720: 0d b8 00 00 00 00 00 00 00 00 00 00 00 09 cb 00 ................
0730: 71 c8 13 c4 13 c4 11 03 01 00 c8 13 73 69 70 3a q...........sip:
0740: 62 6f 62 40 65 78 61 6d 70 6c 65 2e 6e 65 74 00 bob@example.net.
0750: 15 73 69 70 3a 61 6c 69 63 65 40 65 78 61 6d 70 .sip:alice@examp
0760: 6c 65 2e 63 6f 6d 04 61 31 2d 31 12 74 72 2d 38 le.com.a1-1.tr-8
0770: 38 68 40 65 78 61 6d 70 6c 65 2e 63 6f 6d 06 63 8h@example.com.c
0780: 2d 32 2d 74 72 06 73 2d 31 2d 74 72 -2-tr.s-1-tr
]]></artwork>
</figure>
</section>
<!-- <section title="Torture Tests">
<t>[EDITOR'S NOTE: The torture tests have to be reworked to reflect
proper handling of escapes: we log things escaped, and require the
log reader to follow the SIP escaping rules. However, note that this
makes the torture tests much less relevant with respect to the
logging format, and we should review whether it makes sense to
retain this section.]</t>
<t>To demonstrate that the SIPCLF-IPFIX file format can handle other
than simple situations, here we show how log entries from selected
SIP torture tests given in <xref target="RFC4475"/>. Note that this
demonstrates only that there is nothing inherent to the logging
format that precludes handling these cases; implementors of logging
using SIPCLF-IPFIX must still take care that the SIP-specific side
of the implementation handles these torture tests correctly. Each of
these tests displays a resulting record with templates defined in
<xref target="sec-example-template"/> and values for unspecified
fields taken from <xref target="sec-example-uacreg"/>.</t>
<t>The torture test in section 3.1.1.2 tests the handling of unusual
characters. Assuming that the SIP parser is able to handle this
message, the resulting log entry in rfdump format is shown in <xref
target="ex-chars-rfd"/> (hand-edited to fit long lines within
Internet-Draft limits). Note that the unknown SIP method is logged
as such (method 0 = Unknown).</t>
<figure title="Message containing wide variety of characters"
anchor="ex-chars-rfd"> <artwork><![CDATA[
==== message sequence 0 in domain 12345 at 2010-08-12 07:44:33 UTC ====
---- record 12345/257 ----
observationTimeMilliseconds => 2010-08-12 07:44:33 UTC
sipSequenceNumber => 139122385
sourceIPv4Address => 198.51.100.10
destinationIPv4Address => 198.51.100.1
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 0
sipObservationType => 1
sipRequestURI => sip:1_unusual.URI~(to-be!sure)&isn't+it$/crazy?,/
;;*:&it+has=1,weird!*pas$wo~d_too.(doesn't-it)@example.com
sipToURI => sip:1_unusual.URI~(to-be!sure)&isn't+it$/crazy?,/
;;*@example.com
sipToTag =>
sipFromURI => sip:mundane@example.com
sipFromTag => _token~1'+`*%!-.
sipCallId => intmeth.word%ZK-!.*_+'@word`~)(><:\/"][?}{
sipClientTransaction =>
sipServerTransaction =>
]]></artwork>
</figure>
<t>The torture test in section 3.1.1.4 tests the handling of
embedded NULs in strings. Since IPFIX uses length-prefixing for
variable length strings, this does not present a problem for
logging. The resulting record rfdump format in <xref
target="ex-nulls-rfd"/>. Here, hex escaping shows that the NUL is
properly embedded in the string.</t>
<figure title="Message containing NULs in URIs" anchor="ex-nulls-rfd">
<artwork><![CDATA[
==== message sequence 0 in domain 12345 at 2010-08-11 13:01:05 UTC ====
---- record 12345/257 ----
observationTimeMilliseconds => 2010-08-11 13:01:05 UTC
sipSequenceNumber => 14398234
sourceIPv4Address => 198.51.100.10
destinationIPv4Address => 198.51.100.1
sourceTransportPort => 5060
destinationTransportPort => 5060
protocolIdentifier => 17
sipMethod => 12
sipObservationType => 2
sipRequestURI => sip:example.com
sipToURI => sip:null-\x00-null@example.com
sipToTag =>
sipFromURI => sip:null-\x00-null@example.com
sipFromTag => 839923423
sipCallId => escnull.39203ndfvkjdasfkq3w4otrq0adsfdfnavd
sipClientTransaction =>
sipServerTransaction =>
]]></artwork>
</figure>
<t>The sipToURI portion of the record is shown in <xref
target="ex-nulls-hex"/> as an annotated hexdump. Note the length
byte at the beginning of the string, and the NUL embedded
inside.</t>
<figure title="Message containing NULs in URIs" anchor="ex-nulls-hex">
<artwork><![CDATA[
003f: 1b .
[ varlen record, length 27 ]
0040: 73 69 70 3a 6e 75 6c 6c 2d 00 2d 6e 75 6c 6c 40 sip:null-.-null@
[ note NUL here ^^ ]
0050: 65 78 61 6d 70 6c 65 2e 63 6f 6d example.com
]]></artwork>
</figure>
</section> -->
</section>
<section title="Security Considerations">
<t>
[TODO]
</t>
</section>
<section title="IANA Considerations">
<t>This document defines the sipMethod subregistry for the IANA IPFIX
Information Element registry at http://www.iana.org/assignments/ipfix
for the values taken by the sipMethod Information Element. The initial
content of this subregistry is specified in <xref
target="sec-sipmethod"/>. Entries may be added to this subregistry
subject to the same <xref target="RFC5226">Standards Action</xref>
that adds new Methods to the Methods and Response Codes registry at
http://www.iana.org/assignments/sip-parameters.</t>
<t>At such time as this document is prepared for publication as an RFC,
the Information Elements defined herein will be defined for inclusion in
the IANA IPFIX Information Element registry at
http://www.iana.org/assignments/ipfix. Until such time, the Information
Elements within this document are defined within Private Enterprise
Number 35566, belonging to one of the authors.</t>
</section>
<section title="Acknowledgments">
<t>Thanks to Cullen Jennings for his provided insightful discussions,
specific comments and much needed corrections, and to Nico d'Heureuse
for his help with the RFC 3665 examples.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.5101" ?>
<?rfc include="reference.RFC.5655" ?>
<?rfc include="reference.I-D.ietf-sipclf-problem-statement" ?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.trammell-ipfix-ie-doctors" ?>
<?rfc include="reference.I-D.kaplan-dispatch-session-id" ?>
<?rfc include="reference.RFC.2976" ?>
<?rfc include="reference.RFC.3261" ?>
<?rfc include="reference.RFC.3262" ?>
<?rfc include="reference.RFC.3265" ?>
<?rfc include="reference.RFC.3311" ?>
<?rfc include="reference.RFC.3428" ?>
<?rfc include="reference.RFC.3515" ?>
<?rfc include="reference.RFC.3665" ?>
<?rfc include="reference.RFC.3903" ?>
<?rfc include="reference.RFC.4475" ?>
<?rfc include="reference.RFC.5226" ?>
<?rfc include="reference.RFC.6026" ?>
<?rfc include="reference.RFC.6086" ?>
<reference anchor="ripfix">
<front>
<title>
ripfix: IPFIX for Ruby
</title>
<author fullname="B. Trammell" initials="B." surname="Trammell">
<organization>ETH Zurich</organization>
</author>
</front>
<seriesInfo name="" value="available at http://ripfix.rubyforge.org/" />
</reference>
</references>
<section title="Definition of Base SIP Message Information Elements in IANA XML Registry format">
<t>[EDITOR'S NOTE: frontmatter]</t>
<figure title="SIP Message Information Element definitions">
<artwork><![CDATA[
<registry xmlns="http://www.iana.org/assignments" id="ipfix">
<registry id="ipfix-information-element-definitions">
<record>
<name>sipObservationType</name>
<dataType>unsigned8</dataType>
<dataTypeSemantics>identifier</dataTypeSemantics>
<enterpriseId>35566</enterpriseId>
<elementId>419</elementId>
<status>current</status>
<description>
<paragraph>
Denotes whether the entry was
corresponds to a SIP message received, sent, or merely
seen by a passive observer, as follows:
</paragraph>
<paragraph>0: unknown: The Metering Process does not
specify the observation type.</paragraph>
<paragraph>1: receiver: The Metering Process is, or is
co-located with, the receiver of the SIP message.</paragraph>
<paragraph>2: sender: The Metering Process is, or is
co-located with, the sender of the SIP message.</paragraph>
<paragraph>3: passive: The Metering Process passively
observed the SIP message.</paragraph>
</description>
</record>
<record>
<name>sipMethod</name>
<dataType>unsigned8</dataType>
<dataTypeSemantics>identifier</dataTypeSemantics>
<enterpriseId>35566</enterpriseId>
<elementId>402</elementId>
<status>current</status>
<description>
<paragraph>
The SIP method from the CSeq header, encoded as per
the IPFIX sipMethod subregistry.
</paragraph>
</description>
</record>
<record>
<name>sipSequenceNumber</name>
<dataType>unsigned32</dataType>
<dataTypeSemantics>identifier</dataTypeSemantics>
<enterpriseId>35566</enterpriseId>
<elementId>409</elementId>
<status>current</status>
<description>
<paragraph>The sequence number from the CSeq header.</paragraph>
</description>
</record>
<record>
<name>sipRequestURI</name>
<dataType>string</dataType>
<enterpriseId>35566</enterpriseId>
<elementId>403</elementId>
<status>current</status>
<description>
<paragraph>The SIP Request URI, including any parameters,
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.</paragraph>
</description>
</record>
<record>
<name>sipFromURI</name>
<dataType>string</dataType>
<enterpriseId>35566</enterpriseId>
<elementId>404</elementId>
<status>current</status>
<description>
<paragraph>The URI from the SIP From: header</paragraph>
</description>
</record>
<record>
<name>sipFromTag</name>
<dataType>string</dataType>
<enterpriseId>35566</enterpriseId>
<elementId>405</elementId>
<status>current</status>
<description>
<paragraph>The Tag parameter value from the SIP
From: header</paragraph>
</description>
</record>
<record>
<name>sipToURI</name>
<dataType>string</dataType>
<enterpriseId>35566</enterpriseId>
<elementId>406</elementId>
<status>current</status>
<description>
<paragraph>The URI from the SIP To: header</paragraph>
</description>
</record>
<record>
<name>sipToTag</name>
<dataType>string</dataType>
<enterpriseId>35566</enterpriseId>
<elementId>407</elementId>
<status>current</status>
<description>
<paragraph>The Tag parameter value from the SIP To:
header</paragraph>
</description>
</record>
<record>
<name>sipCallId</name>
<dataType>string</dataType>
<enterpriseId>35566</enterpriseId>
<elementId>408</elementId>
<status>current</status>
<description>
<paragraph>The value of the SIP Call-ID: header</paragraph>
</description>
</record>
<record>
<name>sipResponseStatus</name>
<dataType>unsigned16</dataType>
<dataTypeSemantics>identifier</dataTypeSemantics>
<enterpriseId>35566</enterpriseId>
<elementId>412</elementId>
<status>current</status>
<description>
<paragraph>The SIP Response code. The presence of this
Information Element in a SIP Message record marks it as
describing a SIP response; if absent, the record describes
a SIP request.</paragraph>
</description>
</record>
<record>
<name>sipServerTransaction</name>
<dataType>string</dataType>
<dataTypeSemantics>identifier</dataTypeSemantics>
<enterpriseId>35566</enterpriseId>
<elementId>413</elementId>
<status>current</status>
<description>
<paragraph>The transaction identifier associated with
the server transaction.</paragraph>
</description>
</record>
<record>
<name>sipClientTransaction</name>
<dataType>string</dataType>
<dataTypeSemantics>identifier</dataTypeSemantics>
<enterpriseId>35566</enterpriseId>
<elementId>414</elementId>
<status>current</status>
<description>
<paragraph>The transaction identifier associated with
the client transaction.</paragraph>
</description>
</record>
</registry>
</registry>
]]></artwork></figure>
</section>
<section title="Definition of sipMethod registry in IANA XML Registry format">
<t>[EDITOR'S NOTE: frontmatter]</t>
<figure title="sipMethod subregistry">
<artwork><![CDATA[
<registry xmlns="http://www.iana.org/assignments" id="ipfix">
<registry id="sipMethod">
<title>IPFIX sipMethod</title>
<registration_rule>Expert Review</registration_rule>
<record>
<value>0</value>
<description>Unknown</description>
<comments>The Metering Process did not
recognize the SIP method.</comments>
</record>
<record>
<value>1</value>
<description>ACK</description>
<comments/>
<xref type="rfc" data="rfc3261"/>
</record>
<record>
<value>2</value>
<description>BYE</description>
<comments/>
<xref type="rfc" data="rfc3261"/>
</record>
<record>
<value>3</value>
<description>CANCEL</description>
<comments/>
<xref type="rfc" data="rfc3261"/>
</record>
<record>
<value>4</value>
<description>INFO</description>
<comments/>
<xref type="rfc" data="rfc6086"/>
</record>
<record>
<value>5</value>
<description>INVITE</description>
<comments/>
<xref type="rfc" data="rfc3261"/>
</record>
<record>
<value>6</value>
<description>MESSAGE</description>
<comments/>
<xref type="rfc" data="rfc3428"/>
</record>
<record>
<value>7</value>
<description>NOTIFY</description>
<comments/>
<xref type="rfc" data="rfc3265"/>
</record>
<record>
<value>8</value>
<description>OPTIONS</description>
<comments/>
<xref type="rfc" data="rfc3261"/>
</record>
<record>
<value>9</value>
<description>PRACK</description>
<comments/>
<xref type="rfc" data="rfc3262"/>
</record>
<record>
<value>10</value>
<description>PUBLISH</description>
<comments/>
<xref type="rfc" data="rfc3903"/>
</record>
<record>
<value>11</value>
<description>REFER</description>
<comments/>
<xref type="rfc" data="rfc3515"/>
</record>
<record>
<value>12</value>
<description>REGISTER</description>
<comments/>
<xref type="rfc" data="rfc3261"/>
</record>
<record>
<value>13</value>
<description>SUBSCRIBE</description>
<comments/>
<xref type="rfc" data="rfc3265"/>
</record>
<record>
<value>14</value>
<description>UPDATE</description>
<comments/>
<xref type="rfc" data="rfc3311"/>
</record>
<record>
<value>15-65535</value>
<description>Unassigned</description>
<comments></comments>
</record>
</registry>
</registry>
]]></artwork></figure>
</section>
<section title="Definition of Additional SIP Message Information Elements in IANA XML Registry format">
<t>[EDITOR'S NOTE: frontmatter]</t>
<figure title="Additional SIP Message Information Element definitions">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<registry xmlns="http://www.iana.org/assignments" id="ipfix">
<registry id="ipfix-information-element-definitions">
<record>
<name>sipContactURI</name>
<dataType>string</dataType>
<enterpriseId>35566</enterpriseId>
<elementId>415</elementId>
<status>current</status>
<description>
<paragraph>The addr-spec URI, including any URI parameters,
of the first/top-most SIP Contact header,
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.</paragraph>
</description>
</record>
<record>
<name>sipRouteURI</name>
<dataType>string</dataType>
<enterpriseId>35566</enterpriseId>
<elementId>416</elementId>
<status>current</status>
<description>
<paragraph>The addr-spec URI, including any URI parameters,
of the first/top-most SIP Route header,
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.</paragraph>
</description>
</record>
<record>
<name>sipPaiURI</name>
<dataType>string</dataType>
<enterpriseId>35566</enterpriseId>
<elementId>417</elementId>
<status>current</status>
<description>
<paragraph>The addr-spec URI, including any URI parameters,
of the first/top-most SIP P-Asserted-Identity header,
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.</paragraph>
</description>
</record>
<record>
<name>sipPpiURI</name>
<dataType>string</dataType>
<enterpriseId>35566</enterpriseId>
<elementId>418</elementId>
<status>current</status>
<description>
<paragraph>The addr-spec URI, including any URI parameters,
of the first/top-most SIP P-Preferred-Identity header,
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.</paragraph>
</description>
</record>
<record>
<name>sipPAssocURI</name>
<dataType>string</dataType>
<enterpriseId>35566</enterpriseId>
<elementId>430</elementId>
<status>current</status>
<description>
<paragraph>The addr-spec URI, including any URI parameters,
of the first/top-most SIP P-Associated-Identity header,
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.</paragraph>
</description>
</record>
<record>
<name>sipPCalledPartyURI</name>
<dataType>string</dataType>
<enterpriseId>35566</enterpriseId>
<elementId>420</elementId>
<status>current</status>
<description>
<paragraph>The addr-spec URI, including any URI parameters,
of the SIP P-Called-Party-ID header,
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.</paragraph>
</description>
</record>
<record>
<name>sipVia</name>
<dataType>string</dataType>
<enterpriseId>35566</enterpriseId>
<elementId>421</elementId>
<status>current</status>
<description>
<paragraph>The value of the first/top-most Via header
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.</paragraph>
</description>
</record>
<record>
<name>sipAuthUsername</name>
<dataType>string</dataType>
<enterpriseId>35566</enterpriseId>
<elementId>422</elementId>
<status>current</status>
<description>
<paragraph>The value of the username field
of the first/top-most Authorization header
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.</paragraph>
</description>
</record>
<record>
<name>sipSubscriptionEvent</name>
<dataType>string</dataType>
<enterpriseId>35566</enterpriseId>
<elementId>423</elementId>
<status>current</status>
<description>
<paragraph>The value of the Event header
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.</paragraph>
</description>
</record>
<record>
<name>sipSubscriptionState</name>
<dataType>string</dataType>
<enterpriseId>35566</enterpriseId>
<elementId>424</elementId>
<status>current</status>
<description>
<paragraph>The value of the Subscription-State header
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.</paragraph>
</description>
</record>
<record>
<name>sipExpires</name>
<dataType>unsigned32</dataType>
<enterpriseId>35566</enterpriseId>
<elementId>425</elementId>
<status>current</status>
<description>
<paragraph>The numeric value of the expires parameter of the
first/top-most Contact header of a REGISTER request
or response, or Subscription-State header of a SUBSCRIBE
or NOTIFY request or response, or the Expires header
if the expires parameter does not exist, as
received by the metering process.</paragraph>
</description>
</record>
<record>
<name>sipPVisitedNetworkID</name>
<dataType>string</dataType>
<enterpriseId>35566</enterpriseId>
<elementId>426</elementId>
<status>current</status>
<description>
<paragraph>The value of the first/top-most P-Visited-Network-ID
header as a UTF-8 string, escaped according to SIP rules as
received by the metering process.</paragraph>
</description>
</record>
<record>
<name>sipPAccessNetworkInfo</name>
<dataType>string</dataType>
<enterpriseId>35566</enterpriseId>
<elementId>427</elementId>
<status>current</status>
<description>
<paragraph>The value of the P-Access-Network-Info header
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.</paragraph>
</description>
</record>
<record>
<name>sipPChargingFunctionAddr</name>
<dataType>string</dataType>
<enterpriseId>35566</enterpriseId>
<elementId>428</elementId>
<status>current</status>
<description>
<paragraph>The value of the first/top-most
P-Charging-Function-Addresses header
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.</paragraph>
</description>
</record>
<record>
<name>sipPChargingVector</name>
<dataType>string</dataType>
<enterpriseId>35566</enterpriseId>
<elementId>429</elementId>
<status>current</status>
<description>
<paragraph>The value of the P-Charging-Vector header
as a UTF-8 string, escaped according to SIP rules as
received by the metering process.</paragraph>
</description>
</record>
</registry>
</registry>
]]></artwork></figure>
</section>
<section title="Example messages in base64">
<t>This section contains the example messages from this revision of this draft in base64 encoding, for ease of processing by automated tools.</t>
<t>The base templates are in this message:</t>
<t>AAoA/EzALZsAAAAAAAAwOQACAOwBAQARAUMACIGZAAQAAIruAAgABAAMAAQA
BwACAAsAAgAEAAGBkgABAACK7oGjAAEAAIrugZP//wAAiu6Blv//AACK7oGX
//8AAIrugZT//wAAiu6Blf//AACK7oGY//8AAIrugZ7//wAAiu6Bnf//AACK
7gECABEBQwAIgZkABAAAiu4ACAAEAAwABAAHAAIACwACAAQAAYGSAAEAAIru
gaMAAQAAiu6BnAACAACK7oGW//8AAIrugZf//wAAiu6BlP//AACK7oGV//8A
AIrugZj//wAAiu6Bnv//AACK7oGd//8AAIru</t>
<t>The extended 4to6 and 6to4 templates are in this message:</t>
<t>AAoB5EzALZsAAAAAAAAwOQACAdQBBQARAUMACIGZAAQAAIruAAgABAAcABAA
BwACAAsAAgAEAAGBkgABAACK7oGjAAEAAIrugZP//wAAiu6Blv//AACK7oGX
//8AAIrugZT//wAAiu6Blf//AACK7oGY//8AAIrugZ7//wAAiu6Bnf//AACK
7gEGABEBQwAIgZkABAAAiu4ACAAEABwAEAAHAAIACwACAAQAAYGSAAEAAIru
gaMAAQAAiu6BnAACAACK7oGW//8AAIrugZf//wAAiu6BlP//AACK7oGV//8A
AIrugZj//wAAiu6Bnv//AACK7oGd//8AAIruAQcAEQFDAAiBmQAEAACK7gAb
ABAADAAEAAcAAgALAAIABAABgZIAAQAAiu6BowABAACK7oGT//8AAIrugZb/
/wAAiu6Bl///AACK7oGU//8AAIrugZX//wAAiu6BmP//AACK7oGe//8AAIru
gZ3//wAAiu4BCAARAUMACIGZAAQAAIruABsAEAAMAAQABwACAAsAAgAEAAGB
kgABAACK7oGjAAEAAIrugZwAAgAAiu6Blv//AACK7oGX//8AAIrugZT//wAA
iu6Blf//AACK7oGY//8AAIrugZ7//wAAiu6Bnf//AACK7g==</t>
<t>The UAC registration in <xref target="sec-example-uacreg"/> is in this message:</t>
<t>AAoA2EzAO88AAAAAAAAwOQEBAGsAAAEpE2YTkwAAAAHGM2QBxjNkChPEE8QR
DAIPc2lwOmV4YW1wbGUuY29tAAAVc2lwOmFsaWNlQGV4YW1wbGUuY29tBTc2
eWhoFWY4MS1kNC1mNkBleGFtcGxlLmNvbQZjLXRyLTEAAQIAXQAAASkTZhUk
AAAAAcYzZArGM2QBE8QTxBEMAQDIAAAVc2lwOmFsaWNlQGV4YW1wbGUuY29t
BTc2eWhoFWY4MS1kNC1mNkBleGFtcGxlLmNvbQZjLXRyLTEA</t>
<t>The direct call in <xref target="sec-example-direct"/> is in this message:</t>
<t>AAoCGkzAPA8AAAAAAAAwOQEBAIgAAAEpE2YTkwAAACDGM2QBywBxARPEE8QR
BQIYc2lwOmJvYkBib2IxLmV4YW1wbGUubmV0E3NpcDpib2JAZXhhbXBsZS5u
ZXQAFXNpcDphbGljZUBleGFtcGxlLmNvbQU3NnloaBVmODItZDQtZjdAZXhh
bXBsZS5jb20HYy0xLXh0NgABAgB5AAABKRNmGKoAAAAgywBxAcYzZAETxBPE
EQUBALQTc2lwOmJvYkBleGFtcGxlLm5ldAhiLWluNi1pdRVzaXA6YWxpY2VA
ZXhhbXBsZS5jb20FNzZ5aGgVZjgyLWQ0LWY3QGV4YW1wbGUuY29tB2MtMS14
dDYAAQIAeQAAASkTZhz0AAAAIMsAcQHGM2QBE8QTxBEFAQDIE3NpcDpib2JA
ZXhhbXBsZS5uZXQIYi1pbjYtaXUVc2lwOmFsaWNlQGV4YW1wbGUuY29tBTc2
eWhoFWY4Mi1kNC1mN0BleGFtcGxlLmNvbQdjLTEteHQ2AAEBAJAAAAEpE2Yd
CAAAACDGM2QBywBxARPEE8QRAQIYc2lwOmJvYkBib2IxLmV4YW1wbGUubmV0
E3NpcDpib2JAZXhhbXBsZS5uZXQIYi1pbjYtaXUVc2lwOmFsaWNlQGV4YW1w
bGUuY29tBTc2eWhoFWY4Mi1kNC1mN0BleGFtcGxlLmNvbQdjLTEteHQ2AA==</t>
<t>The downstream branch call in <xref target="sec-example-branch"/> is in this message:</t>
<t>AAoE4UzAPEoAAAAAAAAwOQEBAH4AAAEpE2YTkwAAACvGM2QBxjNkChPEE8QR
BQETc2lwOmJvYkBleGFtcGxlLm5ldBNzaXA6Ym9iQGV4YW1wbGUubmV0ABVz
aXA6YWxpY2VAZXhhbXBsZS5jb20EYWwtMRJ0ci04N2hAZXhhbXBsZS5jb20A
BnMteC10cgECAGwAAAEpE2YUwQAAACvGM2QKxjNkARPEE8QRBQIAZBNzaXA6
Ym9iQGV4YW1wbGUubmV0ABVzaXA6YWxpY2VAZXhhbXBsZS5jb20EYWwtMRJ0
ci04N2hAZXhhbXBsZS5jb20ABnMteC10cgEBAIkAAAEpE2YYpgAAACvGM2QK
ywBxARPEE8QRBQIYc2lwOmJvYkBib2IxLmV4YW1wbGUubmV0E3NpcDpib2JA
ZXhhbXBsZS5uZXQAFXNpcDphbGljZUBleGFtcGxlLmNvbQRhbC0xEnRyLTg3
aEBleGFtcGxlLmNvbQZjLXgtdHIGcy14LXRyAQIAdgAAASkTZhlwAAAAK8sA
cQHGM2QKE8QTxBEFAQBkE3NpcDpib2JAZXhhbXBsZS5uZXQEYjEtMRVzaXA6
YWxpY2VAZXhhbXBsZS5jb20EYWwtMRJ0ci04N2hAZXhhbXBsZS5jb20GYy14
LXRyBnMteC10cgECAHYAAAEpE2YbyAAAACvLAHEBxjNkChPEE8QRBQEAtBNz
aXA6Ym9iQGV4YW1wbGUubmV0BGIxLTEVc2lwOmFsaWNlQGV4YW1wbGUuY29t
BGFsLTESdHItODdoQGV4YW1wbGUuY29tBmMteC10cgZzLXgtdHIBAgB2AAAB
KRNmHJgAAAArxjNkCsYzZAETxBPEEQUCALQTc2lwOmJvYkBleGFtcGxlLm5l
dARiMS0xFXNpcDphbGljZUBleGFtcGxlLmNvbQRhbC0xEnRyLTg3aEBleGFt
cGxlLmNvbQZjLXgtdHIGcy14LXRyAQIAdgAAASkTZiDwAAAAK8sAcQHGM2QK
E8QTxBEFAQDIE3NpcDpib2JAZXhhbXBsZS5uZXQEYjEtMRVzaXA6YWxpY2VA
ZXhhbXBsZS5jb20EYWwtMRJ0ci04N2hAZXhhbXBsZS5jb20GYy14LXRyBnMt
eC10cgECAHYAAAEpE2YhpAAAACvGM2QKxjNkARPEE8QRBQIAyBNzaXA6Ym9i
QGV4YW1wbGUubmV0BGIxLTEVc2lwOmFsaWNlQGV4YW1wbGUuY29tBGFsLTES
dHItODdoQGV4YW1wbGUuY29tBmMteC10cgZzLXgtdHIBAQCIAAABKRNmKKwA
AAArxjNkAcYzZAoTxBPEEQEBE3NpcDpib2JAZXhhbXBsZS5uZXQTc2lwOmJv
YkBleGFtcGxlLm5ldARiMS0xFXNpcDphbGljZUBleGFtcGxlLmNvbQRhbC0x
EnRyLTg3aEBleGFtcGxlLmNvbQZjLXgtdHIGcy14LXRyAQEAiAAAASkTZiis
AAAAK8YzZArLAHEBE8QTxBEBAhNzaXA6Ym9iQGV4YW1wbGUubmV0E3NpcDpi
b2JAZXhhbXBsZS5uZXQEYjEtMRVzaXA6YWxpY2VAZXhhbXBsZS5jb20EYWwt
MRJ0ci04N2hAZXhhbXBsZS5jb20GYy14LXRyBnMteC10cg==</t>
<t>The forked call in <xref target="sec-example-fork"/> is in this message:</t>
<t>AAoHjEzAPF0AAAAAAAAwOQEBAH4AAAEpE2YTkwAAACvGM2QBywBxyBPEE8QR
BQETc2lwOmJvYkBleGFtcGxlLm5ldBNzaXA6Ym9iQGV4YW1wbGUubmV0ABVz
aXA6YWxpY2VAZXhhbXBsZS5jb20EYTEtMRJ0ci04OGhAZXhhbXBsZS5jb20A
BnMtMS10cgECAGwAAAEpE2YUwQAAACvLAHHIxjNkARPEE8QRBQIAZBNzaXA6
Ym9iQGV4YW1wbGUubmV0ABVzaXA6YWxpY2VAZXhhbXBsZS5jb20EYTEtMRJ0
ci04OGhAZXhhbXBsZS5jb20ABnMtMS10cgEBAIkAAAEpE2YYpgAAACvLAHHI
ywBxARPEE8QRBQIYc2lwOmJvYkBib2IxLmV4YW1wbGUubmV0E3NpcDpib2JA
ZXhhbXBsZS5uZXQAFXNpcDphbGljZUBleGFtcGxlLmNvbQRhMS0xEnRyLTg4
aEBleGFtcGxlLmNvbQZjLTEtdHIGcy0xLXRyAQUAlQAAASkTZhqcAAAAK8sA
ccggAQ24AAAAAAAAAAAAAAAJE8QTxBEFAhhzaXA6Ym9iQGJvYjIuZXhhbXBs
ZS5uZXQTc2lwOmJvYkBleGFtcGxlLm5ldAAVc2lwOmFsaWNlQGV4YW1wbGUu
Y29tBGExLTESdHItODhoQGV4YW1wbGUuY29tBmMtMi10cgZzLTEtdHIBAgB2
AAABKRNmG8gAAAArywBxAcsAccgTxBPEEQUBAGQTc2lwOmJvYkBleGFtcGxl
Lm5ldARiMS0xFXNpcDphbGljZUBleGFtcGxlLmNvbQRhMS0xEnRyLTg4aEBl
eGFtcGxlLmNvbQZjLTEtdHIGcy0xLXRyAQgAggAAASkTZhz0AAAAKyABDbgA
AAAAAAAAAAAAAAnLAHHIE8QTxBEFAQBkE3NpcDpib2JAZXhhbXBsZS5uZXQE
YjItMhVzaXA6YWxpY2VAZXhhbXBsZS5jb20EYTEtMRJ0ci04OGhAZXhhbXBs
ZS5jb20GYy0yLXRyBnMtMS10cgEIAIIAAAEpE2YfTAAAACsgAQ24AAAAAAAA
AAAAAAAJywBxyBPEE8QRBQEAtBNzaXA6Ym9iQGV4YW1wbGUubmV0BGIyLTIV
c2lwOmFsaWNlQGV4YW1wbGUuY29tBGExLTESdHItODhoQGV4YW1wbGUuY29t
BmMtMi10cgZzLTEtdHIBAgByAAABKRNmIG4AAAArywBxyMYzZAETxBPEEQUC
ALQTc2lwOmJvYkBleGFtcGxlLm5ldAAVc2lwOmFsaWNlQGV4YW1wbGUuY29t
BGExLTESdHItODhoQGV4YW1wbGUuY29tBmMtMi10cgZzLTEtdHIBAgB2AAAB
KRNmIaQAAAArywBxyMYzZAETxBPEEQUCALQTc2lwOmJvYkBleGFtcGxlLm5l
dARiMS0xFXNpcDphbGljZUBleGFtcGxlLmNvbQRhMS0xEnRyLTg4aEBleGFt
cGxlLmNvbQZjLTEtdHIGcy0xLXRyAQIAdgAAASkTZiOYAAAAK8sAcQHLAHHI
E8QTxBEFAQDIE3NpcDpib2JAZXhhbXBsZS5uZXQEYjEtMRVzaXA6YWxpY2VA
ZXhhbXBsZS5jb20EYTEtMRJ0ci04OGhAZXhhbXBsZS5jb20GYy0xLXRyBnMt
MS10cgECAHYAAAEpE2YkYAAAACvLAHHIxjNkARPEE8QRBQIAyBNzaXA6Ym9i
QGV4YW1wbGUubmV0BGIxLTEVc2lwOmFsaWNlQGV4YW1wbGUuY29tBGExLTES
dHItODhoQGV4YW1wbGUuY29tBmMtMS10cgZzLTEtdHIBBQCVAAABKRNmJSkA
AAArywBxyCABDbgAAAAAAAAAAAAAAAkTxBPEEQMCGHNpcDpib2JAYm9iMi5l
eGFtcGxlLm5ldBNzaXA6Ym9iQGV4YW1wbGUubmV0ABVzaXA6YWxpY2VAZXhh
bXBsZS5jb20EYTEtMRJ0ci04OGhAZXhhbXBsZS5jb20GYy0yLXRyBnMtMS10
cgEIAH4AAAEpE2YoPwAAACsgAQ24AAAAAAAAAAAAAAAJywBxyBPEE8QRBQEB
5xNzaXA6Ym9iQGV4YW1wbGUubmV0ABVzaXA6YWxpY2VAZXhhbXBsZS5jb20E
YTEtMRJ0ci04OGhAZXhhbXBsZS5jb20GYy0yLXRyBnMtMS10cgEFAJUAAAEp
E2YqDwAAACvLAHHIIAENuAAAAAAAAAAAAAAACRPEE8QRAQIYc2lwOmJvYkBi
b2IyLmV4YW1wbGUubmV0E3NpcDpib2JAZXhhbXBsZS5uZXQAFXNpcDphbGlj
ZUBleGFtcGxlLmNvbQRhMS0xEnRyLTg4aEBleGFtcGxlLmNvbQZjLTItdHIG
cy0xLXRyAQgAfgAAASkTZiwxAAAAKyABDbgAAAAAAAAAAAAAAAnLAHHIE8QT
xBEDAQDIE3NpcDpib2JAZXhhbXBsZS5uZXQAFXNpcDphbGljZUBleGFtcGxl
LmNvbQRhMS0xEnRyLTg4aEBleGFtcGxlLmNvbQZjLTItdHIGcy0xLXRy</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:39:19 |