KR100556605B1

KR100556605B1 - 인터넷 전화 서비스를 위한 프락시 서버 시스템

Info

Publication number: KR100556605B1
Application number: KR1020030086525A
Authority: KR
Inventors: 현욱; 박선옥; 허미영; 강신각
Original assignee: 한국전자통신연구원
Priority date: 2003-12-01
Filing date: 2003-12-01
Publication date: 2006-03-06
Also published as: KR20050052942A

Abstract

본 발명은 인터넷 전화 서비스뿐 아니라 다양한 VoIP 부가 서비스를 제공하고자 할 때 사용자 단말로부터의 호(call) 요구을 처리하는 SIP(Session Initiation Protocol) 프락시(Proxy) 서버 시스템에 관한 것이다.

본 발명의 프락시 서버는 네트워크 소켓을 통해 수신한 스트림 형태의 메시지를 SIP 메시지 구조체로 파싱해서 상위 계층으로 넘겨주거나 상위 계층으로부터 처리 완료된 SIP 메시지 구조체를 스트림 형태로 다시 생성하는 SIP 파서/제너레이터; SIP 파서/제너레이터의 상위에 위치하여 SIP 요구/응답 메시지를 보낼 위치 및 방법을 결정하는 SIP 전송 매니저; SIP 전송 매니저의 상위에 위치하여 SIP 트랜잭션을 관리하기 위한 SIP 트랜잭션 매니저; SIP 트랜잭션 매니저의 상위에 위치하여 실질적인 SIP 메시지 처리 동작을 수행하는 프락시 매니저 계층; 및 프락시 매니저 계층의 상위에 위치하여 프락시 서버 시스템 관리를 위한 시스템 모니터링, 및 메시지 로깅, 정의된 과금 정책에 따른 과금 부여기능 등을 담당하는 최상위 계층을 포함하여 모듈화된 것이다.

인터넷 전화, SIP, 프락시 서버, 모듈화, 메시지 처리

Description

인터넷 전화 서비스를 위한 프락시 서버 시스템{ Proxy sever system for VoIP}

도 1은 일반적인 SIP 셋업 예를 도시한 개략도,

도 2는 본 발명이 적용되는 SIP 인터넷 폰 서비스를 위한 전체 시스템의 구성을 도시한 개략도,

도 3은 본 발명에 따른 SIP 프락시 서버 시스템의 구성을 도시한 도면,

도 4a는 본 발명에 따라 호 정보를 관리하기 위해 사용되는 구조체의 연관관계를 도시한 도면,

도 4b는 도 4a에 도시된 구조체의 예,

도 5a~도 5d는 본 발명에 따른 SIP 프락시 서버 시스템에서 요구 메시지 처리 과정을 도시한 흐름도,

도 6a, 6b는 본 발명에 따른 SIP 프락시 서버 시스템에서 응답 메시지 처리 과정을 도시한 흐름도.

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

102-1,102-2: 클라이언트 110: 레지스트라 서버

120: 로케이션 서버 200: 프락시 서버

210: SIP 파서/제너레이터 220: SIP 전송 매니저

230: SIP 트랜잭션 매니저 240: 프락시 매니저 계층

241: SIP 콜 매니저 242: DNS 퀘리모듈

243: 레지스트라 접속모듈 244: 인증모듈

245: SDP 파서/제너레이터 250: 최상위 계층

251: 메시지 로깅 모듈 252: 모니터링 모듈

253: 과금모듈 254: 관리자 모듈

본 발명은 세션 초기화 프로토콜(SIP: Session Initiation Protocol ) 기반 인터넷 전화 기술에 관한 것으로, 더욱 상세하게는 인터넷 전화 서비스를 위한 SIP 프락시 서버 및 SIP 메시지 처리방법에 관한 것이다.

