წიგნის ძირითადი წყაროები არიან ცისკოს წიგნები და

ბევრი სხვა ინტერნეტში მოძიებული მასალა რომელიც

დამუშავებულია ჩემს მიერ და შესაძლოა შეიცავდეს არა
ერთ შინაარსობრივ შეცდომას. არარედაქტირებული
ვერსია ავტორი ცოტნე კაპანაძე
19/10/2022

Session Initial Protocol

(SIP)
SIP კომუნიკაციების პროტოკოლი რომელიც მოიცავს Hyper Transfer Protocol (HTTP) და Simple
Mail Transfer Protocol (SMTP) - ის ბევრ ელემენტს. SIP-ს აქვს შესაძლებლობა იმუშაოს სხვა
პროტოკოლებთან ერთად, რომლებიც საჭიროა საკომუნიკაციო სესიების შესაქმნელად და
მხარდასაჭერად, ნათ შორის არიან შემდეგი პროტოკოლები:

• Real-Time Transport protocol (RTP) რეალურ დროში ტრანსპორტირების პროტოკოლი

• Session Description Protocol (SDP) სესიის აღწერის პროტოკოლი
• Resource Reservation Protocol (RSVP) რესურსების დაჯავშვნის პროტოკოლი

SIP მუშაობს მოთხოვნა პასუხის ჩარჩოში (request/response) და ასახავს HTTP - ის მსგავს მოდელს,
SIP მოთხოვნის ინიციატორი არის UAC (user agent client მომხმარებელი აგენტი კლიენტი),
ხოლო რომელიც მოთხოვნას ამუშავებს და აგზავნის მინიმუმ ერთ პასუხს ეწოდება UAS (user
agent server მომხმარებელი აგენტი სერვერი) კონცეპტი SIP ტრანზაქციისა და SIP დიაოგის არის
ურთიერთქმედებები UAC და UAS - ს შორის. SIP ტრანზაქციის პასუხები მოთხოვნაზე შეიძლება
შეიცავდეს ნულს ან მეტ საბოლოო პასუხებს (1XX, 2XX, 3XX, 4XX, 5XX, 6XX) რასაც მოგვიანებით ამ
დოკუმენტში ავღწერ.
SIP დიალოგი მომხმარებელსა და აგენტს შორის არის peer-to-peer. ერთი SIP დიალოგი
შეიძლება შეიცავდეს მრავალ SIP ტრანზაქციას, გარიგება შედგება მოთხოვნისა და პასუხისგან
ამ მოთხოვნაზე.

მოცემულ დიალოგში რომელიც ფოტოზეა ასახული UAC აგზავნის invite შეტყობინებას UAS -
თან სესიის დამყარების მიზნით, შემდეგ UAS-ი რომელიც იღებს invite შეტყობინებას,
უბრუნებს 200 OK პასუხს, UAC-მა უნდა მიიღოს 200 OK შეტყობინება invite ტრანზაქციისთვის
და შემდეგ ის აგზავნის ACK მოთხოვნას. ამ ეტაპის შემდეგ სესია დამყარებულია და ის
გრძელდება მანამ სანამ ერთ ერთი მხარე არ გადაწყვეტს სესიის დასრულებას და როდესაც ეს
მოხდება, ერთი მხარე აგზავნის BYE შეტყობინებას ამ შემთხვევაში UAC. UAS ღებულობს BYE
შეტყობინებას და პასუხობს 200 OK.

SIP იყენებს TCP ან UDP პროტოკოლს მაგრამ ხშირ შემთხვევაში გამოიყენება UDP პროტოკოლი,
იქიდან გამომდინარე რომ TCP უფრო ხაზს უსვამს სანდოობას ვიდრე დროულობას.

Transport Layer Security

TLS
UAC და UAS-ებს შორის გაცვლილი შეტყობინებები შეიცავს ბევრ ინფორმაციას, რაც შეიძლება
არა კეთილი ზრახვებით იქნას გამოყენებული თუ ეს ინფორმაცია სხვას ჩაუვარდება ხელში.
მაგალითად SIP INVITE შეიცავს ინფორმაციას რომელმაც შესაძლოა გამოავლინოს ქსელის
ტოპოლოგიის დეყტალები, მოწყობილობის ტიპი ან მედია სტრიმის დეტალები როგორიცაა
აიპი მისამართები და პორტის ნომრები. ეს განსაკუთრებით პრობლემურია როდესაც
საკომუნიკაციო სესიები მოიცავს ღია ქსელებს, შეტევების თვიდან ასაცილებლად,
შესაძლებელია SIP სიგნალის დაცვა ტრანსპორტის ფენის უსაფრთხოების გამოყენებით
Transport Layer Security (TLS) პორტის ნომერი რომელიც გამოიყენება SIP-ისთვის TLS-ზე არის
5061.

-----
SIP ქსელში რესურსები იდენტიფიცირებულია ერთიანი რესურსების იდენტიფიკატორის
მიერ (URI) Uniform Resource Identifier რომლის ზოგადი ფორმატია
SIP:username:password@host:port

SIP Devices
SIP მოწყობილობები მოიხსენიება როგორც user agents (მომხმარებლის აგენტები) და
შეიძლება იყოს მოწყობილობები როგორიცაა აიპი ტელეფონები, ქოლსერვერები, ფაქს
სერვერები, გეითვეები.

SIP-ის ფუნქციური კომპონენტები

SIP proxy: არის მოწყობილობა რომელსაც შეუძლია შეასრულოს ზარის მარშუტიზაცია,
ავთენტიფიკაცია, ატორიზაცია, დატვირთვის დაბალანსება.

Redirect server: გადამისამართების სერვერი არის არის, რომელიც უზრუნველყოფს

მომხმარებლის ადგილმდებარეობის სერვისებს, user agent - ებისთვის ან პროქსისთვის
მოთხოვნებზე პასუხის გაცემით ან ჰოსტთან მარშუტით. ის ეხმარება პროქს ან
მომხმარებლის აგენტს რომ დაუკავშირდეს ჰოსტს Redirect server პასუხობს მოთხოვნებს
3XX პასუხით რომლის საკონტაქტო ჰედერი შეიცავს ჰოსტის მისამართს URI-ის.

Registar server: არის რომელიც იღებს რეგისტრაციის მოთხოვნებს user agent-ებისგან.

Location server: მდებარეობის სერვერი არ საჭიროებს ცალკე ფიზიკურ სერვერს და

შეიძლება ლოგიკურად კოლოკილებური იყოს Registar server-თან.

B2BUA: არის მოწყობილობა რომლებსაც აქვთ როგორც UAC ასევე UAS ფუნქციონირეა და
შეუძლიათ გადააგზავნონ მოთხოვნები და დაამუშაონ ისინი.

SIP Requests
INVITE : დამრეკი აგზავნის ამ შეტყობინებას რომ მოითხოვოს სხვა მოწყობილობასთან SIP
სესიის დამყარება.

ACK : ეს მიუთითებს იმაზე რომ, კლიენტმა მიიღო საბოლოო პასუხი INVITE

მოთხოვნაზე.

OPTIONS : ეს მოთხოვნა ითხოვს სერვერს.

BYE : იყენებს UAC როცა მას სურს შეწყვიტოს SIP სესია.

CANCEL : ეს გამოიყენება მომლოდინე მოთოვნის გასაუქმებლად და მისი გაგზავნა

შესაძლებელია მხოლოდ იმ შემთვევაში თუ სერვერმა არ უპასუხა საბოლოო პასუხით.

REGISTER : კლიენტი იყენებს ამ შეტყობინებას სერვერთან რესგისტრაციისთვის.

PRACK : provisional პასუხები მიიღება.

SUBSCRIBE : ეს ქმნის გამოწერას მნიშვნელოვან event შეტყობინებისთვის.

NOTIFY : აცნობებს კლიენტს მოვლენის შემთხვევის შესახებ.

INFO : საშუალებას იძლევა ინფორმაციის გაცვლის კომუნიკაციის სუბიექტებს შორის.

PUBLISH : აქვეყნებს ივენთებს სერვერზე.

REFER : ავალებს მიმღებს დაუკავშირდეს სხვა სუბიექტს.

UPDATE : ეს ცვლის სესიის მდგომარეობას დიალოგის მდგომარეობის შეცვლის გარეშე.

MESSAGE : აგზავნის ტექსტურ შეტყობინებებს SIP-ის გამოყენებით.

SIP Response Classes

1XX - ინფორმაციული: მოთხოვნა მიღებულია და მუშავდება.

2XX - წარმატებული: მოთხოვნა მიღებულია და გასაგები.

3XX - გადამისამართება: მოთხოვნის დასასრულებლად საჭიროა შემდგომი ზომების

მიღება. მაგალითდ, UAC-ს უნდა დაუკავშირდეს სხვა სერვერს მოთხოვნის
დასამუშავებლად.

4XX - კლიენტის შეცდომა: მოთხოვნა შეიცავს ცუდ სინტაქსს (malformed headers) ან ვერ
შესრულდება სერვერზე. მაგალითად, თუ სერვერმა ვერ იპოვა მოთხოვნილ URI-ში
მითითებული ნომერი.

5XX - სერვერის შეცდომა: სერვერმა ვერ შეასრულა მოქმედი მოთხოვნა.

6XX – Global Failure: მოთხოვნა ვერ შესრულდება ვერცერთ სერვერზე.

SIP CALL
სანამ დეტალურად გავივლით თუ როგორ ხდება საკომუნიკაციო სესიის დამყარება SIP-ის
მეშვეობით, მნიშვნელოვანია იმის გაგება, თუ როგორ ქმნის მოთხოვნას ინიციატორი UAC
და როგორ ამუშავებს UAS საბოლოო მოთოვნას, SIP-ის სტანდარტებზე დაფუძნებული
მოთხოვნის ფორმებია:

Request-URI : ზოგადად SIP ქსელში თითოეული რესურსი იდენტიფიცირებულია URI -ის

მიერ, რომელიც გამოხატულია როგორც SIP URI ან SIPS URI (SIP Secure URI). კერძოდ SIP
request მოთხოვნის ფარგლებში , request URI header-ი განსაზღვრავს რესურსს, რომელიც
ამუშავებს მოთხოვნას.

VIA : ჰედერის ველი მიუთითებს სატრანსპორტო ფენის პროტოკოლზე რომელიც

გამოიყენება SIP შეტყობინებების გაცვლისთვის.

FROM : ამ სათაურის ველი მიუთითებს მომხმარებლის აგენტის იდენტურობაზე,

რომელიც არის ინიციატორი და იწყებს მოთხოვნას URI-ის სახით. ეს ჰედერი ასევე
შეიძლება შეიცავდეს ინიციატორის სახელსაც. SIP-ზე დამყარებული მედია სესიისას,
ჰედერის ველში ნაჩენები სახელი არის აბონენტის Caller ID-ი.

TO : ამ ჰედერის ველში ჩვეულებისამებრ განსაზღვრავს იმ ერთეულს რომელმაც უნდა

დაამუშაოს მოთოვნა და დასახელებულია SIP URI-ის გამოყენებით ეს ერთეული ჰედერში
შეიძლება იდენტიფიცირებული იყოს ან არ იყოს ფაქტობრივი UAS-ი რომელმაც უნდა
დაამუშაოს მოთხოვნა, სინამდვილეში იდენტიფიცირებული ერთეული ყოველთვის არ
არის ის ვინც უნდა დაამუშაოს მოთოვნა, როდესაც მოთხოვნა გადის რამოდენიმე ჰოპს.
მოთხოვნის დიალოგის გენერირებისას (როგორიც არის SIP INVITE) არ უნდა იყოს ტეგის
პარამეტრი TO header ველში. ტეგ პარამეტრი შეივსება მომხმარელის მიერ რომელიც
დაამუშავებს მოთხოვნას.

Call ID : ამ ჰედერის ველი ცალსახად განსაზღვრავს ყველა შეტყობინებას, რომელიც

ეკუთვნის SIP დიალოგს. SIP დიალოგი იდენტიფიცირდება CALL ID ჰედერში FROM-
ტაგში და TO-ტაგში. SIP დიალოგი შეიძლება შეიცავდეს რამდენიმე SIP ტრანზაქციას,
CALL ID ჰედერის ველის value გენერირდება UAC-ის ნიერ და ინახება შეტყობინებებში
რომლებიც ეგზავნება UAS-ს. CALL ID უნდა იყოს უნიკალური. მომხმარებლის აგენტი
დარწმუნებული უნდა იყოს, რომ ამ ჰედერის ველი გენერირდება ისე, რომ
გარანტირებული იყოს რომ არ არის კვეთა CALL ID ველთან კიდევ სხვა SIP დიალოგში.
CALL ID ჰედერი ზოგჯერ შეიძლება შეიცავდეს აიპი მისამართს, ინფორმაციას
ინიციატორი აგენტის დომენის სახელის შესახებ.

MAX-FORWARDS : ამ ჰედერის ველი ახდენს ჰოპების ლიმიტირებას რომლებიც

მოთხოვნამ უნდა გაიაროს სანამ ის საბოლოო დანიშნულების ადგილს მიაღწევს. ყველა
კვანძი, რომელიც იღებს მოთხოვნას ნაწილობრივ ან მთლიანად ამუშავებს SIP requests.
ნაწილობრივი დამუშავება შეიძლება მოიცავდეს სინტაქსური შემოწმების გაშვებას,
ჰედერის ველების დამატებას, ან ზოგჯერ მოთხოვნის შეცვლას, სანამ ის შემდეგ ჰოპს
გადაეცემა. მოთხოვნის სრული დამუშავების შემდეგ ცხრილში ჩამოთვლილი ექვსი
პასუხის კლასიდან ერთი ან მეტის გაგზავნა. ყველა კვანძი (node) , რომელიც ნაწილობრივ
ამუშავებს მოთხოვნას ამცირებს MAX-Forward-ის ჰედრის ველის value-ს ერთით, სანამ
მოთხოვნია გაუგზავნის შემდეგ ჰოპს, თუ მოთხოვნა მიიღო მომხმარებელის აგენტმა ან
პროქსიმ, რომელიც არ არის მოთხოვნის საბოლოო დანიშნულება, შემოწდება MAX-
Forward-ის ჰედერის ველის value და თუ ეს ნულია ნაშინ მოთხოვნა იქნება უარყოფილი.
(request is rejected with a 483 too many hops response) თუ ის არაა ნული, მაშინ გადადის
შემდეგ ჰოპზე.

CSeq : ეს ჰედერის ველი გამოიყენება დიალოგში ტრანზაქციების შესაკვეთად. იგი

ფორმატირებულია შემდეგნაირად: CSeq: <sequence-Number><Method> სადაც <method>
არის SIP request-ი აქ ჩამოთვლილი ჰედერის ველები საჭიროა ყველა ტიპის SIP
მოთხოვნისთვის. ამასთან, ასევე შეიძლება საჭირო გახდეს დამატებითი ჰედერის ველები,
რაც დამოკიდებულია SIP request მეთოდის ტიპის მიხედვით. მაგალითდ, SIP INVITE
მოითხოვს დამატებით ჰედერის ველებს, რომლებიც თნ ახლავს სავალდებულო ჰედერის
ველებს, რომლებიც ეფექტურად უნდა დამუშავდეს UAS-ის მიერ. SIP INVITE-ისთვის
საჭიროა შემდეგი დამატებითი ჰედერის ველები:

Contact : ამ ჰედერის ველი უზრუნველყოფს SIP/SIPS URI-ის, რომლის დროსაც

მომხმარებლის აგენტი შეიძლება დაუკავშირდეს შემდგომ მოთოვნებს. მაგალითდ
განვიხილოთ აუდიო ზარი, რომელიც უკვე დამყარებულია UAC-სა და UAS-ს შორის და
UAS-ს შეიძლება დასჭირდეს შუამავლობის მოთხოვნის გაგზავნა UAC-თან, ამისათვის ის
იყენებს SIP ან SIPS URI-ს, რომელიც მითითებულია საკონტაქტო ჰედერის ველში.
გაითვალისწინეთ, რომ საკონტაქტო ჰედერის ველის გამოყენება არ შემოიფარგლება
მხოლოდ INVITE მოთხოვნებით. ეს ჰედერის ველი წარმოდგენილია SIP INVITE და სხვა
SIP მეთოდების საპასუხოდ, როდესაც გამოიყენება.

