16. Proxy Behavior

목차

---

16.1 Overview

16.2 Stateful Proxy

16.3 Request Validation

16.4 Route Information Preprocessing

16.5 Determining Request Targets

16.6 Request Forwarding

16.7 Response Processing

16.8 Processing Timer C

16.9 Handling Transport Errors

16.10 CANCEL Processing

16.11 Stateless Proxy

 

 

16.1 Overview^#

SIP proxy는 UAS로 SIP request를 라우트하고 UAC로 SIP response를 라우트 함

Proxy는 logical role이며 proxy가 request를 받으면 동작을 결정하게 됨

stateful과 stateless 모드로 동작 할 수 있음

stateful transports를 사용하여 transaction-stateful 하지 않게 동작 할 수도 있음

stateful proxy가 stateless 하게 동작 할 수도 있음

 

16.2 Stateful Proxy^#

SIP transaction processing engine

하나의 server transaction은 하나 혹은 다수의 client transaction과 proxy core로 관리 됨

새로운 request가 도착하면 새로운 server transaction 생성

 

모든 request는 다음과 같은 처리를 함

1. Validate the request (Section 16.3)
   
2. Preprocess routing information (Section 16.4)
   
3. Determine target(s) for the request (Section 16.5)
   
4. Forward the request to each target (Section 16.6) 
   
5. Process all responses (Section 16.7)

 

Proxy model

            +--------------------+
            |                    | +---+
            |                    | | C |
            |                    | | T |
            |                    | +---+
      +---+ |       Proxy        | +---+   CT = Client Transaction
      | S | |  "Higher" Layer    | | C |
      | T | |                    | | T |   ST = Server Transaction
      +---+ |                    | +---+
            |                    | +---+
            |                    | | C |
            |                    | | T |
            |                    | +---+
            +--------------------+

 

16.3 Request Validation^#

Request를 proxy 하기 전 메시지의 요효성을 살펴봐야 함

메시지의 다음과 같은 절차로 체크함

1. Reasonable Syntax 
   
2. URI scheme 
   
3. Max-Forwards 
   
4. (Optional) Loop Detection
   
5. Proxy-Require 
   
6. Proxy-Authorization

위의 과정을 실해하면 error response를 보내야 함

 

1. Reasonable syntax check

Request는 server transaction이 처리할 수 있도로고 well-formed 되어야 함

처리에 영향을 주지않는 components는 잘못되어도 무시하고 진행되어야 함, 확장성을 높임

 

2. URI scheme check

Request-URI의 URI이가 이해 할 수 있는지 확인

이해 할 수 없다면 : 416 (Unsupported URI Scheme) response

 

3. Max-Forwards check

Max-Forward header field가 없어가 값이 0보다 크다면 pass

값이 0이라면 request를 포워드 하지 않고 483 (Too many hops) response를 보냄, OPTION은 예외로 처리 될 수 있음

 

4. Optional Loop Detection check

Request를 포워딩하기전 loop를 확인 할 수 있음

Via header field의 sent by 파라매터로 loop와 spiral 구분

 

5. Proxy-Require check

Endpoint가 확장을 위하여 proxy가 지원하는 것을 확인

이해할 수 없는 확장이 있다면 420 (Bad Extension) response에 Unsupported header field를 추가하여 보내야 함

 

6. Proxy-Authorization check

request를 포워딩 하기 전에 credential이 필요한지 확인

 

16.4 Route Information Preprocessing^#

Request의 Request-URI를 검사사

Request-URI가 프록시를 가르키고 Route header field의 값이 존재한다면 Request-URI를 Route header field의 가장 마지막 값으로 대체하고 그 값은 삭제 함

만약에 Requet-URI에 maddr 파라매터가 있다면 프록시가 그 도메인을 처리할 필요가 있는지 확인

Route header field의 첫번째 값이 자신을 나타낸다면 그 값을 삭제

 

16.5 Determining Request Targets^#

request의 target 계산

Request-URI에 maddr 파라매터가 있다면 하나의 target URI를 사용하여 Section 16.6 과정을 진행

element가 처리할 필요가 없는 도메인이면 하나의 target을 가지고 포워딩 작업을 함

 

위의 두 조건이 아니라면 element는 Request-URI의 도메인을 처리해야 하며 request를 어디로 보낼지를 결정해야 함

Location service를 이용하여 wjdqhfmf djedma

 

만약 Request-URI가 충분한 정보를 가지고 있지 않다면 485 (Ambiguous) response를 전달하여야 함

request의 정보와 element의 현재 환경등을 이용하여 target set를 만듬

같은 Target URI는 target set에 한번만 들어가야 함

original request의 Request-URI의 도메인이 proxy가 처리할 필요가 없다면 target을 추가하면 안됨

Request가 포워딩 된 후도 3xx response 처리등과 같은 상황을 통해 target을 추가 할 수 있음

location service가 no-op이라면 target URI와 request URI가 동일하며 추가적인 처리를 통해 다음 홉을 결정 할 수 있음

프록시가 Request-URI를 받아 들일 수 없다면 404 (Not Found) response를 전달

 

