IP 멀티미디어 서브시스템을 위한 SIP 확장

SIP extensions for the IP Multimedia Subsystem

SIP(Session Initiation Protocol)는 3세대 파트너십 프로젝트(3GPP)가 [1][2]IP 멀티미디어 서브시스템(IMS)의 2인 이상의 참가자와 멀티미디어 세션을 생성 및 제어하기 위해 선택한 신호 프로토콜로, 따라서 IMS 프레임워크의 핵심 요소다.

SIP는 IETF(Internet Engineering Task Force)가 Internet Protocol(IP) 네트워크에서 멀티미디어 통신 세션을 제어하기 위한 표준으로 개발한 것으로, Internet Protocol Suite의 애플리케이션 계층에서 작업하고 있다. 몇 개의 SIP 확장이 그것의 기능성을 확장하기 위해 기본 프로토콜 사양에 추가되었다.[3][4][5] 이러한 확장은 IETF에 의한 Request for Comments(RFC) 프로토콜 권장사항에 기초한다.

그 3GPP-통신 협회의 단체와 유지하는 것이 IMS개발을 위한 사이의 공동 작업, SIP[1]에 대한 요구 사항의 시리즈를 성공적으로 IMS에 사용되는 반면, 다른 경우엔, 3GPP과 함께 작업했다 그들 중 몇몇은 SIP에서 기존의 능력과 확장을 사용하여 다룰 수 있다고 말했다. 그 IETF는 새로운 요건을 충족시키기 위해 새로운 SIP 확장을[6] 표준화한다. 어떤 경우든 IETF는 SIP를 일반적 기준으로 진화시켜 IMS 프레임워크에 그 확장자의 사용이 제한되지 않도록 한다.

SIP를 위한 3GPP 요구사항

3GPP는 IMS 작동을 위해 기술된 몇 가지 일반 요건을 명시하였다. 여기에는 이동 단말기와 네트워크 사이의 신호 메시지 교환을 최소화하여 무선 인터페이스의 효율적인 이용, 세션 설정 중 대신 세션 설정 전 작업을 수행하여 최소 세션 설정 시간, 단말기에 필요한 최소 지원, 로밍 및 비루밍 지원 등이 포함된다.터미널 이동성 관리(SIP가 아닌 액세스 네트워크에 의해 지원) 및 IPv6 주소 지정을 지원하는 시나리오.

기타 요구사항에는 사용자 또는 서버 정보를 교환하기 위한 SIP 헤더 필드 및 새로운 네트워크 기능(등록, 재등록, 등록 취소, 이벤트 통지, 인스턴트 메시징 또는 통화 제어의 기본 요소)을 지원하는 SIP 방법과 같은 프로토콜 확장이 포함된다.ce

기타 구체적인 요구사항은 다음과 같다.[1]

  • 대상 사용자에게 경고하기 전에 리소스 협상 및 할당뿐만 아니라 정책 및 충전 제어를 통한 서비스 품질 지원.
  • 인증, 승인 및 회계 목적을 위한 사용자 식별. 사용자와 네트워크, 네트워크 노드 사이의 보안은 미디어 인증 확장은 물론 개인 및 공용 키와 다이제스트 등의 상호 인증 메커니즘을 사용하여 해결해야 할 주요 사안이다. 또한 필요할 경우 이 정보를 숨길 수 있는 능력을 가지고 발신자와 발신자 모두에게 상대방의 신원을 제시할 수 있어야 한다. 세션 설정의 익명성과 사생활 보호도 중요하다.
  • 초기 인증 및 대칭 암호키에 기반한 무결성 및 기밀성 지원으로 SIP 신호의 보호, 오류 복구 및 검증도 필요하다.
  • 네트워크에 의해 개시된 세션 릴리스(예: 사용자 단말기가 커버리지에서 이탈하거나 신용이 고갈된 경우).
  • 소스 라우팅 메커니즘. SIP 메시지 라우팅은 IMS에서 자체 요건이 있다. 모든 단말 발생 세션 설정 시도는 이러한 호출 세션 제어 기능(CSCF) 서버가 서비스를 적절하게 제공할 수 있도록 P-CSCF와 S-CSCF를 모두 통과해야 하기 때문이다. 특정 메시지에 대한 특별한 경로 요구사항도 있을 수 있다.
  • IMS와 공중 교환 전화 네트워크(PSTN) 간의 상호 작용.

마지막으로, 각각 아웃바운드 프록시(P-CSCF) 위치와 IP 주소 확인에 대한 SIP 균일 리소스 식별자(URI)와 같은 다른 프로토콜과 네트워크[7] 서비스도 SIP와 함께 작동하도록 적응해야 한다.

연장 협상 메커니즘

SIP에는 사용자 에이전트(UA) 또는 서버 간의 확장[2] 협상을 위한 메커니즘이 있으며, UA 또는 서버(즉, IMS의 사용자 터미널 또는 호출 세션 제어 기능(CSCF))가 이해한 확장을 지정하기 위해 사용할 수 있는 3가지 헤더 필드로 구성된다. 클라이언트가 서버와 SIP 대화상자를 시작할 때, 그것은 사용하는 데 필요한 확장자 및 이해되는 다른 확장자(지원되는)도 명시하고, 그러면 서버는 필요한 확장자 목록이 포함된 응답을 전송한다. 이러한 확장자가 클라이언트의 메시지에 나열되지 않은 경우, 서버의 응답은 오류 응답일 것이다. 마찬가지로, 서버가 클라이언트의 필수 확장자 중 어떤 것도 지원하지 않는 확장자 목록이 있는 오류 응답을 보낼 것이다. 이런 종류의 확장을 옵션 태그라고 하지만 SIP는 새로운 방법으로도 확장할 수 있다. 이 경우 사용자 에이전트 또는 서버는 허용 헤더를 사용하여 지원하는 방법을 명시한다. 특정 대화 상자에서 특정 방법을 사용하도록 요구하려면 해당 방법과 관련된 옵션 태그를 사용해야 한다.

SIP 확장

호출자 기본 설정 및 사용자 에이전트 기능

