IMS - IP Multimedia Subsystem

IMS - IP Multimedia Subsystem

IMS 배경

개요

• IMS = IP Multimedia Subsystem
• 3GPP에서 규정

국내 실정

• SKT, KTF, LGT의 IMS 도입준비
  • SKT는 EVDO 서비스부터 코어망에 IMS 일부 도입하였으며
  • IP 기반의 CSCF(대용량 교환기), PHSS(가입자 정보관리) 등을 잇다라 구축중
• KT는 BcN(Broadband Convergence Network)을 지원하는 IMS 인프라 구축함
  • 다양한 융합 서비스 제공 전망
  • 유선전화 가입자와 이동전화 가입자간 화상통화/인스턴트 메신저 가능

IMS 표준화

표준화 기구

• 3GPP (3rd Generation Partnership Project) : IMT-2000 (W-CDMA, CDMA2000) 표준화 추진, 유럽과 일본방식
• 3GPP2 : CDMA2000 표준화 추진, IMS는 3GPP 따름
• OMA (Open Mobile Alliance) : 많은 관련회사가 가입, 개방적 프로토콜 이나 인터페이스를 채용한 구조를 채택

3GPP 릴리즈

• 거의 매년 릴리즈를 실시
• 릴리즈 99 : RAN(Radio Access Network) + 코어 네트워크(=CS 도메인 + PS 도메인) 으로 구성
• 릴리즈 4 : 소프트 스위치 방식 도입
• 릴리즈 5 : IMS, HSDPA, 2세대 RAN
• 릴리즈 6 : 2004년 12월
  • 회선교환 네트워크와 비 IMS 네트워크 연동
  • 그룹관리 (Presence, Messaging, 회의 서비스 용)
  • 과금
  • 무선 LAN 연동
  • MBMS (Multimedia Broadcast and Multicast Service)
  • Presence
  • Push
  • Poc (Push-to-talk over Cellular)
• 릴리즈 7
  • AIPN (All IP Network)에의 이행
  • PAN(Personal Area Network) 및 PN(Personal Network) 의 통합
  • WiMAX 통합
  • LTE (Long Term Evolution)
  • SAE (System Architecture Evolution)
    

IMS 개요

IMS는

• PS 도메인과 접속해,
• 종래 CS 도메인에서 제공된 실시간 서비스를 IP 기술로 제공
• 논의를 통해 CS 도메인을 없애는 것은 현실적 격차로 인해 공존하는 방향으로 진행됨

IMS 요구사항

• IP 멀티미디어 서비스 (음성, 비디오)
• Qos : 지연, 패킷로스 등을 해결해야함
• 기존 네트워크 접속 : 인터넷, PSTN, 이동망
• 로밍 : 해외에서도 같은 서비스를
• 다양한 서비스의 빠른 제공
• 다양한 액세스망에 대응 : 릴리즈6에서 추가됨. 이동망 뿐아니라 고정네트워크를 이용한 액세스 에도 대응되야함 (LAN, FTTH 등의 IP 고정 액세스 등..)

IMS 구조

IMS 구조

기본 프로토콜

• SIP
• Diameter
• H.248 / MEGACO

