KR100932834B1

KR100932834B1 - Ｓｉｐ 메시지 프로세싱 방법

Info

Publication number: KR100932834B1
Application number: KR1020050027227A
Authority: KR
Inventors: 제레미 토마스 부츠; 진얀 수; 산카란 나라야난; 바딤 이델맨
Original assignee: 마이크로소프트 코포레이션
Priority date: 2004-03-31
Filing date: 2005-03-31
Publication date: 2009-12-21
Also published as: CN1677978B; CN1677978A; KR20060045393A; RU2005109222A; CA2503289A1; EP1583318A2; US20050220095A1; BRPI0501297A; CA2503289C; JP4800651B2; EP1583318B1; AU2005201046B2; JP2005312026A; US7535905B2; AU2005201046A1; CA2811999A1; MXPA05003410A; RU2378773C2; EP1583318A3; CA2811999C

Abstract

SIP 라우팅 헤더들의 서명 및 유효화(validation)를 위한 방법, 컴퓨터 실행 가능 명령어들을 가진 컴퓨터 판독 가능 매체, 및 데이터 구조가 저장되어 있는 컴퓨터 판독 가능 매체가 개시된다. SIP 노드는 메시지 헤더를 포함하는 SIP 요청을 수신할 수 있다. 메시지 헤더의 적어도 일부 및 SIP 노드 헤더 항목에 기초하는 서명이 생성될 수 있다. 그 다음, 서명은 SIP 노드 헤더 항목에 삽입될 수 있다.

SIP, 라우팅 헤더

Description

ＳＩＰ 메시지 프로세싱 방법{SIGNING AND VALIDATING SESSION INITIATION PROTOCOL ROUTING HEADERS}

도 1은 본 발명의 일 실시예에 따른 2개의 SIP 클라이언트들간의 INVITE 요청 및 응답의 개략도이다.

도 2는 도 1에 따른 예시적 INVITE 요청이다.

도 3은 도 1에 따른 VIA 헤더들의 예시적 세트이다.

도 4는 도 1에 따른 RECORD-ROUTE 헤더들의 예시적 세트이다.

도 5는 도 2의 INVITE 요청에 대한 예시적 응답이다.

도 6은 도 1의 피호출자 SIP 노드에 의해 생성되는 예시적 요청이다.

도 7은 도 1의 호출자 SIP 노드에 의해 생성되는 예시적 요청이다.

도 8은 본 발명의 일 실시예에 따른 예시적 SIP 서버의 도면이다.

도 9는 본 발명의 일 실시예에 따른 키 정보 데이터베이스로부터의 예시적 도표의 도면이다.

도 10은 본 발명의 일 실시예에 따라 VIA 서명이 생성될 수 있는 방법을 설명하는 흐름도이다.

도 11은 본 발명의 일 실시예에 따라 VIA 헤더를 확인하는 방법을 설명하는 흐름도이다.

도 12는 본 발명의 일 실시예에 따라 ROUTE SET 서명 및 RECORD-ROUTE 서명이 생성될 수 있는 방법을 설명하는 흐름도이다.

도 13은 본 발명의 일 실시예에 따라 RECORD-ROUTE 서명을 확인하는 방법을 설명하는 흐름도이다.

도 14는 본 발명의 일 실시예에 따라 세션 키가 서버 풀의 서버로 수입(import)될 수 있는 방법을 설명하는 흐름도이다.

<도면의 주요 부분에 대한 부호의 설명>

100, 400 : 사용자

104, 404 : 컴퓨터 시스템

102, 200, 250, 300, 402 : SIP 노드

300A : 제 1 서버

300B : 제 2 서버

500 : INVITE 메시지

600 : 응답 메시지

700, 800 : 요청

발명의 분야

본 출원은 컴퓨터 네트워크를 통해 장치들 사이에서 통신하는 방법들 및 컴 퓨터 판독 가능 매체들에 관한 것으로서, 보다 구체적으로는, SIP(Session Initiation Protocol) 메시지에 포함된 라우팅 명령어들을 인증하기 위해 SIP 라우팅 헤더들에 서명하고 유효화하는 방법들 및 컴퓨터 판독 가능 매체들에 관한 것이다.

발명의 배경

SIP는, 인스턴트 메시지 통신, 인터넷 전화 호출들, 및 인터넷 화상 회의를 포함하는, 통신 세션들을 개설하고, 관리하며, 종결하는 인터넷 신호 프로토콜이다. SIP는, 각각이 참조로써 본 명세서에 통합되어 있는, IETF(Internet Engineering Task Force) RFC(Request for Comments) 2543 및 RFC 3261에 상술되어 있다. SIP 세션들은 하나 이상의 (통상적으로 호출자 및 피호출자인) 관계자들 또는 클라이언트들과 관련이 있다. SIP 메시지들은, 통상적으로 다양한 서버들인, SIP 노드들의 네트워크를 통해 각각의 종단점 SIP 노드(예를 들어, 호출자 및 피호출자) 사이에서 라우팅된다.

일반적으로 2가지 유형의 SIP 메시지들이 존재한다: 호출자(예를 들어, 종단점 SIP 노드)로부터 피호출자로 송신되는 요청들 및 요청에 응답하여 피호출자로부터 호출자로 송신되는 응답들. 일부의 경우들에서는, 다이얼로그 세션이 개시된 후, 피호출자 또한 호출자에게 요청을 송신할 수 있다. 각각의 SIP 메시지는, 그것이 응답이든 요청이든, 일반적으로 3가지 부분들을 포함한다: 시작 라인, 헤더들, 및 바디(body). 시작 라인은 메시지 유형(예를 들어, 요청 또는 응답) 및 프로토콜 버전을 전달하고, 메시지 바디는 메시지의 내용을 포함하며 시작 라인의 신 호 정보를 넘어서는 세션 기술 정보(session description information)를 전달할 수 있다. SIP 헤더 필드들은 메시지의 속성들을 전달하며 메시지 의미를 수정한다. 헤더 필더들에 저장된 메시지의 일부 속성들은, 메시지를 라우팅하는 방법 뿐만 아니라 메시지에 의해 이동된 실제 라우트를 문서화하는 방법에 관한 명령어들이다. 예를 들어, 자신의 라우트에 대한 요청을 관리하는 각각의 SIP 노드는, 완전한 자격의 도메인 네임(fully qualified domain name;FQDN) 또는 인터넷 프로토콜 어드레스와 같은, SIP 노드를 식별하는 정보를 포함하는 'VIA' 헤더를 부가할 것이다. 이런 방식으로, 라우트들의 루프들이 검출될 수 있으며 응답은 요청으로부터의 VIA 헤더들을 사용하여 호출자로 복귀하기 위해서 이동되어야 할 라우트를 결정한다. 그러나, 메시지의 특정 경로는 시간에 따라 달라질 수 있으므로, 홈 서버와 같은, SIP 노드는, 전화 호출과 같은, 다이얼로그의 제 1 요청은 수신할 수 있지만, 동일한 다이얼로그의 후속 요청들은 수신하지 못할 수도 있다. 그 다이얼로그에 대한 '루프'에 남기 위해서, SIP 노드는, URI(uniform resource indicator) 또는 다른 서버들 또는 종단점들이 SIP 노드에 도달할 수 있게 하는 다른 어드레스와 같은, 그 자신을 식별하는 정보를 포함하는 RECORD-ROUTE 헤더를 삽입할 수 있다. 다음으로는, 수신하는 최종 클라이언트(요청들에 대한 피호출자 및 응답들에 대한 호출자)에 의해 한 세트의 ROUTE 헤더들에 RECORD-ROUTE 헤더들의 완전 리스트의 부분들이 복사된다. ROUTE SET 헤더들은 동일한 다이얼로그 세션내의 임의의 장래 요청들을 라우팅하는 방법에 관한 명령어들을 SIP 노드들에 제공하는 데이터를 포함한다.

상술된 SIP 헤더 필드들이, 메시지 라우트에 따른 서버들과 같은, SIP 노드들과의 메시지 라우팅을 돕긴 하지만, 이러한 헤드들 중 많은 것들이 SIP 표준들(RFC3261)에 따라 사용될 경우 안전하지 않다. 예를 들어, SIP 헤더에 위조된 라우팅 정보를 포함하는 복수의 날조된 SIP 메시지들을 이용해, 서버에 서비스 거부 공격들(denial of service attacks)이 가해질 수 있다. 어쩌면 서비스 거부 공격들이 무고한 서버에서 발신된 것처럼 보이게 하면서, 위조된 메시지의 진정한 발신자는 날조된 헤더 정보에 의해 가려질 수도 있다. 또한, 날조된 라우팅 헤더들은 2개의 서버들 간에 루핑 메시지들을 생성할 수 있다. 이런 식으로, 위조된 메시지의 날조된 '라우트'에 따라 각 서버는 위조된 메시지들을 프로세싱하고 전달하는데 귀중한 리소스들을 낭비함으로써, 합법적인 사용자들에게는 그러한 리소스들이 허용되지 않을 수도 있다.

본 발명의 실시예들은, SIP 메시지에서 발견된 라우팅 헤더들을 인증하는 방법들 및 컴퓨터 판독 가능 매체들에 관한 것이다. 구체적으로, SIP 노드는, 메시지 헤더를 포함하는 SIP 요청을 수신할 수 있다. 메시지 헤더의 적어도 일부에 기초하여 서명이 생성되어 SIP 노드 헤더 항목에 삽입될 수 있다. 여기에서 사용되는 바와 같이, SIP 노드는, SIP 클라이언트 또는 서버로서 동작할 수 있는 컴퓨팅 장치상에서 실행 중인 SIP 애플리케이션을 의미한다.

예를 들어, 수신된 요청 헤더의 VIA 헤더들 중 적어도 일부에 기초하여, 제 1 서명이 생성되어 SIP 노드에 대한 VIA 헤더에 삽입될 수 있다. SIP 요청에 대한 응답이 생성될 때, SIP 노드의 VIA 헤더는 SIP 표준 프로세싱에 따른 응답 헤더에 에코백(echo back)된다. SIP 노드가 응답을 수신할 때, SIP 노드는, 응답에 의해 이동된 실제 경로의 무결성(integrity)을 인증하기 위해, 응답에 대한 SIP 노드 VIA 헤더의 제 1 서명을 확인할 수 있다.

부가적으로 또는 다른 방법으로, RECORD-ROUTE 헤더들 중 적어도 일부 및 메시지 헤더의 CONTACT 헤더에 기초하여 제 2 서명이 생성될 수 있다. 제 2 서명은 SIP 노드의 RECORD-ROUTE 헤더에 삽입될 수 있다. 다음으로, 제 2 서명이 첨부된 이러한 RECORD-ROUTE 헤더 부분들은, 세션이 개시된 후 피호출자 시스템에 의해 생성된 호출자 시스템으로의 요청들을 라우팅하고 확인하기 위한 ROUTE 헤더로서의 사용을 위해, 피호출자 시스템에 의해 저장될 것이다.

부가적으로 또는 다른 방법으로, 메시지 헤더의 RECORD-ROUTE 헤더들 중 적어도 일부에 기초하여 제 3 서명이 생성될 수 있다. 제 3 서명은 SIP 노드의 RECORD-ROUTE 헤더에 삽입될 수 있다. 피호출자가 SIP 요청에 응답할 때, SIP 노드의 RECORD-ROUTE 헤더는 응답 헤더로 에코백된다. 장래 요청들을 라우팅하는 방법에 관한 명령어들의 무결성을 확인하기 위해, 제 3 서명은 SIP 노드가 응답을 수신할 때 SIP 노드에 의해 확인될 수 있다. 예를 들어, 응답을 수신하는 SIP 노드는 요청 헤더로부터 에코된 데이터를 포함하는 RECORD-ROUTE 헤더를 식별하여 에코된 헤더로부터 서명을 추출할 수 있다. SIP 노드는 제 3 서명을 생성하는데 사용된 것과 동일한 프로세스, 예를 들어, 응답 헤더의 헤더들 중 적어도 일부에 기초하여 서명을 생성하는 프로세스를 사용해 확인 서명을 생성할 수 있다. 다음으로, SIP 노드는 확인 서명과 추출된 서명을 비교할 수 있다. 서명들이 매칭되면, 메시지는 정상적으로 프로세싱될 수 있다.

제 4 서명이 생성되어 SIP 응답 헤더에 삽입될 수 있다. 예를 들어, 응답을 수신하는 SIP 노드는 응답 헤더의 RECORD-ROUTE 헤더들 중 적어도 일부 및 응답 헤더의 CONTACT 헤더에 기초하여 제 4 서명을 생성할 수 있다. 제 4 서명은 상술된 제 2 서명과 유사하지만, 제 4 서명은 응답의 CONTACT 헤더에 기초하여 생성되므로, CONTACT은 요청과 관련된 호출자가 아니라 피호출자를 식별한다. 다음으로, 제 4 서명은 SIP 노드에 대한 RECORD-ROUTE 헤더에 삽입될 수 있다. 그 다음, 호출자 시스템은, 호출자 시스템이 응답을 수신할 때, 후속 요청들의 라우팅 명령어들의 사용 및 확인을 위한 ROUTE SET 헤더로서 서명이 첨부된 RECORD-ROUTE 헤더의 부분들을 저장할 수 있다.

일부 경우들에서는, SIP 메시지들을 프로세싱하는 SIP 노드가, 동일한 다이얼로그의 메시지들을 프로세싱하는데 교체 사용될 수 있는 적어도 제 1 서버 및 제 2 서버를 가진 서버 풀(pool of servers)에 의해 제공될 수 있다. 그러나, 메시지들이 교환될 때, 다이얼로그의 요청은 제 1 서버에 의해 생성된 서명을 포함하지만 프로세싱을 위해 제 2 서버로 송신될 수 있다. 이것은, 제 2 서버가 요청의 서명을 확인하는데 사용될 세션 키를 가질 것을 요구한다. 요청의 서명을 생성하는데 사용된 세션 키를 안전하게 전달하기 위해, 서명을 생성 중인 제 1 서버는 암호화되고 서명된 세션 키를 메시지의 헤더에 첨부할 수 있다. 예를 들어, 세션 키는, 그 키에 의해 생성된 서명을 포함하는 동일한 헤더에 삽입될 수 있다. 다른 SIP 노드들로부터 세션 키를 보호하기 위해, 제 1 서버는 서버 풀에 액세스할 수 있는 공개 키로 세션 키를 암호화할 수 있다. 그 다음, 제 1 서버는 암호화된 키에 서버 풀에 액세스할 수 있는 비밀 키로 서명할 수 있다. 요청을 수신하는 제 2 서버는 암호화된 키의 서명을 확인한 다음 세션 키를 복호화할 수 있다. 복호화된 세션 키를 사용하여, 제 2 서버는 메시지 헤더의 적어도 일부에 기초하여 서명을 확인할 수 있다. 예를 들어, 공개/비밀 키 쌍들을 포함하는 비대칭 키 기술들을 포함하여, 임의의 적당한 보안 프로세스가 세션 키를 보호하는데 사용될 수 있다는 것을 알 수 있을 것이다.

첨부된 도면들을 참조하는 다음의 상세한 설명으로부터 본 발명의 상술한 태양들 및 부수적인 많은 이점들을 좀더 분명하게 이해할 수 있을 것이다.

바람직한 실시예의 상세한 설명

서비스 거부 공격들은 통상적으로, 웹 서버들 또는 파일 서버들과 같은, 네트워크 서비스들을 과부하하거나 정지시키기 위해 공격자들에 의해 시도되는 컴퓨터화된 공격이다. 예를 들어, 공격으로 인해, 서버는 위조된 메시지들에 응답하기 위한 시도로 너무 분주해져 접속을 위한 합법적 요청들을 무시할 수 있다. 다른 경우에, 합법적 메시지들의 라우팅이 손상되어 SIP 노드들이 응답들을 부정확하게 전송할 수 있다. 일부의 경우들에서는, 컴퓨터 네트워크를 통해 메시지들을 전송하는데 사용되는 통신 프로토콜이 공격의 중점이 될 수 있다. 예를 들어, 상기한 바와 같이, 위조된 SIP 메시지들이 날조된 VIA 헤더들, ROUTE 헤더들, 및/또는 RECORD-ROUTE 헤더들을 포함하여 송신되어, 메시지들을 희생 SIP 노드들(victim SIP nodes)로 유도하거나 그리고/또는 공격자의 식별 정보 및 소스를 가장할 수 있다. 이러한 서비스 거부 공격들을 감소시키기 위해, SIP 헤더들에 포함된 라우팅 명령어들 및 실제 라우팅 경로는 그들의 무결성을 보장하도록 확인될 수 있다.