일반적으로, 대부분의 인터넷 전화 서비스는 ITU-T에서 제정한 H.323 표준에 따라 제공되고 있으나 최근에는 ITU-T의 H.323의 대안으로 IETF(Internet Engineering Task Force)에서 개발한 SIP와 같은 차세대 VoIP 표준 기술을 기반으로 한 제품 개발이 추진되고 있는 추세이다. SIP에 기반한 인터넷 전화 서비스를 제공하기 위해서는 기본적으로 사용자들이 전화를 걸기 위해 사용하는 클라이언트와, 클라이언트로부터의 호 요구을 목적지 클라이언트까지 전송하는 프락시 서버, 특정 클라이언트로의 접속 주소를 저장하는 레지스트라 서버가 필요하다. 여기서, 레지스트라 서버는 사용자의 현재 위치를 등록 받는 서버로서, 레지스터(REGISTER) 메소드내의 Contact 헤더와 Expires 헤더들의 조합으로 현재 사용자의 위치에 대한 등록/갱신/삭제/조회 등의 기능을 담당한다.

도 1은 일반적인 SIP에 기반한 호 셋업(Call Set-up) 예를 도시한 개략도로서, 클라이언트인 앨리스(10-1)와 클라이언트 봅(10-2)이 프락시 서버(20-1,20-2)를 통해 호 셋업되는 과정이 개략적으로 도시되어 있다.

도 1을 참조하면, 앨리스(10-1)는 인터넷 폰을 통해 프락시 서버1(20-1)에 봅의 인터넷 폰을 목적지로 하는 인바이트(INVITE) 요구 메시지를 전송하면, 프락시 서버1(20-1)은 이를 프락시 서버2(20-2)로 전달함과 아울러 앨리스(10-1)에게 시도중(100 Trying) 메시지로 응답하고, 프락시 서버2(20-2)는 인바이트 메시지를 봅(10-2)에게 전달함과 아울러 프락시 서버1(20-1)에 시도중(100 Trying) 메시지로 응답한다. 이어 상대방 클라이언트인 봅(10-2)으로부터 링(180 Ringing) 응답이 프락시 서버2(20-2)와 프락시 서버1(20-1)을 거쳐 앨리스(10-1)에게 전달되고, 봅(10-2)이 인터넷 폰을 들어 후크-오프하면 OK 응답 메시지가 프락시 서버2,1(20-2,20-1)를 통해 앨리스(10-1)에게 전달된다. 앨리스(10-1)는 이에 따라 ACK 메시지로 응답하고, 앨리스(10-1)와 봅(10-2) 사이에는 미디어 세션(Media Session)이 연결되어 서로 통신하게 된다. 통신이 끝나 봅(10-2)이 바이(BYE) 요구 메시지를 전송하면, 앨리스(10-1)가 OK 메시지로 응답하여 세션을 종료하게 된다.

여기서, SIP 프락시 서버(20-1,20-2)로는 스테이트리스 프락시 서버(Stateless Proxy Server)와 스테이트풀 프락시 서버(Stateful Proxy Server)가 있는 데, 스테이트리스 프락시 서버(Stateless Proxy Server)는 클라이언트로부터의 호 요구에 대해 호와 관련된 일체의 정보를 유지하지 않는 프락시 서버이다. 스테이트리스(Stateless) 프락시 서버는 백본망에 붙어 사용자에게 다양한 서비스를 제공하기 보다는 주로 빠른 처리가 필요한 경우에 사용된다. 그리고 스테이트풀 프락시 서버(Stateful Proxy Server)는 클라이언트로부터의 호 요구에 대해 호와 관련된 정보를 유지하며, 이로 인해 다양한 서비스들을 생성할 수 있다. 예컨대, 호 포킹(forking)을 통해 한 사용자에 대한 여러 위치들에 동시 접속 시도를 할 수 있다.

그런데 종래에 개발된 SIP 기반 프락시 서버들은 기본적인 기능들만을 제공하고 있으며, 새로운 기능 제공을 위해 확장하고자 하는 경우, 전체적인 구조가 하나로 묶여 있어 확장의 용이성이 떨어지는 문제점이 있다. 즉, 전체 프락시 구조 자체가 모듈화되어 있지 않으므로 SIP 메소드나 헤더 확장, 프락시 처리 동작 변경이나 확장 등이 용이하지 않다는 단점을 가진다.