Allow : რეკომენდირებულია რომ allow ჰედერის ველი იყოს SIP INVITE -ში. ამ ჰედერის
ველი რეკლამირებს SIP-ის სხვადასხვა მეთოდებს, რომელთა მიღება შესაძლებელია UAC-
ზე SIP INVITE-ის მოთხოვნით ინიცირებული დიალოგის ფარგლებში. Allow ველის
შევსება საშუალებას აძლევს UAS-ს გაიგოს მოთხოვნების ტიპები, რომლებიც შეიძლება
გაიგზავნოს UAC-თან SIP დიალოგის დროს. მაგალითდ, თუ UAS-სურს DTMF
ინფორმაციის გადაცემა SIP INFO შეტყობინების გამოყენებით, მას შეუძლია ამის გაკეთება
მხოლოდ იმ შემთვევაში თუ UAC-ის SIP INFO შეტყობინებაში მხარდაჭერა არის INVITE-
ის ჰედერის ველში. მაგალითდ: Allow: INVITE, ACK, CANCEL, BYE, REGISTER, REFER,
INFO, SUBSCRIBE, NOTIFY,PRACK, UPDATE, OPTIONS. მიუხედავად იმისა, რომ
რეკომენდირებულია UAC-მა Allow ჰედერ ველში შეიტანოს INVITE მოთოვნა, შეიძლება
არსებობდეს შემთხვევები როცა ამ ჰედერის ველში INVITE არაა შეტანილი, ასეთ
შემთვევაში UAS-მა არ უნდა ჩათვალოს, რომ UAC არ უჭერს მხარს არცერთ მეთოდს, ის
უნდა განიმარტოს როგორც UAC-ის სურვილის. UAS-s შეუძლია გააგზავნოს მოთოვნები,
რომლებიც საჭიროა კომუნიკაციის სესიის შემდგომი ინსვლისთვის, თუმცა თუ მთოდი
არ არის დაფიქსირებული UAC-ის მიერ ეს მოთხოვნები უარყოფილი იქნება 405 -
მეთოდის გამოყენებით Not allowed response.

Supported : UAC-მა შეიძლება გამოიყენოს ამ ჰედერის ველი სხვადასხვა გაფართოებების

დასამატებლად, UAS-მა შეიძლება გამოიყენოს ეს გაფართოებები SIP request-ის
საპასუხოდ, მაგალითად თუ UAC მოიცავს ტაიმერის გაფართოებას Supported ჰედერის
ველში, ის რეკლამირებს SIP სესიის განახლების მხარდაჭერას UAS-მა შეიძლება
გამოიყენოს ეს გაფართოება სესიის უზრუნველსაყოფად.

Accept : UAC შეიძლება შეიცავდეს Accept ჰედერის ველს, რათა მიუთითოს კონტენტის
ტიპები, რომლებიც მისთვის მისაღებია მოთხოვნების საპასუხოდ ან დიალოგის
ფარგლებში ახალი მოთხოვნებით. ეს ჰედერის ველი საშუალეას იძლევა მომხმარებლის
აგენტებმა მოახდინონ აღწერილობა სხვადასხვა სესიის ფორმატის მხარდაჭერაზე.

Require : SIP INVITE-ში განთავსებული ჰედერის ეს ველი მოიცავს გაფართოებებს SIP-ის

საბაზისო ტეგების გამოყენებით. თითოეული ტეგის ვარიანტი წარმოადგენს SIP
გაფართოებას, რომ სერვერმა მხარი უნდა დაუჭიროს მოთხოვნის დამუშავების მიზნით.
თუ სერვერს არ შეუძლია მხარი დაუჭიროს კონკრეტულ გაფართოებას, მოთხოვნა
უარყოფილი იქნება პასუხით ‘’ცუდი გაფართოება’’ (420 bad extension response)

Expires : ეს ჰედერის ველი შეიძლება დაემატოს UAC-ს მოწვევის მოქმედების შეზღუდვის

მიზნით. მას შემდეგ რაც საკომუნიკაციო სესია დამყარდება, ამ ჰედერის ველს არ აქვს
გავლენა იმ დროის ოდენობაზე, რამდენიც შეიძლება სესია გაგრძელდეს. ვადა გასული
ჰედერის ველის გამოყენება დამოკიდებულია მეთოდზე.

Diversion : ეს ჰედერის ველი გამოიყენება როდესაც ზარი გადამისამართდება ერთი ენდ

ფოინთიდან მეორე ენდ ფოინთზე.

Remote-Party-ID (RPID) : ეს ჰედერი ძირითადად გამოიყენება დამრეკის

იდენტიფიკაციისთვის, ამ ჰედერის ველის მონაცემებს ხშირად ანაცვლებს დამრეკის
იდენტიფიკაციის სხვა ჰედერები როგორიცაა Contact header, From header და ცისკოს აიპი
ტელეფონები იყენებს ამ ინფორმაციას რომ ანახოს დამრეკის ID. თუ არსებობს კიდევ
ერთი ჰედერის ველი, რომელიც ეფექტურად აღწერს იგივეს, არის P-Asserted-Identity
(PAI) ველი.
 Session Description protocol
სესიის აღწერის პროტოკოლი
(SDP)

SDP სესიის აღწერის პროტოკოლი არის ფორმატი, რომელიც აღწერს მულტიმედიური

კომუნიკაციის სესიებს. ის გამოიყენება სტრიმინგის და მედია აპლიკაციების
მხარდასაჭერად. SDP თავად არ აწვდის მედიის ნაკადებს, მაგრამ გამოიყენება ბოლო
წერტილებს შორის ქსელის მეტრიკის, მედიის ტიპებისა და სხვა თვისებების
მოსალაპარაკებლად. თვისებებისა და პარამეტრების კომპლექტს ეწოდება სესიის
პროფილი (session profile).

SDP-გაფართოებულია ახალი მედიის ტიპებისა და ფორმატების მხარდაჭერისთვის. SDP

თვდაპირველად იყო სესიის გამოცხადების (SAP) ის კომპონენტი, მაგრამ იპოვა სხვა
გამოყენება RTP-RTSP და SIP-თნ ერთად, არის როგორც დამოუკიდებელი პროტოკოლი
მულტიკასტის სესიების აღწერისთვის.

სესიის აღწერა
პროტოკოლი აღწერს სესიას, როგორც ველების ჯგუფს ტექსტზე დაფუძნებული
ფორმატით, თითო ველი თითო სტრიქონზე თითოეული ველის ფორმა ასეთია:

<character>=<value><CR><LF>

სადაც <character> არის ერთი case-sensitive სიმბოლო და <value> არის ტექსტის

სტრუქტურირებული ფორმატი, რომელიც დამოკიდებულია სიმბოლოზე, value, როგორც
წესი დაშიფრულია UTF-8 შიფრაციით. სესიის აღწერა შედგება სამი სექციისგან: Session,
Timing, Media description. სესიის, დროისა და მედიის აღწერილობისგან, თითოეული
აღწერა შეიძლება შეიცავდეს რამდენიმე დროისა და მედიის აღწერილობას. სახელები
უნიკალურია ასოცირებული სინტაქსური კონსტრუქციის ფარგლებში.

Session Description

v= (protocol version number, currently only 0)

o= (originator and session identifier : username, id, version number, network address)

s= (session name : mandatory with at least one UTF-8-encoded character)

i=* (session title or short information)

u=* (URI of description)

e=* (zero or more email address with optional name of contacts)

p=* (zero or more phone number with optional name of contacts)

c=* (connection information—not required if included in all media)

b=* (zero or more bandwidth information lines)

One or more time descriptions ("t=" and "r=" lines; see below)

z=* (time zone adjustments)

k=* (encryption key)

a=* (zero or more session n attribute lines)

Time Description
t= (time the session is active)

r=* (zero or more repeat times)

Media Description
m= (media name and transport address)

i=* (media title or information field)

c=* (connection information — optional if included at session level)

b=* (zero or more bandwidth information lines)

k=* (encryption key)

a=* (zero or more media attribute lines — overriding the Session attribute lines)
 Real-Time Transport Protocol
რეალურ დროში სატრანსპორტო პროტოკოლი

რეალურ დროში სატრანსპორტო პროტოკოლი უზრუნველყოფს ხმისა და ვიდეოს end to end

ტრანსპორტირებას. RTP - როგორც წესი მუშაობს UDP/IP-ზე და უზრუნველყოფს built-in loss
გამოვლენას, მიმღების გამოხმაურების წყაროს იდენტიფიცირებას, მნიშვნელოვანი
მოვლენების მითითებას და თანმიმდევრობას.

RTP - ს აქვს peer პროტოკოლი Real-Time Control Protocol (RTCP), რომელიც უზრუნველყოფს
მედიის მიღების ანალიზს დაკავშირებული RTP ნაკადისთვის. RTP - ის ფუნქციონირების
ცენტრალური ნაწილია RTP სესიის კონცეფცია. RTP სესია არის მონაწილეთა ჯგუფი,
რომლებიც ურთიერთქმედებენ RTP - ზე, ისე რომ მოცემული მონაწილე შეიძლება
ერთდროულად იყოს რამდენიმე სხვადასხვა RTP სესიის ნაწილი. მაგალითად საბოლოო
წერტილებს შეიძლება ჰქონდეს როგორც აუდიო RTP სესია, ასევე ვიდეო RTP სესია. RTP სესია
იდენტიფიცირებულია ქსელის მისამართისა და პორტის კომბინაციით, რომელზეც ტრაფიკი
იგზავნება და მიიღება. სხვადასხვა პორტი შეიძლება გამოყენებული იქნას RTP და RTCP
თითოეული სესიისთვის, ან ორივე პროტოკოლი შეიძლება იყოს მულტიპლექსირებული
საერთო UDP პორტზე. RTP სესია შეიძლება იყოს უნიქასთ ან მულტიქასთი. RTP პაკეტი
შედგება ორი ნაწილისგან RTP header და RTP payload. RTP პაკეტის ფორმატი ასე გამოიყურება:

Version (V): ეს ჰედერი განსაზღვრავს RTP ვერსიას.

Padding (P): ამ ჰედერის ველში როდესაც 1-ია მითითებული, მიანიშნებს იმაზე რომ არსებობს
დამატებითი ოქტეტები, რომელიც გამოიყენება RTP დატვირთვაზე. ეს დამატებითი ოქტეტი
არ არის Payload - ის ნაწილი და პირველ რიგში ჩასმულია იმის ურუნველსაყოფად, რომ
დაშიფვრის ალგორითმები ყოველთვის მუშაობენ მონაცემთა ფიქსირებულ ბლოკებზე.

Extension (X): ეს ველი მიუთითებს RTP ჰედერის გაფართოების არსებობაზე, RTP ჰედერის
გაფართოებები საჭიროა დამატებითი მულტიმედიური სესიის ინფორმაციის
გადასატანად, რომლებიც არ შეიძლება დაშიფრული იყოს სტანდარტულ RTP ჰედერებში ან
Payload - ში. ტიპიური მაგალითები მოიცავს RTP ჰედერის გაფართოებებს audio-level
ინფორმაციისთვის RTP ნიმუშებში. მიუხედავად იმისა, რომ სათაურის გაფართოებები
ხშირად არ გამოიყენება, მნიშვნელოვანია, რომ სპეციფიკაცია ითვალისწინებს
შესაძლებლობას ამ იშვიათი შემთხვევებისთვის.

CSRC Count (CC): ეს ველი განსაზღვრავ იდენტიფიკატორების რაოდენობას, რომლებიც

მიყვებიან ფიქსირებულ ჰედერებს.

Marker Bit (M): ამ ჰედერის ველი გამოიყენება მედია სესიის დროს მნიშვნელოვანი
მოვლენების დასანიშნად მაგალითად, Marker Bit - მა შეიძლება მიუთითებდეს ახალი DTMF
მოთხოვნის დაწყებაზე. M - ველის კიდევ ერთი გამოყენება არის ის, როდესაც Payload -
ფორმატი იცვლება მედია სესიის დროს, მაგალითად, მედია სესიამ შეიძლება მოლაპარაკება
მოახდინოს G711-ზე და დაიწყოს RTP პაკეტების გადაცემა კომუნიკაციის სესიის დროს.
მოთხოვნის ურთიერთქმედებისას შეიძლება მოხდეს კოდეკის ცვლილება G729-ზე
(ცვლილებას თან ახლავს სესიის აღწერილობის პროტოკოლის (SDP) შეთავაზება და პასუხი
(request/response) )

Payload Type (PT): ეს ველი მიუთითებს იმაზე, თუ როგორ უნდა მოხდეს RTP - პაკეტის
დამუშავება და ინტერპრეტაცია მიმღებში. Payload ტიპის მნიშვნელობები დაკავშირებულია
Payload - ის კონკრეტულ ფორმატებთან (მაგალითდ, PCMU, G729, H.264) RTP - პროფილების
გამოყენებით. SIP - ის პერსპექტივიდან, ეს კოლერაცია ხორციელდება SDP request/response -
ით.

Payload Type-To-Format Mapping For RTP/AVP

Payload ფორმატები პასუხისმგებელნი არიან იმის განსაზღვრაზე, თუ როგორ არის

ინფორმაცია მიღებული RTP პაკეტში, მაგალითად თუ რა არის წარმოდგენილი RTP ჰედერში
და RTP Payload - ში.

Sequence Number: ეს 16 ბიტიანი ველი მატულობს თნმიმდევრულად თითოეულ RTP

პაკეტისთვის, რომელიც გაგზავნილია, გამგზავნიდან მიმღებში. სწორედ ამ 16 ბიტიანი
ველის საშუალებით, RTP უზრუნველყოფს დანაკარგის გამოვლენის მექანიზმს თუ პაკეტები
შემცირდა ტრანზიტს დროს, მიმღები RTP შეამჩნევს თნმიმდევრობის ცხრილში მაგალითდ:
მოცემულ სურათში მიმღები აღმოაჩენს რომ აკლია 52941 და 52943 თანმიმდევრობის ნომრები

RTP პაკეტის თნმიმდევრობის ნომრები შერჩეულია შემთხვევით და არასდროს არ იწყება

ნულიდან. თნმიმდევრობა იწყება პირველი პაკეტის შერჩევითი ნომრიდან, ეს იმიტომ ხდება
რომ დაცული იყოს RTP პაკეტი ცნობილი plaintext შეტევისგან.

ასევე გასათვალისწინებელია რომ არსებობს მცდარი წარმოდგენა თანმიმდევრობის ნომრის

ველის შესახებ, რომ ის ეხმარება მიმღებს იმ თანმიმდევრობის განსაზღვრაში რომელიც
პაკეტებშია, მაგრამ ეს არასწორი ვარაუდია, თანმიმდევრობის განსაზღვრა დამოკიდებულია
RTP Timestamp - ზე. თანმიმდევრობის ველი უბრალოდ ეხმარება მიმღების დანაკარგის
გამოვლინებაში.

Timestamp: ამ ჰედერის ველი არის 32 - ბიტიანი, რომელიც აღნიშნავს RTP პაკეტში მედიის
Payload პირველი ოქტატის მომენტალურ შერჩევას. შერჩევა მყისიერად მიმდინარეობს media
clock - იდან. სიჩქარე დამოკიდებულია Payload ფორმატზე და ზოგჯერ შესაძლოა
მნიშვნელოვნად განსხვავდებოდეს მედიის ფორმატის მიხედვით, Timestamp ველი
გამოიყენება მიმღების მიერ, რათა დადგინდეს პაკეტის დაკვრის მოთხოვნა. Timestamp
ჰედერის ველის მნიშვნელობა პირველ პაკეტში არჩეულია შემთხვევით და მოძრაობს Payload
ფორმატით განსაზღვრული სიჩქარით.

Synchronization Source (SSRC) identifier: ეს 32 ბიტიანი ველი ემსახურება RTP სესიის მონაწილეს.
SSRC value ყოველთვისუნდა შეირჩეს შემთხვევით RTP სესიის მონაწილეების მიერ, რადგან RTP
- ს თითოეულ სესიას აქვს საკუთარი უნიკალური SSRC სივრცე. თუ RTP სესიის ერთ ან მეტ
მონაწილეს აქვს იგივე SSRC - ე value (ეს შესაძლებელია რადგან value შემთხვევით აირჩევა)
მოხდება შეჯახება (კოლიზია) და ეს მოგვარდება შემდეგნაირად, end point - ები აგზავნიან
RTCP BYE პაკეტს და შემდეგ ამას მოყვება ახალი შემთხვევითი SSRC value - ის არჩევა, ასევე
აუდიო და ვიდეო სესიისთვის SSRC value უნდა იყოს უნიკალურიორივე მედია სესიაზე.
ზოგიერთი სცენარი რამაც შეიძლება გამოიწვიოს SSRC - ის შეცვლა საკომუნიკაციო სესიის
განმავლობაში, არის შემდეგი: Application restarts (აპლიკაციის გადატვირთვა), SSRC collisions
(SSRC შეჯახება), ცვლილებები RTP სატრანსპორტო მისამართებზე (ქსელის მისამართი,
პორტი).

Payload Header: ამ ჰედერის არსებობა სურვილისამებრ ემყარება დატვირთვის ფორმატის

მოთხოვნებს, რომლებიც შეთანხმებულია.

Media Payload: ამ ჰედერის ფორმა წარმოადგენს მედია მონაცემებს, რომლებიც მოცემულია