이 두 확장자를 통해 사용자는 IMS가 제공하는 서비스에 대한 선호도를 지정할 수 있다.

발신자 선호 확장 기능을 통해,[8] 통화 당사자는 도달하고자 하는 사용자 에이전트의 종류(예: 고정 또는 모바일, 음성 메일 또는 인적, 개인 또는 업무용, 제공할 수 있는 서비스 또는 지원 방법)와 검색 방법을 다음과 같은 세 가지 헤더 필드로 표시할 수 있다. Accept-Contact 원하는 대상 사용자 에이전트를 설명하는 Contact, 피할 사용자 에이전트를 명시하는 Reject-Contact, 네트워크의 서버에서 요청을 처리하는 방법(즉, 리디렉션할지 여부와 사용자를 검색하는 방법: 순차적 또는 병렬적으로)을 지정하는 Request-Disposition.

사용자 에이전트 기능 확장을 사용하면 사용자 에이전트(단말기)가 등록 시 자신을 설명하여 다른 사용자가 발신자 기본 설정 확장 헤더에 따라 검색할 수 있다.[9] 이러한 목적을 위해, 그들은 RERGER 메시지의 Contact 헤더 필드에 그들의 능력을 나열한다.

이벤트 알림

이벤트 알림의 목적은 지정된 리소스(예: 사용자, 음성 메일 서비스)의 상태를 확인하고 변경 시 해당 상태의 업데이트를 받는 것이다.

이벤트 통지는 IMS 프레임워크에서 연락을 대기하고 있는 다른 사람에게 사용자의 존재(즉, "온라인" 또는 "오프라인")를 알리거나 사용자와 자신의 P-CSCF에게 자신의 등록 상태를 통지하여 그들이 도달할 수 있는지 여부와 등록한 공공 ID를 알 수 있도록 하기 위해 필요하다. 더욱이, 이벤트 통지는 음성 메일과 같은 추가 서비스를 제공하는 데 사용될 수 있다(즉, 수신함에 새로운 음성 메시지가 있음을 통지하는 데 사용된다).

이를 위해 특정 이벤트 알림 확장은[10] SIP에서 이벤트 알림에 대한 프레임워크를 정의하는데, SIP에서 Subscribe과 NOTINT, 새로운 헤더 필드와 응답 코드, 그리고 가입자와 알림자의 두 가지 역할의 두 가지 새로운 방법이 있다. 자원(가입자)의 상태 정보에 관심이 있는 기업은 요청 초기 줄에 있는 자원의 통일된 자원 식별자(URI)와 이벤트 헤더에 있는 이벤트 유형을 사용하여 Subscribe 메시지를 전송한다. 그런 다음, 자원 상태(통지자)를 추적하고, Subscription 요청을 받아, 메시지 본문에 있는 자원의 상태에 대한 정보뿐만 아니라 가입 상태 헤더가 있는 NOTINT 메시지를 다시 전송한다. 리소스 상태가 변경될 때마다 알림자는 가입자에게 새 NOTIFY 메시지를 전송한다. 가입자가 가입할 수 있는 각 종류의 이벤트는 새로운 이벤트 패키지에 정의된다. 이벤트 패키지는 Subscribe Event 헤더에 대한 새로운 값과 NOTINT 메시지에서 이벤트 상태 정보를 전달하는 MIME 유형을 설명한다.

이벤트 알림 기능을 나타내는 허용 이벤트 헤더도 있으며, 202가 승인되었고 489개의 불량 이벤트 응답 코드가 승인되었으며, 알림자가 요청된 이벤트의 종류를 이해하지 못해 가입 요청이 사전 승인되었는지 또는 거부되었는지 여부를 표시하기 위한 것이다.

신호 메시지를 효율적으로 활용하기 위해 이벤트 조절이라는 메커니즘을 통해 제한된 알림률(실시간 알림은 아님)을 설정하는 것도 가능하다. 더욱이 지난 가입 이후 새롭게 알릴 것이 있는지 없는지에 따라 통지자가 완전한 NOTIFY 메시지를 보낼지 말지를 결정할 수 있는 조건부 이벤트 알림 메커니즘도 있다.

주정부출판

이벤트 알림 프레임워크는 사용자 에이전트가 리소스 상태에 대한 이벤트를 구독할 수 있는 방법을 정의하지만, 해당 상태를 게시할 수 있는 방법은 명시하지 않는다. 이벤트 상태 게시를[11] 위한 SIP 확장은 사용자 에이전트가 이벤트 상태를 구성하여 가입자에게 배포할 책임이 있는 기업(통보자)에게 이벤트 상태를 게시할 수 있도록 정의되었다.

주정부 간행물 프레임워크는 새로운 방법인 PLOSE를 정의하는데, 이는 이벤트 헤더에 명시된 이벤트와 메시지 본문에 전달된 정보를 참조하여 요청-URI에 명시된 자원의 상태 발행을 요청하기 위해 사용된다.

인스턴트 메시징

문자 메시징과 유사한 서비스를 제공하기 위해 인스턴트 메시지를 보내는 기능은 인스턴트 메시징 확장자에 정의되어 있다.[12] 이러한 메시지는 서로 관련이 없으며(즉, SIP 대화 상자의 기원은 되지 않는다) SIP 신호 네트워크를 통해 송신되어 제어 메시지와 자원을 공유한다.

이 기능은 요청-URI에 명시된 자원으로 즉석 메시지를 전송하는 데 사용할 수 있는 새로운 MEASS 방법에 의해 지원되며, 메시지 본문에 전달되는 콘텐츠가 있다. 이 콘텐츠는 MIME 유형으로 정의되며, 텍스트/플래인이 가장 일반적이다.

관련 메시지가 포함된 인스턴트 메시징 세션을 가지려면 메시지 세션 릴레이 프로토콜(MSRP)[13]을 사용해야 한다.

통화이체

