5.3. Scambio di capacità

Due peer che stabiliscono il trasporto DEVONO scambiare i messaggi Capabilities Exchange come nella macchina a stati (sezione 5.6). Si scoprono identità e capacità (versione, Application Id supportate, sicurezza).

Il ricevente emette comandi solo verso peer che hanno annunciato l'applicazione che definisce il comando. Un nodo DEVE memorizzare le Application Id supportate per non inviare comandi/AVP sconosciuti inutilmente.

Senza applicazioni comuni sul CER, il ricevente DEVE rispondere CEA con DIAMETER_NO_COMMON_APPLICATION e DOVREBBE chiudere il trasporto. CER/CEA da peer che si dichiara relay (sezione 2.4) si interpretano come applicazioni comuni (MUST).

Il ricevente del CER DEVE calcolare l'intersezione con Auth-, Acct- e Vendor-Specific-Application-Id nel CER; il Vendor-Id dentro Vendor-Specific-Application-Id NON deve entrare nel calcolo (MUST NOT). Il mittente del CEA DOVREBBE elencare tutte le applicazioni come suggerimento.

Le implementazioni DOVREBBERO tentare prima TLS/TCP e DTLS/SCTP prima di CER/CEA. Per implementazioni vecchie la sicurezza può ancora negoziarsi con Inband-Security AVP (MAY). Senza meccanismi comuni, CEA con DIAMETER_NO_COMMON_SECURITY e DOVREBBE chiusura trasporto (MUST/SHOULD).

CER da sconosciuti possono essere scartati o ricevere CEA DIAMETER_UNKNOWN_PEER (MAY); in entrambi i casi si chiude. Policy locali possono consentire CEA di successo; la vita della voce peer coincide col trasporto.

CER e CEA NON DEVONO essere proxy, redirect o relay (MUST NOT).

Senza proxy CER/CEA, un agent a monte può non avere peer per l'applicazione del Command Code: nella risposta bit E e DIAMETER_UNABLE_TO_DELIVER (sezione 7).

Salvo CER, richieste con Auth- o Acct-Application-Id o Command Code applicativo possono essere inoltrate solo a host che hanno annunciato l'applicazione (o Relay Application Id) (MAY).