본 발명은 상기와 같은 종래기술의 문제점을 해결하고 향후 용이한 SIP 확장을 위해 모듈화된 SIP 프락시 서버 시스템 및 SIP 메시지 처리방법을 제공하는데 그 목적이 있다. 이와 같이 본 발명에서 제안하는 프락시 서버의 세부 구조는 기능별로 모듈화되어 있으며, 각 단계의 인터페이스는 세부 함수 또는 라이브러리 형 태로 제공되므로, 각 기능별로 확장이 용이하다는 장점을 가진다. 본 발명에서는 스테이트풀(Stateful) 프락시 서버에 대해서만 다루며, 이하 본 발명의 실시예에서 프락시 서버라함은 스테이트풀(Stateful) 프락시 서버를 의미한다.

상기한 목적을 달성하기 위한 본 발명의 프락시 서버 시스템은, 네트워크 소켓을 통해 수신한 스트림 형태의 메시지를 SIP 메시지 구조체로 파싱해서 상위 계층으로 넘겨주거나 상위 계층으로부터 처리 완료된 SIP 메시지 구조체를 스트림 형태로 다시 생성하는 SIP 파서/제너레이터; 상기 SIP 파서/제너레이터의 상위에 위치하여 SIP 요구/응답 메시지를 보낼 위치 및 방법을 결정하는 SIP 전송 매니저; 상기 SIP 전송 매니저의 상위에 위치하여 SIP 트랜잭션을 관리하기 위한 SIP 트랜잭션 매니저; 상기 SIP 트랜잭션 매니저의 상위에 위치하여 실질적인 SIP 메시지 처리 동작을 수행하는 프락시 매니저 계층; 및 상기 프락시 매니저 계층의 상위에 위치하여 프락시 서버 시스템 관리를 위한 시스템 모니터링, 및 메시지 로깅, 정의된 과금 정책에 따른 과금 부여기능 등을 담당하는 최상위 계층을 포함하여 모듈화된 것을 특징으로 한다.

이하, 첨부된 도면을 사용하여 본 발명의 바람직한 실시예를 상세히 설명한다.

도 2는 본 발명이 적용되는 SIP 인터넷 폰 서비스를 위한 전체 시스템의 구 성을 도시한 개략도로서, 전체 시스템은 클라이언트(102-1,102-2)와 레지스트라 서버(110), 로케이션 서버(120), 프락시 서버(200)들이 인터넷을 통해 연결되어 있다.

도 2와 같은 구성 예에서 클라이언트인 앨리스(102-1)가 클라이언트인 봅(102-2)에게 SIP 프로토콜에 따라 인터넷 폰을 연결하는 과정은 다음과 같다. 이때 본 발명에서 사용하는 SIP 프로토콜은 RFC3261 국제 표준을 따른다.

먼저, 클라이언트 봅(102-2)은 레지스트라 서버(110)에 레지스터(RESISTER) 메소드를 통해 등록하고(①), 등록된 봅의 정보는 프락시 서버들이 억세스 용이한 로케이션 서버(120)에 저장(store)되어 있다(②). 클라이언트 앨리스(102-1)는 인바이트(INVITE) 매소드를 통해 프락시 서버(200)에 봅과의 연결을 요구하고(③), 이에 따라 프락시 서버(200)는 로케이션 서버(120)에 봅의 주소를 질의(Query)하고(④), 로케이션 서버(120)는 봅의 주소를 제공하여 응답(Resp)한다(⑤). 이에 따라 프락시 서버(200)는 클라이언트 봅(102-2)에게 인바이트(INVITE) 메소드로 접속을 요구한다(⑥).

도 3은 본 발명에 따른 SIP 프락시 서버 시스템의 구성을 도시한 도면으로서, 본 발명의 프락시 서버(200)는 SIP 파서/제너레이터(210)와, SIP 전송 매니저(220), SIP 트랜잭션 매니저(230), 프락시 매니저 계층(240), 최상위 계층(250) 등 5개의 계층으로 모듈화되어 있다. 그리고 프락시 매니저 계층(240)은 SIP 콜 매니저(241)와, DNS Query 모듈(242), 레지스트라 접속 모듈(243), 인증모듈(244), SDP(Session Description Protocol) 파서/제너레이터 모듈(245)로 이루 어져 있고, 최상위 계층(250)은 메시지 로깅 모듈(251)과 모니터링 모듈(252), 과금모듈(253), 관리자 모듈(254) 등으로 이루어져 있다.