REFE 방법[14] 확장자는 요청 메시지의 참조 헤더 필드에서 URI로 식별되는 리소스에 대한 사용자 에이전트의 연결을 요청하는 메커니즘을 정의한다. 이 메커니즘의 일반적인 용도는 통화 중에 참조 메시지를 보내는 참가자가 해당 헤더 필드에서 URI에 의해 식별된 사용자 에이전트에 연락하도록 수신자에게 지시하는 통화 전송이다. 또한 REFE 메시지는 수신인이 제3자에게 연락할 수 있는지 여부를 발신인이 알 수 있도록 작업 결과에 대한 이벤트 구독을 암시한다.

그러나 참조 대상 헤더 필드는 수신인이 웹 페이지를 방문하도록 요구하는 HTTP URI와 같은 모든 종류의 URI일 수 있으므로, 이 메커니즘은 호출 전송에 제한되지 않는다.

임시 응답의 신뢰도

기본 SIP 규격에서는 요청과 최종 응답(즉, 2XX 응답 코드)만 신뢰성 있게 전송된다. 즉, 승인 메시지가 도착할 때까지(즉, 요청에 대응하는 응답 코드 또는 2XX 응답 코드에 해당하는 ACK 요청)에 의해 재전송된다.[15] SIP는 메시지의 전달을 보장하는 신뢰할 수 있는 전송 프로토콜(TCP)뿐만 아니라 전달 보증을 제공하지 않는 신뢰할 수 없는 전송 프로토콜(UDP)을 통해서도 실행될 수 있으며, 전송 네트워크의 다른 부분에 두 종류의 프로토콜이 존재할 가능성도 있기 때문에 이 메커니즘이 필요하다.

단, IMS 프레임워크와 같은 시나리오에서는, 이 신뢰성을 INSTANT 요청에 대한 잠정적인 대응(세션 설정에 대해서는, 이것은, 통화를 개시하는 것)으로 확대할 필요가 있다. 잠정 응답 연장의[16] 신뢰성은 발신자에게 경보음을 알 수 있는 180 링잉 응답 코드와 같은 잠정 응답이 성공적으로 수신되는지 확인하는 메커니즘을 제공한다. 이를 위해 이 연장은 새로운 방법인 PRACK을 정의하는데, 이는 잠정 응답의 발신인에게 자신의 메시지가 수신되었음을 알리는 데 사용되는 요청 메시지다. 이 메시지에는 승인 중인 임시 응답의 RSeq 헤더 필드와 일치하는 시퀀스 번호인 RACK 헤더 필드가 포함되며, 해당 초대 요청을 식별하는 CSeq 번호도 포함되어 있다. 사용자 에이전트가 신뢰할 수 있는 임시 응답을 요청하거나 지원한다는 것을 나타내기 위해 100rel 옵션 태그를 사용한다.

세션 설명 업데이트

UPDATE 방법 확장의[17] 목적은 초기 초대 요청에 대한 최종 응답이 생성되기 전에 사용자 에이전트가 대화 상자 내에서 업데이트된 세션 설명 정보를 제공할 수 있도록 하는 것이다. 이것은 통화 당사자에게 경고가 전달되기 전에 통화 자원을 협상하고 할당하는 데 사용될 수 있다.

전제조건

IMS 프레임워크에서는 일단 캘리브에 경보가 울리면 세션 실패 확률이 최소가 되어야 한다. 중요한 실패의 원인은 세션을 지원하기 위해 네트워크 자원을 예약할 수 없기 때문에 이러한 자원은 전화벨이 울리기 전에 할당되어야 한다. 단, IMS에서 자원을 예약하기 위해서는 네트워크가 캘리어의 IP 주소, 포트 및 세션 매개변수를 알아야 하므로 세션을 설정하기 위한 초기 제안/응답 교환이 시작되어야 한다(INVITE 요청). 기본 SIP에서, 이 교환은 결국 칼리에게 경고를 유발한다. 이 문제를 해결하기 위해 전제조건의[18] 개념이 도입되었다. 이 개념에서 호출자는 제안의 세션(즉, 코덱과 QoS 요구사항)에 대한 일련의 제약조건을 명시하고 있으며, 캘리어는 세션을 설정하거나 사용자에게 경고하지 않고 제안에 응답한다. 이 설정은 발신자와 통화자 모두가 전제조건이 충족된다는 것에 동의하는 경우에만 발생할 것이다.

전제조건 SIP 확장은 SIP에 영향을 미치며, 새로운 옵션 태그(사전 조건)와 정의된 제안/응답 교환, 그리고 SIP 메시지 본문에 전달되는 스트리밍 미디어 초기화 파라미터를 설명하는 데 사용되는 형식인 SDP(Session Description Protocol)가 모두 영향을 미친다. 새로운 SDP 속성은 자원예약 현황, 세션설립을 진행하기 위한 예약상태, 확인상태를 기술하여 예약상태를 확정해야 하는 시기를 표시하기 위한 것이다.

PRACK 및 UPDATE 요청을 사용한 SDP 제공/응답 모델

IMS에서, 초기 세션 매개변수 협상은 메시지 본문에 SDP와 함께, 임시 응답과 세션 설명 업데이트 확장을 이용하여 이루어질 수 있다. 첫 번째 오퍼는 SDP를 통해 설명되며, 초대 요청에 의해 제공될 수 있으며, 발신자가 지원하는 코덱을 다룰 것이다. 이 요청은 통화자와 통화자가 모두 지원하는 SDP 코덱 목록을 포함하는 신뢰할 수 있는 임시 응답 코드 183 Session Progress로 응답한다. 이 잠정 답변에 해당하는 PRACK은 코덱을 선택하고 QoS 협상을 시작하는 데 사용될 것이다.

QoS 협상은 통화당사망에서 자원예약을 시작하는 PRACK 요청에 의해 지원되며, 2XX 응답코드로 응답한다. 일단 이 응답이 전송되면, 호출된 당사자도 코덱을 선택하고, 코덱 쪽에서 자원 예약을 시작한다. 이후 UPDATE 요청은 예약 진행 상황을 알리기 위해 전송되며, 2XX 응답 코드로 응답한다. 일반적인 제안/답변 교환에서는 예약 완료 시 통화 당사자에 의해 1개의 UPDATE가 전송되며, 그 후 호출된 당사자가 응답하여 결국 자원 할당을 완료한다.[19] 그 다음, 통화에 필요한 모든 자원이 제자리에 있을 때, 발신자에게 경고가 있을 때 입니다.

