세션 경계 컨트롤러를 사용한 NAT 트래버설

이 기사에는 여러 가지 문제가 있습니다.이를 개선하거나 토크 페이지에서 이러한 문제를 논의할 수 있도록 도와주시기 바랍니다.(이러한 템플릿 메시지를 제거하는 방법 및 시기에 대해 알아보십시오.) 이 기사는 고아입니다. 다른 기사는 연결되어 있지 않습니다.관련 기사에서 이 페이지에 대한 링크를 소개하십시오. 제안을 보려면 링크 도구를 사용하십시오.(2013년 11월) 이 문서의 주제는 위키백과의 일반적인 저명성 지침을 충족하지 못할 수 있습니다. 주제와 무관한 신뢰할 수 있는 2차 출처를 인용하여 주제의 유명성을 입증하고 단순한 언급을 넘어 상당한 범위를 제공할 수 있도록 도와주시기 바랍니다. 알림을 표시할 수 없는 경우 문서가 병합, 리디렉션 또는 삭제될 수 있습니다.출처 찾기: "세션 경계 컨트롤러를 사용한 NAT 순회" – 뉴스, 신문, 서적, 학자, JSTOR(2013년 11월) (이 템플릿 메시지를 제거하는 방법 및 시기 알아보기) 이 기사는 너무 기술적이어서 대부분의 독자들이 이해하기 어려울 수 있습니다. 기술적인 세부 사항을 삭제하지 않고 전문가가 아닌 사람들이 이해할 수 있도록 개선할 수 있도록 도와주시기 바랍니다.(2013년 11월) (이 템플릿 메시지를 제거하는 방법 및 시기에 대해 알아보십시오.) (이 템플릿 메시지를 제거하는 방법 및 시기에 대해 알아보십시오.)

네트워크 주소 변환기(NAT)는 기업 또는 운영자의 네트워크를 하나 또는 몇 개의 IP 주소 뒤에 숨겨 IPv4 주소 가용성 부족을 해결하는 데 사용됩니다.NAT 뒤에 있는 장치는 공용 인터넷에서 라우팅할 수 없는 개인 IP 주소를 사용합니다.SIP(Session Initiation Protocol)는 VoIP(^[1]Voice over IP) 통신을 위한 사실상의 표준으로 자리매김했습니다.통화를 설정하기 위해 발신자는 자체 IP 주소가 포함된 SIP 메시지를 보냅니다.착신자는 수신된 SIP 메시지에 포함된 IP 주소로 수신된 SIP 메시지로 응답해야 합니다.발신자가 NAT의 지원을 받고 있으며 개인 IP 주소를 사용하는 경우에는 이 기능이 작동하지 않습니다.

SIP 설계에서 가장 큰 실수는 NAT의 존재를 무시한 것일 수 있습니다.이 오류는 IP 주소 공간이 더 빠르게 소진되어 IPv6로 글로벌 업그레이드해야 하고 NAT의 필요성이 없어질 것이라는 IETF 리더십의 믿음에서 비롯되었습니다.SIP 표준은 NAT이 존재하지 않는다는 가정을 전제로 하고 있으며, 이는 실패로 판명되었습니다. SIP는 NAT을 지원하는 대부분의 인터넷 사용자에게 적용되지 않았습니다.동시에 표준화 수명주기가 시장이 똑딱거리는 방식보다 느리다는 것이 명백해졌습니다.SBC(^[2]Session Border Controller)가 탄생하여 표준이 수행하지 못한 작업인 NAT 트래버설을 해결하기 시작했습니다.

사용자 에이전트가 NAT 뒤에 위치한 경우 SDP 부분뿐만 아니라 연락처 및 헤더를 통해 개인 IP 주소를 연락처 주소로 사용합니다.그러면 이 정보는 공용 인터넷에서 이 사용자 에이전트에 연락하려는 모든 사용자에게 유용하지 않습니다.

STUN, TURN 및 ^[3]ICE와 같은 다양한 NAT 트래버설 솔루션이 있습니다.사용할 솔루션은 NAT의 동작과 상담 시나리오에 따라 달라집니다.SBC를 사용하여 NAT 트래버설 문제를 해결할 때 SBC의 가장 일반적인 접근 방식은 사용자 ^[4]에이전트의 공용 인터페이스 역할을 하는 것입니다.이 작업은 사용자 에이전트의 연락처 정보를 SBC의 연락처 정보로 대체하여 수행됩니다.