도 3을 참조하면, 가장 아래 계층인 SIP 파서/제너레이터(210)는 네트워크 소켓을 통해 수신한 스트림 형태의 메시지를 SIP 메시지 구조체로 파싱(parsing)해서 상위 레이어로 넘겨주거나, 상위 레이어로부터 처리 완료된 SIP 메시지 구조체를 스트림 형태로 다시 생성한다.

SIP 전송 매니저(220)는 SIP 요구/응답 메시지를 보낼 위치 및 방법을 결정하고, SIP 트랜잭션 매니저(230)는 SIP 트랜잭션을 관리한다. SIP에서는 요구(Request) 메시지에 대한 하나 이상의 최종 응답(Response) 수신시까지를 하나의 트랜잭션(transaction)으로 관리하는데, SIP 트랜잭션 매니저(230)는 요구 메시지 재전송 및 타이머 관리, 응답 메시지 수신에 대한 요구 메시지 매칭 등의 작업을 수행한다.

SIP 트랜잭션 매니저(230) 위에는 실질적인 SIP 메시지 처리 동작을 수행하는 SIP 프락시 매니저 계층(240)이 존재한다. SIP 콜 매니저(241)에서는 특정 콜러(Caller)와 콜리(Callee) 사이에 설정된 호(call)와 관련된 다이얼로그 및 호 정보를 관리한다. 또한 인증모듈(244)은 SIP 메시지 인증을 담당하고, SDP P/G 모듈(245)은 SIP 메시지 바디에 전송되어 온 SDP(Session Description Protocol) 정보를 파싱하고 제너레이팅한다. 그리고 레지스트라 접속 모듈(243)은 레지스트라 서버(110)에 접속해서 레지스트라에 등록된 접속 주소를 얻어오고, DNS Query 모듈(242)은 SIP 메시지 전송을 위한 다음 홉에 대한 아이피(IP), 주소(Address), 포트(Port) 정보를 제공한다.

SIP 프락시 서버 시스템의 최상위 레이어(250)에는 프락시 서버 시스템 관리를 위한 시스템 모니터링(252), 및 메시지 로깅 모듈(251), 정의된 과금 정책에 따른 과금 부여기능 등을 담당하는 과금모듈(253)들이 존재한다.

이상에서 설명한 바와 같이 본 발명의 SIP 프락시 서버 시스템(200)은 각각의 레이어로 모듈화되어 있으므로, 추가적인 기능 요구 시 특정 레이어 모듈의 변경만으로 처리될 수 있다. 예컨대, 프락시 동작 변경을 위해서는 SIP 호 매니저 레이어(240)에서의 변경만을 요하며, SCTP나 TLS와 같은 전송 방법을 추가하고자 한다면 SIP 트랜스포트 매니저(230)에 라이브러리를 추가하고, 상위 레이어와의 인터페이스만 제공하면 된다. 또한, SIP의 확장 메소드나 헤더들을 제공하기 위해서는 SIP 파서/제너레이터 레이어(210)를 변경하고 프락시 매니저(240)에서의 추가 메소드에 대한 처리 동작만 기술하면 되므로 SIP 확장이 용이하다.

도 4a,b는 본 발명에 따른 프락시 서버 내에서의 콜 관리를 위한 구조체의 각 연관관계를 도식화한 도면으로서, 전역변수 구조체인 호 리스트 테이블(callListTBL[MAX_CALL]; 310)과, 호 정보(Call_t; 330), 다이얼로그(Dialog_t; 330), 서버 트랜잭션(Transaction_t; 340), 클라이언트 트랜잭션(Transaction_t; 350-1,350-2)의 관계가 도시되어 있다.

도 4a를 참조하면, 먼저 배열 형태의 전역 변수로 선언된 콜 정보(320)와 각 콜 정보 내에 생성될 다이얼로그 정보(330)와 각 다이얼로그 정보 내에 위치할 트랜잭션(340,350-1,350-2)에 관련된 정보를 포함하는 형태를 가진다. 이때 각 정보 들을 단계별로 구분함으로써 전반적인 성능의 최적화를 추구하였다. 도 4a에서는 실제 사용되는 각 구조체의 모든 정보들 중 대표적인 것에 대해서만 표현하였으며, 각 정보들의 검색 및 처리에 키 값이 되는 값들은 음영을 넣어 표현하였다.

