Utilizzare questa pagina per configurare le impostazioni del contenitore SIP per SIP (Session Initiation Protocol).
Per visualizzare questa pagina della console di gestione, fare clic su
.Specifica il numero massimo di sessioni dell'applicazione SIP gestite dal contenitore. Una volta raggiunto il numero massimo, non viene avviata più alcuna nuova conversazione SIP. Se vengono superati i limiti del contenitore in un ambiente cluster, il server non inoltra nuovi dialoghi finché il contenitore non riscende sotto la soglia.
Le sessioni delle applicazioni vengono di solito create da nuove chiamate in ingresso, ma possono essere create anche da altri eventi. Il conteggio di sessioni dell'applicazione non impatta il failover, ma è valido solo per le nuove sessioni create come risultato delle richieste in arrivo.
Quando le sessioni dell'applicazione sono trasferite da un server delle applicazioni a un altro a causa di un failover, il server delle applicazioni rimanente eredita le sessioni inizialmente create sul server che ha riportato l'errore. Inoltre, il servlet può creare la sessione di una nuova applicazione nel contenitore SIP richiamandoSipFactory.createApplicationSession().
Le nuove sessioni di applicazioni create per eventi diversi da quelli che iniziano le conversazioni SIP non sono controllate da questa impostazione. Tutte le nuove sessioni di applicazione sono incluse quando viene calcolato il numero massimo di sessioni di applicazione consentito. Pertanto, tutte le sessioni delle applicazioni attive, comprese quelle non relative all'avvio delle conversazioni SIP, possono causare il superamento del valore massimo.
Tipo dati | Numero intero |
Valore predefinito | 120000 (consigliato) |
Intervallo | 1 <= n <= java.lang.Integer.MAX_VALUE |
Specifica la quantità massima di messaggi SIP per periodo di media. Il periodo di media è il periodo di tempo durante il quale viene calcolato il numero medio di messaggi ricevuti dal contenitore.
Questa media viene utilizzata per determinare il carico per il contenitore e per determinare se il numero di messaggi sta per raggiungere il numero massimo di messaggi. Quando il valore massimo viene superato, il server autonomo o il server proxy continua a gestire tutti i messaggi di dialogo. Le altre richieste vengono rifiutate. Quando il contenitore è in uno stato di sovraccaricato, il server proxy restituisce un errore 503.
Tipo dati | Numero intero |
Valore predefinito | 5000 (consigliato) |
Intervallo | 1 <= n <= java.lang.Integer.MAX_VALUE |
Specifica la dimensione della coda di distribuzione interna. Quando la soglia di dimensione massima della coda viene raggiunta, il contenitore viene sovraccaricato e inizia a rifiutare le richieste per nuove sessioni. In questo caso, il contenitore non riporta il proprio stato di sovraccaricamento al server proxy.
Configurare il sistema per limitare la dimensione della coda per impedire che la coda raggiunga questo valore soglia. Se la coda interna raggiunge lo stato di sovraccaricamento, i pacchetti UDP in entrata verranno rilasciati finché la coda non uscirà dal suddetto stato. Limitando la dimensione della coda si ottiene un migliore ripristino rispetto al caso in cui la CPU viene utilizzata da altri processi o thread (ad esempio, la raccolta dati inutili) e impedisce che il contenitore raggiunga le condizioni di memoria esaurita. Se questo valore viene impostato su 0, allora la dimensione della coda è illimitata.
Tipo dati | Numero intero |
Valore predefinito | 5000 (consigliato) |
Intervallo | 0 <= n <= java.lang.Integer.MAX_VALUE |
Specifica il tempo massimo di risposta, espresso in millisecondi, per un'applicazione. Quando il valore di tale parametro supera il tempo specificato, il contenitore notifica alla struttura del cluster che non è disponibile. È possibile disabilitare questa funzione nella console di gestione annullando la selezione della casella di controllo e specificando il valore 0.
Utilizzare con attenzione il parametro del tempo di risposta massimo perché il tempo di risposta calcolato non corrisponde alla funzionalità di tutte le applicazioni. Per richieste come ad esempio INVITE, in cui le risposte vengono generate come risultato di un'interazione utente (un utente che solleva il ricevitore, ad esempio), il tempo di risposta calcolato è esteso. Tuttavia, in questo esempio, il tempo di risposta esteso non è causato da un ritardo nel contenitore SIP. Quindi, non occorre calcolare il tempo di risposta come fattore di carico. Le applicazioni consigliate per un calcolo effettivo del tempo di risposta sono quelle che rispondono subito senza interazione dell'utente. Tra gli esempi più efficaci, vanno annoverate le applicazioni di sottoscrizione e registrazione.
Tipo dati | Numero intero |
Valore predefinito | 0 |
Intervallo | 1 <= n <= java.lang.Integer.MAX_VALUE |
Specifica i pool di thread disponibili che è possibile selezionare dall'elenco a discesa per l'utilizzo da parte del contenitore SIP nella distribuzione del lavoro. Se dall'elenco a discesa non viene selezionato un pool di thread, viene utilizzato un pool di thread predefinito creato automaticamente dal contenitore.
Si consiglia di creare un pool di thread WebSphere dedicato per le applicazioni SIP. Per un uso generale, indica un numero minimo di 15 thread e un numero massimo di 30 thread (con un thread per coda). Diventa conveniente quando è associato con il rilevamento di thread bloccati WebSphere. Un thread bloccato può bloccare diversi messaggi SIP, quindi è importante che sia rilevato quanto prima. Tuttavia, la soglia predefinita di rilevamento del thread bloccato è molto lunga per la maggior parte degli scenari SIP, quindi è preferibile modificarla in 30 secondi. Consultare la sezione "Configurazione della politica di rilevamento blocco" (riportata di seguito) per i nomi di proprietà appropriati.
Tipo dati | elenco menu |
Valore predefinito | Nessuno |
I bind contrassegnati (online) richiedono un accesso a Internet.