도 1은, SIP 클라이언트(102)의 사용자(100;예를 들어, Alice)가, 인터넷, 인트라넷, WAN(wide-area network), LAN(local area network), 가상 사설 통신망 등을 포함할 수 있는 통신 네트워크를 통해 다른 사용자(400;Bob)와 통신 세션을 개시하고자 하는 예시적인 세션 개시 동작을 도시한다. 그러한 목적을 위해, 컴퓨터 시스템(104)상에 상주하는 SIP 클라이언트(102)는, Bob을 의도된 수신자로서 식별하는 INVITE 요청 메시지(500)를 송신한다. SIP 표준에 따른 통신 맥락에서, 세션을 개시하기 위해 INVITE 메시지(500)를 송신하는 SIP 클라이언트(102)를 "호출자(caller)"라고 하며, Bob의 컴퓨터 시스템(404)상의 SIP 클라이언트(402)를 "피호출자(callee)"라고 한다. SIP에 정의된 바와 같이, SIP 클라이언트(102)는 새로운 요청을 생성하기 때문에, "UAC(user agent client)"라고도 하며, SIP 클라이언트(402)는 SIP 요청(500)에 대한 응답(600)을 생성하기 때문에, "UAS(user agent server)"라고도 한다.

도 1에 나타낸 바와 같이, Alice로부터의 INVITE 메시지(500)는 호출자 SIP 클라이언트 도메인을 위한 아웃바운드 서버(200;outbound server)로 송신된다. 그 후, INVITE 메시지는, 그것이 Bob 도메인의 SIP 프럭시 서버(300;SIP proxy server)에 도달하기 전에, 신호 동작에 관련된 다수의 SIP 노드들을 통해 전달될 수 있다. 간략화를 위해, 도 1에는 5개의 SIP 노드들만이 도시되어 있지만, 임의의 링크들이 다른 서버들, 게이트웨이들, 브릿지들 등을 포함할 수 있다는 것을 이해할 수 있어야 한다. SIP 프럭시(300)는 INVITE 메시지를 Bob 컴퓨터의 SIP 클라이언트(402;피호출자)로 전달한다. Bob의 컴퓨터는 자동적으로 또는 Bob으로부터의 허가시에, 성공적인 전송을 표시하는 "200(OK)" 메시지와 같은, 응답(600)을 INVITE로 송신한다.

상기한 바와 같이, 각각의 SIP 메시지는 일반적으로 시작 라인, 속성들 및 메시지의 라우팅에 관한 정보를 포함하는 헤더, 및 메시지의 바디를 포함한다. 예를 들어, 도 2는 Alice SIP 클라이언트(102)에 의해 송신되어 SIP 노드(200)에 의해 수신된 INVITE 요청(500) 표현을 도시한다. 예시적 INVITE(500)는 시작 라인(502), 복수개의 헤더들(504), 및 바디(506)를 포함한다. 시작 라인(502)은 메시지 유형(여기에서는 INVITE), 일반적으로 피호출자의 SIP 어드레스인 요청 URI, 및 SIP 버전을 식별한다. 헤더들(504)은 SIP 표준하에서 허용된 필드들이다. VIA 헤더(508)는 프로토콜 및 이전 홉(hop)의 어드레스를 표시하는 정보를 포함한다. FROM 헤더(510)는 요청을 발생시킨 사용자(호출자), 여기에서는 Alice를 표시하는 정보를 포함한다. TO 헤더(512)는 호출자에 의해 명시된, 피호출자를 표시하는 정보를 포함한다. Call-ID 헤더(514)는 개시 중인 세션의 전역적으로 고유한 식별자를 표시하는 정보를 포함한다. CSeq 헤더(516)는, 동일한 트랙잭션의 일부로서 동일한 FROM, TO, 및 Call-ID 헤더들로써 송신된 복수 메시지를 구별하는 식별자를 표시하는 정보를 포함한다. CONTACT 헤더(518)는, 장래 메시지들의 라우팅이 (다음에서 부연되는) RECORD-ROUTE 헤더들에 열거되지 않은 SIP 노드들을 우회할 수 있게 하는, 후속 요청들의 목적지를 표시하는 정보를 포함한다. VIA 헤더, TO 헤더, FROM 헤더, COMNTACT 헤더, RECORD-ROUTE 헤더, 및 ROUTE 헤더 각각은, URI, 인터넷 프로토콜 어드레스 등과 같은, 네트워크의 라우팅 위치들을 표시하는 데이터를 포함한다. 예를 들어, 라우팅 위치들을 표시하는 데이터를 포함하는 RECORD-ROUTE 헤더는 헤더 파라미터들이 수반되는 "< >" 괄호들에 둘러싸인 URI 부분을 포함할 수 있다. "< >" 괄호들내의 URI 부분은 URI 및 URI 파라미터를 포함할 수 있다. 일반적으로, 하나 이상의 공백 라인은 헤더들(504)의 끝 및 바디 부분(506)의 시작을 표시한다. 도 5에 나타낸 예시적 응답(600)은, INVITE 요청과 마찬가지로, 시작 라인(602), 헤더 부분(604), 및 바디(606)를 포함한다.

SIP 표준하에서, INVITE(500)가 네트워크를 통해 이동함에 따라 INVITE(500)를 관리하는 모든 SIP 노드는 VIA 헤더를 INVITE 헤더(504)에 추가한다. 이런 식으로, 누적된 VIA 헤더들은 피호출자에 의해 요청의 회답으로서 응답의 라우팅을 유도하는데 사용될 수 있다. SIP 노드가 호출자와 피호출자간의 특정 다이얼로그를 위한 메시지들을 계속 관리하고자 한다면, SIP 노드는 RECORD-ROUTE 헤더를 INVITE 헤더(504)에 삽입할 수 있다. 이런 식으로, 피호출자에 의해 생성될 수 있는 장래 요청들의 라우팅을 유도하기 위해, 다이얼로그-개시 요청에 대한 RECORD-ROUTE 헤더들 및 CONTACT 헤더의 누적된 URI 부분들은, 수신 중인 피호출자에 의해, 열거된 것과 동일한 순서로, 헤더들의 ROUTE SET로서 저장될 수 있다. 마찬가지로, 호출자에 의해 생성된 장래 요청들에 대한 라우팅 명령어들을 제공하기 위 해, 다이얼로그-개시 요청에 응답하여 RECORD-ROUTE 헤더들 및 CONTACT 헤더의 누적된 URI 부분들은, 호출자에 의해, ROUTE SET 헤더들과 반대 순서로 저장될 수 있다.

도 1은, SIP 노드들을 프로세싱하는 것에 의한 헤더들의 추가라는 관점에서 INVITE 요청 및 응답에 대한 라우팅의 특정 예를 도시한다. 간략화를 위해, 비본질적인 헤더들 및 다른 메시지 정보는 제외하였다. 도시된 SIP 노드들의 펑크션들 및 갯수는 예시적인 것이며 메시지 라우팅 및 확인은 특정 목적들 및/또는 네트워크 아키텍처들을 위해 변경될 수 있다는 것을 알 수 있을 것이다.

도 1에 나타낸 바와 같이, SIP 노드(200)는 홈 서버일 수 있으며 SIP 클라이언트(102)로부터 INVITE 요청을 수신할 수 있다. 메시지를 수신 중인 SIP 노드(200)는 INVITE 요청의 헤더(504)에 VIA 헤더를 삽입한다. SIP 노드(200)는, 홈 서버로서, SIP 클라이언트(102)와의 임의의 SIP 메시지들을 관리하고자 할 수 있다. 따라서, SIP 노드(200)는 메시지를 후속 SIP 노드로 전달하기 전에 RECORD-ROUTE 헤더를 INVITE 메시지에 삽입할 수 있다. 도 1의 도시된 실시예에서, 후속 SIP 노드(250)는 호출자 SIP 클라이언트(102)에 대한 에지 서버(edge server)이다. SIP 노드(250)는 자신의 VIA 헤더 및 RECORD-ROUTE 헤더를 메시지의 헤더(504)에 삽입한 후 INVITE 메시지를 전달한다. 궁극적으로, INVITE 메시지는, 도 1의 도시된 실시예에서, 피호출자 SIP 클라이언트(402)의 에지 프럭시 서버인 SIP 노드(300)로 라우팅된다. 에지 프럭시 서버는, 예를 들어, 인터넷으로부터 로컬 네트워크를 추출하는, 네트워크의 에지에서 실행하도록 설계된 프럭시 서버일 수 있다. 에지 서버(250)와 마찬가지로, 에지 프럭시 서버(300)는 메시지를 SIP 클라이언트(402)로 전송하기 전에 VIA 헤더 및 RECORD-ROUTE 헤더를 INVITE 헤더(504)에 삽입한다. INVITE 요청(500)에 삽입된 SIP 노드(200)의 VIA 헤더(530), SIP 노드(250)의 VIA 헤더(532), 및 SIP 노드(300)의 VIA 헤더(534)의 예들이 도 3에 도시되어 있다. INVITE 요청(500)에 삽입된 SIP 노드(200)의 RECORD-ROUTE 헤더(520), SIP 노드(250)의 RECORD-ROUTE 헤더(522), 및 SIP 노드(300)의 RECORD-ROUTE 헤더(524)의 예들이 도 4에 도시되어 있다.

Bob의 SIP 노드(402)는 INVITE를 수용하고 INVITE 요청에 응답하여 OK 응답(600)을 송신할 수 있다. 도 5는 SIP 노드(402)로부터 서버(300)로의 예시적인 응답(600)을 도시한다. SIP 표준하에서, 응답(600)의 많은 헤더 필드들 또는 헤더 필드들의 적어도 일부는 수신된 응답으로부터 복사되거나 에코된다. 이러한 에코된 헤더들은, 예를 들어, SIP 표준하에서 판정할 때, 각각의 VIA 헤더, FROM 헤더, TO 헤더, 각각의 RECORD-ROUTE 헤더, Call-ID 헤더, 및 CSeq 헤더를 포함할 수 있다. 이런 식으로, 도 5에 나타낸 응답(600)은 에코된 헤더들을 도시한다. 구체적으로, 응답(600)의 VIA 헤더들(608, 630, 632, 634)은 피호출자 SIP 노드(402)에 의해 수신된 INVITE(500)의 VIA 헤더들(508, 530, 532, 534)과 동일하다. 마찬가지로, RECORD-ROUTE 헤더들(620, 622, 624)은 SIP 노드들에 의해 생성되었으며 피호출자 SIP 노드(402)에 의해 수신된 RECORD-ROUTE 헤더들(520, 522, 524)과 동일하다. 다음으로, 응답 메시지는 VIA 헤더들(608, 630, 632, 634)에 의해 유도되는 대로 네트워크를 통해 호출자 SIP 노드(102)로 라우팅된다.

응답을 프로세싱 중인 SIP 노드들, 예를 들어, SIP 노드들(300, 250, 200)은 VIA 헤더들에 포함된 라우팅 명령어들을 확인하는 것에 의해 응답에 의해 취해진 실제 라우트의 무결성을 확인할 수 있다. 일 실시예에서, SIP 노드는, VIA 헤더들(508, 530, 532)과 같은, 라우팅 정보를 이후의 액세스 및 응답 VIA 헤더들(608, 630, 632)을 확인하는데 사용하기 위해 데이터베이스에 저장할 수 있다. 다른 방법으로, SIP 노드에 대한 메모리 및 액세스 부하들을 감소시키기 위해, SIP 노드는, 메시지 라우트의 네트워크 라우팅 위치를 표시하는 데이터를 포함하는 하나 이상 헤더의 적어도 일부에 기초하는 서명을 생성할 수 있다. 예를 들어, 서명은 네트워크 라우팅 위치를 포함하는 모든 헤더에 기초하거나, URI, URI 파라미터, 피어 FQDN(fully qualified domain name) 등과 같은, 그 헤더의 일부에만 기초할 수 있다. 서명은, 메시지가 후속 홉을 통해 송신될 접속에 대한 접속 식별자, 에코된 헤더, TO 헤더, FROM 헤더, CONTACT 헤더, Call-ID 헤더, CSeq 헤더, 및 Branch-ID를 포함하여, 하나 이상의 헤더 이외에 다른 정보에 기초할 수도 있다. 다음으로, 요청에 대한 하나 이상 헤더의 적어도 일부에 기초하는 서명은 응답으로 전달되어, 응답이 SIP 노드에 의해 프로세싱될 때, 확인될 수 있다. 헤더 부분이 서명에 포함되어야 할 것인지의 여부는 헤더 부분이 SIP 프럭시에 의해 확인되기 전에 변경될 것인지의 여부에 의존할 수 있다. 예를 들어, 헤더 부분들이 서명의 확인을 위해 액세스되기 전에 삭제되거나 변경될 수 있는 정보를 포함하는 헤더 부분들은 서명에 포함되지 말아야 한다. SIP 메시지에 대한 라우트의 SIP 노드들 중 어느 하나 또는 전부가, 여기에서 논의된 것을 포함하여, 적당한 임의 방식으로 확인 서명을 생성하고 저장할 수 있다는 것을 알 수 있을 것이다. SIP 메시지의 헤더들은, 안전한 링크들의 리스트를 유지하는 것, 서명에 관한 전역적 정책에 따르는 것, 및 특정 도메인과의 메시지들을 서명/확인하는 것을 포함하여, 네트워크 및 SIP 노드들에 대한 보안 문제들 및 표준들에 따라 적절한 것으로 평가될 수 있다는 것도 알 수 있을 것이다. 예를 들어, 안전한 링크들의 리스트를 구현하기 위해, 각각의 서버는 안전한 것으로 판단되는 링크들의 리스트를 유지할 수 있다. 그에 따라, 안전한 링크로 입력되는/안전한 링크로부터 출력되는 모든 메시지는 서명/확인되지 않을 수 있다. 따라서, 서버는 서명을 생성/확인하기 전에, 그 링크가 불안전하다는 것, 예를 들어, 안전한 링크들의 리스트에 열거되지 않았다는 것을 확인하기 위해, 안전한 링크들의 리스트를 검사할 수 있다.

일례에서는, 액세스 가능한 세션 키를 사용해, 요청 메시지의 하나 이상의 VIA 헤더에 기초하는 서명이 생성될 수 있다. 메시지에 의해 이동된 라우트를 확인하기 위해, SIP 노드는 모든 VIA 헤더들 또는 적어도 SIP 노드에 의해 수신된 모든 VIA 헤더들에 기초하는 VIA 서명을 생성할 수 있다. 예를 들어, 도 1 및 도 2에 나타낸 INVITE 메시지(500)의 경우, SIP 노드(200)는, SIP 노드(200)에 의해 액세스 가능한 세션 키를 사용하는 것에 의해, SIP 클라이언트(102;Alice)를 표시하는 정보를 포함하는 VIA 헤더에 기초하는 VIA 서명을 제공할 수 있다. 생성된 VIA 서명은 메시지내에 저장되고, 응답 메시지로 전달된 다음, SIP 노드(200)를 통한 메시지의 복귀 트립(return trip)시에 확인될 수 있다. 마찬가지로, SIP 노드(300)는, 수신된 VIA 헤더들에 기초해, 응답이 SIP 노드(300)에 의해 수신될 때 응답을 후속적으로 평가하기 위한 VIA 서명을 생성할 수 있다. VIA 헤더들에 서명하기 위해, SIP 노드(300)는, 액세스 가능한 세션 키를 사용해, Alice의 VIA 헤더(508), SIP 노드(200)의 VIA 헤더(530), 및 SIP 노드(250)의 VIA 헤더(532)에 기초하는 VIA 서명을 생성할 수 있다.

