Internet DRAFT - draft-westerlund-avtext-rtcp-sdes-srcname
draft-westerlund-avtext-rtcp-sdes-srcname
Network Working Group M. Westerlund
Internet-Draft B. Burman
Intended status: Standards Track Ericsson
Expires: April 24, 2014 October 21, 2013
RTCP Source Description Item SRCNAME to Label Individual Media Sources
draft-westerlund-avtext-rtcp-sdes-srcname-03
Abstract
This document defines a new Source Description (SDES) item called
SRCNAME, which uniquely identifies a single media source, like a
camera or a microphone. It also enables identification of the
encoding to support when multiple ones are produced. That way anyone
receiving the SDES information from a set of interlinked RTP sessions
can determine which SSRCs are logically related to the same media
source and encoding. In addition the new SDES item is also defined
for usage with both a header extension and with the SDP source
specific media attribute ("a=ssrc"). Enabling an end-point to
receive the SRCNAME with the relevant RTP packets, as well as RTCP,
or learn the source bindings through signalling, ahead of receiving
RTP and RTCP packets.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Westerlund & Burman Expires April 24, 2014 [Page 1]
Internet-Draft RTCP SDES SRCNAME October 2013
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. SRCNAME Format . . . . . . . . . . . . . . . . . . . . . . 6
4.2. SDES Item SRCNAME . . . . . . . . . . . . . . . . . . . . 7
4.3. SRCNAME in SDP . . . . . . . . . . . . . . . . . . . . . . 7
4.4. SRCNAME as RTP Header Extension . . . . . . . . . . . . . 8
5. Usage with the Offer/Answer Model . . . . . . . . . . . . . . 8
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 9
7. Relation to Application Token . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Westerlund & Burman Expires April 24, 2014 [Page 2]
Internet-Draft RTCP SDES SRCNAME October 2013
1. Introduction
This specification defines a new RTP/RTCP [RFC3550] Source
Description (SDES) item called Source Name (SRCNAME). There exist
different use cases, including simulcast and scalable encoding, where
a sender transmit multiple RTP packet streams containing full or
partial encodings of the same media source. This include multiple
independent encodings, where it is desirable to identify the
different encodings. These different packet streams needs to be
correctly associated with media sources and encodings in an receiver
so that they correctly use the packet streams.
The proposed solution provides the RTP packet streams (SSRCs) with
identities for both the media source and the specific encoding. The
identification is done by creating a RTCP SDES item, SRCNAME, by
combing a media source identifier and an encoding identifier
separated by a full stop ("."). The SRCNAME can be sent periodically
in RTCP SDES packets to enable joiners to receive the information
within some time period from when they join. The SRCNAME is also
proposed to be sent in an RTP header extension for SDES items
[I-D.westerlund-avtext-sdes-hdr-ext] when it is desirable to speed up
reception. For example by transmitting the SRCNAME in the first N
RTP packets when a new SSRC joins an RTP session. Finally the
SRCNAME can be associated with the SSRC in signalling, and source
specific attribute is provided for this purpose.
2. Definitions
2.1. Requirements Language
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 [RFC2119].
2.2. Terminology
This document uses terminology defined in "A Taxonomy of Grouping
Semantics and Mechanisms for Real-Time Transport Protocol (RTP)
Sources" [I-D.lennox-raiarea-rtp-grouping-taxonomy] . In particular
the following definitions:
o Media Source
o Packet Stream
o Media Encoder
Westerlund & Burman Expires April 24, 2014 [Page 3]
Internet-Draft RTCP SDES SRCNAME October 2013
o Encoded Stream
o Dependent Stream
o Participant
o End point
3. Motivation
In RTP Applications where an end-point has more than one Media Source
in a particular RTP session there can exist need to provide these
media sources with an identifier. One reason is to be able to
explicitly track it across any SSRC collisions with resulting SSRC
changes. Another reason is when there exist multiple RTP Packet
Streams (SSRC) associated with that particular media source.
Especially in RTP sessions where multiple media sources are
simultaneously transmitted. This document focus on the cases that
results in multiple packet streams due to the encoding process.
Simulcast [I-D.westerlund-avtcore-rtp-simulcast] as referred to in
this document is the process when communication participant provides
a media source in multiple encodings using multiple media encoders
with different configurations. These different encoded streams are
then simultaneously transmitted using RTP to a receiver or a group of
receivers. The receiver(s) need two things; First to determine which
of the received packet streams (SSRCs) carries which media source,
and thus determining the different media sources and secondly what
alternative representations of each media source that exist. This
can be accomplished using an identifier to refer to a particular
encoding of a media source.
Scalable encoding is performed by some few media encoders, with the
prime example being H.264 Scalable Video Codec [RFC6190]. A scalable
media codec produces one or more base layers, i.e. an encoded stream,
and additionally one or more enhancement layers that are dependent on
the base layer as well as selected other enhancement layers, these
called dependent streams. The encoded and dependent streams can be
sent using multiple RTP packet streams, called multi-stream
transmission (MST). Thus explicit information are required for which
media source a particular packet stream (SSRC) are containing,
independent if it is the encoded or dependent stream. In cases where
one uses multiple base layers, the encoding identifier can be used to
provide RTP/RTCP level identification of the sub-groups of packet
streams that form an independent dependency tree. The detailed
dependency information between the encoded streams and dependent
streams are present in meta data information objects (SEI messages)
Westerlund & Burman Expires April 24, 2014 [Page 4]
Internet-Draft RTCP SDES SRCNAME October 2013
that are included inside the RTP payloads for SVC [RFC6190].
By providing media source and encoding identity information on RTP
and RTCP level we enable or improve usages that prior has been
impractical or sub-optimal:
a. A multi-party sessions where the media sources dynamically join
and leave and the central media node is source projection mixer.
A large conference with some participant churn, in this case to
rely solely on a signalling based solution can be problematic, as
each signalling session between the conference and all the
participants needs to be updated, for example using SIP, each
time a participant joins or leaves. Thus enabling RTP/RTCP level
information enables the joining participant's flows to be
explicitly indicated as new media sources and alternative
representations on RTP/RTCP level and thus correctly handled.
b. Multicast or broadcast situations where session configuration
information is provided ahead of the session, and the exact set
of media sources and their identifies can't be determined and
assigned ahead of time.
c. To optimize the away the need for buffering or holding
transmission in centralized mixer cases when there is some delay
on the signalling channel. When a media source is added and the
information is provided using signalling only, then a receiver
that hasn't gotten the signalling yet, needs to either buffer or
discard received media until the signalling arrives,
alternatively, the sender needs to hold the transmission until
the receiver have confirmed reception of signalling.
d. By providing this information in the RTP/RTCP also enables third
party monitoring of the RTP/RTCP streams to work better as the
stream relations are made clear.
It is important to note that a particular RTP packet stream's role in
a communication application can be quite independent to which media
source and the particular encoding the packet stream is. Although
the media source and encoding is sufficient information in some use
cases, there are other cases where additional information about the
current role of packet stream or set of streams are required.
Further discussion of this in Section 7.
SRCNAME extends and complement the existing solutions using SDP Media
Description grouping [RFC5888], or SSRC grouping within a Media
Description in SDP [RFC5576] or implicit or heuristic based mapping
of packet streams between or within RTP sessions. SRCNAME enables
explicit identity information at RTP/RTCP level in a form that are
Westerlund & Burman Expires April 24, 2014 [Page 5]
Internet-Draft RTCP SDES SRCNAME October 2013
unique across the whole communication session, usable to create
relationships on RTP/RTCP level independent if one or more RTP
session is used, independent on how the packet streams are
distributed over those RTP sessions and how many media sources an
end-point have.
4. Solution
This section defines the SRCNAME identifier format and its usage as
RTCP SDES item [RFC3550], registers it as an SDES item possible to
use in the RTP header extension for SDES items
[I-D.westerlund-avtext-sdes-hdr-ext], and in a source specific SDP
attribute [RFC5576] as well.
4.1. SRCNAME Format
The SRCNAME MUST fulfill the requirements Section 6.5 in RTP
[RFC3550] puts on SDES item values in general. These requirements is
that it is a UTF-8 [RFC3629] text string that have a maximum length
of 255 bytes.
In addition, there are format restrictions to accommodate the
separation of the Media Source ID and the encoding ID part, as
described by the following ABNF [RFC5234]:
media-source-id = 1*(%x01-09 / %x0B-0C / %x0E-1F / %x21-2D / %x2F-FF)
encoding-id = media-source-id *(%x2E media-source-id)
; Same as RFC 4566 "byte-string"
; except for space and the "." separator
srcname-content = media-source %x2E encoding-id
Figure 1: SRCNAME Format ABNF
Note, the format do allow multiple "." separators, but only as part
of the encoding ID.
The media source identifier is identifying a media source (as defined
by section 2.1.4 of [I-D.lennox-raiarea-rtp-grouping-taxonomy]).
Each media source ID MUST be unique when combined with the CNAME.
Note that if one intended to byte compare the combination of CNAME
and media-source-id then one need to pad the CNAME to full 255 bytes
with a common pattern prior to concatenation and comparison.
The encoding-id identifies a particular media encoder (Section 2.1.6
in [I-D.lennox-raiarea-rtp-grouping-taxonomy]) and its set of
Westerlund & Burman Expires April 24, 2014 [Page 6]
Internet-Draft RTCP SDES SRCNAME October 2013
produced encoded or dependent streams (as defined per section 2.1.7
and 2.1.8 in [I-D.lennox-raiarea-rtp-grouping-taxonomy]
respectively). The encoding-id MUST be unique in the context of the
CNAME and the media source ID.
By require uniqueness scoped by CNAME we simplify the creation of
unique identifiers and reduce the overhead for the inclusion of
SRCNAME. As the CNAME defines the scope of a single synchronization
context, commonly a single host will be responsible for assigning
media source and encoding ID to media sources and their encodings. A
common case will be for having a single character media source ID
followed by stop and then another single character encoding ID, e.g.
"a.2".
4.2. SDES Item SRCNAME
Distributing the SRCNAME using a RTCP Source Descriptions (SDES) item
are a method that should work with all RTP topologies (assuming that
any intermediary node is supporting this item) and existing RTP
extensions. Thus, a new SDES item called SRCNAME are defined. That
way, anyone receiving the SDES information from a set of interlinked
RTP sessions or SSRCs in a single session can determine the SRCNAME
associated with each SSRC.
The SDES SRCNAME item follows the same format as the other SDES items
defined in RTP [RFC3550]:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRCNAME=TBA1 | length | source name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SDES SRCNAME Format
The source name field MUST follow the above (Section 4.1) srcname-
content definition.
When using the SRCNAME SDES item, it is of equally importance with
CNAME. Thus, SRCNAME is RECOMMENDED to be included in all full
compound RTCP packets being sent. It MAY also be included in non-
compound packets in cases where the implementation believes that
there might be new receivers needing the information.
4.3. SRCNAME in SDP
"Source-Specific Media Attributes in the Session Description Protocol
(SDP)" [RFC5576] defines a way of declaring attributes for SSRC in
Westerlund & Burman Expires April 24, 2014 [Page 7]
Internet-Draft RTCP SDES SRCNAME October 2013
each RTP session in SDP. With a new SDES item, it is possible to use
this framework to define how SRCNAME can also be provided in the SDP
for each SSRC in each RTP session, thus enabling an end-point to
declare and learn the source bindings ahead of receiving RTP/RTCP
packets.
Hence, we define a new SDP source attribute called srcname with the
following structure:
a=ssrc:<ssrc-id> srcname:<srcname>
The srcname value MUST be identical to the SRCNAME value the media
sender will send in the SDES SRCNAME item in the SDES RTCP packets.
Formal ABNF syntax [RFC5234] for the "srcname" attribute:
srcname-attr = "srcname:" srcname
srcname = srcname-content
attribute =/ srcname-attr
; The definition of "attribute" is in RFC 4566.
Figure 3: SRCNAME Attribute ABNF
When used in SDP, srcname-content MUST use ISO 10646 in UTF-8
encoding, and MUST be independent of any "a=charset".
4.4. SRCNAME as RTP Header Extension
In cases when timely deliver of the SRCNAME is required, for example
when adding a new SSRC to an RTP session, or when new receiver joins
a multiparty RTP session, then the SRCNAME can be included in the RTP
header extension for SDES items [I-D.westerlund-avtext-sdes-hdr-ext].
The RTP header extension for SDES items
[I-D.westerlund-avtext-sdes-hdr-ext] is functioning for any SDES
item, but do require new SDES items to register its URN identifier.
This is done below in the IANA section (Section 8).
5. Usage with the Offer/Answer Model
The SDP offer/answer procedures for a=ssrc are specified in Source-
Specific Media Attributes in the Session Description Protocol (SDP)
[RFC5576]. The SDP offer/answer procedures for a=exthdr are
specified in A General Mechanism for RTP Header Extensions [RFC5285].
Westerlund & Burman Expires April 24, 2014 [Page 8]
Internet-Draft RTCP SDES SRCNAME October 2013
6. Backward Compatibility
Clients not supporting SRCNAME will not have the possibility to bind
different streams to a specific media source, since they will not
understand the SRCNAME SDES item or the RTP header extension.
However, sending SRCNAME SDES items to a client not supporting it
should not impose any problems since all clients should be prepared
that new SDES items may be specified according to RTP [RFC3550].
According to the definition of SDP attributes in SDP: Session
Description Protocol [RFC4566], if an attribute is received that is
not understood, it MUST be ignored by the receiver. So a receiver
not supporting the a=ssrc attribute will simply ignore it.
Source-Specific Media Attributes in the Session Description Protocol
(SDP) [RFC5576] defines rules of how new source attributes should be
registered, which means that a receiver supporting RFC 5576 should be
prepared that new source attributes may be defined. This means that
a user supporting some of the source attributes should not have any
problems when the user receives an SDP with unknown source
attributes.
RTP header extension will only be used when successfully negotiated
in SDP, which requires support in both sender and receiver.
7. Relation to Application Token
There exists a proposal for an application token SDES item
[I-D.even-mmusic-application-token], who's purpose is to map SSRCs to
application purposes or usages of the RTP packet stream. In this
section the similarities and differences are discussed to arrive at
the conclusion that for a number of cases both will be required to
enable powerful applications.
The APPID is flexible in that it allows applications or specific
usage of RTP to define how they map the APPID tokens to particular
purpose or usages of the streams. This is clearly intended to
provide flexibility. For example one APPID tokens can have meanings
such as Presentation stream, main talker, video thumbnail number 3,
FEC stream for Audio etc. Such roles can be transient in their
behavior. For example main talker is a role that moves around in a
multiparty communication session based on who is the current speaker,
based on voice activity, or a conference management interface. Thus,
the APPID token for this role will be moved between different SSRCs.
This is in strong contrast with SRCNAME which identifies a particular
media source and encoding. That is not expected to move around,
other than in cases of SSRC collisions, when they enable tracking
Westerlund & Burman Expires April 24, 2014 [Page 9]
Internet-Draft RTCP SDES SRCNAME October 2013
across this event. RTP Mixers that perform mixes or switching
between input sources, are them selves having conceptual media
sources, which will have stable identities.
A case that makes it clear that SRCNAME identification may benefit
from having additional role tokens is the case of having a source
projection mixer using simulcast from clients to mixers. From the
perspective of a receiver, there will be multiple SSRCs visible for a
particular media source, but the source projection mixer will select
a sub-set of all potential streams to deliver. A given sub-setting
is to only deliver one representation of each media source to the
receiver. During a multiparty conference where a main speaker is
shown larger at the receiver, and other participants are shown
smaller, the mixer may due to congestion be forced to switch
representation of the main speaker. If the role would be strictly
associated with the encoding representation then main speakers video
may for example be reduced in display size. If instead it is
explicitly indicated using APPID the receiving application would
continue to show the main speaker as a larger display area, despite
the reduced quality to ensure the user continuous to understand that
this is still the main talker.
Where SRCNAME provides stable identification that a SSRC is
associated with a media source and particular encoding of that media
source, the APPID can function as a complement when needed to provide
explicit indication of the current role and intended of application
usage of a SSRC.
8. IANA Considerations
Following the guidelines in SDP [RFC4566], in The Session Description
Protocol (SDP) Grouping Framework [RFC5888], and in RTP [RFC3550],
the IANA is requested to register:
1. A new SDES item named SRCNAME, as defined in Section 4.2. This
item needs to be assigned an identifier TBA1.
2. A new SDP source attribute named srcname, as defined in
Section 4.3.
3. New RTP header extension URN identifiers for SRCNAME, as defined
in Section 4.4.
Westerlund & Burman Expires April 24, 2014 [Page 10]
Internet-Draft RTCP SDES SRCNAME October 2013
9. Security Considerations
The SDES item or header extension SRCNAMEs being close to opaque
identifiers could potentially carry additional meanings or function
as overt channel. If the SRCNAME would be permanent between
sessions, they have the potential for compromising the users' privacy
as they can be tracked between sessions. See Guidelines for Choosing
RTP Control Protocol (RTCP) Canonical Names (CNAMEs) [RFC7022] for
more discussion.
A third party modification of the srcname labels either in the RTCP
SDES items, in the SDP a=ssrc attribute, or in the RTP header
extension can cause service disruption. By modifying labels the
wrong streams could be associated, with potentially serious effects
including media disruptions. If streams that are to be associated
aren't associated, then another type of failures occur. To prevent
modification, insertion or deletion of the srcname labels, the
carrying channel needs to be protected by integrity protection and
source authentication. For RTCP and RTP header extension, various
solutions exist, such as SRTP [RFC3711], DTLS [RFC6347], or IPsec
[RFC4301]. For protecting the SDP, the signalling channel needs to
provide protection. For SIP S/MIME [RFC3261] are the ideal, and hop
by hop TLS [RFC5246] provides at least some protection, although not
perfect. For SDPs retrieved using RTSP DESCRIBE [RFC2326], TLS would
be the RECOMMENDED solution.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009.
Westerlund & Burman Expires April 24, 2014 [Page 11]
Internet-Draft RTCP SDES SRCNAME October 2013
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, September 2013.
10.2. Informative References
[I-D.even-mmusic-application-token]
Even, R., Lennox, J., and Q. Wu, "The Session Description
Protocol (SDP) Application Token Attribute",
draft-even-mmusic-application-token-01 (work in progress),
September 2013.
[I-D.lennox-raiarea-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, "A Taxonomy of Grouping Semantics and
Mechanisms for Real-Time Transport Protocol (RTP)
Sources", draft-lennox-raiarea-rtp-grouping-taxonomy (work
in progress), October 2013.
[I-D.westerlund-avtcore-rtp-simulcast]
Westerlund, M. and B. Burman, "Using Simulcast in RTP
sessions", draft-westerlund-avtcore-rtp-simulcast (work in
progress), October 2013.
[I-D.westerlund-avtext-sdes-hdr-ext]
Westerlund, M., Burman, B., and R. Even, "RTP Header
Extension for RTCP Source Description Items",
draft-westerlund-avtext-sdes-hdr-ext (work in progress),
October 2013.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
Westerlund & Burman Expires April 24, 2014 [Page 12]
Internet-Draft RTCP SDES SRCNAME October 2013
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis,
"RTP Payload Format for Scalable Video Coding", RFC 6190,
May 2011.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
Authors' Addresses
Magnus Westerlund
Ericsson
Farogatan 6
SE-164 80 Kista
Sweden
Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com
Bo Burman
Ericsson
Farogatan 6
SE-164 80 Kista
Sweden
Phone: +46 10 714 13 11
Email: bo.burman@ericsson.com
Westerlund & Burman Expires April 24, 2014 [Page 13]