호 설정(Call Set-up) 요구을 받게 되면, 전역변수 구조체인 호 리스트 테이블(CallListTBL; 310)에서 빈 칸을 찾아서 그곳에 값을 설정해 넣으며, 하위로 차례로 다이얼로그(330), 트랜잭션 정보들(340,350-1,350-2)을 생성하게 된다. 다이얼로그(330)의 경우에는 동시에 서버 트랜잭션(TLS: Server Transaction; 340)과 클라이언트 트랜잭션(TLC: Client Transaction; 350-1,350-2)으로 동작을 하게 되므로, 하나의 다이얼로그 구조체 내에 두개의 트랜잭션 정보를 수용하게 된다. 각 콜, 다이얼로그, 트랜잭션들은 각기 내부 스테이트를 유지하며, 스테이트의 상태에 따라 동작하게 된다.

이와 같은 콜 관련 정보들은 도 4b에 도시된 바와 같이 구조체로 표현되는데, 서버 트랜잭션이나 클라이언트 트랜잭션은 모두 같은 구조체를 사용하고 있으며, 트랜잭션의 특성에 따라 필요한 변수를 사용하게 된다.

하나의 INVITE 요구 메시지를 수신하였을 경우, 프락시 내부에서는 그 콜에 대한 콜 정보가 생성되며, 해당 콜 정보의 하위로 하나의 다이얼로그정보가 생성된다. 그리고 포킹(forking)등의 이유로 이 INVITE 요구 메시지의 목적지가 N개일 경우, 하나의 다이얼로그내에 N개의 클라이언트 트랜잭션이 발생되며, 하나의 서버 트랜잭션이 발생된다. 클라이언트 트랜잭션의 개수는 레지스트라 서버(110)에 해당 사용자에 대해 등록되어 있는 주소 수만큼 발생이 된다.

도 5a 내지 도 5d는 본 발명에 따라 호에 대한 정보를 유지하는 SIP 프락시 서버 시스템에서의 요구 메시지 처리 과정을 도식화한 것이다.

도 5a 내지 도 5d를 참조하면, 본 발명에 따른 요구 메시지 처리과정은 SIP 메시지를 파싱하는 단계(501), 요구(Request) 메시지이면, 유효성을 검사하는 단계(502,503), 요구 메시지를 전처리하여 해당 메소드에 따라 처리하는 단계(504), 인바이트(INVITE), 옵션(OPTION), 언노운(UNKNOWN) 메소드이면, 호 리스트 테이블(310)에서 해당 호 정보(320)를 검색하여 있으면 호 정보에서 다이얼로그 정보(330)를 검색한 후 리퀘스트 핸들러(CM_RequestHandler)를 수행하고, 없으면 호 등록하는 단계(505~511), 캔슬(CANCEL) 메소드이면, 호 리스트 테이블(310)에서 해당 호 정보(320)를 검색하여 있으면 호 정보에서 다이얼로그 정보(330)를 검색한 후 캔슬 핸들러(CM_CancelHandler)를 수행하고, 없으면 에러 응답하는 단계(512~516), ACK 메소드이면, 호 리스트 테이블(310)에서 호 정보(320)를 검색하고, 호 정보에서 다이얼로그 정보(330)를 검색한 후 ACK 핸들러(CM_AckHandler)를 수행하는 단계(518~521), BYE 요구 처리 단계(517), 등록(REGISTER) 요구 처리 단계(522)으로 이루어진다.

여기서, 호 정보(320)는 콜 아이디(CallID)와, 다이얼로그 정보(pDialog)로 이루어지고, 다이얼로그 정보(330)는 From 정보(pFrom), To 정보(pTo), 페어런트콜(pParentCall), 서버 트랜잭션(pTLS), 클라이언트 트랜잭션(pTLC)로 이루어지며, 트랜잭션(340,350-1,350-2)은 시퀀스번호와 메소드(CSeq), 수신 SIP 메시지(pRcvdSIPMsg), 페어런트 다이얼로그(pParentDialog), 콜러 어드레스정보(pCallerAddrInfo)를 포함한다.