VIA 헤더들 및 다른 헤더 정보의 적당한 임의 조합이 응답 헤더(604)의 라우팅 명령어들을 인증하기 위해 할당될 수 있다는 것을 알 수 있을 것이다. 예를 들어, VIA 서명은, TO 헤더, FROM 헤더, 또는 요청 헤더(504)로부터 응답 헤더(604)로 에코될 수 있는 임의의 다른 헤더 이외에, VIA 헤더들의 일부에 기초할 수 있다. 또한, 요청 헤더(504)에 삽입된 VIA 서명(550)은 생성된 디지털 서명을 표시하는 임의의 데이터 또는 신호일 수 있다. 예를 들어, 저장된 서명(550)은 생성된 서명 블로브(signature blob)에 대한 소정 갯수의 중요 비트들이거나 전반적인 디지털 서명일 수 있다.

INVITE 요청의 프로세싱 동안에 생성된 VIA 서명이 SIP 노드에서의 응답 확인을 위해 존재한다는 것을 보장하기 위해, 생성된 VIA 서명이 INVITE 요청의 에코된 헤더에 삽입될 수 있다. 예를 들어, 서명은, 표준 라우팅 위치 정보 이후의의 URI 파라미터 또는 헤더 파라미터로서, 삽입될 수도 있다. 따라서, 클라이언트 SIP 노드(402)가 SIP 요청의 에코된 헤더들에 기초하여 응답 헤더들(604)을 생성할 때, 생성된 서명은 요청으로부터 응답으로 자동적으로 전달된다. 따라서, 응답을 수신 중인 SIP 노드는 응답 헤더로 전달된 서명을 확인할 수 있다. 이전의 협정에 기초하여 클라이언트 SIP 노드에 의해 에코된 임의의 에코된 헤더 또는 맞춤형 헤 더(custom header)가 SIP 노드에 의한 확인용 서명을 저장하기에 적당할 수도 있다는 것을 알 수 있을 것이다.

도 3에 나타낸 바와 같이, VIA 서명은 서명을 생성 중인 SIP 노드의 VIA 헤더에 삽입될 수 있다. 예를 들어, SIP 노드(300)는 요청(500)으로 수신된 VIA 헤더들(508, 530, 532)에 기초하는 VIA 서명(550)을 생성할 수 있다. SIP 노드(300)는 VIA 서명(550)을 SIP 노드(300)의 VIA 헤더(534)에 삽입할 수 있다. 상기한 바와 같이, 요청 헤더의 VIA 헤더들은 응답 헤더들(604)로 에코백된다. 따라서, SIP 노드(402)가 응답(600)을 형성할 때, SIP 노드(402)는 VIA 헤더들(534)내에 포함된 정보를 SIP 노드(300)의 VIA 헤더(634)로 복사할 수 있다(도 1). 표준 SIP 프로세싱에 따르면, VIA 헤더가 에코될 때, 표준 VIA 정보 뿐만 아니라, VIA 서명(550)과 같은, 헤더 파라미터로서 첨부된 임의의 정보도 복사된다.

수신된 VIA 서명(650)을 확인하기 위해, SIP 노드(300;도 1)는 도 5에 나타낸 수신된 VIA 서명(650)을 추출하여 저장할 수 있다. SIP 노드(300)는 요청에 삽입된 VIA 서명(550)을 생성하는데 사용된 동일한 절차들을 사용해 확인 VIA 서명을 생성할 수 있다. 상술된 VIA 서명(550)의 생성에 따르면, SIP 노드(300)는 수신된 응답(600)의 VIA 헤더들을 식별할 수 있으며 다음의 SIP 노드(300) VIA 헤더(534)에 열거된 모든 VIA 헤더들에 기초하는 확인 VIA 서명(validation VIA signature)을 생성할 수 있다. 이런 식으로, 확인 VIA 서명은, SIP 노드(300)가 요청 메시지(500)의 VIA 서명(550)을 생성할 때 SIP 노드(300)에 의해 공지된 VIA 헤더들에 기초할 수 있다. 따라서, SIP 노드(300)에 대한 확인 VIA 서명은 SIP 노드(250)에 대한 VIA 헤더(632), SIP 노드(200)에 대한 VIA 헤더(630), 및 호출자 SIP 노드(102)에 대한 VIA 헤더(608)에 기초할 수 있다. SIP 노드(300)는 확인 VIA 서명을 수신된 VIA 서명(650)과 비교할 수 있다.

서명들이 매칭되지 않으면, SIP 노드(300)는 SIP 표준에 따른 정상 프로세싱을 계속하여 응답을 응답 헤더들(604)의 VIA 헤더들에서 표시된 후속 SIP 노드로 전달할 수 있다. 서명들이 매칭되지 않으면, SIP 노드(300)는 자신의 프로세싱 스택으로부터 응답(600)을 누락시키고 그리고/또는 프로토콜에 의해 지원된다면 (나타내지 않은) SIP 노드 모니터링 서비스 또는 임의의 적절한 모니터링 에이전트로 오류 메시지를 송신할 수 있다. 서명 적합 및/또는 공격들의 검출을 위한 메시지 프로세싱 성능을 측정하기 위해, SIP 노드(300)는 거절된 메시지 각각에 대해 서명 실패 성능 카운터(signature failure performance counter)를 증가시킬 수 있다. 서명 실패 성능 카운터는 헤더 서명들을 확인하기 위한 SIP 노드의 실패들을 표시하는 임의의 데이터 또는 신호일 수 있다. 예를 들어, 서명 실패 성능 카운터는 소정 시간내의 실패한 서명 확인들의 수를 카운트할 수 있다. 그 다음, 서명 실패 성능 카운터는, 약 1초의 메시지 프로세싱 시간에 약 6회의 실패한 서명 확인들, 약 10회의 실패한 서명 확인들, 또는 약 25회의 실패한 서명 확인들과 같은, 그 시간 동안의 실패한 서명 확인들에 대한 소정 임계치와 비교될 수 있다. 성능 카운터가 임계치를 초과할 경우, SIP 노드는 (이메일 및/또는 페이지에 의한 것을 포함하여) 인간 시스템 관리자에게 및/또는, 예를 들어, 실패한 메시지들을 라우팅하는 네트워크 접속을 누락시키는 것, 네트워크를 폐쇄하는 것, 그리고/또는 메시지 큐들을 비우는 것을 포함하여, 성능 카운터에 기초하여 소정 동작들을 개시할 수 있는 컴퓨터-기반 시스템 관리자에게 통지 또는 경보할 수 있다.

일부의 경우들에서는, 서명이, 라우트상의 각 단계, 예를 들어, 복귀 트립상의 요청 및/또는 응답을 프로세싱 중인 각각의 SIP 노드에서, 생성되고 그리고/또는 확인될 수 있다. 그러나, SIP 노드 서버들에 대한 계산 부하를 감소시키기 위해, 필요할 경우에만 메시지가 확인될 수도 있다.

예를 들어, 요청이 하나의 VIA 헤더, 예를 들어, 요청(500)에서의 Alice의 SIP 노드(102)에 대한 VIA 헤더(508)만을 포함한다면, 노드의 요청에서 서명이 생성되지 않을 수도 있다. 좀더 구체적으로, Alice의 SIP 노드(102)는, 응답이 SIP 노드(102)에 의해 소비될 것이기 때문에, 예를 들어, 더 이상 전달되지 않을 것이기 때문에, 응답(600)의 어떤 라우팅 명령어도 확인할 필요가 없을 수도 있다. 따라서, 요청이 하나의 VIA 헤더만을 포함할 경우에는 VIA 서명이 생성되지 않을 수 있으며, 그에 따라, 수신된 요청이 하나의 VIA 헤더, 예를 들어, 수신 중인 SIP 노드의 VIA 헤더만을 포함할 경우에는 VIA 서명이 확인될 필요가 없을 수도 있다.

부가적인 예로서, 안전하지 못한 접속을 통해 메시지가 수신된다면, 서비스 거부 공격들이 좀더 발생하기 쉬울 수 있다. 메시지의 보안성을 향상시키기 위해, 안전하지 못한 접속을 통해 메시지가 수신될 때, 메시지를 확인할 수 있다. 예를 들어, 다른 서버들로부터 수신된 메시지들은 다른 방법들로 인증될 수 있으므로, 안전하지 못한 접속은 임의의 서버 유형에 대한 임의의 클라이언트 접속을 포함할 수 있다. 또한, 안전하지 못한 접속은 에지 프럭시 서버에 대한 외부 서버 접속을 포함할 수도 있고, 좀더 구체적으로는, 모든 외부 서버 접속들을 포함할 수 있다.

도 1에 나타낸 바와 같이, SIP 노드(200)와 SIP 노드(250)간의 접속들(210, 212)은, 이러한 접속들이 홈 서버와 에지 서버간의 내부 링크들로 간주될 수 있으므로, 안전한 접속들일 수 있다. 서버들은 서버들간의 메시지 트래픽을 인증하는 다른 방법들을 가질 수 있으므로, SIP 노드(200)와 SIP 노드(250)간의 링크들(260, 262)이 안전한 접속들일 수도 있지만, 일부 경우들에서는, 특히 서버 인증의 다른 방법들이 불충분하다고 생각된다면, 이러한 링크들이 안전하지 못한 것으로 간주될 수도 있다. 클라이언트 노드(402)와 SIP 노드(300)간의 링크들(310, 312)은, SIP 메시지들이 클라이언트 SIP 노드와 송신되기 때문에, 안전하지 못한 접속일 수 있다. 따라서, 링크(312)와 같은, 안전하지 못한 접속을 통해 수신된 임의의 메시지 트랙픽은 메시지 무결성 및/또는 인증성을 검증하기 위해 SIP 노드에서 확인될 수 있다.

안전한 링크들을 통해 수신된 응답들은 확인되지 않는 경우라면, 요청이 안전한 링크를 통해 후속 SIP 노드로 전달될 경우, VIA 서명이 생성될 필요는 없다. 예를 들어, SIP 노드들(200 및 250)이 안전하지 못한 접속을 통해 응답(600)을 수신하지 않을 수도 있으므로, 이 노드들은 응답의 라우트를 확인할 필요가 없을 수 있고, 따라서, INVITE 요청의 헤더들(504)내에 VIA 서명을 생성하거나 저장하지 않을 수 있다. 따라서, VIA 서명을 생성하기 전에, SIP 노드는 대응되는 응답의 확인이 필요한지를 판정할 수 있다. 응답이 확인될 필요가 없다면, 예를 들어, 후속 링크가 안전한 접속이라면, VIA 서명은 생성될 필요가 없으며 SIP 요청의 정상적인 프로세싱이 계속될 수 있다. 그러나, 대응되는 응답이 안전하지 못한 접속을 통해 SIP 노드에서 수신된다면, 상술한 바와 같이 VIA 서명이 생성될 수 있다. 마찬가지로, 응답을 수신한 후, SIP 노드는, 응답이 안전하지 못한 접속으로부터 수신되었는지를 먼저 판정할 수 있다. 안전하지 못한 접속으로부터 수신되었다면, VIA 서명이, 존재한다면, 확인될 수 있다. 예를 들어, SIP 노드(300)는, 응답(600)이 안전하지 못한 접속을 통해 수신되었는지를 판정할 수 있다. 도 1에 나타낸 바와 같이, 링크(312)는 안전하지 못한 접속이다. 그 결과, SIP 노드(300)는 응답의 헤더(604)내에서 SIP 노드(300)의 VIA 헤더(634)를 식별할 수 있다. SIP 노드(300)는, 식별된 VIA 헤더(634)내에 서명이 존재하는지를 판정할 수 있다. VIA 서명이 존재하지 않으면, SIP 노드(300)는, 프로토콜에 의해 허용된다면, 오류 메시지를 송신하거나, 그것의 프로세싱 스택으로부터 메시지를 누락시키거나, 서명 실패 성능 카운터를 증가시키거나, 그리고/또는 임의의 적절한 다른 동작을 취할 수 있다. 도 5에 나타낸 바와 같이, VIA 서명(650)이 존재하면, SIP 노드(300)는 상술한 바와 같이 서명을 확인할 수 있다.

VIA 헤더들에 서명하는 것은, 상기한 바와 같이, 응답 헤더(604)의 라우팅 명령어들에 대한 무결성을 확인하는데 도움이 될 수 있다. 그러나, SIP 노드는, 부가적으로 또는 다른 방법으로, 피호출자에 의해 생성된 요청에 대한 라우팅 명령어들의 확인을 원할 수 있다. 따라서, SIP 노드는 다이얼로그-개시 요청의 RECORD-ROUTE 헤더들 중 하나 이상의 적어도 일부에 기초하여 서명을 생성한 다음, 인-다이얼로그 요청(in-dialog request)의 라우팅 명령어들에 대한 무결성을 확인 하기 위해, 피호출자로부터의 후속 요청에서 그 서명을 확인할 수 있다.

피호출자 요청에 의해 이동된 라우트의 무결성을 확인하기 위해, SIP 노드는 요청의 수신된 헤더 필드들에 포함된 RECORD-ROUTE 헤더들 및 CONTACT 헤더의 URI 부분들에 기초하는 피호출자 ROUTE SET 서명을 생성할 수 있다. 하나 이상의 CONTACT 헤더가 존재하면, 피호출자 ROUTE SET 서명은 RECORD-ROUTE 헤더들의 선택된 URI 부분들 및 처음으로 열거된 CONTACT 헤더의 URI 부분에 기초할 수 있다. 보다 구체적으로, 도 1, 도 2, 및 도 4에 나타낸 INVITE 메시지(500)의 경우, SIP 노드(300)는 SIP 노드(250)의 RECORD-ROUTE 헤더(522)에 대한 URI 부분, SIP 노드(200)의 RECORD-ROUTE 헤더(520)에 대한 URI 부분, 및 호출자 Alice의 CONTACT 헤더(518)에 대한 URI 부분에 기초하는 피호출자 ROUTE SET 서명을 제공할 수 있다. 생성된 피호출자 ROUTE SET 서명은, 동일한 다이얼로그에 속하는 피호출자 SIP 노드(402)에 의해 생성되는 임의의 요청들내에서의 저장 및 사용을 위해, 메시지내에 저장되어 피호출자 SIP 노드(402)로 전달될 수 있다. RECORD-ROUTE 헤더들 및 다른 헤더 정보의 적당한 임의 조합이 피호출자 SIP 노드(402)에 의해 생성되는 임의의 후속 요청에 대한 라우팅 명령어들을 인증하기 위해 할당될 수 있다는 것을 알 수 있을 것이다. 요청 헤더(504)에 삽입된 피호출자 ROUTE SET 서명은 서명 블로브의 소정 갯수의 주요 비트들 및 전체적인 디지털 서명을 포함하는, 생성된 서명을 표시하는 임의의 데이터 또는 신호일 수 있다.

요청의 프로세싱 동안에 생성된 피호출자 ROUTE SET 서명이 호출자 SIP 노드(402)에 의해 생성된 후속 요청들에서의 확인을 위해 존재한다는 것을 보장하기 위 해, 생성된 피호출자 ROUTE SET 서명이 요청의 에코된 헤더에 삽입될 수 있다. 따라서, 클라이언트 SIP 노드(402)가 SIP 다이얼로그-개시 요청의 에코된 헤더들에 기초하여 새로운 요청을 생성할 때, 생성된 서명들은 자동적으로 전달된다. 따라서, 요청을 수신 중인 SIP 노드는 요청 헤더로 전달된 서명을 확인할 수 있다. 이전의 규약에 기초하여 클라이언트 SIP 노드에 의해 에코백된 임의의 에코된 헤더 부분 또는 맞춤형 헤더가 SIP 노드에 의한 확인을 위한 피호출자 ROUTE SET 서명을 저장하기에 적합할 수 있다는 것을 알 수 있을 것이다.

도 2 및 도 4에 나타낸 바와 같이, 피호출자 ROUTE SET 서명이, URI 파라미터로서, 서명을 생성 중인 SIP 노드의 RECORD-ROUTE 헤더에 삽입될 수 있다. 예를 들어, SIP 노드(300)는 요청(500)의 RECORD-ROUTE 헤더들(522, 520) 및 CONTACT 헤더(518)에 대한 URI 부분들에 기초하는 피호출자 ROUTE SET 서명(560)을 생성할 수 있다. SIP 노드(300)는 피호출자 ROUTE SET 서명(560)을 URI 파라미터로서 SIP 노드(300)의 RECORD-ROUTE 헤더(524)에 삽입할 수 있다. 상기한 바와 같이, 호출자로부터의 다이얼로그-개시 요청의 RECORD-ROUTE 헤더들(522, 520) 및 CONTACT 헤더(518)에 대한 URI 부분들은, 피호출자 SIP 노드에 의해, 다이얼로그내에서 피호출자에 의해 생성된 임의의 장래 요청들에 대한 라우팅 명령어들을 제공하기 위해, ROUTE 헤더들에 저장 및 에코될 수 있다. 따라서, 도 6에 나타낸 바와 같이, SIP 노드(402)가 요청을 형성할 때, SIP 노드(402)는 표준 SIP 프로세싱하에서 RECORD-ROUTE 헤더(524)의 URI 부분을 SIP 노드(300)의 ROUTE 헤더(724)에 복사할 수 있다. RECORD-ROUTE 헤더의 URI 부분이 에코될 때, 표준 라우트 정보 뿐만 아니라 피호출자 ROUTE SET 서명(560)을 포함하는 임의의 URI 파라미터들도 복사된다.

