간단한 예재를 통하여 SIP 동작을 설명
atlanta.com . . . biloxi.com
. proxy proxy .
. .
Alice's . . . . . . . . . . . . . . . . . . . . Bob's
softphone SIP Phone
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| 100 Trying F3 |--------------->| INVITE F4 |
|<---------------| 100 Trying F5 |--------------->|
| |<-------------- | 180 Ringing F6 |
| | 180 Ringing F7 |<---------------|
| 180 Ringing F8 |<---------------| 200 OK F9 |
|<---------------| 200 OK F10 |<---------------|
| 200 OK F11 |<---------------| |
|<---------------| | |
| ACK F12 |
|------------------------------------------------->|
| Media Session |
|<================================================>|
| BYE F13 |
|<-------------------------------------------------|
| 200 OK F14 |
|------------------------------------------------->|
| |
Figure 1: SIP session setup example with SIP trapezoid
이 예제는
- Alice와 Bob 사이의 SIP 메시지 전단을 나타냄
- Alice는 SIP softphone 사용
- Bob은 SIP phone 사용
- Alice와 Bob편의 프록시 서버
Alice는 Bob의 SIP URI, SIPS RUI를 이용하여 calls 함
SIP URI, SIPS URI는 email address 폼과 비슷하며 Caller가 직접 타이핑하거나 하이퍼링크 클릭, 주소록을 이용
SIPS URI는 보안을 위하여 사용되며 TLS라 불리는 encrpyted transport는 이용하여 caller에서 calleee까지 전달
HTTP와 비슷한 request/response transaction model을 사용
Request 메시지의 예
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
- method 이름은 invite
header fields
- Via : 이 request가 전달되고 response 전달해줄 주소, transaction 키로 사용될 branch 파라매터를 가짐
- To : display name, SIP 또는 SIPS URI로 이루어짐, request가 도착하여야할 최종 도착지
- From : display name, SIP 또는 SIPS URI로 이루어짐, request의 최초 생성자, tag 파라매터를 가짐
- Call-ID : call을 구별하기 위한 global identifier를 포함, 임의의 문자열과 host name, host ip의 조합으로 생성, To tag, From tag, Call-ID를 이용하여 dialog id 생성
- CSeq or Command Sequence : integer와 method 이름으로 구성, dialog에서 새로운 request 생성시 1씩 증가
- Cantact : Alice의 direct route 주소, FQDN 방식을 사용하며 IP 주소 역시 사용 될 수 있음, 후에 request를 보낼 element를 나타냄
- Max-Forwards : request가 유지 될 최대 홉수
- Content-Type : 메시지 바디의 타입
- Content-Length : 메시지 바디의 길이 (8진수)
- Via : 이 request가 전달되고 response 전달해줄 주소, transaction 키로 사용될 branch 파라매터를 가짐
SIP를 이용하여 media, codec, sampling rate등과 같은 세션의 세부적인 사항은 표현 할 수 없음
메시지 바디에 SDP와 같은 또다른 프로토콜을 사용하여 정의 할 수 있음
Alice의 소프트폰은 Bob가 타 도메인에 위치하기 때문에 Alice가 위치한 도메인의 proxy 서버에게 request를 전달함
proxy 서버의 주소는 미디 셋팅하거나 DHCP와 같은 프로토콜을 사용하여 찾을 수 있음
- Alice가 atlanta.com SIP 프록시 서버에 request를 보냄
atlanta.com SIP 프록시 서버는 Alice에게 100 (Trying)을 보냄
- 100 (Trying) response는 Alice에게 메시지를 잘 받았고 처리를 하고 있음을 나타냄
- response에는 INVITE 메시지와 동일한, To, From, Call-ID, CSeq, Via의 branch 파라매터가 있음
- 100 (Trying) response는 Alice에게 메시지를 잘 받았고 처리를 하고 있음을 나타냄
atlanta.com SIP 프록시 서버가 biloxi.com SIP 프록시 서버에 request를 보냄
- biloxi.com SIP 프록시 서버는 DNS 룩업을 통하여 찾음
- request 메시지의 Via 헤더 필드에 자신의 주소를 추가함
- biloxi.com SIP 프록시 서버는 DNS 룩업을 통하여 찾음
- biloxi.com SIP 프록시 서버는 altanta.com SIP 프록시 서버에게 100 (Trying) response를 보냄
biloxi.com SIP 프록시 서버는 Bob에게 request를 보냄
- Bob의 IP 주소는 location service라 불리는 database에서 가져옴
- request 메시지의 Via 헤더에 자신의 주소를 추가함
- Bob의 IP 주소는 location service라 불리는 database에서 가져옴
Bob's phone은 180 (Ringing) response를 biloxi.com SIP 프록시 서버에게 전달 -> Via의 순으로 Alice까지 전달
- response의 경우는 DNS나 location service가 필요 하지 않음
Bob이 전화를 받으면 biloxi.com SIP 프록시 서버에게 200 (OK) response를 보냄 -> Via의 순으로 Alice 까지 전달
- 200 (OK) response의 메시지 바디에 SDP 포함 될 수 있으며 SDP는 offer/answer 모델임
Response 메시지의 예
Via: SIP/2.0/UDP server10.biloxi.com
;branch=z9hG4bKnashds8;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com
;branch=z9hG4bK776asdhds ;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)
response는 response code (200) 와 reason phrase (OK) 로 시작됨
Via, To, From, Call-ID, CSeq 헤더 필드는 INVTE request에서 복사
To 헤더 필드에 tag 추가
Cantact 헤더 필드는 Bob에 직접 연결 가능한 주소
DNS와 location service의 경우는 486 (Busy Here) response가 발생하였을 경우, 프록시가 Bob's의 보이스 메일로 보내거나 forking 하는데 사용함
위의 예제에서 200 (OK) reponse는 두개의 proxy를 거쳐서 Alice에게 도착하고 Alice는 ACK 메시지는 보냄, 이때 ACK는 response의 Contact 헤더 필드를 이용하여 Bob에게 직접 전달하게 됨
미디어 세션이 만들어 진후, SDP 교환으로 패킷의 포맷을 결정한 후 종단 간 미디어 패킷을 보내게 되는때 이 때의 path는 시그널링에 사용된 패스와 다름
세션 중간에 re-INVITE를 통하여 미디어 세션의 특징을 바꿀 수 있음
새로운 세션을 만드는 것이 아님 수정만 이루어짐
200 (OK) 와 ACK를 받게되면 변환이 성공 한 것이고 만약 실패를 하더라도 이전의 상태로 세션이 유지 됨
BYE 메시지를 생성하고 200 (OK) 메시지를 받으면 세션과 BYE transaction이 종료함
ACK는 보내지 않음, ACK는 INVITE 메시지의 응답으로만 사용
Record-Route 헤더 필드
- 프록시가 세션이 진행되는 동안의 모든 메시지를 보고 싶을때 사용
- 프록시의 IP 주소와 hostname 구성됨
Registration
- one way
- REGISTER 메시지는 SIP 또는 SIPS URI와 Contact 헤더 필드의 정보를 연관을 바인딩이라 하고 이 정보를 location server라 불리는 database에 저장
- 논리적인 개념이며 물리적 개념은 아님
- 하나이상의 디바이스에 대하여 registration이 가능
Location service
- 추상적 개념
- 하나의 URI에 대하여 0 혹은 다수의 URI와 바인딩 되어져 있음
- Registrain은 구성하기 위한 한 방법임, 다른 방법도 존재(관리자에 의한 입력등)
OPTION 메소드는 SIP서버 혹은 클라이언트의 특징을 알아내기 위하여 사용됨
CANCEL 메소드는 pending request를 처리하기 위하여 사용
'Protocol > SIP' 카테고리의 다른 글
| 06. Definitions (0) | 2013.09.25 |
|---|---|
| 05. Structure of the Protocol (0) | 2013.09.25 |
| 02. Overview of SIP Functionality (0) | 2013.09.25 |
| 01. Introduction (0) | 2013.09.25 |
| ABOUT SIP (0) | 2013.09.25 |