또한 리퀘스트 핸들러(510)는 도 5b에 도시된 바와 같이, 인바이트(INVITE) 핸들러와 언노운(UNKNOWN) 핸들러, 옵션(OPTION) 핸들러로 이루어지고, 어크 핸들러(521)는 도 5c에 도시된 바와 같으며, 캔슬 핸들러(515)는 도 5d에 도시된 바와 같다.

즉, 새로운 쓰레드로 수행되는 프로세스 프록싱(ProcessProxying()) 함수가 수행되며, 파스 SIP 메시지(ParseSIPMsg())함수가 호출되어 SIP 트랜스포트 매니저(220)로부터 받은 문자열 데이터를 SIP 메시지 구조체로 파싱한다(501). 요구(Request) 메시지 파싱 수행시 에러가 발생한 경우에는 400 “Bad Request” 응답(Response) 메시지를 전송한다. 이상이 없을 경우에는 수신된 메시지가 요구 메시지인지 응답 메시지인지에 따라 처리동작이 구분된다(502).

요구 메시지일 경우에는 요구 유효성 검사 함수(Process Request ValidationCheck())를 통해 요구 메시지 유효성 검사를 수행한다(503). 그 이후 메시지 라우팅과 관련된 전처리 과정을 요구 전처리함수( RequestPreProcessing())를 통해 수행하게 되고, 각 메소드별로 적절한 함수를 호출한다. 여기서, 메소드로는 6가지의 기본 메소드(INVITE, ACK, BYE, CANCEL, OPTION, REGISTER)와 언노운 메소드가 있다.

다른 호스트를 지칭하는 라우트(Route) 헤더가 존재하지 않는 INVITE/ OPTIONS/ UNKNOWN 요구 메시지를 수신한 경우, 프락시 서버(200)는 해당 호에 대한 정보를 관리한다. 만약 Route 헤더가 존재하거나, Request-URI가 다른 호스트를 지칭할 경우에는 해당 주소로 수신 메시지를 직접 송신해 준다(outbounding).

먼저 호 정보를 관리해야 할 메시지를 수신하게 되면, 내부 호 테이블(310)로부터 이미 호 정보가 있는지를 점검한다. 존재할 경우에는 재전송으로 판단하며, 존재하지 않을 경우에는 프락시(proxy) 내부의 CallListTBL(310)에 새로운 호 정보를 생성하여 등록한다. 그리고 하위 브랜치들에 대한 트랜잭션을 활성화시켜 메시지를 전송시킨다.

그리고 리퀘스트 핸들러(CM_RequestHandler;510)가 수행되는데, 인바이트 핸들러(CM_InviteHandler)와 언노운 핸들러(CM_UnknownHandler), 옵션 핸들러(CM_OptionsHandler)를 호출한다.

도 6a, 6b는 본 발명에 따른 프락시 서버 시스템에서의 응답 메시지 처리 과정 흐름도로서, 각 응답 코드별 처리과정을 도식화한 것이다.

도 6a 및 도 6b를 참조하면, 본 발명의 응답 메시지 처리과정은 SIP 메시지를 파싱하는 단계(601)와, 응답(Response) 메시지이면, 응답 메소드에 따라 호 리스트 테이블(310)에서 호 정보(320)를 검색하는 단계(602~609), 호 정보에서 다이얼로그 정보(330)를 검색하는 단계(610), 및 응답 핸들러(611)를 호출하는 단계로 이루어진다.

그리고 응답 핸들러(611)는 도 6b에 도시된 바와 같이, 클라이언트 트랜잭션 1xx(TLC_1xx) 핸들러와, 클라이언트 트랜잭션 2xx (TLC_2xx) 핸들러와, 클라이언트 트랜잭션 3xx (TLC_3xx) 핸들러와, 클라이언트 트랜잭션 4xx (TLC_4xx) 핸들러와, 클라이언트 트랜잭션 5xx (TLC_5xx) 핸들러와, 클라이언트 트랜잭션 6xx (TLC_6xx) 핸들러로 이루어진다.

즉, 응답 메시지의 경우에는 파싱 이후에 특별한 유효성 점검 과정을 필요로 하지 않으며, 수신한 메시지로부터 키값(Call-ID, From, To, CSeq, branch)을 가져온 후 해당 키값을 통해 내부 콜 테이블(310)로부터 일치하는 트랜잭션 정보들을 검색한다.