도 6의 수신된 피호출자 ROUTE SET 서명(760)을 확인하기 위해, SIP 노드(300)는 수신된 피호출자 ROUTE SET 서명(760)을 추출하여 저장할 수 있다. SIP 노드(300)는 다이얼로그-생성 요청, 여기에서는 INVITE에 삽입된 피호출자 ROUTE SET 서명(560)을 생성하는데 사용된 것과 동일한 절차들을 사용해 확인 ROUTE SET 서명을 생성할 수 있다. 상술된 피호출자 ROUTE SET 서명(560)의 생성에 따라, SIP 노드(300)는 수신된 요청(700)의 RECORD-ROUTE 헤더들을 식별하고 수신 중인 SIP 노드의 ROUTE 헤더 이외에 요청에 존재하는 모든 ROUTE 헤더들에 기초하여 확인 ROUTE SET 서명을 생성할 수 있다. 이런 식으로, 확인 ROUTE SET 서명은, SIP 노드(300)가 요청 메시지(500)의 피호출자 ROUTE SET 서명(560)을 생성할 때 SIP 노드(300)에 의해 공지된 RECORD-ROUTE 헤더들 및 CONTACT 헤더에 기초할 수 있다. 예를 들어, 도 1의 설정에서, SIP 노드(300)에 대한 확인 ROUTE SET 서명은 SIP 노드(250)의 ROUTE 헤더(722), SIP 노드(200)의 ROUTE 헤더(720), 및 호출자 SIP 노드(102)를 식별하는 CONTACT 헤더에 기초하는 ROUTE 헤더(718)에 기초할 수 있다. SIP 노드(300)는 확인 ROUTE SET 서명을 수신된 피호출자 ROUTE SET 서명(760)과 비교할 수 있다. 서명들이 매칭되지 않으면, SIP 노드(300)는 프로토콜에 의해 허용된다면 오류 메시지를 송신하고, 자신의 프로세싱 스택으로부터 요청(700)을 삭제하며, 서명 실패 성능 카운터를 증가시키고, 그리고/또는 임의의 적절한 다른 동작을 취할 수 있다. 서명들이 매칭되면, SIP 노드(300)는 SIP 표준에 따른 정상 프로세싱을 계속하여 요청을 응답 헤더들(704)의 ROUTE 헤더들에서 표시된 후속 SIP 노드로 전달할 수 있다.

일부의 경우들에서는, 피호출자 ROUTE SET 서명이, 라우트의 각 단계에서, 예를 들어, 요청을 프로세싱 중인 각각의 SIP 노드에서, 생성 및/또는 확인될 수 있다. 그러나, SIP 노드 서버들의 계산 부하를 감소시키기 위해, 필요한 경우에만 요청이 확인될 수도 있다.

예를 들어, 요청이 어떤 RECORD-ROUTE 헤더도 포함하지 않으면, 예를 들어, 현재의 프로세싱 중인 SIP 노드조차도 RECORD-ROUTE 헤더를 부가하지 않았다면, 피호출자 ROUTE SET 서명은 생성될 수 없다. 좀더 구체적으로, 요청을 프로세싱 중인 SIP 노드가 피호출자와 호출자간의 추가적인 통신을 위해 "루프내에(in-the-loop)" 남아 있을 것을 요청하지 않았다면, 그 SIP 노드는 장래의 수신 메시지에서 라우팅 명령어들의 확인을 원하지 않을 수도 있다.

추가적인 예에서, 요청이 RECORD-ROUTE 헤더들을 포함하긴 하지만 하나의 CONTACT 헤더도 갖지 않으면, SIP 노드는, 그러한 RECORD-ROUTE 헤더들을 에코 중인 어떤 응답 또는 요청의 확인을 원하지 않을 수도 있다. 이것은, 어떤 유형들의 ACK 및 CANCEL SIP 메시지들을 포함하는 일부 경우들에서 발생할 수 있다. 좀더 구체적으로, 수신된 요청이 하나 이상의 RECORD-ROUTE 헤더 및 0개의 CONTACT 헤더를 포함한다면, 피호출자 ROUTE SET 서명은 생성될 수 없으며 메시지의 정상 프로세싱이 계속될 것이다.

추가적인 예에서는, 안전하지 못한 링크들로부터의 요청들이 서비스 거부 공격들의 소스들일 가능성이 많으므로, 메시지가 안전하지 못한 접속을 통해 수신될 때 확인될 수 있다. 안전한 링크들을 통해 수신된 피호출자로부터의 요청들이 확인되지 않는다면, 호출자로부터의 다이얼로그-개시 요청이 안전한 링크를 통해 후속 SIP 노드로 전달될 때, 피호출자 ROUTE SET 서명(560)은 생성될 필요가 없다. 예를 들어, 도 1에 나타낸 바와 같이, SIP 노드(200)는 안전한 접속을 통해 요청(700)을 수신할 것이며, 다시 말해, SIP 노드는 안전하지 못한 접속을 통해 요청(700)을 수신하지 않을 것이다. 따라서, 피호출자로부터의 임의 요청들에 대한 라우트를 확인할 필요가 없으므로, 이 노드는 INVITE 요청의 헤더들(504)내에 피호출자 ROUTE SET 서명을 생성하거나 삽입하지 않을 것이다. 따라서, 피호출자 ROUTE SET 서명을 생성하기 전에, SIP 노드는, 임의의 피호출자 요청에 대한 확인이 필요한지를 판정할 수 있다. 피호출자 요청을 확인하지 않는다면, 예를 들어, 현재 요청이 안전한 접속을 통해 수신된다면, 피호출자 ROUTE SET 서명은 생성될 필요가 없으며 SIP 요청의 정상 프로세싱이 계속될 수 있다. 그러나, 피호출자 요청이 안전하지 못한 접속을 통해 SIP 노드에서 수신된다면, 상술된 바와 같이, 피호출자 ROUTE SET 서명이 생성될 수 있다. 마찬가지로, 피호출자 ROUTE SET 서명을 확인하는 동안, 프로세싱 중인 SIP 노드는 먼저 피호출자로부터의 요청이 안전하지 못한 접속을 통해 수신되었는지를 판정할 수 있다. 안전하지 못한 접속을 통해 수신되었다면, 피호출자 ROUTE SET 서명이, 존재한다면, 확인될 수 있다. 예를 들어, SIP 노드(300)는, 요청이 안전하지 못한 접속을 통해 수신되었는지를 판정할 수 있다. 도 1에 나타낸 바와 같이, 링크(312)는 안전하지 못한 접속이다. 따라서, SIP 노드(300)는 도 6에 나타낸 요청(700)의 헤더(704)내에서 SIP 노드(300)의 ROUTE 헤더(724)를 식별할 수 있다. SIP 노드(300)는, 식별된 ROUTE 헤더(724)내에 서명이 존재하는지를 판정할 수 있고, 존재한다면 그 서명을 확인할 수 있다.

SIP 노드는, 추가적으로 또는 다른 방법으로, 다이얼로그-개시 요청에 후속하여 호출자에 의해 생성된 인-다이얼로그 요청에 대한 라우팅 명령어들의 확인을 원할 수 있다. 따라서, SIP 노드는 다이얼로그-개시 요청에 대한 응답의 하나 이상의 RECORD-ROUTE 헤더들의 적어도 일부에 기초하는 서명을 생성한 다음, 요청의 라우팅 명령어들에 대한 무결성을 보장하기 위해 호출자로부터의 후속 요청에서 그 서명을 확인할 수 있다.

호출자 요청에 의해 이동될 라우트의 무결성을 보장하기 위해, SIP 노드는 수신된 응답의 헤더 필드들에 포함된 RECORD-ROUTE 헤더들 및 CONTACT 헤더의 URI 부분들에 기초하는 호출자 ROUTE SET 서명을 생성할 수 있다. 하나 이상의 CONTACT 헤더가 존재하면, 호출자 ROUTE SET 서명은 RECORD-ROTE 헤더들의 선택된 URI 부분들 및 처음으로 열거된 CONTACT 헤더의 URI 부분에 기초할 수 있다. 보다 구체적으로, 도 1 및 도 5에 나타낸 응답 메시지(600)의 경우, SIP 노드(200)는 SIP 노드(250)의 RECORD-ROUTE 헤더(622)에 대한 URI 부분, SIP 노드(300)의 RECORD-ROUTE 헤더(624)에 대한 URI 부분, 및 피호출자 블로브의 CONTACT 헤더(618)에 대한 URI 부분에 기초하는 호출자 ROUTE SET 서명을 제공할 수 있다. 생성된 호출자 ROUTE SET 서명은 메시지내에 저장되어, 동일한 다이얼로그에 속하는 호출자 SIP 노드(102)에 의해 생성되는 임의의 요청들내에서의 저장 및 사용을 위해, 호출자 SIP 노드(102)로 전달될 수 있다. RECORD-ROUTE 헤더들 및 다른 헤더 정보의 적당한 임의 조합이 호출자 SIP 노드(102)에 의해 생성된 임의의 후속 요청에서의 라우팅 명령어들을 인증하기 위해 할당될 수 있다는 것을 알 수 있을 것이다. 응답 헤더(604)에 삽입된 호출자 ROUTE SET 서명은 서명 블로브에 대한 소정 갯수의 주요 비트들 및 전체적인 디지털 서명을 포함하는 생성된 디지털 서명을 표시하는 임의의 데이터 또는 신호일 수 있다.

응답의 프로세싱 동안에 생성된 호출자 ROUTE SET 서명이 호출자 SIP 노드(102)에 의해 생성된 후속 요청들에서의 확인을 위해 존재한다는 것을 보장하기 위해, 생성된 호출자 ROUTE SET 서명이 응답의 에코된 헤더에 URI 파라미터로서 삽입될 수 있다. 따라서, 클라이언트 SIP 노드(102)가 SIP 응답으로부터의 에코된 헤더들에 기초하는 새로운 요청을 생성할 때, 생성된 서명들은 자동적으로 전달된다. 따라서, 요청을 수신 중인 SIP 노드는 요청 헤더로 전달된 서명을 확인할 수 있다. 이전의 규약에 기초하는 클라이언트 SIP 노드에 의해 에코된 임의의 에코된 헤더 부분 또는 맞춤형 헤더가 SIP 노드에 의한 확인을 위한 호출자 ROUTE SET 서명을 저장하기에 적합할 수 있다는 것을 알 수 있을 것이다.

도 5에 나타낸 바와 같이, 호출자 ROUTE SET 서명이 서명을 생성 중인 SIP 노드의 RECORD-ROUTE 헤더에 삽입될 수 있다. 예를 들어, SIP 노드(200)는 응답(600)의 RECORD-ROUTE 헤더들(622, 624) 및 CONTACT 헤더(618)에 대한 URI 부분들에 기초하여 호출자 ROUTE SET 서명(660)을 생성할 수 있다. SIP 노드(200)는 호출자 ROUTE SET 서명(660)을 SIP 노드(200)의 RECORD-ROUTE 헤더(620)에 삽입할 수 있다. 상기한 바와 같이, 다이얼로그-개시 요청에 대한 응답의 RECORD-ROUTE 헤더 들 및 CONTACT 헤더에 대한 URI 부분들은 호출자 SIP 노드에 의해, 다이얼로그내에서 호출자에 의해 생성된 임의의 장래 요청들에 대한 라우팅 명령어들을 제공하기 위한 ROUTE 헤더들에 저장 및 에코될 수 있다. 따라서, 도 7의 예시적 요청(800)에 나타낸 바와 같이, SIP 노드(102)가 그 다이얼로그의 후속 요청을 형성할 때, SIP 노드(102)는 표준 SIP 프로세싱하에서 RECORD-ROUTE 헤더(620)의 URI 부분을 SIP 노드(200)의 ROUTE 헤더(820)에 복사할 수 있다. RECORD-ROUTE 헤더의 URI 부분이 에코될 때, 표준 라우트 정보 뿐만 아니라 호출자 ROUTE SET 서명(660)을 포함하는 임의의 URI 파라미터들도 복사된다.

도 7의 수신된 호출자 ROUTE SET 서명(860)을 확인하기 위해, SIP 노드(200)는 수신된 호출자 ROUTE SET 서명(860)을 추출하여 저장할 수 있다. SIP 노드(200)는 다이얼로그-생성 요청에 삽입된 호출자 ROUTE SET 서명(660)을 생성하는데 사용된 것과 동일한 절차들을 사용해 확인 ROUTE SET 서명을 생성할 수 있다. 상술된 호출자 ROUTE SET 서명(660)의 생성에 따라, SIP 노드(200)는 수신된 요청(800)의 RECORD-ROUTE 헤더들을 식별하고 수신 중인 SIP 노드의 ROUTE 헤더 이외에 요청에 존재하는 모든 ROUTE 헤더들에 기초하는 확인 ROUTE SET 서명을 생성할 수 있다. 이런 식으로, 확인 ROUTE SET 서명은, SIP 노드(200)가 응답 메시지(600)의 호출자 ROUTE SET 서명(660)을 생성할 때 SIP 노드(200)에 의해 공지된 RECORD-ROUTE 헤더들 및 CONTACT 헤더에 기초할 수 있다. 따라서, SIP 노드(200)에 대한 확인 ROUTE SET 서명은 SIP 노드(250)의 ROUTE 헤더(822), SIP 노드(300)의 ROUTE 헤더(824), 및 피호출자 SIP 노드(402)를 식별하는 CONTACT 헤더에 기초하는 ROUTE 헤더(818)에 기초할 수 있다. SIP 노드(200)는 확인 ROUTE SET 서명을 수신된 호출자 ROUTE SET 서명(860)과 비교할 수 있다. 서명들이 매칭되지 않으면, SIP 노드(200)는 프로토콜에 의해 지원된다면 오류 메시지를 송신하고, 자신의 프로세싱 스택으로부터 요청(800)을 삭제하며, 서명 실패 성능 카운터를 증가시키고, 그리고/또는 임의의 적절한 다른 동작을 취할 수 있다. 서명들이 매칭되면, SIP 노드(200)는 SIP 표준에 따른 정상 프로세싱을 계속하여 요청을 요청 헤더들(804)의 ROUTE 헤더들에서 표시된 후속 SIP 노드로 전달할 수 있다.

일부의 경우들에서는, 호출자 ROUTE SET 서명이 라우트의 각 단계에서, 예를 들어, 응답 및/또는 요청을 프로세싱 중인 각각의 SIP 노드에서, 생성 및/또는 확인될 수 있다. 그러나, VIA 서명 및 요청에 삽입된 호출자 ROUTE SET 서명과 관련하여 상술한 바와 같이, 필요한 경우에만 호출자 ROUTE SET 서명 확인 요청하는 것에 의해, SIP 노드 서버들에 대한 계산 부하가 감소될 수 있다.

예를 들어, 응답이 어떤 RECORD-ROUTE 헤더도 포함하지 않으면, 예를 들어, 현재의 SIP 노드조차도 RECORD-ROUTE 헤더를 부가하지 않았다면, 호출자 ROUTE SET 서명은 생성될 수 없다. 좀더 구체적으로, 응답을 프로세싱 중인 SIP 노드가 호출자와 피호출자간의 추가적인 통신을 위해 "루프내에" 남아 있을 것을 요청하지 않았다면, 그 SIP 노드는 추가적인 메시지들의 라우팅 명령어들의 확인을 원하지 않을 수도 있다.

