Internet DRAFT - draft-stokking-avtcore-idms-for-iptv
draft-stokking-avtcore-idms-for-iptv
Network Working Group H. Stokking
Internet-Draft O. van Deventer
R. van Brandenburg
Intended status: Informational TNO
Expires: April 30, 2015 F. Boronat
M. Montagud
Universitat Politecnica de
Valencia
October 27, 2014
Inter-Destination Media Synchronizaton for IPTV Environments
draft-stokking-avtcore-idms-for-iptv-00.txt
Abstract
[RFC7272] describes the use of RTCP for the purpose of Inter-
Destination Media Synchronization (IDMS) between Synchronization
Clients (SCs) and an Media Synchronization Application Server (MSAS).
This document extends that work for application in the area of IPTV.
First, RTCP can be used according to the single source multicast
(SSM) principles from [RFC5760] in the IPTV application area. This
document specifies the use of a feedback target for collecting and
possibly summarizing IDMS reports. For this, the document defines 2
new sub-report blocks for the use of IDMS according to the SSM
principles. Alternatively, the MSAS can be co-located with the
Feedback Target, for synchronizing small groups of receivers.
Secondly, in an IPTV environment, different viewers may receive the
same content, but in non-identical streams. The IDMS solution
presented in [RFC7272] will no longer work in such a case. This
document provides a solution for this.
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].
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/.
Stokking, et al. Expires April 30, 2015 [Page 1]
Internet-Draft idms for iptv October 27, 2014
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 30, 2015.
Copyright Notice
Copyright (c) 2014 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
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. IDMS in an IPTV environment . . . . . . . . . . . . . . . 3
1.1.1. IDMS for Single Source Multicast . . . . . . . . . . . 3
1.1.2. IDMS for different streams providing the same
content . . . . . . . . . . . . . . . . . . . . . . . 4
2. IDMS report aggregation in SSM session . . . . . . . . . . . . 5
2.1. IDMS Packet Received Sub-Report Block . . . . . . . . . . 5
2.2. IDMS Packet Presented Sub-Report Block . . . . . . . . . . 7
3. IDMS with separate synchronization server with unicast
synchronization settings . . . . . . . . . . . . . . . . . . . 7
4. IDMS in case of multiple RTP streams . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Stokking, et al. Expires April 30, 2015 [Page 2]
Internet-Draft idms for iptv October 27, 2014
1. Introduction
The Real-time Transport Protocol (RTP) provides a real-time transport
mechanism suitable for unicast and multicast communication between
multimedia applications. An important component of the RTP protocol
is the control channel, defined as the RTP Control Protocol (RTCP).
RTP and RTCP have been extended in numerous RFCs. Two such
extensions are the extensions for Single-Source Multicast (SSM)
Sessions with Unicast Feedback in [RFC5760] and the use of RTCP for
Inter-Destination Media Synchronization (IDMS) in [RFC7272].
This Internet draft provides a number of extensions on the use of
RTCP for IDMS in an IPTV environment. The IPTV environment has a
number of characteristics that are currently not dealt with
[RFC7272]. The introduction discusses the IPTV environment and
identifies various gaps in the current IDMS solution. The next
sections discuss solution directions for dealing with these gaps.
The purpose of this Internet Draft is to build upon [RFC7272] so that
the IDMS solution can be applied in an IPTV specific environment.
1.1. IDMS in an IPTV environment
An IPTV environment has specific characteristics, which [RFC7272]
does not deal with properly. These characteristics are:
o Single Source Multicast (SSM, [RFC5760]) setting with a large
number of viewers.
o Different receivers may receive different versions of the same
content, i.e. they receive non-identical streams, e.g. different
unicast streams, different encoded streams, streams from different
media senders.
1.1.1. IDMS for Single Source Multicast
The first characteristic of IPTV is the large-scale Single Source
Multicast (SSM) setting. Regular linear television is offered using
SSM. Such SSM sessions have a large number of viewers, often in the
millions, which requires a highly scalable approach. Applying IDMS
to such an SSM session can be done in two ways:
1. Synchronize all receivers. In this case, [RFC7272] does not
offer the scalability to synchronize all viewers in such large-scale
sessions. In such a case each receiver contains a synchronization
client (SC) which communicates with the Media Synchronization
Application Server (MSAS).[RFC5760] offers a unicast feedback system
using feedback targets (FTs) to collect and possibly aggregate RTCP
reports of groups of receivers. IDMS can be performed using this
Stokking, et al. Expires April 30, 2015 [Page 3]
Internet-Draft idms for iptv October 27, 2014
same feedback system, providing more scalability. Section 2 of this
document specifies how to accomplish this.
2. Synchronize independent groups of receivers, depending on the
application. Use cases for synchronization, such as social TV or
such as multiple receivers in a single physical location, require
only a limited number of receivers to be synchronized together. For
example, when millions of viewers watch the same television show,
only specific groups of users viewing the show together would have to
be synchronized, and only within their own group. [RFC5760]
describes a system that provides all receivers with the same
information. If only a limited subset of the receivers are
synchronized together, not all receivers need to receive the same
synchronization instructions. Section 3 of this document provides a
unicast way of sending synchronization instructions to receivers,
which requires the MSAS to be co-located with the Feedback Target.
The choice between options 1 and 2 depends on a number of factors.
If only a limited number of receivers use a service that requires
IDMS, it is inefficient to synchronize all viewers. Also, playout
timing differences between various receivers can be relatively large
due to e.g. variable propagation delays. If that is the case, and
every receiver is synchronizing to the slowest receiver, a lot of
buffering needs to be done. This is not efficient, and also
significantly increases channel changing delays. In these cases, it
makes sense to use option 2. If on the other hand many viewers use
synchronization sensitive services, and playout timing differences
are relatively small, it may make sense to synchronize all receivers
by using option 1.
1.1.2. IDMS for different streams providing the same content
Different viewers may watch the same content, but use a different
media stream in an IPTV environment. An example of this is when one
viewer receives an High Definition (HD) stream and another viewer
receives an Standard Definition (SD) stream. Another example is when
multiple receivers view the same video-on-demand, receiving this
using different unicast streams. Services such as social TV, where
different viewers remotely view media content together, require
synchronization of these different streams. The IDMS solution is
based on RTP timestamps. For different streams, these timestamps are
not aligned, i.e. there is no relation between the timestamps in one
stream and the timestamps in another stream, because of the different
random offset of the RTP timestamps, as well as potential clock skew.
Because of this, the MSAS cannot determine proper synchronization
instructions.
There are two possible solution directions for this problem.
Stokking, et al. Expires April 30, 2015 [Page 4]
Internet-Draft idms for iptv October 27, 2014
The first is to have the media source output the different streams
with the same timing. The NTP timestamp in the RTP packets will then
be synchronous, i.e. IDMS can be based on this NTP timestamp analogue
to inter-stream synchronization (lip-sync). This does require the
MSAS to be informed on the RTP/NTP relationships of the various
streams. This information is available in the RTCP SRs of the
various streams. If the MSAS is part of the media source, this is
implicitly available. If this is not the case, the MSAS should
receive these SRs somehow. This document presents various options to
achieve this.
The other solution for this problem, is to have the media source
determine and signal the relationship between the various RTP
timestamps of the various streams. Again, if the MSAS is part of
with the media source, then this information is locally available.
If the MSAS is a separate entity, the media source can sent this
information to the MSAS. Section 4 of this document shows how that
is done.
2. IDMS report aggregation in SSM session
[RFC5760] describes how to use Feedback Targets (FTs) or the
Distribution Source (DS)for summarizing RTCP packets from receivers,
using the Receiver Summary Information (RSI) Packet. This section
describes two new sub-report blocks, to be used in those RSI packets.
One sub-report block is for summarizing reported RTP packet received
timestamps, the other is for summarizing reported RTP packet
presented timestamps.
A feedback target or distribution source MUST only summarize IDMS
information from SCs, if they belong to the same synchronization
group, i.e. when the reports from the receivers contain the same
Media Stream Correlation Identifier [RFC7272]. If at least one of
the receivers in a certain synchronization group reports on both
packet received timestamps and packet presented timestamps, a
feedback target or distribution source SHOULD also include packet
presented timestamps. If all receivers report on packet presented
timestamps, a feedback target or distribution source MUST include
packet presented timestamps. If a feedback target or distribution
source summarizes the packet received timestamps, it SHOULD also
summarize the packet presented timestamps.
2.1. IDMS Packet Received Sub-Report Block
To summarize the packet received timestamps in the IDMS information
from SCs, a feedback target or distribution source can use the
following sub-report block. The name of this sub-report block is
"IDMS Received", the long name is "IDMS Packet Received NTP
Stokking, et al. Expires April 30, 2015 [Page 5]
Internet-Draft idms for iptv October 27, 2014
Timestamp".
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRBT=TBD | Length | NDB | MF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PT | Resrv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Media Stream Correlation Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received NTP Timestamp - Minimum Distribution Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received NTP Timestamp - Maximum Distribution Value |
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Distribution Buckets |
| ... |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IDMS Packet Received Sub-Report Block
Sub-Report Block Type (SRBT): 8 bits, TBD upon IANA registration.
Length: 8 bits, the length of the sub-report in 32-bit words, as
defined in RFC 5760.
Number of Distribution Buckets (NDB): 12 bits, as defined in RFC
5760, except for the calculation of the size of each bucket. Since
the header is longer than the sub-report blocks defined in RFC 5760,
the size of each bucket can be calculated using the formula ((length
* 4) - 32) * 8 / NDB number of bits.
Multiplicative Factor (MF): 4 bits, as defined in [RFC5760].
Packet Received RTP Timestamp: 32 bits, as defined in [RFC7272].
Payload Type (PT): 7 bits, as defined in [RFC7272].
Reserved Bits (Resrv): 25 bits, as defined in [RFC7272].
Media Stream Correlation Identifier: 32 bits, as defined in
[RFC7272].
Stokking, et al. Expires April 30, 2015 [Page 6]
Internet-Draft idms for iptv October 27, 2014
Packet Received NTP timestamp - Minimum Distribution Value: 64 bits,
as defined in [RFC7272].
Packet Received NTP Timestamp - Maximum Distribution Value: 64 bits,
as defined in [RFC7272].
Distribution Buckets: each bucket has ((Length * 4) - 28) * 8 / NDB
bits.
The whole sub-report block contains only a single packet received RTP
timestamp value. Since various receivers will normally report on
different packet received RTP timestamps, a feedback target MUST
recalculate all packet received NTP timestamps to match the single
packet received RTP timestamp. This will give an overview of the
packet received times of all receivers for that specific RTP
timestamp. This recalculation is necessary for all reported
timestamps: minimum, maximum and those in the distribution buckets.
2.2. IDMS Packet Presented Sub-Report Block
To summarize the packet presented timestamps in the IDMS information
from SCs, a feedback target or distribution source can use the
following sub-report block. The name of this sub-report block is
"IDMS Presented", the long name is "IDMS Packet Presented NTP
Timestamp".
Stokking, et al. Expires April 30, 2015 [Page 7]
Internet-Draft idms for iptv October 27, 2014
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRBT=TBD | Length | NDB | MF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PT | Resrv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Media Stream Correlation Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Presented NTP Timestamp - Minimum Distribution Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Presented NTP Timestamp - Maximum Distribution Value |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Distribution Buckets |
| ... |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IDMS Packet Presented Sub-Report Block
Sub-Report Block Type (SRBT): 8 bits, TBD upon IANA registration.
Length: 8 bits, the length of the sub-report in 32-bit words, as
defined in RFC 5760.
Number of Distribution Buckets (NDB): 12 bits, as defined in RFC
5760, except for the calculation of the size of each bucket. Since
the header is longer than of the sub-report blocks defined in RFC
5760, the size of each bucket can be calculated using the formula
((length * 4) - 28) * 8 / NDB number of bits.
Multiplicative Factor (MF): 4 bits, as defined in [RFC5760].
Packet Received RTP Timestamp: 32 bits, as defined in [RFC7272].
Payload Type (PT): 7 bits, as defined in [RFC7272].
Reserved Bits (Resrv): 25 bits, as defined in [RFC7272].
Media Stream Correlation Identifier: 32 bits, as defined in
[RFC7272].
Packet Presented NTP timestamp - Minimum Distribution Value: 32 bits,
as defined in [RFC7272].
Packet Presented NTP Timestamp - Maximum Distribution Value: 32 bits,
Stokking, et al. Expires April 30, 2015 [Page 8]
Internet-Draft idms for iptv October 27, 2014
as defined in [RFC7272].
Distribution Buckets: each bucket has ((Length * 4) - 28) * 8 / NDB
bits.
The whole sub-report block contains only a single packet received RTP
timestamp value. Since various receivers will report on different
packet presented NTP timestamps, a feedback target MUST recalculate
all packet presented NTP timestamps to match the single packet
received RTP timestamp. This is true for all reported timestamps:
minimum, maximum and those in the distribution buckets.
3. IDMS with separate MSAS with unicast synchronization settings
The second alternative for IDMS in a large-scale SSM context is to
synchronize small groups of receivers that need to be synchronized
with each other because of the service requirements. Different
groups may still receive the same RTP streams, but can be
synchronized independent of each other. In that case, each group
MUST receive its own synchronization settings instructions in the
form of IDMS Settings Packets as defined in [RFC7272]. Normally the
Receiver Reports (RRs) or the Received Summary Information (RSI) is
sent to all receivers. But, since different groups of receivers may
need different synchronization settings instructions, these
instructions cannot be multicast. As it happens, multicasting all
instructions would lead to a situation where all receivers would
receive a multitude of different settings instructions. They would
have to find their own instructions based on the MSCI of their group,
which is possible. But, with a large number of groups, this would be
highly inefficient. This is why a unicast method is taken here.
To unicast the instructions to the various SCs, the MSAS needs to
directly receive the IDMS reports from the various SCs. This means
the MSAS MUST be co-located with the feedback target. When supplying
SCs with the unicast address to which they should sent their reports,
different SCs in the same synchronization group MUST be allocated the
same feedback target. Also, because the synchronization information
is no longer relevant upstream of the MSAS, the feedback target
SHOULD terminate these RTCP blocks and not forward them or summarize
them.
How the receivers receive the unicast address of the feedback target
is out of scope of this draft. [RFC5760] only defines pre-
configuration for this. Alternatively, the RTCP-attribute as
specified in [RFC3605] can be used on the session level to provide
receivers of a shared session with the unicast address of the MSAS,
similar to how this is done in [TS183063].
Stokking, et al. Expires April 30, 2015 [Page 9]
Internet-Draft idms for iptv October 27, 2014
Synchronization settings instructions MUST be sent by the MSAS to the
source IP addresses of the received synchronization information,
using the same destination port as the received synchronization
information.
4. IDMS in case of multiple RTP streams
IDMS is based on various receivers reporting on the packet received
times or packet presentation times. This document describes
situations in which the MSAS is not part of the media source. If all
receivers receive the exact same RTP streams, e.g. in case of
multiple receivers of a single multicast streams, this will work
fine. The MSAS can relate the various received IDMS information.
Even if different receivers report on different RTP timestamps, the
MSAS can calculate the timing differences between clients by
extrapolation using the RTP clock frequency derived from the reported
payload type.
However, when the MSAS is not co-located with the media source and
the receivers receive the same content in different RTP streams, an
MSAS cannot perform the necessary calculations for achieving
synchronization. To perform these calculations, there has to exist
some common timeline in the reports by the various receivers. To
determine a common timeline, the MSAS needs some kind of information
correlating the RTP timestamps in the various streams. This section
provides two alternatives for this.
The first alternative is to use the RTCP Sender Reports that belong
to the various RTP streams. In these SRs, the RTP timestamps are
linked to the employed wallclock time. This is normally used for
intra- and inter-media synchronization. The media sources need to
ensure that the same part of the content in different streams
corresponds to the same wallclock time (NTP timestamp in the SR).
This way the SRs of the various RTP streams can be used to establish
a common timeline between those RTP streams. The easiest way to send
the SR to the MSAS is by having the receiver append it to its report
blocks. Another option is to have the MSAS act as a third party
monitor, as described in [RFC3550].
The second alternative is that the media source sends information on
the correlation of the various timestamps to the MSAS. This can be
done by using the IDMS report block from [RFC7272], using the
Synchronization Packet Sender Types (SPST) 3 and 4, as specified in
[TS183063] Annex W, and registered with IANA in the IDMS XR Block
SPST Registry. These SPSTs are normally used for synchronization in
case a transcoder is changing the media stream such that the RTP
timestamps also change. In this case, synchronization would be
impossible between users receiving the original stream and users
Stokking, et al. Expires April 30, 2015 [Page 10]
Internet-Draft idms for iptv October 27, 2014
receiving the transcoded version. A transcoder can link an incoming
RTP timestamps (SPST=3) to an outgoing RTP timestamp (SPST=4), and
thus enable correlating the timelines. These SPSTs 3 and 4 can also
be used if one source sends out two version of the same content,
linking the timestamps of one stream to those of the other stream.
5. IANA Considerations
This document defines two new RSI Sub-Report Blocks, the "IDMS
Received" and the "IDMS Presented". Based on the specification in
section 2, these two sub-report blocks are added to the IANA registry
for Sub-Report Block Type (SRBT) Values for the RSI Packet, as part
of the RTP parameters registration.
6. Security Considerations
The content of this ID does not pose any security risks above or
beyond those mentioned in [RFC5760] and [RFC7272].
7. Acknowledgements
8. 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.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, October
2003.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC7272] Brandenburg, R. van, Stokking, H., Deventer, O. van,
Boronat, F., Montagud, M., Gross, K., "Inter-Destination
Media Synchronization (IDMS) Using the RTP Control
Protocol (RTCP)", RFC 7272, June 2014.
[TS183063] ETSI, "Telecommunications and Internet converged Services
and Protocols for Advanced Networking (TISPAN); IMS-based
IPTV stage 3 specification", TS 183 063 v3.6.1, August
Stokking, et al. Expires April 30, 2015 [Page 11]
Internet-Draft idms for iptv October 27, 2014
2014.
Authors' Addresses
Hans Stokking
TNO
Brassersplein 2
Delft, 2292CH
The Netherlands
Phone: 0031-(0)88-86 67 278
Fax:
Email: hans.stokking@tno.nl
URI:
Oskar van Deventer
TNO
Brassersplein 2
Delft, 2292CH
The Netherlands
Phone: 0031-(0)88-86 67 078
Fax:
Email: oskar.vandeventer@tno.nl
URI:
Ray van Brandenburg
TNO
Brassersplein 2
Delft, 2292CH
The Netherlands
Phone: 0031-(0)88-86 63 609
Fax:
Email: ray.vanbrandenburg@tno.nl
URI:
Fernando Boronat
Universitat Politecnica de Valencia
IGIC Institute, Universitat Politecnica de Valencia-Campus de Gandia
(UPV), C/ Paraninfo, 1, Grao de Gandia Valencia, 46730
Spain
Phone: +34 962 849 341
Fax:
Stokking, et al. Expires April 30, 2015 [Page 12]
Internet-Draft idms for iptv October 27, 2014
Email: fboronat@dcom.upv.es
URI:
Mario Montagud
Universitat Politecnica de Valencia
IGIC Institute, Universitat Politecnica de Valencia-Campus de Gandia
(UPV), C/ Paraninfo, 1, Grao de Gandia Valencia, 46730
Spain
Phone: +34 962 849 341
Fax:
Email: mamontor@posgrado.upv.es
URI:
Stokking, et al. Expires April 30, 2015 [Page 13]
