N.2 NAT traversal

26.2343GPPProtocols and codecsRelease 17Transparent end-to-end Packet-switched Streaming Service (PSS)TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

If the PSS Client has identified the presence of a NAT, it may probe one or all of the following procedures.

UPnP (Universal Plug and Play) defines a set of procedures to discover gateways and open port-forwarding on client request. UPNP may not be implemented or activated in all NATs. Thus, the client should not expect UPnP present in all cases.

UDP Port Punching: With many existing NATs, the PSS client can initiate NAT routing by "punching" the UDP ports before packets are sent by the server. This is done after the port pairs are negotiated (via SETUP) and before streaming is initiated via PLAY, by sending an RTP packet on the RTP port pair and an RTCP report on the RTCP port pair.

RTSP/RTP Interleaving: The RTP data is interleaved with the RTSP data on a single TCP connection (defined in RFC 2326 section 10.12). RTSP/RTP Interleaving is implemented by a high variety of available streaming servers.

"RTP over TCP" (RFC4571): The RTP packets are tunnelled over separate TCP connections. A major difference compared to the "RTSP/RTP Interleaving" mode (RFC 2326) is, that the client opens one or more separate TCP connections to the server for the RTP transport. This mechanism is described in the RTSP 2.0 draft (draft-ietf-mmusic-rfc2326bis-18.txt).

The PSS Client may also use other transports than RTP. For instance the PSS Client may also try to use progressive download as defined in clause 5.1.

Annex O (informative):
Examples for PSS Timeshift

In the following, the PSS timeshift functionality is described using different examples.

In the following example, a PSS client starts the live session consumption in timeshift mode. This may happen when changing from MBMS reception to PSS reception. Note the PSS client uses the wallclock time from the MBMS stream to start the PSS session.

C->S: PLAY rtsp://example.com/fizzle/foo RTSP/1.0

CSeq: 835

Session: 12345678

Range: clock=20080401T072901.1Z-

S->C: RTSP/1.0 200 OK

CSeq: 835

Range: clock=20080401T072901.1Z-

3GPP-TS-CurrentRecording-Time: clock=20080401T072905.1Z

3GPP-TS-Buffer: clock=20080401T062905.1Z-20080401T072905.1Z

The timeshift buffer in the example above is described by a closed ranged. The timeshift buffer is not progressing as sliding window.

In the following, the use of the 3GPP-TS-Buffer RTSP header is clarified. The "client -> server" request messages left are not shown in these examples.

The server is maintaining a constant 3600 second buffer in the following example. The current time of the live session (at the time of response generation) is as specified in the CurrentRecording-Time.

S->C: RTSP/1.0 200 OK

CSeq: 835

3GPP-TS-CurrentRecording-Time: clock=20080401T072905.1Z

3GPP-TS-Buffer: buffer-depth=3600

The timeshift buffer is still being established and will progress as sliding window in the following example.

S->C: RTSP/1.0 200 OK

CSeq: 835

3GPP-TS-CurrentRecording-Time: clock=20080401T072905.1Z

3GPP-TS-Buffer: clock=20080401T062905.1Z-; buffer-depth=3600

Recording has started at 06:29:05.1, 1 April 2008 and will progress until a buffer-depth of 3600 seconds is reached; once 3600 seconds is reached then the timeshift buffering progresses in a sliding window. Once the PSS timeshift buffer is fully established, the PSS server should only give the "buffer-depth" parameter with the 3GPP-TS-Buffer header.

The following example shows a static timeshift buffer. The buffer only contains information between the given closed range.

S->C: RTSP/1.0 200 OK

CSeq: 835

3GPP-TS-CurrentRecording-Time: clock=20080401T072905.1Z

3GPP-TS-Buffer: clock=20080401T062905.1Z-20080401T072905.1Z

Time shifting is available between the times specified (06:29:05.1 and 07:29:05.1, 1 April 2008). For example, this may be a recording of an earlier broadcast.

An open timeshift buffer range range is used in the following example

S->C: RTSP/1.0 200 OK

CSeq: 835

3GPP-TS-CurrentRecording-Time: clock=20080401T072905.1Z

3GPP-TS-Buffer: clock=20080401T062905.1Z-

Time shifting is available indefinitely, beginning from 06:29:05.1. For example, this may be a live event in progress which is being recorded in its entirety for time-shifting purposes.

Annex P (informative):
QoE Reporting Management Object Device Description Framework

This Device Description Framework (DDF) is the standardized minimal set. A vendor can define its own DDF for the complete device. This DDF can include more features than this minimal standardized version.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE MgmtTree PUBLIC "-//OMA//DTD-DM-DDF 1.2//EN"

"http://www.openmobilealliance.org/tech/DTD/dm_ddf-v1_2.dtd">

<Man>–The device manufacturer–</Man>

<Mod>–The device model–</Mod>

<Node>