구간	용도	이름	프로토콜
CSCF↔CSCF	CSCF 사이의 SIP 메시지의 교환	Mw	SIP
CSCF↔Multimedia IP Network	SIP으로 시그널링을 하는 IP network과 CSCF 사이의 SIP 메시지의 교환	Mm	SIP
S-CSCF↔BGCF	PSTN으로 나가는 호에 대해서 S-CSCF가 BGCF로 SIP 메시지를 포워딩하는 역할	Mi	SIP
S-CSCF↔MRFC	S-CSCF가 MRF의 자원을 제어하기 위한 인터페이스	Mr	SIP
CSCF↔HSS	S-CSCF 선택을 위한 I-CSCF와 HSS 사이의 정보교환 및 가입자 정보의 전달을 위한 인터페이스	Cx	DIAMETER
CSCF↔SLF	CSCF가 적절한 SLF로 부터 HSS의 주소를 얻기 위한 인터페이스	Dx	N/A
S-CSCF↔OSA SCS S-CSCF↔SIP AS	S-CSCF에서 AS를 triggering하고 제어하기 위한 인터페이스	ISC	SIP
UE↔CSCF	UE와 CSCF에게 등록, 호의 착/발신, 부가서비스 제어,인증 등을 하기 위한 인터페이스	Gm	SIP
GGSN↔Multimedia IP Network GGSN↔P-CSCF GGSN↔MGW	GPRS 망이 GGSN을 통한 관문으로 IP network으로 연결되는 부분	Gi	IP
GGSN↔PCF	PCF가 GGSN의 bearer 사용에 대한 정책(policy)을 적용하기 위한 인터페이스	Go	COPS
HSS↔OSA SCS HSS↔SIP AS	AS가 HSS로부터 서비스 제어에 필요한 사용자 정보를 조회하는 인터페이스	Sh	N/A
SIP AS↔MRFC	AS가 MRF의 자원을 제어하기 위한 인터페이스	Sr	SIP
OSA SCS↔OSA AS	OSA API를 사용하는 SCS와 AS 간의 인터페이스	-	Parlay
BGCF↔MGCF	BGCF가 PSTN 착신 호가 나갈 MGCF를 결정한 후 SIP 메시지를 포워딩 하는 인터페이스	Mj	SIP
MGCF↔MGW	MGCF가 MGW를 제어하기 위한 인터페이스	Mc	MEGACO
MGCF↔S-CSCF	MGCF가 PSTN으로부터 들어오는 ISUP 호를 SIP 메시지로 변환 후 그 SIP 메시지를 S-CSCF로 포워딩 하는 인터페이스	Mg	SIP
MRFC↔MRFP	MRFC가 MRFP를 제어하기 위한 인터페이스	Mp	MEGACO
BGCF↔BGCF	다른 망으로 향하는 PSTN 착신 호를 BGCF 간에 포워딩 하기 위한 인터페이스	Mk	SIP
TE↔MT	TE가 MT에게 GGSN과의 PPP 연결을 요구하는 인터페이스	R	AT command

기능블럭

• 세션 제어 기능 블럭 : P-CSCF, S-CSCF, I-CSCF
• 홈 가입자 서버 블럭 : HSS, SLF
• 어플리케이션 서버 블럭 : AS
• 멀티미디어 제어 기능 블럭 : MRFC, MRFP
• 기존망과의 게이트웨이 블록 : MGCF IM-MGW, SGW, BGCF
• QoS 제어 블록 : PCRF, PCEF
  

IMS 기본 프로토콜 > (1) SIP

개요

• Session Initiation Protocol
• 멀티미디어 회의, 원격 수업을 실시하기 위해 개발된 프로토콜
• Session : IP Network에 접속한 단말간 멀티미디어 통신
• SIP : 세션의 개시, 종료, 제어 기능을 제공
• 표준문서 : IETF RFC3261

서버, 클라이언트 모델

• UAC (User Agent Client) : 세션 요청 메시지 보낸 측
• UAS (User Agent Server) : 세션 요청 메시지 수신하는 측

텍스트 기반 메시지

• HTTP, SMTP 처럼 텍스트를 기반으로 함

메소드와 상태코드

• Message : 개시행 + Header + Space + Body
  • 개시행 : 요청시 (메소드명, 요청 URI, SIP 버전), 응답시 (SIP 버전, 상태코드, 응답구문)
  • Header : To, From, Contact, Cseq, Call-ID 등..
  • Body : 세션정보, 미디어정보(주소, 코덱), SDP(Session Description Protocol)
• 주요 SIP 메소드
  • INVITE : 세션 확립
  • ACK : INVITE의 수신 확인
  • BYE : 세션종료
  • CANCEL : 처리중 요청을 중지
  • OPTIONS : 다른 UA나 서버의 능력을 문의
  • REGISTER : 유저의 현위치 등록 (유저의 Public URI와 현재의 Location 매핑)
  • INFO : PSTN의 호출 제어 신호를 전달
  • NOTIFY : SIP UA에 특정의 이벤트를 통지
  • PRACK : 잠정 응답의 수신을 확인
  • PUBLISH : 정보를 서버에 업로드
  • SUBSCRIBE : 특정 이벤트의 통지 예약
  • UPDATE : 세션의 내용을 변경
  • MESSAGE : 인스턴트 메시지를 송신
  • REFER : 상대의 SIP UA에 대해 지정된 리소스에 컨택트하는 것을 요구