추가적인 예에서, 응답이 RECORD-ROUTE 헤더들을 포함하긴 하지만 하나의 CONTACT 헤더도 갖지 않으면, SIP 노드는 그러한 RECORD-ROUTE 헤더들을 에코 중인 어떤 응답 또는 요청의 확인도 원하지 않을 수 있다. 좀더 구체적으로, 수신된 응답이 하나 이상의 RECORD-ROUTE 헤더 및 0개의 CONTACT 헤더를 포함한다면, 호출자 ROUTE SET 서명은 생성될 수 없으며 정상 프로세싱이 계속될 것이다.

추가적인 예에서는, 호출자 요청의 ROUTE SET 헤더들이 안전하지 못한 접속을 통해 수신될 경우에만, 호출자 요청의 ROUTE SET 헤더들을 확인할 수 있다. 안전한 링크들을 통해 수신된 요청들이 확인되지 않는다면, 응답이 안전한 링크를 통해 후속 SIP 노드로 전달될 때, 호출자 ROUTE SET 서명(660)은 생성될 필요가 없다. 마찬가지로, 호출자로부터 요청을 수신한 후, 안전한 접속을 통해 수신되었다면, ROUTE SET 서명은 확인될 필요가 없다.

상기한 바와 같이, RECORD-ROUTE 헤더들은, 후속 요청들을 라우팅하는데 사용되는 피호출자 및 호출자 ROUTE SET 헤더들을 생성하기 위해, 다이얼로그-개시 요청 및 그것의 대응되는 응답에 포함된다. 따라서, 일부 경우들에서, SIP 노드는 RECORD-ROUTE 헤더들의 무결성을 보장하기 위해, 다이얼로그-개시 요청에 응답하여 RECORD-ROUTE 헤더들을 확인할 수 있다. 예를 들어, 첨부 노드는 요청의 RECORD-ROUTE 헤더들을 위조할 수 있고, 그에 따라, 후속 SIP 노드는 날조된 RECORD-ROUTE 헤더들을 통해 서명할 수 있으므로, 유효한 ROUTE SET 서명을 갖지만 날조된 라우팅 정보에 기초하는 ROUTE 헤더를 발생시킬 수 있다. 따라서, SIP 노드는 요청의 RECORD-ROUTE 헤더들 중 하나 이상의 적어도 일부에 기초하여 서명을 생성한 다음, 메시지의 RECORD-ROUTE 헤더들의 무결성을 보장하기 위해, 피호출자로부터의 응답에서 그 서명을 확인할 수 있다.

RECORD-ROUTE 헤더들의 세트에 대한 무결성을 보장하기 위해, SIP 노드는 수신된 요청의 헤더 필드들에 포함된 RECORD-ROUTE 헤더들의 URI 부분들에 기초하는 RECORD-ROUTE 서명을 생성할 수 있다. 보다 구체적으로, 도 1, 도 2, 및 도 4에 나타낸 INVITE 메시지(500)에 대해, SIP 노드(300)는 SIP 노드(250)의 RECORD-ROUTE 헤더(522)에 대한 URI 부분들 및 SIP 노드(200)의 RECORD-ROUTE 헤더(520)에 대한 URI 부분들에 기초하는 RECORD-ROUTE 서명(570)을 제공할 수 있다. 상술된 피호출자 ROUTE SET 서명과 달리, SIP 표준들에 따르면, 피호출자는 응답의 CONTACT 헤더(518)를 에코하지 않으므로, RECORD-ROUTE 서명(570)은 CONTACT 헤더를 포함하지 않는다. 생성된 RECORD-ROUTE 서명(570)은 메시지내에 저장되어 응답 메시지로 전달되고, SIP 노드를 통해 응답이 프로세싱될 때 확인될 수 있다. RECORD-ROUTE 헤더들 및 다른 헤더 정보의 적당한 임의 조합이 피호출자 SIP 노드(402)에 의해 생성된 응답의 라우팅 명령어들을 인증하기 위해 서명될 수 있다는 것을 알 수 있을 것이다. 요청 헤더(504)에 삽입된 RECORD-ROUTE 서명(570)은 서명 블로브의 소정 갯수의 주요 비트들 및 전체 디지털 서명 자체를 포함하는 생성된 디지털 서명을 표시하는 임의의 데이터 또는 신호일 수 있다.

요청의 프로세싱 동안에 생성된 RECORD-ROUTE 서명이 피호출자 SIP 노드(402)에 의해 생성된 응답에 확인을 위해 존재한다는 것을 보장하기 위해, 생성된 RECORD-ROUTE 서명(570)은 헤더 파라미터 또는 URI 파라미터로서 요청의 에코된 헤더에 삽입될 수 있다. 따라서, 클라이언트 SIP 노드(402)가 SIP 요청으로부터의 에코된 헤더들에 기초하여 응답을 생성할 때, 생성된 서명들은 요청으로부터 응답 으로 자동적으로 전달된다. 따라서, 응답을 수신 중인 SIP 노드는 응답 헤더로 전달된 서명을 확인할 수 있다. 이전의 규약에 기초하는 클라이언트 SIP 노드에 의해 에코된 임의의 에코된 헤더 또는 맞춤형 헤더가 SIP 노드에 의한 확인을 위해 RECORD-ROUTE 서명을 저장하기에 적당할 수 있다는 것을 알 수 있을 것이다.

도 4에 나타낸 바와 같이, RECORD-ROUTE 서명이 서명을 생성 중인 SIP 노드의 RECORD-ROUTE 헤더에 삽입될 수 있다. 예를 들어, SIP 노드(300)는 RECORD-ROUTE 서명(570)을 헤더 파라미터로서 SIP 노드(300)의 RECORD-ROUTE 헤더(524)에 삽입할 수 있다. 상기한 바와 같이, RECORD-ROUTE 헤더들은 응답 헤더들(604)로 에코백된다. 따라서, SIP 노드(402)가, 도 5에 나타낸 응답(600)과 같은, 응답을 형성할 때, SIP 노드(402)는 표준 SIP 프로세싱에 따라 RECORD-ROUTE 헤더(524)를 SIP 노드(200)의 RECORD-ROUTE 헤더(624)로 복사할 수 있다. RECORD-ROUTE 헤더가 에코될 때, 표준 정보 뿐만 아니라 RECORD-ROUTE 서명(570)을 포함하는 임의의 헤더 파라미터들도 복사된다.

도 5의 수신된 RECORD-ROUTE 서명(670)을 확인하기 위해, SIP 노드(300)는 수신된 RECORD-ROUTE 서명(670)을 추출하여 저장할 수 있다. SIP 노드(300)는 대응되는 요청에 삽입된 RECORD-ROUTE 서명(570)을 생성하는데 사용된 것과 동일한 절차들을 사용해 확인 RECORD-ROUTE 서명을 생성할 수 있다. 상술된 RECORD-ROUTE 서명(570)의 생성에 따르면, SIP 노드(300)는 SIP 노드(250)의 RECORD-ROUTE 헤더(622)에 대한 URI 부분 및 SIP 노드(200)의 RECORD-ROUTE 헤더(620)에 대한 URI 부분에 기초하는 확인 RECORD-ROUTE 서명을 생성할 수 있다. SIP 노드(300)는 확인 RECORD-ROUTE 서명을 수신된 RECORD-ROUTE 서명(670)과 비교할 수 있다. 서명들이 매칭되지 않으면, SIP 노드(300)는 프로토콜에 의해 지원된다면 오류 메시지를 송신하고, 자신의 프로세싱 스택으로부터 응답(600)을 삭제하며, 그리고/또는 서명 실패 성능 카운터를 증가시킬 수 있다. 서명들이 매칭되면, SIP 노드(300)는 SIP 표준에 따른 정상 프로세싱을 계속할 수 있으며 응답을 응답 헤더들(604)의 VIA 헤더들에서 표시되는 후속 SIP 노드로 전달할 수 있다.

일부의 경우들에서는, 응답의 RECORD-ROUTE 헤더들이, 라우트의 각 단계에서, 예를 들어, 응답을 프로세싱 중인 각각의 SIP 노드에서, 확인될 수 있다. 그러나, SIP 노드들에 대한 계산 부하를 감소시키기 위해, 응답은, VIA 서명(650)을 참조하여 상술된 바와 유사하게, 필요한 경우에만 확인될 수도 있다. 예를 들어, 요청이 어떤 RECORD-ROUTE 헤더들도 포함하지 않으면, RECORD-ROUTE 서명은 생성되지 않을 수도 있다. 추가적인 예에서, 후속 SIP 노드로의 접속이 안전한 접속이라면, RECORD-ROUTE 서명을 생성되지 않을 수도 있다. 통신 시스템들에 대한 부하를 감소시키기 위해, SIP 노드는, 확인 이후에 그리고 응답을 후속 SIP 노드로 전달하기 전에, RECORD-ROUTE 헤더로부터 RECORD-ROUTE 서명을 삭제할 수 있다.

SIP 메시지들의 헤더들 중 적어도 일부에 기초하는 서명을 생성하기 위해, 확인 및 검증 능력들을 요하는 SIP 노드는, 암호화, 복호화, 시그널링, 및/또는 검증을 포함하는 소정 암호화 펑크션들을 수행하기 위해 CPU상에서 실행되는 암호화 프로그램을 포함할 수 있다. 일례로서, 암호화 프로그램은, 서명을 계산할 때 랜덤 데이터를 부가하는데 사용되거나 암호화/복호화 목적들에 사용되는 대칭 키들과 같은, 암호화 키들을 생성하고 파괴할 수 있다. 다른 방법으로, 암호화 프로그램은 비대칭(공개/비밀) 키 쌍으로의 액세스를 가질 수 있다. 통상적인 비대칭 키 쌍에서, 공개는 정보를 암호화하는데 사용될 수 있고 대응되는 비밀 키는 정보를 복호화하는데 사용될 수 있다. 비밀 키를 사용해 디지털 서명이 생성될 수 있으며 그 서명은 공개 키를 사용해 인증될 수 있다. 단독으로 또는 조합으로, 공격에 대한 회복성(resilience to attack), 상대적인 속도, 및 관련 서명의 생성을 위한 계산 부하와 같은 많은 팩터들에 기초하는 MD5, salt, HMAC, SHA1, 및 RSA를 포함하여, 임의의 일방적인 해싱 메커니즘이 SIP 헤더들에 기초하는 서명들을 생성하기에 적당할 수 있다는 것을 알 수 있어야 한다. 전체적인 서명 블로브, 서명 블로브의 일부, 또는 임의의 인코딩 방식을 사용하는 서명 블로브의 인코딩된 버전이 VIA, ROUTE SET, 및/또는 RECORD-ROUTE 서명으로서 삽입될 수 있다는 것도 알 수 있을 것이다. 일례에서, 서명은 SIP 메시지 헤더들 및, 난수 및/또는 세션 키를 포함하는, 임의의 다른 정보의 선택된 부분에 대한 16 바이트의 일방적인 MD5 해시(16 byte one way MD5 hash)일 수 있다. SIP 헤더들에 기초하는 서명은, 서명 생성과 확인 사이에서 순서가 일관되게 유지되기만 한다면, 특정한 임의 순서의 관련 헤더들로 생성될 수 있다.

동일한 SIP 노드에 의해 프로세싱되는 VIA 서명, ROUTE SET 서명들, 및 RECORD-ROUTE 서명은 동일한 세션 키에 의해 각각 생성될 수 있다. 다른 방법으로, 상이한 회복성과 속도의 키들이 각각의 서명 또는 서명들의 임의 조합에 대해 사용될 수도 있다. 예를 들어, VIA 서명 및/또는 RECORD-ROUTE 서명은 통상적으로 비교적 빨리, 예를 들어, 대응되는 응답에서 확인될 것이므로, VIA 서명들을 생성하는데 사용되는 VIA 키는 비교적 작은 계산 부하를 가진 비교적 경량 키/암호화 솔루션(fairly lightweight key/cryptographic solution)일 수 있다. 그러나, ROUTE SET 헤더들은 전체 다이얼로그에 걸쳐 확인이 계속될 수 있으므로, ROUTE SET 키는 경량 키/암호화 솔루션보다 공격에 덜 취약한 중량 키/암호화 솔루션(heavy weight key/cryptographic solution)일 수 있다.

서명을 생성하기 위한 세션 키 자체가 특정한 SIP 노드에 의한 소정의 시간 프레임내에서 프로세싱되는 모든 다이얼로그 요청들 및/또는 응답들에 대해 생성되고 사용될 수 있다. 다른 방법으로, 각각의 다이얼로그에 대해, 그 SIP 노드에 의해 사용되는 다른 다이얼로그 세션 키들과 동일하거나 상이할 수 있는 그리고 다른 SIP 노드들에 의해 사용되는 다이얼로그 세션 키들과 동일하거나 상이할 수 있는, 특정한 세션 키가 발행될 수도 있다. 세션 키들은 소정 시간 후에, 다이얼로그의 끝에, 그리고/또는 키 및/또는 헤더 손상에 대한 표시를 수신했을 때, 암호화 프로그램에 의해 파괴될 수 있다.

각각의 SIP 노드는, VIA 서명들을 생성하기 위한 VIA 키, ROUTE SET 헤더들을 생성하기 위한 ROUTE 키, 및 RECORD-ROUTE 서명들을 생성하기 위한 RECORD-ROUTE 키와 같은, 자신만의 세션 키를 생성할 수 있다. 다른 방법으로, 세션 키는, 공개/비밀 키 쌍에 대한 인증서를 통하는 것과 같이, 헤더의 각 유형이 동일한 키를 사용해 서명되도록, SIP 노드들 각각에 의해 액세스될 수 있다.

서명들을 생성하는데 사용되는 세션 키들의 취약성을 감소시키기 위해, 키들 은 때때로 리프레시(refresh)될 수 있다. 예를 들어, 세션 키는 매 4시간마다 리프레시될 수 있다. 그러나, 세션 키가 리프레시된 이후라 하더라도 다이얼로그들이 계속해서 허용된다는 것을 보장하기 위해, SIP 노드의 암호화 프로그램은 이전의 세션 키들을 저장하고 유지할 수 있다. 저장된 키들은, RECORD-ROUTE 및 ROUTE SET 키들에 대한 약 5분에서 약 24시간의 범위 이내 그리고 VIA 키들에 대한 약 5분에서 약 30분의 범위 이내와 같은, 소정 시간 동안 저장될 수 있다. 추가적으로 또는 다른 방법으로, 세션 키들은, 그 키를 사용해 서명된 모든 메시지들이 확인될 때까지, 저장될 수 있다. 서명을 확인하기 위한 정확한 키가 액세스된다는 것을 보장하기 위해, 암호화 프로그램은 서명에 키 식별자를 삽입하고 그리고/또는 에코된 SIP 헤더의 부가적인 파라미터로서 키 식별자를 첨부할 수 있다.

일부의 경우들에서, SIP 메시지들을 프로세싱 중인 SIP 노드에는 서버 풀이 제공될 수 있다. 그러나, 서명을 확인하는 동일 서버가 서명을 생성한 것과 동일할 것이라는 보장은 없다. 따라서, 서버 풀내의 서버들은, 풀내의 다른 서버들이 메시지를 프로세싱하는데 사용된다면 그 서명들을 확인할 수 있도록 하기 위해, 서명들을 생성하는데 사용된 키를 통신해야 할 수 있다. 일례에서, 서버들은 키를 서로 송신하거나 인증서 또는 다른 적당한 방법을 통해 키 서비스로부터의 적당한 키에 액세스할 수 있다. 그러나, 서버 풀내의 서버들은 일반적으로 손상을 감소시키기 위해 그들간의 통신을 최소화하며 키 서비스에 액세스하는 것은 메시지 프로세싱 시간을 증가시킬 수 있다. 따라서, 서명을 생성 중인 서버로부터 서명을 확인 중인 서버로 세션 키를 안전하게 전달하기 위해, 서명(들)을 생성 중인 서버는 암호화되고 서명된 세션 키를 서명을 가진 메시지의 에코된 헤더에 첨부할 수 있다.