RTP პაკეტში. მისი კონტენტი რეგულირდება Payload ფორმატით.

Real-Time Transport Control Protocol

(RTCP)

RTP-ეს peer პროტოკოლი RTCP მოიცავს შემდეგ ფუნქციებს: 1. საშუალებას აძლევს მიმღებს და
გამომგზავნს მიაწოდოს, ხარისხის შესახებ ინფორმაცია reciver report - ის საშუალებით. ეს
რეპორტი საშუალებას აძლევს გამგზავნს, მიიღონ ქსელის მახასიათებლები და შესაძლოა
შეცვალონ მათი გადაცემის ნიმუშები ისე როგორც საჭიროება მოითხოვს. 2. RTCP
განსაზღვრავს transport-level იდენტიფიკატორს, სახელწოდებით კანონიკური სახელი
canonical name (CNAME), რომელიც ემსახურება სოურსის მიერ გადაცემულ ყველა მედია
ნაკადს. ასევე ეხმარება მიმღებს მრავალი ნაკადის კოლერაციაში მოცემულ მონაწილესთან და
მედიის სინქრონიზაციის მიღწევაში მონაწილის მიერ გადმოცემულ მრავალ ნაკადში. 3. RTCP
მოითხოვს ყველა მონაწილის რეპორტების გაცვლას, მიუხედავად იმისა არიან თუ არა ისინი
აქტიური გამგზავნები. ეს უზრუნველყოფს RTP სესიის გლობალურ ხედვას. RTCP
უზრუნველყოფს დიაგნოსტიკას და თითოეულ მონაწილეს აძლევს RTP სესიის მონაწილეების
შეფასებას. 4. RTCP - ს შეუძლია სურვილისამებრ, გადასცეს დამატებითი ინფორმაცია
მონაწილის იდენტობის, ელ.ფოსტა და ადგილმდებარეობის ინფორმაცია.

იმის გათვალისწინებით, რომ ყველა მონაწილემ უნდა გაუშვას RTCP ტრაფიკი , გადაცემა
პერიოდული უნდა იყოს დაშექმნილია ისე, რომ არ გადააჭარბოს სესიის გამტარიანობას. RTCP
ტრაფიკი ყოველთვის უნდა გამოიყოს მთლიანი სესიის გამტარუნარიანობის პროცენტული
მაჩვენებლით RTCP - ისთვის გამტარუნარიანობის რეკომენდირებული პროცენტი 5%-ს
შეადგენს.

RTCP მოიცავს პაკეტის სხვადასხვა ტიპებს, რომლებიც გამოიყენება სხვადასხვა სცენარისთვის.

ცისკოს საკომუნიკაციო გარემოში RTCP - ის ხუთი ყველაზე გავრცელებული ტიპია :

1. Version: (V)
2. Padding: (P)
3. Reciver Count/Source Count: (RC/SC)
4. Packet Type (PT)
5. Lenght

Version (V): საზღვრავს RTP ვერსიის ნომერს.

Padding (P): როდესაც მითითებულია Padding ეს ბიტი მიგვანიშნებს იმაზე, რომ პაკეტი
შეიცავს დამატებით მონაცემთა ოქტეტს პაკეტის ბოლოს. ეს პირველ რიგში საჭიროა
როცა დაშიფვრის შიფერები მოითხოვს მონაცემთა ფიქსირებულ ბლოკებს.

(RC/SC): ამ ჰედერის ველი გამოიყენება RTCP პაკეტში შეტანილი მიმღების რეპორტის ან

სოურსის აღწერილობის (SDES) რაოდენობას RTCP - ი პაკეტში.

Packet Type (PT): ამ ჰედერის ველი განსაზღვრავს RTCP ტიპს

Length: ამ ჰედერის ველი აღნიშნავს პაკეტის სიგრძეს common ჰედერის შემდეგ. ა,

ჰედერის ველი გამოხატულია 32 ბიტიანი სიტყვებით და შეიძლება ქონდეს value 0.
ნული value მიუთითებს ცარიელ პაკეტზე, რომელიც შეიცავს 4 ბაიტს common header.

ყველა RTCP პაკეტი უნდა გაიგზავნოს ნაერთი RTCP პაკეტის სახით, რომელიც მოიცავს
კომბინაციას პაკეტების სხვადასხვა RTCP ტიპს და მიყვება ძალიან მკაცრი შეკვეთის
წესის სქემას. RTCP პაკეტების ხუთი განსხვავებული ტიპებია:

1. RTCP sender report (SR)

2. RTCP reciver report (RR)
 3. RTCP source description (SDES)
4. RTCP googbye (BYE)
5. RTCP application-defined packet (APP)

RTCP sender report (SR):

RTCP გამგზავნის რეპორტები იგზავნება წყაროებით, რომლებმაც ახლახან გადასცეს მედია და

იდენტიფიცირებულია პაკეტის ტიპის მნიშვნელობით 200. აქტიური გამგზავნი ასევე შეიცავს
სტატისტიკის ყველა სხვა წყაროს(source), საიდანაც მან მიიღო მედიაპაკეტები. მისაღები
სტატისტიკა არის დაშიფრული როგორც RTCP მიმღების ანგარიშის (RR) ბლოკები ისე, რომ
თითოეული ბლოკი შეესაბამებოდეს წყაროს საიდანაც მიიღეს მედია. მიმღების გრაფის (RC)
ჰედერის ველი RTCP გამგზავნის ანგარიშის პაკეტში იღებს მიმღების ანგარიშის ბლოკების
რაოდენობას. თუ მედია არ არის მიღებული ნებისმიერი წყაროდან და არ არსებობს მიმღების
ანგარიშის ბლოკები, რომლებიც შედის ნაერთ RTCP პაკეტში, მაშინ RC სათაურის ველი 0-ია.

პაკეტის გამგზავნის რეპორტიორი SSRC ველი მოიცავს წყაროს SSRC- ს, რომელიც გადასცემს
RTCP SR პაკეტს და ეს არის 32-ბიტიანი ველი. ამის შემდეგ არის 64-ბიტიანი ქსელის დროის
პროტოკოლი (NTP) Timestamp ველი. ამ სფეროში დრო გამოხატულია NTP ფორმატით, რაც
არის წამების რაოდენობა, ეს ველი მიუთითებს იმ დროზე, როდესაც RTCP SR პაკეტი
გაიგზავნა.

32-ბიტიანი RTP Timestamp ჰედერის ველი იმავე დროს კოდირებს, რასაც NTP Timestamp
ჰედერის ველი, მაგრამ გამოხატულია RTP დროის ფორმატში. მიმღები იყენებს NTP Timestamp
და RTP Timestamp ჰედერის ველებს გამგზავნისგან სხვადასხვა ნაკადების მედია საათების
სინქრონიზაციისთვის, რაც საშუალებას გვაძლევს აუდიო და ვიდეო მედიის ნაკადების
სინქრონიზაციას. RTP Timestamp ველის შემდეგ არის Sender's Packet Count და Sender's Octet
Count ველები. Sender's Packet Count ველი იღებს RTP მონაცემთა პაკეტების საერთო
რაოდენობას, რომლებიც გადაეცემა გამგზავნის მიერ სესიის დაწყებიდან RTCP SR პაკეტის
გადაცემით. Sender's Octet Count ველი იღებს RTP სესიის დაწყებიდან გაგზავნილი მონაცემთა
ჯამურ რაოდენობას, RTCP SR პაკეტის გადაცემით. ეს არ ითვალისწინებს RTP ჰედერებს და
padding- ს და მხოლოდ აღელვებს octets- ის რაოდენობა, რომლებიც იგზავნება RTP პაკეტის
Payload - ის გამოყენებით.

RTCP Receiver Report (RR):

RTCP მიმღების რეპორტები გამოიყენება გადაცემის სტატისტიკის შესატყობინებლად

გამომგზავნისთვის, მასთან საიდანაც მიღებულია RTP პაკეტები.

RTCP RR პაკეტში სურათის მიხედვით Packet Type ჰედერის ველში მითითებულია 201-ი, ხოლო
რეპორტების ბლოკების რაოდენობა მითითებულია RC-ი ჰედერის ველში. RTCP RR პაკეტის
გამგზავნის ვინაობა აღინიშნება SSRC ჰედერის ველში. RTP გამაგზავნი, რომლის შესახებაც
სტატისტიკა იგზავნება, მითითებულია SSRC Source_N ველში. შესაძლებელია RTP სესიის
ერთმა მონაწილემ RTP პაკეტები მიიღოს მრავალი წყაროდან, ამ შემთხვევაში მიღების
სტატისტიკის რეპორტში უნდა იყოს მოხსენიებული თითოეული წყარო. RTCP RR პაკეტში
სულ შესაძლებელია მითითებული იყოს 31 მიმღების რეპორტი. თუ არსებობს 31-ზე მეტი
წყარო მაშინ მოხსენება უნდა იყოს ამის შესახებ. Loss Fraction ჰედერის ველი აღნიშნავს RTP
მედია პაკეტების ნაწილს რომლებიც დაიკარგა კონკრეტული წყაროდან წინა SR ან RR პაკეტის
გადაცემის შემდეგ. ეს value გამოხატულია როგორც fixed-point ნომერი. Cumulative Number of
Packets Lost - ამ ჰედერის ველი არის 24 ბიტიანი მთელი რიცხვი, რომელიც აღნიშნავს
მიღებული პაკეტების რაოდენობას გამოკლებული მოსალოდნელი პაკეტების რაოდენობა.
მოსალოდნელი რაოდენობა განისაზღვრება ბოლოს მიღებული sequence number-ი,
გამოკლებულია დასაწყისიდან მიღებულ sequence number-ზე. პაკეტის დუბლიკატების
შემთხვევაში Cumulative Number ჰედერის ველს აქვს უარყოფითი value. Extended Highest
Sequence Number Received ჰედერი ველი არის 32 ბიტიანი, სადაც ქვედა 16 ბიტი მიუთითებს
RTP მედია პაკეტში მიღებულ უმაღლეს მიმდევრობის რიცხვს მოცემული წყაროდან. ზედა 16
ბიტი მიუთითებს თუ რამდენჯერ არის დანომრილი თანმიმდევრობა RTP-ში 65535-იდან 0-
ამდე. Interarrival Jitter ველი უზრუნველყოფს RTP გარემოს სტატისტიკური დისპერსიის
შეფასებას. დროს პაკეტის მოსვლას შორის. ამ ჰედერის ველი იზომება დროის ერთეულებში
და გამოიხატება როგორც მთელი რიცხვი. Last SR (LSR) ჰედერის ველი იჭერს NTP-ში
მიღებული 64 ბიტიდან შუა 32-ს, წინა SR პაკეტის TimeStamp ჰედერის ველიდან, რომელსაც ეს
RR ბლოკი შეესაბამება. თუ წყაროდან არ არის მიღებული RTCP SR პაკეტები, ამ ველში იქნება
მითითებული 0 ნული. The Delay Since Last SR (DSLR) ჰედერის ველი არის 32-ბიტიანი ველი,
რომელიც გამოხატულია 1/65,536 ერთეულებში, წამები რითაც გამოითვლება წყაროდან
მიღებული last SR პაკეტის დაყოვნება (რომელსაც ეს RR ბლოკი შეესაბამება) და გაგზავნა ამ RR
ბლოკის. თუ არ ყოფილა ჯერ SR პაკეტი მიღებული შესაბამისი წყაროდან, მაშინ ამ ჰედერის
ველში მითითებულია 0 ნული.

RTCP-მიღების რეპორტები როგორც წესი გამოიყენება რეალურ დროში მიღების ხარისხის

შესახებ ინფორმაციის, გამომგზავნისთვის მისაწოდებლად. გამგზავნებს შეუძლიათ
გამოიყენონ ეს მოხსენებები მათი გადაცემის შაბლონების შესაცვლელად. გარდა ამისა, მესამე
მხარის მონიტორინგის აპლიკაციები იყენებენ RTCP ანგარიშებს მედიის საერთო ხარისხის
შესაფასებლად სესიების ადგილობრივი, რეგიონული ან გლობალური პერსპექტივიდან.

RTCP Source Description (SDES) Packet

RTCP SDES პაკეტი ძირითადად გამოიყენება მუდმივი მონაწილის იდენტიფიკატორის

უზრუნველსაყოფად, რომელიც მოიცავს SSRC ცვლილებებს და სისტემის გადატვირთვას.
მუდმივი იდენტიფიკატორის მიწოდების გარდა, ის ასევე შეიცავს ინფორმაციას, როგორიცაა
მონაწილის სახელი, ელექტრონული ფოსტის მისამართი, მდებარეობა და ტელეფონის
ნომერი. საერთო SDES პაკეტის ფორმატი შეიცავს ნულს ან მეტ ნაწილს და ნაწილაკების ზუსტ
რაოდენობას რომელიც აღბეჭდილია SC ჰედერის ველის value-ში.

თითოეული ელემენტის ნაწილი იწყება გამგზავნის SSRC-ით, რასაც მოჰყვება ჩანაწერების

სტრიქონი. Type header ველი გადმოსცემს SDES RTCP-ის ტიპს. Packet, Lenght ჰედერის ველები
შიფრავს (UTF8-ის) არსებული ტექსტის ოქტეტების რაოდენობას.
SDES პაკეტის ფორმატი შეიცავს შემდეგ ელემენტებს:

CNAME SDES ამ ელემენტის ტიპის მნიშვნელობა არის 1 და არის ერთადერთი სავალდებულო

SDES პაკეტი, რომელიც უნდა გაიგზავნოს ყველა განხორციელებით. ეს პაკეტი
უზრუნველყოფს მდგრადობას ტრანსპორტის დონის იდენტიფიკატორი მონაწილისთვის,
რომელიც ცნობილია როგორც CNAME. მოსალოდნელია, რომ მონაწილის CNAME იგივე
დარჩება SSRC ცვლილებებისა და სისტემის გადატვირთვისას, ასევე ის უნიკალური იქნება RTP
სესიაში ან დაკავშირებული RTP სესიების ჯგუფებში. CNAME ჰედერის ველის მნიშვნელობა
მიღებულია ალგორითმულად, ფორმატის user@host-ის გამოყენებით ან უბრალოდ
მასპინძლობს, როდესაც მომხმარებლის სახელი მიუწვდომელია. CNAME აუცილებელია
მიმღებისთვის მედიის ნაკადების იდენტიფიცირების და სინქრონიზაციისთვის, რომლებიც
მომდინარეობს მოცემული წყაროდან.

NAME SDES ელემენტის ტიპს აქვს value 2-ი და საჭიროა მონაწილისთვის სახელის
მისაწოდებლად. ჩვეულებრივ ეს დასახლებულია მომხმარებლის მიერ და შეიძლება იყოს
შემდეგი ფორმატით წარმოდგენილი მაგალითად, სახელი გვარი. აპლიკაციებს შეუძლიათ
გამოიყენონ NAME SDES პუნქტი კონფერენციების სიების შესავსებად, როდესაც მონაწილეები
შეუერთდებიან.

EMAIL SDES ელემენტის ტიპს აქვს value 3-ი და საჭიროა მონაწილისთვის ელ. ფოსტის
გადასაცემად და შეიძლება იყოს შემდეგი ფორმატით წარმოდგენილი მაგალითად,
tsotne.kapanadze@example.com

PHONE SDES ელემენტის ტიპს აქვს value 4-ი და ასახავს ტელეფონის ნომერს საერთაშორისო
ფორმატით.

LOC SDES ელემენტის ტიპს აქვს value 5-ი და შიფრავს მონაწილეთა მდებარეობას სხვადასხვა
ხარისხის დეტალებით. კორპუსი 11 საბურთალო, მოქმედებს კოდირება.

TOOL ელემენტის ტიპს აქვს value 6-ი და გამოიყენება პროდუქტის ან აპლიკაციის სახელის
გამოსავლინებლად რომელიც წარმოქმნის ნაკადს. ეს ძირითადად გამოიყენება
მარკეტინგისთვის და არ აქვს რაიმე გავლენა RTP სესიაზე.
NOTE SDES ელემენტის ტიპს აქვს value 7-ი და გამოიყენება ზოგადი აღნიშვნის
უზრუნველსაყოფად, როგორიცაა სტატუსი (მაგ. ტელეფონზე). მიუხედავად იმისა, რომ ეს
კარგია გამოყენებისთვის, ის ამაინც რ უნდა იქნას გამოყენებული საკომუნიკაციო სესიაზე
შეტყობინებების მიწოდებისთვის, რადგან RTCP პაკეტების გაცვლა იშვიათად ხდება
მონაწილეებს შორის.

PRIV SDES ელემენტის ტიპს აქვს value 8-ი და გამოიყენება ექსპერიმენტული მიზნებისთვის.

RTCP Goodbye (BYE) პაკეტი

