Utilizaţi această pagină pentru a configura setările containerului SIP pentru Session Initiation Protocol (SIP).
Pentru a vizualiza această pagină de consolă administrativă, apăsaţi pe Servere de aplicaţii > serverName > Setări container SIP > Container SIP.
Specifică faptul că, atunci când este adevărat, containerul SIP presupune existenţa Proxy-ului SIP care rulează pe alt proces de server şi,l prin urmare, delegă traficul de ieşire rutare la acea componentă.
Tip de date | Boolean |
Implicit | Adevărat |
Specifică numărul maxim de sesiuni de aplicaţie SIP pe care le gestionează containerul. Când se atinge maximul, nu se porneşte nici o conversaţie SIP nouă. Când se depăşeşte maximul într-un mediu pus în cluster, serverul nu înaintează noi dialoguri până când numărul de sesiuni de aplicaţie nu scade sub maxim.
Sesiunile de aplicaţie sunt de obicei create de apeluri de intrare noi, dar pot fi create şi de alte evenimente. Numărul sesiunilor de aplicaţie nu are impact asupra preluării la eroare, dar se aplică numai pentru noile sesiuni care sunt create ca rezultat al apelurilor de intrare.
Când sesiunile de aplicaţie sunt transferate de la un server de aplicaţii la altul din cauza preluării la eroare, serverul de aplicaţii activ moşteneşte sesiunile create pe serverul care a eşuat. În plus, servletul ar putea crea o nouă sesiune de aplicaţie în containerul SIP apelând SipFactory.createApplicationSession().
Sesiunile de aplicaţie noi create pentru evenimente diferite de pornirea conversaţiilor SIP nu sunt controlate de această setare. Dar toate sesiunile de aplicaţie noi sunt incluse atunci când se calculează numărul maxim de sesiuni de aplicaţie permise. Prin urmare, toate sesiunile de aplicaţie active, inclusiv cele care nu sunt legate de pornirea conversaţiilor SIP, pot duce la depăşirea maximului.
Tip de date | Întreg |
Implicit | 120000 (recomandat) |
Interval | 1 <= n <= java.lang.Integer.MAX_VALUE |
Specifică numărul maxim de mesake SIP procesare per perioadă de mediere. Perioada de mediere este perioada în care se calculează numărul mediu de mesaje primite de container.
Această medie este utilizată pentru a determina sarcina containerului şi pentru a determina dacă numărul de mesaje se apropie de maxim. Când se depăşeşte maximul, serverul independent sau serverul proxy continuă să manipuleze toate mesajele în-dialog. Alte cereri non-dialog sunt respinse. Când un container este într-o stare de supraîncărcare, serverul proxy returnează o eroare 503.
Tip de date | Întreg |
Implicit | 5000 (recomandat) |
Interval | 1 <= n <= java.lang.Integer.MAX_VALUE |
Specifică dimensiunea cozii de dispecerizare interne. Când se atinge pragul dimensiunii maxime a cozii, coada containerului devine supraîncărcată şi începe să abandoneze cereri pentru sesiuni noi. În acest caz, containerul nu-şi raportează starea de supraîncărcare la serverul proxy.
Configuraţi-vă sistemul să limiteze dimensiunea cozii pentru a o împiedica să atingă acest prag. Dacă coada internă ajunge în starea de supraîncărcare, pachetele UDP de intrare sunt abandonate până când coada nu mai este în starea de supraîncărcare. Limitarea dimensiunii cozii permite o mai bună recuperare dacă CPU este utilizat de alte procese sau fire de execuţie şi împiedică containerul să ajungă în condiţii de lipsă de memorie. Când valoarea este setată la 0, dimensiunea cozii este nelimitată.
Tip de date | Întreg |
Implicit | 5000 (recomandat) |
Interval | 0 <= n <= java.lang.Integer.MAX_VALUE |
Specifică timpul maxim de răspuns, în milisecunde, pentru o aplicaţie. Când se depăşeşte durata, containerul notifică cadrul de lucru de funcţionare în cluster că este indisponibil. Puteţi dezactiva această caracteristică în consola administrativă deselectând caseta de bifare şi specificând valoarea 0.
Utilizaţi cu grijă setarea timpului de răspuns SIP maxim pentru că timpul de răspuns calculat nu se potriveşte comportamentului tuturor aplicaţiilor. Pentru cereri, cum ar fi cererile INVITE, unde răspunsurile sunt generate ca rezultat al unei interacţiuni de utilizator, timpul de răspuns calculat este extins. Totuşi, timpul de răspuns extins nu este determinat de o întârziere în containerul SIP. Prin urmare, nu ar trebui să calculaţi timpul de răspuns ca factor de încărcare. Aplicaţiile recomandate pentru calculul eficient al timpului de răspuns sunt aplicaţiile care răspund imediat fără o interacţiune cu utilizatorul. Aplicaţiile de abonare şi înregistrare sunt exemple relevante.
Tip de date | Întreg |
Implicit | 0 |
Interval | 1 <= n <= java.lang.Integer.MAX_VALUE |
Specifică durata în milisecunde de utilizat pentru calcularea numărului maxim de mesaje per perioadă de mediere. Această setare este fereastra glisantă prin care containerul SIP numără mesajele trimise la container.
Tip de date | Întreg |
Implicit | 1000 (recomandat) |
Interval | 1000 <= n <= java.lang.Integer.MAX_VALUE |
Specifică controlul asupra intervalului pentru care containerul calculează medii şi publică statistici la PMI (Performance Monitoring Infrastructure).
Tip de date | Întreg |
Implicit | 1000 (recomandat) |
Interval | 1000 <= n <= java.lang.Integer.MAX_VALUE |
Specifică dacă să se activeze localizarea serverelor SIP utilizând DNS (Directory Name Service).
Un URI (Uniform Resource Identifier) SIP poate fi rezolvat prin DNS în adresa IP (Internet Protocol), portul şi protocolul de transport ale următorului hop.
Tip de date | Boolean |
Implicit | Fals |
Tip de date | Şir |
Implicit | şir gol. |
Tip de date | Şir |
Implicit | şir gol. |
Specifică pool-urile de fire de execuţie disponibile pe care le puteţi selecta din lista derulantă pentru containerul SIP de utilizat când se dispecerizează lucrul. Dacă nu selectaţi un pool de fire de execuţie din lista derulantă, se utilizează un pool de fire de execuţie implicit, care este creat automat de container.
Se recomandă să creaţi un pool de fire de execuţie WebSphere dedicat pentru aplicaţii SIP. Pentru utilizare generală, există un minim de 15 fire de execuţie şi un maxim de 30 de fire de execuţie (cu un fir de execuţie per coadă). Acest lucru este convenabil când este combinat cu detecţia firului de execuţie WebSphere suspendat. Un fir de execuţie suspendat poate bloca multe mesaje SIP, aşadar este important să fie detectat cât mai repede posibil. Totuşi, pargul de detecţie al firelor de execuţie suspendate este prea lung pentru majoritatea scenariilor SIP, aşadar se recomandă să-l modificaţi la 30 de secunde. Consultaţi subiectul "Configurarea politicii de detecţie a suspendării" (cu legătură mai jos) pentru numele exacte ale proprietăţilor.
Tip de date | listă meniu |
Implicit | Fără |
Legăturile marcate (online) necesită acces la internet.