• 응답 메시지의 상태코드
  • 1xx : 잠정, 요청이 수신되어 처리가 계속중
  • 2xx : 성공, 요청이 성공
  • 3xx : Redirect, 요청 처리할 수 있는 다른 URI 정보를 줌
  • 4xx : 클라이언트 에러, 요청 내용에 문제가 있어 처리 못함
  • 5xx : 서버 에러, 서버측 문제로 실패
  • 6xx : 글로벌 에러, 어느 서버에서도 처리 못함.

Transaction & Dialog

• Transaction
  • 하나의 Request와 Response 묶음
  • 응답이 다수일때, 도중에 오는것은 "잠정 응답", Transaction 끝나는 것은 "최종 응답"
  • 만약 초기 Request가 INVITE이고 마지막 Response가 non-2xx이면 ACK도 또한 Transaction에 포함된다
• Dialog
  • 세션을 설정하고 종료할때까지 (일정 시간 동안의 지속성을 가진 두 종단간의 SIP 관계)
  • 성립 : 세션 설정하는 최초의 Transaction 완료시
  • 종료 : 세션 종료하는 Transaction 완료시
  • INVITE와 Response (i.e 200 OK) 과정이 끝나면 생성 되며, 헤더 필드의 Call-ID, To-tag, From tag로 구분됨
• Session
  • Dialog의 생성 후, offer/answer 메세지 교환(stream의 지원 여부 : codec, IP, Port값 포함)이 끝나면 또한 session이 생성.
  • BYE 메세지로 session과 dialog의 종료가 이루어진다.

기존 프로토콜과의 조합

• RTCP, RTP, SMTP, HTTP.....

SIP의 기본 요소

• UA (User Agent) : UAC, UAS
• SIP 서버
  • 등록 서버 : 레지스트라, UA 위치정보 등록
  • Proxy 서버 : 요청/응답을 중계
  • Redirect 서버 : 요청 메시지의 수신측 요청에 이용하는 서버
  • Location 서버 : 등록 서버의 지시에 의해 UA 위치 정보를 저장하는 기능, Proxy서버, Redirect 서버의 요청에 대응

SIP Architecture

Proxy Server

Location Server

SDP (Session Description Protocol)

• 세션을 기술하기 위한 텍스트 포멧임 --> 프로토콜은 아니다
• 세션 기술 : 세션 레벨 정보 + 미디어 레벨 정보
  • 세션 레벨 정보 : 버전, 유저 ID, 세션명, IP 주소, 세션 유효시간 등..
  • 미디어 레벨 정보 : 미디어 스트림 정보 (어떤 미디어가 어느 방향으로..)
• 포멧 : type=value

SIP 처리과정 예제

상기의 그림을 간략히 설명하자면, 먼저 Alice는 Bob과 통화하기 위해서 INVITE 메시지(F1, F2, F4))를 Bob에게 전송한다. 이때 Alice의 media type에 대한 정보가 Body에 실려 전달된다(아래의 SIP 요청 메시지 예시 참고). INVITE 메시지가 Bod의 단말에 전달되면 전화벨이 울리고(F6, F7, F8), 그 상태를 다시 Alice에게 알려준다(F9, F10, F11). 전화벨이 울린후, Bob이 전화를 받으면 통화를 할려고 한다는 메시지를 Bob의 media type 정보와 함께 Alice에게 전해주고, Alice는 ACK 메시지(F12)를 Bob에게 전송함으로써 통화를 시도하는 Alice와 Bob이 media type이 일치함을 알리고, 실제 통화를 위해 Media Session이 오픈된다. 통화가 끝난뒤 Bob이 통화를 종료하면 BYE 메시지(F13)가 Alice에게 전달되고, Alice는 Bob에게 Media Session을 종료하는 BYE 메시지가 정상적으로 처리되었음을 알리는 200 OK 메시지를 전송(F14)함으로써 통화(Media Session)가 종료되게 된다.

F1 INVITE 메시지 구조

F9 200 OK 메시지 구조

SIP 헤더 [필수요소] 