식별 및 충전

IMS 프레임워크에서는 인증, 승인 및 회계 목적을 위해 사용자 ID를 처리하는 것이 기본이다. IMS는 IP 네트워크를 통해 멀티미디어 서비스를 제공하는 것을 의미하지만, 또한 그것을 위해 사용자에게 요금을 부과하는 메커니즘이 필요하다. 이 모든 기능은 새로운 특수 헤더 필드에서 지원된다.

P헤더

P-헤더라고도 알려진 [6]SIP에 대한 프라이빗 헤더 익스텐션은 하위 계층 프로토콜의 특정 토폴로지와 특성을 가진 프라이빗 네트워크에 적용가능성이 제한된 특별한 헤더 필드다. 그들은 보다 일반적인 솔루션을 이용할 수 없었기 때문에 3GPP 요건을 충족하도록 특별히 설계되었다.

이러한 헤더 필드는 충전 및 통화 통과 네트워크에 대한 정보를 포함하여 다양한 용도로 사용된다.

  • P 충전 벡터: IMS 충전 ID(ICID) 값, ICID 값을 생성하는 SIP 프록시의 주소, IOI(Inter Operator Identifier)와 같은 충전 정보 모음입니다. 세션 설정 중 또는 대화 상자 밖에서 독립 실행형 트랜잭션으로 작성될 수 있다.
  • P-충전-기능-주소: 사용자의 홈 네트워크에 있는 충전 기능(충전 기록이나 이벤트를 수신하는 기능 주체)의 주소. 또한 대화 상자 설정 중 또는 독립 실행형 거래로 작성될 수 있으며, 거래에 관여하는 각 대리인에게 통지한다.
  • P-방문-네트워크-ID: 방문한 네트워크의 식별 문자열. 로밍 이용자에게 어떤 네트워크가 서비스를 제공하고 있는지 사용자의 홈네트워크에 표시하여 홈네트워크가 로밍 약정에 따라 등록을 받아들일 수 있도록 하는 데 등록시에 사용된다.
  • P-Access-Network-Info: 무선 액세스 기술 및 셀 ID와 같은 액세스 기술(연결성을 제공하는 네트워크)에 대한 정보. 서비스 프록시와 홈 네트워크를 알려 서비스를 최적화할 수 있도록 하거나 무선 네트워크에서 사용자를 쉽게 찾을 수 있도록 하기 위해 사용된다.
  • P-Party-ID: URI는 원래 호출 사용자 에이전트에 의해 생성된 요청의 요청-URI에 표시되었다. 요청이 호출된 사용자의 등록자(S-CSCF)에 도달하면, 등록자는 요청의 첫 번째 줄에 있는 요청-URI를 호출된 사용자의 등록된 연락처 주소(즉, IP 주소)로 다시 작성하고, 대체된 요청-URI를 이 헤더 필드에 저장한다. IMS에서 사용자는 여러 SIP URI(기록의 주소)로 식별될 수 있으며, 예를 들어, 업무용 SIP URI와 개인용 SIP URI로 식별될 수 있으며, 등록 담당자가 요청-URI를 유효 연락처 주소로 교체할 경우, 원래 요청-URI를 저장하여 발신 당사자가 어떤 주소가 초대인지 알 수 있도록 해야 한다. 발송된
  • P-Associated-URI: 등록 중인 사용자와 연결된 추가 URI. 서비스 제공업체가 AAR(Address-of-Record) URI와 연관되어 있는 다른 URI를 사용자에게 알리기 위한 레지스터 요청에 대한 200 OK 응답에 포함되어 있다.

사용자 데이터베이스 액세스를 위해 더 많은 개인 헤더가 정의됨:

  • P-사용자-데이터베이스:[20] 특정 요청을 생성한 사용자의 프로필을 포함하는 사용자 데이터베이스의 주소, 즉 HSS(Home Subscriber Server) HSS는 고유한 마스터 데이터베이스지만 신뢰성과 확장성을 이유로 다른 노드로 분산할 수 있다. 이 경우 특정 사용자를 취급하는 HSS를 찾기 위해서는 SLF(Subscriber location function)가 필요하다. 사용자 요청이 관리 도메인의 가장자리에 있는 I-CSCF에 도달하면 이 엔터티는 해당 HSS에 대해 SLF를 조회한 다음 S-CSCF가 다시 SLF를 쿼리할 필요가 없도록 HSS 주소를 P-User-Database 헤더의 S-CSCF로 전송한다. 그러면 S-CSCF는 HSS에 직접 질의하여 사용자에 대한 정보(예: 등록 중 인증 정보)를 얻을 수 있게 된다.[21]
  • P-Profile-Key:[22] 특정 SIP 요청의 대상 SIP URI에 해당하는 프로파일에 대해 사용자 데이터베이스(HSS)를 쿼리하는 데 사용할 키. 첫번째 프록시는 키를 찾고 다른 프록시는 키를 직접 사용하여 데이터베이스를 쿼리하는 빠른 데이터베이스 쿼리를 수행하기 위해 프록시 간에 전송된다. 이것은 와일드카드 방식의 서비스 ID(즉, 정규식과 일치하는 공용 서비스 ID)를 사용할 때 유용하다. 첫 번째 쿼리는 키를 찾기 위해 정규식을 해결해야 하기 때문이다.

어설픈 정체성

신뢰할 수 있는 네트워크[23] 내에서 단언된 ID에 대한 민간 확장은 이전에 합의된 식별 정보의 생성, 전송 및 사용에 대한 정책이 있는 관리 도메인 내에서만 신뢰할 수 있는 SIP 서버 네트워크가 인증된 사용자의 ID를 주장할 수 있도록 설계된다. 또한 이러한 확장은 사용자들이 자신의 신원이 트러스트 도메인 외부로 퍼지지 않도록 프라이버시를 요청할 수 있게 해준다. 이를 나타내려면 개인 정보 토큰 ID를 개인 정보 헤더 필드에 삽입해야 한다.[24]