예를 들어, SIP 노드(300)에는 도 1에 점선으로 도시된 제 1 서버(300A) 및 제 2 서버(300B)를 포함하는 서버 풀이 제공될 수 있다. 일부의 경우들에서, 요청(500)은 SIP 노드(300A)를 통해 라우팅될 수 있고 피호출자로부터의 인-다이얼로그 후속 요청들(700)은 SIP 노드(300B)를 통해 라우팅될 수 있다. 따라서, 인-다이얼로그 요청에서 ROUTE SET 서명(760)을 검증하기 위해, SIP 노드(300B)는, SIP 노드(300A)에 의해 ROUTE SET 서명(560)을 생성하는데 사용된 키를 알아야 한다. 도 4의 예시적인 요청 RECORD-ROUTE 헤더들에 도시된 바와 같이, RECORD-ROUTE 헤더(534)와 같은, RECORD-ROUTE 헤더는 표준 SIP 프로세싱하에서의 통상적인 네트워크 위치 정보, SIP 노드(300A)에 의해 생성된 ROUTE SET 서명(560), 및 SIP 노드(300A)에 의해 서명(560)을 생성하는데 사용된 ROUTE SET 키(580)를 표현하는 데이터를 포함할 수 있다.

그러나, 다른 SIP 노드들이 메시지 헤더의 ROUTE SET 키(580)에 로의 액세스를 갖지 않는다는 것을 보장하기 위해, SIP 노드(300A)는 ROUTE SET 키를 공개 키로 암호화할 수 있다. 따라서, 그 암호화의 무결성을 확인하기 위해, SIP 노드는 암호화된 ROUTE SET 키에 비밀 키로 서명할 수 있다. 그 다음, SIP 노드(300A)는, 안전한 세션 키를 세션 키를 암호화하고 세션 키에 서명하는데 사용된 공개/비밀 키 쌍으로의 액세스를 가진 서버로 분배하기 위해, 암호화되고 서명된 세션 키를, RECORD-ROUTE 헤더의 URI 파라미터와 같은, 에코된 헤더에 삽입할 수 있다. 암호 화된 세션 키 및 서명된 세션 키는 단일 파라미터로서 또는 다수 파라미터들로서 삽입될 수 있다.

일부의 경우들에서는, 메시지 헤더들의 세션 키를 안전하게 하기 위해 2쌍의 공개/비밀 키 쌍들을 이용하는 것이 바람직할 수도 있다. 예를 들어, 제 1 공개/비밀 키 쌍 및 제 2 공개/비밀 키 쌍이 인증서 시스템을 통해 설치되거나 액세스될 수 있다. 서명을 생성 중인 SIP 노드에서, 제 1 공개/비밀 키 쌍의 제 1 공개 키는 세션 키를 암호화하는데 사용될 수 있고 제 2 공개/비밀 키 쌍의 제 2 비밀 키는 세션 키에 서명하는데 사용될 수 있다. 이런 식으로, 양자의 공개/비밀 키 쌍들로의 액세스를 가진 수신 중인 SIP 노드는 제 2 공개/비밀 키 쌍의 제 2 공개 키를 서명의 유효성을 확인하는데 사용할 수 있고 제 1 공개/비밀 키 쌍의 제 1 비밀 키는 세션 키를 복호화하는데 사용할 수 있다.

공개/비밀 키 쌍에 의한 세션 키의 암호화 및 서명은 계산 집약적일 수 있다. 따라서, SIP 노드에 대한 부하를 감소시키기 위해, 서명된 암호화 세션 키는 복호화된 키 정보, 키 생성의 날짜/시간 스탬프, 키 만료의 날짜/시간, 및/또는 임의의 다른 정보와 관련된 키 데이터베이스에 저장될 수 있다. 이런 식으로, 암호화/서명은 각각의 전송 이전에 계산될 필요가 없을 수도 있다.

예를 들어, 도 6에 나타낸 바와 같이, SIP 노드(300B)가 ROUTE SET 서명(760)을 포함하는 ROUTE SET 헤더(724)를 가진 요청을 수신할 때, SIP 노드(300B)는, 어떤 ROUTE SET 키가 서명(560)을 생성하는데 사용되었는지를 식별하기 위해 ROUTE SET 서명을 조사할 수 있다. 일부의 경우들에서, SIP 노드(300B)는, 저장된 키들의 데이터베이스가 식별된 ROUTE SET 키(580)를 거기에 저장하고 있는지를 확인하기 위해, 저장된 키들의 데이터베이스에 액세스할 수 있다. ROUTE SET 키가 저장되어 있지 않으면, SIP 노드(300B)는 ROUTE SET 헤더로부터 ROUTE SET 키를 판정하기 위해 공개/비밀 키 쌍에 액세스할 수 있다. 보다 구체적으로, SIP 노드(300B)는 공개/비밀 키 쌍에 액세스하기 위해 인증서 서비스를 사용하거나 데이터베이스로부터 또는 적당한 임의 방법 또는 프로세스를 통해 공개/비밀 키 쌍을 검색할 수 있다. 공개 키를 사용해, SIP 노드(300B)는 세션 키의 서명을 인증할 수 있다. 또한, SIP 노드(300B)는 ROUTE SET 키(580)를 복호화하는데 비밀 키를 사용한 다음, 그렇게 복호화된 키를 확인 ROUTE SET 서명을 생성하는데 사용할 수 있다. 유사한 방식으로, VIA 헤더들 및 RECORD-ROUTE 헤더들을 생성하는데 사용된 세션 키들은 에코된 헤더에 삽입될 수 있는데, 보다 구체적으로, 그 세션 키에 의해 생성된 서명을 포함하는 에코된 헤더에 삽입될 수 있다.

세션 키는 단독으로 암호화될 수 있거나 공개 키와의 암호화 전에 다른 정보가 세션 키에 포함될 수 있다. 마찬가지로, 암호화된 세션 키는 단독으로 서명되거나, 다른 방법으로, 암호화된 세션 키 블로브에, 전체가 비밀 키로 서명되기 전에 암호화되거나 복호화될 수 있는 다른 정보가 첨부될 수 있다. 이런 식으로, 키 식별자, 세션 키 만료 날짜, 또는 임의의 다른 정보와 같은, 다른 정보가 암호화된/서명된 세션 키와 함께 전송될 수 있다. 추가적인 정보가 암호화된/서명된 세션 키에 첨부될 수 있으며 동일한 공개/비밀 키 쌍 또는 다른 적당한 암호화 프로세스를 사용해 암호화되거나 그리고/또는 서명될 수 있다.

일부의 경우들에서, 서명되고 암호화된 세션 키를 수신 중인 SIP 노드는 세션 키의 만료 시간 및/또는 날짜를 확인할 수 있다. 이러한 관점에서, SIP 노드(300A)는 세션 키 생성의 날짜 및/또는 시간 스탬프와 함께 세션 키를 암호화하고 세션 키에 서명할 수 있다. SIP 노드(300B)가 다이얼로그내의 요청을 수신할 때, SIP 노드(300B)는 세션 키의 서명 및 날짜/시간 스탬프를 인증할 수 있고 이들을 상기한 바와 같이 복호화할 수 있다. 또한, SIP 노드(300B)는 세션 키의 날짜/시간 스탬프를 키의 기대 수명(expected lifetime) 또는 저장되어 있는 만료 날짜/시간과 비교할 수 있다. 키가 만료되면, SIP 노드(300B)는 지원된다면 오류 메시지를 송신할 수 있고, 자신의 프로세싱 스택으로부터 메시지를 삭제할 수 있으며, 그리고/또는 임의의 적합한 다른 동작을 취할 수 있다. 누락된 키가 액티브이면, SIP 노드(300B)는 복호화된 키를 메시지의 대응되는 서명을 확인하는데 계속해서 사용할 수 있다.

도 1에 나타낸 포괄적인 예에서, SIP 노드(300A)는 VIA 서명을 생성할 수 있고 그 서명을, 요청(500)의 VIA 헤더에 대한 헤더 파라미터와 같은, 에코된 헤더에 삽입할 수 있다. 그 다음, VIA 서명은, 피호출자가 그 요청에 대한 응답(600)을 송신할 때, SIP 노드(300)에서 확인될 수 있다. 마찬가지로, 요청이 다이얼로그-개시 요청이라면, SIP 노드(300)는 RECORD-ROUTE 서명을 생성할 수 있고 그 서명을, 요청(500)의 RECORD-ROUTE 헤더에 대한 헤더 파라미터와 같은, 에코된 헤더에 삽입할 수 있다. 그 다음, RECORD-ROUTE 서명은, 피호출자가 다이얼로그-개시 요청에 대한 응답(600)을 송신할 때, SIP 노드(300)에서 확인될 수 있다. 또한, 요 청이 다이얼로그-개시 요청이라면, SIP 노드(300)는 또한 피호출자 ROUTE SET 서명을 생성하여 그 서명을, 요청(500)의 RECORD-ROUTE 헤더에 대한 URI 파라미터와 같은, 에코된 헤더에 삽입할 수도 있다. 이러한 ROUTE SET 서명은, 그 다이얼로그의 피호출자에 의해 생성되는 임의의 장래 요청들에서 한 세트의 ROUTE 헤더들로서 사용되기 위해 피호출자 SIP 노드에 의해 저장될 수 있다. 따라서, 피호출자 ROUTE SET 서명은 요청의 피호출자에 의해 사용될 때까지 확인되지 않는다. 마찬가지로, 다이얼로그-개시 요청의 응답에서, SIP 노드(200)는 호출자 ROUTE SET 서명을 생성하여 그 서명을 SIP 노드(200)의 RECORD-ROUTE 헤더에 대한 URI 파라미터로서 삽입할 수 있다. 호출자 ROUTE SET 서명은, 호출자 SIP 노드에 의해 생성되는 임의의 요청들에 대한 한 세트의 ROUTE 헤더들로서 사용되기 위해 호출자 SIP 노드에 의해 저장될 수 있다. 이런 식으로, 호출자 ROUTE SET 서명은, 그것이 호출자로부터의 요청으로 전송될 때까지 확인되지 않을 수 있다.

도 8 내지 도 14를 참조하여, SIP 노드 서버의 예시적인 구현을 설명할 것이다.

도 1에 도시되어 있는, 호출자 SIP 노드(102), SIP 노드(200), SIP 노드(250), SIP 노드(300), 및/또는 피호출자 SIP 노드(402)의 임의 조합이 존재할 수 있으며 SIP 노드 프로세서로서 동작하는 하나 이상의 컴퓨터들 또는 다른 장치들상에서 운영될 수 있다. 이러한 노드들 각각은 다수 컴퓨터 시스템들 또는 다른 장치들상에 전체적으로 또는 부분적으로 제공될 수 있으며 그리고/또는 상술된 프로세스들을 제공하기 위해, 유선 접속, 무선 접속 등을 포함하여 업계에 공지되어 있 는 임의의 방법을 사용해 다같이 네트워크화될 수 있다.

도시된 실시예에서, SIP 노드(300)는, 도 8 내지 도 14를 참조하여 후술될 노드 서버(1300)로써 제공될 수 있다. SIP 노드(102), SIP 노드(200), SIP 노드(250), SIP 노드(300), 및 SIP 노드(402)는 유사한 서버/컴퓨터 시스템들로써 제공될 수 있다.

도 8에 나타낸 바와 같이, 노드 서버(1300)는, 하나 이상의 프로세서들(1304), 내부 날짜 및 시간 클록(1306), 그리고 실행될 경우, 컴퓨터에게 SIP 노드(300)의 동작들을 수행할 것을 지시하는 명령어들을 정의하는 하나 이상의 컴퓨터 프로그램들을 포함하는 저장 장치(1308)를 포함할 수 있는 하나 이상의 통신 포트들(1302)을 포함할 수 있다. 저장 장치는 또한, 도 9와 관련하여 부연될 키 데이터베이스(1310) 및 도 10 내지 도 14를 참조하여 후술될 프로그램들(1322)을 포함할 수 있다.

도 9는, 하나 이상의 레코드들을 포함하는, 키 데이터베이스(1310)에 대한 예시적 도표(1350)를 도시한다. 일반적으로, 각각의 레코드는 세션 키(1354)를 키에 관한 추가적인 정보와 관련짓는다. 이 예에서, 각각의 레코드(1352)는 키 식별자(1353), 세션 키(1354), 공개 키로 암호화되어 있는 암호화된 키(1356), 생성 날짜/시간(1358), 및 만료 날짜/시간(1360)을 포함한다. SIP 노드(300)는 세션 키(1354)를 생성할 수 있지만, SIP 노드는 메시지 자체로부터 세션 키를 식별하고, 키 서비스로부터 또는 데이터에 서명하는데 사용될 세션 키를 생성하기에 적합한 임의의 방법을 통해 세션 키를 검색할 수 있다. 마찬가지로, 나머지 데이터는 초 기화될 수 있고, SIP 노드(300)로서 업데이트된 메시지 자체 또는 다른 시스템은 키 정보를 제공한다.

키 데이터베이스는, 관계 데이터베이스, 객체-지향형 데이터베이스, 비구조화 데이터베이스, 인-메모리 데이터베이스, 또는 다른 데이터베이스를 포함하는, 임의 종류의 데이터베이스일 수 있다. 데이터베이스는, ASCII 텍스트, 이진 파일, 통신 네트워크를 통해 전송된 데이터, 또는 임의의 다른 파일 시스템과 같은 단층 파일 시스템을 사용해 구조화될 수 있다. 상기 데이터베이스들의 이러한 가능한 구현들에도 불구하고, 여기에서 사용되는 데이터베이스라는 용어는, 컴퓨터에 의해 액세스 가능한 어떤 방식으로 수집되고 저장된 임의의 데이터를 의미한다.

이제 도 10 내지 도 14를 참조하여, SIP 노드(300)에 의해 수행되는 다양한 동작들을 설명할 것이다. 보다 구체적으로, 도 10을 참조하여 VIA 서명의 생성이 설명되고 도 11을 참조하여 VIA 서명의 확인이 설명된다. RECORD-ROUTE 및 ROUTE SET 서명들의 생성이 도 12를 참조하여 설명되며 이 서명들의 확인이 도 13을 참조하여 설명된다. 도 14는 세션 키를 서버 풀 중 하나의 서버로부터 다른 서버로 수입하는 연산들을 도시한다.

도 10을 참조하면, VIA 서명을 생성하기 위한 연산들은 SIP 요청을 수신하는 단계(900)를 포함하지만, 이에 한정되는 것은 아니다. 상기 도면들이 INVITE 요청을 참조하여 논의되기는 하지만, VIA 서명은 시스템의 보안 및 프로세싱 요구 사항들에 따라 모든 요청들 또는 선택된 요청들에 대해 생성될 수 있다. SIP 노드는, 응답이 전달될 링크가 안전하지 못한 링크인지를 판정할 수 있다(902). 링크가 안 전하다면, SIP 노드는 SIP 표준 프로세스들에 따른 요청의 표준 프로세싱을 계속할 수 있다. 전달 링크가 불안전하다면, 연산들은, 프로세싱 중인 노드의 VIA 헤더를 제외하고, 차례로 수신된 VIA 헤더들 모두의 VIA 헤더 세트를 구성하는 단계(904)를 포함할 수 있다. 구체적으로, 요청을 조사하여 수신 메시지에 존재하는 VIA 헤더들은 서버(1300) 메모리에 저장될 수 있다. VIA 헤더 세트가 공백이면(906), 메시지의 표준 프로세싱이 계속될 수 있다. 하나보다 많은 VIA 헤더가 존재하면, 연산들은 또한, 상기한 바와 같이 서버(1300)에 의해 생성되거나, (도 14를 참조하여 다음에서 부연되는) 메시지 자체로부터 액세스되거나, 인터넷과 같은 수단을 통해 키 서비스로부터 검색될 수 있는 VIA 키를 식별하는 단계(908)를 포함할 수도 있다. 다음으로는, VIA 서명이 생성될 수 있으며(910), 메모리에 저장되어 있는 VIA 헤더 세트의 해시를 생성하기 위해 암호화 프로그램을 호출하는 단계를 포함할 수 있다. 프로세싱 중인 SIP 노드(300)에 대한 VIA 헤더가 생성될 수 있으며(912), VIA 서명은 헤더 파라미터로서 SIP 노드(300)에 대한 VIA 헤더에 삽입될 수 있다(914). 서버(1300)는 VIA 세션 키를 도 9를 참조하여 상술된 키 데이터베이스에 저장할 수 있고(916), 키 식별자, 키 생성 날짜/시간, 만료 날짜/시간, 암호화된 키, 및/또는 다른 정보와 같은, 키 파라미터들을 초기화하거나 업데이트할 수 있다.

