Network behaviour

This document describes the behaviour of the OpenTV Player with regards to network requests and connections, such as HTTP redirections or DNS resolution. This information is aimed at operators who plan to integrate the player in their Content Delivery Network (CDN) infrastructure. 

Manifest redirections when playback starts

The player supports redirections on manifests on most platforms, but the maximum number of allowed redirections can vary. The most recent versions can perform 20 redirects, which has become an accepted standard behaviour for most browsers.
Behaviour  Android 4 iOS 2+ Chrome
The player follows redirects, up to a maximum of 20.  
Under analysis    

Media segment redirections during playback

The player supports redirections on media segments on most platforms, but the maximum number of allowed redirections can vary. The most recent versions can perform 20 redirects, which has become an accepted standard behaviour for most browsers.
Behaviour  Android 4 iOS 2+ Chrome
The player follows redirects, up to a maximum of 20.  
Under analysis    

Server connection

This section describes whether, once the player has connected to a server, it stays connected to the same server during playback, or regularly resolves the host name and could then change the server it connects to. 

The most recent versions of the player perform a hostname lookup once at startup, and never refresh unless the connection is killed. However, older versions or some platforms can show a different behaviour. For example, older versions of the player resolve every 60 seconds, or inherit from the behaviour of the OS network stack, such as NSURLSession on iOS.
Behaviour  Android 4 iOS 2+ Chrome

The host name is resolved for every playlist or segment as it is downloaded. 

 
Under analysis    

Dealing with a reset connection

This section describes whether, when a connection is reset, the player tries to resolve the host again and resume play. The kind of connection reset here is a TCP/IP connection closed by the server, or some other network error that leads to the connection being closed prematurely.

Behaviour  Android 4 iOS 2+ Chrome
The player resolves the host again, and treats the whole thing as a new connection.    
The player considers this as a network error and places itself in an error state. At application level, playback can be retried, however, no DNS lookup will be performed.  

Dealing with cookies sent by the server

This section describes how the player handles cookies sent by the server. The most recent versions of the player do not honour cookies sent by the server. Some older versions supported cookies, but to a varying degree between platforms and between devices. 

Behaviour  Android 4 iOS 2+ Chrome
The player honours cookies sent by the server.  
The player does not honour cookies sent by the server.    

Retry policies

This section describes the retry policies when there is no reply within the expected time, what the expected time is, and whether the player times out on data transfer.

Recent versions of the player timeout on connections taking more than 5 minutes to establish, which translates to a network error. Older versions might timeout earlier or later.
Behaviour  Android 4 iOS 2+ Chrome
The player uses a 30 seconds timeout on connection establishing.     
The player uses a 300 seconds timeout on connection establishing.    
The player uses the timeout setting native to the pp.URLLoader library.    
The player uses no timeout on data transfer.