RTCP BYE პაკეტი გადაიცემა როდესაც მონაწილე ტოვებს RTP სესიას ან როდესაც აღმოჩენილია
SSRC შეჯახება. მონაწილეებს აქვთ გარკვეული დროის მოსაზრებები რომელიც უნდა
გავითვალისწინოთ RTCP BYE შეტყობინებების გადაცემისას, რათა თავიდან აიცილოთ
გადატვირთულობა.

RTCP BYE პაკეტის ფორმატი გამოსახულია სურათზე, მას აქვს პაკეტის ტიპის value 203. SC
ჰედერის ველი ასახავს SSRC/CSRC იდენტიფიკატორების რაოდენობას მოცემულ RTCP BYE
პაკეტში. optional 8-ბიტიანი ველი, ასახავს ოქტეტების რაოდენობას, რომლებიც გამოხატულია
Lenght და Reason for Leaving ჰედერის ველებში. ჰედერის ველი Reason for Leaving იძლევა
ტექსტურ აღწერას თუ რატომ გადაწყვიტა წყარომ RTP სესიის დატოვება. ამ ველის მაგილითი
შეიძლება იყოს “camera not operational.”

RTCP Application-Defined Packet (APP)

RTCP APP პაკეტი საშუალებას გაძლევთ გამოიყენოთ აპლიკაციის სპეციფიკური
გაფართოებები.ამ ტიპის პაკეტი ძირითადად გამოიყენება კონფიდენციალური ინფორმაციის
გაცვლისთვის.

Other RTCP Packet Types

არსებობს RTCP პაკეტის უფრო მეტი ფორმატი, ვიდრე ეს განსაზღვრულია RFC 3550-ში,
შესაძლოა ისინი იშვიათად ან საერთოდ არ შეგვხვდეს. �აგალითად, პაკეტის ტიპი RTCP
Payload Specific Feedback (PSFB) (206) RFC 4585-დან. RTCP Payload ტიპების სრული სიისთვის
ეწვიეთ შემდეგ გვერდს https://www.iana.org/assignments/rtp-parameters/rtp-
parameters.xhtml#rtp-parameters-4.

RTCP Transport
UDP და მსგავსი სატრანსპორტო ფენის პროტოკოლებისთვის, აპლიკაციებმა უნდა
გამოიყენონლუწი პორტის ნომერი RTP-სთვის და შემდეგი უფრო მაღალი (კენტი) პორტის
ნომერი RTCP-სთვის. აპლიკაციებს შეუძლიათ გამოიყენონ SDP ატრიბუტი a=rtcp:<udp-port>
სხვა RTP პორტის დასადგენად, შემდეგი UDP უმაღლესი პორტის ნაცვლად. გარდა ამისა, RFC
5761-მა შემოიღო RTP/RTCP მულტიპლექსირების კონცეფცია ერთი UDP პორტით. ეს არის
გადმოცემული SDP ატრიბუტის გამოყენებით a=rtcp-mux.
 Dual-Tone Multifrequency