주요 기능은 P-Asserted-Identity 확장 헤더가 지원한다. 프록시 서버는 신뢰할 수 없는 엔티티로부터 요청을 받아 사용자를 인증(즉, 사용자가 자신이 말하는 본인임을 확인)하면 인증된 ID로 이 헤더를 삽입한 후 평소와 같이 요청을 전달한다. 이렇게 하면 트러스트 도메인 내에서 이 SIP 요청을 수신하는 다른 프록시 서버(즉, 이전에 합의된 보안 정책을 가진 신뢰할 수 있는 엔티티의 네트워크)는 사용자를 재인증할 필요 없이 P-Asserted-Identity 헤더에서 전송되는 ID 정보에 안전하게 의존할 수 있다.

P-Preferred-Identity 확장 헤더도 정의되어 있어, 여러 개의 공용 ID를 가진 사용자가 인증되었을 때 P-Asserted-Identity 헤더에 어떤 공용 ID가 포함되어야 하는지 프록시에게 알려줄 수 있다.

마지막으로 개인 정보 보호가 요청될 때 프록시는 사용자 요청을 신뢰할 수 없는 ID(신뢰할 수 없는 도메인 외부)로 전달하기 전에 P-Asserted-Identity 헤더를 제거하여 신뢰할 수 있는 도메인 외부에서 어설션된 ID 정보를 보류해야 한다.

사용자 자신이 아닌 사용자의 서비스 식별을 처리하기 위한 유사한 확장 헤더가 존재한다.[25] 이 경우 균일한 리소스 이름을 사용하여 서비스 식별(예: 음성 통화, 인스턴트 메시징 세션, IPTV 스트리밍)[26]

보안 메커니즘

참고 항목: IMS 보안

IMS의 접속 보안은 S-CSCF가 행하는 사용자 인증 및 인가를 먼저 한 다음 P-CSCF와 사용자 간의 보안 연결을 확립하는 것으로 구성된다. 이를 달성하기 위한 몇 가지 메커니즘이 있는데 다음과 같다.

그 후, P-CSCF와 단말기에서 사용할 보안 알고리즘과 매개변수를 협상하기 위한 보안 메커니즘을 제공하기 위해 SIP에[28] 대한 보안 메커니즘 협정 확장이 도입되었다. 이 확장자는 세 개의 새로운 헤더 필드를 사용하여 협상 프로세스를 지원한다.

  • 첫째, 터미널은 레지스터 요청에 지원하는 메커니즘, 인증 및 암호화 알고리즘을 포함하는 보안-클라이언트 헤더 필드를 추가한다.
  • 그런 다음 P-CSCF는 클라이언트와 동일한 정보를 포함하지만 P-CSCF와 관련된 응답에 보안-서버 헤더 필드를 추가한다. 두 개 이상의 메커니즘이 있는 경우, 우선순위 값과 연관된다.
  • 마지막으로, 사용자 에이전트는 이전에 수신한 보안 서버 헤더 필드와 동일한 내용을 전달하는 보안 검증 헤더 필드를 포함하여 협상 매개변수와의 방금 작성된 보안 연결을 통해 새로운 레지스터 요청을 전송한다. 이 절차는 맨-더-미들 공격으로부터 협상 메커니즘을 보호하는데, 공격자가 터미널이 약한 보안 알고리즘을 선택하도록 하기 위해 보안-서버 헤더 필드에서 가장 강력한 보안 메커니즘을 제거했다면 보안-검증 및 보안-서버 헤더 필드가 일치하지 않을 것이다. 보안-검증 헤더 필드의 내용은 새로 확립된 보안 연결을 통해 전송되므로 변경할 수 없으며, 이 연결이 실시간으로 공격자에 의해 해제되지 않는 한(즉, P-CSCF가 진행 중인 맨인더중간 공격을 발견하기 전)에는 변경할 수 없다.

미디어 인증

서비스 품질(QoS)을 제공하기 위해 자원을 예약해야 하는 IMS의 필요성은 승인 제어와 서비스 거부 공격에 대한 보호라는 또 다른 보안 문제로 이어진다. 전송 자원을 얻기 위해, 사용자 에이전트는 네트워크(즉, 정책 시행 지점, 또는 PEP)에 권한 토큰을 제시해야 한다. 이 토큰은 QoS 정책 제어를 담당하거나 원래 인증 토큰을 제공하는 네트워크에서 정책 제어 엔티티(즉, 정책 결정 기능 또는 PDF)와 인터페이스가 있을 수 있는 P-CSCF에서 얻는다.

P-CSCF에서 사용자 에이전트로 토큰을 운반하기 위한 P-Media-Authorization 헤더 필드와 인증 토큰을 획득하기 위한 메커니즘을 정의함으로써 네트워크 내의 미디어에[29] 적용되는 QoS 메커니즘에 신호를 보내는 개인 확장. 이 확장은 신뢰 관계가 있는 관리 도메인 내에서만 적용된다. 그것은 특히 일반 인터넷이 아닌 IMS와 같은 전문화된 SIP 네트워크를 위해 설계되었다.

소스 라우팅 메커니즘

소스 라우팅은 메시지의 발신인이 메시지가 통과하는 경로의 일부 또는 전체를 지정할 수 있는 메커니즘이다. SIP에서 발신인이 채운 경로 헤더 필드는 메시지가 방문할 프록시 집합을 나열하여 이 기능을 지원한다. IMS 컨텍스트에서는 사용자의 요청으로 통과되어야 하는 특정 네트워크 엔티티(즉, 특정 CSCF)가 있으므로, 그것들은 경로 헤더 필드에 나열되어야 한다. 송신자가 그러한 엔티티를 발견하고 경로 헤더 필드를 채울 수 있도록 하기 위해, 주로 경로와 서비스 경로의 두 개의 확장 헤더 필드가 있다.

경로

비인접접촉자[30] 등록을 위한 확장 헤더 필드는 RERGER 메시지가 통과할 때 사용자 에이전트와 등록기관 사이에 위치한 프록시의 SIP URI를 축적하고 전송하는 경로 헤더 필드를 제공한다. 이렇게 하면 등록 담당자는 사용자 에이전트로 돌아가기 위해 전송해야 하는 프록시의 순서를 발견하고 기록할 수 있다.

