SIP 메시지 구조

SIP 메시지 구조



SIP는 각 사용자들을 구분하기 위해 이메일 주소와 비슷한 다음과 같은 SIP URL을 사용하여 사용자는 IP 주소에 종속되지 않고 서비스를 제공받을 수 있다. 참고로 REGISTER 메시지인 경우에는 “@”이 없는 domain name 으로 설정한다.


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


상기의 그림을 간략히 설명하자면, 먼저 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)가 종료되게 된다.



상기의 SIP 동작 절차중 F1 INVITE 메시지 구조는 다음과 같다.

상기의 SIP 동작 절차중 F9 200 OK 메시지 구조는 다음과 같다

상기와 같이 제시된 SIP 메시지를 요소별로 살펴보면 START LINE에는 요청할 Method 종류와 SIP URI를 기술하고, HEADER에는 Session을 제어하기 위한 값들이 설정된다. BODY에 는 Content-Type에 설정된 타입의 내용이 들어가게 된다. 상기에서 제시된 SIP 메시지 예제에서는 Content-Type 값이 application/sdp로 설정되어 있으므로 BODY에는 SDP를 이용한 media type에 대해 기술한다. 참고로 HEADER와 BODY 사이는 반드시 공백라인(CR/LF)를 두어 이를 구분해야 한다.



제시된 SIP 메시지 예제에서 보는바와 같이 SIP 메시지는 크게 Header와 Body로 구분된다. 구럼 우선 SIP Header 요소들에 대해 살펴보자. SIP Header 요소중 필수 요소는 다음과 같다.


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 생성시 포함.

- To 예시

To: Bob

From
- Request 메시지 전송자의 식별 정보.

- 디스플레이 이름과 요청을 보내는 UA의 URI 포함

- tag parameter를 반드시 포함해야 한다.
- From 예시

From: “Bob” ;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 Header 요소중 선택 요소는 다음과 같다.



Contact
- SIP 요청 메시지 구성시 반드시 필요한 요소를 구성한 다음에는 SIP 요청 메시지를 보내는 UAC 자신의 주소 정보를 Contact 값으로 지정하여 구성한다.

- 추후 UAS가 SIP 응답 메시지를 전송할때 이전에 수신한 SIP 요청 메시지의 Contact 정보를 참조하여 해당 주소로 전송한다.

- 일단 호출이 수립되고 난 후 목적지 UA가 요청 UA로 접속하는 데 필요한 정보

- UA가 이후의 request를 위해 사용할 SIP 또는 SIPS URI. INVITE 전송 시에는 필수 header 임.
- Contact 예시

Contact:



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한테 난 그렇게 못해라고 응답하고 있다.