Translated ['src/network-services-pentesting/pentesting-voip/basic-voip-

src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md

@@ -4,76 +4,76 @@
 
 ## 기본 정보
 
-SIP (Session Initiation Protocol)는 **신호 및 통화 제어 프로토콜**로, IP 네트워크를 통해 음성, 비디오 및 인스턴트 메시징을 포함한 멀티미디어 세션을 설정, 수정 및 종료하는 데 널리 사용됩니다. **인터넷 엔지니어링 태스크 포스 (IETF)**에 의해 개발된 SIP는 **RFC 3261**에 정의되어 있으며 VoIP 및 통합 커뮤니케이션의 사실상의 표준이 되었습니다.
+SIP (Session Initiation Protocol)은 IP 네트워크 상에서 음성, 비디오, 인스턴트 메시징을 포함한 멀티미디어 세션을 설정, 수정 및 종료하는 데 널리 사용되는 **신호 및 통화 제어 프로토콜**입니다. **Internet Engineering Task Force (IETF)**에서 개발되었으며, SIP는 **RFC 3261**에 정의되어 VoIP 및 통합 커뮤니케이션의 사실상 표준이 되었습니다.
 
-SIP의 주요 기능은 다음과 같습니다:
+SIP의 주요 특징은 다음과 같습니다:
 
-1. **텍스트 기반 프로토콜**: SIP는 텍스트 기반 프로토콜로, 사람이 읽을 수 있고 디버깅이 용이합니다. HTTP와 유사한 요청-응답 모델을 기반으로 하며, 통화 세션을 제어하기 위해 INVITE, ACK, BYE 및 CANCEL과 같은 메서드를 사용합니다.
-2. **확장성 및 유연성**: SIP는 매우 확장 가능하며 소규모 배포뿐만 아니라 대규모 기업 및 통신사 환경에서도 사용할 수 있습니다. 새로운 기능으로 쉽게 확장할 수 있어 다양한 사용 사례와 요구 사항에 적응할 수 있습니다.
-3. **상호 운용성**: SIP의 광범위한 채택과 표준화는 다양한 장치, 애플리케이션 및 서비스 제공업체 간의 더 나은 상호 운용성을 보장하여 다양한 플랫폼 간의 원활한 통신을 촉진합니다.
-4. **모듈식 설계**: SIP는 미디어 전송을 위한 **RTP (Real-time Transport Protocol)** 및 멀티미디어 세션을 설명하기 위한 **SDP (Session Description Protocol)**와 같은 다른 프로토콜과 함께 작동합니다. 이 모듈식 설계는 다양한 미디어 유형 및 코덱과의 호환성을 높이고 유연성을 제공합니다.
-5. **프록시 및 리디렉션 서버**: SIP는 통화 라우팅을 용이하게 하고 통화 포워딩, 통화 전환 및 음성 메일 서비스와 같은 고급 기능을 제공하기 위해 프록시 및 리디렉션 서버를 사용할 수 있습니다.
-6. **프레즌스 및 인스턴트 메시징**: SIP는 음성 및 비디오 통신에 국한되지 않습니다. 또한 프레즌스 및 인스턴트 메시징을 지원하여 다양한 통합 커뮤니케이션 애플리케이션을 가능하게 합니다.
+1. **텍스트 기반 프로토콜**: SIP는 텍스트 기반 프로토콜로 사람이 읽기 쉽고 디버깅하기 용이합니다. HTTP와 유사한 요청-응답 모델을 기반으로 하며, INVITE, ACK, BYE, CANCEL 등의 메서드를 사용해 통화 세션을 제어합니다.
+2. **확장성과 유연성**: SIP는 높은 확장성을 가지며 소규모 배포부터 대규모 엔터프라이즈 및 통신사업자급 환경까지 사용할 수 있습니다. 새로운 기능으로 쉽게 확장할 수 있어 다양한 사용 사례와 요구사항에 적응할 수 있습니다.
+3. **상호운용성**: SIP의 광범위한 채택과 표준화는 다양한 장치, 애플리케이션, 서비스 제공자 간의 더 나은 상호운용성을 보장하여 다양한 플랫폼 간의 원활한 통신을 촉진합니다.
+4. **모듈형 설계**: SIP는 미디어 전송을 위한 **RTP (Real-time Transport Protocol)** 및 멀티미디어 세션을 설명하기 위한 **SDP (Session Description Protocol)** 등 다른 프로토콜과 함께 작동합니다. 이 모듈형 설계는 다양한 미디어 유형과 코덱과의 호환성을 높이고 유연성을 제공합니다.
+5. **프록시 및 리다이렉트 서버**: SIP는 프록시 및 리다이렉트 서버를 사용하여 통화 라우팅을 용이하게 하며, 착신전환, 통화 전달, 음성사서함과 같은 고급 기능을 제공합니다.
+6. **프레즌스 및 인스턴트 메시징**: SIP는 음성 및 비디오 통신에 국한되지 않습니다. 프레즌스 및 인스턴트 메시징을 지원하여 다양한 통합 커뮤니케이션 애플리케이션을 가능하게 합니다.
 
-많은 장점에도 불구하고 SIP는 NAT 트래버설 및 방화벽 문제를 처리할 때 구성 및 관리가 복잡할 수 있습니다. 그러나 그 유연성, 확장성 및 산업 전반에 걸친 광범위한 지원 덕분에 VoIP 및 멀티미디어 통신을 위한 인기 있는 선택이 됩니다.
+많은 장점에도 불구하고, SIP는 NAT 통과 및 방화벽 문제를 다룰 때 특히 구성 및 관리가 복잡할 수 있습니다. 그러나 그 범용성, 확장성 및 업계 전반의 광범위한 지원으로 인해 VoIP 및 멀티미디어 통신에 인기 있는 선택입니다.
 
 ### SIP 메서드
 
 **RFC 3261**에 정의된 핵심 SIP 메서드는 다음과 같습니다:
 
-1. **INVITE**: **새로운 세션(통화)을 시작**하거나 기존 세션을 수정하는 데 사용됩니다. INVITE 메서드는 세션 설명(SDP 사용)을 포함하여 수신자에게 제안된 세션의 세부정보(미디어 유형, 코덱 및 전송 프로토콜 등)를 알립니다.
-2. **ACK**: INVITE 요청에 대한 최종 응답을 **확인하기 위해** 전송됩니다. ACK 메서드는 INVITE 트랜잭션의 신뢰성을 보장하여 종단 간 확인을 제공합니다.
-3. **BYE**: **설정된 세션(통화)을 종료**하는 데 사용됩니다. BYE 메서드는 세션의 어느 한 쪽에서 통신을 종료하고자 할 때 전송됩니다.
-4. **CANCEL**: 세션이 설정되기 전에 **보류 중인 INVITE** 요청을 **취소하기 위해** 전송됩니다. CANCEL 메서드는 발신자가 마음을 바꾸거나 수신자로부터 응답이 없을 경우 INVITE 트랜잭션을 중단할 수 있게 합니다.
-5. **OPTIONS**: SIP 서버 또는 사용자 에이전트의 **기능을 조회하기 위해** 사용됩니다. OPTIONS 메서드는 세션을 실제로 설정하지 않고 지원되는 메서드, 미디어 유형 또는 기타 확장에 대한 정보를 요청하기 위해 전송될 수 있습니다.
-6. **REGISTER**: 사용자 에이전트가 **SIP 등록 서버에 현재 위치를 등록하기 위해** 사용됩니다. REGISTER 메서드는 사용자의 SIP URI와 현재 IP 주소 간의 최신 매핑을 유지하는 데 도움을 주어 통화 라우팅 및 전달을 가능하게 합니다.
+1. **INVITE**: 새 세션(통화)을 **시작하거나** 기존 세션을 수정하는 데 사용됩니다. INVITE 메서드는 제안된 세션의 세부사항(일반적으로 SDP 사용)을 전달하여 수신자에게 미디어 유형, 코덱 및 전송 프로토콜과 같은 정보를 알립니다.
+2. **ACK**: INVITE 요청에 대한 최종 응답의 수신을 **확인**하기 위해 전송됩니다. ACK 메서드는 종단 간 확인을 제공하여 INVITE 트랜잭션의 신뢰성을 보장합니다.
+3. **BYE**: 확립된 세션(통화)을 **종료**하는 데 사용됩니다. BYE 메서드는 세션의 어느 쪽이든 통화를 종료하려는 의사를 표시하기 위해 전송됩니다.
+4. **CANCEL**: 세션이 성립되기 전에 보류 중인 INVITE 요청을 **취소**하기 위해 전송됩니다. CANCEL 메서드는 발신자가 마음을 바꾸거나 수신자로부터 응답이 없는 경우 INVITE 트랜잭션을 중단할 수 있게 합니다.
+5. **OPTIONS**: SIP 서버 또는 사용자 에이전트의 **기능을 질의**하는 데 사용됩니다. OPTIONS 메서드는 실제로 세션을 성립하지 않고도 지원되는 메서드, 미디어 유형 또는 기타 확장에 대한 정보를 요청할 수 있습니다.
+6. **REGISTER**: 사용자 에이전트가 SIP 레지스트라 서버에 **현재 위치를 등록**하는 데 사용됩니다. REGISTER 메서드는 사용자의 SIP URI와 현재 IP 주소 간의 최신 매핑을 유지하여 통화 라우팅 및 전달을 가능하게 합니다.
 
 > [!WARNING]
-> 누군가에게 전화를 걸기 위해서는 **REGISTER**를 사용할 필요가 **없습니다**.\
-> 그러나 **INVITE**를 수행하기 위해 발신자가 먼저 **인증**해야 할 수도 있으며, 그렇지 않으면 **`401 Unauthorized`** 응답을 받을 수 있습니다.
+> Note that to call someone it's **not neccesary to use the REGISTER** for anything.\
+> However, it's possible that in order to perform an **INVITE** the caller needs to **authenticate** first or he will receive a **`401 Unauthorized`** response.
 
-이러한 핵심 메서드 외에도 다른 RFC에서 정의된 **여러 SIP 확장 메서드**가 있습니다:
+이 핵심 메서드들 외에도 RFC 등 다른 문서들에 정의된 **여러 SIP 확장 메서드**가 있습니다:
 
-1. **SUBSCRIBE**: RFC 6665에 정의된 SUBSCRIBE 메서드는 특정 리소스의 상태(예: 사용자의 프레즌스 또는 통화 상태)에 대한 **알림을 요청하기 위해** 사용됩니다.
-2. **NOTIFY**: RFC 6665에 정의된 NOTIFY 메서드는 서버가 **구독된 사용자 에이전트**에게 모니터링된 리소스의 상태 변경에 대해 **알리기 위해** 전송됩니다.
-3. **REFER**: RFC 3515에 정의된 REFER 메서드는 수신자에게 **전환을 수행하거나 제3자를 참조하도록 요청하기 위해** 사용됩니다. 이는 일반적으로 **통화 전환** 시나리오에 사용됩니다.
-4. **MESSAGE**: RFC 3428에 정의된 MESSAGE 메서드는 SIP 사용자 에이전트 간에 **인스턴트 메시지를 전송하기 위해** 사용되며, SIP 프레임워크 내에서 텍스트 기반 통신을 가능하게 합니다.
-5. **UPDATE**: RFC 3311에 정의된 UPDATE 메서드는 **기존 대화의 상태에 영향을 주지 않고 세션을 수정할 수 있게** 합니다. 이는 진행 중인 통화 중에 코덱이나 미디어 유형과 같은 세션 매개변수를 업데이트하는 데 유용합니다.
-6. **PUBLISH**: RFC 3903에 정의된 PUBLISH 메서드는 사용자 에이전트가 **이벤트 상태 정보를 서버에 게시하여** 다른 관심 있는 당사자에게 제공할 수 있도록 합니다.
+1. **SUBSCRIBE**: RFC 6665에 정의된 SUBSCRIBE 메서드는 사용자의 프레즌스나 통화 상태와 같은 특정 리소스의 상태에 대한 **알림을 요청**하는 데 사용됩니다.
+2. **NOTIFY**: 역시 RFC 6665에 정의된 NOTIFY 메서드는 서버가 **구독한 사용자 에이전트에게** 모니터링 중인 리소스 상태의 변경을 통지하기 위해 전송합니다.
+3. **REFER**: RFC 3515에 정의된 REFER 메서드는 수신자에게 **전달을 수행하거나 제3자를 참조하도록 요청**하는 데 사용됩니다. 주로 통화 전달 시나리오에서 사용됩니다.
+4. **MESSAGE**: RFC 3428에 정의된 MESSAGE 메서드는 SIP 사용자 에이전트 간에 **인스턴트 메시지를 전송**하는 데 사용되어 SIP 프레임워크 내에서 텍스트 기반 통신을 가능하게 합니다.
+5. **UPDATE**: RFC 3311에 정의된 UPDATE 메서드는 **기존 대화의 상태에 영향을 주지 않고 세션을 수정**할 수 있게 합니다. 이는 진행 중인 통화 중에 코덱이나 미디어 유형과 같은 세션 매개변수를 업데이트하는 데 유용합니다.
+6. **PUBLISH**: RFC 3903에 정의된 PUBLISH 메서드는 사용자 에이전트가 서버에 **이벤트 상태 정보를 게시**하여 다른 관심 있는 당사자들이 이용할 수 있게 합니다.
 
 ### SIP 응답 코드
 
-- **1xx (임시 응답)**: 이러한 응답은 요청이 수신되었으며 서버가 계속 처리 중임을 나타냅니다.
+- **1xx (임시 응답)**: 이러한 응답은 요청이 수신되었고 서버가 계속 처리 중임을 나타냅니다.
 - 100 Trying: 요청이 수신되었으며 서버가 작업 중입니다.
-- 180 Ringing: 수신자가 알림을 받고 있으며 전화를 받을 것입니다.
-- 183 Session Progress: 통화 진행 상황에 대한 정보를 제공합니다.
-- **2xx (성공적인 응답)**: 이러한 응답은 요청이 성공적으로 수신, 이해 및 수락되었음을 나타냅니다.
-- 200 OK: 요청이 성공적이며 서버가 이를 이행했습니다.
-- 202 Accepted: 요청이 처리 중으로 수락되었지만 아직 완료되지 않았습니다.
-- **3xx (리디렉션 응답)**: 이러한 응답은 요청을 이행하기 위해 추가 조치가 필요함을 나타내며, 일반적으로 대체 리소스에 연락해야 합니다.
-- 300 Multiple Choices: 여러 옵션이 있으며 사용자가 하나를 선택해야 합니다.
-- 301 Moved Permanently: 요청된 리소스에 새 영구 URI가 할당되었습니다.
-- 302 Moved Temporarily: 요청된 리소스가 다른 URI에서 일시적으로 사용 가능합니다.
+- 180 Ringing: 피호출자에게 알림이 가고 있으며 통화를 받을 준비를 하고 있습니다.
+- 183 Session Progress: 통화의 진행 상황에 대한 정보를 제공합니다.
+- **2xx (성공 응답)**: 이러한 응답은 요청이 성공적으로 수신, 이해 및 수락되었음을 나타냅니다.
+- 200 OK: 요청이 성공적으로 처리되었습니다.
+- 202 Accepted: 요청이 처리용으로 수락되었지만 아직 완료되지는 않았습니다.
+- **3xx (리다이렉션 응답)**: 이러한 응답은 요청을 완료하기 위해 추가 조치가 필요함을 나타내며, 일반적으로 다른 리소스에 연락해야 함을 의미합니다.
+- 300 Multiple Choices: 사용 가능한 여러 옵션이 있으며 사용자나 클라이언트가 하나를 선택해야 합니다.
+- 301 Moved Permanently: 요청된 리소스가 새로운 영구 URI로 할당되었습니다.
+- 302 Moved Temporarily: 요청된 리소스가 임시로 다른 URI에서 사용 가능합니다.
 - 305 Use Proxy: 요청은 지정된 프록시로 전송되어야 합니다.
-- **4xx (클라이언트 오류 응답)**: 이러한 응답은 요청에 잘못된 구문이 포함되어 있거나 서버가 이를 이행할 수 없음을 나타냅니다.
+- **4xx (클라이언트 오류 응답)**: 이러한 응답은 요청에 잘못된 구문이 포함되었거나 서버가 요청을 이행할 수 없음을 나타냅니다.
 - 400 Bad Request: 요청이 잘못되었거나 유효하지 않습니다.
 - 401 Unauthorized: 요청에 사용자 인증이 필요합니다.
-- 403 Forbidden: 서버가 요청을 이해했지만 이행을 거부합니다.
-- 404 Not Found: 요청된 리소스가 서버에서 발견되지 않았습니다.
-- 408 Request Timeout: 서버가 준비된 대기 시간 내에 완전한 요청을 수신하지 못했습니다.
-- 486 Busy Here: 수신자가 현재 통화 중이며 전화를 받을 수 없습니다.
+- 403 Forbidden: 서버는 요청을 이해했지만 이를 이행하기를 거부합니다.
+- 404 Not Found: 요청된 리소스를 서버에서 찾을 수 없습니다.
+- 408 Request Timeout: 서버가 기다릴 준비가 된 시간 내에 완전한 요청을 수신하지 못했습니다.
+- 486 Busy Here: 피호출자가 현재 바빠서 전화를 받을 수 없습니다.
 - **5xx (서버 오류 응답)**: 이러한 응답은 서버가 유효한 요청을 이행하지 못했음을 나타냅니다.
 - 500 Internal Server Error: 서버가 요청을 처리하는 동안 오류가 발생했습니다.
 - 501 Not Implemented: 서버가 요청을 이행하는 데 필요한 기능을 지원하지 않습니다.
-- 503 Service Unavailable: 서버가 현재 유지 관리 또는 과부하로 인해 요청을 처리할 수 없습니다.
-- **6xx (전역 실패 응답)**: 이러한 응답은 요청이 어떤 서버에 의해서도 이행될 수 없음을 나타냅니다.
-- 600 Busy Everywhere: 통화를 위한 모든 가능한 목적지가 바쁩니다.
-- 603 Decline: 수신자가 통화에 참여하고 싶지 않습니다.
-- 604 Does Not Exist Anywhere: 요청된 리소스가 네트워크 어디에서도 사용할 수 없습니다.
+- 503 Service Unavailable: 서버가 유지보수나 과부하로 인해 현재 요청을 처리할 수 없습니다.
+- **6xx (전역 실패 응답)**: 이러한 응답은 네트워크의 어떤 서버도 요청을 이행할 수 없음을 나타냅니다.
+- 600 Busy Everywhere: 통화를 위한 가능한 모든 목적지가 바쁩니다.
+- 603 Decline: 피호출자가 통화에 참여하고 싶어하지 않습니다.
+- 604 Does Not Exist Anywhere: 요청된 리소스가 네트워크 어디에도 존재하지 않습니다.
 
-## 예시
+## 예제
 
-### SIP INVITE 예시
+### SIP INVITE 예제
 ```
 INVITE sip:jdoe@example.com SIP/2.0
 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds
@@ -94,43 +94,43 @@ s=-
 c=IN IP4 pc33.example.com
 t=0 0
 m=audio 49170 RTP/AVP 0
-a=rtpmap:0 PCMU/8000te
+a=rtpmap:0 PCMU/8000
 ```
 <details>
 
-<summary>각 매개변수 설명</summary>
+<summary>각 파라미터 설명</summary>
 
-1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - 이 줄은 메서드(INVITE), 요청 URI(sip:[jdoe@example.com](mailto:jdoe@example.com)), 및 SIP 버전(SIP/2.0)을 나타냅니다.
-2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - Via 헤더는 전송 프로토콜(UDP)과 클라이언트의 주소(pc33.example.com)를 지정합니다. "branch" 매개변수는 루프 감지 및 트랜잭션 일치를 위해 사용됩니다.
-3. **Max-Forwards**: `Max-Forwards: 70` - 이 헤더 필드는 요청이 프록시를 통해 전달될 수 있는 횟수를 제한하여 무한 루프를 방지합니다.
-4. **To**: `To: John Doe <sip:jdoe@example.com>` - To 헤더는 통화의 수신자를 지정하며, 표시 이름(John Doe)과 SIP URI(sip:[jdoe@example.com](mailto:jdoe@example.com))을 포함합니다.
-5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - From 헤더는 통화의 발신자를 지정하며, 표시 이름(Jane Smith)과 SIP URI(sip:[jsmith@example.org](mailto:jsmith@example.org))을 포함합니다. "tag" 매개변수는 대화에서 발신자의 역할을 고유하게 식별하는 데 사용됩니다.
+1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - 이 줄은 메서드(INVITE), 요청 URI (sip:jdoe@example.com) 및 SIP 버전(SIP/2.0)을 나타냅니다.
+2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - Via 헤더는 전송 프로토콜(UDP)과 클라이언트 주소(pc33.example.com)를 지정합니다. "branch" 매개변수는 루프 감지 및 트랜잭션 매칭에 사용됩니다.
+3. **Max-Forwards**: `Max-Forwards: 70` - 이 헤더 필드는 프록시가 요청을 전달할 수 있는 횟수를 제한하여 무한 루프를 방지합니다.
+4. **To**: `To: John Doe <sip:jdoe@example.com>` - To 헤더는 수신자(표시 이름 John Doe 및 SIP URI sip:jdoe@example.com)를 지정합니다.
+5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - From 헤더는 발신자(표시 이름 Jane Smith 및 SIP URI sip:jsmith@example.org)를 지정합니다. "tag" 매개변수는 다이얼로그에서 발신자의 역할을 고유하게 식별하는 데 사용됩니다.
 6. **Call-ID**: `Call-ID: a84b4c76e66710` - Call-ID 헤더는 두 사용자 에이전트 간의 통화 세션을 고유하게 식별합니다.
-7. **CSeq**: `CSeq: 314159 INVITE` - CSeq 헤더는 시퀀스 번호와 요청에 사용된 메서드를 포함합니다. 이는 응답을 요청과 일치시키고 순서가 뒤바뀐 메시지를 감지하는 데 사용됩니다.
-8. **Contact**: `Contact: <sip:jsmith@pc33.example.com>` - Contact 헤더는 발신자에게 직접 연결할 수 있는 경로를 제공하며, 이는 후속 요청 및 응답에 사용될 수 있습니다.
-9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - User-Agent 헤더는 발신자의 소프트웨어 또는 하드웨어에 대한 정보를 제공하며, 이름과 버전을 포함합니다.
-10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - Allow 헤더는 발신자가 지원하는 SIP 메서드를 나열합니다. 이는 수신자가 통신 중 사용할 수 있는 메서드를 이해하는 데 도움이 됩니다.
-11. **Content-Type**: `Content-Type: application/sdp` - Content-Type 헤더는 메시지 본문의 미디어 유형을 지정하며, 이 경우 SDP(세션 설명 프로토콜)입니다.
-12. **Content-Length**: `Content-Length: 142` - Content-Length 헤더는 메시지 본문의 크기를 바이트 단위로 나타냅니다.
-13. **Message Body**: 메시지 본문에는 미디어 유형, 코덱 및 제안된 세션의 전송 프로토콜에 대한 정보가 포함된 SDP 세션 설명이 포함됩니다.
+7. **CSeq**: `CSeq: 314159 INVITE` - CSeq 헤더는 시퀀스 번호와 요청에 사용된 메서드를 포함합니다. 이는 응답을 요청에 매칭하고 메시지의 순서가 어긋났는지 감지하는 데 사용됩니다.
+8. **Contact**: `Contact: <sip:jsmith@pc33.example.com>` - Contact 헤더는 발신자에 대한 직접 경로를 제공하며 이후의 요청과 응답에 사용할 수 있습니다.
+9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - User-Agent 헤더는 발신자의 소프트웨어 또는 하드웨어에 대한 정보(이름 및 버전)를 제공합니다.
+10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - Allow 헤더는 발신자가 지원하는 SIP 메서드 목록을 제공합니다. 이는 수신자가 통신 중 사용할 수 있는 메서드를 이해하는 데 도움을 줍니다.
+11. **Content-Type**: `Content-Type: application/sdp` - Content-Type 헤더는 메시지 본문의 미디어 유형을 지정하며, 이 경우 SDP(Session Description Protocol)입니다.
+12. **Content-Length**: `Content-Length: 142` - Content-Length 헤더는 메시지 본문의 바이트 크기를 표시합니다.
+13. **Message Body**: The message body contains the SDP session description, which includes information about the media types, codecs, and transport protocols for the proposed session.
 
-- `v=0` - 프로토콜 버전 (SDP의 경우 0)
-- `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - 생성자 및 세션 식별자
-- `s=-` - 세션 이름 (단일 하이픈은 세션 이름이 없음을 나타냅니다)
-- `c=IN IP4 pc33.example.com` - 연결 정보 (네트워크 유형, 주소 유형 및 주소)
-- `t=0 0` - 타이밍 정보 (시작 및 종료 시간, 0 0은 세션이 제한되지 않음을 의미합니다)
-- `m=audio 49170 RTP/AVP 0` - 미디어 설명 (미디어 유형, 포트 번호, 전송 프로토콜 및 형식 목록). 이 경우 RTP/AVP(실시간 전송 프로토콜 / 오디오 비디오 프로파일)를 사용하는 오디오 스트림과 형식 0(PCMU/8000)을 지정합니다.
-- `a=rtpmap:0 PCMU/8000` - 형식(0)을 코덱(PCMU) 및 클럭 속도(8000 Hz)에 매핑하는 속성입니다.
+- `v=0` - Protocol version (0 for SDP)
+- `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - Originator and session identifier
+- `s=-` - Session name (a single hyphen indicates no session name)
+- `c=IN IP4 pc33.example.com` - Connection information (network type, address type, and address)
+- `t=0 0` - Timing information (start and stop times, 0 0 means the session is not bounded)
+- `m=audio 49170 RTP/AVP 0` - Media description (media type, port number, transport protocol, and format list). In this case, it specifies an audio stream using RTP/AVP (Real-time Transport Protocol / Audio Video Profile) and format 0 (PCMU/8000).
+- `a=rtpmap:0 PCMU/8000` - Attribute mapping the format (0) to the codec (PCMU) and its clock rate (8000 Hz).
 
 </details>
 
 ### SIP REGISTER 예제
 
-REGISTER 메서드는 세션 시작 프로토콜(SIP)에서 사용자 에이전트(UA), 예를 들어 VoIP 전화기나 소프트폰이 **SIP 등록 서버에 자신의 위치를 등록할 수 있도록** 사용됩니다. 이 과정은 서버가 **등록된 사용자에게 도착하는 SIP 요청을 어디로 라우팅해야 하는지 알 수 있게 해줍니다**. 등록 서버는 일반적으로 SIP 프록시 서버 또는 전용 등록 서버의 일부입니다.
+The REGISTER method is used in Session Initiation Protocol (SIP) to allow a user agent (UA), such as a VoIP phone or a softphone, to **register its location with a SIP registrar server**. This process lets the server know **where to route incoming SIP requests destined for the registered user**. The registrar server is usually part of a SIP proxy server or a dedicated registration server.
 
-다음은 REGISTER 인증 프로세스에 관련된 SIP 메시지의 자세한 예입니다:
+Here's a detailed example of the SIP messages involved in a REGISTER authentication process:
 
-1. UA에서 등록 서버로의 초기 **REGISTER** 요청:
+1. Initial **REGISTER** request from UA to the registrar server:
 ```yaml
 REGISTER sip:example.com SIP/2.0
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
@@ -143,11 +143,11 @@ Contact: <sip:alice@192.168.1.100:5060>;expires=3600
 Expires: 3600
 Content-Length: 0
 ```
-이 초기 REGISTER 메시지는 UA(앨리스)가 등록 서버에 전송합니다. 여기에는 원하는 등록 기간(Expires), 사용자의 SIP URI (sip:[alice@example.com](mailto:alice@example.com)), 및 사용자의 연락처 주소(sip:alice@192.168.1.100:5060)와 같은 중요한 정보가 포함됩니다.
+이 초기 REGISTER 메시지는 UA (Alice)가 레지스트라 서버로 전송합니다. 이 메시지에는 원하는 등록 기간 (Expires), 사용자의 SIP URI (sip:[alice@example.com](mailto:alice@example.com)), 그리고 사용자의 연락처 주소 (sip:alice@192.168.1.100:5060)와 같은 중요한 정보가 포함되어 있습니다.
 
-2. **401 Unauthorized** 등록 서버의 응답:
-```css
-cssCopy codeSIP/2.0 401 Unauthorized
+2. 레지스트라 서버로부터의 **401 Unauthorized** 응답:
+```
+SIP/2.0 401 Unauthorized
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
 From: Alice <sip:alice@example.com>;tag=565656
 To: Alice <sip:alice@example.com>;tag=7878744
@@ -156,9 +156,9 @@ CSeq: 1 REGISTER
 WWW-Authenticate: Digest realm="example.com", nonce="abcdefghijk", algorithm=MD5, qop="auth"
 Content-Length: 0
 ```
-레지스트라 서버는 "401 Unauthorized" 메시지로 응답하며, 여기에는 "WWW-Authenticate" 헤더가 포함됩니다. 이 헤더에는 UA가 자신을 인증하는 데 필요한 정보가 포함되어 있습니다. 예를 들어 **인증 영역, nonce 및 알고리즘**이 있습니다.
+레지스트라 서버는 "401 Unauthorized" 응답을 반환하며, 이 응답에는 "WWW-Authenticate" 헤더가 포함됩니다. 이 헤더는 UA가 자신을 인증하는 데 필요한 정보를 포함하며, 예를 들어 **authentication realm, nonce, and algorithm** 등이 있습니다.
 
-3. 인증 자격 증명 **이 포함된 REGISTER 요청**:
+3. REGISTER 요청 **with authentication credentials**:
 ```vbnet
 REGISTER sip:example.com SIP/2.0
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
@@ -172,9 +172,9 @@ Expires: 3600
 Authorization: Digest username="alice", realm="example.com", nonce="abcdefghijk", uri="sip:example.com", response="65a8e2285879283831b664bd8b7f14d4", algorithm=MD5, cnonce="lmnopqrst", qop=auth, nc=00000001
 Content-Length: 0
 ```
-UA는 또 다른 REGISTER 요청을 보내며, 이번에는 **필요한 자격 증명(예: 사용자 이름, 영역, nonce 및 제공된 정보와 사용자의 비밀번호를 사용하여 계산된 응답 값)**이 포함된 **"Authorization" 헤더**를 포함합니다.
+UA는 또 다른 REGISTER 요청을 보냅니다. 이번에는 제공된 정보와 사용자의 비밀번호를 사용해 계산된 **사용자 이름(username), realm, nonce 및 응답값(response value)과 같은 필요한 자격 증명을 포함한 "Authorization" header**를 포함합니다.
 
-이것이 **Authorization 응답**이 계산되는 방법입니다:
+다음은 **Authorization response**가 계산되는 방법입니다:
 ```python
 import hashlib
 
@@ -207,7 +207,7 @@ qop = "auth"
 response = calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop)
 print(f"MD5 response value: {response}")
 ```
-4. **성공적인 등록** 응답은 등록 서버에서:
+4. **성공적인 등록** 응답 (레지스트라 서버로부터):
 ```yaml
 SIP/2.0 200 OK
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
@@ -219,13 +219,98 @@ Contact: <sip:alice@192.168.1.100:5060>;expires=3600
 Expires: 3600
 Content-Length: 0
 ```
-등록 서버가 제공된 자격 증명을 확인한 후, **등록이 성공했음을 나타내기 위해 "200 OK" 응답을 보냅니다**. 응답에는 등록된 연락처 정보와 등록 만료 시간이 포함됩니다. 이 시점에서 사용자 에이전트(앨리스)는 SIP 등록 서버에 성공적으로 등록되었으며, 앨리스를 위한 수신 SIP 요청은 적절한 연락처 주소로 라우팅될 수 있습니다.
+등록 서버가 제공된 자격 증명을 확인한 후, **등록이 성공했음을 알리기 위해 "200 OK" 응답을 전송합니다**. 응답에는 등록된 contact 정보와 등록의 만료 시간이 포함됩니다. 이 시점에서 user agent (Alice)는 SIP registrar server에 성공적으로 등록되며, Alice로 향하는 들어오는 SIP 요청은 적절한 contact 주소로 라우팅될 수 있습니다.
 
-### 통화 예시
+### Call Example
 
 <figure><img src="../../../images/image (1101).png" alt=""><figcaption></figcaption></figure>
 
-> [!NOTE]
-> 언급되지는 않았지만, 사용자 B는 전화를 받을 수 있기 전에 **Proxy 2에 REGISTER 메시지를 전송해야 합니다**.
+> [!TIP]
+> 언급되지는 않았지만, User B는 전화를 받을 수 있기 전에 **REGISTER message to Proxy 2** 를 보냈어야 합니다.
 
+
+
+---
+
+## SIP Security and Pentesting Notes
+
+이 섹션은 더 광범위한 VoIP 가이드라인을 중복하지 않으면서 실용적이고 프로토콜에 특화된 팁을 추가합니다. 종단간 VoIP 공격 방법론, 도구 및 시나리오에 대해서는 다음을 참조하십시오:
+
+{{#ref}}
+../README.md
+{{#endref}}
+
+### Fingerprinting and Discovery
+
+- OPTIONS 요청을 전송하고 `Allow`, `Supported`, `Server` 및 `User-Agent` 헤더를 검토하여 장치와 스택을 fingerprint 합니다:
+
+```bash
+# nmap NSE (UDP 5060 by default)
+sudo nmap -sU -p 5060 --script sip-methods <target>
+
+# Minimal raw OPTIONS over UDP
+printf "OPTIONS sip:<target> SIP/2.0\r\nVia: SIP/2.0/UDP attacker;branch=z9\r\nFrom: <sip:probe@attacker>;tag=1\r\nTo: <sip:probe@<target>>\r\nCall-ID: 1@attacker\r\nCSeq: 1 OPTIONS\r\nMax-Forwards: 70\r\nContact: <sip:probe@attacker>\r\nContent-Length: 0\r\n\r\n" | nc -u -w 2 <target> 5060
+```
+
+### Username/Extension Enumeration Behavior
+
+- 열거는 일반적으로 `REGISTER`/`INVITE`에서 `401/407` 대 `404/403`의 차이를 악용합니다. 서버가 균일하게 응답하도록 하여 노출을 방지하세요.
+- Asterisk chan_sip: 일반 설정으로 `alwaysauthreject=yes` 를 설정하여 유효한 사용자를 노출하지 않도록 하세요. 최신 Asterisk(PJSIP)에서는 `anonymous` endpoint가 정의되지 않는 한 guest calling이 비활성화되어 있고 유사한 "always auth reject" 동작이 기본이지만, 여전히 네트워크 ACL과 perimeter에서의 fail2ban 적용을 강제하세요.
+
+### SIP Digest Authentication: algorithms and cracking
+
+- SIP는 일반적으로 HTTP-Digest 스타일 인증을 사용합니다. 역사적으로 MD5(및 MD5-sess)가 널리 사용되었고; 최신 스택은 RFC 8760에 따라 SHA-256 및 SHA-512/256을 지원합니다. 최신 배포에서는 이러한 더 강력한 알고리즘을 우선 사용하고 가능한 경우 MD5를 비활성화하세요.
+- pcap에서의 오프라인 크래킹은 MD5 다이제스트에 대해 매우 쉽습니다. challenge/response를 추출한 후 hashcat 모드 11400 (SIP digest, MD5)을 사용할 수 있습니다:
+
+```bash
+# Example hash format (single line)
+# username:realm:method:uri:nonce:cnonce:nc:qop:response
+echo 'alice:example.com:REGISTER:sip:example.com:abcdef:11223344:00000001:auth:65a8e2285879283831b664bd8b7f14d4' > sip.hash
+
+# Crack with a wordlist
+hashcat -a 0 -m 11400 sip.hash /path/to/wordlist.txt
+```
+
+> [!NOTE]
+> RFC 8760은 HTTP Digest(또는 SIP Digest)에 대해 SHA-256 및 SHA-512/256을 정의합니다. 채택 상황은 균일하지 않습니다; 최신 PBX를 대상으로 할 때 도구들이 이를 처리하는지 확인하세요.
+
+### SIP over TLS (SIPS) and over WebSockets
+
+- Signaling encryption:
+- `sips:` URI와 TCP/TLS는 일반적으로 포트 5061을 사용합니다. 엔드포인트에서의 인증서 검증을 확인하세요; 많은 장비가 self-signed 또는 wildcard cert를 허용하여 약한 배포에서는 MitM이 가능해집니다.
+- WebRTC softphones는 종종 RFC 7118에 따라 SIP over WebSocket (`ws://` 또는 `wss://`)을 사용합니다. PBX가 WSS를 노출하는 경우 인증 및 CORS를 테스트하고 HTTP 프론트엔드에서도 rate limit이 적용되는지 확인하세요.
+
+### DoS quick checks (protocol level)
+
+- INVITE, REGISTER 또는 malformed 메시지 플러딩은 트랜잭션 처리를 소모시킬 수 있습니다.
+- UDP/5060에 대한 간단한 rate-limiting 예시(Linux iptables hashlimit):
+
+```bash
+# Limit new SIP packets from a single IP to 20/s with burst 40
+iptables -A INPUT -p udp --dport 5060 -m hashlimit \
+--hashlimit-name SIP --hashlimit 20/second --hashlimit-burst 40 \
+--hashlimit-mode srcip -j ACCEPT
+iptables -A INPUT -p udp --dport 5060 -j DROP
+```
+
+### Recent, relevant SIP-stack CVE to watch (Asterisk PJSIP)
+
+- CVE-2024-35190 (published May 17, 2024): 특정 Asterisk 릴리스에서 `res_pjsip_endpoint_identifier_ip`가 무단 SIP 요청을 로컬 엔드포인트로 잘못 식별할 수 있어 무단 동작 또는 정보 노출을 초래할 수 있습니다. 18.23.1, 20.8.1 및 21.3.1에서 수정되었습니다. 테스트 시 PBX 버전을 검증하고 책임감 있게 보고하세요.
+
+### Hardening checklist (SIP-specific)
+
+- 신호(Signaling)는 TLS를 우선 사용하고 미디어에는 SRTP/DTLS-SRTP를 사용하세요; 가능한 경우 평문(cleartext)을 비활성화하세요.
+- 강력한 비밀번호와 다이제스트 알고리즘(SHA-256/512-256 지원 시; MD5는 피함)을 적용하세요.
+- Asterisk의 경우:
+- chan_sip: `alwaysauthreject=yes`, `allowguest=no`, 엔드포인트별 `permit`/`deny` CIDR ACL 설정.
+- PJSIP: 필요하지 않다면 `anonymous` endpoint를 생성하지 마세요; endpoint `acl`/`media_acl`을 강제하고 fail2ban 또는 동등한 것을 활성화하세요.
+- 정보 누출(leak)을 줄이기 위해 SIP 프록시(예: outbound proxy/edge SBC)에서 토폴로지 숨기기(topology hiding)를 적용하세요.
+- 엄격한 `OPTIONS` 처리 및 rate limit; 필요하지 않은 메서드(예: `MESSAGE`, `PUBLISH`)는 비활성화하세요.
+
+
+
+## References
+
+- RFC 8760 – Using SHA-256 and SHA-512/256 for HTTP Digest (applies to SIP Digest too): https://www.rfc-editor.org/rfc/rfc8760
+- Asterisk GHSA advisory for CVE-2024-35190: https://github.com/asterisk/asterisk/security/advisories/GHSA-qqxj-v78h-hrf9
 {{#include ../../../banners/hacktricks-training.md}}