SIP протоколымен жұмыс істейтін VoIP желілерін қорғау үшін Session Border Controller (SBC) құрылғысы қолданылады. WebRTC қолданбаларымен интеграция мүмкін.
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Кіріспе
VoIP желілерінде орналастырылған желілік құрылғы
Network device deployed in VoIP networks
Сеанс шекаралық контроллері (SBC) – SIP протоколы негізіндегі дауыс протоколы арқылы Интернет-желісі (VoIP) желілерін қорғау үшін орналастырылған желілік элемент. SBC-лердің алғашқы орналастырылуы екі қызмет провайдері желілері арасындағы байланыс шекараларына бағытталған. Бұл рөл қазір қызмет провайдерінің кіру желісі мен магистральдық желі арасындағы тұрғын және/немесе кәсіпкерлік клиенттерге қызмет көрсету үшін маңызды жүзеге асыруларға дейін кеңейді. SIP over WebSockets (RFC 7118) көбінесе SIP-тің көзделіп отырған байланыс сценарийлерінің көпшілігіне қолданылу мүмкіндігі және JsSIP сияқты ашық кодты бағдарламалық қамтамасының болуына байланысты қолданылады. Мұндай жағдайда SBC WebRTC қолданбалары мен SIP терминалдары арасындағы шлюз ретінде жұмыс істейді.
A session border controller (SBC) is a network element deployed to protect SIP based voice over Internet Protocol (VoIP) networks. Early deployments of SBCs were focused on the borders between two service provider networks in a peering environment. This role has now expanded to include significant deployments between a service provider's access network and a backbone network to provide service to residential and/or enterprise customers. SIP over WebSockets (RFC 7118) is often used partially due to the applicability of SIP to most of the envisaged communication scenarios as well as the availability of open source software such as JsSIP. In such a case the SBC acts as a gateway between the WebRTC applications and SIP end points.
Қолданбалар
SBC-лер VoIP қоңырауындағы шақырушы және шақырылған тараптар арасындағы сигнал беру және/немесе медиа жолдарына енгізіледі, көбінесе сессияны бастау протоколы (SIP), H.323 және MGCP қоңырау сигнализациясы протоколдарын пайдаланады. Көп жағдайда SBC желі топологиясын жасырады және қызмет провайдерінің немесе кәсіпорынның пакеттік желілерін қорғайды. SBC кіріс қоңырауды аяқтап, екінші қоңырау аяғын бағыттық тарапқа бастайды. Техникалық тұрғыдан алғанда, SIP протоколымен қолданылғанда, бұл кері пайдаланушы агентін (B2BUA) анықтайды. Бұл мінез-құлықтың салдары – сигнал беру трафигі ғана емес, сонымен қатар медиа трафигі (дауыс, бейне) SBC арқылы басқарылады. Егер SBC медиа қызметтерін ұсыну мүмкіндігіне ие болмаса, SBC медиа трафигін желідегі басқа элементке, жазу, күтіп тұру музыкасын жасау немесе басқа медиамен байланысты мақсаттар үшін қайта бағыттауға қабілетті. Керісінше, SBC болмаған жағдайда, медиа трафигі тікелей соңғы нүктелер арасында жүреді, желілік қоңырау сигнализация элементтері оның жолын бақыламайды. Басқа жағдайларда, SBC әрбір қоңырауда қатысатын қоңырауды басқару (сигнал беру) деректерінің ағынын ғана өзгертеді, мүмкін жүргізілетін қоңырау түрлерін шектейді, кодектерді таңдайды және т.б. Нәтижесінде, SBC желі операторларына желілеріндегі қоңырауларды басқаруға, өзара іс-қимылға қол жеткізу үшін протоколдарды және протоколдық синтаксисті түзетуге немесе өзгертуге, сондай-ақ өрт қабырғалары мен желілік адресті аударушылардың (NAT) VoIP қоңыраулары үшін туындайтын кейбір мәселелерді шешуге мүмкіндік береді. SBC-нің жұмысын көрсету үшін, қарапайым қоңырау орнату тізбегін SBC-мен қоңырау орнату тізбегімен салыстыруға болады. Тек бір прокси бар ең қарапайым сессия орнату тізбегінде проксинің міндеті – шақырылған тараптың орналасқан жерін анықтау және сұрауды оған жіберу. Прокси сондай-ақ жауаптың өтуі керек жолын көрсету үшін өзінің мекенжайы бар Via баслығын қосады. Прокси хабарламадағы диалогты анықтау ақпаратын, мысалы, From баслығындағы тег, Call Id немесе Cseq өзгертпейді. Проксилер SIP хабарламаларының мазмұнындағы ақпаратты өзгертпейді. Сессияны бастау кезеңінде пайдаланушы агенттері медиа трафигін күтетін мекенжайларды қамтитын SDP органдарымен SIP хабарламаларын алмасады. Сессияны бастау кезеңін сәтті аяқтағаннан кейін пайдаланушы агенттері проксинің қатысуынсыз бір-бірімен тікелей медиа трафигін алмастыра алады. SBC көптеген қолданулар үшін жасалған және операторлар мен кәсіпорындар оларды әртүрлі мақсаттарға жету үшін пайдаланады. Тіпті бір SBC іске асыруы оның конфигурациясына және қолдану жағдайына байланысты әртүрлі әрекет ете алады. Сондықтан барлық SBC-ге қолданылатын нақты SBC мінез-құлқын сипаттау оңай емес. Жалпы алғанда, SBC-ге ортақ кейбір ерекшеліктерді анықтауға болады. Мысалы, көптеген SBC пайдаланушы агенті ретінде іске асырылады. B2BUA – бұл SIP транзакциясын екі қоңырау аяғына бөлетін прокси-сервер: пайдаланушы агенті клиентіне (UAC) қараған жағында ол сервер ретінде әрекет етеді, пайдаланушы агенті серверіне (UAS) қараған жағында ол клиент ретінде әрекет етеді. Прокси әдетте тек белсенді транзакцияларға қатысты жай-күй ақпаратын сақтайды, ал B2BUA белсенді диалогтар туралы, мысалы, қоңыраулар туралы жай-күй ақпаратын сақтайды. Яғни, прокси SIP сұранысын алғаннан кейін кейбір жай-күй ақпаратын сақтайды. Транзакция аяқталғаннан кейін, мысалы, жауап алғаннан кейін, жай-күй ақпараты көп ұзамай жойылады. B2BUA белсенді қоңыраулар туралы ақпаратты сақтайды және бұл ақпаратты қоңырау аяқталғаннан кейін ғана жояды. Шақыру жолына SBC енгізілген кезде, SBC шақырушыға қатысты пайдаланушы агенті сервері ретінде және шақырылған тарапқа қатысты пайдаланушы агенті клиенті ретінде әрекет ететін B2BUA ретінде әрекет етеді. Осы мағынада, SBC шақырушы жасаған қоңырауды аяқтап, шақырылған тарапқа жаңа қоңырауды бастайды. SBC жіберген INVITE хабарламасында шақырушы туралы нақты сілтеме болмайды. SBC-нің проксиге жіберген INVITE-де Via және Contact баслықтары бар, олар шақырушы емес, SBC-нің өзіне сілтеме жасайды. SBC-лер көбінесе Call Id және From тегтерінде көрсетілген диалогты анықтау ақпаратын да өңдейді. Сонымен қатар, егер SBC медиа трафигін басқаруға конфигурацияланған болса, онда SBC сонымен қатар SDP корпусының c және m жолдарына енгізілген медиа мекенжайлау ақпаратын өзгертеді. Осылайша, SIP хабарламаларының барлығы ғана емес, сонымен қатар барлық аудио және бейне пакеттері SBC арқылы өтеді. SBC жіберген INVITE жаңа диалогты орнататындықтан, SBC сондай-ақ хабарлама тізбегінің нөмірін (CSeq) және Max Forwards мәнін де өңдейді. Мұнда тізімделген баслықтарды өңдеу тізімі SIP хабарламасына SBC енгізе алатын мүмкін өзгерістердің бір бөлігі ғана екенін ескеріңіз. Сонымен қатар, кейбір SBC тізімделген өңдеулердің барлығын жасамауы мүмкін. Егер SBC медиа трафигін басқаруға күтілмесе, онда SDP корпусында ештеңені өзгертудің қажеті болуы мүмкін. Кейбір SBC диалогты анықтау ақпаратын өзгертпейді, ал басқалары тіпті мекенжайлау ақпаратын өзгертпеуі мүмкін. SBC-лер көбінесе корпорациялармен бірге өрт қабырғаларымен және басқыншылықты алдын алу жүйелерімен (IPS) қорғалған кәсіпорын желісіне және одан VoIP қоңырауларын жасау үшін қолданылады. VoIP қызмет провайдерлері SBC-лерді NAT пайдаланатын жеке желілерден VoIP протоколдарын пайдалануға және қызмет сапасын сақтау үшін қажетті күшті қауіпсіздік шараларын іске асыруға мүмкіндік береді. SBC-лер сондай-ақ қолданба деңгейінің шлюздерінің функциясын ауыстырады.
SBCs are inserted into the signaling and/or media paths between calling and called parties in a VoIP call, predominantly those using the Session Initiation Protocol (SIP), H.323, and MGCP call signaling protocols. In many cases the SBC hides the network topology and protects the service provider or enterprise packet networks. The SBC terminates an inbound call and initiates the second call leg to the destination party. In technical terms, when used with the SIP protocol, this defines a back to back user agent (B2BUA). The effect of this behavior is that not only the signaling traffic, but also the media traffic (voice, video) is controlled by the SBC. In cases where the SBC does not have the capability to provide media services, SBCs are also able to redirect media traffic to a different element elsewhere in the network, for recording, generation of music on hold, or other media related purposes. Conversely, without an SBC, the media traffic travels directly between the endpoints, without the in network call signaling elements having control over their path. In other cases, the SBC simply modifies the stream of call control (signaling) data involved in each call, perhaps limiting the kinds of calls that can be conducted, changing the codec choices, and so on. Ultimately, SBCs allow the network operators to manage the calls that are made on their networks, fix or change protocols and protocol syntax to achieve interoperability, and also overcome some of the problems that firewalls and network address translators (NATs) present for VoIP calls. To show the operation of an SBC, one can compare a simple call establishment sequence with a call establishment sequence with an SBC. In the simplest session establishment sequence with only one proxy between the user agents the proxy’s task is to identify the callee’s location and forward the request to it. The proxy also adds a Via header with its own address to indicate the path that the response should traverse. The proxy does not change any dialog identification information present in the message such as the tag in the From header, the Call Id or the Cseq. Proxies also do not alter any information in the SIP message bodies. Note that during the session initiation phase the user agents exchange SIP messages with the SDP bodies that include addresses at which the agents expect the media traffic. After successfully finishing the session initiation phase the user agents can exchange the media traffic directly between each other without the involvement of the proxy. SBCs are designed for many applications and are used by operators and enterprises to achieve a variety of goals. Even the same SBC implementation might act differently depending on its configuration and the use case. Hence, it is not easily possible to describe an exact SBC behavior that would apply to all SBC implementations. In general it is possible to identify certain features that are common to SBCs. For example, most SBCs are implemented as back to back user agent. A B2BUA is a proxy like server that splits a SIP transaction in two call legs: on the side facing the user agent client (UAC), it acts as server, on the side facing user agent server (UAS) it acts as a client. While a proxy usually keeps only state information related to active transactions, B2BUAs keep state information about active dialogs, e. g., calls. That is, once a proxy receives a SIP request it will save some state information. Once the transaction is over, e. g., after receiving a response, the state information will soon after be deleted. A B2BUA will maintain state information for active calls and only delete this information once the call is terminated. When an SBC is included in the call path, the SBC acts as a B2BUA that behaves as a user agent server towards the caller and as user agent client towards the callee. In this sense, the SBC actually terminates that call that was generated by the caller and starts a new call towards the callee. The INVITE message sent by the SBC contains no longer a clear reference to the caller. The INVITE sent by the SBC to the proxy includes Via and Contact headers that point to the SBC itself and not the caller. SBCs often also manipulate the dialog identification information listed in the Call Id and From tag. Further, in case the SBC is configured to also control the media traffic then the SBC also changes the media addressing information included in the c and m lines of the SDP body. Thereby, not only will all SIP messages traverse the SBC but also all audio and video packets. As the INVITE sent by the SBC establishes a new dialog, the SBC also manipulates the message sequence number (CSeq) as well the Max Forwards value. Note that the list of header manipulations listed here is only a subset of the possible changes that an SBC might introduce to a SIP message. Furthermore, some SBCs might not do all of the listed manipulations. If the SBC is not expected to control the media traffic then there might be no need to change anything in the SDP body. Some SBCs do not change the dialog identification information and others might even not change the addressing information. SBCs are often used by corporations along with firewalls and intrusion prevention systems (IPS) to enable VoIP calls to and from a protected enterprise network. VoIP service providers use SBCs to allow the use of VoIP protocols from private networks with Internet connections using NAT, and also to implement strong security measures that are necessary to maintain a high quality of service. SBCs also replace the function of application level gateways.