도 11을 참조하면, 요청에 VIA 서명을 생성한 후, SIP 노드는 사전에 프로세싱된 요청에 대한 회답으로서 응답을 수신할 수 있다(918). 서버는 응답의 VIA 헤더들을 조사하여 하나보다 많은 VIA 헤더가 존재하는지를 판정할 수 있다(920). 단 하나의 VIA 헤더가 존재하면, 메시지의 표준 프로세싱이 계속될 수 있다. 하나보다 많은 VIA 헤더가 존재하면, SIP 노드는, 응답이 안전한 또는 안전하지 못한 접속을 통해 수신되었는지를 판정할 수 있다. 링크가 안전하다면, 메시지의 표준 프로세싱이 계속될 수 있다. 링크가 불안전하다면, SIP 노드(300)는 SIP 노드(300)에 대한 VIA 헤더를 조사하여 서명이 존재하는지를 판정할 수 있다(924). 서명이 존재하지 않으면, SIP 노드(300)는 자신의 프로세싱 스택들로부터 메시지를 누락시킬 수 있다. 서명이 존재하면, SIP 노드(300)는 헤더로부터 서명을 추출하여 VIA 서명을 메모리에 저장한 다음(926), 메시지로부터 최고 VIA 헤더(topmost VIA header;예를 들어, SIP 노드(300)의 VIA 헤더)를 추출할 수 있다(928). SIP 노드는 키 데이터베이스, 키 서비스, 또는 메시지 자체로부터 적절한 VIA 세션 키를 검색할 수 있다(930). 적절한 키는 서명 자체의 명백한 식별자, 메시지의 날짜/시간, 서명의 유형(예를 들어, VIA), 또는 적절한 VIA 세션 키를 식별하기에 적합한 임의의 다른 파라미터에 기초하여 선택될 수 있다. SIP 노드는 응답에 존재하는 나머지 VIA 헤더들의 VIA 헤더 세트를 생성할 수 있다(932). VIA 서명이 VIA 헤더들이 메시지에 제시된 순서로 생성되었다면, 확인 VIA 헤더는 서명 파라미터들의 적당한 순서를 보장하기 위해 동일한 순서로 생성될 수 있다. 연산들은 또한 VIA 헤더 세트 및 검색된 세션 키에 기초하여 VIA 확인 서명을 생성하는 단계(934), 그 다음, 확인 VIA 서명을 저장되어 있는 VIA 서명과 비교하는 단계(936)도 포함한다. VIA 서명들이 매칭되면, 메시지의 표준 프로세싱이 계속될 수 있다. 서명들이 매칭되지 않으면, SIP 노드는 자신의 프로세싱 스택에서 그 메시지를 누 락시키거나 적당한 임의의 다른 동작을 취할 수 있다.

도 12를 참조하면, ROUTE SET 및 RECORD-ROUTE 서명들을 생성하기 위한 연산들은 SIP 노드에서 메시지를 수신하는 단계(938) 및 메시지가 하나 이상의 RECORD-ROUTE 헤더를 포함하는지를 판정하는 단계(940)를 포함한다. 메시지가 어떤 RECORD-ROUTE 헤더들도 포함하지 않으면, 메시지의 표준 프로세싱이 계속될 수 있다. 그렇지 않으면, SIP 서버는, 메시지가 안전한 또는 안전하지 못한 링크를 통해 전송될 것인지를 판정할 수 있다(944). 보다 구체적으로, SIP 서버는, 확인될 메시지가 안전한 또는 안전하지 못한 링크를 통해 수신될 것인지를 판정할 수 있다. 응답 링크가 안전하면, 표준 프로세싱이 계속될 수 있다. 링크가 불안전하면, SIP 서버는, 수신된 메시지가 요청인지를 판정할 수 있다(946). 메시지가 요청이 아니라면, SIP 서버는 응답의 RECORD-ROUTE 헤더들에 기초하는 RECORD-ROUTE 헤더 세트를 구성할 수 있다(948). 메시지가 요청이라면, SIP 서버는 RECORD-ROUTE 헤더 세트를 구성하고(950), 상기한 바와 같이 서버(1300)에 의해 생성되거나, (도 14를 참조하여 다음에서 부연되는) 메시지 자체로부터 액세스되거나, 인터넷과 같은 수단을 통해 키 서비스로부터 검색될 수 있는 RECORD-ROUTE 세션 키를 식별할 수 있다(951). 그 다음, RECORD-ROUTE 서명이 생성될 수 있는데(952), 이것은 메모리에 저장되어 있는 RECORD-ROUTE 헤더 세트에 대한 URI 부분들의 해시를 생성하기 위해 암호화 프로그램을 호출하는 단계를 포함할 수 있다. RECORD-ROUTE 서명은 헤더 파라미터로서 SIP 노드(300)에 대한 RECORD-ROUTE 헤더에 삽입될 수 있다(954). 서버(1300)는 RECORD-ROUTE 세션 키를 도 9를 참조하여 상술된 키 데 이터베이스에 저장하고(956), 키 식별자, 키 생성 날짜/시간, 만료 날짜/시간, 및/또는 암호화된 키와 같은 키 파라미터들을 초기화 및/또는 업데이트할 수 있다. 메시지가 요청인지의 여부에 따라, SIP 서버는, 수신된 메시지내에 하나의 CONTACT 헤더가 존재하는지를 판정할 수 있다(942). 존재하지 않는다면, 표준 프로세싱이 계속될 수 있지만, 존재한다면, SIP 노드는 RECORD-ROUTE 헤더 세트 및 CONTACT 헤더로부터 ROUTE 헤더 세트를 구성할 수 있다(958). 그 다음, SIP 서버는 ROUTE SET 세션 키를 식별할 수 있고(960), 그 키를 사용해, URI 파라미터로서 SIP 노드(300)의 RECORD-ROUTE 헤더에 삽입(964)될 수 있는 ROUTE SET 서명을 생성할 수 있다. SIP 노드는 ROUTE SET 세션 키 및 키 파라미터들을 상술된 키 데이터베이스에 저장할 수 있다. 그 다음, SIP 서버는 메시지의 표준 프로세싱을 진행할 수 있다.

도 13을 참조하면, RECORD-ROUTE 서명의 확인은, SIP 노드가 응답을 수신할 때(968) 발생할 수 있다. SIP 노드는, 메시지에 RECORD-ROUTE 헤더들이 존재하는지를 판정할 수 있다(970). 존재하지 않으면, 메시지의 표준 프로세싱이 계속될 수 있지만, 존재한다면, SIP 노드는, 응답이 안전하지 못한 링크를 통해 수신되었는지를 판정할 수 있다(972). 링크가 안전하다면, 메시지의 표준 프로세싱이 계속될 수 있다. 링크가 불안전하다면, SIP 노드는, SIP 노드에 대한 RECORD-ROUTE 헤더가 RECORD-ROUTE 서명을 포함하는지를 판정할 수 있다(974). 포함하지 않는다면, 메시지는 SIP 노드(300)의 프로세싱 스택으로부터 누락될 수 있다. RECORD-ROUTE 서명이 존재한다면, SIP 노드 서버는 SIP 노드(300)의 RECORD-ROUTE 헤더내의 모든 서명들을 추출하여 저장할 수 있다(976). 예를 들어, SIP 노드(300)에 대 한 RECORD-ROUTE 헤더가 RECORD-ROUTE 서명 뿐만 아니라 ROUTE SET 서명도 포함할 수 있다. 어느 것이든, 이들의 위치가 다이얼로그 전체에 걸쳐 일관되고 그리고/또는 서명들이 다수 서명들을 구별하기 위한 적당한 방식으로 식별되기만 한다면, RECORD-ROUTE URI 파라미터들에 먼저 열거될 수 있다. 예를 들어, 다수 서명들을 가진 헤더에 삽입된 각각의 서명은 헤더의 유형을 특정하는 식별자를 포함할 수 있고 그리고/또는 각각의 서명에는 삽입된 서명의 유형을 식별하는 추가적인 파라미터가 수반될 수 있다. SIP 노드는 메시지 헤더들의 RECORD-ROUTE 헤더들에 대한 URI 부분들을 포함하는 RECORD-ROUTE 헤더 세트를 구성할 수 있다(978). 또한, SIP 노드는 도 11의 연산(930)을 참조하여 상술된 절차들에 따라 적합한 RECORD-ROUTE 세션 키를 검색할 수도 있다(980). SIP 노드는 RECORD-ROUTE 헤더 세트 및 세션 키에 기초하는 확인 RECORD-ROUTE 서명을 생성한 다음(982), 확인 RECORD-ROUTE 서명을 저장된 RECORD-ROUTE 서명과 비교할 수 있다(984). 서명들이 매칭되지 않으면, SIP 노드는 자신의 프로세싱 스택으로부터 메시지를 누락시킬 수 있다. 서명들이 매칭되면, 표준 프로세싱이 계속될 수 있다. ROUTE SET 서명이 RECORD-ROUTE 헤더의 URI 파라미터로서 존재했다면, SIP 노드 서버는 메시지 및/또는 메모리로부터 이 서명을 삭제할 수 있다(986). 보다 구체적으로, 피호출자 ROUTE SET 서명들이 피호출자 SIP 노드에 의해 저장되었으므로, 호출자에게 전달 중인 현재 메시지에서 더 이상 요구되지 않는다. 호출자에 대해 새로운 ROUTE SET 서명이 생성되어 피호출자에게 전송되어야 하는지를 판정하기 위해, SIP 노드는, 후속 SIP 노드가 안전하지 못한 링크를 통과하는지 그리고 하나 이상의 CONTACT 헤더가 존재 하는지를 판정할 수 있다(987). 그렇지 않다면, 메시지의 표준 프로세싱이 계속될 수 있다. 후속 링크가 불안전하다면, SIP 노드 서버는, RECORD-ROUTE 키와 동일할 수 있는 ROUTE SET 세션 키를 검색하는 것(988)에 의해 ROUTE SET 서명을 생성할 수 있다. 그 키를 사용해, SIP 노드는 RECORD-ROUTE 헤더 세트 및 처음으로 열거된 CONTACT 헤더의 URI 부분에 기초하는 ROUTE SET 서명을 생성할 수 있다(990). ROUTE SET 서명은 호출자 SIP 노드(102)로 전달될 SIP 노드(300)에 대한 RECORD-ROUTE 헤더에 삽입될 수 있다(992). SIP 노드는 ROUTE SET 세션 키 및/또는 RECORD-ROUTE 세션 키와 키 파라미터들을 상술된 키 데이터베이스에 저장할 수 있다(994). 그 다음, SIP 서버는 메시지의 표준 프로세싱을 진행할 수 있다. 피호출자 ROUTE SET 서명 및/또는 후속 요청들의 호출자 ROUTE SET 서명의 확인은 설명된 것과 유사한 프로세스를 수반할 수 있다.

도 14는 서버 풀내의 서버들 사이에서 세션 키를 전달하기 위한 예시적 일 구현의 연산들을 도시한다. 예를 들어, 상기한 바와 같이, SIP 노드(300)는 서버(300A) 및 서버(300B)로써 제공될 수 있다. 이런 식으로, SIP 노드(300A)는 세션 키를 가진 서명을 생성할 수 있고, 그 다음, SIP 노드(300B)에게는 그 서명을 확인할 것이 요청될 수 있다. 다음 예는 ROUTE SET 헤더들을 참조하여 설명되지만, 유사한 프로세스가 RECORD-ROUTE 세션 키 및/또는 VIA 세션 키의 암호화, 서명, 및 액세스에 사용될 수도 있다.

도 14에 나타낸 바와 같이, 공개/비밀 키 쌍의 공통 인증서가 생성되어(996) 서버 풀내의 각 서버(300A, 300B)상에 설치된다(998). 상기한 바와 같이, 공개/비 밀 키 쌍이 그 노드에 의해 프로세싱된 모든 세션 키들의 서명 및 암호화에 사용될 수 있거나, 세션 키의 각 유형(VIA, RECORD-ROUTE, 및/또는 ROUTE SET)이 특징적인 공개/비밀 키 쌍을 가질 수 있다. 연산시에, SIP 노드(300A)는 서명될 필요가 있는 요청을 수신할 수 있다(1000). 상기한 바와 같이, SIP 노드 서버는, ROUTE SET 세션 키를 생성하거나, 액세스하거나, 검색하는 것에 의해, ROUTE SET 세션 키를 식별할 수 있다(1002). 또한, SIP 노드는, 인증서가 키 교환에 관한 라우팅 정보를 위해 구성되었는지를 확인할 수 있다(1004). SIP 서버는 ROUTE SET 세션 키의 생성 날짜/시간 스탬프를 판정하여 날짜/시간 스탬프를 세션 키에 첨부할 수 있다(1006). 공개 키를 사용해, SIP 서버는 세션 키 및 날짜/시간 스탬프를 암호화할 수 있고(1008) 비밀 키로 그 결과에 서명할 수 있다(1010). 암호화되고 서명된 세션 키의 결과는 날짜/시간 스탬프, 세션 키, 세션 키 식별자 등과 같은 키 파라미터들과 함께 도 9를 참조하여 상술된 키 데이터베이스에 저장될 수 있다(1012). ROUTE SET 세션 키를 사용해, SIP 노드는 도 12를 참조하여 상술된 바와 같은 ROUTE SET 서명을 생성하고 SIP 노드(300)에 대한 RECORD-ROUTE 헤더를 생성할 수 있다(1014). SIP 노드 서버는 ROUTE SET 서명을 SIP 노드에 대한 RECORD-ROUTE 헤더에 삽입할 수 있고(1018), 서명되고 암호화된 ROUTE SET 세션 키를 SIP 노드 RECORD-ROUTE 헤더의 URI 파라미터들로서 삽입할 수도 있다(1020).

피호출자가 요청을 수신한 후, 피호출자는 RECORD-ROUTE 헤더들의 URI 부분들 및 CONTACT 헤더를 ROUTE 헤더들의 세트에 저장할 것이다. 피호출자 SIP 노드가 후속 인-다이얼로그 요청을 생성할 때, 피호출자 SIP 노드는, SIP 노드(300A)에 의해 생성된 ROUTE SET 서명 및 ROUTE SET 세션 키를 포함하는 RECORD-ROUTE 및 CONTACT 헤더들을 에코하는 ROUTE SET 헤더들을 포함할 수 있다. 제 2 SIP 노드(300B)는 하나 이상의 ROUTE 헤더를 가진 인-다이얼로그 요청을 수신할 수 있다(1022). 도 12를 참조하여 상술된 적합한 세션 키를 검색하는 것(930)과 관련하여, SIP 노드는 ROUTE 헤더로부터 서명되고 암호화된 ROUTE SET 세션 키를 추출하고(1024), 서버 노드(300B)가 복호화된 세션 키로의 액세스를 갖는지를 판정하기 위해, 서명되고 암호화된 키를 키 데이터베이스의 항목들과 비교할 수 있다(1026). 매칭이 존재하면, SIP 노드(300B)는 키 데이터베이스로부터의 세션 키를 ROUTE 헤더의 ROUTE SET 서명을 확인하는데 사용할 수 있다. 매칭이 존재하지 않으면, SIP 노드는 키 서명을 추출하고(1028) 공개 키로 키 서명을 확인할 수 있다(1030). 서명이 확인되지 않으면, SIP 노드는 자신의 프로세싱 스택으로부터 메시지를 누락시키거나 임의의 적절한 다른 동작을 취할 수 있다. 서명이 매칭되면, 암호화된 세션 키가 추출될 수 있다(1032). 키가 더 이상 액티브가 아니라면(예를 들어, 만료되었다면), 날짜/시간 스탬프는 서버 리소스들을 최소화하기 위해 세션 키와 별개로 복호화될 수 있다(1034). 보다 구체적으로, SIP 노드는, 날짜/시간 스탬프가 그 유형의 세션 키에 대한 구성 수명내에 있다는 것을 확인하기 위해, 복호화 후에 날짜/시간 스탬프를 확인할 수 있다(1036). 날짜/시간 스탬프가 확인될 수 없다면, 메시지는 프로세싱 스택으로부터 누락될 수 있다. 날짜/시간 스탬프가 확인되면, 세션 키는 비밀 키로 복호화된 다음(1038) ROUTE SET 서명을 확인하는데(1040) 사용될 수 있다. 복호화된 세션 키의 결과는 날짜/시간 스탬프, 서명되고 암호화 된 세션 키, 세션 키 식별자 등과 같은 키 파라미터들과 함께 도 9를 참조하여 상술된 키 데이터베이스에 저장될 수 있다(1042). 그 다이얼로그가 종료될 때, 그 세션 키를 사용하는 헤더들이 더 이상 기대되지 않을 때, 세션 키의 액티브 수명의 끝에서, 그리고/또는 세션 키의 만료 날짜 이후와 같은 때에, 간혹, 세션 키는 만료될 수 있고, 세션 키, 서명되고 암호화된 세션 키 등을 포함하는, 그 세션 키에 대한 데이터베이스 레코드들은 키 데이터베이스로부터 제거될 수 있다.

