One document matched: draft-jennings-mmusic-adjacent-grouping-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace="yes" ?>
<?rfc rfcedstyle="no" ?>
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-jennings-mmusic-adjacent-grouping-04"
ipr="trust200902">
<front>
<title abbrev="Adjacent Media Grouping in SDP">Grouping of Adjacent Media
in the Session Description Protocol</title>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 408 421-9990</phone>
<email>fluffy@cisco.com</email>
</address>
</author>
<author fullname="Ali Begen" initials="A." surname="Begen">
<organization>Cisco</organization>
<address>
<postal>
<street>181 Bay Street</street>
<city>Toronto</city>
<region>ON</region>
<code>M5J 2T3</code>
<country>Canada</country>
</postal>
<email>abegen@cisco.com</email>
</address>
</author>
<date day="11" month="July" year="2011" />
<abstract>
<t>Applications such as multi-screen video conferencing systems or
advertisement boards often have multiple audio and video streams that
are organized to be rendered side by side or in a grid. This
specification uses the RFC 5888 Grouping Framework to define new
semantics for grouping the media streams to be rendered side by side or
in a grid and indicating their relative ordering.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>There are many situations where applications create media streams
that are meant do be rendered adjacent to each other. A common example
is a multi-screen video conferencing system. Other examples are several
video monitors placed side by side to display signs, and audio streams
from a linear array of microphones, or a grid of display for monitoring
security cameras. The Session Description Protocol (SDP) <xref
target="RFC4566"></xref> allows negotiation of multiple media streams
but does not have a way to describe the ordering information to indicate
which media stream is adjacent to which one.</t>
<t>This specification introduces new grouping semantics, using the SDP
Grouping Framework defined in <xref target="RFC5888"></xref>, that
indicate media streams are adjacent, and the adjacency order is defined
by the order of the entries in the group.</t>
</section>
<section title="Terminology">
<t>This specification uses all the terms defined in <xref
target="RFC5888"></xref> and will not make sense unless you have read
<xref target="RFC5888"></xref>. The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in <xref target="RFC2119"></xref>.</t>
</section>
<section title="Adjacent Media Grouping">
<section title=""ADJ" Grouping Semantics">
<t>This specification defines new grouping semantics of "ADJ" that
indicate the media streams in this group are meant to be played or
displayed adjacently. Furthermore, the order of media streams in the
group indicates the adjacency order. This only indicates the order the
device sending the SDP believes is the preferred way to display the
media described in this SDP. </t>
<t>N media streams could be in a linear horizontal layout, in which
case we use a grid size of 1 x N. Alternatively, N media streams could
be in a linear vertical layout, in which case we use a grid size of N
x 1. In these configurations, the first stream in the group MUST be
the one corresponding to the left most and top most output unit,
respectively. In a more general grid size of N x M, we can group K
(where K <= N x M) media streams starting from the one
corresponding to the top-left output unit, and then doing a continuous
horizontal scanning of the grid row by row (i.e., scanning first the
top row from left to right, and then the second row from left to
right, and so on). When we say left most, we mean from the point of
view of the person looking at the display.</t>
<t>To indicate the dimensions of the layout grid in an SDP
description, we define a new session-level attribute. The ABNF syntax
<xref target="RFC5234"></xref> for the new attribute is as
follows:</t>
<figure>
<artwork><![CDATA[
media-grid-dims-line = "a=media-grid-dims:" [gridname]
%20 rows "x" columns CRLF
gridname = token ; token is defined in RFC 4566
rows = %x31-39 *DIGIT
columns = %x31-39 *DIGIT
namechar = token // as defined in
]]></artwork>
</figure>
<t>The parameters 'rows' and 'columns' indicate the number of rows and
columns for this media grid. They both MUST be an integer larger than
zero. The gridname indicates a name for this grid. If there are multiple
media-grid-dims attribute in the SDP, each MUST have a unique
gridname. </t>
<t>If the 'media-grid-dims' attribute does not exist in the SDP
description, then a 1 x N horizontal linear layout MUST be assumed.</t>
<t>Per <xref target="RFC5888"></xref>, there MAY be more than one
adjacent media group in a single SDP description. The 'media-grid-dims'
attribute MUST come before the group or sssrc-group that it applies
to. An group or SSRC-group for an ADJ group MUST use the first
'media-grid-dims' attribute found above it in the SDP. </t>
</section>
<section title="Grouping for SSRC-Multiplexed RTP Streams">
<t><xref target="RFC5576"></xref> defines an SDP media-level
attribute, called 'ssrc-group', for grouping the RTP streams that are
SSRC multiplexed and carried in the same RTP session. The grouping is
based on the SSRC identifiers. Since SSRC-multiplexed RTP streams are
defined in the same "m" line, the 'group' attribute cannot be
used.</t>
<t>This section specifies how adjacency is described with
SSRC-multiplexed streams using the 'ssrc-group' attribute <xref
target="RFC5576"></xref>.</t>
<t>The semantics of "ADJ" for the 'ssrc-group' attribute are the same
as the one defined for the 'group' attribute except that the SSRC
identifiers are used to designate the adjacency grouping associations:
a=ssrc-group:ADJ *(SP ssrc-id) <xref target="RFC5576"></xref>.</t>
<t>The SSRC identifiers for the RTP streams that are carried in the
same RTP session MUST be unique per <xref target="RFC3550"></xref>.
However, the SSRC identifiers are not guaranteed to be unique among
different RTP sessions. Thus, the 'ssrc-group' attribute MUST only be
used at the media level <xref target="RFC5576"></xref>.</t>
</section>
<section title="SDP Offer/Answer Model Considerations">
<t>When offering adjacent media grouping using SDP in an Offer/Answer
model <xref target="RFC3264"></xref>, the following considerations
apply.</t>
<t>A node that is receiving an offer from a sender may or may not
understand line grouping. It is also possible that the node
understands line grouping but it does not understand the "ADJ"
semantics. From the viewpoint of the sender of the offer, these cases
are indistinguishable.</t>
<t>When a node is offered a session with the "ADJ" grouping semantics
but it does not support line grouping or the adjacent media grouping
semantics, as per <xref target="RFC5888"></xref>, the node responds to
the offer either (1) with an answer that ignores the grouping
attribute or (2) with a refusal to the request (e.g., 488 Not
Acceptable Here or 606 Not Acceptable in SIP).</t>
<t>In the first case, the original sender of the offer must send a new
offer without any grouping. In the second case, if the sender of the
offer still wishes to establish the session, it should retry the
request with an offer without the adjacent media grouping. This
behavior is specified in <xref target="RFC5888"></xref>.</t>
<t>The offer contains the sender's suggested layout. The answer MAY
contain the suggested layout of the streams that the system sending the
answer will be sending to the system that sent the offer.</t>
</section>
</section>
<section title="SDP Examples">
<t>This section provides SDP examples showing how to use the adjacent
media grouping.</t>
<section title="Horizontal Layout">
<t>A video system with two screens and one audio channels sends a SIP
offer. The following figure shows a top-down view of the room with the
three screen system that is sending the SIP offer. Screen A is the
left most screen for the user in this room but should be displayed as
the rightmost screen for the user at the far end that will be viewing
the video.</t>
<figure>
<artwork><![CDATA[
Screen A Screen B
[----------][------------]
User
]]></artwork>
</figure>
<t>Assume the SDP mid values for the screens are sa and sb, for
Screens A and B respectively. The offer contains the following in the
SDP:</t>
<figure>
<artwork><![CDATA[ a=group:ADJ sb sa
]]></artwork>
</figure>
<t>The complete SDP in the offer could look like:</t>
<figure>
<artwork><![CDATA[
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
a=group:ADJ sb sa
t=0 0
m=audio 49101 RTP/AVP 101
a=rtpmap:101 PCMU/8000
a=mid:sm
m=video 49111 RTP/AVP 111
a=rtpmap:111 H261/90000
a=mid:sa
m=video 49112 RTP/AVP 112
a=rtpmap:112 H261/90000
a=mid:sb
]]></artwork>
</figure>
<t>There might be other media streams, such as presentation video,
that are not part of any "ADJ" group.</t>
<t>As a note to implementors, consider the case where each screen had
two media flows that were in the same FID group. In this case all the
media streams are still listed in the ADJ group and the order of two
streams in the same FID group can be arbitrarily picked as they will
be displayed on the same device.</t>
</section>
<section title="Grid Layout">
<t> The following SDP is for a system providing 6 video streams. Four of
these streams are arranged as a wall of screens on a 2 by 2 grid
while the other 2 streams should be shown separate but still arranged
side by side. </t>
<figure>
<artwork><![CDATA[
v=0
o=bob 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
a=media-grid-dims:A 2x2
a=group:ADJ 1 2 3 4
a=media-grid-dims:B 2x1
a=group:ADJ 5 6
t=0 0
m=video 49101 RTP/AVP 101
a=rtpmap:101 H261/90000
a=mid:1
m=video 49102 RTP/AVP 102
a=rtpmap:102 H261/90000
a=mid:2
m=video 49103 RTP/AVP 103
a=rtpmap:103 H261/90000
a=mid:3
m=video 49104 RTP/AVP 104
a=rtpmap:104 H261/90000
a=mid:4
m=video 49105 RTP/AVP 105
a=rtpmap:105 H261/90000
a=mid:5
m=video 49106 RTP/AVP 106
a=rtpmap:106 H261/90000
a=mid:6
]]></artwork>
</figure>
<t></t>
</section>
<section title="Layout with SSRC multiplex">
<t>The following SDP is for a system providing 2 video streams using
SSRC multiplexing. In this example, the SSRC for one stream is 12345
while for the other it is 67890. </t>
<figure>
<artwork><![CDATA[
v=0
o=bob 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
a=ssrc-group:ADJ 12345 67890
t=0 0
m=video 49170 RTP/AVP 96
a=rtpmap:96 H264/90000
]]></artwork>
</figure>
<t></t>
</section>
</section>
<section title="Security Considerations">
<t>Like all SDP, integrity of this information is important. When
carrying SDP in SIP, mechanisms such as Transport Layer Security (TLS)
can provide hop by hop confidentiality and integrity. The receiver
SHOULD do an integrity check on SDP and follow the security
considerations of SDP <xref target="RFC4566"></xref> to trust only SDP
from trusted sources. End-to-end integrity can be provided by <xref
target="RFC4474"></xref>.</t>
</section>
<section title="IANA Considerations">
<t>Note to RFC Editor: Please replace [RFC-AAAA] with the RFC number for
this specification.</t>
<section title="Registration of SDP Attributes">
<t>This document registers a new attribute name in SDP.</t>
<figure>
<artwork><![CDATA[
SDP Attribute ("att-field"):
Attribute name: media-grid-dims
Long form: 2-D media grid dimensions
Type of name: att-field
Type of attribute: Session level
Subject to charset: No
Purpose: Specifies the dimensions for a media grid
Reference: [RFC-AAAA]
Values: See [RFC-AAAA]
]]></artwork>
</figure>
</section>
<section title="Registration of Grouping Semantics">
<t>This document, following the Standards Action policy from <xref
target="RFC5226"></xref>, registers the following semantics with IANA
in the "Semantics for the "group" SDP Attribute" registry under SDP
Parameters:</t>
<figure>
<artwork><![CDATA[
Semantics Token Reference
--------------------------------- ----- -----------
Adjacent Media ADJ [RFC-AAAA]
]]></artwork>
</figure>
<t></t>
<t>This document also registers the following semantics with IANA in
"Semantics for the 'ssrc-group' SDP Attribute" registry under SDP
Parameters:</t>
<t><figure>
<preamble></preamble>
<artwork><![CDATA[
Token Semantics Reference
------- ----------------------------- ---------
ADJ Adjacent Media [RFC-AAAA]
]]></artwork>
</figure></t>
<t></t>
</section>
</section>
<section title="Acknowledgments">
<t>The authors would like to thank Flemming Andreasen, Allyn Romanow, Roni
Even, Hakon Dahle, Ingemar Johansson, Paul Kyzivat, Peter Musgrave,
Christer Holmberg, Magnus Westerlund, Stephen Botzko, and Geir Arne
Sandbakken for their review comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC5888">
<front>
<title>The Session Description Protocol (SDP) Grouping
Framework</title>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization></organization>
</author>
<author fullname="H. Schulzrinne" initials="H."
surname="Schulzrinne">
<organization></organization>
</author>
<date month="June" year="2010" />
<abstract>
<t>In this specification, we define a framework to group "m" lines
in the Session Description Protocol (SDP) for different purposes.
This framework uses the "group" and "mid" SDP attributes, both of
which are defined in this specification. Additionally, we specify
how to use the framework for two different purposes: for lip
synchronization and for receiving a media flow consisting of
several media streams on different transport addresses. This
document obsoletes RFC 3388. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5888" />
<format octets="43924"
target="http://www.rfc-editor.org/rfc/rfc5888.txt" type="TXT" />
</reference>
<reference anchor="RFC4566">
<front>
<title>SDP: Session Description Protocol</title>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization></organization>
</author>
<author fullname="V. Jacobson" initials="V." surname="Jacobson">
<organization></organization>
</author>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization></organization>
</author>
<date month="July" year="2006" />
<abstract>
<t>This memo defines the Session Description Protocol (SDP). SDP
is intended for describing multimedia sessions for the purposes of
session announcement, session invitation, and other forms of
multimedia session initiation. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4566" />
<format octets="108820"
target="http://www.rfc-editor.org/rfc/rfc4566.txt" type="TXT" />
</reference>
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997" />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document: <list style="empty">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119.</t>
</list></t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
<format octets="4723"
target="http://www.rfc-editor.org/rfc/rfc2119.txt" type="TXT" />
<format octets="17491"
target="http://xml.resource.org/public/rfc/html/rfc2119.html"
type="HTML" />
<format octets="5777"
target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"
type="XML" />
</reference>
<reference anchor="RFC5234">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization></organization>
</author>
<author fullname="P. Overell" initials="P." surname="Overell">
<organization></organization>
</author>
<date month="January" year="2008" />
<abstract>
<t>Internet technical specifications often need to define a formal
syntax. Over the years, a modified version of Backus-Naur Form
(BNF), called Augmented BNF (ABNF), has been popular among many
Internet specifications. The current specification documents ABNF.
It balances compactness and simplicity with reasonable
representational power. The differences between standard BNF and
ABNF involve naming rules, repetition, alternatives,
order-independence, and value ranges. This specification also
supplies additional rule definitions and encoding for a core
lexical analyzer of the type common to several Internet
specifications. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="68" />
<seriesInfo name="RFC" value="5234" />
<format octets="26359"
target="http://www.rfc-editor.org/rfc/rfc5234.txt" type="TXT" />
</reference>
<reference anchor="RFC5576">
<front>
<title>Source-Specific Media Attributes in the Session Description
Protocol (SDP)</title>
<author fullname="J. Lennox" initials="J." surname="Lennox">
<organization></organization>
</author>
<author fullname="J. Ott" initials="J." surname="Ott">
<organization></organization>
</author>
<author fullname="T. Schierl" initials="T." surname="Schierl">
<organization></organization>
</author>
<date month="June" year="2009" />
<abstract>
<t>The Session Description Protocol (SDP) provides mechanisms to
describe attributes of multimedia sessions and of individual media
streams (e.g., Real-time Transport Protocol (RTP) sessions) within
a multimedia session, but does not provide any mechanism to
describe individual media sources within a media stream. This
document defines a mechanism to describe RTP media sources, which
are identified by their synchronization source (SSRC) identifiers,
in SDP, to associate attributes with these sources, and to express
relationships among sources. It also defines several source-level
attributes that can be used to describe properties of media
sources. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5576" />
<format octets="40454"
target="http://www.rfc-editor.org/rfc/rfc5576.txt" type="TXT" />
</reference>
<reference anchor="RFC3264">
<front>
<title>An Offer/Answer Model with Session Description Protocol
(SDP)</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization></organization>
</author>
<author fullname="H. Schulzrinne" initials="H."
surname="Schulzrinne">
<organization></organization>
</author>
<date month="June" year="2002" />
<abstract>
<t>This document defines a mechanism by which two entities can
make use of the Session Description Protocol (SDP) to arrive at a
common view of a multimedia session between them. In the model,
one participant offers the other a description of the desired
session from their perspective, and the other participant answers
with the desired session from their perspective. This offer/answer
model is most useful in unicast sessions where information from
both participants is needed for the complete view of the session.
The offer/answer model is used by protocols like the Session
Initiation Protocol (SIP). [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3264" />
<format octets="60854"
target="http://www.rfc-editor.org/rfc/rfc3264.txt" type="TXT" />
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC4474">
<front>
<title>Enhancements for Authenticated Identity Management in the
Session Initiation Protocol (SIP)</title>
<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization></organization>
</author>
<author fullname="C. Jennings" initials="C." surname="Jennings">
<organization></organization>
</author>
<date month="August" year="2006" />
<abstract>
<t>The existing security mechanisms in the Session Initiation
Protocol (SIP) are inadequate for cryptographically assuring the
identity of the end users that originate SIP requests, especially
in an interdomain context. This document defines a mechanism for
securely identifying originators of SIP messages. It does so by
defining two new SIP header fields, Identity, for conveying a
signature used for validating the identity, and Identity-Info, for
conveying a reference to the certificate of the signer. [STANDARDS
TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4474" />
<format octets="104952"
target="http://www.rfc-editor.org/rfc/rfc4474.txt" type="TXT" />
</reference>
<reference anchor="RFC5226">
<front>
<title>Guidelines for Writing an IANA Considerations Section in
RFCs</title>
<author fullname="T. Narten" initials="T." surname="Narten">
<organization></organization>
</author>
<author fullname="H. Alvestrand" initials="H." surname="Alvestrand">
<organization></organization>
</author>
<date month="May" year="2008" />
<abstract>
<t>Many protocols make use of identifiers consisting of constants
and other well-known values. Even after a protocol has been
defined and deployment has begun, new values may need to be
assigned (e.g., for a new option type in DHCP, or a new encryption
or authentication transform for IPsec). To ensure that such
quantities have consistent values and interpretations across all
implementations, their assignment must be administered by a
central authority. For IETF protocols, that role is provided by
the Internet Assigned Numbers Authority (IANA).</t><t>
In order for IANA to manage a given namespace prudently, it needs
guidelines describing the conditions under which new values can be
assigned or when modifications to existing values can be made. If
IANA is expected to play a role in the management of a namespace,
IANA must be given clear and concise instructions describing that
role. This document discusses issues that should be considered in
formulating a policy for assigning values to a namespace and
provides guidelines for authors on the specific text that must be
included in documents that place demands on
IANA.</t><t> This document obsoletes RFC 2434. This
document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26" />
<seriesInfo name="RFC" value="5226" />
<format octets="66160"
target="http://www.rfc-editor.org/rfc/rfc5226.txt" type="TXT" />
</reference>
<reference anchor="RFC3550">
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author fullname="H. Schulzrinne" initials="H."
surname="Schulzrinne">
<organization></organization>
</author>
<author fullname="S. Casner" initials="S." surname="Casner">
<organization></organization>
</author>
<author fullname="R. Frederick" initials="R." surname="Frederick">
<organization></organization>
</author>
<author fullname="V. Jacobson" initials="V." surname="Jacobson">
<organization></organization>
</author>
<date month="July" year="2003" />
<abstract>
<t>This memorandum describes RTP, the real-time transport
protocol. RTP provides end-to-end network transport functions
suitable for applications transmitting real-time data, such as
audio, video or simulation data, over multicast or unicast network
services. RTP does not address resource reservation and does not
guarantee quality-of- service for real-time services. The data
transport is augmented by a control protocol (RTCP) to allow
monitoring of the data delivery in a manner scalable to large
multicast networks, and to provide minimal control and
identification functionality. RTP and RTCP are designed to be
independent of the underlying transport and network layers. The
protocol supports the use of RTP-level translators and mixers.
Most of the text in this memorandum is identical to RFC 1889 which
it obsoletes. There are no changes in the packet formats on the
wire, only changes to the rules and algorithms governing how the
protocol is used. The biggest change is an enhancement to the
scalable timer algorithm for calculating when to send RTCP packets
in order to minimize transmission in excess of the intended rate
when many participants join a session simultaneously.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="64" />
<seriesInfo name="RFC" value="3550" />
<format octets="259985"
target="http://www.rfc-editor.org/rfc/rfc3550.txt" type="TXT" />
<format octets="630740"
target="http://www.rfc-editor.org/rfc/rfc3550.ps" type="PS" />
<format octets="504117"
target="http://www.rfc-editor.org/rfc/rfc3550.pdf" type="PDF" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:57:46 |