세션 테두리 제어기

Session border controller

세션 경계제어기(SBC)는 인터넷 프로토콜(VoIP) 네트워크를 통한 SIP 기반 음성을 보호하기 위해 구축된 네트워크 요소다.

SBC의 초기 구축은 피어링 환경에서 두 서비스 제공자 네트워크 사이의 경계에 초점을 맞추었다. 이제 이 역할은 주거용 및/또는 기업 고객에게 서비스를 제공하기 위한 서비스 제공자의 액세스 네트워크와 백본 네트워크 사이의 중요한 배치를 포함하도록 확장되었다.[1]

"세션"이라는 용어는 둘 이상의 당사자 사이의 통신을 의미하며, 전화의 맥락에서 이것은 통화일 것이다. 각 통화는 통화를 제어하는 하나 이상의 통화 신호 메시지 교환과 통화 통계 및 품질 정보와 함께 통화의 오디오, 비디오 또는 기타 데이터를 전달하는 하나 이상의 통화 미디어 스트림으로 구성된다. 이 개울들은 함께 하나의 세션을 구성한다. 세션의 데이터 흐름에 영향력을 행사하는 것은 세션 경계 통제관의 일이다.

"경계"란 네트워크의 한 부분과 다른 부분 사이의 경계점을 말한다. 간단한 예로, 기업 네트워크의 가장자리에서는 방화벽이 나머지 인터넷(기업 외부)으로부터 로컬 네트워크(기업 내부)를 구분한다. 좀 더 복잡한 예는 서로 다른 부서가 위치별, 어쩌면 데이터 종류별로 보안 요구를 가지고 있는 대기업의 경우다. 이 경우, 데이터 스트림의 흐름을 제어하기 위해 필터링 라우터나 다른 네트워크 요소를 사용한다. 정책 관리자가 이러한 경계를 가로지르는 세션 데이터의 흐름을 관리하는 데 도움을 주는 것은 세션 경계 컨트롤러의 일이다.

"컨트롤러"라는 용어는 세션 경계 컨트롤러가 네트워크의 한 부분과 다른 부분 간의 경계를 통과하기 때문에 세션을 구성하는 데이터 스트림에 미치는 영향을 말한다. 또한 세션 경계 제어기는 종종 자신이 제어하는 호출에 대한 측정, 접근 제어 및 데이터 변환 기능을 제공한다.

기능들

SBC는 일반적으로 전체 세션 상태를 유지하고 다음과 같은 기능을 제공한다.

  • 보안 – 네트워크 및 기타 장치를 다음으로부터 보호:
    • 서비스 거부 공격(DoS) 또는 분산된 DoS와 같은 악의적인 공격
    • 악성 미디어 스트림을 통한 요금 부정 행위
    • 잘못된 형식의 패킷 보호
    • TLS 및 IPSec을 통한 신호 암호화 및 미디어(SRTP)
  • 연결 – 네트워크의 다른 부분이 다음과 같은 다양한 기법을 사용하여 통신할 수 있도록 허용한다.
    • NAT 트래버설
    • SIP 메시지 및 헤더 조작을 통한 SIP 표준화
    • IPv4와 IPv6의 연동
    • VPN 연결
    • SIP, SIP-I, H.323 간 프로토콜 변환
  • 서비스 품질 – 네트워크의 QoS 정책과 흐름의 우선순위는 일반적으로 SBC에 의해 구현된다. 다음과 같은 기능을 포함할 수 있다.
  • 규제 – 여러 번 SBC가 다음과 같은 규제 요건을 지원할 것으로 예상된다.
  • 미디어 서비스 – 많은 차세대 SSP는 또한 국경 기반 미디어 제어 및 다음과 같은 서비스를 제공할 수 있도록 DSP(디지털 신호 프로세서)를 내장하고 있다.
    • DTMF 계전기 및 연동
    • 미디어 트랜스코딩
    • 신호음 및 알림
    • 데이터 및 팩스 연동
    • 음성 및 화상 통화 지원
  • 통계 및 청구 정보 – 네트워크의 가장자리를 통과하는 모든 세션이 SBC를 통과하므로, 이러한 세션에 대한 통계 및 사용량 기반 정보를 수집하는 것은 자연스러운 지점이다.