IMS에서 모든 사용자 에이전트는 그것의 P-CSCF에 의해 서비스되는데, 이는 사용자가 IMS 네트워크에 들어갈 때 동적 호스트 구성 프로토콜 또는 동등한 메커니즘을 사용하여 발견되며, 사용자 에이전트의 모든 요청과 응답은 이 프록시를 통과해야 한다. 사용자가 홈 등록자(S-CSCF)에 등록할 때, P-CSCF는 자체 SIP URI를 RERGER 메시지의 경로 헤더 필드에 추가하여 S-CSCF가 사용자의 연락처 정보와 관련된 이 정보를 수신하고 저장한다. 이러한 방식으로 S-CSCF는 해당 사용자에게 제기된 모든 요청을 해당 P-CSCF를 통해 경로 헤더 필드에 URI를 나열하여 전달한다.

서비스 경로

등록[31] 중 서비스 경로 검색에 대한 연장선은 등록자가 등록한 사용자에게 모든 요청을 전달해야 하는 법인을 알리기 위해 등록자가 등록 요청에 대한 2XX 응답에 사용하는 서비스 경로 헤더 필드로 구성된다.

IMS에서, 등록자는 홈 네트워크의 S-CSCF이며, 또한 모든 요청은 이 기관이 처리해야 하므로, 서비스 경로 헤더 필드에 자체 SIP URI를 포함할 것이다. 그런 다음 사용자는 자신의 모든 요청에 대한 경로 헤더 필드에 이 SIP URI를 포함시켜 홈 S-CSCF를 통해 전달된다.

전역 라우팅 가능한 사용자 에이전트 URI

IMS에서 사용자는 동일한 공용 ID(예: SIP URI)로 식별되는 여러 개의 단말기(예: 휴대폰, 컴퓨터) 또는 애플리케이션 인스턴스(예: 비디오 전화, 인스턴트 메시징, 음성 메일)를 가질 수 있다. 따라서 원하는 기기나 어플리케이션으로 요청을 라우팅하기 위한 메커니즘이 필요하다. 즉, GRU(Global Routable User Agent URI)[32]는 특정 사용자 에이전트 인스턴스(즉, 터미널 또는 응용 프로그램 인스턴스)를 식별하고 전체적으로 수행하는 URI(즉, 인터넷에 있는 다른 사용자 에이전트에서 해당 사용자 에이전트로 메시지를 라우트하는 것이 유효함)이다.

이러한 URI는 사용자 에이전트 인스턴스를 식별하는 값을 가진 공용 SIP URI 또는 개인 정보 보호를 위해 GRUU와 사용자 ID 사이의 관계를 밝히지 않는 특수하게 생성된 URI에 gr 매개 변수를 SIP URI에 추가하여 구성된다. 그것들은 일반적으로 등록 과정에서 얻어진다: 등록 사용자 에이전트는 그 SIP 인스턴스를 고유하게 식별하는 균일한 자원 이름(UNURN)을 보내고, 등록자(즉, S-CSCF)는 GRUU를 구축하여 등록 ID와 SIP 인스턴스에 연결한 후 응답의 사용자 에이전트에 다시 전송한다. S-CSCF가 해당 GRU에 대한 요청을 수신하면 해당 요청을 등록된 SIP 인스턴스로 라우팅할 수 있다.

신호 압축

무선 인터페이스나 기타 저대역폭 접속을 포함할 수 있는 네트워크 자원의 효율적인 사용은 사용자에게 대기 시간의 측면에서 허용 가능한 경험을 제공하기 위해 IMS에서 필수적이다. 이 목표를 달성하기 위해 SIP 메시지는 SigComp[33](Signaling compression)로 알려진 메커니즘을 사용하여 압축할 수 있다.

압축 알고리즘은 이 모든 단어들이 한 번만 나타나는 사전의 위치에 따라 메시지에서 반복되는 단어를 대체함으로써 이 작업을 수행한다. 첫 번째 접근방식에서, 이 사전은 압축기에 의해 각 메시지에 대해 제작되어 메시지 자체와 함께 압축 풀기자에게 보내질 수 있다. 그러나 서로 다른 메시지에서 많은 단어가 반복되기 때문에, 시그컴프[34] 확장 연산은 후속 메시지들 사이에서 공유 사전을 사용하는 방법을 정의한다. 더욱이, SIP는 후속 메시지를 따라 사전을 구축하는 과정을 가속화하고 첫 번째 INVIT 메시지 이후 높은 압축 비율을 제공하기 위해, 이미 일반적인 SIP 용어와 SDP 용어로 구축된 정적 SIP/SDP 사전을 제공한다.

SIP 메시지가 압축되기를 원한다는 것을 나타내는 메커니즘이[36] 있다. 이 메커니즘은 SIP URI에 대한 comp=sigcomp 매개 변수를 정의하는데, 이는 URI가 확인한 SIP 실체가 SigComp를 지원하고 압축 메시지를 수신할 의사가 있음을 알리는 신호다. request-URI에 사용할 경우 요청을 압축해야 함을 나타내는 반면, Via 헤더 필드에서는 후속 응답을 압축해야 함을 나타낸다.

콘텐츠 양방향

심지어 더 짧은 SIP 메시지를 얻고 자원을 매우 효율적으로 사용하기 위해, 콘텐츠 양방향[37] 확장은 메시지의 MIME 본문 부분을 외부 참조(일반적으로 HTTP URI)로 대체하는 것을 가능하게 한다. 이러한 방식으로 메시지 수신인은 사용 가능한 대역폭에 따라 참조를 준수하여 리소스를 가져올지 여부를 결정할 수 있다.

NAT 트래버설

네트워크 주소 변환(NAT)은 터미널에서 생성된 패킷이 NAT을 통과할 때 공용 주소로 매핑되는 전용 주소를 사용하기 때문에 전용 네트워크 외부에서 터미널에 연결할 수 없도록 한다. 따라서 신호 평면과 미디어 평면 모두에 NAT 통과 메커니즘이 필요하다.