<NodeName>3GPP_PSSQOE</NodeName>

<Get/>

</AccessType>

<node/>

</DFFormat>

</Occurrence>

<Scope>

</Scope>

<DFTitle>The interior node holding all 3GPP PSS QoE Metrics Reporting objects</DFTitle>

</DFType>

</DFProperties>

<Node>

<NodeName>Enabled</NodeName>

<Get/>

</AccessType>

<bool/>

</DFFormat>

<One/>

</Occurrence>

<Scope>

</Scope>

<DFTitle>The QoE reporting requested indicator</DFTitle>

</DFType>

</DFProperties>

</Node>

<Node>

<NodeName>Servers</NodeName>

<Get/>

</AccessType>

<chr/>

</DFFormat>

<One/>

</Occurrence>

<DFTitle>The URL of the QoE report servers</DFTitle>

</DFType>

</DFProperties>

</Node>

<Node>

<Get/>

</AccessType>

<chr/>

</DFFormat>

</Occurrence>

<DFTitle>The Access Point Name for QoE reporting</DFTitle>

</DFType>

</DFProperties>

</Node>

<Node>

<NodeName>Format</NodeName>

<Get/>

</AccessType>

<chr/>

</DFFormat>

</Occurrence>

<DFTitle>The QoE metrics report format</DFTitle>

</DFType>

</DFProperties>

</Node>

<Node>

<NodeName>Rules</NodeName>

<Get/>

</AccessType>

<chr/>

</DFFormat>

</Occurrence>

<DFTitle>The QoE metrics rules</DFTitle>

</DFType>

</DFProperties>

</Node>

<Node>

<NodeName>Session</NodeName>

<Get/>

</AccessType>

<node/>

</DFFormat>

</Occurrence>

<DFTitle>The QoE session metrics node</DFTitle>

</DFType>

</DFProperties>

<Node>

<NodeName>Metrics</NodeName>

<Get/>

</AccessType>

<chr/>

</DFFormat>

</Occurrence>

</DFType>

</DFProperties>

</Node>

<Node>

<Get/>

</AccessType>

<node/>

</DFFormat>

</Occurrence>

<Scope>

</Scope>

<DFTitle> A collection of all extension objects</DFTitle>

</DFType>

</DFProperties>

</Node>

<Node>

<NodeName>Speech</NodeName>

<Get/>

</AccessType>

<node/>

</DFFormat>

</Occurrence>

<DFTitle>The QoE speech metrics node</DFTitle>

</DFType>

</DFProperties>

<Node>

<NodeName>Metrics</NodeName>

<Get/>

</AccessType>

<chr/>

</DFFormat>

</Occurrence>

</DFType>

</DFProperties>

</Node>

<Node>

<Get/>

</AccessType>

<node/>

</DFFormat>

</Occurrence>

<Scope>

</Scope>

<DFTitle> A collection of all extension objects</DFTitle>

</DFType>

</DFProperties>

</Node>

<Node>

<NodeName>Video</NodeName>

<Get/>

</AccessType>

<node/>

</DFFormat>

</Occurrence>

<DFTitle>The QoE video metrics node</DFTitle>

</DFType>

</DFProperties>

<Node>

<NodeName>Metric</NodeName>

<Get/>

</AccessType>

<chr/>

</DFFormat>

</Occurrence>

</DFType>

</DFProperties>

</Node>

<Node>

<Get/>

</AccessType>

<node/>

</DFFormat>

</Occurrence>

<Scope>

</Scope>

<DFTitle>A collection of all extension objects</DFTitle>

</DFType>

</DFProperties>

</Node>

<Node>

<Get/>

</AccessType>

<node/>

</DFFormat>

</Occurrence>

<DFTitle>The QoE timed text metrics node</DFTitle>

</DFType>

</DFProperties>

<Node>

<NodeName>Metric</NodeName>

<Get/>

</AccessType>

<chr/>

</DFFormat>

</Occurrence>

</DFType>

</DFProperties>

</Node>

<Node>

<Get/>

</AccessType>

<node/>

</DFFormat>

</Occurrence>

<Scope>

</Scope>

<DFTitle>A collection of all extension objects</DFTitle>

</DFType>

</DFProperties>

</Node>

<Node>

<Get/>

</AccessType>

<node/>

</DFFormat>

</Occurrence>

<Scope>

</Scope>

<DFTitle>A collection of all extension objects</DFTitle>

</DFType>

</DFProperties>

</Node>

</MgmtTree>

Annex Q (informative):
Void

Annex R (normative):
Content Protection extensions

This annex specifies extensions to support protected PSS streaming, typically in conjunction with a Digital Rights Management system. The following is defined in the following clauses:

– the use of ISMACryp for transport of confidentiality protected PSS streams

– the optional use of OMA BCAST Short-Term Key Messages for carriage of frequently changing keys over UDP

– SDP signalling for the use of protected PSS streaming