위의 모든 과정을 하였는데도 target set이 비어 있다면 480 (Temporarily Unavailable) response 전달

 

16.6 Request Forwarding^#

target set이 비어있지 않다면 proxy는 request를 포워딩하기 시작함

qvalue를 ordering mechanism으로 주로 사용

response context : original request에 대하여 forwarded resquest와 response의 값을 가지고 있음

 

각각의 taget에 대하여 proxy가 request를 포워딩 하는 절차는 다음과 같다

1. Make a copy of the received request

2. Update the Request-URI

3. Update the Max-Forwards header field

4. Optionally add a Record-route header field value 

5. Optionally add additional header fields

6. Postprocess routing information

7. Determine the next-hop address, port, and transport

8. Add a Via header field value

9. Add a Content-Length header field if necessary

10. Forward the new request

11. Set timer C

 

1. Copy request

받은 request를 카피함, 헤더와 바디를 수정 없이 카피하고 헤더필드의 순서를 유지하여야 함

구현시 카피를 안할 수도 있음

 

2. Request-URI

target으로 교체

모든 파라매터는 제거 하여야 함

어떤 경우는 기존의 Request-URI와 변화가 없을 수도 있음

 

3. Max-Forwards

Max-Forwards를 포함하고 있다면 1 감소시켜야 함

없다면 70을 값으로 하여 추가

 

4. Record-Route

request에 의해서 만들어지는 dialog안에서 전달되는 request를 받기를 원한다면 Record-Route를 추가하여야 함

dialog에 포함되어 있더라고 후에 path에 존재하고 싶다면 Record-Route를 추가하여야 함, endpoint에는 아무런 영향을 미치지 않음

• 추가하지 않는다면 endpoint가 dialog를 재구성 할때 빠질 수 있음

Record-Route를 추가할 지는 proxy가 독립적으로 결정

SIP 또는 SIPS URI여야 함

lr 파라매터를 포함하여야 함

다음번 request가 어떤 transport를 사용할지 알지 않는다면 transport를 포함하여서는 안됨

Record-Route의 첫번째 값이 SIPS URI이면 반드시 SIPS URI여야 함

security perimeter에 있는 proxy라면 dialog동안 primeter를 잘 지켜야 함

response를 받았을때 Record-Route를 수정 할 수 있음

Record-Route에 파라매터를 포함 할 수 있음

Record-Route는 해당 dialog 안에서 만들어진 transaction 안에서만 유효함

네트워크의 확장성이 떨어지므로 필요할 때만 사용 하여야 함

 

5. Add Additional Header Fields

필요한 헤더필드를 추가

 

6. Postprocess routing information

목적이로 request를 전달하기전 local policy에 의하여 지정된 proxy들을 거쳐야 할 필요가 있을 경우 Route header field를 추가 할 수 있음

Route header field가 있다면 최상위 값을 보고 lr 파라매터가 없으면 다음을 수행하여야 함

• Request-URI를 Route header의 최하위 값으로 추가
  
• Route header의 최상위 값을 Request-URI로 대체하고 Route에서 삭제

 

7. Determine Next-Hop Address, Port, and Transport

local polcy에 의하여 특정 주소, port, transport를 지정하여 보낼 수 있으나 추천하지 않음, 대신 Route header field를 사용할 수 있음

[4]의 과정을 따라 Request-URI 또는 Route의 최상위 값을 input URI로 하여 address, port, transport로 이루어진 tuple의 set을 생성

set의 첫번째 tuple부터 성공할때까지 set을 이용하여 시도

각 tuple에 대하여 시도할때마다 새로운 clien transaction으로 시도

새로운 clien transaction은 새로운 branch를 가짐

client transaction이 실패한다면 ordered set의 다음 주소를 이용하여 재시도

ordered set이 다 소모되고 element에 의해 전달 할 수 있는 target set이 없을 경우 408 (Request Timeout) final response을 리턴

 

8. Add a Via header field value

Via header field를 추가하여야, global unique한 branch를 생성하여야 함

branch는 loop를 detect하는데 이용 가능

To tag, From tag, Call-ID header field, the Request-URI of the request received, opmost Via header, and the sequence number from the CSeq header field, Proxy-Require and Proxy-Authorization header fields  들을 hash하여 값을 구함, MD5 해쉬를 추천

request method는 사용되어사는 안됨 (CANCEL과 ACK일 경우 같은 branch를 사용)

 

9. Add a Content-Length header field if necessary

다음 홉이 stream- based transport이 경우는 Content-Length header field를 넣어야 함

 

10. Forward Request

새로운 client transaction을 만들어서 보냄

 

11. Set timer C

INVITE request의 경우 final response를 안 만들 수 있기 때문에 timer C를 시작

INVITE request에 대하여 client transaction을 시작할때 3분이상으로 셋팅하여 시작

 

16.7 Response Processing^#

Response를 받으면 response와 client transaction을 매칭함

 

client transaction은 다음 절차를 거쳐 proxy layer에게 전달

1. Find the appropriate response context