WebRTC의 출현과 함께 일부 SBC는 WebRTC 게이트웨이에 대한 SIP의 역할을 맡았고 SIP를 번역했다. WebRTC 규격에 의해 신호 프로토콜이 의무화되지는 않지만,[2] WebSockets (RFC 7118)는 JSIP와 같은 오픈 소스 소프트웨어의 가용성뿐만 아니라 대부분의 예상된 통신 시나리오에 SIP의 적용 가능성 때문에 부분적으로 사용되는 경우가 많다. 그러한 경우에 SBC는 WebRTC 애플리케이션과 SIP 엔드 포인트 사이의 게이트웨이 역할을 한다.

적용들

SBC는 주로 SIP(Session Initiation Protocol), H.323 및 MGCP 통화-신호 프로토콜을 사용하는 전화 당사자와 통화 당사자 사이의 신호 및/또는 미디어 경로에 삽입된다.

많은 경우에 SBC는 네트워크 토폴로지를 숨기고 서비스 제공자나 기업 패킷 네트워크를 보호한다. SBC는 인바운드 호출을 종료하고 목적지 당사자에게 두 번째 호출을 개시한다. 기술 용어로 SIP 프로토콜과 함께 사용할 경우, 이것은 연속 사용자 에이전트(B2B)를 정의한다.UA). 이러한 행동의 효과는 신호 트래픽뿐만 아니라 미디어 트래픽(음성, 비디오)도 SBC에 의해 제어된다는 것이다. SBC가 미디어 서비스를 제공할 수 있는 기능이 없는 경우, SBC는 녹음, 보류 음악 생성 또는 기타 미디어 관련 목적을 위해 네트워크 내 다른 곳에 있는 다른 요소로 미디어 트래픽을 리디렉션할 수도 있다. 반대로, SBC가 없으면, 미디어 트래픽은 네트워크 내 통화 신호 요소가 경로를 제어하지 않고 엔드포인트 사이를 직접 이동한다.

다른 경우에, SBC는 단순히 각 통화에 관련된 통화 제어(신호화) 데이터의 흐름을 수정하며, 아마도 수행할 수 있는 통화의 종류를 제한하고, 코덱 선택을 변경하는 등의 작업을 한다. 궁극적으로 SBC는 네트워크 사업자가 자신의 네트워크에서 이루어지는 통화를 관리하고 프로토콜과 프로토콜 구문을 수정 또는 변경하여 상호운용성을 달성하며, 또한 VoIP 통화에 대해 방화벽과 네트워크 주소 변환기(NATs)가 제시하는 몇 가지 문제를 극복할 수 있도록 한다.

SBC의 작동을 보여주기 위해 간단한 통화 설정 순서와 SBC의 통화 설정 시퀀스를 비교할 수 있다.[3] 사용자 에이전트 사이에 하나의 프록시만 있는 가장 간단한 세션 설정 순서에서 프록시의 임무는 캘리어의 위치를 식별하고 요청을 해당 에이전트에 전달하는 것이다. 또한 프록시는 자체 주소를 가진 Via 헤더를 추가하여 응답이 통과해야 하는 경로를 표시한다. 프록시는 From 헤더, Call-Id 또는 Cseq의 태그와 같은 메시지에 있는 대화 상자 식별 정보를 변경하지 않는다. 프록시는 또한 SIP 메시지 본문에서 어떤 정보도 변경하지 않는다. 세션 시작 단계에서 사용자 에이전트는 에이전트가 미디어 트래픽을 예상하는 주소를 포함하는 SDP 본체와 SIP 메시지를 교환한다. 세션 개시 단계를 성공적으로 완료한 후 사용자 에이전트는 프록시의 개입 없이 미디어 트래픽을 서로 직접 교환할 수 있다.

SBC는 많은 애플리케이션을 위해 설계되었으며 다양한 목표를 달성하기 위해 운영자와 기업이 사용한다. 동일한 SBC 구현도 그 구성과 사용 사례에 따라 다르게 작용할 수 있다. 따라서 모든 SBC 구현에 적용되는 정확한 SBC 동작을 쉽게 설명할 수 없다. 일반적으로 SBC에 공통적인 특정 특징을 식별할 수 있다. 예를 들어, 대부분의 SBC는 연속 사용자 에이전트로 구현된다. B2BUA는 SIP 트랜잭션을 사용자 에이전트 클라이언트(UAC)를 마주보는 쪽, 클라이언트 역할을 하는 쪽, 서버 역할을 하는 쪽, 사용자 에이전트 서버(UAS)를 마주보는 쪽 등 두 개의 호출 레그로 분할하는 프록시 같은 서버다. 일반적으로 프록시는 활성 트랜잭션과 관련된 국가 정보만 보관하는 반면, B2BUA는 활성 대화(예: 통화)에 대한 주 정보를 보관한다. 즉, 일단 프록시가 SIP 요청을 받으면 일부 주 정보를 저장하게 된다. 예를 들어, 응답을 받은 후와 같이 거래가 끝나면 곧 국가 정보가 삭제될 것이다. B2BUA는 활성 통화에 대한 상태 정보를 유지하고 통화가 종료된 후에만 이 정보를 삭제한다.