사용자 등록 및 NAT 트래버설의 SBC 처리

SBC의 공용 인터페이스를 통해 사용자 에이전트에 연결할 수 있도록 SBC는 사용자 에이전트의 등록 정보를 조작합니다.사용자는 REGISTER 요청에 개인 IP 주소를 연락처 정보로 포함합니다.이 주소는 공개적으로 라우팅할 수 없기 때문에 호출이 실패합니다.SBC는 연락처 헤더의 정보를 자체 IP 주소로 바꿉니다.이것은 등록자에게 등록되는 정보입니다.그런 다음 사용자에게 전송되는 통화는 SBC로 전송됩니다.

SBC가 실제로 연결되는 사용자 에이전트를 알 수 있도록 SBC는 사용자 에이전트 등록의 로컬 사본을 보관할 수 있습니다.로컬 복사본에는 NAT에서 SIP 메시지에 할당한 IP 헤더에 포함된 공용 IP 주소뿐만 아니라 개인 IP 주소와 사용자의 SIP URI가 포함됩니다.

또는 SBC는 이 정보를 전달된 SIP 메시지에 저장할 수 있습니다.이것은 여기 그림에 표시되어 있습니다.사용자의 연락처 정보는 특수 형식으로 결합되어 연락처 헤더에 추가 매개 변수로 추가됩니다.연락처 정보에는 사용자의 개인 IP 주소와 SIP URI뿐만 아니라 SIP 메시지의 IP 헤더에 있는 공용 IP 주소도 포함됩니다.레지스트라가 사용자에 대한 요청을 수신하면 레지스트라는 이 정보를 SIP 메시지에 포함하는 전체 연락처 정보를 프록시에 반환합니다.그런 다음 SBC는 SIP 요청에서 이 정보를 검색하고 이 정보를 사용하여 요청을 사용자에게 적절하게 라우트할 수 있습니다.

등록된 연락처 정보에 사용자 에이전트의 연락처 정보를 추가하면 많은 이점이 있습니다.SBC는 로컬 등록 정보를 보관할 필요가 없으므로 이 솔루션은 구현이 간단하고 정보를 보관하기 위한 메모리가 필요하지 않습니다.또한 사용자 에이전트를 대상으로 하는 요청은 사용자 에이전트의 등록 메시지를 처리한 SBC를 통과할 필요가 없습니다.사용자 에이전트에 연결할 수 있는 모든 SBC는 SIP 요청에 포함된 정보를 기반으로 사용자 에이전트로 전송되는 메시지를 올바르게 라우트할 수 있습니다.그러나 이 장점은 일부 경우에만 적용됩니다.사용자 에이전트 앞에서 사용되는 NAT이 사용자 에이전트가 이전에 연결한 IP 주소의 트래픽만 수신하는 경우 사용자 에이전트의 REGISTER 요청을 처리한 SBC만 사용자 에이전트에 연결할 수 있습니다.

다른 옵션은 등록 정보의 로컬 복사본을 유지하는 것입니다. 그러나 SBC의 처리 요구 사항을 증가시킬 수 있습니다.SBC는 로컬 등록 데이터베이스를 관리해야 합니다.SBC는 메모리 요구 사항 외에도 가용성이 높은 경우 이 정보를 백업 시스템에 복제해야 합니다.이렇게 하면 SBC의 처리 요구 사항이 더욱 증가하고 대역폭 소비가 증가합니다.