• Request-URI
  - 메시지의 첫째줄에 들어가는 값으로  To header의 URI와 동일한 값으로 설정. 
  - REGISTER 인 경우에는 “@”이 없는 domain name 으로 설정.
  - Request-URI 예시
  
      sip:alice@atlanta.com
      sips:alice@atlanta.com?subject=project%20x&priority=urgent
      sip:+1-212-555-1212:1234@gateway.com;user=phone
      sips:1212@gateway.com
      sip:alice@192.0.2.4
      sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com
  
  
  
• To
  - Request의 논리적인 수신자.
  - 목적지 UA(User Agent)나 종단지점의 URI(Uniform Resource Identifier) 포함
  - tag parameter는 UAS가 response 생성시 포함. (tag는 포킹 Proxy 서버를 경유하여 복수의 다른 상대에 도달시 각각을 구별하기 위해 사용됨)
  - To 예시
  
     To: Bob <sip:bob@biloxi.com>
  
  
  
• From
  - Request 메시지 전송자의 식별 정보. 
  - 디스플레이 이름과 요청을 보내는 UA의 URI 포함
  - tag parameter를 반드시 포함해야 한다.
  - From 예시
  
     From: “Bob” <sips:bob@biloxi.com> ;tag=a48s    
    
  - tag parameter는 Call-ID 와 함께 dialog를 식별하기 위한 정보로써, 세계적으로  유일하고 암호화된 값이어야 한다.
  
  
• Call-ID
  - 일련의 메시지들을 group하기 위한 unique identifier.
  - Dialog에서 UA가 보낸 모든 request와 response에 대해 같아야 하고 UA로부터의 각 registration에서 같아야 함.
  - SIP UA는 Call-ID 헤더 필드가 다른 UA에 의해 중복 생성되지 않음을 보장하는 수단을 가져야 함.
  - 암호화된 random ID 사용을 권고함. (RFC 1750)
  - Authentication을 위해 request를 재전송하는 경우에도 Call-ID를 새로 할당하면 안된다.
  - Call-ID 예시
  
     Call-ID: a84b4c76e66710@pc33.atlanta.com
  
  
  
• CSeq
  - transaction을  식별하고  정렬하는 방법으로서의 역할을 함.
  - Sequence no와 method로 구성, method는 request의 것과 같아야 함.
  - CSeq 예시
  
     CSeq: 4711 INVITE
  
  
  
• Max-Forwards
  - destination까지 가면서 transit할 수 있는 hop의 수를 제한
  - 각 hop에서 1씩 감소, request가 목적지에 도착하기 전에 0이 되면 483(Too Many Hops) error response를 보냄.
  - Max-Forwards 예시
  
      Max-Forwards: 70
  
  
  
• Via
  - 사용될 전송 프로토콜과 SIP 버전 포함.
  - 송신자가 그 요청에 대한 응답을 받을 수 있게 보장하는 IP 주소도 또한 포함.
  - 호출시 각 프록시 서버는 이 필드에 자신의 IP 주소를 넣음으로써 응답이 이 곳을 통해 가도록 한다.
  - transaction에 사용될 transport 이름과 version 정보,  response가 보내질 location을 표시
  - branch parameter가 포함되어야 하며, 그 request가 생성한 transaction을 identify한다.
  - branch는 “z9hG4bK”로 시작(magic cookie로 사용됨)
  - Via 예시
  
     Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds

SIP 헤더 [선택요소] 

• Contact
  - 유저가 직접 통신하기 위한 URI 정보를 나타냄 (q:퀄리티값, expires:기한)
  - SIP 요청 메시지 구성시 반드시 필요한 요소를 구성한 다음에는 SIP 요청 메시지를 보내는 UAC 자신의 주소 정보를 Contact 값으로 지정하여 구성한다.
  - 추후 UAS가 SIP 응답 메시지를 전송할때 이전에 수신한 SIP 요청 메시지의 Contact 정보를 참조하여 해당 주소로 전송한다.
  - 일단 호출이 수립되고 난 후 목적지 UA가 요청 UA로 접속하는 데 필요한 정보
  - UA가 이후의 request를 위해 사용할 SIP 또는 SIPS URI. INVITE 전송 시에는 필수 header 임.
  - Contact 예시
  
      Contact: <sip:alice@pc33.atlanta.com>
  
  
  