SBC가 통화 경로에 포함될 때 SBC는 B2B 역할을 한다.호출자에게 사용자 에이전트 서버 역할을 하는 UA와 호출자에게 사용자 에이전트 클라이언트 역할을 하는 UA. 이런 의미에서 SBC는 실제로 발신자가 발생시킨 통화를 종료하고 통화권자를 향한 새로운 통화를 시작한다. SBC가 보낸 초대 메시지는 더 이상 발신자에 대한 명확한 참조를 포함하지 않는다. SBC가 프록시로 보낸 초대에는 발신자가 아닌 SBC 자체를 가리키는 비아 및 연락처 헤더가 포함된다. 또한 SBC는 Call-Id 및 From 태그에 나열된 대화 상자 식별 정보를 조작하는 경우가 많다. 또한, SBC가 미디어 트래픽을 제어하도록 구성된 경우, SBC는 SDP 본체의 c 및 m 라인에 포함된 미디어 주소 지정 정보도 변경한다. 따라서 모든 SIP 메시지는 SBC를 통과할 뿐만 아니라 모든 오디오 및 비디오 패킷도 통과하게 된다. SBC에 의해 전송된 INVITE가 새로운 대화상자를 설정함에 따라, SBC는 또한 메시지 순서 번호(CSeq)와 Max-Forwards 값을 조작한다. 여기에 나열된 헤더 조작 목록은 SBC가 SIP 메시지에 도입할 수 있는 가능한 변경사항의 일부에 지나지 않는다는 점에 유의한다. 더욱이 일부 SBC는 열거된 조작을 모두 하지 않을 수도 있다. 만약 SBC가 미디어 트래픽을 통제할 것으로 예상되지 않는다면, SDP 본체에서 어떤 것도 변경할 필요가 없을 수도 있다. 일부 SBC는 대화 상자 식별 정보를 변경하지 않으며 다른 SBC는 주소 지정 정보를 변경하지 않을 수도 있다.

SBC는 기업이 방화벽 및 침입 방지 시스템(IPS)과 함께 보호되는 기업 네트워크와의 VoIP 호출을 가능하게 하기 위해 자주 사용된다. VoIP 서비스 제공업체는 SBC를 사용하여 NAT을 사용하는 인터넷 연결을 통해 사설 네트워크에서 VoIP 프로토콜을 사용할 수 있도록 허용하고, 또한 높은 서비스 품질을 유지하는 데 필요한 강력한 보안 조치를 구현한다. 또한 SBC는 애플리케이션 수준 게이트웨이의 기능을 대체한다.[4] 대기업에서는 SBC를 SIP 트렁크와 함께 사용하여 통화 제어를 제공하고, 통화가 LAN/WAN을 통해 라우팅되는 방법에 대한 라우팅/정책 결정을 내릴 수도 있다. 전통적인 회선 교환 전화 네트워크를 통해 통화를 라우팅하는 것이 아니라 기업의 내부 IP 네트워크를 통한 트래픽 라우팅과 관련된 엄청난 비용 절감 효과가 종종 있다.

또한 일부 SBC는 서로 다른 VoIP 신호 프로토콜(예: SIP, H.323, 메가코/MGCP)을 사용하는 두 전화기 사이에 VoIP 통화를 설정할 수 있을 뿐만 아니라 다른 코덱이 사용 중일 때 미디어 스트림의 트랜스코딩을 수행할 수 있다. 또한 대부분의 SBC는 VoIP 트래픽에 방화벽 기능(서비스 보호, 통화 필터링, 대역폭 관리 거부)을 제공한다. 프로토콜 표준화와 헤더 조작도 SBC에 의해 일반적으로 제공되어 서로 다른 벤더와 네트워크 간의 통신이 가능하다.