도 1 및/또는 도 8의 SIP 노드들에 대한 다양한 요소들이 개별적으로 또는 조합으로 구현될 수 있는 컴퓨터 시스템은 통상적으로, 사용자에게 정보를 디스플레이하는 출력 장치 및 사용자로부터 정보를 수신하는 입력 장치 모두에 접속되어 있는 하나 이상의 메인 유닛을 포함한다. 메인 유닛은 상호 접속 메커니즘을 통해 메모리 시스템에 접속되어 있는 프로세서를 포함할 수 있다. 입력 장치 및 출력 장치 또한 상호 접속 메커니즘을 통해 프로세서 및 메모리 시스템에 접속된다.

도 1 및/또는 도 8에 도시된 컴퓨팅 장치들은 통상적으로 어떤 형태의 컴퓨터 판독 가능 매체를 포함한다. 컴퓨터 판독 가능 매체는, SIP 서버의 다른 컴퓨팅 장치들에 의해 액세스될 수 있는 이용 가능한 임의의 매체일 수 있다. 한정이 아닌 일례로써, 컴퓨터 판독 가능 매체는 컴퓨터 저장 매체 및 통신 매체를 구비할 수 있다. 컴퓨터 저장 매체는 컴퓨터 판독 가능 명령어들, 데이터 구조들, 프로그램 모듈들, 또는 다른 데이터와 같은 정보의 저장을 위해 임의의 방법 또는 기술로 구현된 휘발성 및 비휘발성, 추출형 및 비추출형 매체를 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD 또 는 다른 광학 디스크 저장 장치, 자기 카세트들, 자기 테이프, 자기 디스크 저장 장치 또는 다른 자기 저장 장치들, 또는 소정 정보를 저장하는데 사용될 수 있으며 SIP 노드의 컴퓨팅 시스템들에 의해 액세스될 수 있는 임의의 다른 매체를 포함하지만, 이에 한정되는 것은 아니다. 통신 매체는 통상적으로 컴퓨터 판독 가능 명령어들, 데이터 구조들, 프로그램 모듈들, 또는 반송파나 다른 전송 메커니즘과 같은 변조 데이터 신호의 다른 데이터를 구현하며 임의의 정보 전달 매체를 포함한다. 한정이 아닌 일례로써, 통신 매체는 유선 네트워크 또는 직접-유선 접속과 같은 유선 매체, 및 음향, RF, 적외선 및 다른 무선 매체와 같은 무선 매체를 포함한다. 상기한 것들의 임의 조합들 또한 컴퓨터 판독 가능 매체의 범위내에 포함되어야 한다.

하나 이상의 출력 장치들 및 하나 이상의 입력 장치들이 컴퓨터 시스템에 접속될 수 있다. 본 방법은, 컴퓨터 시스템과 함께 사용된 특정한 입력 또는 출력 장치들 또는 여기에서 설명된 것들에 한정되지 않는다.

컴퓨터 시스템은, SmallTalk, C++, 자바, 에이다, 또는 C#(C-sharp)과 같은, 컴퓨터 프로그래밍 언어 또는, 스크립팅 언어 또는 심지어 어셈블리어와 같은, 다른 언어를 사용해 프로그램될 수 있는 범용 컴퓨터 시스템일 수 있다. 본 발명의 다양한 태양들은 비-프로그램 환경(예를 들어, HTML, XML, 또는 브라우저 프로그램의 윈도우에서 보여질 때, 그래픽 사용자 인터페이스의 태양들을 렌더링하거나 다른 펑크션들을 수행하는 다른 포맷으로 생성된 문서들)에 구현될 수도 있다. 본 발명의 다양한 태양들은 프로그램 요소들, 비-프로그램 요소들, 또는 그들의 임의 조합으로서 구현될 수 있다. 또한, 컴퓨터 시스템은 특수하게 프로그램되거나, 특수 목적의 하드웨어 또는 ASIC(application specific integrated circuit)일 수도 있다. 또한, 판독기 시스템은 페이저, 전화기, PDA, 또는 다른 전자 데이터 통신 장치를 포함할 수도 있다.

범용 통신 시스템에서, 프로세서는 통상적으로, Intel Corporation으로부터 입수할 수 있는 주지의 Pentium® 프로세서와 같은 상업적으로 이용 가능한 프로세서이다. 많은 타 프로세서들이 이용될 수 있다. 이러한 프로세서는 일반적으로, 예를 들어, Microsoft Corporation으로부터 입수할 수 있는 Windows 95®, Windows 98®, Windows NT®, Windows 2000®, 또는 Windows XP®, Apple Computer로부터 입수할 수 있는 MAC OS System X, Sun Microsystems로부터 입수할 수 있는 Solaris Operating System, 또는 다양한 소스들로부터 입수할 수 있는 UNIX일 수 있는 오퍼레이팅 시스템을 실행시킨다. 많은 타 오퍼레이팅 시스템들이 사용될 수 있다.

프로세서 및 오퍼레이팅 시스템은 다같이, 고급 프로그래밍 언어들의 애플리케이션 프로그램들이 기입될 수 있는 컴퓨터 플랫폼을 정의한다. 본 발명이 특정한 컴퓨터 시스템 플랫폼, 프로세서, 오퍼레이팅 시스템, 또는 네트워크에 한정되지 않는다는 것을 이해할 수 있어야 한다. 또한, 당업자들에게는, 본 발명이 특정 프로그래밍 언어 또는 컴퓨터 시스템에 한정되지 않는다는 것이 명백해야 한다. 또한, 다른 적절한 프로그래밍 언어들 및 다른 적절한 컴퓨터 시스템들이 사용될 수도 있다는 것을 알 수 있어야 한다.

컴퓨터 시스템의 하나 이상 부분들이, 통신 네트워크에 결합되어 있는 (나타 내지 않은) 하나 이상의 컴퓨터 시스템들을 통해, 분산될 수 있다. 이러한 컴퓨터 시스템들 또한 범용 컴퓨터 시스템들일 수 있다. 예를 들어, 본 발명의 다양한 태양들은, 하나 이상의 클라이언트 컴퓨터들(예를 들어, 서버들)에게 서비스를 제공하거나 분산 시스템의 일부로서 전반적인 태스크를 수행하도록 구성된 하나 이상의 컴퓨터 시스템들 사이에 분산될 수 있다. 예를 들어, 본 발명의 다양한 태양들은, 본 발명의 다양한 실시예들에 따라 다양한 펑크션들을 수행하는 하나 이상의 서버 시스템들 사이에 분산되어 있는 컴포넌트들을 포함하는 클라이언트-서버 시스템상에서 수행될 수 있다. 이들 컴포넌트들은, 통신 프로토콜(예를 들어, SIP 또는 TCP/IP)을 사용하는 통신 네트워크(예를 들어, 인터넷)를 통해 통신하는 실행 가능 코드, 중간 코드(예를 들어, IL), 또는 해석 코드(예를 들어, 자바)일 수 있다. 본 발명이 임의의 특정 시스템 또는 시스템들의 그룹상에서의 실행에 한정되지 않는다는 것을 알 수 있어야 한다.

본 발명의 몇가지 예시적 실시예들을 설명하였지만, 당업자들은, 상기한 것들이 한정이 아닌 단지 일례로서 제시된 것이라는 것을 알 수 있어야 한다. 다양한 변경들 및 다른 예시적 실시예들이 당업자에게 가능할 수 있으며 본 발명의 범위내에 해당되는 것으로 해석된다. 특히, 여기에서 제시된 많은 예들이 방법 연산들 또는 시스템 요소들의 특정 조합들과 관련되어 있지만, 이러한 연산들 및 요소들은 동일한 목적들을 실현하기 위해 다른 방법들로 조합될 수 있다는 것을 이해할 수 있어야 한다. 일 실시예와 관련하여서만 논의된 연산들, 요소들, 및 특징들이 다른 실시예들의 유사한 역할로부터 제외되는 것은 아니다. 또한, 청구항 요소를 변경하기 위해 청구항들에서 "제 1" 및 "제 2"와 같은 서수 용어들을 사용하는 것은 그 자체가 다른 청구항 요소에 대한 어떤 청구항 요소의 우선 순위, 서열이나 순서 또는 방법의 연산들이 수행되는 시간적 순서를 암시하는 것이 아니라, (서수 용어의 용도를 위해서가 아니라) 청구항 요소들을 구별하기 위해, 소정 이름을 가진 하나의 청구항 요소를 동일한 이름을 가진 다른 청구항 요소와 구별하기 위한 레이블들로서 사용될 뿐이다.

본 발명은 SIP 메시지에 포함된 라우팅 명령어들을 인증하기 위해 SIP 라우팅 헤더들에 서명하고 유효화하는 방법을 개시한다.

Claims

SIP(Session Initiation Protocol) 메시지를 프로세싱하는 방법으로서,

SIP 노드에서, 네트워크 라우팅 위치들을 표시하는 데이터를 포함하는 메시지 헤더를 포함하는 SIP 요청을 수신하는 단계;

상기 SIP 요청의 RECORD-ROUTE 헤더를 판정하는 단계;

상기 SIP 노드에서 상기 데이터를 편집하는 단계;

상기 편집된 데이터를 포함하는 상기 메시지 헤더의 적어도 일부에 기초하여 서명을 생성하는 단계;

SIP 노드 헤더 항목(entry)을 생성하는 단계; 및

상기 서명을 상기 SIP 노드 헤더 항목에 삽입하는 단계를 포함하고,

상기 서명을 생성하는 단계는, 상기 SIP 요청의 상기 RECORD-ROUTE 헤더의 적어도 일부분에 기초하여 상기 서명을 생성하는 단계를 포함하고,

상기 서명을 삽입하는 단계는, 상기 SIP 노드의 RECORD-ROUTE 헤더에 상기 서명을 삽입하는 단계를 포함하는, SIP 메시지 프로세싱 방법.
제1항에 있어서,

상기 SIP 노드 헤더 항목은 에코되는(echoed) 헤더인, SIP 메시지 프로세싱 방법.
제1항에 있어서,

상기 서명을 삽입하는 단계는, 상기 SIP 노드의 상기 RECORD-ROUTE 헤더의 헤더 파라미터로서 상기 서명을 삽입하는 단계를 포함하는, SIP 메시지 프로세싱 방법.
제1항에 있어서,

상기 SIP 요청에 응답하여, 상기 SIP 노드에서 SIP 응답을 수신하는 단계 - 상기 SIP 응답은 제3 수신 서명을 포함하는 상기 SIP 노드에 대한 상기 RECORD-ROUTE 헤더를 포함함 -; 및

상기 제3 수신 서명을 검증하는 단계

를 더 포함하는 SIP 메시지 프로세싱 방법.
제1항에 있어서,

상기 SIP 요청을 수신하기 위해, 후속 SIP 노드로의 후속 링크를 결정하는 단계; 및

상기 후속 SIP 노드로의 상기 후속 링크가 안전하지 못한(untrusted) 링크인지를 판정하는 단계를 더 포함하고,

상기 서명을 생성하는 단계는, 상기 후속 링크가 안전하지 못한 링크일 경우에만 상기 서명을 생성하는 단계를 포함하는, SIP 메시지 프로세싱 방법.
SIP 메시지를 프로세싱하는 방법으로서,

SIP 노드에서, 메시지 헤더를 포함하는 SIP 요청을 수신하는 단계;

상기 메시지 헤더의 적어도 일부에 기초하여 서명을 생성하는 단계;

VIA 헤더인 SIP 노드 헤더 항목(entry)을 생성하는 단계;

상기 서명을 상기 SIP 노드 헤더 항목에 삽입하는 단계;

상기 SIP 요청에 응답하여, 상기 SIP 노드에서 SIP 응답을 수신하는 단계 - 상기 SIP 응답은 상기 SIP 노드에 대한 상기 VIA 헤더를 포함하고, 상기 VIA 헤더는 제1 수신 서명을 포함함 -;

상기 제1 수신 서명을 검증하는 단계;

상기 SIP 요청을 수신하기 위해 후속 SIP 노드로의 후속 링크를 결정하는 단계; 및

상기 후속 SIP 노드로의 상기 후속 링크가 안전하지 않은 링크인지를 판단하는 단계를 포함하고,

상기 서명을 생성하는 단계는 상기 후속 링크가 안전하지 않은 링크인 경우에만 상기 서명을 생성하는 단계를 포함하는, SIP 메시지 프로세싱 방법.
SIP 메시지를 프로세싱하는 방법으로서,

SIP 노드에서, 메시지 헤더를 포함하는 SIP 요청을 수신하는 단계;

상기 메시지 헤더의 적어도 일부에 기초하여 서명을 생성하는 단계;

SIP 노드 헤더 항목(entry)을 생성하는 단계;

상기 서명을 상기 SIP 노드 헤더 항목에 삽입하는 단계;

상기 SIP 요청에 응답하여, 응답 헤더를 포함하는 SIP 응답을 수신하는 단계;

상기 응답 헤더의 CONTACT 헤더 및 RECORD-ROUTE 헤더에 기초하여 또 다른 서명을 생성하는 단계;

상기 또 다른 서명을 상기 응답의 상기 SIP 노드의 RECORD-ROUTE 헤더로 삽입하는 단계; 및

상기 또 다른 서명을 생성하기 전에, 상기 SIP 노드 헤더 항목에서 기존 서명을 제거하는 단계

를 포함하는 SIP 메시지를 프로세싱하는 방법.
동일한 다이얼로그에서의 메시지 프로세싱을 위해 호환적으로 사용될 수 있도록 구성되고 배치된 제 1 서버 및 제 2 서버를 갖는 서버 풀(a pool of servers)에서 메시지들을 프로세싱하기 위한 단계들을 수행하기 위한 컴퓨터 실행가능 명령어들을 저장한 컴퓨터 판독가능 기록매체로서, 상기 단계들은,

상기 제1 서버에서, 공개 키 및 비밀 키를 식별하는 단계;

상기 제 1 서버에서, 제1 헤더를 포함하는 제1 메시지를 수신하는 단계;

세션 키를 생성하는 단계;

상기 세션 키를 상기 비밀 키로 암호화하는 단계;

상기 공개 키로, 상기 암호화된 세션 키에 기초하여 키 서명을 생성하는 단계;

상기 키 서명을 상기 제1 헤더에 삽입하는 단계; 및

상기 세션 키에 대한 생성 날짜 및 시간을 표현하는 데이터를 포함하는 타임 스탬프를 식별하고, 상기 타임 스탬프를 상기 세션 키에 첨부하는 단계를 더 포함하고,

상기 세션 키를 암호화하는 단계는 상기 세션 키 및 상기 타임 스탬프를 암호화하는 단계를 포함하는, 컴퓨터 판독가능 기록매체.
제8항에 있어서,

상기 단계들은,

상기 제 2 서버에서, 상기 공개 키 및 상기 비밀 키를 식별하는 단계;

상기 제 2 서버에서, 상기 키 서명을 포함하는 제2 헤더를 포함하는 제2 메시지를 수신하는 단계; 및

상기 세션 키를 결정하기 위해, 상기 키 서명을 복호화하는 단계

를 더 포함하는, 컴퓨터 판독가능 기록매체.
제9항에 있어서,

상기 단계들은,

상기 세션 키로 상기 제2 메시지의 적어도 일부를 검증하는 단계

를 더 포함하는, 컴퓨터 판독가능 기록매체.
제8항에 있어서,

상기 제1 메시지는 SIP 메시지인, 컴퓨터 판독가능 기록매체.
제8항에 있어서,

상기 제1 서버는 프록시(proxy) 서버인, 컴퓨터 판독가능 기록매체.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제