• Require
  - UAC가 해당 request를 처리하기 위해 필요한 extension을 명시하기 위해 사용. 이를 수신한 UAS가  자신이 처리할 수 있는 extension을  열거하여 response를 전송함.
  - Require 예시
  
     UAC->UAS:  
                    INVITE sip:watson@bell-telephone.com SIP/2.0
                    Require: 100rel
     UAS->UAC:  
                    SIP/2.0 420 Bad Extension
                    Unsupported: 100rel
  - 상기의 예시는 UAS가 이를 수신하면 모든 Provisional Response를 신뢰성 있게 전송해야 한다는 의미이다. 즉, "RFC3262 - Reliability of Provisional Responses in the SIP" 규격을 지원함을 말한다. 그런데 UAS는 UAC한테 난 그렇게 못해라고 응답하고 있다.

SIP 예제 및 헤더 정보 출처 : 몽키몽키 http://blog.naver.com/cache798/130026756994

세션 설정시 참고사항

• Record-Route 사용여부
  • Proxy서버가 보안, 필터링, 방화벽, 특정서비스(BYE시 통화시간 통지 서비스) 등의 기능이 있을때 모든 message가 경유하며 message를 저장함

• 세션 설정후 INVITE 요청
  • 세션 내용을 변경하고 싶을때 갱신된 SDP를 포함한 INVITE를 보내면 됨 --> re-INVITE
  • UPDATE 도 동일 목적시 사용하지만, 수신측에서 변경의 확인이 필요없는 경우에 사용됨

 

IMS 기본 프로토콜 > (2) Diameter

개요

• AAA를 지원하는 프로토콜 (Ahentication:인증, Authorization:인가, Accountin:어카운팅)
• RADIUS (Remote Authentication Dial In User Service)를 기반
• 표준문서 : IETF RFC 3588
• 서버 클라이언트 모델
• 헤더부(커맨드 정보, 메시지 송수신 제어 정보), AVP(Attribute-Value Pair) 로 구성
• 참고 : http://www.ibm.com/developerworks/libra ··· dex.html

Diameter Message

IMS에서의 Diameter

IMS 기본 프로토콜 > (3) H.248 / MEGACO

개요

• ITU 와 IETF가 공동 개발하여서 이름이 2개임. (ITU에서는 H.248, IETF에서는 MEGACO)
• MEGACO : MEdia GAteway COntrol
• 기존 Soft Switch 구조의 기본 기술인 MGCP (Media Gateway Control Protocol)을 발전시킨 것임
• 참고 : http://blog.empas.com/enigma1980/15577118

Megaco Connection Model  : Termination, Stream, Context

• 멀티미디어를 지원하기 때문에(※ MGCP는 음성신호전용) context 내에서 여러 종류의 스트림을 전달할 수 있다. 따라서 한 context내에서 몇 개의 termination이 존재할 수 있다.
• Termination MG내에서 media stream, control stream, 등을 생성하고 전송하는 논리적인 연결 구성요소(logical entity) 이며, context내에서 termination 사이의 관계에 대한 사항을 정의 한다.
• Stream context에 전송되는 Media Flow를 의미한다.
  

 

IMS 기능 블록 > (1) 세션제어 기능 블럭

P-CSCF (Proxy-CSCF)

• 유저가 IMS망에 최초로 억세스하는 지점임, 위치 등록시 할당되는 SIP 서버임
• UE로부터 정의안된 SIP 메시지 차단
• UE로부터 요청에 따른 다른 CSCF 로 전송
• UE로부터 엑세스가 없는 경우, 세션 종료

S-CSCF (Serving-CSCF)

• 세션제어 중심적인 SIP 서버임
• 유저 단말정보를 HSS에 전송
• HSS로부터 다운로드 받은 가입자 정보를 보관 유지
• B2BUA 기능 : 세션의 개시, 종료, SIP 메시지 경로를 찾음
• 필요시 AS 서비스 처리를 기동

I-CSCF (Interrogating-CSCF)

• 다른 망으로부터 SIP 메시지를 수신하는 게이트웨이 성격의 SIP 서버임
• 유저가 위치 등록할때 해당하는 HSS를 선택
• 자신의 망내의 적절한 S-CSCF에게 UE의 메시지 전송
• 타 망에 대해 자신의 망 구성을 은폐하는 THIG(Toplogy Hiding Internetwork Gateway) 기능이 옵션 기능으로 있음

example : Registration Path

 

IMS 기능 블록 > (2) 홈 가입자 서버 블록