IP 멀티미디어 서브시스템(IMS) 또는 3GPP(3세대 파트너십 프로젝트) 아키텍처 관점에서 SBC는 신호면의 P-CSCF와 IMS-ALG, 접근면의 미디어 평면의 IMS 액세스 게이트웨이의 통합이다. 상호연결측에서 SBC는 IBCF, 신호면의 IWF, 미디어 평면의 TrGW(Transition Gateway)에 매핑한다.

IMS/TISPAN 아키텍처 관점에서 SBC는 접근측에서 P-CSCF와 C-BGF 기능을 통합하고 피어링측에서는 IBCF, IWF, THIG 및 I-BGF 기능을 통합하는 것이다. 일부 SBC는 "삭제"될 수 있으며, 즉, 신호 기능은 미디어 릴레이 기능이 아닌 별도의 하드웨어 플랫폼에 위치할 수 있다. 즉, P-CSCF는 C-BGF에서 분리되거나 IBCF/IWF는 물리적으로 I-BGF 기능과 분리될 수 있다. H.248 Ia 프로필과 같은 표준 기반 프로토콜은 몇 개의 SBC가 독점 프로토콜을 사용하는 동안, 신호 플랫폼에 의해 미디어 1을 제어하는 데 사용될 수 있다.

논란

유아기에 SBC의 개념은 다음과 같은 이유로 엔드투엔드 시스템과 피어투피어 네트워킹의 지지자들에게 논란이 되었다.

  • SBC는 미디어 경로의 길이(네트워크를 통한 미디어 패킷의 방식)를 상당히 확장할 수 있다. 긴 미디어 경로는 음성 패킷의 지연과 패킷 손실 가능성을 증가시키기 때문에 바람직하지 않다. 두 가지 효과 모두 음성/영상 화질을 악화시킨다. 그러나, 통화 당사자 사이에 방화벽과 같은 통신 장애물이 여러 번 존재하며, 이러한 경우 SBC는 통화자와 통화자 사이의 허용 가능한 경로로 미디어 스트림을 안내하는 효율적인 방법을 제공한다. SBC가 없으면 통화 미디어가 차단될 것이다. 일부 SBC는 통화의 끝이 동일한 하위 네트워크에 있는지, 그리고 미디어가 클라이언트 간에 직접 흐를 수 있도록 하는 매체의 릴리스 제어에 있는지 감지할 수 있는데, 이것은 안티 트롬본화 또는 미디어 릴리스다. 또한, 일부 SBC는 (두 엔드포인트 사이의 다양한 방화벽과 다른 보안 장치로 인해) 다른 어떤 것도 존재할 수 없는 미디어 경로를 만들 수 있다. 마지막으로, 서비스 제공자가 네트워크를 소유하는 특정 VoIP 네트워크 모델의 경우 SBC는 실제로 바로 가기 라우팅 접근법에 의해 미디어 경로를 줄일 수 있다. 예를 들어, 여러 기업에 트렁킹 서비스를 제공하는 서비스 제공업체는 일반적으로 각 기업에 VPN을 할당한다. 종종 SBC를 통해 VPN을 상호 연결하는 옵션을 갖는 것이 바람직하다. VPN 인식 SBC는 모든 트래픽을 코어로 보내는 대신 VPN 네트워크의 가장자리에서 이 기능을 수행할 수 있다.
  • SBC는 통화 끝점 사이의 정보 흐름을 제한하여 엔드투엔드 투명성을 제한할 수 있는 잠재력을 가지고 있다. VoIP 전화기는 SBC에 의해 이해되지 않는 한 새로운 프로토콜 기능을 사용할 수 없을 수 있다. 그러나 SBC는 대개 대다수의 새롭고 예상치 못한 프로토콜 특징에 대처할 수 있다.
  • 암호화된 호출에서 정보 스트림의 일부분은 암호화되지 않고, 그 부분은 SBC의 영향을 받을 수 있지만 SBC가 키를 가지고 있지 않으면 엔드투엔드 암호화를 사용할 수 없을 때도 있다. 그러나 충분한 컴퓨팅 용량으로 무장한 신세대 SBC는 SIP-TLS, IPsec 및/또는 SRTP를 종료함으로써 이 암호화 기능을 네트워크의 다른 요소에서 오프로드할 수 있다. 더욱이, SBC는 특정 프로토콜 "정상화" 또는 "수정"을 수행함으로써 이전에는 불가능했을 때 실제로 통화와 다른 SIP 시나리오가 작동하도록 할 수 있다.
  • 대부분의 경우 VoIP 전화기가 STON, Turn, ICE 또는 UPnP(Universal Plug and Play)와 같은 프로토콜을 지원하는 경우 SBC 없이 원격 또는 호스팅된 NAT Traversal을 수행할 수 있다.