2. Update timer C for provisional responses

3. Remove the topmost Via

4. Add the response to the response context

5. Check to see if this response should be forwarded immediately

6. When necessary, choose the best final response from the response context

다음 과정은 best response를 선택 이후의 과정 임

7. Aggregate authorization header field values if necessary

8. Optionally rewrite Record-Route header field values

9. Forward the response

10. Generate any necessary CANCEL requests

 

1. Find Context

response에 해당하는 response context를 찾음

 

2. Update timer C for provisional responses

response가 provisional일 경우, timer C를 리셋, 값은 3분 이상이어야 함

 

3. Via

response에서 최사위 Via를 제거

response에 남은 Via가 없다면 포워드 해서는 안됨, CANCEL일 경우 나타 날 수 있음

 

4. Add response to context

context의 sever transaction이 final response를 생성하기 전까지 response를 response context에 저장

3xx response일 경우

• Contact 주소를 target set에 넣는다면 해당 주소는 response context에 넣기 전에 Contact에서 제거 하여야 함
  
• Contact가 없다면 response context에 넣을 필요 없음
  
• SIP, SIPS, non-SIP URI들이 올 수도 잇음

416 (Unsupported URI Scheme) response

• non-SIP URI의 SIP URI로 천이하여 target set에 추가

 

5. Check response for forwarding

context의 sever transaction이 final response를 생성하기 전까지 다음 response는 즉시 포워딩 해야 함

• 100 (Trying)을 제외한 provional response
  
• 2xx respoonse

6 response를 받았을 경우

• 모든 pending transaction을 cancel

context의 sever transaction이 final response를 생성하였다면 다음 response는 즉시 포워딩 해야 함

• INVITE repuset에 대한 2xx response

Stateful proxy는 response를 즉시 포워딩 하지 않고 best response를 생성함

즉시 보내져야 하는 경우는 바로 "Aggregate Authoriztion Header Fileld", "Record-Route" 과정으로 보내져야 함

 

6. Choosing the best response

stateful proxy는 즉시 보내져야 하는 response가 없었다면 반드시 자신이 final response를 보내야 함

response context의 값 중 best final response를 선택

final response가 없다면 408 (Request Timeout) response 전달

6xx class의 response가 있다면 무선 선택해야 함, 없다면 작은 response class 부터 선택함

503 (Service Unavailable) response를 받았다면 subsequent request도 503 response를 보낼 것이라 확신 할 수 없다면 500 response를 생성하여 보내야 함

dialog를 생성하는 과정중의 resonse의 To tag는 수정하면 안됨

3-6xx responses는 hop-by-hop으로 전달 됨

3-6xx response 포워딩시 To tag를 대체한다면 오리지널 tag를 보전하는 것이 디버깅에 도움이 됨

몇몇의 response의 정보를 이용할 경우 존재하는 To tag중 임의로 선정하는 것 보다 새로 생성하는 것이 디버깅에 도움이 됨

 

7. Aggregate Authorization Header Field Values

401 (Unauthorized) or 407 (Proxy Authentication Required) 선택하였을 경우

response context내의 모든 401 (Unauthorized) and 407 (Proxy Authentication Required) responses 에서 WWW- Authenticate, Proxy-Authenticate header field 값들을 fianl respoone에 추가하여야 함

 

8. Record-Route

자신이 적은 Record-Route를 수정 할 수 있음 - multi-homed hosts일 경우 유용

TLS-> proxy -> non-TSL일 경우는 Record-Route를 SIPS URI로 바꿔야 함

URI는 transport 파라매터를 가지면 안됨

unique identifier를 이용하여 spiral일 경우 수정하고자 하는 Record-Route를 찾을 수 있도록 함

 

9. Forward response

response context의 server transaction으로 best final response를 Via의 최상위로 보냄

더 이상 server transaction이 없다면 stateless하게 server transport에게 전달

final response를 보낸 후 response context는 연관된 모든 transaction이 종료 되기 전까지 유지

 

10. Generate CANCELs

pending client transaction에 대하여 CANCEL request를 보냄

 

 

16.8 Processing Timer C^#

Timer C가 종료되면 선택된 값으로 reset 하거나 client transaction을 종료

 

16.9 Handling Transport Errors^#

transport layer에서 에러가 발생하면 503 (Service Unavailable) response를 받을 것 처럼 처리

response를 포워딩시 에러가 발생하면 response를 drop 함

 

16.10 CANCEL Processing^#

매칭된 CANCEL request를 받았으면 response context와 연관된 모든 pending clinet transaction을 cancel 해야 함

INVITE's Expires header field를 이용 stateful proxy를 CANCEL respues를 생성 할 수도 있음

CANCEL request를 server transaction에서 처리할 경우, 자신의 response context를 생성하지 않고 cancel할 resquest의 server transaction을 찾고 즉시 200 (OK)를 보냄

response context가 없다면 statelessly하게 CANCEL request를 보내야 함

 

16.11 Stateless Proxy^#

statelessly하게 동작하는 proxy는 단순히 메시지를 전달함

transaction을 관리하지 않음