인터넷 엔지니어링 태스크 포스의 RFC 6314는[38] 이를 달성하기 위해 대칭 응답 라우팅과 SIP 신호에 대한 클라이언트 시작 연결, 미디어 스트림에 이전의 두 가지를 결합한 STON, Turn, ICE 등의 다양한 방법을 요약하고 통합한다.

인터넷 프로토콜 버전 6 호환성

인터넷 엔지니어링 태스크 포스의 RFC 6157은[39] IPv6으로 전환하는 동안 두 인터넷 프로토콜 버전 간에 SIP가 성공적으로 작동하도록 보장하는 데 필요한 메커니즘을 설명한다. 이러한 권고에 따라 프록시 서버와 DNS 항목이 적절히 구성되어 양쪽 네트워크를 통해 메시지를 중계하는 한 SIP 신호 메시지는 이기종 IPv4/IPv6 네트워크를 통해 전송될 수 있지만, 사용자 에이전트는 미디어 스트림을 직접 교환할 수 있도록 확장을 구현해야 할 것이다. 이러한 확장은 Session Description Protocol 제공/응답 초기 교환과 관련되며, 직접 통신을 설정할 수 있도록 양 끝의 IPv4 및 IPv6 주소를 수집하는 데 사용된다.

다른 기술과의 연동

IMS가 성공적으로 작동할 수 있도록 SIP에 설명되어 있는 모든 확장과는 별도로, IMS 프레임워크가 상호작용을 하고 기존 네트워크 인프라, 주로 PSTN(Public Switched Telephone Network)과 서비스를 교환하는 것도 필요하다.

PSTN과 인터넷(즉, IMS 네트워크) 사이의 서비스 연동을 위한 다음과 같은 몇 가지 표준이 있다.

또한 PSTN-SIP 게이트웨이에서 각 네트워크에서 한 쪽 끝의 통화를 지원하는 경우:

  • 이러한 게이트웨이의 관행과 사용을 기술하는 SIP-T(Session Initiation Protocol for Telephones)[42]
  • ISUP(ISUP)에서 SIP(Session Initiation Protocol) 매핑으로 SIP 신호 메시지를 PSTN에서 사용되는 신호시스템 No. 7(SS7)의 ISUP 메시지로 변환할 수 있으며,[43] 그 반대의 경우도 가능하다.

더욱이 SIP INFO 방법 확장은 신호 대화상자에 영향을 주지 않고 단말기 간에 사용자 정보를 전달하도록 설계되었으며, 듀얼 톤 다중 주파수 신호를 전송하여 사용자에게 전화 키패드 기능을 제공할 수 있다.[44]

참고 항목

