12 Header Field Definitions (Definizioni dei campi di intestazione)
12 Header Field Definitions (Definizioni dei campi di intestazione)
I campi di intestazione HTTP/1.1 [2] o altri campi non standard non elencati qui non hanno attualmente un significato ben definito e DOVREBBERO essere ignorati dal destinatario.
La tabella 3 riassume i campi di intestazione usati da RTSP. Il tipo «g» indica intestazioni generali di richiesta presenti sia nelle richieste sia nelle risposte, «R» intestazioni di richiesta, «r» intestazioni di risposta ed «e» campi di intestazione dell'entità. I campi contrassegnati con «req.» nella colonna «support» DEVONO essere implementati dal destinatario per il metodo indicato; quelli «opt.» sono facoltativi. Non tutti i campi «req.» saranno inviati in ogni richiesta di quel tipo: «req.» significa solo che client (per le intestazioni di risposta) e server (per quelle di richiesta) DEVONO implementare tali campi. L'ultima colonna elenca il metodo per cui il campo è significativo; «entity» si riferisce a tutti i metodi che restituiscono un corpo del messaggio. In questa specifica DESCRIBE e GET_PARAMETER rientrano in questa classe.
| Header | type | support | methods |
|---|---|---|---|
| Accept | R | opt. | entity |
| Accept-Encoding | R | opt. | entity |
| Accept-Language | R | opt. | all |
| Allow | r | opt. | all |
| Authorization | R | opt. | all |
| Bandwidth | R | opt. | all |
| Blocksize | R | opt. | all but OPTIONS, TEARDOWN |
| Cache-Control | g | opt. | SETUP |
| Conference | R | opt. | SETUP |
| Connection | g | req. | all |
| Content-Base | e | opt. | entity |
| Content-Encoding | e | req. | SET_PARAMETER, DESCRIBE, ANNOUNCE |
| Content-Language | e | req. | DESCRIBE, ANNOUNCE |
| Content-Length | e | req. | SET_PARAMETER, ANNOUNCE, entity |
| Content-Location | e | opt. | entity |
| Content-Type | e | req. | SET_PARAMETER, ANNOUNCE |
| Content-Type | r | req. | entity |
| CSeq | g | req. | all |
| Date | g | opt. | all |
| Expires | e | opt. | DESCRIBE, ANNOUNCE |
| From | R | opt. | all |
| If-Modified-Since | R | opt. | DESCRIBE, SETUP |
| Last-Modified | e | opt. | entity |
| Proxy-Authenticate | r | opt. | all |
| Proxy-Require | R | req. | all |
| Public | r | opt. | all |
| Range | R | opt. | PLAY, PAUSE, RECORD |
| Range | r | opt. | PLAY, PAUSE, RECORD |
| Referer | R | opt. | all |
| Require | R | req. | all |
| Retry-After | r | opt. | all |
| RTP-Info | r | req. | PLAY |
| Scale | Rr | opt. | PLAY, RECORD |
| Session | Rr | req. | all but SETUP, OPTIONS |
| Server | r | opt. | all |
| Speed | Rr | opt. | PLAY |
| Transport | Rr | req. | SETUP |
| Unsupported | r | req. | all |
| User-Agent | R | opt. | all |
| Via | g | opt. | all |
| WWW-Authenticate | r | opt. | all |
Panoramica dei campi di intestazione RTSP
12.1 Accept
Il campo di intestazione di richiesta Accept può specificare tipi di contenuto della descrizione di presentazione accettabili per la risposta.
Il parametro «level» per le descrizioni di presentazione è definito correttamente nella registrazione del tipo MIME, non qui.
Sintassi: vedere [H14.1].
Esempio: Accept: application/rtsl, application/sdp;level=2
12.2 Accept-Encoding
Vedere [H14.3].
12.3 Accept-Language
Vedere [H14.4]. La lingua indicata si applica alla descrizione di presentazione e alle eventuali frasi di motivazione, non al contenuto multimediale.
12.4 Allow
Il campo di intestazione di risposta Allow elenca i metodi supportati dalla risorsa identificata dalla request-URI. Serve a informare rigorosamente il destinatario dei metodi validi. In una risposta 405 (Method not allowed) DEVE essere presente Allow.
Esempio: Allow: SETUP, PLAY, RECORD, SET_PARAMETER
12.5 Authorization
Vedere [H14.8].
12.6 Bandwidth
Il campo Bandwidth descrive la larghezza di banda stimata disponibile per il client, come intero positivo in bit al secondo. La banda può variare durante la sessione RTSP, ad es. per riaddestramento del modem.
Bandwidth = "Bandwidth" ":" 1*DIGIT
Esempio: Bandwidth: 4000
12.7 Blocksize
Inviato dal client al server multimediale per richiedere una dimensione di pacchetto multimediale; non include intestazioni di livello inferiore (IP, UDP, RTP). Il server può usare una dimensione inferiore. Il server PUÒ troncare al multiplo più vicino della dimensione minima specifica del media o sostituirla se necessario. La dimensione DEVE essere un decimale positivo in ottetti. Errore (416) solo se il valore è sintatticamente invalido.
12.8 Cache-Control
Specifica direttive che tutti i meccanismi di caching lungo la catena richiesta/risposta DEVONO rispettare. Le direttive devono essere inoltrate dai proxy/gateway. Cache-Control va indicato solo in SETUP e risposta; non governa il caching delle risposte come in HTTP ma del flusso identificato da SETUP; le risposte RTSP non sono memorizzabili in cache salvo quelle a DESCRIBE.
Cache-Control = "Cache-Control" ":" 1#cache-directive
cache-directive = cache-request-directive |
cache-response-directive
cache-request-directive = "no-cache" |
"max-stale" |
"min-fresh" |
"only-if-cached" |
cache-extension
cache-response-directive = "public" |
"private" |
"no-cache" |
"no-transform" |
"must-revalidate" |
"proxy-revalidate" |
"max-age" "=" delta-seconds |
cache-extension
cache-extension = token [ "=" ( token | quoted-string ) ]
no-cache: indica che il flusso multimediale NON DEVE essere memorizzato in cache in alcun luogo. Consente al server di origine di impedire il caching anche da cache configurate per restituire risposte non fresche.
public: indica che il flusso è memorizzabile in cache da qualsiasi cache.
private: indica che il flusso è destinato a un singolo utente e NON DEVE essere memorizzato da una cache condivisa. Una cache privata (non condivisa) può memorizzare il flusso.
no-transform: un cache intermedio (proxy) può trovare utile convertire il tipo multimediale di uno stream. Ad esempio un proxy può convertire tra formati video per risparmiare spazio o ridurre il traffico su un collegamento lento. Possono tuttavia verificarsi gravi problemi operativi quando tali trasformazioni sono applicate a stream destinati a certe applicazioni (imaging medico, analisi scientifica, autenticazione end-to-end). Se una risposta include no-transform, un cache o proxy intermedio NON DEVE modificare la codifica dello stream. A differenza di HTTP, RTSP non prevede in questo punto trasformazione parziale, ad es. traduzione in un'altra lingua.
only-if-cached: in alcuni casi, ad es. con connettività di rete estremamente scarsa, il client può volere che una cache restituisca solo gli stream multimediali attualmente memorizzati. Il client può includere only-if-cached. Se la cache riceve questa direttiva, DOVREBBE rispondere con uno stream coerente con gli altri vincoli della richiesta oppure con 504 (Gateway Timeout). Se un gruppo di cache opera come sistema unificato con buona connettività interna, tale richiesta PUÒ essere inoltrata all'interno del gruppo.
max-stale: indica che il client accetta uno stream la cui validità è scaduta; con valore, il superamento massimo in secondi è limitato; senza valore, accetta qualsiasi età.
min-fresh: indica che il client accetta uno stream la cui vita di freschezza residua è almeno pari all'età attuale più i secondi indicati.
must-revalidate: quando presente in una risposta SETUP ricevuta da una cache, quella cache NON DEVE usare l'entrata dopo che è diventata obsoleta per rispondere senza prima rivalidarla con il server di origine, ogni volta che la risposta in cache è obsoleta in base solo a Expires del server di origine.
12.9 Conference
Collega logicamente una conferenza preesistente a un flusso RTSP; la conference-id non deve cambiare per la stessa sessione.
Conference = "Conference" ":" conference-id
Esempio: Conference: [email protected]%20Starr
Codice 452 se l'id non è valido.
12.10 Connection
Vedere [H14.10].
12.11 Content-Base
Vedere [H14.11].
12.12 Content-Encoding
Vedere [H14.12].
12.13 Content-Language
Vedere [H14.13].
12.14 Content-Length
Lunghezza del contenuto del metodo dopo il doppio CRLF finale degli header. A differenza di HTTP DEVE essere incluso in tutti i messaggi con corpo oltre gli header; se manca, si assume zero. [H14.14].
12.15 Content-Location
Vedere [H14.15].
12.16 Content-Type
Vedere [H14.18]. In pratica i tipi adatti a RTSP sono spesso limitati a descrizioni di presentazione e tipi parametro-valore.
12.17 CSeq
Numero di sequenza per la coppia richiesta-risposta RTSP; DEVE essere in ogni richiesta e risposta; le ritrasmissioni mantengono lo stesso numero.
12.18 Date
Vedere [H14.19].
12.19 Expires
Il campo di intestazione dell'entità Expires fornisce data e ora dopo le quali la descrizione o il flusso multimediale devono considerarsi obsoleti. L'interpretazione dipende dal metodo.
Risposta DESCRIBE: Expires indica dopo quale istante la descrizione va considerata obsoleta.
Una voce di cache obsoleta non deve in genere essere restituita senza prima validazione con il server di origine (o con un cache intermedio con copia fresca). Vedere la sezione 13.
La presenza di Expires non implica che la risorsa originale cambierà o cesserà di esistere a, prima o dopo quell'istante.
Il formato è data e ora assoluta HTTP-date [H3.3]; DEVE essere in formato RFC1123-date:
Expires = "Expires" ":" HTTP-date
Esempio: Expires: Thu, 01 Dec 1994 16:00:00 GMT
I client e le cache RTSP/1.0 DEVONO trattare altri formati di data non validi, in particolare il valore «0», come avvenuti nel passato (già scaduti).
Per contrassegnare «già scaduto», il server di origine dovrebbe usare una data Expires uguale a Date. Per «mai scaduto», una data circa un anno dopo l'invio. I server RTSP/1.0 non dovrebbero inviare Expires oltre un anno nel futuro.
La presenza di Expires con data futura su uno stream che altrimenti non sarebbe memorizzabile in cache indica che lo stream è memorizzabile in cache, salvo diversa indicazione da Cache-Control (sezione 12.8).
12.20 From
Vedere [H14.22].
12.21 Host
Non necessario per RTSP; se inviato, ignorare silenziosamente.
12.22 If-Match
Vedere [H14.25]. Utile per l'integrità della descrizione (HTTP esterno o garanzia tra DESCRIBE e SETUP). Identificatore opaco.
12.23 If-Modified-Since
Con DESCRIBE e SETUP condizionale; se non modificato, 304 senza corpo.
If-Modified-Since = "If-Modified-Since" ":" HTTP-date
Esempio: If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
12.24 Last-Modified
Data/ora ultima modifica per descrizione o flusso [H14.29].
12.25 Location
Vedere [H14.30].
12.26 Proxy-Authenticate
Vedere [H14.33].
12.27 Proxy-Require
Funzionalità sensibili al proxy che il proxy DEVE supportare; negazione se non supportate. Il server dovrebbe trattare come Require. Sezione 12.32.
12.28 Public
Vedere [H14.35].
12.29 Range
Questo campo di intestazione di richiesta e risposta specifica un intervallo di tempo. L'intervallo può essere espresso in varie unità. Questa specifica definisce le unità smpte (sezione 3.5), npt (3.6) e clock (3.7). In RTSP gli intervalli in byte [H14.36.1] non sono significativi e NON DEVONO essere usati. L'intestazione può anche contenere un parametro time in UTC che indica l'istante in cui l'operazione deve avere effetto. Un server che supporta Range DEVE comprendere il formato NPT e DOVREBBE comprendere SMPTE. L'intestazione di risposta Range indica quale intervallo temporale è effettivamente in riproduzione o registrazione. Se Range è in un formato temporale non compreso, il destinatario dovrebbe restituire «501 Not Implemented».
Gli intervalli sono semi-aperti: includono l'estremo inferiore ed escludono il superiore. Un intervallo a–b inizia esattamente al tempo a e termina appena prima di b. È rilevante solo l'istante di inizio di un'unità media come un fotogramma video o audio. Supponendo fotogrammi video ogni 40 ms, l'intervallo 10,0–10,1 include un fotogramma che inizia a 10,0 o dopo e include un fotogramma che inizia a 10,08 anche se si estende oltre l'intervallo. L'intervallo 10,0–10,08 esclude invece il fotogramma a 10,08.
Range = "Range" ":" 1#ranges-specifier [ ";" "time" "=" utc-time ]
ranges-specifier = npt-range | utc-range | smpte-range
Esempio: Range: clock=19960213T143205Z-;time=19970123T143720Z
La notazione è simile all'intestazione delle plage di byte HTTP/1.1 [2]. Consente al client di selezionare un estratto dall'oggetto multimediale, di riprodurre da un punto fino alla fine e dalla posizione corrente fino a un punto dato. L'inizio della riproduzione può essere pianificato in qualsiasi momento futuro, sebbene il server possa rifiutarsi di mantenere risorse per lunghi periodi di inattività.
12.30 Referer
Vedere [H14.37]. URL della descrizione di presentazione, spesso via HTTP.
12.31 Retry-After
Vedere [H14.38].
12.32 Require
Il campo Require è usato dal client per chiedere al server quali opzioni può supportare o meno. Il server DEVE rispondere usando l'intestazione Unsupported per negare le opzioni NON supportate.
Ciò garantisce che l'interazione proceda senza ritardo quando tutte le opzioni sono comprese da entrambe le parti, e rallenti solo se non lo sono. Per coppie client-server ben abbinate si risparmia spesso un round-trip. Inoltre si elimina ambiguità quando il client richiede funzionalità che il server non comprende.
Require = "Require" ":" 1#option-tag
Esempio:
C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0 CSeq: 302 Require: funky-feature Funky-Parameter: funkystuff
S->C: RTSP/1.0 551 Option not supported CSeq: 302 Unsupported: funky-feature
C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0 CSeq: 303
S->C: RTSP/1.0 200 OK CSeq: 303
In questo esempio «funky-feature» è il tag di funzionalità che indica al client che il campo fittizio Funky-Parameter è richiesto. La relazione tra «funky-feature» e Funky-Parameter non viene comunicata nello scambio RTSP, essendo proprietà immutabile del tag.
I proxy e altri dispositivi intermedi DOVREBBERO ignorare le funzionalità non comprese in questo campo. Se un'estensione richiede il supporto degli intermediari, va etichettata in Proxy-Require (sezione 12.27).
12.33 RTP-Info
Questo campo imposta parametri specifici RTP nella risposta PLAY.
url: indica l'URL del flusso a cui corrispondono i parametri RTP seguenti.
seq: indica il numero di sequenza del primo pacchetto del flusso, per gestire correttamente i pacchetti durante il seek.
rtptime: indica il timestamp RTP corrispondente al valore temporale nell'intestazione di risposta Range. (Nota: con controllo aggregato uno stream può non generare un pacchetto per il valore temporale restituito; non c'è garanzia che il pacchetto con seq abbia il timestamp rtptime.) Il client usa questo valore per calcolare la mappatura da tempo RTP a NPT.
La mappatura RTP→NTP (orologio di parete) è disponibile via RTCP, ma non basta per RTP→NPT. Per disponibilità e affidabilità al momento necessario (avvio o dopo seek), la mappatura è sul canale di controllo RTSP.
Per compensare la deriva in presentazioni lunghe, i client RTSP dovrebbero mappare anche NPT su NTP usando i sender report RTCP iniziali e successivi.
RTP-Info = "RTP-Info" ":" 1#stream-url 1*parameter
stream-url = "url" "=" url
parameter = ";" "seq" "=" 1*DIGIT | ";" "rtptime" "=" 1*DIGIT
Esempio: RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102, url=rtsp://foo.com/bar.avi/streamid=1;seq=30211
12.34 Scale
Un valore di scala 1 indica riproduzione o registrazione normale al tasso di visione in avanti normale. Se non è 1, il valore corrisponde al rapporto rispetto al tasso normale. Ad esempio 2 indica il doppio («avanzamento rapido») e 0,5 la metà. In altre termini, con rapporto 2 il tempo di riproduzione normale cresce al doppio del ritmo dell'orologio a parete: ogni secondo di orologio a parete vengono consegnati due secondi di contenuto. Un valore negativo indica direzione inversa.
Salvo diversa richiesta del parametro Speed, il tasso di dati non DOVREBBE cambiare. L'implementazione delle variazioni di scala dipende dal server e dal tipo di media. Per il video il server può consegnare solo fotogrammi chiave o selezionati; per l'audio può dilatare nel tempo preservando l'intonazione o, meno desiderabilmente, inviare frammenti.
Il server dovrebbe approssimare il tasso di visione, ma può limitare l'intervallo di valori supportati. La risposta DEVE contenere il valore di scala effettivo scelto dal server.
Se la richiesta contiene un parametro Range, il nuovo valore di scala avrà effetto a quell'istante.
Scale = "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ]
Esempio di riproduzione inversa a 3,5 volte il tasso normale:
Scale: -3.5
12.35 Speed
Questo parametro del campo di intestazione di richiesta chiede al server di consegnare i dati al client a una certa velocità, in funzione della capacità e della volontà del server di servire il flusso a quella velocità. L'implementazione da parte del server è OPZIONALE. Il valore predefinito è il bitrate del flusso.
Il valore è espresso come rapporto decimale; es. 2,0 indica consegna al doppio della velocità normale. Velocità zero non valida. Se la richiesta contiene Range, la nuova velocità avrà effetto a quell'istante.
Speed = "Speed" ":" 1*DIGIT [ "." *DIGIT ]
Esempio: Speed: 2.5
L'uso di questo campo modifica la larghezza di banda usata per la consegna. È pensato per circostanze in cui serve un'anteprima a tasso più alto o basso. Gli implementatori tengano presente che la banda della sessione può essere stata negoziata in anticipo (con mezzi diversi da RTSP) e che può servire rinegoziazione. Con dati su UDP si raccomanda fortemente RTCP o simili per monitorare le perdite di pacchetti.
12.36 Server
Vedere [H14.39].
12.37 Session
Questo campo di intestazione di richiesta e risposta identifica una sessione RTSP avviata dal server multimediale in una risposta SETUP e conclusa con TEARDOWN sull'URL della presentazione. L'identificatore di sessione è scelto dal server multimediale (sezione 3.4). Una volta ricevuto l'identificatore Session, il client DEVE restituirlo in ogni richiesta relativa a quella sessione. Il server non deve impostare un identificatore se ha altri mezzi per identificare la sessione, ad es. URL generati dinamicamente.
Session = "Session" ":" session-id [ ";" "timeout" "=" delta-seconds ]
Il parametro timeout è ammesso solo nell'intestazione di risposta. Il server lo usa per indicare per quanto tempo è disposto ad attendere tra comandi RTSP prima di chiudere la sessione per inattività (appendice A). Il timeout è in secondi, predefinito 60.
Nota: l'identificatore di sessione identifica una sessione RTSP al di là delle sessioni o connessioni di trasporto. Più URL RTSP possono essere controllati nella stessa sessione RTSP se tutti i flussi provengono dallo stesso server (esempio sezione 14). Più sessioni «utente» per lo stesso URL dallo stesso client DEVONO usare identificatori diversi.
L'identificatore serve a distinguere più richieste di consegna per lo stesso URL dallo stesso client.
Risposta 454 (Session Not Found) se l'identificatore non è valido.
12.38 Timestamp
L'intestazione generale Timestamp indica quando il client ha inviato la richiesta al server. Il valore ha significato solo per il client e può usare qualsiasi scala temporale. Il server DEVE fare eco dello stesso valore esatto e PUÒ, se dispone di informazioni accurate, aggiungere un numero in virgola mobile con i secondi trascorsi dalla ricezione della richiesta. Il client usa il timestamp per calcolare il round-trip time e regolare il timeout delle ritrasmissioni.
Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ]
delay = *(DIGIT) [ "." *(DIGIT) ]
12.39 Transport
Questa intestazione di richiesta indica quale protocollo di trasporto usare e ne configura i parametri, come indirizzo di destinazione, compressione, TTL multicast e porta di destinazione per un singolo flusso. Imposta valori non già fissati dalla descrizione della presentazione.
I trasporti sono separati da virgole in ordine di preferenza. Parametri aggiuntivi per ogni trasporto sono separati da punto e virgola.
L'intestazione Transport PUÒ anche servire a modificare alcuni parametri di trasporto. Il server PUÒ rifiutare di modificare parametri di un flusso esistente.
Il server PUÒ restituire un'intestazione Transport nella risposta con i valori effettivamente scelti.
Se l'intestazione di richiesta contiene un elenco di opzioni accettabili al client, il server DEVE restituire una singola opzione scelta.
La sintassi dello specificatore di trasporto è transport/profile/lower-transport. Il valore predefinito di lower-transport dipende dal profilo; per RTP/AVP il predefinito è UDP.
Parametri generali:
unicast | multicast: indicazione mutuamente esclusiva; predefinito multicast. Client che supportano entrambi DEVONO indicarlo con due transport-spec completi con parametri separati.
destination: indirizzo a cui verrà inviato il flusso. Per evitare di diventare involontariamente artefici di attacchi DoS remoti, il server DOVREBBE autenticare il client e registrare tali tentativi prima di consentire di dirigere un flusso verso un indirizzo non scelto dal server. Particolarmente importante se i comandi RTSP passano su UDP; il TCP da solo non è affidabile per identificare il client. Il server NON DOVREBBE consentire di dirigere flussi verso indirizzi diversi da quello d'origine dei comandi.
source: se l'indirizzo sorgente del flusso non è deducibile dall'endpoint RTSP (server in riproduzione o client in registrazione), la sorgente PUÒ essere specificata. L'autorità dovrebbe essere la risposta SETUP, non solo SDP.
layers: numero di strati multicast per questo flusso, inviati a indirizzi consecutivi a partire dalla destinazione.
mode: metodi supportati per questa sessione; valori validi PLAY e RECORD; predefinito PLAY.
append: con RECORD indica che i dati si accodano alla risorsa esistente invece di sovrascriverla. Se richiesto e non supportato, il server DEVE rifiutare invece di sovrascrivere. Ignorato se mode non contiene RECORD.
interleaved: implica mescolare il flusso multimediale con il flusso di controllo (sezione 10.12); l'argomento è il numero di canale per l'istruzione $. Può essere un intervallo, es. interleaved=4-5.
Specifici multicast: ttl (time-to-live).
Specifici RTP: port (coppia RTP/RTCP multicast), client_port e server_port (coppie unicast), ssrc (solo unicast, SSRC RTP da associare al flusso).
Transport = "Transport" ":" 1#transport-spec
transport-spec = transport-protocol/profile[/lower-transport] *parameter
transport-protocol = "RTP"
profile = "AVP"
lower-transport = "TCP" | "UDP"
parameter = ( "unicast" | "multicast" ) |
";" "destination" [ "=" address ] |
";" "interleaved" "=" channel [ "-" channel ] |
";" "append" |
";" "ttl" "=" ttl |
";" "layers" "=" 1*DIGIT |
";" "port" "=" port [ "-" port ] |
";" "client_port" "=" port [ "-" port ] |
";" "server_port" "=" port [ "-" port ] |
";" "ssrc" "=" ssrc |
";" "mode" "=" "\"" 1#Method "\"" | Method
ttl = 1*3(DIGIT)
port = 1*5(DIGIT)
ssrc = 8*8(HEX)
channel = 1*3(DIGIT)
address = host
Esempio: Transport: RTP/AVP;multicast;ttl=127;mode="PLAY", RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"
Un solo flusso RTP; semplifica i firewall.
12.40 Unsupported
Elenco funzionalità non supportate; con Proxy-Require il proxy DEVE inserire «551 Option Not Supported». Esempio in 12.32.
12.41 User-Agent
Vedere [H14.42].
12.42 Vary
Vedere [H14.43].
12.43 Via
Vedere [H14.44].
12.44 WWW-Authenticate
Vedere [H14.46].