그러나 등록 정보의 로컬 사본을 보관하는 것도 장점이 있습니다.네트워크 주소 변환기는 사용자 에이전트로부터 메시지를 수신할 때 사용자 에이전트의 개인 IP 주소를 공용 IP 주소로 바인딩합니다.이 바인딩은 바인딩 기간 동안 활성 상태로 유지됩니다.사용자 에이전트가 바인딩 기간보다 긴 기간 동안 메시지를 보내거나 받지 않는 경우 NAT은 바인딩을 삭제하고 사용자 에이전트에 더 이상 외부에서 연결할 수 없습니다.바인딩을 활성 상태로 유지하려면 사용자 에이전트가 정기적으로 바인딩을 새로 고쳐야 합니다.이것은 바인딩 기간보다 짧은 시간 간격으로 REGISTER 요청을 전송함으로써 달성됩니다.REGISTER 메시지는 일반적으로 인증되어야 하기 때문에 높은 빈도로 전송되는 REGISTER 메시지를 처리해야 하는 경우 운영자의 인프라에 높은 성능의 타격을 줄 수 있습니다. SBC는 이 로드를 오프로드하는 데 도움이 됩니다.사용자 에이전트가 첫 번째 REGISTER 요청을 보낼 때 SBC는 REGISTER 요청을 운영자의 등록 서버로 전달합니다.작업자가 등록을 성공적으로 인증하고 수락하면 SBC는 등록 정보의 로컬 사본을 보관합니다.수신되는 각 REGIETER 요청을 운영자의 등록 서버로 전달하는 대신, SBC는 다소 큰 시간 간격(시간 범위)으로만 REGISTER 요청을 등록 서버로 전송합니다.내용 등록 정보를 변경하지 않는 사용자 에이전트로부터 도착한 등록 요청은 SBC 자체에서 응답합니다.또한 로컬 등록이 만료되거나 변경되면 SBC는 등록 서버에 이 사실을 알립니다.

통화 설정 및 NAT 트래버설의 SBC 처리

등록 사례와 유사하게 SBC도 INVITE 및 기타 요청 메시지의 경로에 포함됩니다.NAT 뒤에 있는 사용자 에이전트로부터 INVITE를 수신하면 SBC는 자체 주소를 가진 경유 헤더를 포함하고, 연락처 헤더의 정보를 자체 주소로 바꾸고, SDP 본문의 주소 정보를 자체 주소로 바꿉니다.따라서 모든 SIP 메시지 및 미디어 패킷은 SBC를 통과합니다.

SBC 미디어 패킷 처리 및 NAT 트래버설

SIP를 사용하여 통화를 설정한 후 미디어 패킷, 즉 음성, 비디오 또는 데이터가 교환됩니다. 일반적으로 RTP(Real-time Transport Protocol)를 사용합니다. SIP 메시지의 NAT 통과는 복잡해 보일 수 있지만 미디어가 NAT을 통과할 수 있도록 하는 것이 더 복잡한 작업입니다.초기 문제 설명은 동일합니다.NAT 뒤에 있는 SIP 장치가 IP 주소를 보급하는 경우 NAT 반대편에 있는 피어는 해당 장치로 트래픽을 라우팅할 수 없습니다.SBCs와 함께 제공된 솔루션은 SIP의 작동 방식을 무시합니다.SBC는 SIP SDP 본문에 보급된 IP 주소 및 포트 번호로 미디어를 보내는 대신 사용자 에이전트에 대한 미디어를 에이전트가 자체 미디어를 보낸 위치로 대칭적으로 다시 보냅니다.이러한 대칭 통신은 일반적으로 VoIP가 출시되기 전에 NAT에서 제조한 트래픽 패턴이기 때문에 작동합니다.

이것이 대부분 효과가 있지만 몇 가지 제한이 있다는 것을 알아야 합니다.우선, "대칭 방식"으로 구축된 클라이언트에서만 작동합니다. 즉, 미디어를 보내고 받는 데 동일한 포트를 사용합니다.요즘은 다행히도 대부분의 사용 가능한 장비입니다.

또 다른 눈에 띄는 단점은 "삼각 라우팅"입니다. SBC는 호출자-SBC 및 SBC-콜리 경로를 대칭적으로 만들기 위해 통화에 대한 모든 VoIP 트래픽을 릴레이해야 합니다.그것은 사실 VoIP 운영자에게 상당한 오버헤드입니다.가장 일반적인 코덱인 G.711에서는 릴레이된 호출이 아웃바운드 2개, 인바운드 2개의 87.2 kbit/s 스트림 4개를 사용합니다.

다른 불편한 제한 사항도 발생할 수 있습니다.예를 들어 SIP 장치가 VAD(음성 활동 감지)를 사용하고 처음에 음성 패킷을 보내지 못하는 경우 SBC는 해당 주소를 학습하지 않고 수신 미디어도 전달하지 않습니다.

레퍼런스