DTMF Relay
Voice over IP-ის (VoIP) გამოჩენასთან ერთად, კლავიატურის კლავიშების ტონის საიმედო
გადაცემა პრობლემად იქცა, რადგან აუდიო კოდეკები არ იყო ოპტიმიზირებული ამ ტიპის
მონაცემთა დამახინჯების გარეშე გადაცემისთვის. საჭირო გახდა ახალი ტონის გადაცემის
გზის პოვნა, რომელიც გათვალისწინებდა თანამედროვე ქსელების ყველა სირთულეს.
საბედნიეროდ, ინდუსტრია IETF და ITU-T ხელმძღვანელობით შემუშავებული იქნა DTMF relay
რომელიც თანამდეროვე ქსელებში კარგად მუშაობს. DTMF იყენებს ორი ტონის კომბინაციას:
მაღალი სიხშირის ტონს და დაბალი სიხშირის ტონს კლავიატურაზე (0–9, *, #) ან ასოს
(A,B,C,D) გამოსაყენებლად. მოწყობილობა, რომელიც მხარს უჭერს DTMF-ს აქვს 4×4
მატრიცული კლავიატურის განლაგება, ისე, რომ თითოეული მწკრივი წარმოადგენს ბგერის
დაბალი სიხშირის კომპონენტს და თითოეული სვეტი წარმოადგენს მაღალი სიხშირის
სიგნალის ტონალურ კომპონენტს.

სურათი ასახავს 4x4 ბადეს:

შემდეგ სურათში განვიხილავთ შემთხვევას როდესაც აბონენტი რეკავს კორპორატიულ
ქსელში და მას პასუხობს ლოკალური IVR-ი. როდესაც ზარი დამყარდება IVR სისტემას
შეუძლია დაუკრას მოთხოვნა, რომელიც მოუწოდებს აბონენტს შეიყვანოს ციფრი გაყიდვების
განყოფილებასთან დასაკავშირებლად ან შეიყვანოს სხვა ციფრი მომსახურების
განყოფილებასთან დასაკავშირებლად და ა.შ. შემდეგ აბონენტს შეყავს ციფრი კლავიშზე
დაჭერის მეშვეობით, ციფრის ყოველი დაჭერა წარმოადგენს DTMF ტონს, რომელიც გადაეცემა
აბონენტიდან IVR სისტემას. სტანდარტული PSTN ქსელები ატარებენ DTMF ინფორმაციას
სტანდარტულ სიგნალებად, სტანდარტული PSTN ქსელები ატარებენ DTMF ინფორმაციას
სტანდარტულ სიგნალებად, ხოლო აიპი ქსელების მეშვეობით DTMF ტონი გადაიცემა ან
სიგნალით სახით (როგორც აპლიკაციის შეტყობინების პროტოკოლი) ან მედია ნაკადის სახით
(მედიაში ან RTP პაკეტში) ციფრული ინფორმაციის გადაცემის პროცესი აიპი ქსელში არის
inband (მედიის საშუალებით) ან out-of-band (სიგნალის საშუალებით) ან ორივე კომბინაციის
საშუალებით.

სიგნალების გადაცემა DTMF გამოყენებით TDM და ანალოგური ქსელებით უკიდურესად

საიმედოა; თუმცა, DTMF-ის გადაცემა VoIP ქსელებით არც ისე მარტივია.
ამ შემთხვევაში, დისტანციური მოწყობილობა რეკავს საწარმოში, ინტერნეტ სატელეფონო
სერვისის პროვაიდერის (ITSP) მეშვეობით. ამ ზარის მარშრუტი განსაზღვრება CUBE-ისა და
Unified CM-ის მეშვეობით და საბოლოოდ მთავრდება Cisco Unified Contact Center Express-ში
ექსპრესი (UCCX). UCCX-მა შეიძლება აბონენტს დაუკრას მორგებული სკრიპტი, როგორც ეს ჩანს
წინა სურათში. სურათში მომხმარებელი კლავიატურაზე აჭერს 1-ს, შემდეგ DTMF-მა უნდა
გადაიტანოს ზარის სხვადასხვა სეგმენტზე, პროცესი შემდეგნაირად მუშაობს:

ნაბიჯი პირველი. ITSP და CUBE აწარმოებენ მოლაპარაკებას in-band RTP-NTE DTMF მეთოდზე
და DTMF ციფრი გადადის CUBE-ზე ITSP-დან.

ნაბიჯი მეორე. CUBE და Unified CM მოლაპარაკებას აწარმოებენ out-of-band (OOB) SIP KPML DTMF
მეთოდზე და DTMF ციფრი გადადის Unified CM-ზე.

ნაბიჯი მესამე. Unified CM და UCCX თანხმდებიან DTMF მეთოდზე როგორც JTAPI მოვლენები
და DTMF მეთოდი გადაეცემა IVR აპლიკაციას ანალიზისთვის და მოქმედებისთვის.

ეს მხოლოდ ძირითადი მაგალითია, რომელიც აჩვენებს, თუ როგორ შეუძლიათ აპლიკაციებს

ციფრების გადაცემა IP-ზე. IETF და ITU-T, შეიმუშავეს DTMF relay-ის განსხვავებული მეთოდები

Variants of DTMF Relay (DTMF Relay ვარიანტები)

თანამედროვე დროში ქსელების მასშტაბისა და სირთულის მიუხედავად, არსებობს მხოლოდ
ორი გზა რომელიც DTMF-მა შეიძლება გადაიტანოს მოცემულ ზარზე:

In-band: In-band DTMF relay-ის ეხება ტონების გადაცემა RTP (მედია) ნაკადში.

Out-of-band: Out-of-band-ს ეხება DTMF ინფორმაციის გადაცემა სასიგნალო არხზე.

ორივე მეთოდს აქვს თავისი დადებითი და უარყოფითი მხარეები და, როგორც VoIP-ის
მრავალი სხვა ასპექტის შემთხვევაში, საუკეთესო DTMF relay მეთოდის განხორციელების
არჩევანი დამოკიდებულია ქსელზე.

In-Band DTMF Relay

DTMF ტონების გადაცემა მედიის ნაკადში მოიხსენიება, როგორც In-Band DTMF Relay. VoIP
ქსელებში გამოყენებული კოდეკების უმეტესობა შექმნილია და ოპტიმიზირებულია
ადამიანის მეტყველებისთვის და მათი კოდირებისა და დეკოდირების ალგორითმები კარგად
არ მუშაობს ორმაგი სიხშირის ტონებზე. ეს განსაკუთრებით ეხება მაღალი შეკუმშვის
კოდეკებს, როგორიცაა G.729, რომელიც საკმაოდ ამახინჯებენ ტონებს ისე, რომ მათი ზუსტი
რეპროდუცირება შეუძლებელია მიმღებ აპლიკაციაში. სწორედ ამიტომ, IETF-მა დაისახა
ამოცანა, იმ მიზნით რომ შეექმნა გზა ტონების საიმედოდ გადაცემის საშუალება მედია
ნაკადში, რამაც შემდგომში გამოიწვია სატელეფონო სტანდარტიზაცია RFC 2833-ში
(რომელიც მას შემდეგ შეიცვალა RFC 4733-ით). არსებობს ორი გზა DTMF ტონების შესაძლო
გადაცემის მედიის ნაკადში:

■ Named telephony events (NTEs)

■ Raw in-band tones

Named telephony events (NTEs)

RFC 2833 განსაზღვრავს Payload სპეციალიზებულ ფორმატს და სპეციფიკაციას DTMF ტონებს
მედია ნაკადში გადაცემისთვის (NTEs) ივენთის გამოყენებით. ეს სპეციფიკაცია
დამაჯერებლად გადალახავს DTMF ტონების გადაცემის ზოგიერთ ცნობილ შეზღუდვას
სტანდარტული აუდიო კოდეკის გამოყენებით. named telephony events (NTEs) DTMF-ის
გადაცემის სტანდარტული აუდიო კოდეკები მოიცავს შემდეგს:

■ DTMF ტონების აუდიო კოდეკთან დაკავშირება უზრუნველყოფს გადაცემის წარმატებას

მაშინაც კი, როდესაც იყენებთ მაღალი შეკუმშვის კოდეკებს, როგორიცაა G.729.

■ ცალკეული RTP Payload ფორმატის განსაზღვრა უზრუნველყოფს ჭარბი რაოდენობას DTMF

ციფრების გადაცემას, გადაცემის დაბალი სიჩქარის შენარჩუნებით.

■ ზოგიერთ ტონს (როგორიცაა ANSAM ტონი მოდემის ზარებისთვის) აქვს ფაზის შეცვლა. ამ
ფაზის შებრუნებები შეუძლებელია ზუსტად იქნას გადატანილი აუდიო პაკეტების სახით IP
ქსელში. named telephony events-ის გამოყენება ასეთი ტონების წარმოსადგენად
მნიშვნელოვნად ამარტივებს პროცესს.

■ ახალმა მოწყობილობებმა შეიძლება გადასცეს DTMF ინფორმაცია, როგორც named telephony

events-ის საშუალებით, ასევე აქტუალური ტონის წყვილების გენერირებით.

NTE Payload სტანდარტულ RTP პაკეტებში ისე, რომ იგივე sequence number და timestamp
სივრცე გამოიყენება როგორც აუდიო კოდირებული პაკეტებისთვის, ასევე NTE
პაკეტებისთვის.

განვიხილოთ თუ როგორ ხდება NTE პაკეტის RTP პაკეტში გატარება, რომელიც ატარებს NTE
Payload-ს. სამი სხვადასხვა ტიპის პაკეტი იგზავნება თითო მოვლენაზე NTE სქემაში:

■ პაკეტი, რომელიც მიუთითებს DTMF მოვლენის დაწყებაზე. საწყის RTP პაკეტში მარკერის
ბიტი (M) ყოველთვის არის 1-ზე. RFC 2833-ში შეიძლება იყოს სამი პაკეტი მარკერის ბიტით
დაყენებული true-ზე, ხოლო RFC 4733-ში DTMF მოვლენაში მხოლოდ პირველ პაკეტს უნდა
ჰქონდეს მარკერის ბიტის ნაკრები true-ზე

■ Refresh ან update პაკეტები, რომლებიც იგზავნება ყოველ 50 მილიწამში ივენთის

დასრულებამდე.
■ სამი პაკეტი, რომელიც აღნიშნავს ივენთის დასასრულს. ბოლო პაკეტებს ყოველთვის აქვთ
ბოლო (E) ბიტი NTE Payload სეტში 1-ი.

აღწერილი სამი სხვადასხვა ტიპის პაკეტი განკუთვნილია ერთი ივენთისთვის ან DTMF

ციფრისთვის და მათ ყველას აქვთ იგივე RTP Timestamp-ი. sequence number-ი თითოეულ NTE
პაკეტში იზრდება ერთით. sequence number-ი თითოეულ NTE პაკეტში იზრდება ერთით.
სურათზე ასახულია RTP პაკეტის ფორმატი NTE Payload-ით.

payload ფორმატი named telephony ივენთისთვის ილუსტრირებულია ქვემოთ თანდართულ

სურათზე.

■ Event: ეს არის რიცხვი 0-დან 255-მდე, სადაც თითოეული რიცხვი აღნიშნავს კონკრეტულ
ივენთს, როგორც ეს აღწერილია RFC 2833-ში და RFC 4733-ში. თუმცა, DTMF-ისთვის ივენთ ID-
ებს შეუძლიათ მიიღონ რიცხვი 0-დან 15-მდე. ცხრილში ჩამოთვლილია რიცხვები და ასოები
რომბლებსაც შეესაბამება რიცხვები 0-იდან 15-ამდე:
ასო A-დან D-მდე არის სამხედრო აპლიკაციებისთვის და ჩვეულებრივ არ გამოიყენება
კომერციულ პროგრამებში.

■ End (E) bit: როდესაც ეს ბიტის მნიშვნელობა დაყენებულია 1-ზე, ის აღნიშნავს DTMF
მოვლენის დასასრულს; აუცილებელია, რომ ეს ბიტი არ იყოს დაყენებული 1-ზე იმ
პაკეტებისთვის, რომლებიც ან მიუთითებენ ივენთის დაწყებას ან ანახლებენ პაკეტებს,
რომლებიც იგზავნება ყოველ 50 მილიწამში.

■ Volume: DTMF რიცხვებისთვის და სხვა ივენთებისთვის, რომლებიც შეიძლება იყოს

წარმოდგენილი ტონების სახით, ეს ველი აღწერს ბგერის სიმძლავრის დონეს, რომელიც
გამოხატულია dBm0 ნიშნის შემდეგ. სიმძლავრის დონეები მერყეობს 0-დან -63 dBm0-მდე.
მოქმედი DTMF-ის დიაპაზონი არის 0-დან −36-მდე dBm0.

■ Duration: ეს ველი განსაზღვრავს Timestamp ერთეულებს DTMF ივენთის ხანგრძლივობას.

Timestamp ველში მოცემული value მიუთითებს ნებისმიერ RTP პაკეტში იმ მომენტზე,
როდესაც ის ივენთი დაიწყო, ხოლო Duration ველში მოცემული value ნებისმიერ NTE პაკეტში
მიუთითებს თუ რამდენ ხანს გაგრძელდა ივენთი.

R bit: ეს არის სარეზერვო ბიტი და ამჟამად არ აქვს რაიმე განსაზღვრული ფუნქცია.

იმის გათვალისწინებით, რომ დასახელებული სატელეფონო ივენთები ხორციელდება მედია

ნაკადში აუდიოშიფრირებულ პაკეტებთან ერთად, მიმღები აპლიკაცია განასხვავებს ამ
პაკეტებს სტანდარტული აუდიოსგან payload ტიპისა და payload ფორმატის საშუალებით. NTE
პაკეტებისთვის, payload ტიპები არჩეული არის დინამიურად და შეიძლება განსხვავდებოდეს
96-დან 127-მდე.
 Raw In-Band Tones
Raw in-band DTMF-ს ეხება raw ტონების გადაცემა მედია ნაკადში. განსხვავებით NTE
ივენთებისგან რისთვისაც არსებობს სპეციალიზებული RTP Payload ფორმატი DTMF-ისთვის,
ხოლო raw In-band DTMF-ი შიფრავს ტონის სიხშირეებს სტანდარტული RTP Payload-ის
ფარგლებში. როგორც აქამდე ავღნიშნეთ აუდიო კოდეკებს აქვთ ალგორითმები
ოპტიმიზირებული მეტყველებისთვის და არ მუშაობენ ოპტიმალურად DTMF ტონების
გადაცემისთვის. მაღალი შეკუმშვის კოდეკების გამოყენება DTMF-ის გადასაცემად,
გაართულებს DTMF გადაცემას ტონის მნიშვნელოვანი დამახინჯების გამო. ქვემოთ
მოცემულია რამდენიმე უარყოფითი მხარე, რომელიც თან ახლავს Raw in-band DTMF-ის
გამოყენებას:

■ კოდეკის ოპტიმიზაციის ნაკლებობა DTMF-ის გადაცემისთვის.

■ არ არსებობს მხარდაჭერა DTMF ჭარბი ტონების გადაცემისას (განსხვავებით NTE-ისგან,

რომელსაც აქვს ჩაშენებული ჭარბი რაოდენობა). თუ ჭარბი რაოდენობა უნდა იყოს
გადაცემული, ეს ხდება ზედმეტი RTP ნაკადის მეშვეობით RFC 2198-ის კონსტრუქციების
გამოყენებით. ეს იწვევს სირთულის გაზრდას. და გამტარუნარიანობის დატვირთვას.

■ დიაგნოსტიკის ნაკლებობა პრობლემების აღმოსაფხვრელად. იმის გამო, რომ ეს ტონები raw

ტონების სახით ხორციელდება აუდიო კოდეკში, DTMF გადაცემის პრობლემების მოგვარების
ერთადერთი გზაა აუდიო ნაკადის გაშიფვრა სპეციალიზებული პროგრამული
უზრუნველყოფის გამოყენებით.

■ ფართოდ არ არის მიღებული მოწყობილობებსა და გამყიდველებში.

მიუხედავად ამისა, ჯერ კიდევ არის ზოგიერთი სერვისის პროვაიდერი, რომელიც იყენებს
DTMF გადაცემის ამ მეთოდს. ქვემოთ მოყვანილ სურათზე ნაჩვენებია NTE და RAW მეთოდით
DTMF ტონის გადაცემა.
 Out-of-Band DTMF Relay
Out-of-Band DTMF Relay ეყრდნობა სასიგნალო არხს ციფრების დაჭერისთვის კომუნიკაციაში.
ზარის კონტროლის პროტოკოლებს, როგორიცაა SIP და H.323, აქვთ სპეციალიზებული
მექანიზმები და გაფართოებები DTMF ინფორმაციის კომუნიკაციისთვის. DTMF Relay-ის ამ
მეთოდით, გადიან სასიგნალო გზას, რომელიც შეიძლება მოიცავდეს აგენტების გამოძახებებს
და პროქსებს, სხვა მოწყობილობებს შორის. შემდეგი სურათი ასახავს განსხვავებას in-band და
out-of-band DTMF-ს შორის.
 JITTER
გლობალური მიღების ჰიბრიდულმა მუშაობამ ხაზი გაუსვა VoIP-ისა და ვიდეოს
მნიშვნელობას, როგორც პირველადი საკომუნიკაციო გადაწყვეტილებებს. ძალიან
მნიშვნელოვანია, რომ თქვენი ქსელი ოპტიმალურად ფუნქციონირებდეს ნებისმიერ დროს და
ყველა მოწყობილობასა და მდებარეობაზე. თუმცა, ერთ-ერთი ყველაზე გავრცელებული
გამოწვევა არის ქსელის ცუდი ხარისხი, რაც გავლენას ახდენს VoIP ზარის ხარისხზე და ამ
დროს ვიდეოს ხარისხიც დაბალია. Jitter არის დროის დაყოვნების ცვალებადობა სიგნალის
გადაცემისა და ქსელის კავშირის საშუალებით მიღებისას, რაც ზომავს ცვალებადობას პინგში.
ეს ხშირად გამოწვეულია ქსელის გადატვირთულობით, ტექნიკის ცუდი მუშაობით და
პაკეტების პრიორიტეტიზაციის შეუსრულებლობით. VoIP და ვიდეო სერვისების
შესრულებისას ნეგატიურად მოქმედებს რაც უფრო დიდია დაგვიანება და მაღალმა ჯიტერმა
შეიძლება გამოიწვიოს წყვეტილი და არათანმიმდევრული საუბარი ზარისას - ან საერთოდ
გაითიშოს ზარი.

Ping and Jitter

Ping-ი და jitter-ი ყველაზე მნიშვნელოვანია მედია სტრიმინგის გამოყენების დროს,

როგორიცაა ვიდეო ნაკადი, ონლაინ თამაში ან ხმა ინტერნეტით (VoIP). ვებ გვერდების
დათვალიერებაზე დიდ გავლენას არ ახდენს რეაგირების დრო და მასში არსებული
ცვალებადობა, მაგრამ თუ გჭირდებათ რეალურ დროში მონაცემების გაცვლა, პინგი და
ჯიტერი თქვენი კავშირის ხარისხის მნიშვნელოვანი საზომია. Ping არის საზომი, თუ რა დრო
სჭირდება თქვენს კავშირს რეაგირებისთვის, ან რამდენად სწრაფად იღებთ პასუხს
მოთხოვნის მიღებისას. Ping იზომება მილიწამებში (ms) და რაც უფრო დაბალია პინგის
ნომერი, მით უფრო სწრაფია თქვენი კავშირი. პინგი მნიშვნელოვანია რეალურ დროში
აპლიკაციის გამოყენებისას, როგორიცაა ვიდეო ნაკადი ან ონლაინ თამაში. ხოლო ჯიტერი
არის შეყოვნების ვარიაცია, ანუ დროის შეფერხება სიგნალის გადაცემისა და მისი მიღების
შორის. ეს განსხვავება იზომება მილიწამებში (ms) და აღწერილია, როგორც მონაცემთა
პაკეტების გაგზავნის ნორმალური თანმიმდევრობის დარღვევა. კარგ კავშირებს აქვთ სანდო
და თანმიმდევრული რეაგირების დრო, რომელიც წარმოდგენილია როგორც დაბალი
ჯიტერის ქულა. რაც უფრო მაღალია ჯიტერის ქულა, მით უფრო არათანმიმდევრულია
რეაგირების დრო, რაც გამოიხატება ზარების ხარისხზე ცუდი ჟღერადობით ან ვიდეოს
ხარისხში.

ტექნოლოგია ჯიტერის მიღმა

Data packets: ქსელში ჯიტერის დასადგენად, საქმე ეხება მონაცემთა პაკეტებს და პაკეტის
დაკარგვას. ქსელის მონაცემთა პაკეტების უმეტესობა დაყოფილია სამ ნაწილად:

ჰედერი: ჰედერი შეიცავს ინსტრუქციებს პაკეტის მიერ გადატანილი მონაცემების შესახებ,

როგორიცაა:
 • Packet length - ზოგიერთ ქსელს აქვს ფიქსირებული სიგრძის პაკეტები, ზოგი კი ამ
ინფორმაციის შემცველ ჰედერს ეყრდნობა.
• Synchronization - რათა დაეხმაროს პაკეტს ქსელთან დაკავშირებაში.
• Packet number – პაკეტის თანმიმდევრობის იდენტიფიცირება.
• Protocol - განსაზღვრავს, თუ რა ტიპის პაკეტი იგზავნება, იქნება ეს ელექტრონული
ფოსტა, ვებ გვერდი, ვიდეოს ნაკადი, ხმის ნაკადი.
• Destination address - სად მიდის პაკეტი
• Originating address - საიდან მოვიდა პაკეტი

Payload ეს არის ფაქტობრივი მონაცემები , რომელიც მიეწოდება დანიშნულების ადგილამდე.

თუ პაკეტი ფიქსირებული სიგრძისაა, მაშინ Payload შეიძლება იყოს ცარიელი , რათა ის
საჭირო ზომის იყოს.

Trailer ეუბნება მიმღებ მოწყობილობას, რომ მიაღწია პაკეტის ბოლოს. მას ასევე შეიძლება
ჰქონდეს გარკვეული ტიპის შეცდომის შემოწმება. შეცდომის ყველაზე გავრცელებული
შემოწმება, რომელიც გამოიყენება პაკეტებში, არის ციკლური სიჭარბის შემოწმება (CRC).

VoIP ტექნოლოგია გარდაქმნის თქვენი ხმის ფრაგმენტებს მონაცემთა პაკეტებად, რომლებიც

ციფრულად გადაიცემა ინტერნეტის საშუალებით. VoIP სერვისებზე ჯიტერის ერთ-ერთი
ყველაზე გავრცელებული მიზეზი არის პაკეტის პრიორიტეტების არარსებობა. თუ ხმოვანი
პაკეტები არ არის პრიორიტეტული, მაშინ საბოლოო მომხმარებელი დიდი ალბათობით
განიცდის ჯიტერს. ინფორმაციის უზარმაზარი რაოდენობა მუდმივად გადადის წინ და უკან -
მილიონობით პაკეტი ყოველ წამში - და მთელი ეს მონაცემები ხშირად ზიანდება ქსელის
რესურსებში, რაც ხშირად იწვევს შეფერხებას. ამ მონაცემთა პაკეტების გაგზავნის შეფერხება
შეიძლება არც ისე აშკარა იყოს ფაილის ან ელ.ფოსტის ჩამოტვირთვისას, მაგრამ როდესაც
თქვენი ხმა იგზავნება, ის შეიძლება იყოს დამახინჯებული და ჟღერდეს
არათანმიმდევრულად.

ჯიტერის მაგალითები

Constant jitter ეს არის პაკეტიდან პაკეტის დაყოვნების ცვალებადობის დაახლოებით მუდმივი

დონე.

Transient jitter ახასიათებს მნიშვნელოვანი თანდათანობითი შეფერხება, რომელიც შეიძლება

წარმოიშვას ერთი პაკეტით.

Short term delay variation დაყოვნების ზრდა, რომელიც გრძელდება გარკვეული რაოდენობის
პაკეტებისთვის და შეიძლება თან ახლდეს პაკეტიდან პაკეტის დაყოვნების ცვალებადობის
ზრდა. ამ ტიპის ჯიტერი ჩვეულებრივ გამოწვეულია გადატვირთულობით და მარშრუტის
ცვლილებებით.

რა არის მისაღები ქსელის ჯიტერი?

ზოგიერთ აპლიკაციას და სერვისს აქვს უფრო მაღალი დონის ტოლერანტობა jitter-ის მიმართ,
ვიდრე სხვებს. რა არის მისაღები ქსელის ჯიტერი? მაგალითად, ჯიტერი არ ახდენს გავლენას
ელ.წერილების გაგზავნაზე ისე, როგორც ეს VoIP ზარებზეა დამოკიდებული, ასე რომ, ეს
დამოკიდებულია იმაზე, თუ რა გვინდა მივიღოთ თქვენი ინტერნეტ სერვისის
პროვაიდერისგან, როგორც დარღვევები და რყევები მონაცემთა გადაცემაში. მაგრამ ცუდი
აუდიო ხარისხი VoIP ზარებსა და ვიდეოს ხარისხში იწვევს მომხმარებლის ცუდ
გამოცდილებას და შეიძლება გავლენა იქონიოს ორგანიზაციის ხაზზე. ყველა ქსელი
განიცდის გარკვეულ შეყოვნებას, განსაკუთრებით ფართო არეალის ქსელები. იდეალურ
შემთხვევაში, ნორმალურად მოქმედ ქსელში, პაკეტები მოძრაობენ თანაბარი ინტერვალებით,
პაკეტებს შორის 10 ms დაგვიანებით. მაღალი ჟიტერის შემთხვევაში, ეს შეიძლება გაიზარდოს
50 ms-მდე, რაც სერიოზულად არღვევს ინტერვალებს და გაურთულებს მიმღებ კომპიუტერს
მონაცემთა დამუშავებას.

იდეალურ შემთხვევაში, ჯიტერი უნდა იყოს 30 ms-ზე ნაკლები. პაკეტის დაკარგვა არ უნდა
იყოს 1%-ზე მეტი, ხოლო ქსელის შეყოვნება არ უნდა აღემატებოდეს 150 ms ცალმხრივი (300
ms დაბრუნება). თუ თქვენ მხოლოდ ერთ ბოლო წერტილს აკონტროლებთ, შეგიძლიათ
შეასრულოთ პინგ ჯიტერის ტესტი საშუალო ორმხრივი დროისა და მინიმალური ორმხრივი
დროის გაანგარიშებით პაკეტების სერიისთვის ხოლო თუ თქვენ გაქვთ კონტროლი ორივე
ბოლო წერტილზე, მაშინ შეგიძლიათ შეამოწმოთ ჯიტერი იმით, რაც ცნობილია როგორც
მყისიერი ჯიტერის გაზომვა( instantaneous jitter). ეს ეხება განსხვავებას გადაცემისა და
მიღების ინტერვალებს შორის ერთი პაკეტისთვის. ამ შემთხვევაში, ჯიტერი გამოითვლება,
როგორც საშუალო სხვაობა მყისიერად ჯიტერის წაკითხვასა და საშუალო მყისიერ ჯიტერს
შორის მრავალ პაკეტში.

რამ შეიძლება გამოიწვიოს ქსელის ჯიტერი

ქსელის ჯიტერის მართვა დამოკიდებულია იმაზე, თუ რა იწვევს ჯიტერს კომპიუტერულ
ქსელებში. რეგულარული ქსელის ჯიტერის ტესტის გაკეთებამ შეიძლება შეამციროს
ჯიტერის გავრცელება თქვენს ქსელში.

Network congestion - ქსელის გადატვირთულობა, რომელიც გამოწვეულია არასაკმარისი

გამტარუნარიანობით, საერთო პრობლემაა. ქსელები გადატვირთულია ტრაფიკის
გადატვირთულით, როდესაც ძალიან ბევრი აქტიური მოწყობილობა მოიხმარს სიჩქარეს.
არსებობს ნაბიჯები, რომელთა გადადგმაც შეგიძლიათ ქსელის გადატვირთულობის
შესამცირებლად, რომლებსაც მოგვიანებით განვიხილავთ.

Poor Hardware Performance - ძველი ქსელები მოძველებული აღჭურვილობით, მათ შორის

მარშრუტიზატორები, კაბელები ან გადამრთველები, შეიძლება იყოს ჯიტერის მიზეზი.
Wireless jitter - უკაბელო ქსელის გამოყენების ერთ-ერთი მინუსი არის დაბალი ხარისხის
ქსელური კავშირი. სადენიანი კავშირები დაგეხმარებათ იმის უზრუნველსაყოფად, რომ
ხმოვანი და ვიდეო ზარის სისტემებმა უზრუნველყონ მომხმარებლისთვის უფრო მაღალი
ხარისხი.

Not implementing packet prioritization - განსაკუთრებით VoIP სისტემებისთვის, ჯიტერი ხდება

მაშინ, როდესაც აუდიო მონაცემების პაკეტების პრიორიტეტი არ არის იმაზე მაღალი ვიდრე
სხვა დანარჩენი პაკეტები.

Quality of Services (QoS) and jitter

სერვისების ხარისხი (QoS) და ჯიტერი
QoS არის ტექნოლოგია, რომელიც მართავს მონაცემთა ტრაფიკს, რათა შეამციროს ჯიტერი
თქვენს ქსელში და თავიდან აიცილოს ან მინიმუმამდე დაიყვანოს ხარისხის დეგრადაცია. QoS
აკონტროლებს და მართავს ქსელის რესურსებს პრიორიტეტების მიხედვით, რომლითაც
მონაცემები იგზავნება ქსელში.
არსებობს ინსტრუმენტები და ტექნიკა, რომლებიც ხშირად შედის ორგანიზაციის ქსელის
სერვისის დონის შეთანხმებაში Service Level Agreement (SLA) შესრულების მისაღები დონის
გარანტირებისთვის.

QoS tools to address jitter

QoS ინსტრუმენტები jitter-ის მოსაგვარებლად

Queuing - საშუალებას გაძლევთ დააყენოთ პრიორიტეტები ან შეუკვეთოთ პაკეტები ისე, რომ

შეფერხებისადმი მგრძნობიარე პაკეტებმა უფრო სწრაფად დატოვონ რიგები, ვიდრე
დაყოვნებისადმი ნაკლებად მგრძნობიარე პაკეტებმა.

Link fragmentation and interleaving (LFI) - მარშრუტიზატორები არ აფერხებენ იმ პაკეტს,

რომელიც ამ მომენტში გადაიცემა, ამიტომ LFI ამცირებს უფრო დიდი პაკეტების ზომებს
მცირე ფრაგმენტებად გაგზავნამდე.

Compression - Payload ან headers შეიძლება იყოს შეკუმშული და ეს ამცირებს მონაცემთა

გადაცემისთვის საჭირო ბიტების საერთო რაოდენობას. ეს მოითხოვს ნაკლებ გამტარობას,
რაც იმას ნიშნავს, რომ რიგები მცირდება, რაც თავის მხრივ ამცირებს დაყოვნებას.

Traffic shaping - ხელოვნურად ზრდის დაყოვნებას, რათა შეამციროს ვარდნა Frame Relay-ში ან
ATM ქსელში.
ზოგადად Traffic shaping (ან packet shaping) არის გამტარუნარიანობის შეზღუდვის ტექნიკა,
რომელიც შეიძლება მოხმარდეს გარკვეულ აპლიკაციებს კრიტიკული აპლიკაციების მაღალი
შესრულების უზრუნველსაყოფად.

როგორ იზომება ქსელის ჯიტერი

Single Endpoint

როდესაც თქვენი ქსელი აკონტროლებს მხოლოდ ერთ ბოლო წერტილს (ცალმხრივი),

ჯიტერი განისაზღვრება საშუალო ორმხრივი დროის (RTT) და ხმოვანი პაკეტების სერიის
მინიმალური RTT-ის გაზომვით.

Double endpoint

ამ დროს საზომი არის მყისიერი ჯიტერი(instantaneous jitter), ანუ ცვალებადობა ერთი პაკეტის
გადაცემისა და მიღების ინტერვალებს შორის. Jitter არის საშუალო განსხვავება მყისიერად
გაზომილ ჯიტერსა და საშუალო მყისიერ ჯიტერს შორის მონაცემთა პაკეტების სერიის
გადაცემის განმავლობაში.

Bandwidth Testing

გამტარუნარიანობის ტესტის შესრულებამ ასევე შეიძლება განსაზღვროს ჯიტერის დონე.

გამტარუნარიანობის ტესტი აფასებს თქვენი ინტერნეტ კავშირის ატვირთვისა და
ჩამოტვირთვის სიჩქარეს.

როგორ მოვაგვაროთ ქსელის პრობლემები

ქსელის ჯიტერის პრობლემების მოგვარება შეიძლება რთული იყოს მისი
არაპროგნოზირებადობის გამო. Jitter-ის მინიმუმამდე დაყვანა იწყება იმით, რომ თქვენი
ქსელი თავდაპირველად სწორად არის დაყენებული. ხარისხიანი ქსელური კავშირის,
საკმარისი გამტარუნარიანობის და პროგნოზირებადი შეყოვნების უზრუნველყოფა
დაგეხმარებათ ქსელის ძაბვის შემცირებაში.

Jitter buffering - VoIP ბოლო წერტილები, როგორიცაა სამაგიდო ტელეფონები და ATA, როგორც
წესი, შეიცავს ჯიტერ ბუფერებს, რათა განზრახ შეაფერხოს შემომავალი მონაცემთა პაკეტები.
Jitter ბუფერი უზრუნველყოფს, რომ მიმღებ მოწყობილობას შეუძლია შეინახოს პაკეტების
გარკვეული რაოდენობა და შემდეგ გაასწოროს ისინი სათანადო თანმიმდევრობით, ისე, რომ
მიმღებმა განიცადოს ხმის მინიმალური დამახინჯება. Jitter ბუფერები არის ერთ-ერთი გზა
ქსელის ჯიტერისა და შეყოვნების მოსაგვარებლად, მაგრამ ყოველთვის არ იმუშავებს. თუ
jitter ბუფერი ძალიან მცირეა, მაშინ ძალიან ბევრი პაკეტი შეიძლება განადგურდეს, რაც
ნიშნავს ცუდი ზარის ხარისხს. თუ ჯიტერის ბუფერი ძალიან დიდია, მაშინ დამატებით
შეფერხებამ შეიძლება გამოიწვიოს საუბრის სირთულე. ტიპიური jitter ბუფერის
კონფიგურაცია არის 30ms-დან 50ms-მდე ზომის. თქვენ შეგიძლიათ გაზარდოთ თქვენი
ჯიტერის ბუფერის ზომა მაგრამ, როგორც წესი, ისინი ეფექტურია მხოლოდ 100 ms-ზე
ნაკლები დაყოვნებისთვის.

შეასრულეთ გამტარუნარიანობის ტესტი - გამტარუნარიანობის ტესტირება აგზავნის

ფაილებს ქსელის მეშვეობით კონკრეტულ კომპიუტერში, შემდეგ ზომავს ფაილების
ჩამოტვირთვისთვის საჭირო დროს დანიშნულების ადგილზე. ეს განსაზღვრავს მონაცემთა
თეორიულ სიჩქარეს ორ წერტილს შორის, რომელიც იზომება კილობიტებში წამში (Kbps) ან
მეგაბიტებში (Mbps). გამტარუნარიანობის ტესტები შეიძლება მნიშვნელოვნად
განსხვავდებოდეს. ფაქტორები, რომლებიც გავლენას ახდენენ ტესტირებაზე, შეიძლება იყოს
ინტერნეტ ტრაფიკი, ხმაური მონაცემთა ხაზებზე, ფაილის ზომა და სერვერზე დატვირთვის
მოთხოვნა ტესტირების დროს. გამტარუნარიანობის ტესტირება იდეალურად უნდა
ჩატარდეს რამდენჯერმე საშუალო გამტარუნარიანობის დასადგენად.

გამოიყენეთ Ethernet კაბელი - თუ იყენებთ დესკტოპ კომპიუტერს ფიქსირებულ სამუშაო

წერტილზე, შესაძლოა ღირდეს ჩაანაცვლება WiFi-ის Ethernet კაბელით, რათა ვუზრუნველყოთ
უფრო ძლიერი კავშირი ნაკლები ჯიტერით.

განაახლეთ თქვენი ქსელის კაბელები - თუ იყენებთ ქსელის კაბელებს, შეიძლება

აღმოაჩინოთ, რომ მოძველებულმა კაბელებმა და გადამრთველებმა ხშირად შეიძლება
გამოიწვიოს მაღალი ჯიტერის პრობლემები. უახლეს კაბელებს შეუძლიათ მონაცემთა
გადაცემა 250 MHz სიხშირეზე, 125 MHz-ისგან განსხვავებით, პოტენციურად გადაჭრის Ethernet
jitter-ს.

შეამოწმეთ თქვენი მოწყობილობის სიხშირე - VoIP ტელეფონი, რომელიც მუშაობს უფრო

მაღალი სიხშირით, ვიდრე სტანდარტული 2.4 გჰც, შეიძლება გამოიწვიოს ჩარევა თქვენს
ქსელში. ზოგიერთი ტელეფონი მუშაობს 5,8 გჰც-მდე სიხშირეზე, რამაც შესაძლოა
გააძლიეროს თქვენი ქსელის არეულობა.

შეამცირეთ სიჩქარის არასაჭირო გამოყენება სამუშაო საათებში - დიდი რაოდენობით

გამტარუნარიანობის გამოყენებამ სამუშაოსთან დაკავშირებული აქტივობებისთვის,
როგორიცაა ქსელური თამაში, ან ვიდეო კონტენტის სტრიმინგი, შეიძლება გააუარესოს
მდგომარეობა.

აპლიკაციებისა და ოპერაციული სისტემების განახლება უნდა განხორციელდეს სამუშაო

დროის მიღმა, რათა გაათავისუფლოს შესაძლებლობები უფრო მნიშვნელოვანი
კომუნიკაციებისთვის.

ქსელის გადატვირთულობის შემცირება

ქსელის გადატვირთულობა არის მონაცემთა გადატვირთვა, რომელიც ანელებს ტრაფიკს
მთელ თქვენს ქსელში. ინტერნეტის ნელი სიჩქარე, გაუმართავი ინტერნეტ კავშირი ან
ვიდეოების ბუფერირება, შეიძლება გავლენა იქონიოს პროდუქტიულობაზე, მომხმარებლის
გამოცდილებაზე და საბოლოოდ დაგიჯდეთ დრო და ფული. ქსელის გადატვირთულობის
შესამცირებლად რამდენიმე გზა არსებობს.

ქსელის ტრაფიკის მონიტორინგი და ანალიზი

სწორი ქსელის მონიტორინგის ინსტრუმენტი დაგეხმარებათ პასუხის გაცემაში. მაგალითად,
ქსელის აღმოჩენის პროგრამას შეუძლია თქვენი კომპანიის ვირტუალური ქსელების,
ღრუბლოვანი სერვერების და ყველა სხვა უკაბელო ქსელის და მოწყობილობის სკანირება,
რათა დაეხმაროს მოწყობილობების, სერვერების და თუნდაც მომხმარებლების
იდენტიფიცირებას, რაც ითვალისწინებს ხელმისაწვდომი გამტარუნარიანობის
მნიშვნელოვან ნაწილს.

პრიორიტეტული ქსელის ტრაფიკი

იმისათვის, რომ მნიშვნელოვანი ონლაინ პროცესები შეუფერხებლად წარიმართოს,

შეგიძლიათ პრიორიტეტულად მივანიჭოთ VoIP ტრაფიკი და ვიდეო ტრაფიკი ისე, რომ
დაზოგოთ სიჩქარეს გარკვეული მომხმარებლებისთვის, მოწყობილობებისთვის ან
პლატფორმებისთვის. ხმოვანი ტრაფიკის ან ვიდეო ქსელის ტრაფიკის პრიორიტეტიზაცია
ნიშნავს, რომ შესაძლოა დაგჭირდეთ ქსელის კავშირების შენელება არასაჭირო ან დაბალი
პრიორიტეტის ფუნქციებისა თუ მოწყობილობებისთვის.

გამტარუნარიანობის გაზრდა

თქვენ ხშირად შეგიძლიათ შეამციროთ გადატვირთულობა თქვენს ქსელში, უბრალოდ

ხელმისაწვდომი გამტარუნარიანობის გაზრდით. როდესაც გაზრდით თქვენი ქსელის
გამტარუნარიანობას, თავად ქსელი შეძლებს ერთდროულად ატაროს მეტი მონაცემი და მეტი
მოწყობილობა. თქვენი ქსელის გამტარუნარიანობის გაზრდა ნიშნავს, რომ თქვენ შეამცირებთ
ჯიტერს და მომხმარებლები ჩვეულებრივ ისარგებლებენ კავშირის უფრო მაღალი სიჩქარით
და ნაკლები შეფერხებით.

Secure Sockets Layer

SSL
როდესაც ინტერნეტ მომხმარებელი ეწვევა უსაფრთხო ვებსაიტს, SSL სერთიფიკატი
უზრუნველყოფს საიდენტიფიკაციო ინფორმაციას ვებ სერვერის შესახებ და ამყარებს
დაშიფრულ კავშირს. ეს პროცესი წამის ფრაქციაში ხდება. SSL სერთიფიკატი არის ციფრული
სერთიფიკატი, რომელიც ამოწმებს ვებსაიტის იდენტურობას და საშუალებას აძლევს
დაშიფრულ კავშირს. SSL ნიშნავს Secure Sockets Layer, უსაფრთხოების პროტოკოლს, რომელიც
ქმნის დაშიფრულ კავშირს ვებ სერვერსა და ვებ ბრაუზერს შორის. კომპანიებმა და
ორგანიზაციებმა უნდა დაამატონ SSL სერთიფიკატები თავიანთ ვებსაიტებზე, რათა
უზრუნველყონ ონლაინ ტრანზაქციები და შეინარჩუნონ მომხმარებლის პირადი
ინფორმაციის უსაფრთხოება.

როგორ მუშაობს SSL სერთიფიკატები

1. ბრაუზერი ან სერვერი ცდილობს SSL-ით დაცულ ვებსაიტთან (მაგ., ვებ
სერვერთან) დაკავშირებას.
2. ბრაუზერი ან სერვერი ითხოვს ვებ სერვერის იდენტიფიცირებას.
3. ვებ სერვერი პასუხად უგზავნის ბრაუზერს ან სერვერს მისი SSL სერთიფიკატის
ასლს.
4. ბრაუზერი ან სერვერი ამოწმებს, ენდობა თუ არა SSL სერთიფიკატს. თუ ეს ასეა,
ეს სიგნალს აძლევს ვებ სერვერს.
5. შემდეგ ვებ სერვერი აბრუნებს ციფრულად ხელმოწერილ დადასტურებას SSL
დაშიფრული სესიის დასაწყებად.
6. დაშიფრული მონაცემები ზიარდება ბრაუზერს ან სერვერსა და ვებსერვერს
შორის.

ამ პროცესს ზოგჯერ მოიხსენიებენ, როგორც "SSL ხელის ჩამორთმევას".

მიუხედავად იმისა, რომ ეს ხანგრძლივ პროცესად ჟღერს, რეალურად ეს
მილიწამებში ხდება. როდესაც ვებსაიტი დაცულია SSL სერთიფიკატით, აკრონიმი
HTTPS (რაც ნიშნავს HyperText Transfer Protocol Secure) გამოჩნდება URL-ში. ხოლო SSL
სერთიფიკატის გარეშე გამოჩნდება მხოლოდ ასოები HTTP - ანუ S-ის გარეშე Secure.
ბოქლომის სიმბოლო ასევე გამოჩნდება URL მისამართის ზოლში. ეს მიანიშნებს
ნდობაზე და აძლევს გარანტიას მათ, ვინც სტუმრობს ვებსაიტს. SSL სერთიფიკატის
დეტალების სანახავად შეგიძლიათ დააწკაპუნოთ ბოქლომის სიმბოლოზე,
რომელიც მდებარეობს ბრაუზერის ზოლში. დეტალები, როგორც წესი, შედის SSL
სერთიფიკატებში მოიცავს:

• დომენის სახელი, რომლისთვისაც გაიცა სერთიფიკატი

• რომელ პიროვნებაზე, ორგანიზაციაზე ან მოწყობილობაზე იყო გაცემული
• რომელმა სასერთიფიკატო ორგანომ გასცა იგი
• სერტიფიკატის ორგანოს ციფრული ხელმოწერა
• ასოცირებული ქვედომენები
• სერთიფიკატის გაცემის თარიღი
• სერტიფიკატის ვადის გასვლის თარიღი
• საჯარო გასაღები (პირადი გასაღები არ არის გამოვლენილი)

რატომ გჭირდებათ SSL სერთიფიკატი

ვებსაიტებს სჭირდებათ SSL სერთიფიკატები მომხმარებლის მონაცემების
უსაფრთხოდ შესანარჩუნებლად, ვებსაიტის საკუთრების დასადასტურებლად,
თავდამსხმელების მიერ საიტის ყალბი ვერსიის შექმნის თავიდან ასაცილებლად
და მომხმარებლებისთვის ნდობის მოსაპოვებლად. თუ ვებსაიტი მომხმარებლებს
სთხოვს პერსონალური დეტალების შეყვანას, როგორიცაა მათი საკრედიტო
ბარათის ნომრები, ან კონფიდენციალური ინფორმაციის შეყვანას, მაშინ
აუცილებელია მონაცემების კონფიდენციალური შენარჩუნება. SSL სერთიფიკატები
ხელს უწყობს ონლაინ ინტერაქციის კონფიდენციალურობას და მომხმარებლებს
არწმუნებს, რომ ვებგვერდი ავთენტურია და უსაფრთხოა პირადი ინფორმაციის
გასაზიარებლად. ბიზნესისთვის უფრო აქტუალურია ის ფაქტი, რომ SSL
სერთიფიკატი საჭიროა HTTPS ვებ მისამართისთვის. HTTPS არის HTTP-ის უსაფრთხო
ფორმა, რაც ნიშნავს, რომ HTTPS ვებსაიტებს აქვთ ტრაფიკი დაშიფრული SSL-ით.
ბრაუზერების უმეტესობა HTTP საიტებს – SSL სერთიფიკატების გარეშე – აღნიშნავს
როგორც „საფრთხის შემცველს“. ეს მკაფიო სიგნალს უგზავნის მომხმარებლებს,
რომ საიტი შეიძლება არ იყოს სანდო. SSL სერთიფიკატი ხელს უწყობს ისეთი
ინფორმაციის დაცვას, როგორიცაა:

• ავტორიზაციის სახელი და პაროლი

• ინფორმაცია საკრედიტო ბარათის ან საბანკო ანგარიშის შესახებ
• პერსონალური იდენტიფიცირებადი ინფორმაცია — როგორიცაა სრული
სახელი, მისამართი, დაბადების თარიღი ან ტელეფონის ნომერი
• იურიდიული დოკუმენტები და კონტრაქტები
• �ამედიცინო ჩანაწერები
• საკუთრების ინფორმაცია

Types of SSL certificate

SSL სერტიფიკატების ტიპები
არსებობს სხვადასხვა ტიპის SSL სერთიფიკატები სხვადასხვა ვალიდაციის დონით.
ექვსი ძირითადი ტიპია:

1. Extended Validation certificates (EV SSL)

2. Organization Validated certificates (OV SSL)

3. Domain Validated certificates (DV SSL)

4. Wildcard SSL certificates

5. Multi-Domain SSL certificates (MDC)

6. Unified Communications Certificates (UCC)

 Extended Validation certificates (EV SSL)

ეს არის ყველაზე მაღალი რანგის და ყველაზე ძვირადღირებული ტიპის SSL

სერთიფიკატი. ის ჩვეულებრივ გამოიყენება მაღალი პროფილის ვებსაიტებისთვის,
რომლებიც აგროვებენ მონაცემებს და მოიცავს ონლაინ გადახდებს.
დაინსტალირებისას ეს SSL სერთიფიკატი აჩვენებს ბოქლომს, HTTPS-ს, ბიზნესის
სახელს და ქვეყანას ბრაუზერის მისამართის ზოლზე. ვებსაიტის მფლობელის
ინფორმაციის ჩვენება მისამართების ზოლში დაგეხმარებათ განასხვავოთ საიტი
მავნე საიტებისგან. EV SSL სერთიფიკატის დასაყენებლად, ვებსაიტის მფლობელმა
უნდა გაიაროს სტანდარტიზებული პირადობის გადამოწმების პროცესი, რათა
დაადასტუროს, რომ ისინი ლეგალურად არიან ავტორიზებული დომენის
ექსკლუზიურ უფლებებზე.

Organization Validated certificates (OV SSL)

SSL სერთიფიკატის ამ ვერსიას აქვს მსგავსი გარანტიის დონე როგორც EV SSL

სერთიფიკატს. მიღების შემდეგ; ვებსაიტის მფლობელმა უნდა დაასრულოს
მნიშვნელოვანი ვალიდაციის პროცესი. ამ ტიპის სერტიფიკატი ასევე აჩვენებს
ვებსაიტის მფლობელის ინფორმაციას მისამართების ზოლში, რათა განასხვავოს
მავნე საიტები. OV SSL სერთიფიკატები, როგორც წესი, მეორე ყველაზე ძვირი
სერთიფიკატია (EV SSL-ების შემდეგ) და მათი მთავარი მიზანია მომხმარებლის
ინფორმაციის დაშიფვრა ტრანზაქციების დროს. კომერციულმა ან საჯარო
ვებსაიტებმა უნდა დააინსტალირონ OV SSL სერტიფიკატი, რათა უზრუნველყონ
კლიენტის ნებისმიერი გაზიარებული ინფორმაციის კონფიდენციალურობა.

Domain Validated certificates (DV SSL)

ამ SSL სერთიფიკატის ტიპის მისაღებად ვალიდაციის პროცესი მინიმალურია და

შედეგად, დომენის ვალიდაციის SSL სერთიფიკატები უზრუნველყოფს დაბალ
გარანტიას და მინიმალურ დაშიფვრას. ისინი, როგორც წესი, გამოიყენება
ბლოგებისთვის ან საინფორმაციო ვებსაიტებისთვის - ანუ, რომლებიც არ
გულისხმობს მონაცემთა შეგროვებას ან ონლაინ გადახდებს. ეს SSL სერთიფიკატის
ტიპი ერთ-ერთი ყველაზე ნაკლებად ძვირი და სწრაფია. ვალიდაციის პროცესი
მხოლოდ ვებსაიტების მფლობელებს მოითხოვს, დაამტკიცონ დომენის საკუთრება
ელ. ფოსტის ან სატელეფონო ზარის პასუხით. ბრაუზერის მისამართის ზოლში
ნაჩვენებია მხოლოდ HTTPS და ბოქლომი ბიზნესის სახელის გარეშე.

Wildcard SSL certificates

Wildcard SSL სერთიფიკატები საშუალებას გაძლევთ უზრუნველყოთ საბაზისო

დომენი და შეუზღუდავი ქვედომენები ერთ სერტიფიკატზე. თუ თქვენ გაქვთ
მრავალი ქვე-დომენი, რომელიც უნდა დაიცვათ, მაშინ Wildcard SSL სერთიფიკატის
შეძენა გაცილებით იაფია, ვიდრე თითოეული მათგანისთვის ინდივიდუალური
SSL სერთიფიკატების შეძენა. Wildcard SSL სერთიფიკატებს აქვთ ვარსკვლავი *,
როგორც საერთო სახელის ნაწილი, სადაც ვარსკვლავი წარმოადგენს ნებისმიერ
მოქმედ ქვედომენს, რომელსაც აქვს იგივე საბაზისო დომენი. მაგალითად, ერთი
Wildcard სერთიფიკატი * ვებსაიტისთვის შეიძლება გამოყენებულ იქნას
დასაცავად:

• გადახდა.yourdomain.com
• ავტორიზაცია.yourdomain.com
• ელ.ფოსტა.yourdomain.com
• გადმოწერა.yourdomain.com
• ნებისმიერი.yourdomain.com

Multi-Domain SSL Certificate (MDC)

მრავალ დომენის სერთიფიკატი შეიძლება გამოყენებულ იქნას მრავალი დომენის

და/ან ქვე-დომენის დასაცავად. ეს მოიცავს სრულიად უნიკალური დომენების და
ქვე-დომენების კომბინაციას სხვადასხვა TLD-ებთან (უმაღლესი დონის
დომენებით), გარდა ადგილობრივი/შიდა დომენებისა. მაგალითად:

• www.example.com
• example.org
• mail.this-domain.net
• example.anything.com.au
• checkout.example.com
• secure.example.org

მრავალ დომენის სერთიფიკატები ნაგულისხმევად არ უჭერს მხარს ქვედომენებს.

თუ თქვენ გჭირდებათ როგორც www.example.com, ასევე example.com-ის დაცვა
ერთი მრავალ დომენის სერტიფიკატით, მაშინ ორივე ჰოსტის სახელი უნდა იყოს
მითითებული სერთიფიკატის მიღებისას.

Unified Communications Certificate (UCC)

Unified Communications Certificates (UCC) ასევე განიხილება მრავალ დომენის SSL

სერთიფიკატებად. UCC თავდაპირველად შეიქმნა Microsoft Exchange და Live
Communications სერვერების დასაცავად. დღეს, ვებსაიტის ნებისმიერ მფლობელს
შეუძლია გამოიყენოს ეს სერთიფიკატები, რათა დაუშვას მრავალი დომენის
სახელი ერთ სერტიფიკატზე. UCC სერთიფიკატები დამოწმებულია
ორგანიზაციულად და აჩვენებს ბოქლომს ბრაუზერზე. UCC შეიძლება
გამოყენებულ იქნას როგორც EV SSL სერთიფიკატები, რათა ვებგვერდის
ვიზიტორებს მისცენ უმაღლესი გარანტია მწვანე მისამართების ზოლის
მეშვეობით.
 CISCO UNIFIED COMUNICATION MANAGER
ცისკოს ერთიანი კომუნიკაციეის მენეჯერი
(CUCM)

ცისკო ერთიანი კომუნიკაციების მენეჯერი არის ზარების და სესიების მართვის

ინფრასტრუქტურა, რომელიც აუმჯობესებს გუნდურ კომუნიკაციას და
კოლაბორაციას დღევანდელი სამუშაო ძალისთვის. CUCM აერთიანებს
რეგისტრირებულ აიპი ტელეფონებს, მობილურ მოწყობილობებს, დესკტოპ
კომპიუტერებს და სხვა საბოლოო წერტილებს ერთ UC პლატფორმაში, საბოლოო
მომხმარებლის ადგილმდებარეობის მიუხედავად. ეს არის არქიტექტურა რომელიც
შესაძლებელს ხდის სამუშაო გუნდები და მომხმარებლები დაუკავშირდნენ თავიანთ
სასურველ მოწყობილობებს მრავალ არხზე მათ შორის:

• ვოიპ ტელეფონია
• ვიდეო და მედია კონფერენცია
• მყისიერი გუნდური ჩეთის შეტყობინებები
• მომხმარებელთა საკონტაქტო ცენტრი
• გარე აპლიკაციები
• მონაცემთა ინტეგრაცია

CUCM-ის არქიტექტურა საშუალებას აძლევს შიდა და გარე გუნდებს დააკავშირონ ზემო

აღნიშნული საკომუნიკაციო არხები ნებისმიერ დროს, ნებისმიერი ადგილიდან და ნებისმიერ
მოწყოილობაზე. CUCM-ის საშუალებით მომხმარებლებს აქვთ მოქნილი საშუალება მიიღონ
ზარები როგორც აიპი ტელეფონებზე ასევე დესკტოპ კომპიუტერებზე, გააგზავნონ სწრაფი
ჩეთ შეტყობინება პლანშეტებზე ან თუნდაც წამოიწყონ ვიდეო ზარი სმარტ ტელეფონებიდან.

ერთიანი კომუნიკაციების მენეჯერი ასევე იძლევა ზარის მართვის აუცილებელ ფუნქციებს

როგორიცაა ზარის დამუშავება, დარეკვის გეგმა (dial plan), დირექტორია სერვისები და სხვა
რაზეც მოგვიანებით ვისაუბრებთ.

CUCM-ოპტიმიზებს ცისკოს Unified Communication Suit-ის ფუნქციონირებას, ის

უზრუნველყოფს შეუფერხებელ თავსებადობას ცისკოს სხვადასხვა აპლიკაციებთან
როგორიცაა Webex, Cisco Jabber, Cisco Unified Contact Center Express და სხვა.

CUCM- მაღალი ხელმისაწვდომობის საშუალებას იძლევა ის ასევე მუშაობს მესამე მხარის

აპებთან, როგორიცაა Microsoft Teams და Slack. CUCM არის მასშტაბირებადი გადაწყვეტა
რომელიც შექმნილია კომუნიკაციის გასაუმჯობესებლად ბიზნესის ყველა ფაზაში.

Cisco UC Components
ცისკოს ერთიანი კომუნიკაციის კომპონენტები

ცისკოს ერთიანი საკომუნიკაციო სტრუქტურა აერთიანებს ხმას, ვიდეოს, და მონაცემთა

ტრაფიკს ერთი ქსელის ინფრასტრუქტურაში. ცისკოს აღჭურვილობა მართავს ტრაფიკის ამ
სამი ტიპის ყველა სტანდარტზე დაფუძნებულ ქსელურ პროტოკოლებთან ურთიერთობისას,
მრავალ ფენიანი სისტემის გამოყენებით ცისკო უზრუნველყოფს ინტეგრირებული
კოორდინირებული პროდუქტების ქსელს.

Call Control Layer

ზარის კონტროლის ფენა
ზარის კონტროლის ფენა ამუშავებს ზარის პროცესს, დარეკვის გეგმის ადმინისტრირებას,
ფუბქციებს და მოწყობილობის კონტროლს, ზარის კონტროლის ფუბქციები ხდება
ინფრასტრუქტურის ფენისგან ფიზიკურად დამოუკიდებელ ზონაში, ეს იმიტომ რომ ზარები
შეიძლება იყოს გეოგრაფიულ მდებარეობებს შორის, ზარის ხარისხის შემცირების გარეშე.

Application Layer
აპლიკაციების ფენა
ცისკოს აპლიკაციები დამოუკიდებლად მუშაობს ზარის მართვის ფუნქციებისგან და ხმის
დამუშავების ფიზიკური ინფრასტრუქტურისგან. ამის ნაცვლად აპლიკაციები
ინტეგრირებულია აიპის მეშვეობით, რაც მათ საშუალებას აძლევს იყოს ნებისმიერ ადგილას
ქსელში. ზოგიერთ პოპულარულ აპლიკაციას მიეკუთვნება Cisco Unified MeetingPlace, Cisco
Emergency Responder, Cisco Unified Presence და სტანდარტული პროტოკოლის ინტერფეისები,
მათ შორის სატელეფონო აპლიკაციის პროგრამირების ინტერფეისი, Java სატელეფონო
პროგრამის ინტერფეისი და მარტივი ობიექტზე წვდომის პროტოკოლი.

Endpoints Layer
საბოლოო წერტილების ფენა

საბოლოო წერტილების ფენა პასუხისმგებელია მომხმარებლისთვის CUCM აპლიკაციის და

ფუნქციონირების სერვისზე, ეს არის ის რაც აკავშირებს საკომუნიკაციო არხებს და ფუნქციებს
მომხმარებლის მიმდინარე საკომუნიკაციო მოწყობილობასთან ‘’Endpoint’’- თან. საბოლოო
წერტილები შეიძლება შეიცავდეს აიპი ტელეფონებს, დესკტოპ კომპიუტერებს, პროგრამულ
ტელეფონებს, ვიდეო ზარის აპარატურას, სმარტ ტელეფონს და ნებისმიერ სხვა თავსებად
საკომუნიკაციო მოწყობილობას.

ერთიანი კომუნიკაციების მენეჯერის უპირატესობები

სანამ დეტალურ აღწერაზე გადავალთ განვიხილოთ CUCM - ის უპირატესობები. სხვა

კონკურეტებთან შედარებით ცისკო 1997 წლიდან უზრუნველყოფს აიპი საკომუნიკაციო
სერვისებსა და აპლიკაციებს, რაც მას ყველაზე ხანგძლივ ფუნქციონირებად სისტემად აქცევს.
ცისკოს ერთიანი კომუნიკაციებით თქვენ შეგიძლიათ შექმნათ ტრანსფორმაციული სამუშაო
ადგილები, რომლებიც თანამშრომლებს საშუალებას აძლევს იმუშაონ იქ სადაც საჭიროა.
CUCM - უზრუნველყოფს საჭირო ინსტრუმენტებს და სთავაზობს ფართო ფუნქციებს
მობილური და დისტანციური თნამშრომლების მხარდასაჭერად. CUCM - ის ლიცენზირება
განისაზღვრება მომხმარებელთა საერთო რაოდენობის, მომხმარებლის ფუნქციების და
კონფიგურირებული მოწყობილოების მიხედვით, ამიტომ ორგანიზაციები იხდიან მხოლოდ
იმ სერვისებისთვის რაც მათ სჭირდებათ. CUCM - მოქნილია როგორც მცირე ბიზნესისთვის
ასევე საწარმო დონის კორპორაციებისთვის 80000 - ამდე მომხმარებლის საჭიროების
შემთხვევაშიც. CUCM - ასევე ადაპტირდება ცვალებად ბიზნეს საჭიროებებთან.

ღია და თავსებადი
CUCM - თან შესაძლებელია მესამე მხარის ინტეგრაცია. ცისკოს გიგანტური ქსელით
სარგებლობით, მომხმარებლებს შეუძლიათ ისარგებლონ ცისკოს კოლაბორაციის მდიდარი
ინსტრუმენტებით, ეს ასევე მოიცავს პარტნიორობას მსხვილ კომპანიებთან როგორიცაა
Microsoft, Amazon Web Services, Google, Saleforce, Dropbox. მაგალითად Webex Cloud-Connected
UC - სერვისებისაშუალებას იძლევა ნრავალ საიტიან ბიზნესს ქონდეს ცენტრალიზირებული
კონტროლი ერთიან კომუნიკაციებზე. ეს მოიცავს ფუნქციებს , როგორიცაა განახლებები,
ანალიტიკა და პრობლემის აღმოფხვრა საიტის სპეციფიკური ზედამხედველობის გარეშე.

უსაფრთხოება

CUCM - ს აქვს მხარდაჭერა უახლესი ავტორიზაციის, დაშიფვრის და კომუნიკაციის

პროტოკოლების პლატფორმა შეესაბამება ინდუსტრიის ძირითად სერთიფიკატებს,
აკმაყოფილებს წარმოების, საცალო და სამთავრობო მომხმარებლის მიერ დადგენილ
უმაღლეს სტანდარტებს მთელ მსოფლიოში, ეს მოიცავს HIPPA, GDPR, PC, CJIS და FedRAMP - ს.
შესაბამისად ცისკოს მომხმარებლები სარგებლობენ ამ მაღალი სტანდარტებით. CUCM - ს აქვს
მხარდაჭერა დაშიფვრის გაფართოებულ სტანდარტზე (AES) 128 - ბიტიანი დაშიფვრის
გასაღები და 32 ბიტიანი ავთენტიფიკაციის ტეგით.

IM and Presence Service

Cisco Unified Presence - ახორციელებს მყისიერ შეტყობინებებს, ეს ხელსაწყოები აძლიერებს

პროდუქტიულობას თანამშრომლებთან უშუალო კავშირის მიწოდებით. თანამშრომლების
ხელმისაწვდომობა Presnce - ის სტატუსის განახლების საშუალებით აადვილებს იმის
გარკვევას თუ ვინ არის ხაზზე და მზად კომუნიკაციისთვის, ეს თავისთავად ეხმარება
მომხმარებლებს დროის დაზოგვაში და ირიდებენ მიუწვდომელ თნამშრომელთან
დაკავშირების მცდელობას. Cisco Jabber არის პირდაპირი შეტყობინების პლატფორმა ასევე
შეიცავს უამრავ ინტეგრაციას ყველა მსხვილი მწარმოებლის პროდუქტებთან, რათა
უზრუნველყოს თნამშრომლების კომუნიკაცია ნებისმიერ დროს.

ანალიტიკა
ცისკო გვთავაზობს ანალიტიკური ინტეგრაციის ფართო სპექტრს რათა კლიენტებმა მიიღონ
მონაცემები, რომლებიც მათ სჭირდებათ რათა გააუმჯობესონ საკომუნიკაციო არხების ფრომა
და ფუნქციონირება, ძირითადი ანალიტიკური შემოთავაზებები მოიცავს:

• Webex Cloud-Connected UC analytics Reports

• Endpoint KPLs, Headest KPLs, Endpoint deployment Distrubution, Headest
Deployment Distribution
• Call Quality, Call Status
• Call Count, Call Duration, End point utilization, Headset Utilization
• CPU Utilization, Memory Utilization, Disk Utilization, Cluster and Node
availabity

Dial Plan Administration

დარეკვის გეგმის ადმინისტრირება

დარეკვის გეგმის ნაკრები საჭიროა იმისთვის რათა CUCM - მა გამოიყენოს ზარის

მარშუტის შესასრულებლად. CUCM - ში მომხმარებელს აქვს შესაძლებლობა შექმნან
მაშტაბური დარეკვის გეგმები ასევე მომხმარებლებს შეუძლიათ განსაზღვრონ
დარეკვის წესები, რომლებიც შემდგომ მართავენ ნებადართული ზარების ტიპებს
ზარის განსახორციელებლად.

Call Routing
ზარის მარშუტიზაცია

მომხმარებლებს შეუძლიათ შექმნან ზარის მარშუტიზაციის ცხრილი CUCM - თან

რეგისტრირებული მოწყობილობებისთვის, ასევე შეიყვანონ დამატებითი მარშუტების
შბლონები სისტემაში კონფიგურირებული ცისკოს აიპი ტელეფონებისათვის და
კომპიუტერული ტელეფონის ინტეგრაციის (CTI) მონაცემთა ბაზაზე.

Call Queuing
 ზარის რიგი

CUCM - ი საშუალებას გვაძლევს ზარები შემომავალი ზარები ჩადგეს რიგში, სანამ

ოპერატორი მზად იქნება რომ მათ უპასუხონ.

Call Recording
ზარის ჩაწერა
CUCM - ს აქვს მხარდაჭერა ზარის ჩაწერის სამი ტიპის და ხელმისაწვდომია როგორც ერთ
კლასტერულ ასევე მრავალ კლასტერულ გარემოში.

1. ავტომატური ჩუმი ჩაწერა, იწყებს ზარის ჩაწერას ყველა ზარზე, ტელეფონზე არ არის
ვიზუალური მითითება რომ ზარის ჩაწერა მიმდინარეობს
2. შერჩევითი ჩუმი ჩაწერა ჩართულია ზედამხედველის მიერ CTI - ზე, შესაძლებელია
ავტომატური ჩაწერისთვის წინასწარ განვსაზღვროთ წესები მოვლენების საფუძველზე
3. მომხმარებლის შერჩევითი ჩაწერა, მომხმარებელი ირჩევს რომელი ზარები ჩაიწეროს.
როდესაც ჩართულია მომხმარებლის შერჩევითი ჩაწერა, ტელეფონი აჩვენებს რომ
ჩაწერის სესია აქტიურია

Remote Worker Emergency Calling

ეს ინსტრუმენტი საშუალებას იძლევა მომხმარებელმა დააყენოს გადაუდებელი

კომუნიკაციის მხარდაჭერა დისტანციურად მომუშავეებისთვის. ოფისის გარეთ მომუშავე
ადამიანის მდებარეობის ინფრომაცია მიეწოდება ყოველ ზარზე თუ გადაუდებელი
შემთხვევა მოხდა მაშველებს ექნებათ მომხმარებლის მისამართი.

Auto-Attendant

მომხმარებელს საშუალებას აძლევს მოხვდნენ შესაბამის განყოფილებაში ან შესაბამის შიდა

ნომერზე რომელიც მათ სჭირდებათ. CUCM - პასუხობს ზარს და უკრავს კონფიგურირებულ
აუდიო მისალმებას შემდეგ აბონენტს აძლევს საშუალებას აირჩიოს განყოფილება, აკრიფოს
შიდა ნომერი ან დაწეროს სახელი.
 Directory Services

CUCM - ი იყენებს შიდა მონაცემთა ბაზას ინფორმაციის შესანახად, ის ახორციელებს

მომხმარებლის ავთენტიფიკაციას ამ დირექტორიაში და შეუძლია მისი სინქნორიზაცია
მომხმარებლის ცენტრალიზირებული მართვისთვის, ეს პროცესი საშუალებას CUCM - ს
გამოიყენოს ისეთი ინტეგრირებული ინსტრუმენტები როგორიცაა Microsoft Active Directory,
Netscape, Iplanet და Sun one. CUCM - ი საშუალებას იძლევა ადგილობრივი და გარე
დირექტორიებთან მუშაობას. ასევე გვთავაზობს Called Name Display - ის რომელიც
უზრუნველყოფს მომხმარებლის სრულ სახელს ტელეფონის ნომერთან ერთად.

პროგრამირების ინტერფეისი გარე აპლიკაციებთან

CUCM - უზრუნველყოფს პროგრამირების ინტერფეისს გარე აპლიკაციეთან როგორიცაა Cisco

IP Softphone, Cisco IP Communicator, Cisco Unified IP Interactive Voice Response – (IP IVR), Cisco
Unified Personal Communicator და CUCM Attendant Console.

Integration
ინტეგრაცია
CUCM - შექმნილია ცისკოს აპარატურასა და პროგრამულ უზრუნველყოფასთან უკეთესად
ინტეგრირებისთვის, თუმცა ის ასევე თავსებადია მესამე მხარის მოწყობილობებთან და
ბიზნეს საკომუნიკაციო აპლიკაციებთან. Cisco end point ტექნიკის ინტეგრაცია მოიცავს Cisco ip
ტელეფონებს, Webex დაფებს, Webex room სერიებს, Webex ყურსასმენებს, Webex desk pro - ს და
კიდევ ბევრ სხვა ცისკოს მოწყობილობას. მესამე მხარის ინტეგრაცია მოიცავს Poly და Yealink IP
ტელეფონებს, Jabra headsets და სხვა. CUCM ინტეგრირდება ცისკოს ბიზნეს საკომუნიკაციო
გადაწყვეტილებებთან როგორიცაა:

• Webex Meetings
• Webex Calling
• Cisco Jabber
• Cisco Unified Mobility
• Webex Events
• Cisco UC Manager IM and Presence Service
• Cisco Webex Messenger
• Cisco Unified Contact Center Enterprise
• Cisco Business Edition 7000
• Cisco Business Edition 6000
• Cisco Network Route Director
• Cisco UC Integration for Microsoft Lync
• Cisco Expressway Series
• Cisco Unified Border Element
• Cisco Emergency Responder
• Cisco Office Manager
• Cisco Paging Server
• Cisco RSVP Agent
• Cisco Unified CallConnectors
• Cisco Unified Communications Widgets
• Cisco WebAttendant

Cisco Unity Connection

 CUC
გამოიყენება ხმოვანი ფოსტის სერვისებისთვის ასევე უზრუნველყოფს სხვა მახასიათებლებს
როგორიც არის basic auto-attendant functionality. უპირატესობები:

1. სწრაფი და მოქნილი წვდომა შეტყობინებებზე მომხმარებლისთვის

მომხმარებლებს შეუძლიათ დაზოგონ დრო და გაზარდონ პროდუქტიულობა

შეტყობინებებზე სწრაფი და ეფექტური წვდომით, მათ მიერ გამოყენებული
მოწყობილობებიდან და აპლიკაციებიდან, მიწოდებული მათთვის სასურველი
ფორმატით.

Unity Connection მხარს უჭერს აუდიო და ვიდეო შეტყობინებებს, ტელეფონიდან

ტელეფონზე ვიდეო მესიჯებს, ასევე მეტყველების ტექსტურ შეტყობინებაში
ტრანსკრიფციას.

2. მარტივი და ეფექტური ადმინისტრირება და მართვა

Unity Connection ვირტუალიზებულია, მოქნილი და ადვილად ინტეგრირებულია ქსელში

და აპლიკაციის გარემოში. Unity Connection იმართება Prime Collaboration-ის მიერ,
შესაძლებელია სერვისის გააქტიურება, მონიტორინგი, შესრულების ანალიზი და
ანგარიშგება, განახლება, მიგრაციისა და ლიცენზიების მართვა.

3. მაღალი დონის უსაფრთხოება

მასშტაბირებადი და თავსებადი Unity Connection არის შეტყობინებების ერთიანი

გადაწყვეტა. რომელსაც თანმიმდევრულად ირჩევენ საშუალო და გლობალური
კორპორაციები, სამთავრობო უწყებები და უსაფრთხოების სამსახურები 2005 წლიდან.

Cisco Meeting Server

(CMS)
CMS არის მასშტაბური, უსაფრთხო, შიდა შეხვედრების გადაწყვეტილება. CMS მოიცავს
cisco webex-ს და ის ასევე უზრუნველყოფს ფართო კონფიგურაციას ვიდეო, აუდიო და ვებ
კომუნიკაციისთვის. CMS ვებ აპი ნებისმიერს საშუალებას აძლევს შექმნას, შეუერთდეს და
გაუშვას შეხვედრები მარტივად, ბრაუზერის მეშვეობით. მომხმარებლებს ასევე
შეუძლიათ სწრაფად შეუერთდნენ შეხვედრას აპლიკაციის ჩამოტვირთვის გარეშე,
ბრაუზერების გამოყენებით რომელთაც აქვთ WebRTC მხარდაჭერა.
 Cisco Telepresence Management Suite
(TMS)
შეიძლება დაერთოს CMS-ს, რათა მართოს ვიდეო კონფერენციის მოწყობილობები ქსელში,
ცენტრალიზებული შეხვედრის დაგეგმვასთან ერთად. TMS-ი უზრუნველყოფს ფართო
მაშტაბიან ჩართვებს გამარტივებული კონფიგურაციით, კომპლექტს აქვს 100 ათასამდე
მომხმარებლის მხარდაჭერა, ასევე მხარს უჭერს 5000-მდე პირდაპირ მართულ
მოწყობილობას, აქვს გამარტივებული ინტეგრაცია, აერთიანებს სატელეფონო წიგნაკებს
სხვადასხვა გარე ინფორმაციის წყაროებიდან და არსებული დირექტორიებიდან. ასევე
შესაძლებლობას იძლევა გამოვიყენოთ Microsoft exchange-ის გაფართოებებთან ერთად,
რათა დავგეგმოთ შეხვედრები უშუალოდ Microsoft Outlook-ის კლიენტებთან. TMS-ი ასევე
საშუალებას იძლევა კონტაქტების მარტივ მართვას, ადმინისტრირებას, კონფიგურაციის
ცენტრალიზებულ მართვას, ქსელის მიმოხილვას, საინფორმაციო დაფებს, სტატუსის
ინდიკატორებს.

Cisco Meeting Manager

(CMM)
Cisco Meeting Manager (CMM) უზრუნველყოფს CMS-ის გარშემო გაერთიანებულ
მენეჯმენტის სერვისების ერთობლიობას.

Cisco Prime Collaboration Deployment

(PCD)
კოლაბორაციის მართვის პროგრამა როგორიცაა (PCD) ეხმარება UC-ინჟინრებს
კოლაბორაციის პროგრამების განთავსებაში, მიგრაციასა და დამონტაჟებაში, ხოლო Prime
Collaboration Provisioning (PCP) უზრუნველყოფს ადგილს, რათა შეასრულოს
გადაადგილება, დამატება, შეცვლა და ოპერაციების წაშლა სისტემის სხვადასხვა
კონფიგურაციისთვის, საბოლოო წერტილებისა და მომხმარებლებისთვის.
 Cisco Unified Contact Center Express (UCCX)

Cisco Unified Contact Center Express (UCCX) რომელიც უზრუნველყოფს მომხმარებელთა

ურთიერთქმედების მართვის უსაფრთხო და ადვილად გამოსაყენებელ გადაწყვეტას 400-მდე
აგენტისთვის. ეს არის IP-ზე დაფუძნებული ავტომატური ზარის განაწილების (ACD) სისტემა,
რომელიც ანაწილებს რიგებს და შემომავალ ზარებს, რომლებიც განკუთვნილია Cisco Unified
Communications Manager-ის მომხმარებლების

Unified CCX გთავაზობთ ვარიანტებს მრავალი საკონტაქტო ცენტრის ფუნქციონალური

უბნების მიმართ, როგორიცაა:

• Inbound voice
• Outbound campaign
• Agent email
• Web chat
• Next-generation historical and real-time reports and dashboards

CCX შეიძლება გამოყენებულ იქნას ზარების გადასატანად კონკრეტულ აგენტებთან ან

თუნდაც ერთიან IP IVR-თან ინტეგრირებისთვის, აბონენტის მონაცემების შეგროვებისა და
შემომავალი ზარების კლასიფიკაციისთვის. დეველოპერებს შეუძლიათ ერთიან CCX-თან
ინტეგრირება შემდეგი გზით:

• Computer Telephony Integration (CTI) Protocol

• Configuration REST API
• Cisco Unified CCX Editor
• Cisco Identity Service Client SDK
 ტექნიკური მიმოხილვა

Unified CCX სისტემა შედგება შემდეგი კომპონენტებისგან, რომლებიც უზრუნველყოფს

პროგრამირებადი ინტერფეისებს სხვა აპლიკაციებისთვის:

• Unified CCX Engine

• Administration API Web Application
• Finesse

Unified CCX Engine

Unified CCX Engine ასრულებს Contact Center Express-ის ძირითად ფუნქციებს, რომელიც
მოიცავს:

• IVR ფუნქციები ხმოვანი ზარებისთვის

• პროგრამირებადი სკრიპტები
• აგენტი და საკონტაქტო მენეჯმენტი
• რიგი და მარშრუტიზაცია
• კომპიუტერული სატელეფონო ინტეგრაციის (CTI) შეტყობინებები
• მონაცემთა გენერირება ცოცხალი მონაცემებისა და ისტორიის რეპორტები

CTI Server
CTI სერვერი პასუხისმგებელია ზარების თვალყურის დევნებაზე, აგენტის მდგომარეობებზე
და ყველა CTI კლიენტთან სოკეტის კავშირების შენარჩუნებაზე. ის ასევე ამუშავებს CTI
კლიენტების მოთხოვნებს და აგზავნის განახლებებს, როდესაც ხდება ცვლილებები. CTI
კლიენტები უკავშირდებიან და ურთიერთობენ CTI სერვერთან/CCX ძრავთან ერთიანი CCX CTI
პროტოკოლის მეშვეობით. CTI პროტოკოლის გამოყენებით, აპლიკაციებს შეუძლიათ:

• make agent login requests

• manage state
• make/answer/drop calls
• receive agent and team configuration events
• silent monitor calls
• and many more operations

Programmable Scripting Engine

Unified CCX უზრუნველყოფს დეველოპერებს შესაძლებლობას დააპროგრამონ ბიზნეს ლოგიკა,

თუ როგორ უნდა მართონ ხმოვანი ზარი ან Http კონტაქტი (მომხმარებლის მიერ
შესრულებული ვებ-მოქმედება) ძრავის მიერ. სკრიპტირება გულისხმობს ბიზნეს სამუშაო
ნაკადის შექმნას საკუთრების დომენის სპეციფიკური პროგრამირების ხელსაწყოს, Unified CCX
Editor-ის გამოყენებით და განსაზღვრული სამუშაო ნაკადის შენახვას UCCX-ში ატვირთვის
ფაილად ადმინისტრაციის ვებსა და REST ინტერფეისის საშუალებით. ერთიანი CCX
რედაქტორი უზრუნველყოფს მომხმარებლის გრაფიკულ ინტერფეისს სკრიპტის
შესაქმნელად და შესამოწმებლად.

სკრიპტის პროგრამირების ინდივიდუალური ნაბიჯები უნდა შეირჩეს არსებული pool-იდან .

თუ ხელმისაწვდომი ნაბიჯები არ არის საკმარისი, მაშინ შეიძლება განხორციელდეს Java
პროგრამირების ენის გამოყენებით.