SBC를 둘러싼 대부분의 논쟁은 (소유자에 대한 서비스 중) 호 통제가 두 엔드포인트에만 머물러야 하는지, 아니면 오히려 두 통화 엔드포인트를 연결하는 데 관여하는 다양한 네트워크를 관리하는 조직이 소유한 다른 네트워크 요소와 공유되어야 하는지에 관한 것이다. 예를 들어, 통화 제어는 앨리스와 밥(두 명의 발신자)에게 남아 있거나, 통화 제어는 앨리스와 밥의 VoIP 전화를 연결하는 데 관련된 모든 IP 네트워크의 운영자와 공유되어야 한다. 이 점에 대한 논쟁은 본질적으로 거의 종교에 가까운 활발한 것이었다. 엔드포인트에서만 제한되지 않는 제어를 원했던 사람들은 방화벽과 필터링/스스로틀링과 같은 현대적 네트워크의 다양한 현실에 크게 좌절하기도 했다. 한편, 네트워크 사업자들은 일반적으로 전반적인 네트워크 성능, 상호운용성 및 품질에 대해 우려하고 있으며, 보안성을 확보하고자 한다.

합법적 요격 및 칼레아

SBC는 통신사가 네트워크 세션의 합법적인 가로채기 요청을 집행하는 데 사용할 수 있는 세션 미디어(일반적으로 RTP)와 신호(흔히 SIP) 도청 서비스를 제공할 수 있다. 이러한 서비스의 가로채기 표준은 ATIS, TIA, 케이블랩스, ETSI 등이 제공하고 있다.

역사와 시장

조나단 로젠버그, RFC3261(SIP)과 그 밖의 여러 다른 관련 댓글 요청의 저자에 따르면, Dynamicsoft Aravox와 함께지만 제품 정말 marketshare을 얻지 않은 첫 일하는 SBC을 개발했다.[표창 필요한]. 시스코고 공개적으로 tra다 뉴포트 네트웍스는 런던 증권 거래소의 AIM에 2004년 5월(NNG)에 있는 신규 상장을 하기 처음이었다.1990년부터 헌납하다. Acme Packet은 2006년 10월에 나스닥에 떠서 그 뒤를 이었다. 인수로 필드가 좁아지면서 넥스트톤은 리프포인트와 합병해 넥스트포인트가 됐고, 이후 젠밴드가 2008년 인수한 것이다. 이와 동시에 국경 통제 기능이 다른 에지 장치로 통합되는 「통합형」 SBC가 출현했다. 2009년에 잉게이트 시스템즈 방화벽은 SBC의 VoIP 보안 기능을 인증하는 이정표인 ICSA Labs로부터 인증을 받은 최초의 SBC가 되었다.

VoIP 네트워크의 지속적인 성장은 SBC를 더욱 최첨단으로 밀어내고 용량과 복잡성의 적응을 의무화한다. VoIP 네트워크가 커지고 트래픽 볼륨이 증가하면서 SBC를 통과하는 세션이 늘고 있다. 공급업체들은 이러한 새로운 규모의 요구사항을 다양한 방식으로 해결하고 있다. 일부는 SBC 클러스터 앞에 배치하기 위해 별도의 부하 분산 시스템을 개발했다. 다른 이들은 더 높은 성능의 SBC와 서비스 카드를 사용한 확장성을 제공하는 최신 세대 칩셋을 사용하여 새로운 아키텍처를 개발했다.

참고 항목

참조

  1. ^ Hautakorpi, J.; Camarillo, G.; Penfield, R.; Hawrylyshen, A.; Bhatia, M. (April 2010). Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments. IETF. doi:10.17487/RFC5853. RFC 5853.
  2. ^ WebRTC가 전화 통신을 혁신하는 방법. Blogs.trilogy-lte.com (2014-02-21) 2014-04-11년에 검색됨.
  3. ^ "Understanding Session Border Controllers" (PDF). FRAFOS GmbH.
  4. ^ Sinnreich, Henry; Johnston, Alan B. (2001), Internet Communication Using SIP, Wiley, p. 180, ISBN 978-0-471-77657-4