만약, 검색 결과가 없으면 내부에 콜 테이블로써 관리하지 않는 콜로 판단하여 비아(Via)에 명시된 주소로 송신되거나 폐기된다. 그리고 메시지의 상태 코드에 따라 각 코드 클래스에 해당하는 함수로 분기된다. 각 응답(OnRecvXxxResponse) 함수들은 내부적으로 응답 핸들러(TL_ResponseHandler)를 호출하게 되는데, 이는 트랜잭션 매니저 레이어(230)에서의 동작을 처리하기 위한 과정이며, 이 과정을 마친 이후 다시 응답 핸들러(CM_ResponseHandler; 611)에게 이후의 동작을 맡기게 되며, 각각의 상태 코드에 대한 프락시 서버의 동작을 취하게 된다. 도 6a에서 1xx응답은 Provisional을 나타내고, 2xx응답은 Success, 3xx응답은 Redirection, 4xx응답은 Client Error, 5xx응답은 Sever error, 6xx응답은 Global Failure를 나타낸다.

이상에서 설명한 바와 같이, 본 발명의 프락시 서버는 기능별로 모듈화 되어 있으며, 양 단말간의 호 설정을 위한 콜 정보들을 다양한 구조체들을 이용하여 효율적으로 관리하는 효과가 있다. 즉, 본 발명의 프락시 서버는 각 모듈별로 기능 이 세분화되어 있고, 모듈간의 인터페이스는 세부 함수 또는 라이브러리 형태로 제공되고 있으므로 SIP 프락시 서버 시스템 개발 및 향후 SIP 기능 변경, 확장이 용이하다. 또한 체계적인 콜 정보 관리를 통해 전체적인 서버 구조를 단순화하고, 에러 수정 및 이후 버전으로의 확장성이 용이하다.

상기에서는 본 발명의 바람직한 실시예를 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다.

Claims

네트워크 소켓을 통해 수신한 스트림 형태의 메시지를 SIP 메시지 구조체로 파싱해서 상위 계층으로 넘겨주거나 상위 계층으로부터 처리 완료된 SIP 메시지 구조체를 스트림 형태로 다시 생성하는 SIP 파서/제너레이터;

상기 SIP 파서/제너레이터의 상위에 위치하여 SIP 요구/응답 메시지를 보낼 위치 및 방법을 결정하는 SIP 전송 매니저;

상기 SIP 전송 매니저의 상위에 위치하여 SIP 트랜잭션을 관리하기 위한 SIP 트랜잭션 매니저;

상기 SIP 트랜잭션 매니저의 상위에 위치하여 실질적인 SIP 메시지 처리 동작을 수행하는 프락시 매니저 계층; 및

상기 프락시 매니저 계층의 상위에 위치하여 프락시 서버 시스템 관리를 위한 시스템 모니터링, 및 메시지 로깅, 정의된 과금 정책에 따른 과금 부여기능 등을 담당하는 최상위 계층을 포함하여 모듈화되어 있고,

상기 프락시 매니저 계층은, 특정 콜러(Caller)와 콜리(Callee) 사이에 설정된 호(call)와 관련된 다이얼로그 및 호 정보를 관리하는 SIP 콜 매니저와, SIP 메시지 인증을 담당하는 인증모듈과, SIP 메시지 바디에 전송되어 온 SDP(Session Description Protocol) 정보를 파싱하고 제너레이팅하는 SDP 파싱/제너레이팅 모듈과, 레지스트라 서버에 접속해서 레지스트라에 등록된 접속 주소를 얻어오는 레지스트라 접속 모듈과, SIP 메시지 전송을 위한 다음 홉에 대한 아이피(IP), 주소(Address), 포트(Port) 정보를 제공하는 DNS Query 모듈을 포함하는 것을 특징으로 하는 인터넷 전화 서비스를 위한 프락시 서버 시스템.
삭제
제1항에 있어서, 상기 SIP 트랜잭션 매니저는

요구 메시지 재전송 및 타이머 관리, 응답 메시지 수신에 대한 요구 메시지 매칭을 수행하는 것을 특징으로 하는 인터넷 전화 서비스를 위한 프락시 서버 시스템.