HSS (Home Subscriber Server)

• 세션제어, 서비스제어에 필요한 모든 정보를 저장
• 이동통신의 UE의 물리적 위치정보(즉, 기지국 정보)를 저장하고 있는 HLR과 연동
• 저장정보
  • 가입자 식별정보 (서비스 가입 상황 등..)
  • 유저 인증 정보
  • S-CSCF 선택 정보
  • 개별 어플리케이션을 선택하기 위한 정보 (User Profile)
  • IN(이동용 지능형 네트워크)의 CAMEL 지원 정보

SLF (Subscriber Locator Function)

• IMS망내에 복수개의 HSS존재시, 해당 유저 정보 가진 HSS를 찾기 위한 정보를 가짐
• I-CSCF, S-CSCF, AS 에서 필요시 액세스함
• 1개의 HSS 존재시 필요없음

IMS 기능 블록 > (3) 멀티미디어 제어 기능 블록

MRFP (Multimedia Resource Function Processor)

• 음성, 비디오 등의 Stream을 Mix, 생성, 처리
  

MRFC (Multimedia Resource Function Controller)

• SIP 메시지를 IMS 내의 다른 서버와 송수신하여, MRFP를 제어하는 기능
• MRFP 제어시 H.248/MEGACO 를 사용함

 

IMS 기능 블록 > (4) 어플리케이션 서버 블록

AS(Application Server)를 동작시키는 서버

• 개별 Application Service는  AS에서 제공 --> AS는 S-CSCF와 SIP 메시지를 송수신해야함
• AS 동작 방법
  • SIP 직접 제어
  • 개방형 API 를 사용 --> Parlay
  • 기존의 IN(즉, CAMEL) 활용

• 참고 : http://blog.naver.com/wlsqor2/40043506374
• parlay_sdp_연동방안-sunsky98.pdf
  
  
  

User Profile

• S-CSCF에 의해 다양한 서비스를 제공하기 위해 SIP 메시지 종류에 따른 조건을 저장 필요 --> HSS내에 User Profile 로 저장됨
• 구성 = PUI (Public User ID) + 필터 조건 (Trigger Point + Trigger Point 조건 일치시 SIP 전송하는 AS정보)
• 참고 : http://www.3gdb.org/doc/overview-summary.html
  

 

IMS 기능 블록 > (5) 기존망과 연계된 게이트웨이 블록

• IM-MGW (IP Multimedia-Media Gateway) : IP Network와 Circuit Network 간의 음성,비디오 변환기능
• MGCF (MGW Control Function) : IMS의 SIP와 Circuit Network의 ISUP간의 Signaling의 변환, IM-MGW 제어
• BGCF (Breakout Gateway Control Function) : IMS로 전송한 세션 요청 메시지가 Circuit Network에 착신할때, 전송할 MGCF 를 선택
• SGW (Signaling Gateway) : SIP <--> ISUP 변환

 

IMS 기능 블록 > (6) QoS 제어 블록

• PCRF (Policy and Charging Rules Function) : 정책을 결정
• PCEF (Policy and Charging Enforcement Function) : 정책을 실행, 실제로 미디어를 취급하는 GGSN 내에 존재
• PCRF & PCEF 사이의 프로토콜 :  릴리즈6까지는 COPS, 릴리즈7부터는 Diameter 를 사용
  

 

User ID

• Private User ID : 등록, 인증용
• Public User ID
  • 서비스, 세션제어용
  • URI로 표현
  • SIP URI 또는 Tel URI

 

과금

• 오프라인 과금 (후불)
  • CSCF, AS로부터의 CDR(Call Data Record)를 통해 정기적으로 요금이 청구
  • P-CSCF 에서 과금 식별자(ICID) 생성 후, 각 서버에 알림
  • CCF(Charging Collection Function)에서 과금 수집하여 청구
• 온라인 과금 (선불)
  • 세션 과금 : 세션 설정시 잔고가 없으면 세션 종료하는 방식
  • 이벤트 과금 : 액세스시에 일정액 인출하는 정액제 / 단위 요금마다 인출하는 종량 과금제
  • Bearer 과금 : IP 패킷량에 따른 과금방식 / 시간에 따른 과금방식

 

참고사이트

http://www.tech-invite.com/Ti-sip-archi.html
http://theimsjungle.wordpress.com/