2010년 01월 05일
2010년도 공인중개사 시험
# by | 2010/01/05 12:39 | 트랙백 | 덧글(0)
2009년 09월 11일
[RFC 3261] Session Initiation Protocol (기본)
=================================== Keyword ======================================
=================================== Overview ======================================
RFC 3261는 SIP Protocol의 기본이 되는 권고안이다.
SIP Protocol을 통해 기본적인 호처리를 하기위한 모든 것이 설명되어 있다.
이외의 추가 RFC들은 추가적인 기능들과 보완을 위한 권고안인 것이다. 따라서 RFC 3261를 반드시 이해를 해야 한다.
RFC 3261의 기본적인 내용을 분류하여 정리한다.
섹션은 총 6가지로 이루어 진다.
1. 기본
2. Method
3. Header
4. UAC
5. UAS
6. Proxy
이번 챕터는 말그대로 기본이 되는 사항을 설명한다.
=================================== Table of Contents ==============================
1 Introduction ........................................ 8
2 Overview of SIP Functionality ....................... 9
3 Terminology ......................................... 10
4 Overview of Operation ............................... 10
5 Structure of the Protocol ........................... 18
6 Definitions ......................................... 20
7 SIP Messages ........................................ 26
7.1 Requests ............................................ 27
7.2 Responses ........................................... 28
7.3 Header Fields ....................................... 29
7.3.1 Header Field Format ................................. 30
7.3.2 Header Field Classification ......................... 32
7.3.3 Compact Form ........................................ 32
7.4 Bodies .............................................. 33
7.4.1 Message Body Type ................................... 33
7.4.2 Message Body Length ................................. 33
7.5 Framing SIP Messages ................................ 34
--------------------------------------------------------------
21 Response Codes ...................................... 182
21.1 Provisional 1xx ..................................... 182
21.1.1 100 Trying .......................................... 183
21.1.2 180 Ringing ......................................... 183
21.1.3 181 Call Is Being Forwarded ......................... 183
21.1.4 182 Queued .......................................... 183
21.1.5 183 Session Progress ................................ 183
21.2 Successful 2xx ...................................... 183
21.2.1 200 OK .............................................. 183
21.3 Redirection 3xx ..................................... 184
21.3.1 300 Multiple Choices ................................ 184
21.3.2 301 Moved Permanently ............................... 184
21.3.3 302 Moved Temporarily ............................... 184
21.3.4 305 Use Proxy ....................................... 185
21.3.5 380 Alternative Service ............................. 185
21.4 Request Failure 4xx ................................. 185
21.4.1 400 Bad Request ..................................... 185
21.4.2 401 Unauthorized .................................... 185
21.4.3 402 Payment Required ................................ 186
21.4.4 403 Forbidden ....................................... 186
21.4.5 404 Not Found ....................................... 186
21.4.6 405 Method Not Allowed .............................. 186
21.4.7 406 Not Acceptable .................................. 186
21.4.8 407 Proxy Authentication Required ................... 186
21.4.9 408 Request Timeout ................................. 186
21.4.10 410 Gone ............................................ 187
21.4.11 413 Request Entity Too Large ........................ 187
21.4.12 414 Request-URI Too Long ............................ 187
21.4.13 415 Unsupported Media Type .......................... 187
21.4.14 416 Unsupported URI Scheme .......................... 187
21.4.15 420 Bad Extension ................................... 187
21.4.16 421 Extension Required .............................. 188
21.4.17 423 Interval Too Brief .............................. 188
21.4.18 480 Temporarily Unavailable ......................... 188
21.4.19 481 Call/Transaction Does Not Exist ................. 188
21.4.20 482 Loop Detected ................................... 188
21.4.21 483 Too Many Hops ................................... 189
21.4.22 484 Address Incomplete .............................. 189
21.4.23 485 Ambiguous ....................................... 189
21.4.24 486 Busy Here ....................................... 189
21.4.25 487 Request Terminated .............................. 190
21.4.26 488 Not Acceptable Here ............................. 190
21.4.27 491 Request Pending ................................. 190
21.4.28 493 Undecipherable .................................. 190
21.5 Server Failure 5xx .................................. 190
21.5.1 500 Server Internal Error ........................... 190
21.5.2 501 Not Implemented ................................. 191
21.5.3 502 Bad Gateway ..................................... 191
21.5.4 503 Service Unavailable ............................. 191
21.5.5 504 Server Time-out ................................. 191
21.5.6 505 Version Not Supported ........................... 192
21.5.7 513 Message Too Large ............................... 192
21.6 Global Failures 6xx ................................. 192
21.6.1 600 Busy Everywhere ................................. 192
21.6.2 603 Decline ......................................... 192
21.6.3 604 Does Not Exist Anywhere ......................... 192
21.6.4 606 Not Acceptable .................................. 192
=================================== 내용 정리 ===================================
SIP Protocol은 H.323과 함께 Internet상의 기본적인 호처리를 위한 Signal Protocol이다.
SIP 1.0 Version (RFC 2543)에서는 H.323에 비하여 효용성이 떨어졌으나, 현재 2.0 Version을 Internet 망의 호처리 Protocol의 주를 이루며 사용되고 있다. (현재 한국의 기반망의 Signal Base는 SIP Protocol이 주를 이룬다.)
== 기본 Flow ==
옆의 그림은 SIP의 기본 Flow이다.
발/착신자가 INVITE -> 200 -> ACK Method를 주고 받으면서 기본적인 호처리 정보와 미디어 정보를 주고 받고, ACK를 수신한 시점부터 음성/영상을 주고 받으며 전화를 할 수 있게 된다.
RTP는 SIP를 통한 Signal이 성립된 이후 음성/영상 데이터를 주고 받는 또 다른 Protocol이다.
즉 SIP Protocol로 Signal처리가 완료되면, RTP Protocol을 이용하여 실제 음성/영상을 주고 받는 것이다.
BYE는 호를 종료할 때 사용되는 Method이다.
== SIP Message ABNF ==
String 기반의 SIP의 기본적인 메시지는 다음과 같은 형태를 같는다.
-------------------- SIP Message ABNF -----------------------------
generic-message = start-line
*message-header
CRLF
[ message-body ]
start-line = Request-Line / Status-Line
Request-Line = Method SP Request-URI SP SIP-Version CRLF
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
---------------------------------------------------------------------
"start-line" 은 SIP Version, 메시지의 Type과 착신자 정보 혹은 Response 정보등을 담는다.
메시지 Type는 Requset, Response로 나뉘는데 start-line의 형태를 보고 판별한다.
"message-header"는 호처리를 위한 정보를 담는다. 이 정보를 통하여 Proxy나 UAS/UAC가 동작한다.
필수로 들어가야 Header들도 있고, 추가적인 정보들을 담는 Header들도 있다.
"message-body"는 호처리 이외의 정보들을 담는다. Media를 주고받는 RTP Session을 생성하는 정보, SMS에 주고 받는 메시지 데이터등 여러 정보들을 가질 수 있다.
== Start Line ==
Start-Line은 위에서 말한것 처럼 기본적인 Message의 정보를 가지고 있다.
Start-Line이 Request-Line의 형태를 갖는다면, 이 메시지는 Request Message이고, Status-Line의 형태를 갖는다면 Response Message라고 판별한다.
이 Line을 한줄만 허용된다.
"Request-Line"의 Method는 이 Request Message가 무엇을 위한 것인지 판별하는데 사용된다.
"Request-Line"의 Request-URI는 다음 착신자의 정보를 갖는다. (이는 Loose-Route냐 Strict-Route냐에 따라 다르다.)
"Request-Line"의 SIP-Version은 이 메시지의 SIP Protocol Version을 의미한다. (기본적으로 상위 버전은 하위 버전을 호환하도록 설계 및 개발 되어야 한다. 실제 Version 1.0의 메시지가 오지 않더라도, 거의 모든 망업체의 요구 사항이다.)
"Status-Line"의 Status-Code는 Request Message를 받은 측에서 Message를 처리한 정보로 Request Message를 보낸 측에서 다음의 행동을 결정한다. 이 값은 범위가 정의되어 있다.
1xx: Provisional -- request received, continuing to process the request;
2xx: Success -- the action was successfully received, understood, and accepted;
3xx: Redirection -- further action needs to be taken in order to complete the request;
4xx: Client Error -- the request contains bad syntax or cannot be fulfilled at this server;
5xx: Server Error -- the server failed to fulfill an apparently valid request;
6xx: Global Failure -- the request cannot be fulfilled at any server.
현재 정의 된 이외의 Code 값을 추가적으로 정의 할 수 있지만, Resonse Code의 범위 값 내에서 정의 하는 것이 좋다.
"Reason-Phrase"는 Status-Code에 대한 추가적 정보로 반드시 있는 것은 아니며, 또한 권고안에서 정한 값이 아닐 수 있다. (애드팍 단말기중 구 버전은 이 부분이 없다면 단말기에서 Message를 처리 못하는 경우를 본적있다.)
== Message-Header==
Header의 기본형태는 다음과 같다.
-------------------- Header ABNF -----------------------------
header = "header-name" HCOLON header-value *(COMMA header-value)
---------------------------------------------------------------
항상 Header-name으로 시작하며 Header field값(Header-value)는 ":"으로 구분된다.
SIP Message에 반드시 하나만 넣을 수 있는 Header가 있는 반면, 연속된 멀티라인으로 구성할 수 있는 Header들이 존재 한다.
멀티라인으로 사용할 수 있는헤더는 반드시 연속되어야 한다는 것을 주의해야 하며, 한 Header의 최대 길이는 1000 character를 넘을수 없다는 것 또한 주의 해야 한다. (RFC 2822 Section 2.1.1 Line Length Limits)
== Message-Body ==
Message Body는 여러가지 형태를 갖는다. SDP형태 일반적인 String등 여러가지 형태를 지원한다.
Message Body는 SIP Message에 항상 존재해야하는 것은 아니다.
== Response Codes==
SIP Response Code는 위에 언급한 것처럼 범위가 정의 되어 있다.
1xx Response Code는 Final Response (2xx ~ 6xx) 이전에 UAS(Request를 수신한 측)에서 추가 적인 정보를 UAC(Request를 전달한 측)에게 전달 하기 위해서 사용된다.
권고안에서는 Final Response를 보내기 200 ms 이전에 1xx Response를 보내야 한다는 말이 있지만, 사실 그렇지도 않다. 18x Reponse 를 수신하지 못하고 200 Response를 받는다면 호처리에 성공하지 못하는 단말들도 꽤 있기때문에.. 어쩔수 없이 보내야 하는 경우도 있고, 또한 Server단에서는 1 ms 가 지나기도 전에 메시지를 처리 하는 경우도 있다. 따라서 순서에 맞게 전달 할 수 있게 설계하는 것이 좋다.
2xx Response Code는 Request에 대한 처리가 성공되었다는 것을 의미한다.
3xx Response Code는 Request를 다른 쪽으로 재전달 하라는 것을 의미한다.
4xx Response Code는 UAC의 Requset Message에 문제가 있어 Fai l되었다는 것을 의미한다.
5xx Response Code는 UAS에서 Request Message를 처리하다가 문제가 발생되어 Fail 되었다는 것을 의미한다.
6xx Response는 Global Fail Response Code로 Request Message처리에는 성공하였으나, 다른 이유로 호를 종료해야 하고자 할 때 사용된다.
== 기본적인 용어==
- Proxy Server : SIP Message를 중계해주는 역활을 하는 서버로, 사용자 등록을 위한 REGISTER 메시지처리, 호처리 메시지 중계, Location Server와의 연동을 통한 착신자 위치 찾기등을 담당한다.
IMS망의 거의 모든 SIP처리하는 서버(CSCF)도 기본적으로 Proxy의 기능을 기반으로 만들었다고 해도 과언이 아닐 것이다. - Register Server : Register 기능을 담당하는 서버로 Location Server에 사용자 위치등을 등록하는 기능을 담당
- Location Server : 사용자의 위치정보를 관리하며, Proxy에서 질의할 사용자의 정보를 알려주는 기능을 담당
- UAC : Request Message를 생성하여 전송하는 UA
- UAS : Request Message를 수신하여 처리하는 UA
- Dialog : 호 한개에 대한 Session 이라고 보면되는데, 호가 시작될 때 생성되며, 끝나는 시점까지 유지된다.
- Transaction : Reqeust메시지와 Response Message에 대한 처리의 한 과정 동안 유지되는데, Re-Trans 기능을 담당한다.
# by | 2009/09/11 10:00 | [SIP] | 트랙백 | 덧글(1)
2009년 09월 11일
[RFC 3261] Session Initiation Protocol (Method)
=================================== Keyword ======================================
=================================== Overview ======================================
Method는 이 Request Message가 어떤 용도이다는 것을 표현하는 부분이다.
따로 RFC 3261에서 정리하고 있지는 않지만, UAS, UAC, PROXY등을 이해 하려면, 기본적으로 알아야 하는 내용이다.
=================================== Table of Contents ==============================
없음
=================================== 내용 정리 ===================================
SIP Message는 Method 별로 용도가 다르다. 따라서 Method들을 이해 하고나서 UAC, UAS, PROXY등의 동작하는 것을 이해 하면 좋다. RFC 3261이후 그리고 이전에 여러 Method들이 존재 하지만, RFC 3261는 기본적인 호처리를 위한 Method들을 정의 하고 있다.
== OPTIONS Method ==
OPTIONS Method는 각각의 SIP Element들이 통신하는 상대측이 Capability 알아 내기 위해서 사용되는 Method이다.
지원하는 Method, 추가적인 기능등을 알기 위하여 사용되는데, 굉장히 심플하여 호처리에 어떠한 영향도 주지 않는다.
하지만, 이외에도 다른 방법들로 사용되는데, 사용가능한 자원의 양을 받아오기 위해서 사용하기도 하고, Network나 상대측 SIP Element가 이상이 없는지 판단하는데도 사용된다.
== REGISTER Method ==
REGISTER Method는 UA가 망에 등록하기 위하여 사용된다. 기본적인 연동 Flow는 웹을 검색하면 나오므로 설명하지 않겠다.
망에서는 단말의 정보를 가입시 등록하기도 하지만, REGISTER Method를 통하여 지원하는 Media나 기능등을 추가 정보로 저장하기도 한다.
예를 들어 가입자가 초기에 가입한 단말정보가 영상폰이 였다고 하자. 문제는 사용자가 영상단말이 고장나서 잠시 음성단말을 사용한다고 하자, 이때 3G 폰에서 전화가 왔다고 한다면? 이를 예외처리 하기 위해서 REGISTER Method에 지원가능한 Media도 등록하는 망도 있다.
== INVITE Method ==
INVITE Method는 호를 성립하기 위한 Method이다. 이 INVITE Method에는 접속정보, Caller 정보, Callee정보, Media 정보 등 여러가지 호를 성립하기 위한 정보가 들어간다.
== ACK Method ==
ACK Method는 UAS쪽에서 INVITE에 대한 Response가 UAC쪽에 전달되었는지 확인하기 위한 Method이다. 호가 성공처리가 되던, 실패가 되던 항상 UAC쪽에서 ACK가 UAS에 도착해야 호가 성립되거나, 정리 된다.
No-SDP INVITE를 사용한 경우에는 SDP가 ACK 메시지에도 존재 하는 경우도 있다.
== CANCEL Method ==
CANCEL Method는 호처리에 대하여 Final Response를 수신하기 전에 UAC쪽에서 호를 종료하고자 할 때 사용된다.
CANCEL Method를 수신한 Proxy들은 항상 같은 곳으로 Routing 해야한다는 특징이 있다.
== BYE Method ==
BYE Method는 호가 성립된 이후 종료하고자 할 때 사용된다.
# by | 2009/09/11 09:51 | [SIP] | 트랙백 | 덧글(0)
2009년 09월 11일
[RFC 3261]Session Initiation Protocol (Header)
=================================== Keyword ======================================
=================================== Overview ======================================
이번 챕터는 SIP Protocol에서 사용하는 Header들에 대한 설명이다.
SIP에서는 Header에 대한 개념이 없다면 거의 모르는 것이라고 봐야 할 정도로 중요한 내용이다.
Header들이 호처리를 위한 모든 정보를 표현하기 때문이다.
=================================== Table of Contents ==============================
20 Header Fields ....................................... 159
20.1 Accept .............................................. 161
20.2 Accept-Encoding ..................................... 163
20.3 Accept-Language ..................................... 164
20.4 Alert-Info .......................................... 164
20.5 Allow ............................................... 165
20.6 Authentication-Info ................................. 165
20.7 Authorization ....................................... 165
20.8 Call-ID ............................................. 166
20.9 Call-Info ........................................... 166
20.10 Contact ............................................. 167
20.11 Content-Disposition ................................. 168
20.12 Content-Encoding .................................... 169
20.13 Content-Language .................................... 169
20.14 Content-Length ...................................... 169
20.15 Content-Type ........................................ 170
20.16 CSeq ................................................ 170
20.17 Date ................................................ 170
20.18 Error-Info .......................................... 171
20.19 Expires ............................................. 171
20.20 From ................................................ 172
20.21 In-Reply-To ......................................... 172
20.22 Max-Forwards ........................................ 173
20.23 Min-Expires ......................................... 173
20.24 MIME-Version ........................................ 173
20.25 Organization ........................................ 174
20.26 Priority ............................................ 174
20.27 Proxy-Authenticate .................................. 174
20.28 Proxy-Authorization ................................. 175
20.29 Proxy-Require ....................................... 175
20.30 Record-Route ........................................ 175
20.31 Reply-To ............................................ 176
20.32 Require ............................................. 176
20.33 Retry-After ......................................... 176
20.34 Route ............................................... 177
20.35 Server .............................................. 177
20.36 Subject ............................................. 177
20.37 Supported ........................................... 178
20.38 Timestamp ........................................... 178
20.39 To .................................................. 178
20.40 Unsupported ......................................... 179
20.41 User-Agent .......................................... 179
20.42 Via ................................................. 179
20.43 Warning ............................................. 180
20.44 WWW-Authenticate .................................... 182
=================================== 내용 정리 ===================================
SIP Protocol에서 Header는 호처리에 대한 모든 정보를 표현하며, 이 값들을 이용하여 호의 성립, 추가 기능 제공, 호 종료에 이용된다.
Header는 사용에 관해서 여러가지 주의점이 있다.
최대길이 : 한 Header의 최대 길이는 1000 character를 넘을수 없다는 것 또한 주의 해야 한다. (RFC 2822 Section 2.1.1 Line Length)
멀티라인 : 멀티라인으로 표현되는 Header는 연속되어 있어야 한다. 한개만 사용할 수 있는 Header들도 존재 함으로, 사용에 주의 해야 한다.
사용 가능정보 : 사용할 수 있는 Message Type, Method등으 정의 되어 있다. 각 Header별로 그 사용할 수 있는 범위가 정의 되어 있으므로 사용에 주의 해야 한다.
== 사용정보 ==
Header는 Message Type(Request/Response)에따라, 혹은 Method에 따라 혹은 Response Code에 따라 사용여부가 다 다르다. 따라서 다음의 값을 알고 있어야 추가 Header들의 사용 가능 정보를 파악하기 용의할 것이다.
사용 가능 정보표현은 "where", "proxy", "method" 3가지 영역으로 나뉜다.
---------------------------- Where 사용 정보 --------------------------
R : 오직 Request Message에서만 사용할 수 있는 Header
r : 오직 Response Messag에서만 사용할 수 있는 Header
2xx, 4xx, etc : 지정된 Response Code 영역에서만 사용할 수 있는 Header
c : Request Message에서 값을 복사해서 Response에 사용해야 하는 Header
표시가 없으면 모든 Request, Response에서 사용이 가능한 Header를 의미한다.
------------------------------------------------------------------------
---------------------------- Proxy 사용 정보 --------------------------
a : Proxy에서 추가 가능한 Header
m : Proxy에서 변경만 할 수 있는 Header
d : Proxy에서 삭제만 할 수 있는 Header
r : Proxy에서 읽을수만 있는 Header
------------------------------------------------------------------------
---------------------------- Method 사용 정보 -------------------------
c : 조건에 따라 사용이 가능한 Header (Conditional)
m : 반드시 들어가야 하는 Header (Madatory)
m* : 사용할 수 있으나 UAC/UAS모두 Message에 이 Header가 존재하지 않아도 처리 할 수 있어야 한다.
o : 넣어도 되고 안넣어도 되는 Header (Optional)
t : m*와 동일하다. 하지만 TCP같은 Stream-based Protocol을 사용하는 Stack이라면 반드시 사용되어야 한다.
* : 이 Header들은 SIP Message Body가 존재한다면 반드시 사용되어 한다.
- : 적절치 못한 Header (사용하지 말라는 뜻, 사용하면 Fail Response 가 올 것이다.)
------------------------------------------------------------------------
위의 정보표현을 사용하여 각 Header별로 사용정보를 표현한 Table은 RFC 3261의 "Page 162" 부터 참고하면 된다.
== Accept Header ==
받아 들일 수 있는 Body Type을 표현한다. Optional이기에 Accept Header가 존재 하지 않는다면 UAS는 Default값인 "application/sdp"를 받을 수 있는 것으로 판단한다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Accept R - o - o m* o
Accept 2xx - - - o m* o
Accept 415 - c - c c c
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Accept = "Accept" ":" #( media-range [ accept-params ] )
media-range = ( "*/*" | ( type "/" "*" ) | ( type "/" subtype ) )
*( ";" parameter )
parameter = attribute "=" value
attribute = token
value = token | quoted-string
accept-params = ";" "q" "=" qvalue *( accept-extension )
accept-extension = ";" token [ "=" ( token | quoted-string ) ]
qvalue = ( "0" [ "." 0*3DIGIT ] ) | ( "1" [ "." 0*3("0") ] )
ex = "Accept : application/sdp, text/plain"
------------------------------------------------------------------------
== Accept-Encoding Header ==
받아 들일 수 있는 Body의 Encoding Type을 표현한다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Accept-Encoding R - o - o o o
Accept-Encoding 2xx - - - o m* o
Accept-Encoding 415 - c - c c c
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Accept-Encoding = "Accept-Encoding" ":" #( content-coding )
content-coding = token
ex = "Accept-Encoding : gzip"
------------------------------------------------------------------------
== Accept-Language Header ==
받아들일 수 있는 Reason phrases, Session Descriptions(SDP), Response의 Body등의 Language를 표현한다.
Header가 없다면 UAS는 UAC에서 모든 Language들을 받아 들일 수 있는 것으로 판단한다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Accept-Language R - o - o o o
Accept-Language 2xx - - - o m* o
Accept-Language 415 - c - c c c
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Accept-Language = "Accept-Language" ":" 1#( language-range [ ";" "q" "=" qvalue ] )
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
ex = "Accept-Language : da, en-gb;q-0.8
------------------------------------------------------------------------
== Alert-Info Header ==
INVITE에 있으면 UAS에서 Ring에, 180 Response에 있으면 UAC에서 Ring back tone에 사용할 음원정보를 표현한다.
하지만 실제로 이것을 사용하는 것은 본적이 없다.
일반적으로 단말은 일반적인 Signal 처리만 하고, 기반 망에 있는 MS (Media Server)에서 음원을 송출하는 형태를 보았다.
우리나라 최초의 MRBT Service 부터 특정 서버가 음원을 송출하도록 설계되어있다. (내가 모를 망에서는 사용할 지 모르지만..)
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Alert-Info R ar - - - o - -
Alert-Info 180 ar - - - o - -
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Alert-Info = "Alert-Info" ":" # ( "<" URI ">" *( ";" generic-param ))
generic-param = token [ "=" ( token | host | quoted-string ) ]
ex = "Alert-Info : <http://www.example.com/sounds/moo.wav>"
------------------------------------------------------------------------
== Allow Header ==
UA가 받아 들일 수 있고, 처리할 수 있는 Method의 List를 표현한다. 다른 SIP Element들과 통신 할 경우 처리가 불가능한 Method는 보내지 않도록 하는 예외처리 할 때 사용할 수 있다.
예를 들어 Session-Timer를 사용하려고 할 때, UPDATE가 Allow Header에 없다면 Re-INVITE를 사용하고, UPDATE가 있다면, UPDATE를 사용하여 Session Refrash를 할 수 있도록 하는 방법이다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Allow R - o - o o o
Allow 2xx - o - m* m* o
Allow r - o - o o o
Allow 405 - m - m m m
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Allow = "Allow" ":" 1#Method
Method = "INVITE" | "ACK" | "OPTIONS" | "BYE"
| "CANCEL" | "REGISTER" | extension-method
ex = "Allow : INVITE, ACK, CANCEL, BYE"
------------------------------------------------------------------------
== Authentication-Info Header ==
HTTP Digest로 상호인증을 할 때 사용된다. UAS에서 Reqeust의 Authorization Header field 값을 기본으로 Digest 인증에 성공한다면 2xx Response때 이 Header Field를 넣어야 한다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Authentication-Info 2xx - o - o o o
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Authentication-Info = "Authentication-Info" HCOLON ainfo *(COMMA ainfo)
ainfo = nextnonce / message-qop / response-auth / cnonce / nonce-count
nextnonce = "nextnonce" EQUAL nonce-value
response-auth = "rspauth" EQUAL response-digest
response-digest = LDQUOT *LHEX RDQUOT
ex = "Authentication-Info : nextnonce="468761df3s4df54sd51f351"
------------------------------------------------------------------------
== Authorization Header ==
인증처리를 위한 정보를 갖는다. 이 헤더의 특징은 멀티라인 룰과 싱글라인 룰을 따르지 않는다는 것이다.(??)
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Authorization R o o o o o o
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Authorization = "Authorization" ":" "pgp" # pgp-response
pgp-response = realm | pgp-version | pgp-signature
| signed-by | nonce
realm = "realm" "=" realm-value
realm-value = quoted-string
pgp-signature = "signature" "=" quoted-string
signed-by = "signed-by" "=" <"> URI <">
ex = "Authorizaation : Digest username="Alice", realm="atlanta.com", nonce="846a4sdf84sd", response="54as65df46"
------------------------------------------------------------------------
== Call-ID Header ==
Call을 구분지을 때 사용하는 Header이다. 이 값을 이용해서 각 Dailog를 구분하는데 사용하는데, Unique한 값을 사용해야한다.
하지만 이값이 항상 Unique하다는 것은 아니다. 생각 해보라 모든 단말기, 서버등이 자체적으로 만들어 내는데 어떻게 Unique하게 하겠는가? 그래서 Dialog나 Transaction을 찾을 때는, 이 값 이외에 Via branch, To/From Value와 Tag, CSeq값등을 사용하여 찾는다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Call-ID c r m m m m m m
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Call-ID = ( "Call-ID" / "i" ) HCOLON callid
callid = word [ "@" word ]
ex = "Call-ID: 923u5oijasdp9ufpoj@xxx.com"
------------------------------------------------------------------------
== Call-Info Header ==
Call-Info Header는 Callre나 Callee에 대한 추가적인 정보를 제공하기 위해 사용된다. (아직 망에서 특정용도로 사용해본적은 없다.)
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Call-Info ar - - - o o o
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Call-Info = "Call-Info" ":" # ( "<" URI ">" *( ";" info-param) )
info-param = "purpose" "=" ( "icon" | "info" | "card" | token ) | generic-param
ex = "Call-Info: <http://example.com/alice/photo.jpg>;purpose=icon,<http://example.com/alice/>;purpose=info"
------------------------------------------------------------------------
== Contact Header ==
Contact Header는 호를 위한 여러가지 정보를 갖는다.
- 호가 성립된 이후 자신이 받아 들일 수 있는 접속정보 (INVITE 등)
- 등록상태가 만료 되는 유지 시간 정보 (REGISTER)
- 자신이 지원하는 미디어 정보 (REGISTER, INVITE 등)
호가 성립될 때 각각의 UA는 자신의 접속정보를 Contact Header에 보내야 하며,
성립된 이후에는 각각의 UA는 상대방의 접속정보인 Contact Header Field값의 정보를 기억해야 한다.
하지만 망마다, 또는 단말 마다 아래 Header사용정보대로 지키지 않는 곳들이 있기 때문에(Contact Header가 없으면 Fail을 주는 곳이 있다.) 망에 맞추어 사용해야 된다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Contact R o - - m o o
Contact 1xx - - - o - -
Contact 2xx - - - m o o
Contact 3xx d - o - o o o
Contact 485 - o - o o o
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Contact = ( "Contact" | "m" ) ":"
("*" | (1# (( name-addr | addr-spec )
*( ";" contact-params ) )))
name-addr = [ display-name ] "<" addr-spec ">"
addr-spec = SIP-URL | URI
display-name = *token | quoted-string
contact-params = "q" "=" qvalue |
"action" "=" "proxy" | "redirect" |
"expires" "=" delta-seconds | <"> SIP-date <"> |
contact-extension
qvalue = ( "0" [ "." 0*3DIGIT ] ) | ( "1" [ "." 0*3("0") ] )
contact-extension = generic-param
generic-param = token [ "=" ( token | host | quoted-string ) ]
ex = "Contact: "JS.Song <SIP:JS.SOng@xxx.com>;expires=3600"
------------------------------------------------------------------------
== Content-Disposition Header ==
Content-Disposition Header는 Message Body가 어떠한지 묘사한다.
예를 들어 "session"이라는 Type값이 있다면, Body가 Session용 이라는 것을 말한다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Content-Disposition o o - o o o
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Content-Disposition = "Content-Disposition" ":" disposition-type *( ";" disposition-param )
disposition-type = "render" | "session" | "icon" | "alert" | disp-extension-token
disposition-param = "handling" "=" ( "optional" | "required" | other-handling ) | generic-param
other-handling = token
disp-extension-token = token
ex = "Content-Disposition : session"
------------------------------------------------------------------------
== Content-Encoding Header ==
Content-Encoding Header는 Body의 압축형태에 대해 묘사한다.
일반적인 호의 Body는 망에서는 최대 500~600 Byte를 넘지 않고, 비압축 하여 사용되기 때문에 이 Header는 사용되지 않는다. 아마 MMS나 이미지 전송같은데 사용되기 위해서 정의 된 것 같은데, 아직 본적은 없다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Content-Encoding o o - o o o
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Content-Encoding = ( "Content-Encoding" | "e" ) ":" 1#content-coding
content-coding = token
ex = "Content-Encoding : gzip"
------------------------------------------------------------------------
== Content-Language Header ==
권고안에서는 H14.12절을 보라고만 명시 되어 있다.
Accept-Language Header는 받아 들일 수 있는 Language를 표현한다고 설명했다. 이 Header는 실제 Body의 Language를 표현한다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Content-Language o o - o o o
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Content-Language = "Content-Language" ":" 1#language-tag
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
ex = "Content-Language : fr"
------------------------------------------------------------------------
== Content-Length Header ==
Content-Length Header는 Message Body의 길이를 표현한다.
주의점은 이 Header는 TCP같은 Stream-base Protocol 에서는 반드시 존재 해야 한다는 것이다.
UDP같은 Protocol에서는 Body가 없을 때는 이 Header가 메시지에 없어도 무방하게 처리 되어야 한다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Content-Length ar t t t t t t
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Content-Length = ( "Content-Length" | "l" ) ":" 1*DIGIT
ex = "Content-Length : 341"
------------------------------------------------------------------------
== Content-Type Header ==
Content-Type Header는 Body Type을 표현한다.
이 Header는 Body가 존재한다면 반드시 Message 내에 존재 해야 한다.
Body가 없다면 없어도 무방하다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Content-Type * * - * * *
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Content-Type = ( "Content-Type" | "c" ) ":" media-type
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
parameter = attribute "=" value
attribute = token
value = token | quoted-string
ex = "Content-Type: application/sdp"
------------------------------------------------------------------------
== CSeq Header ==
CSeq Header는 현재 메시지의 Sequence Number와 Method의 정보를 표현한다.
이 값을 이용하여 Transaction과 Dialog를 판별하며, 루핑같이 뒤늦게 들어오는 Message를 Discard하는 등의 정보로 사용된다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
CSeq c r m m m m m m
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
CSeq = "CSeq" ":" 1*DIGIT Method
ex = "CSeq: 1290481 INVITE"
------------------------------------------------------------------------
== Date Header ==
Date Header는 날짜와 시간을 표현한다. 각각의 UA끼리 동기를 맞추기 위해 사용된다는데..
* RFC 1123
호처리에 영향을 주는 것도 아니고, 실제로 잘 사용하지 않는 Header이다.
Media는 RTCP로 동기화 하고, Signal은 그렇게 시간과 상관없고.. 과금같은 경우는 NTP를 사용해서 처리도 가능하니..
과연, 어떠한 경우에 유용하게 사용되는지 모르겠다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Date a o o o o o o
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Date = "Date" ":" SIP-date
SIP-date = rfc1123-date
5.2.14 RFC-822 Date and Time Specification: RFC-822 Section 5
The syntax for the date is hereby changed to:
date = 1*2DIGIT month 2*4DIGIT* RFC 822
date-time = [ day "," ] date time
day = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun"
date = 1*2DIGIT month 2DIGIT
month = "Jan" / "Feb" / "Mar" / "Apr"
/ "May" / "Jun" / "Jul" / "Aug"
/ "Sep" / "Oct" / "Nov" / "Dec"
time = hour zone ; ANSI and Military
hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] ; 00:00:00 - 23:59:59
zone = "UT" / "GMT" / "EST"/ "EDT" / "CST"/"CDT" /"MST"/ "MDT" / "PST"/ "PDT"/ 1ALPHA
/ ( ("+" / "-") 4DIGIT )
ex = "Date: Sat, 13 Nov 2010 23:29:00 GMT"
------------------------------------------------------------------------
== Error-Info Header ==
Error-Info Header는 error status response의 추가적인 정보를 표현하기 위하여 정의 되었다.
하지만, 망에서는 이 Header보다 이후에 정의된 Reason을 주로 사용한다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Error-Info 300-699 a - o o o o o
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Error-Info = "Error-Info" ":" # ( "<" URI ">" *( ";" generic-param ))
generic-param = token [ "=" ( token | host | quoted-string ) ]\
ex = "Error-Info: <sip:not-in-service-recording@atlanta.com"
------------------------------------------------------------------------
== Expires Header ==
Expires Header는 Message가 Expires 되는 시간을 표현한다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Expires - - - o - o
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Expires = "Expires" ":" ( SIP-date | delta-seconds )
ex = "Expires : 60"
------------------------------------------------------------------------
== From Header ==
From Header는 Message의 발송자를 표현한다.
Caller, Callee를 의미 하는 것이 아닌 현재 메시지의 Request를 생성 및 발송한 UA를 표현 하는 것이므로,
호의 시작인 INVITE와 성립된 이후의 메시지에서 From의 값이 다를 수 있다는 것을 기억해야 한다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
From c r m m m m m m
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
From = ( "From" | "f" ) ":" ( name-addr | addr-spec ) * ( ";" from-param )
from-param = tag-param | generic-param
tag-param = "tag" "=" token
ex = "From: <sip:JS.Song@xxx.com>;tags=sadfi21x"
------------------------------------------------------------------------
== In-Reply-To Header ==
In-Reply-To Header를 이용하여 여러개의 Call-ID값을 Cache하고, 이 값으로 Call을 Filtering하는데 사용한다고 하는데..
하직 사용해 본적도, 요구하는 망의 FLow도 없었기에.. 정확한 사용용도는 모르겠다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
In-Reply-To R - - - o - -
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
In-Reply-To = "In-Reply-To" ":" 1# callid
ex = "In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com"
------------------------------------------------------------------------
== Max-Forwards Header ==
Max-Forwards Header는 SIP Message가 최대 Forward되는 횟수를 표현한다.
이 값을 이용하여 Looping을 방지하는데 사용되는데 각 Server는 Forward 할 때 마다 값을 확인하고,
1씩 감소한 값으로 변경해야 한다.
값의 범위는 0 ~ 255이지만 일반적으로 70부터 시작한다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Max-Forwards R amr m m m m m m
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Max-Forwards : "Max-Forwards" HCOLON 1*DIGIT
ex = "Max-Forwards : 70"
------------------------------------------------------------------------
== Min-Expires Header ==
Min-Expires Header는 Refresh Interval의 최소 값을 표현한다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Min-Expires 423 - - - - - m
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Min-Expires : "Min-Expires" HCOLON 1*DIGIT
ex = "Min-Expires : 70"
------------------------------------------------------------------------
== MIME-Version Header ==
권고안에서는 H19.4.1절을 보라고만 명시 되어 있다.
MIME-Version Header는 Message의 MIME-formatted를 표현한다.
아직 사용해 본적은 없다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
MIME-Version o o - o o o
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
MIME-Version = "MIME-Version" HCOLON 1*DIGIT "." 1*DIGIT
ex = "MIME-Version : 1.0"
------------------------------------------------------------------------
== Organization Header ==
Organization Header는 일반적으로 SIP Eelement의 개발한 곳의 정보를 표현한다.
즉, 회사명이 보통 들어간다. 호 처리 하고는 전혀 상관없다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Organization ar - - - o o o
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Organization : "Organization" HCOLON [TEXT-UTF8-TRIM]
ex = "Organization: SIP Stack by JS.SONG"
------------------------------------------------------------------------
== Priority Header ==
Priority Header는 SIP Message의 우선순위등을 표현하여 긴급한 메시지표현 할 때 사용한다고 한다.
예가 있기는 한데.. 정확히 어느 시점에 사용해야 하는지.. 모르겠다..
아직 망에서 보지 못했다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Priority R ar - - - o - -
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Priority = "Priority" HCOLON priority-value
priority-value = "emergency" / "urgent" / "nomal" / "non-urgent" / other-priority
other-pritority = token
ex = "Priority: nomal"
------------------------------------------------------------------------
== Proxy-Authenticate Header ==
Proxy-Authenticate Header는 인증처리를 하는 Proxy를 위하여 사용되는 Header이다.
Proxy-Authorization Header와 연계하여 사용된다.
아직 망에서 Proxy마다 인증처리를 요구하는 Header를 아직 본적이 없다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Proxy-Authenticate 407 ar - m - m m m
Proxy-Authenticate 401 ar - o o o o o
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge
challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) / other-challenge
other-challenge = auth-scheme / auth-param *(COMMA auth-param)
digest-cln = realm / domain / nonce / opaque / stale / algorithm
/ qop-options / auth-param
realm = "realm" EQUAL realm-value
realm-value = quoted-string
domain = "domain" EQUAL LDQUOT URI *( 1*SP URI ) RDQUOT
URI = absoluteURI / abs-path
opaque = "opaque" EQUAL quoted-string
stale = "stale" EQUAL ( "true" / "false" )
qop-options = "qop" EQUAL LDQUOT qop-value *("," qop-value) RDQUOT
qop-value = "auth" / "auth-int" / token
ex = "Proxy-Authenticate: Digest realm="atlanta.com",
domain="sip:ss1.carrier.com", qop="auth",
nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="", stale=FALSE, algorithm=MD5"
------------------------------------------------------------------------
== Proxy-Authorization Header ==
Proxy-Authorization Header는 Proxy에서 인증을 요구 하는경우 Client에서 생성하여 전달하는 Header이다.
인증에 관련된 정보가 이 Header에 값으로 사용된다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
__________________________________________________________
Proxy-Authorization R dr o o - o o o
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge
challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) / other-challenge
other-challenge = auth-scheme / auth-param *(COMMA auth-param)
digest-cln = realm / domain / nonce / opaque / stale / algorithm
/ qop-options / auth-param
realm = "realm" EQUAL realm-value
realm-value = quoted-string
domain = "domain" EQUAL LDQUOT URI *( 1*SP URI ) RDQUOT
URI = absoluteURI / abs-path
opaque = "opaque" EQUAL quoted-string
stale = "stale" EQUAL ( "true" / "false" )
qop-options = "qop" EQUAL LDQUOT qop-value *("," qop-value) RDQUOT
qop-value = "auth" / "auth-int" / token
ex = "Proxy-Authenticate: Digest realm="atlanta.com",
domain="sip:ss1.carrier.com", qop="auth",
nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="", stale=FALSE, algorithm=MD5"
------------------------------------------------------------------------
== Proxy-Require Header ==
Proxy-Require Header는 Proxy가 지원하고 사용하고자 하는 기능들을 표현하고자 할 때 사용된다.
동작방법 Require Header를 참조하면 된다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
__________________________________________________________
Proxy-Require R ar - o - o o o
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Proxy-Require = "Proxy-Require" HCOLON option-tag * (COMMA option-tag)
ex = "Proxy-Require : foo"
------------------------------------------------------------------------
== Record-Route Header ==
Record-Route Header는 Routing 정보를 UA에게 알려주기 위하여 사용된다.
Bob A (Proxy) B (Proxy) Allice
---- INVITE --->
----- INVITE ---->
(Record-Route : A )
----- INVITE ---->
(Record-Route : A, B )
<---- 200 Ok -----
(Record-Route : A, B )
<---- 200 Ok -----
(Record-Route : A, B )
<---- 200 Ok -----
(Record-Route : A, B )
이 때 주의 할 점은 UAS(Allice)는 Recored-Route의 값의 순서대로 이 Header값을 기억하면 되지만,
UAC(Bob)은 역순으로 이 Header값을 기억해야 한다.
그리고, ACK나 CANCEL Request Message는 Proxy에서 이 값과 관계없이 Down Stream을 기억하고 같은 곳으로 전달 해야 한다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
__________________________________________________________
Record-Route R ar o o o o o -
Record-Route 2xx,18x mr - o o o o -
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Record-Route = "Record-Route" HCOLON rec-route * (COMMA rec-route)
rec-route = name-addr * (SEMI rr-param)
rr-param = generic-param
ex = "Record-Route: sip:JS.SONG@Proxy_1.com;lr, sip:JS.SONG@Proxy_2.com"
------------------------------------------------------------------------
== Reply-To Header ==
Reply-To Header는 From Header와 다른 URI값을 갖는다.
이 Header의 값을 이용하여 다른 URI정보를 넘기는데 사용된다.
망에서 가끔 발신자 정보를 변경하기 위하여 사용되기도 한다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
__________________________________________________________
Reply-To - - - o - -
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Reply-To = "Reply-To" HCOLON rplyto-spec
rplyto-sepc = (name-addr / addr-spec) * (SEMI rplyto-param)
rplyto-param = generic-param
ex = "Reply-To: JS.SONG <sip:JS.SONG@xxx.com>
------------------------------------------------------------------------
== Require Header ==
Require Header는 UAC와 UAS간에 사용하고자 하는 기능을 option-tag를 이용하여 표현한다.
이 때, 지원하지 않는 기능을 요구할 때는 Fail Response를 수신하게 된다.
따라서 Supported로 지원되는 기능을 UAC에서 UAS에게 전달하여, 기능을 사용하고자 하던지,
또는 OPTIONS를 이용하여 미리 지원되는 기능을 판단후에 Request Header에 사용하는 것이 좋다.
대표적은 예로 PRACK을 사용하고자 하는 100rel option-tag다
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
__________________________________________________________
Require ar - c - c c c
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Require = "Require" HCOLON option-tag * (COMMMA option-tag)
option-tag = token
ex = "Require : 100rel"
------------------------------------------------------------------------
== Retry-After Header ==
Retry-After Header는 UAS에 요청한 Message에 대해서 UAS에서 일정시간후 재 시도 하라는 정보를 알려주고자 할 때 사용된다.
SIP Protocol의 주는 호연결 이고, 주체는 사람이므로, 자주 사용되는 Header는 아니다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
__________________________________________________________
Retry-After 404,413,480, - o o o o o
Retry-After 486,500,503 - o o o o o
Retry-After 600,603 - o o o o o
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Retry-After = "Retry-After" HCOLON delta-seconds [comment] * (SEMI retry-param)
retry-param = ("duration" EQUAL delta-seconds) / generic-param
ex = "Retry-After: 18000;duration=3600"
------------------------------------------------------------------------
== Route Header ==
Route Header는 Request Message가 가야할 Routing정보를 담고 있다. 이 정보와 Request-URI값을 이용하여 Proxy가 Next Hop을 결정하여 Message를 전달한다. Message를 전달 할때는 자신의 정보를 삭제하고 전달 해야 한다.
이때 이해해야 할 부분이 Strict-Routing과 Loose-Routing인데 이는 Proxy 에서 기술 하겠다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
__________________________________________________________
Route R adr c c c c c c
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Route = "Route" HCOLON route-param * (COMMA route-param)
route-param = naem-addr * (SEMI rr-param)
ex = "Route: sip:JS.SONG@Proxy_1.com;lr, sip:JS.SONG@Proxy_2.com"
------------------------------------------------------------------------
== Server Header ==
Server Header는 UAS의 software의 정보를 표현하는데 사용된다.
호처리하고는 전혀 상관없는 Header이다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
__________________________________________________________
Server r - o o o o o
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Server = "Server" HCOLON server-val * (LWS server-val)
server-val = product / comment
product = token [SLASH product-version]
product-version = token
ex = "Serve : JS.SONG Stack Ver.2"
------------------------------------------------------------------------
== Subject Header ==
Subject Header는 호의 정보를 표현하기 위해 사용된다.
망에서 이 Header를 특별한 의미로 사용하는 것은 아직 본적이 없다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
__________________________________________________________
Subject R - - - o - -
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Subject = ( "Subject" / "s" ) HCOLON [TEXT-UTF8-TRIM]
ex = "Subject: Go Home"
------------------------------------------------------------------------
== Supported Header ==
Supported Header는 지원하는 추가 기능을 상대측에 알려주기 위하여 사용된다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
__________________________________________________________
Supported R - o o m* o o
Supported 2xx - o o m* m* o
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Supported = ("Supported" / "k") HCOLON [option-tag * (COMMA option-tag)]
ex = "Supported : 100rel"
------------------------------------------------------------------------
== Timestamp Header ==
Timestamp Header는 UAC가 UAS에게 Request보낸 때를 표현하기 위해 사용된다.
실제 사용하는 망은 보지 못했다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
__________________________________________________________
Timestamp o o o o o o
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Timestamp = "Timestamp" HCOLON 1*(DIGIT) ["." *(DIGITI)] [LWS delay]
delay = *(DIGIT) ["." *(DIGITI]
------------------------------------------------------------------------
== To Header ==
To Header는 UAS를 표현한다. 이 값의 형태는 From Header와 동일 하다.
다른 점은 From Header는 UAC에서 tag를 생성하여 전달 하지만, To Header의 tag는 UAS에서 추가한다.
이 tag값은 호가 종료되는 시점까지 변경되지 않는다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
__________________________________________________________
To c(1) r m m m m m m
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
To = ( "To" | "t" ) ":" ( name-addr | addr-spec ) *( ";" to-param )
to-param = tag-param | generic-param
ex = "To: sip:JS.SONG@xxx.com;tag=s98ufijx"
------------------------------------------------------------------------
== Unsupported Header ==
Unsupported Header는 지원되지 않는 기능을 UAC에서 요구할 때 UAS에서 이를 알려주기 위해 사용된다.
지원하지 않는 기능을 Require Header를 이용하여 UAC에서 사용하자고 알려온다면,
UAS는 Fail Response에 Unsupported Header에 지원하지 않는 기능들을 알려줄 수 있다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
__________________________________________________________
Unsupported 420 - m - m m m
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Unsupported = "Unsupported" HCOLON option-tag *(COMMA option-tag)
ex = "Unsupported: 100rel"
------------------------------------------------------------------------
== User-Agent Header ==
User-Agent는 UAC의 정보를 표현하기 위해 사용된다.
호에 영향을 주지 않는다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
__________________________________________________________
User-Agent o o o o o o
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
User-Agent = "User-Agent" HCOLN server-val *(LWS server-val)
ex = "User-Agent: Softphone Beta 1.5"
------------------------------------------------------------------------
== Via Header ==
Via Header는 Request 메시지가 거처간 SIP Element의 정보를 가지며, 이 값을 사용하여 Response가 Routing될 정보로 사용된다. 추가적으로 Transaction을 판단하는데 이 Header의 Branch Tag가 사용되며, 그 외에도 여러 용도로 사용되는 중요 Header중에 하나이다.
중요한 점은 Brach의 값이 magic cookie "z9hG4bK"로 시작해야 한다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
__________________________________________________________
Via R amr m m m m m m
Via rc dr m m m m m m
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Via = ( "Via" | "v" ) ":" 1#( sent-protocol sent-by *( ";" via-params ) [comment] )
sent-protocol = protocol-name "/" protocol-version "/" transport
protocol-name = "SIP" | token
protocol-version = token
transport = "UDP" | "TCP" | token
sent-by = ( host [":" port] ) | ( concealed-host )
concealed-host = token
via-params = via-hidden | via-ttl | via-maddr | via-received |
via-branch | via-extension
via-hidden = "hidden"
via-ttl = "ttl" "=" ttl
via-maddr = "maddr" "=" maddr
via-received = "received" "=" host
via-branch = "branch" "=" token
via-extension = generic-param
generic-param = token ["=" ( token | quoted-string )]
comment = "(" *( ctext | quoted-pair | comment ) ")"
quoted-pair = " \ " CHAR
ex = "Via: SIP/2.0/UDP JS.SONG.proxy.com;brach=z9hG4bKa7c6a8dlze"
------------------------------------------------------------------------
== Warning Header ==
Waring Header도 Response의 추가적인 정보를 제공하고자 사용한다.
하지만, 잘 사용하지 않는 Header이다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
__________________________________________________________
Warning r - o o o o o
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
Warning = "Warning" HCOLON warning-value *(COMMA warning-value)
warning-value = warn-code SP warn-agent SP warn-text
warn-code = 3DIGIT
warn-agent = hostport / pseudonym
warn-text = quoted-string
pseudonym = token
ex = Warning : 301 isi.edu "Incompatible network address type 'E.164'"
------------------------------------------------------------------------
== WWW-Ahthenticate Header ==
WWW-Authenticate Header는 인증관련된 정보를 표현한다.
---------------------------- Header 사용 정보 -------------------------
Header field where proxy ACK BYE CAN INV OPT REG
__________________________________________________________
WWW-Authenticate 401 ar - m - m m m
WWW-Authenticate 407 ar - o - o o o
------------------------------------------------------------------------
---------------------------- Header ABNF -----------------------------
WWW-Authenticate = "WWW-Authenticate" HCOLON challenge
ex = "WWW-Authenticate: Digest realm="atlanta.example.com",
qop="auth", nonce="84f1c1ae6cbe5ua9c8e88dfa3ecm3459", opaque="",
stale=FALSE, algorithm=MD5 "
------------------------------------------------------------------------
# by | 2009/09/11 09:50 | [SIP] | 트랙백 | 덧글(0)
2009년 09월 10일
[Draft] Diversion Indication in SIP draft-levy-sip-diversion-10
=================================== Keyword ======================================
=================================== Overview ======================================
Diversion Header는 Call Forward시 사용하는데, 이 Header에는 Forward가 발생한 정보들을 담을 수 있다.
=================================== Table of Contents ==============================
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. When is the Diversion header used? . . . . . . . . . . . . 7
5. Extension syntax . . . . . . . . . . . . . . . . . . . . . . . 7
6. Detailed semantics . . . . . . . . . . . . . . . . . . . . . . 8
6.1. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 8
6.3. Redirect Server Behavior . . . . . . . . . . . . . . . . . 8
6.4. Proxy Server Behavior . . . . . . . . . . . . . . . . . . 8
6.4.1. Proxy Logic for Diversion header . . . . . . . . . . . 9
7. Examples using Diversion header . . . . . . . . . . . . . . . 10
7.1. Call Forward Unconditional . . . . . . . . . . . . . . . . 10
7.1.1. Network Call Forward Unconditional, P2 recursing . . . 10
7.1.2. Network Call Forward Unconditional, P1
non-recursing P2 non-recursing . . . . . . . . . . . . 11
7.1.3. Network Call Forward Unconditional, P1 recursing
P2 non-recursing . . . . . . . . . . . . . . . . . . . 12 7.1.4. Endpoint Call Forward Unconditional, P1 recursing P2 non-recursing . . . . . . . . . . . . . . . . . . . 13
7.2. Call Forward on Busy . . . . . . . . . . . . . . . . . . . 14
7.2.1. Network Call Forward on Busy, P2 recursing . . . . . . 14
7.2.2. Network Call Forward on Busy, P1 non-recursing P2
non-recursing . . . . . . . . . . . . . . . . . . . . 15
7.2.3. Network Call Forward on Busy, P1 recursing P2
non-recursing . . . . . . . . . . . . . . . . . . . . 16
7.2.4. Endpoint Call Forward on Busy, P1 recursing P2
non-recursing . . . . . . . . . . . . . . . . . . . . 17
7.3. Call Forward on No-Answer . . . . . . . . . . . . . . . . 18
7.3.1. Network Call Forward on No-Answer, P2 recursing . . . 18
7.3.2. Network Call Forward on No-Answer, P1
non-recursing P2 non-recursing . . . . . . . . . . . . 19
7.3.3. Network Call Forward on No Answer, P1 recursing P2
non-recursing . . . . . . . . . . . . . . . . . . . . 20
7.3.4. Endpoint Call Forward on No-Answer, P1 recursing,
P2 non-recursing B non-recursing . . . . . . . . . . . 21
7.4. Call Forward on Unavailable . . . . . . . . . . . . . . . 22
7.4.1. Network Call Forward on Unavailable, P2 recursing . . 22
7.4.2. Network Call Forward on Unavailable, P1
non-recursing P2 non-recursing . . . . . . . . . . . . 23
7.4.3. Network Call Forward on Unavailable, P1 recursing
P2 non-recursing . . . . . . . . . . . . . . . . . . . 24
7.5. Multiple Diversions . . . . . . . . . . . . . . . . . . . 24
7.5.1. Call Forward Unconditional and Call Forward Busy . . . 25
7.5.2. Call Forward Unconditional and Call Forward No
Answer . . . . . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9. Further Examples . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Night Service/Automatic Call Distribution (ACD) using
Diversion header . . . . . . . . . . . . . . . . . . . . . 28
9.2. Voicemail Service using Diversion header . . . . . . . . . 36
9.3. Q&A on alternative approaches . . . . . . . . . . . . . . 40
10. Mapping ISUP/ISDN Redirection information to SIP Diversion
header . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
10.1. Mapping ISUP/ISDN Diversion Reason codes . . . . . . . . . 41
10.2. Mapping ISUP Redirection information to SIP Diversion
header . . . . . . . . . . . . . . . . . . . . . . . . . . 42
10.2.1. ISUP Definitions . . . . . . . . . . . . . . . . . . . 42
10.2.2. ISUP parameters . . . . . . . . . . . . . . . . . . . 43
10.2.3. ISUP to SIP translation . . . . . . . . . . . . . . . 43
10.2.4. SIP to ISUP translation . . . . . . . . . . . . . . . 44
10.2.5. Example of ISUP to SIP translation . . . . . . . . . . 44
10.2.6. Example of SIP to ISUP translation . . . . . . . . . . 45
10.3. Mapping ISDN Redirection information to SIP Diversion
header . . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.3.1. ISDN Definitions . . . . . . . . . . . . . . . . . . . 46
10.3.2. ISDN parameters . . . . . . . . . . . . . . . . . . . 46
10.3.3. ISDN to SIP translation . . . . . . . . . . . . . . . 48
10.3.4. SIP to ISDN translation . . . . . . . . . . . . . . . 49
10.3.5. Example of ISDN to SIP translation . . . . . . . . . . 50
10.3.6. Example of SIP to ISDN translation . . . . . . . . . . 50
10.4. Information loss in SIP to ISUP/ISDN translation . . . . . 51
10.4.1. Loss of diversion URI information . . . . . . . . . . 51
10.4.2. Loss of diversion reason information . . . . . . . . . 51
10.4.3. Loss of diversion counter information . . . . . . . . 51
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 52
12. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 52
13. Normative References . . . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
=================================== 내용 정리 ===================================
Diversion Header는 Call Forwar가 발생할 때의 정보들을 담는 Header이다. 이 Header의 값을 이용하여,
추가적인 서비스 수행과 예외처리등에 사용할 수 있다.
이 Header가 나온 간단한 예를 들면, A가 B에게 전화를 걸려고 시도를 했다. 하지만 B는 C에게 Call Forward 해놓았고, C 또한 B에게 Call Forward를 해놓았다.. 과현 호는??
이외에도 실제 망에서 사용되고 있는 각종 서비스에서도 이 헤더를 이용하여 예외처리가 가능하다.
기본적인 사용법과 예들은 권고안을 보면 굉장히 자세히 설명되어 있다.
하지만 Deversion의 counter, limit parameter의 예는 없기에 이를 설명한다.
counter parameter는 Forward된 횟수를 말하며, limit는 최대 Forward되는 횟수를 말한다.
예를 들어 최초 Forward를 시작한 Proxy에서 counter=1;limit=3; 이라는 값을 주면
Forward가 1번 되었으며, 최대 3번까지 더 Forward가 가능하다는 것을 말하는 것이다.
limit가 없다면, Forward를 하려는 Proxy의 자체 설정으로 처리해도 무방하다.
만약 Forward가 계속되어 counter값과 limit값이 같아진다면, Proxy는 호를 폐기할 수도 있다.
-------------------- Diversion Header ABNF ----------------------------
Diversion = "Diversion" ":" 1# (name-addr *( ";" diversion_params ))
diversion-params = diversion-reason | diversion-counter |
diversion-limit | diversion-privacy |
diversion-screen | diversion-extension
diversion-reason = "reason" "="
( "unknown" | "user-busy" | "no-answer" |
"unavailable" | "unconditional" |
"time-of-day" | "do-not-disturb" |
"deflection" | "follow-me" |
"out-of-service" | "away" |
token | quoted-string )
diversion-counter = "counter" "=" 1*2DIGIT
diversion-limit = "limit" "=" 1*2DIGIT
diversion-privacy = "privacy" "=" ( "full" | "name" |
"uri" | "off" | token | quoted-string )
diversion-screen = "screen" "=" ( "yes" | "no" | token | quoted-string )
diversion-extension = token ["=" (token | quoted-string)]
ex = "Diversion: xxx@proxy.com;counter=1;limit=3;
------------------------------------------------------------------
# by | 2009/09/10 14:05 | [SIP] | 트랙백 | 덧글(0)
2009년 09월 10일
[RFC 4028]Session Timers in the Session Initiation Protocol (SIP)
=================================== Keyword ======================================
Option-Tag : timer
=================================== Overview ======================================
Message처리중 오류나 중간의 Proxy이상등올 자원해제가 안되는 경우를 위한 Session-Timer에 대한 설명
=================================== Table of Contents ==============================
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . 4
4. Session-Expires Header Field Definition . . . . . . . . . . 6
5. Min-SE Header Field Definition . . . . . . . . . . . . . . . 8
6. 422 Response Code Definition . . . . . . . . . . . . . . . . 8
7. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Generating an Initial Session Refresh Request . . . . 9
7.2. Processing a 2xx Response . . . . . . . . . . . . . . 9
7.3. Processing a 422 Response . . . . . . . . . . . . . . 11
7.4. Generating Subsequent Session Refresh Requests . . . . 11
8. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Processing of Requests . . . . . . . . . . . . . . . . 13
8.2. Processing of Responses . . . . . . . . . . . . . . . 14
8.3. Session Expiration . . . . . . . . . . . . . . . . . . 15
9. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Performing Refreshes . . . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . 18
11.1. Inside Attacks . . . . . . . . . . . . . . . . . . . . 18
11.2. Outside Attacks . . . . . . . . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
12.1. IANA Registration of Min-SE and Session-Expires
Header Fields . . . . . . . . . . . . . . . . . . . . 19
12.2. IANA Registration of the 422 (Session Interval Too
Small) Response Code . . . . . . . . . . . . . . . . . 20
12.3. IANA Registration of the 'timer' Option Tag . . . . . 20
13. Example Call Flow . . . . . . . . . . . . . . . . . . . . . 20
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
15.1. Normative References . . . . . . . . . . . . . . . . . 25
15.2. Informative References . . . . . . . . . . . . . . . . 26
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 27
=================================== 내용 정리 ===================================
RFC 4028에서는 자원이 남아 해지 안되는것을 해결하기 위한 Sessoin-Timer를 설명하고 있다.
Session-Timer란 발/착신자 어느 쪽에서도 Session에 관련 Timer를 두어 주기적으로 Session이 유효한지 체크하고,
Session의 Timer Expire시 Dialog 해지를 위한 것이다.
이때, Session-Timer를 지원하는지 확인하는 방법은 Supported에 추가된 "timer" Option-tag다.
만약 존재한다면 이것은 Session-Timer를 지원한다고 볼 수 있다.
Session-Timer를 지원하면 Session-Expires, Min-SE Header 또한 지원해야 하는데, 이는
Session-Timer를 시작및 관리 하기 위한 추가된 Header이다.
== Session-Expires Header ==Session-Expires Header는 Session-Timer의 값과 Refresh할 측(UAC/UAS)의 정보를 함께 포함한다.
이 헤더는 INVITE와 UPDATE Message와 이에 응하는 Response에 사용할 수 있다.
이 해더의 delta-time이라는 값이 있는데, 이 값이 Refrash와 자원 해지 정보로 사용된다.
이 값은 초로 표현되는데 90보다 크고 1800 (30분) 보다 작은 값을 선택하기를 권고하고 있다.
90보다 커야 한다는 이유는, 너무 자주 Session-Refrash 메시지를 주고 받을 경우 네트워크에 부하를 주기 때문이다.
refresher의 값에서 UAC와 UAS는 발 착신자를 의미한다.
--------------- Session-Expires Header ABNF -----------------
Session-Expires = ("Session-Expires" / "x") HCOLON delta-seconds *(SEMI se-params)
se-params = refresher-param / generic-param
refresher-param = "refresher" EQUAL ("uas" / "uac")
ex = "Session-Expires:900;refresher=uac"
----------------------------------------------------------------
== Min-SE Header ==Min-SE Header는 자신의 Session-Timer의 최소값을 상대측에게 알려주기 위해 사용된다.
만약 수신측에서 자신의 Session-TImer값보다 상대측값이 작을 경우 422 Response와 함께 전달하여, 호를 거부 할 수 있다.
수신측이 만약 422 Response를 전달 하고자 하면, 반드시 Min-Se Header를 메시지에 포함 해야 한다.
---------------- Min-SEI Header ABNF -----------------
Min-SE = "Min-SE" HCOLON delta-seconds *(SEMI generic-param)
-------------------------------------------------------
== 주의점 ==Session-Timer를 사용할 때에는 다음과 같은 주의사항이 필요하다.
1. Session-Timer를 사용하는 Session이 성립되었다면 Refrasher는 성립된 Session-Time값의 1/2에 Refresh 동작을 수행해야 한다.
2. 422 Response에는 반드시 Min-SE가 들어가야 한다.
3. 422 Response를 받은 발신측이 호를 재시도 할 때는, 이전에 실패한 INVITE의 Call-ID, To, From Header의 값과 같은 값을 사용하여 INVITE를 재시도 해야 한며, 422 Response의 Min-SE보다 큰값을 Session-Expires값에 사용해야 한다. (다르게 사용해본적은 없다..)
4. Session-Timer가 Expire되었다면, BYE를 상대측에 보내야 한다. 하지만, UA가 아니라면, 할당된 자원만 해지 해야 한다.
5. Session-Refrash는 Re-INVITE와 UPDATE 메시지를 통해 사용할 수 있는데, UPDATE를 지원한다면, 되도록 UPDATE를 쓰는것을 권장한다. (권고안 내용)
6. Refrasher는 일반적으로 발신측에서 결정한 값을 사용하는데, 만약 refresher parameter가 없다면, 수신측에서 결정할 수 있다. (단 UAC/UAS 모두 Session-TImer를 지원하는 경우에 한해서이다.)
7. Refresher동작을 하는 측은 Response Message를 받았을 때, 반대 측은 Request Message를 받았을 때 Session-Timer를 Update한다.
# by | 2009/09/10 13:39 | [SIP] | 트랙백 | 덧글(0)
2009년 09월 10일
[RFC 3966]The Tel URI for Telephone Numbers
=================================== Keyword ======================================
=================================== Overview ======================================
Tel-URI는 SIP-URI와 같이 망에서 자주 사용되는 URI다.
형태는 User의 정보를 전화번호 형태로 표현된 것이 SIP-URI와 다른점이다.
이 Tel-URI의 ABNF와 각 필드 값의 의의들을 설명하고 있다.
=================================== Table of Contents ==============================
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. URI Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. URI Comparisons . . . . . . . . . . . . . . . . . . . . . . . 6
5. Phone Numbers and Their Context . . . . . . . . . . . . . . . 6
5.1. Phone Numbers. . . . . . . . . . . . . . . . . . . . . 6
5.1.1. Separators in Phone Numbers . . . . . . . . . . 7
5.1.2. Alphabetic Characters Corresponding to Digits . 7
5.1.3. Alphabetic, *, and # Characters as Identifiers. 7
5.1.4. Global Numbers. . . . . . . . . . . . . . . . . 7
5.1.5. Local Numbers . . . . . . . . . . . . . . . . . 8
5.2. ISDN Subaddresses. . . . . . . . . . . . . . . . . . . 9
5.3. Phone Extensions . . . . . . . . . . . . . . . . . . . 10
5.4. Other Parameters . . . . . . . . . . . . . . . . . . . 10
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Why Not Just Put Telephone Numbers in SIP URIs?. . . . 11
7.2. Why Not Distinguish between Call Types?. . . . . . . . 11
7.3. Why tel. . . . . . . . . . . . . . . . . . . . . . . . 11
7.4. Do Not Confuse Numbers with How They Are Dialed. . . . 11
8. Usage of Telephone URIs in HTML . . . . . . . . . . . . . . . 11
9. Use of "tel" URIs with SIP (Informative). . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12. Changes Since RFC 2806. . . . . . . . . . . . . . . . . . . . 14
13. References. . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 17
=================================== 내용 정리 ===================================
Tel-URI는 말그대로 전화번호를 URI형태로 사용한다고 이해하면 쉽다.
일반적으로 사용하는 전화번호와 같은 형태와 국가번호가 들어간 형태등 여러가지 형태가 있다.
이 URI는 Request-URI, To, From, P-Asserted-Identity등 여러 곳에서 자주 사용된다.
---------------Telephone-URI ABNF-----------------
telephone-uri = "tel:" telephone-subscriber
telephone-subscriber = global-number / local-number
global-number = global-number-digits *par
global-number-digits = "+" *phonedigit DIGIT *phonedigit
local-number = local-number-digts *par context *par
local-number-digits = *phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex
context = ";phone-context=" descriptor
descriptor = domainname / global-number-digits
phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ]
phonedigit = DIGIT / [ visual-separator ]
visual-separator = "-" / "." / "(" / ")"
ex = tel:+1-201-555-0123
tel:7042;phone-context=korea.com
tel:863-1234;phone-context=+1-914-555
----------------------------------------------------------------
위 ABNF는 Tel-URI 전체의 BNF는 아니다. K모사와 S모사의 망에서 자주 사용하고, 볼 수 있는 부분까지만 넣었다.
간단하게 Local Number와 Global Number의 차이점은 2가지다
- "+"로 시작하면 Global Number이고, 그렇지 않다면 Local Number이다.
- "phone-context" Parameter는 Local Number에만 사용할 수 있다.
# by | 2009/09/10 11:53 | [SIP] | 트랙백 | 덧글(0)
2009년 09월 03일
[RFC 3455] Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the ...
=================================== Keyword ======================================
=================================== Overview ======================================
3gpp나 IMS망에 관련된 내용을 보다보면 나오는 새로운 P-Header들, 이에 대한 ABNF와 각 필드 값의 의미들을
설명하고 있다.
P-Charging-Vector외에는 아직 사용해본적이 없다. 따라서 지극히 개인적인 의견이다.
=================================== Table of Contents ==============================
1. Overall Applicability . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. SIP Private Headers . . . . . . . . . . . . . . . . . . . . . 3
4.1 The P-Associated-URI header. . . . . . . . . . . . . . . . 3
4.1.1 Applicability statement for the
P-Associated-URI header. . . . . . . . . . . . . . . 4
4.1.2 Usage of the P-Associated-URI header . . . . . . . . 4
4.2 The P-Called-Party-ID header . . . . . . . . . . . . . . . 6
4.2.1 Applicability statement for the
P-Called-Party-ID header. . . . . . . . . . . . . . . 9
4.2.2 Usage of the P-Called-Party-ID header. . . . . . . . 10
4.3 The P-Visited-Network-ID header. . . . . . . . . . . . . . 11
4.3.1 Applicability statement for the
P-Visited-Network-ID header. . . . . . . . . . . . . 11
4.3.2 Usage of the P-Visited-Network-ID header . . . . . . 12
4.4 The P-Access-Network-Info header . . . . . . . . . . . . . 15
4.4.1 Applicability Statement for the
P-Access-Network-Info header . . . . . . . . . . . . 16
4.4.2 Usage of the P-Access-Network-Info header . . . . . 17
4.5 The P-Charging-Function-Addresses header . . . . . . . . . 18
4.5.1 Applicability Statement for the
P-Charging-Function-Addresses header . . . . . . . . 18
4.5.2 Usage of the P-Charging-Function-Addresses
headerd. . . . . . . . . . . . . . . . . . . . . . . 19
4.6 The P-Charging-Vector header . . . . . . . . . . . . . . . 21
4.6.1 Applicability Statement for the
P-Charging-Vector header . . . . . . . . . . . . . . 22
4.6.2 Usage of the P-Charging-Vector header . . . . . . . 23
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1 P-Associated-URI header syntax . . . . . . . . . . . . . . 25
5.2 P-Called-Party-ID header syntax. . . . . . . . . . . . . . 25
5.3 P-Visited-Network-ID header syntax . . . . . . . . . . . . 25
5.4 P-Access-Network-Info header syntax. . . . . . . . . . . . 25
5.5 P-Charging-Function-Addresses header syntax. . . . . . . . 26
5.6 P-Charging-Vector header syntax. . . . . . . . . . . . . . 26
5.7 Table of new headers . . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6.1 P-Associated-URI . . . . . . . . . . . . . . . . . . . . . 28
6.2 P-Called-Party-ID. . . . . . . . . . . . . . . . . . . . . 28
6.3 P-Visited-Network-ID . . . . . . . . . . . . . . . . . . . 28
6.4 P-Access-Network-Info. . . . . . . . . . . . . . . . . . . 29
6.5 P-Charging-Function-Addresses. . . . . . . . . . . . . . . 30
6.6 P-Charging-Vector. . . . . . . . . . . . . . . . . . . . . 30
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 30
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 32
10. Normative References . . . . . . . . . . . . . . . . . . . . 32
11. Informative References . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 34
=================================== 내용 정리 ===================================
RFC 3455에서는 3gpp(또는 IMS)망에서 주로 사용하는 P-Header들의 헤더의 값과 의미를 설명하고 있다.
== P-Associated-URI Header ==
UA가 Registrar에 등록한 address-of-record의 값을 Registrar가 알려주고자 할 때 사용한다.
이 Header Field값은 최근에 등록된 것, 이전에 등록된 것, 삭제요청한 것들의 List형태로 표현된다.
UA는 이 Header Field값을 From Header등의 다른 Header Field값으로 사용할 수 있다.
주의 할 점은 Proxy나 UA단에서는 이 헤더를 생성할 수 없다는 것이다. (단말쪽을 만들어 본적이 없어 본적이 없다...)
--------------- P-Associated-URI Header ABNF -----------------
P-Associated-URI = "P-Associated-URI" HCOLON p-aso-uri-spec *(COMMA p-aso-uri-spec)
p-aso-uri-spec = name-addr *( SEMI ai-param)
ai-param = "generic-param
example = P-Associated-URI : sip:lukiji@xxx.com, sip:07077777@xxx.com
----------------------------------------------------------------
== P-Called-Party-ID Header ==
3GPP(IMS망)의 User는 여러 개의 SIP URI를 가질 수 있다. 이 여러개의 URI는 한명의 가입자를 나타내지만, 각 다른 그룹의 사용자들이 이 유저에게 전화 할 때 AS나 CSCF에서 각 다른 서비스등을 제공 하는데 사용한다. (아직 망에서 본적은 없다.)
주의점은 UA는 넣을 수 없으며, Proxy만이 Request-URI의 값으로 이 Header를 추가 할 수 있다.
--------------- P-Called-Party-ID Header ABNF -----------------
P-Called-Party-ID = "P-Called-Party-ID" HCOLON called-pty-id-spec
called-pty-id-spec = name-addr *( SEMI cpid-param )
cpid-param = generic-parm
example = P-Called-Party-ID : sip:user1-business@example.com
----------------------------------------------------------------
== P-Visited-Network-ID Header ==
UA의 SIP Message가 지나온 네트워크의 ID값을 넣는데 사용된다.
이 Header Field값은 모든 네트워크에서 Unique해야 하며, 같으 네트워크 ID를 사용하는 Domain에서는 추가할 수 없다.
주의점은 Proxy만이 넣을 수 있다는 점이다. (아직 망에서 본적이 없다. 과금용일까? ...)
--------------- P-VIsited-Network-ID Header ABNF -----------------
P-Visited-Network-ID = "P-Visited-Network-ID" HCOLON vnetwork-spec *(COMMA vnetwork-spec)
vnetwork-spec = (token / quoted-string) *( SEMI vnetwork-param)
vnetwork-param = generic-param
example = P-Visited-Network-ID : other.net, "Visited network number 1"
-------------------------------------------------------------------
== P-Access-Network-Info Header ==
UA가 접속하고 있는 네트워크 정보가 필요 할 경우가 있다. 이 때 이를 표현해주어야 할 때 이 Header가 사용되는데, 이 Header의 값으로 다음과 같은 서비스를 지원 할 수 있다.
- 위치기반 서비스
- 접속한 서버에 따른 서비스 (접속한 서버가 미지원하는 기능들을 판별할 때 사용할 수도 있겠군요.. )
주의점은 UA는 이 헤더를 넣을 수 있지만, Proxy는 이 헤더를 수정할 수 없다. (이러면.. UA단에서 잘 못된 정보를 넣을 경우.. 서비스 에러가 날 것 같은데.. 머 권고안에서 그리 말하니.. 쩝)
--------------- P-Access-Network-Info Header ABNF -----------------
P-Access-Network-Info = "P-Access-Network-Info" HCOLON access-net-spec
access-net-spec = access-type *(SEMI access-info)
access-type = "IEEE-803.11a" / "IEEE-802.11b" / "3GPP-GERAN" / "3GPP-UTRAN-FDD" /
"3GPP-UTRAN_TDD" / "3GPP-CDMA2000" /token
access-info = cgi-3gpp / utran-cell-id-3gpp / extension-access-info
extension-access-info = gen-value
cgi-3gpp = "cgi-3gpp" EQUAL (token / quoted-string)
utran-cell-id-3gpp = "utran-cell-id-3gpp" EQUAL (token /quoted-string)---------------------------------------------------------------------
== P-Charging-Function-Addresses Header ==
Charging record나 Event의 정보를 담는 Header 이다.
Off-line 과금과 On-line 과금정보를 표현하는데 Off-Line과금은 CCF라 표현되고, On-Line과금은 ECF라 표현된다.
주의점은 UA는 이 헤더를 알 필요도 내용을 이해할 필요도 없고,
Proxy에서만 넣을 수 있으며, 같은 Domain에서 한번만 넣을 수 있다.
실제로 망에서 받아보았지만.. 하하.. UA입장이여서 무시했다...
--------------- P-Charging-Function-Addresses Header ABNF ----------------
P-Charging-Addr = "P-Charging-Function-Address" HCOLON charge-addr-params *(SEMI charge-addr-params)
charge-addr-params = ccf / ecf / generic-param
ccf = "ccf" EQUAL gen-value
ecf = "ecf EQUAL gen-value
example = P-Charging-Function-Addresses : ccf=192.1.1.1; ccf=192.1.1.2
-----------------------------------------------------------------------------
== P-Charging-Vector Header ==
IMS망에서 과금을 하기위해 호마다 각 특수 값인 ICID value값을 지정한다. 이 값을 가지고 다니는 Header가 P-Charging-Vector 이다.
이 값은 같은 과금일 경우에 대해서는 Unique하지만, 서비스에 따라 변경 될 수 있다.
아 호란 발신자가 착신자에게 전화를 것을 말하지만, IMS망에서는 서비스에 따라 추가 과금 될 수도 있다. 이때 ICID Value값이 변한다. 따라서 한 호에 대하여 발신자에게서 착신자한테 가는동안 모두 동일한 값을 가지지 않을 수 있다.
주의점은 권고안에서 UA는 넣을 수도 없고, 알 필요도 없는 헤더다고 정의하고 있고, Proxy만이 넣을 수 있다고 정의 되어 있다.
하지만 실제 그렇지는 않다. UA의 기능을 가지는 중간의 Server들도 넣을 수도, 이 ICID값을 이용하기 도 한다.
--------------- P-Charging-Vector Header ABNF ----------------
P-Charging-Vector = "P-Charging-Vector" HCOLON icid-value *(SEMI charge-params)
charge-params = icid-gen-addr /orig-ioi / term-ioi / genneric-param
icid-value = "icid-value" EQUAL gen-value
icid-gen-addr = "icid-generated-at" EQUAL host
orig-ioi = "orig-ioi" EQUAL gen-value
term-ioi = "term-ioi" EQUAL gen-value
example = P-Charging-Vector : icid-value=121234dgfsfa;icid-generated-at=192.0.0.1;orig-ioi=home1.net
----------------------------------------------------------------
# by | 2009/09/03 09:25 | [SIP] | 트랙백 | 덧글(0)
2009년 09월 02일
[RFC 3428] Session Initiation Protocol (SIP) Extension for Instant Messaging
=================================== Keyword ======================================
=================================== Overview ======================================
MESSAGE Method는 말 그대로 Message를 주고 받는데 사용한다.
실망에서는 SMS등을 주고 받는데 사용하고 있다. 또한 호전환 시에도 사용되기도 한다.
=================================== Table of Contents ==============================
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Scope of Applicability . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . 4
4. UAC Processing . . . . . . . . . . . . . . . . . . . . . . . 5
5. Use of Instant Message URIs . . . . . . . . . . . . . . . . 6
6. Proxy Processing . . . . . . . . . . . . . . . . . . . . . . 6
7. UAS Processing . . . . . . . . . . . . . . . . . . . . . . . 7
8. Congestion Control . . . . . . . . . . . . . . . . . . . . . 8
9. Method Definition . . . . . . . . . . . . . . . . . . . . . 9
10. Example Messages . . . . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . 13
11.1 Outbound authentication . . . . . . . . . . . . . . . . . . 13
11.2 SIPS URIs . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.3 End-to-End Protection . . . . . . . . . . . . . . . . . . . 14
11.4 Replay Prevention . . . . . . . . . . . . . . . . . . . . . 14
11.5 Using message/cpim bodies . . . . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15
15. Normative References . . . . . . . . . . . . . . . . . . . . 16
16. Informational References . . . . . . . . . . . . . . . . . . 16
17. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
18. Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
=================================== 내용 정리 ===================================
RFC 3428에서는 MESSAGE Method의 사용법과 형태를 설명하고 있다.
MESSAGE는 Dialog를 생성하면서 전달 할 수 있으며, 이미 생성된 Dialog를 통해서도 전달이 가능하다.
== 주의점 ==
1. Dialog를 생성할 수 있다보니 Proxy에서 Forking이 가능하지만 RFC 3261의 룰에 따라 Proxy는 하나의 Response만을 발신자에게 전달 해야 한다.
2. 기본적으로 지원해야 하는 Body-Type은 text/plain이다.
3. UAC는 Contact Header를 MESSAGE Method에 넣을 수 없다.
4. UAC가 202 Response를 받았어도, 최종 착신자에게 MESSAGE Method가 전달되었다고 가졍할 수 없다.
5. UAC가 200 Response를 받았어도, 최종 착신자가 메시지를 읽었다고 가정할 수 없다.
6. UAS는 MESSAGE Method에 Expires Header가 존재 하고, 착신자가 보기전에 expires 값이 지난다면 Message를 삭제 해야 한다.
# by | 2009/09/02 16:49 | [SIP] | 트랙백 | 덧글(0)
2009년 09월 02일
[RFC 3326] The Reason Header Field for the Session Initiation Protocol (SIP)
=================================== Keyword ======================================
=================================== Overview ======================================
SIP Response값 만으로 판별 하기 어려운 경우가 있다. 이 때 세부적인 에러이유등을 UAC에게 전달 하기 위한 Header가 Reason이다.
실망에서는 이 값을 참조로 예외처리 하는 경우도 있다.
=================================== Table of Contents ==============================
1. Introduction ............................................... 2
1.1. Terminology ................................................ 3
2. The Reason Request Header Field ............................ 3
3. Examples ................................................... 4
3.1. Call Completed Elsewhere ................................... 4
3.2. Refusing an Offer that Comes in a Response ................. 4
3.3. Third Party Call Control ................................... 5
3.4. ISUP interworking .......................................... 5
4. IANA Considerations ........................................ 6
5. Security Considerations .................................... 6
6. Acknowledgments ............................................ 7
7. Authors' Addresses ......................................... 7
8. Normative References ....................................... 7
9. Full Copyright Statement ................................... 8
=================================== 내용 정리 ===================================
RFC 3326에서는 Reason Header의 사용법과 ABNF를 설명하고 있다.
Reason Header는 멀티라인이 가능하고 한라인에 여러 값이 들어갈 수 있다.
Reason Header는 Optional한 Header이기 때문에 호처리에 큰영향은 주지 않지만, 각 망에 따라 이 값을
예외처리에 한 방향으로 사용하기도 한다.
---------------- Reason Header ABNF -----------------
Reason = "Reason" HCOLON reason-value * (COMMA reason-value)
reason-value = protoco * (SEMI reason-params)
protocol = "SIP" / "Q.850" / "Preemption" / token
reason-params = protocol-cause / reason-text / reason-extention
protocol-cause = "cause" EQUAL cause
cause = 1*DIGIT
reason-text = "text" EQUAL quoted-string
reason-extension = generic-param
example = Reason : SIP;cause=200;text="Call Completed elsewhere"
-----------------------------------------------------
# by | 2009/09/02 16:35 | [SIP] | 트랙백 | 덧글(0)
2009년 09월 02일
[RFC 3325] Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity ...
=================================== Keyword ======================================
Privacy Type : id
=================================== Overview ======================================
P-Asserted-Identity Header와 P-Preferred-Identity Header는 서버간 또는 망간에서 User를 인증하기 위해 사용한다.
(실망에서는 주로 P-Asserted-Identity Header는 과금정보에 반영된다.)
=================================== Table of Contents ==============================
1. Applicability Statement . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 5
6. Hints for Multiple Identities . . . . . . . . . . . . . . . 6
7. Requesting Privacy . . . . . . . . . . . . . . . . . . . . . 6
8. User Agent Server Behavior . . . . . . . . . . . . . . . . . 7
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 7
9.1 The P-Asserted-Identity Header . . . . . . . . . . . . 8
9.2 The P-Preferred-Identity Header . . . . . . . . . . . . 8
9.3 The "id" Privacy Type . . . . . . . . . . . . . . . . . 9
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1 Network Asserted Identity passed to trusted gateway . . 9
10.2 Network Asserted Identity Withheld . . . . . . . . . . 11
11. Example of Spec(T) . . . . . . . . . . . . . . . . . . . . . 13
12. Security Considerations . . . . . . . . . . . . . . . . . . 14
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
13.1 Registration of new SIP header fields . . . . . . . . . 14
13.2 Registration of "id" privacy type for SIP Privacy header 15
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
Normative References . . . . . . . . . . . . . . . . . . . . 15
Informational References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
=================================== 내용 정리 ===================================
RFC 3325에서는 P-Asserted-Identity Header와 P-Preferred-Identity Header 그리고 "id"라는 Privacy Header의 필드 값과 사용법을 설명한다.
이 P-Header 들은 멀티 라인이 가능하고, 한 라인에 여러개의 값도 가질 수 있다.
== P-Asserted-Identity Header ==
P-Asserted-Identity Header IMS망에서 주로 사용하는데, From같이 단말기에서 생성하는 Header는 다른값으로 변경이 가능 함으로 과금정보 생성에 문제가 생긴다. 따라서 Server(CSCF혹은 Proxy)에서 인증하고 생성하는 P-Asserted-Identity가 과금 정보에 사용된다.
---------------- P-Asserted-Identity Header ABNF -----------------
PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value * (COMMA PAssertedID-value)
PAssertedId-value = name-addr / addr-spec
examples = P-Asserted-Identity : "Cullen Jennings" <sip:fluffy@cisco.com>, tel:+14085264000
-----------------------------------------------------
== P-Asserted-Identity Header ==
P-Preferred-Identity Header는 UA에서 Server에게 P-Asserted-Identity 값을 지정하는 우선순위를 요구 할 때 사용된다.
---------------- P-Preferred-Identity Header ABNF -----------------
PPreferredID = "P-Preferred-Identity" HCOLON PPreferredID-value * (COMMA PPreferredID-value)
PPreferredID-value = name-addr / addr-spec
examples = P-Preferred-Identity : "Cullen Jennings" <sip:fluffy@cisco.com>, tel:+14085264000
-----------------------------------------------------
== Privacy Type "id" ==
Privacy Header에 "id"가 존재 한다면, Server는 신뢰할 수 없는 곳으로 SIP Message를 전달 할 때 P-Asserted-Identity Header를 삭제하고 전달 해야 한다.
만약 Privacy Header에 "none"이 존재 한다면, Server는 신뢰할 수 없는 곳으로 SIP Message를 전달 한다 하더라도, P-Asserted-Identity Header를 삭제 하지 못하고 전달 해야 한다. (7. Requesting Privacy)
Privacy Header가 없다면 Server는 P-Asserted-Identity Header의 추가 혹은 삭제를 원하는 대로 할 수 있으나, 인증 또는 과금 정보등에 사용하는 망이라면 되도록 사용하도록 권장한다. (서비스 실패가 날 수 있다.)
# by | 2009/09/02 15:50 | [SIP] | 트랙백 | 덧글(0)
2009년 09월 02일
[RFC 3264] An Offer/Answer Model with the Session Description Protocol(SDP)
=================================== Keyword ======================================
=================================== Overview ======================================
미디어 처리를 위한 SDP 교환 모델
=================================== Table of Contents ==============================
1 Introduction ........................................ 2
2 Terminology ......................................... 3
3 Definitions ......................................... 3
4 Protocol Operation .................................. 4
5 Generating the Initial Offer ........................ 5
5.1 Unicast Streams ..................................... 5
5.2 Multicast Streams ................................... 8
6 Generating the Answer ............................... 9
6.1 Unicast Streams ..................................... 9
6.2 Multicast Streams ................................... 12
7 Offerer Processing of the Answer .................... 12
8 Modifying the Session ............................... 13
8.1 Adding a Media Stream ............................... 13
8.2 Removing a Media Stream ............................. 14
8.3 Modifying a Media Stream ............................ 14
8.3.1 Modifying Address, Port or Transport ................ 14
8.3.2 Changing the Set of Media Formats ................... 15
8.3.3 Changing Media Types ................................ 17
8.3.4 Changing Attributes ................................. 17
8.4 Putting a Unicast Media Stream on Hold .............. 17
9 Indicating Capabilities ............................. 18
10 Example Offer/Answer Exchanges ...................... 19
10.1 Basic Exchange ...................................... 19
10.2 One of N Codec Selection ............................ 21
11 Security Considerations ............................. 23
12 IANA Considerations ................................. 23
13 Acknowledgements .................................... 23
14 Normative References ................................ 23
15 Informative References .............................. 24
16 Authors' Addresses .................................. 24
17 Full Copyright Statement............................. 25
=================================== 내용 정리 ===================================
RFC 3264에서는 호의 미디어 처리를 위한 SDP 교환 방식을 규정하고 있다.
Offer란 SDP정보를 최초전달 혹은 변경하고자 원하는 SDP를 말하며,
Answer란 Offer로 수신된 SDP를 참조하여 만든 응답 SDP를 말한다.
Offer는 발/착신자에 구분없이 시작이 가능하다.
== 주의사항 ==
1. Glare 상태호가 성립되어 있는 상태에서 Caller/Callee 모두 Session을 변경하고자 하는 경우, 동시에 Offer가 발생할 수 있다. 이 때 491 Response를 전달하여 실패됨을 알려주어야 한다. (실망에서 이런 에러는 본적이 아직 없다.)
# by | 2009/09/02 15:45 | [SIP] | 트랙백 | 덧글(0)
2009년 09월 02일
[RFC 3311] The Session Initiation Protocol (SIP) UPDATE Method
=================================== Keyword ======================================
Method : UPDATE
=================================== Overview ======================================
UPDATE Method의 사용법
=================================== Table of Contents ==============================
1 Introduction .............................................. 2
2 Terminology ............................................... 3
3 Overview of Operation ..................................... 3
4 Determining Support for this Extension .................... 3
5 UPDATE Handling ........................................... 4
5.1 Sending an UPDATE ......................................... 4
5.2 Receiving an UPDATE ....................................... 5
5.3 Processing the UPDATE Response ............................ 6
6 Proxy Behavior ............................................ 7
7 Definition of the UPDATE method ........................... 7
8 Example Call Flow ......................................... 7
9 Security Considerations ................................... 11
10 IANA Considerations ....................................... 11
11 Notice Regarding Intellectual Property Rights ............. 11
12 Normative References ...................................... 11
13 Acknowledgements .......................................... 12
14 Author's Address .......................................... 12
15 Full Copyright Statement .................................. 13
=================================== 내용 정리 ===================================
RFC 3311은 호가 성립되기 이전이나 이후에 사용할 수 있는 UPDATE Method 에 대하여 설명한다.
UPDATE Method는 Early-Media나 Session-Timer를 사용하는데 주로 사용한다. (실 망에서는 Session-Timer용으로 주로 사용)
== UPDATE Method==
Method : UPDATE
=================================== Overview ======================================
UPDATE Method의 사용법
=================================== Table of Contents ==============================
1 Introduction .............................................. 2
2 Terminology ............................................... 3
3 Overview of Operation ..................................... 3
4 Determining Support for this Extension .................... 3
5 UPDATE Handling ........................................... 4
5.1 Sending an UPDATE ......................................... 4
5.2 Receiving an UPDATE ....................................... 5
5.3 Processing the UPDATE Response ............................ 6
6 Proxy Behavior ............................................ 7
7 Definition of the UPDATE method ........................... 7
8 Example Call Flow ......................................... 7
9 Security Considerations ................................... 11
10 IANA Considerations ....................................... 11
11 Notice Regarding Intellectual Property Rights ............. 11
12 Normative References ...................................... 11
13 Acknowledgements .......................................... 12
14 Author's Address .......................................... 12
15 Full Copyright Statement .................................. 13
=================================== 내용 정리 ===================================
RFC 3311은 호가 성립되기 이전이나 이후에 사용할 수 있는 UPDATE Method 에 대하여 설명한다.
UPDATE Method는 Early-Media나 Session-Timer를 사용하는데 주로 사용한다. (실 망에서는 Session-Timer용으로 주로 사용)
== UPDATE Method==
UPDATE Method는 자주사용되는 Method 중에 하나이다. 주로 Session-Timer용으로 사용되지만, RFC 3311에서는 호가 성립되기 전에 Media를 변경할 필요가 있는경우 사용 할 수 있다고 명시 되어 있다.
UPDATE의 장점은 Dialog의 변화가 없다는 점이다. 따라서 호가 성립되기 전에도 사용이 가능하다.
사용할 수 있는 Flow는 다음과 같다.위 FLow처럼 언제 어느 때라도 어느 쪽에서 다 사용이 가능한 것이 UPDATE Method이다.
하지만, SIP 권고안을 좀이나마 읽어 본사람은 알겠지만, 항상 Allow Header의 값을 통해 UPDATE가 지원되는지 확인 하고 사용해야 한다.
== 주의점 ==
1. UPDATE Method는 Response의 수신이 있기 전에 중복전송이 불가능하다.UPDATE Method를 전송이후 해당 UPDATE Method의 Response를 받기전에, 또 다른 UPDATE Method를 전달한다면, 상대측으로 부터 500 Response를 수신하게 될 것이다.
2.Offer/Answer Model의 규칙을 따라야 한다.Offer/Answer Model(RFC 3264)의 규칙을 따르지 않고, Offer에 대한 Answer를 수긴하기도 전에 Offer를 보낸다면 500 Response를 수신하게 될 것이다.
또 Offer를 수신하고도 Answer를 보내지 않고, 새로운 Offer를 보낸다면 역시 491 Response를 받을 것이다.
3.호가 성립된 이후에는 Media 변경 처리시 Re-INVITE를 사용하라.UPDATE의 단점은 Response가 제대로 수신되었는지 확인 할 수 없다는 점이다. 이에 따라 권고안 에서는 호가 성립된 이후라면 Re-INVITE를 사용하여 Media 변경 처리를 하는 것을 권장한다.
4. SDP가 받아 들일 수 없다면 488 Response를 전달 해야 한다.이 488 Response에는 Warning Header가 들어가야 한다.
# by | 2009/09/02 15:04 | [SIP] | 트랙백 | 덧글(0)
2009년 09월 02일
[RFC 3262]Reliability of Provisional Responses in the Session Initiation Protocol(SIP)
=================================== Keyword ======================================
Method : PRACK
Header : RAck, RSeq, CSeq
Option-Tag : 100rel
=================================== Overview ======================================
INVITE에 대한 1xx Response에서 Early-Media 등의 처리를 위한 PRACK Method의 규칙과 UAC, UAS에서의 처리방법
RAck, RSeq 헤더의 ABNF와 값의 의미
Supported, Require Header에서의 Option-Tag "100rel"의 의미
CSeq값의 처리
=================================== Table of Contents ==============================
1 Introduction ........................................ 2
2 Terminology ......................................... 3
3 UAS Behavior ........................................ 3
4 UAC Behavior ........................................ 6
5 The Offer/Answer Model and PRACK .................... 9
6 Definition of the PRACK Method ...................... 10
7 Header Field Definitions ............................ 10
7.1 RSeq ................................................ 10
7.2 RAck ................................................ 11
8 IANA Considerations ................................. 11
8.1 IANA Registration of the 100rel Option Tag .......... 11
8.2 IANA Registration of RSeq and RAck Headers .......... 12
9 Security Considerations ............................. 12
10 Collected BNF ....................................... 12
11 Acknowledgements .................................... 12
12 Normative References ................................ 13
13 Informative References .............................. 13
=================================== 내용 정리 ===================================
RFC 3262는 INVITE에 대한 1xx(100 Response는 제외) Response가 Caller에게 전달이 반드시 되는것을 확인하기 위하여 사용하는 PRACK Method에 대해 사용법과 규칙등을 설명한다..
INVITE에 대한 200 OK Response를 응답하고, ACK가 수신측에 전달 되지 않았을 때는 호가 성립되지 않는 것 처럼,
1xx Response에 발신자에게 반드시 가야한다고 생각되는 정보가 있다면, 이 PRACK Method를 사용할 수 있다.
아직 Server 대 Server에서 사용한 적은 없다. (만들어 놓고도 테스트 해본적은 없다..)
== PRACK Method의 사용협의==
PRACK Method은 UAC가 사용하고자 한다고 사용할 수 있는 것이 아니다. UAS에서도 지원을 해야만 사용할 수 있는데, 이를 판단할 수 있는 것이 "100rel" Option-tag 이다. (2. UAC Behavior, 3. UAS Behavior 참고)== RSeq Header ==
또한, UAS에서 PRACK Method를 지원하지만 사용할 필요가 없다면, 사용하지 않을 수 도 있다.
PRACK를 사용한다는 의미의 "100rel" Option-tag의 위치(Supported, Require Header) 다음과 같은 Flow들이 발생 할 수 있다.
1. UAC에서는 PRACK Method를 지원하지만, UAS에서 사용하지 않고자 할때, 또는 UAS에서 사용할 필요가 없는 경우
2. UAC에서 PRACK Method를 지원하고, 사용하고자 원하며, UAS에서도 지원하고, 사용이 필요한 경우
3. UAC에서 PRACK Method를 지원하고, UAS에서도 지원하고, 사용할 필요가 있는 경우4. UAS가 지원하지도 않는데, UAC가 사용하자고 한경우
RSeq Header는 UAS가 PRACK을 사용하고자 할 때, 1xx Response에 사용된다. 이 값은 Digit 이다.
이 값은 UAC에서 1xx에 대한 PRACK을 생성할 때 추가될 RAck Header의 값을 만들 때 사용된다.
---------------- RSeq Header ABNF -----------------
RSeq = "RSeq" HCOLON response-num
response-num = 1 * DIGIT
example = RSeq : 988789
-----------------------------------------------------
== RAck Header ==
RAck Header는 UAS에서 전달한 1xx Response 에 대한 PRACK을 생성 할 때 사용된다.
RAck Header는 UAC에서 전달한 1xx Response와 매칭 되기 위해서 사용된다.
이 RAck Header의 값은 1xx Response의 CSeq값과 RSeq값의 조합으로 생성된다.
---------------- RAck Header ABNF -----------------
RAck = "RAck" HCOLON response-num LWS CSeq-num LWS Method
response-num = 1*DIGIT
CSeq-num = 1*DIGIT
example = RAck : 988789 1 INVITE
-----------------------------------------------------
== 주의점 ==
1. CSeq값 관리 :호가 성립되기 전에 PRACK과 UPDATE Method사용할 수 있는데, 이 때 CSeq값이 증가된다.
하지만, CSeq값은 호가 성립되는 시점에서 최초 INVITE에 대한 CSeq값으로 초기화하여 사용되어야 한다.
그렇지 않다면, 이후 호처리에 실패가 될 것이다.
2. RAck 값 관리 :PRACK Method에 RSeq값과 CSeqt값을 조합으로 값을 생성한다고 하였다. 이 값이 문제가 있어 UAS에서
매칭되는 Dialog를 찾을 수 없다면, 481 Response를 받고, 호는 종료 될 것이다.
3. RSeq 값 관리 :1xx를 여러번 보낸다면 RSeq값이 1씩 증가 되어야 한다. (실 망에서 1xx를 여러번 사용하는 FLow는 아직 본적이 없다.)
4. PRACK Method 전달 시 주의점호가 성립된 이후 1xx Response를 받았다면 무시하라. PRACK Method를 전달 할 필요가 없다. UDP로 통신한다면,
호성립이후 1xx Response를 받을 경우도 있다. 이는 무시해도 상관없다.
또한, 1xx Response의 Require 헤더에 "100rel" Option-tag가 없다면, PRACK을 전달 할 필요도 없다.
5. UAS의 한계대기1xx Response를 전달한 UAS의 PRACK 한계 대기시간은 T1*64이다.
이 시간동안 PRACK Method를 받지 못한다면 5xx Response로 호를 실패 처리 해야 한다.
# by | 2009/09/02 13:28 | [SIP] | 트랙백 | 덧글(0)
◀ 이전 페이지 다음 페이지 ▶