참조

  1. ^ a b c Garcia-Martin, M. (May 2005). Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP). IETF. doi:10.17487/RFC4083. RFC 4083. Retrieved November 29, 2014.
  2. ^ a b Camarillo, Gonzalo; García-Martín, Miguel A. (November 4, 2008). The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds (3 ed.). John Wiley & Sons. pp. 55–336. ISBN 978-0-470-51662-1. Retrieved 15 November 2014.
  3. ^ Poikselkä, Miikka; Mayer, Georg; Khartabil, Hisham; Niemi, Aki (March 10, 2006). The IMS: IP multimedia concepts and services (2 ed.). John Wiley & Sons. pp. 320–331. ISBN 978-0-470-01906-1. Retrieved 15 November 2014.
  4. ^ Red Hat. "8.6. SIP AND IMS EXTENSIONS". redhat.com. Retrieved 15 November 2014.
  5. ^ Systems & Networks Training. "SIP in IMS". snt.co.uk. Retrieved 15 November 2014.
  6. ^ a b Jesske, R.; Drage, K.; Holmberg, C. (July 2014). Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP. IETF. doi:10.17487/RFC7315. RFC 7315. Retrieved November 15, 2014.
  7. ^ Rosenberg, J.; Schulzrinne, H. (June 2002). Session Initiation Protocol (SIP): Locating SIP Servers. IETF. doi:10.17487/RFC3263. RFC 3263. Retrieved December 1, 2014.
  8. ^ Rosenberg, J.; Schulzrinne, H.; Kyzivat, P. (August 2004). Caller Preferences for the Session Initiation Protocol (SIP). IETF. doi:10.17487/RFC3841. RFC 3841. Retrieved December 1, 2014.
  9. ^ Rosenberg, J.; Schulzrinne, H.; Kyzivat, P. (August 2004). Indicating User Agent Capabilities in the Session Initiation Protocol (SIP). IETF. doi:10.17487/RFC3840. RFC 3840. Retrieved December 1, 2014.
  10. ^ Roach, A. (June 2002). Session Initiation Protocol (SIP)-Specific Event Notification. IETF. doi:10.17487/RFC3265. RFC 3265. Retrieved December 1, 2014.
  11. ^ Niemi, A. (October 2004). Session Initiation Protocol (SIP) Extension for Event State Publication. IETF. doi:10.17487/RFC3903. RFC 3903. Retrieved December 2, 2014.
  12. ^ Campbell, B.; Ed., Rosenberg; J., Schulzrinne; H., Huitema; C., and; D., Gurle (December 2002). Session Initiation Protocol (SIP) Extension for Instant Messaging. IETF. doi:10.17487/RFC3428. RFC 3428. Retrieved December 2, 2014.
  13. ^ Campbell, B.; Ed., Mahy; R., Ed.; Jennings, C. (September 2007). The Message Session Relay Protocol (MSRP). IETF. doi:10.17487/RFC4975. RFC 4975. Retrieved December 2, 2014.
  14. ^ Sparks, R. (April 2003). The Session Initiation Protocol (SIP) Refer Method. IETF. doi:10.17487/RFC3515. RFC 3515. Retrieved December 2, 2014.
  15. ^ a b Rosenberg, J.; et al. (June 2002). SIP: Session Initiation Protocol. IETF. doi:10.17487/RFC3261. RFC 3261. Retrieved November 15, 2014.
  16. ^ Rosenberg, J.; Schulzrinne, H. (June 2002). Reliability of Provisional Responses in Session Initiation Protocol (SIP). IETF. doi:10.17487/RFC3262. RFC 3262. Retrieved December 2, 2014.
  17. ^ Rosenberg, J. (October 2002). The Session Initiation Protocol (SIP) UPDATE Method. IETF. doi:10.17487/RFC3311. RFC 3311. Retrieved December 2, 2014.
  18. ^ Camarillo, G.; Ed., Marshall; W., Ed.; Rosenberg, J. (October 2002). Integration of Resource Management and Session Initiation Protocol (SIP). IETF. doi:10.17487/RFC3312. RFC 3312. Retrieved December 3, 2014.
  19. ^ EvenHelix. "IMS to IMS call" (PDF). eventhelix.com/. Retrieved 3 December 2014.
  20. ^ Camarillo, G.; Blanco, G. (April 2006). The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header). IETF. doi:10.17487/RFC4457. RFC 4457. Retrieved December 5, 2014.
  21. ^ EvenHelix. "IMS registration" (PDF). eventhelix.com/. Retrieved 5 December 2014.
  22. ^ Camarillo, G.; Blanco, G. (August 2007). The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header). IETF. doi:10.17487/RFC5002. RFC 5002. Retrieved December 5, 2014.
  23. ^ Jennings, C.; Peterson, J.; Watson, M. (November 2002). Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks. IETF. doi:10.17487/RFC3325. RFC 3325. Retrieved December 3, 2014.
  24. ^ Peterson, J. (November 2002). A Privacy Mechanism for the Session Initiation Protocol (SIP). IETF. doi:10.17487/RFC3323. RFC 3323. Retrieved December 3, 2014.
  25. ^ Drage, K. (November 2010). A Session Initiation Protocol (SIP) Extension for the Identification of Services. IETF. doi:10.17487/RFC6050. RFC 6050. Retrieved December 5, 2014.
  26. ^ Rosenberg, J. (June 2010). Identification of Communications Services in the Session Initiation Protocol (SIP). IETF. doi:10.17487/RFC5897. RFC 5897. Retrieved December 5, 2014.
  27. ^ Niemi, A.; Arkko, J.; Torvinen, V. (September 2002). Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA). IETF. doi:10.17487/RFC3310. RFC 3310. Retrieved December 5, 2014.
  28. ^ Arkko, J.; Torvinen, V.; Camarillo, G.; Niemi, A.; Haukka, T. (January 2003). Security Mechanism Agreement for the Session Initiation Protocol (SIP). IETF. doi:10.17487/RFC3329. RFC 3329. Retrieved December 5, 2014.
  29. ^ Marshall, W. (January 2003). Private Session Initiation Protocol (SIP) Extensions for Media Authorization. IETF. doi:10.17487/RFC3313. RFC 3313. Retrieved December 5, 2014.
  30. ^ Willis, D.; Hoeneisen, B. (December 2002). Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts. IETF. doi:10.17487/RFC3327. RFC 3327. Retrieved December 5, 2014.
  31. ^ Willis, D.; Hoeneisen, B. (October 2003). Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration. IETF. doi:10.17487/RFC3608. RFC 3608. Retrieved December 5, 2014.
  32. ^ Rosenberg, J. (October 2009). Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP). IETF. doi:10.17487/RFC5627. RFC 5627. Retrieved December 5, 2014.
  33. ^ Price, R.; Bormann, C.; Christoffersson, J.; Hannu, H.; Liu, Z.; Rosenberg, J. (January 2003). Signaling Compression (SigComp). IETF. doi:10.17487/RFC3320. RFC 3320. Retrieved December 4, 2014.
  34. ^ Hannu, H.; Christoffersson, J.; Forsgren, S.; Leung, K.-C.; Liu, Z.; Price, R. (January 2003). Signaling Compression (SigComp) - Extended Operations. IETF. doi:10.17487/RFC3321. RFC 3321. Retrieved December 4, 2014.
  35. ^ Garcia-Martin, M.; Bormann, C.; Ott, J.; Price, R.; Roach, A. (February 2003). The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp). IETF. doi:10.17487/RFC3485. RFC 3485. Retrieved December 4, 2014.
  36. ^ Camarillo, G. (February 2003). Compressing the Session Initiation Protocol (SIP). IETF. doi:10.17487/RFC3486. RFC 3486. Retrieved December 4, 2014.
  37. ^ Burger, E. (May 2006). A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages. IETF. doi:10.17487/RFC4483. RFC 4483. Retrieved December 4, 2014.
  38. ^ Boulton, C.; Rosenberg, J.; Camarillo, G.; Audet, F. (July 2011). NAT Traversal Practices for Client-Server SIP. IETF. doi:10.17487/RFC6314. RFC 6314. Retrieved December 5, 2014.
  39. ^ Camarillo, G.; El, Malki; K., and; V., Gurbani (April 2011). IPv6 Transition in the Session Initiation Protocol (SIP). IETF. doi:10.17487/RFC6157. RFC 6157. Retrieved December 5, 2014.
  40. ^ Petrack, S.; Conroy, L. (June 2000). The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services. IETF. doi:10.17487/RFC2848. RFC 2848. Retrieved December 5, 2014.
  41. ^ Gurbani, V.; Ed., Brusilovsky; A., Faynberg; I., Gato; J., Lu; H., and; M., Unmehopa (October 2004). The SPIRITS (Services in PSTN requesting Internet Services) Protocol. IETF. doi:10.17487/RFC3910. RFC 3910. Retrieved December 5, 2014.
  42. ^ Vemuri, A.; Peterson, J. (September 2002). Session Initiation Protocol for Telephones (SIP-T): Context and Architectures. IETF. doi:10.17487/RFC3372. RFC 3372. Retrieved December 5, 2014.
  43. ^ Camarillo, G.; Roach, A.; Peterson, J.; Ong, L. (December 2002). Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping. IETF. doi:10.17487/RFC3398. RFC 3398. Retrieved December 5, 2014.
  44. ^ Holmberg, C.; Burger, E.; Kaplan, H. (January 2011). Session Initiation Protocol (SIP) INFO Method and Package Framework. IETF. doi:10.17487/RFC6086. RFC 6086. Retrieved December 5, 2014.

책들

외부 링크