본문 바로가기
Protocol/SIP

08. General User Agent Behavior

aucd29 2013. 9. 25. 18:00

 


 


User agent : end system, user agent client(UAC) and user agent server(UAS)



UAC



  • User agent client
  • request를 생성
  • response를 처리

 


UAS



  • User agent server
  • request 수신
  • response 생성

 


UAC, UAS 처리에 영향을 주는 요소



  1. request나 response가 dialog 안에서 일어나는가 밖에서 일어가는가
  2. request method의 종류

 


 


8.1 UAC Behavior#


이 섹션에서는 dialog 밖에서의 UAC의 행동에 대하여 논의


 


8.1.1 Generating the Request#


Request는 적어도 6개의 헤더 필드(To, From, CSeq, Call-ID, Max-Forwards, Via)는 가지고 있어야 함


Request line은 method, Request-URI, SIP version으로 구성됨


 


8.1.1.1 Request-URI#

Initial Request-URI



  • To filed의 URI의 값으로 셋팅되어야 함(SHOULD)
  • REGISTER method는 제외
  • privacy나 convenience이 이유로 바람직하지 않을 수도 있음

 


Pre-existing route set



  • dialog 밖에서 request를 보낼 때 지나가야할 서버의 URI의 순서 셋
  • 사용자나 서비스 제공자에 의하여 미리 정의
  • Request-URI에 영향
  • Outbound proxy 설정을 원할때는 set을 하나의 outbound proxy의 URI로 설정하기로 추천(RECOMMENDED)
  • 존재시 처리과정은 Section 12.2.1.1.을 따라야 함(MUST)

 


8.1.1.2 To#

To header field



  • Request의 논리적 수신자, Request의 타켓이 되는 사용자나 resource의 AOR
  • SIP 또는 SIPS가 올 수 있음 (MAY), 다른 URI scheme들도 사용 가능
  • 구현시 SIP URI는 반드시 지원 가능해야 함(MUST)
  • TLS를 지원하는 구현은 반드시 SIPS URI 를 지원해야 함(MUST)
  • UAC에서의 입력 : 사람이 직접 입력, 주소록에서 선택
  • dialog 밖에서의 request는 반드시 tag를 가져서는 안됨(MUST)
  • display name을 적을 수 있음음

 


예)



To: Carol <sip:carol@chicago.com>


 


8.1.1.3 From#

From header field



  • request를 만든 쪽의 논리적 identity, 주로 사용자의 AOR
  • URI와 display name으로 구성
  • 논리적 이름이기 때문에 IP address나 FQDN을 사용해서는 안됨
  • client를 숨기고 싶을때는 diaplay 이름을 "Anonymous"로 줄 수 있음
  • 특정 UA는 사용자나 local domain의 관리자가 미리 정의한 값으로 설정
  • 특정 UA는 multiple user가 가능
  • request의 수신지가 From header field를 이용하여 request의 originator를 증명 할 수 있음
  • 반드시 tag 파라매터를 포함해야 함(MUST)

 


예)


      From: "Bob" <sips:bob@biloxi.com> ;tag=a48s
      From: sip:+12125551212@phone2net.com;tag=887s
      From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8

 


8.1.1.4 Call-ID#

Call-ID header field



  • 연속된 메시지 그룹의 unique identifier로 동작
  • dialog 내부의 UA들이 생성한 모든 request와 response를 같은 값을 가져야 함(MUST)
  • UA가 보낸 registration들은 같은 값을 가져야 함(SHOULD)
  • dialog 밖에서 새로운 request를 생성시 UAC는 method-speicific한 동작이 아니라면 global unique한 값을 가지는 Call-ID를 생성
  • Cryptographically random identifiers(RFC 1750) 방법을 추천(RECOMMENDED)
  • 구현시 "localid@host" 형식을 사용 할 수도 있음(MAY)
  • 비교시 case-sensitive, byte-by-byte

 


예)


      Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com

 


8.1.1.5 CSeq#

CSeq header field



  • transaction의 identify와 순서를 제공
  • sequence number와 method로 구성
  • method는 request와 반드시 match되어야 함(MUST)
  • dialog 밖의 non-REGISTER의 값은 임의로 결정
  • 32-bit unsigned integer로 반드시 표현 가능해야 함(MUST), 2**31보다 작아야 함(MUST)

 


예)


      CSeq: 4711 INVITE

 


8.1.1.6 Max-Forwards#

Max-Forwards header field



  • 도착지까지 request를 전달할때 지나가는 홉의 수를 제한
  • 한 홉을 지날때마다 값이 하나씩 감소
  • 도착지에 도착전에 값이 0이 되면 483 (Too Many Hops) error response 전달
  • UAC는 각각의 request에 반드시 넣어야 함(MUST), 값은 70으로 함(SHOULD)

 


8.1.1.7 Via#

Via header field



  • response가 어디로 보내져야 할지를 나타냄
  • 다음 홉이 결정되고 나면 추가함
  • UAC가 request를 생성하면 request에 반드시 넣어야 함(MUST)
  • 프로토콜 이름과 버젼은 SIP, 2.0이 되어야 함(MUST)
  • 반드시 branch 파라매터를 가져야 함(MUST)

 


branch 파라매터



  • request에 의해 생성된 transaction을 구별
  • UA가 보내는 모든 request에 대하여 time, space에 unque 해야 함(MUST), CANCEL과 non-2xx response에 대한 ACK는 제외
  • 3261 규격서에 따를 경우 branch ID는 "z9hG4bK" character set으로 시작하여야 함
  • maddr, ttl, sent-by component들이 transport layer 처리시 추가 될 수 있음

 


8.1.1.8 Contact#

Contact header field



  • UA가 SIP, SIPS URI를 이용 다음번 request를 보낼때 특정 contact를 나타낼 경우 사용
  • Dialog 생성 시 하나의 SIP 또는 SIPS URI를 포함하고 반드시 나타나야 함(MUST)
  • Global scope을 가짐
  • Request-URI나 Route header field의 첫번째 값이 SIPS URI라면 Contact는 반드시 SIPS URI여야 함(MUST)

 


8.1.1.9 Supported and Require#

Supported header field



  • UAC가 지원하는 확장가능한 option tag의 list
  • option tags list는 standards-track RFCs에 나온것만 올 수 있음(MUST)

 


Require header field



  • UAC가 UAS가 지원하는 확장을 알고 싶을때
  • option tags list값을 넣어 사용

 


Proxy-Require header field



  • UAC가 proxy가 지원하는 확장을 확인
  • ption tags list값을 넣어 사용

 


8.1.1.10 Additional Message Components#

추가적인 헤더 필드가 추가 될 수 있음


어떤 헤더 필드는 특정 method에 나타남


MIME-encoded된 메시지 바디를 포함 할 수 있음(MAY)


 


 


8.1.2 Sending the Request#


request의 도착지 계산



  • local policy가 없으면 DNS로 결정(MUST)
  • route set의 첫번째 값이 strict 라우터이거나 값이 없으면 Request-URI을 input URI로 (MUST)
  • 아니면 route set의 첫번째 값을 input URI로 address, port, transport를 구함(MUST)
  • Request-URI가 SIPS 리소스이고 input URI가 SIPS URI이면 [4]의 방법을 따라야 함(MUST)

 


Local ploicy가 대체 목적지를 나타낼 경우(MAY)



  • Request-URI가 SIPS URI라면 alternate destination은 TLS로 전달되어야 함(MUST)
  • Route header field가 없으면 제한이 없음
  • pre-existing route set을 이용하여 outbond proxy 설정 가능(NOT RECOMMANDED), set은 반드시 하나의 URI만 가져야 함(MUST)

  • Route header field가 있을 경우



    • pre-existing route set을 route set의 최상위값으로 함

 


Stateful element에 대하여 [4]에서 정의한 과정을 따라야 함(SHOULD)


 


 


8.1.3 Processing Responses#


Response의 처리 : transport layer -> transaction layer -> TU (method specific)


 


8.1.3.1 Transaction Layer Errors#

Timeout error 발생 : 반드시 408 (Request Timeout)을 받은 것처럼 처리(MUST)


Fatal transport error : 반드시 503 (Service Unavailable)을 받은 것처럼 처리(MUST)


 


8.1.3.2 Unrecognized Responses#

인지할 수 없는 final response를 받았다면 UAC는 해당 클래스의 x00 response를 받을 것 처럼 처리 해야 함(MUST)


인지 할 수없는 100이 아닌 provisional response를 받았다면 UAC는 183 (Session Progress)를 받을 것 처럼 처리해야 함(MUST)


UAC는 100 그리고 183 response를 처리 할 수 있어야 함


 


8.1.3.3 Vias#

하나이 상의 Via header field가 존재한다면 UAC는 메시지를 버려야 함(SHOULD)


 


8.1.3.4 Processing 3xx Responses#

UAC가 redirection response를 받았다면 response의 Contact header field의 값을 이용하여 하나 이상의 새로운 request를 생성해야 함(SHOULD)


Proxy의 resursing과 비슷하게 동작


Contact의 내용을 target set에 넣을 수 있음


target set에 같은 URI가 한번 이상 들어가면 안됨(MUST NOT)


원래의 Request-URI가 SIPS URI였으나 non-SIPS URI를 선택 할 수도 있음(MAY), 사용자에게 insecure URI가 사용됨을 알려야 함(SHOULD)


q-values를 사용하여 target set에서 URI의 순서를 결정 할 수 있음(MAY) : serially 또는 parallel하게 처리 할 수 있음(MAY)


 


Target set list의 모든 주소를 실패하면 그 request는 실패가 됨


Failure는 response code(399보다 큰)를 통해 확인 할 수 있음(SHOULD)


Failure가 발생하면 다음 contact address를 이용하여 새로운 transaction을 만들고 재시도(SHOULD)


3xx response의 contact address를 기반으로 하여 request를 생성할때, UAC는 target set의 "method-param", "header" 파라매터를 제외한 전체의 URI를 Request-URI로 카피(MUST)


 


새로운 request를 만들때



  • comma-separated list 값을 가지는 header feild일 경우는 헤더 필드에 추가
  • multiple value를 가질 수 없을 경우는 overwritten
  • To, From, Call-ID는 redireted request와 같은 값을 사용하기를 추천(RECOMMENDED), UAC는 새로운 Call-ID를 만들 수 있음(MAY)
  • 새로운 transanction을 생성하므로 top Via의 branch ID는 새로운 값으로 사용해야 함(MUST)
  • origianl request의 body와 header field도 재사용 해야 함(SHOULD)

 


UAC는 받은 status code에 따라 contact header field의 값은 임시적이나 영구적으로 가질 수 있음


 


8.1.3.5 Processing 4xx Responses#

어떤 4xx response는 method에 독립적으로 UA에서 처리됨


 


401(Unauthorized), 407(Proxy Authentication Required) response



  • 섹션 22.2에 따라 authoriztion을 처리하고 섹션 22.3에 따라 credential과 함께 request를 재시도 (SHOULD)

 


413 (Request Entity Too Large) response



  • 가능하다면 바디를 생략하거나 smaller length를 사용하여 재시도(SHOULD)

 


415 (Unsupported Media Type) response



  • UAS가 지원하지 않는 media type을 포함하고 있음
  • response의 Accept header field에서 포함된 content를 사용하고 인코딩은 Accept-Encoding header fiel를 사용, Accept-Language에 있는 언어를 사용하여 재시도(SHOULD)

 


416 (Unsupported URI Scheme) response



  • 서버가 지원하지 않는 URI scheme 사용
  • SIP URI를 사용하여 재시도(SHOULD)

 


420 (Bad Extension) response



  • UAS에서 request의 Require 또는 Proxy-Require header field에 지원하지 않는 확장이 있을 경우
  • Response의 Unsupported header field에 있는 확장은 생략하고 재시도(SHOULD)

 


새로운 request를 생성할 때



  • 새로운 transaction을 생성
  • Call-ID, To, From은 동일한 값을 가져야 함(SHOULD)
  • SCeq값은 이전 보다 하나 큰 값으로 해야 함 (SHOULD)

 


 


 


8.2 UAS Behavior#


dialong 밖에서 UAS가 request를 처리할때, method의 독립적으로 처리 과정


request의 처리는 atomic 해야 함


 


8.2.1 Method Inspection#


Request가 authenticate되었다면



  • request의 method 검사(MUST) : 지원하지 않는 method이면 405 (Method Not Allowed) response 생성
  • 405 (Method Not Allowed) response 생성시 Allow header field에 UAS가 지원하는 method의 리스트를 적어줘야 함(MUST)

 


8.2.2 Header Inspection#


이해할수 없는 header field는 반드시 무시해야 하고 메시지 처리 (MUST)


request를 처리하는데 필요없는 header field일 경우 잘못된 값이어도 무시 (SHOULD)


 


8.2.2.1 To and Request-URI#

To header field



  • From field의 사용자가 생성한 request의 original 수신자
  • Call forwarding이나 proxy 동작으로 original 수신자가 UAS 처리를 안 할 수도 있음
  • UAS가 To header field를 보고 받아들일지를 결정하는 local policy를 가지고 있을 수도 있음(MAY)
  • UAS가 URI scheme를 이해하지 못하더라도 reqeust를 받아들이기를 추천(RECOMMENDED)
  • 만약 거절할 경우 403 (Forbidden) response를 생성하여 전달해야 함 (SHOULD)

 


Request-URI



  • UAS가 지원하지 않는 scheme일 경우 반드시 416 (Unsupported URI Scheme) response로 거절해야 함 (MUST)
  • 받은 주소를 확인 할 수 없을때는 404 (Not Found) response로 거절 (SHOULD)

 


8.2.2.2 Merged Requests#

To header field에 tag가 없을 경우



  • 진행중인 transaction을 체크 해야 함(MUST)
  • From tag, Call-ID, CSeq가 진행중인 transaction과 match되지만 request가 match되지 않는다면 UAS core는 482 (Loop Detected) response 생성 전달해야 함 (SHOULD)

 


8.2.2.3 Require#

request를 처리할 적당한 element를 찾았으면 Require header field가 존재한다면 검사해야 함


UAC가 UAS가 처리 하기를 원하는 확장의 리스트를 가지고 있음


UAS가 처리 하지 못한다면 420 (Bad Extension) reponse에 Unsupported header field에 지원 할 수 없는 필드를 넣어서 보냄 (MUST)


Require and Proxy-Require




  • CANCEL request나 non-2xx response에 대한 ACK에는 사용되어선 안됨 (MUST NOT)



    • 만약 사용될 경우 무시하여야 함(MUST)

  • 2xx response에 대한 ACK의 경우 initial request에 포함되었다면 반드시 포함하여야 함 (MUST)

 


예)


      UAC->UAS:   INVITE sip:watson@bell-telephone.com SIP/2.0
                  Require: 100rel

      UAS->UAC:   SIP/2.0 420 Bad Extension
                  Unsupported: 100rel

 


 


8.2.3 Content Processing#


UAS는 메시지의 body, 그것을 설명하는 header field를 검사해야 함


 


body의 type, language 또는 encoding을 이해 할 수 없을 경우



  • 415 (Unsupported Media Type) response로 거절 (MUST)
  • response에 Accept header field를 포함해야 함 (MUST)

 


Content의 encoding을 이해 할 수 없을때



  • Accept-Encoding header field 포함 (MUST)

 


이해 할 수 없는 언어를 포함 하였을 경우



  • Accept-Language header field  포함 (MUST)

 


 


8.2.4 Applying Extensions#


UAS가 response에 확장 사용을 원할 경우, request의 Supported header field에 나오지 않은 확장은 사용 해서는 안됨 (MUST NOT)


확장이 지원 되지 않을 경우, 지원 가능한 확장이나 SIP 베이스로 생성하여야 함 (SHOULD)


꼭 지원되어야 확장일 경우, 421 (Extension Required) response를 보낼 수도 있음 (MAY)



  • response에 Require header field에 필요한 확장을 넣어야 함(MUST)
  • interoperability를 깨므로 일반적으로 추천되지 않음 (NOT RECOMMENDED)

non-421 response가 확장을 원할 경우, Require header field를 포함해야 함(MUST)



  • 지원되지 않는 확장은 response에 사용되어서는 안됨
  • option tags list는 standards-track RFC에 정의 된것이어야 함

 


 


8.2.5 Processing the Request#


위의 모든 체크가 끝나면 나머지 처리는 method에 의존되어 짐


섹션 10에선 REGISTER에 대하여


섹션 11에선 OPTION에 대하여


섹션 13에선 INVITE에 대하여


 


 


8.2.6 Generating the Response#


request의 response를 생성하기를 원한다면 다음 섹션의 과정을 따라야 함


response를 생성하였다면 request가 온 transaction을 이용하여 response를 전달


 


8.2.6.1 Sending a Provisional Response#

non-INVITE request에 대하서는 Provisional response를 보내면 안됨 (SHOULD NOT)


 


8.2.6.2 Headers and Tags#

From, Call-ID, CSeq, Via header field들은 request와 동일 하여야 함(MUST)


To header field에 tag가 있을 경우는 그것을 쓰고 없을 경우는 추가하여야 함


 


 


8.2.7 Stateless UAS Behavior#


Provisional (1xx) response를 보내지 않음 (MUST NOT)


Response를 재전송 하지 않음 (MUST NOT)


ACK request를 무시 (MUST)


CANCEL request를 무시 (MUST)


To header field의 tag 생성


 


 


8.3 Redirect Servers#


Proxy server의 load를 줄임, signaling path의 견고함을 향상


request에 대하여 routing 정보를 줄 수 있음


네트워크의 확장성 제공


transaction layer와 transacstion user에 의하여 논리적으로 처리되며 location service를 이용


SIP request를 생성하지 않음


3xx response 생성시 Contact header field에 alternative location 정보를 넣음, "expires" 파라매터를 이용 lifetime을 제한 할 수 있음


같은 주소에 대하여 다른 transport를 줄 수 있음


Request-URI와 동일한 URI를 redirect로 줘서는 안됨


Contact header field의 값은 originally call의 리소스와 다를 수 있음, 적당한 URI가 올 수 있음


"expires" 파라매터는 URI가 얼마나 유효한지를 나타냄


이해 할 수 없는 features들은 무시하고 계속 진행함


 

'Protocol > SIP' 카테고리의 다른 글

10. Registrations  (0) 2013.09.25
09. Canceling a Request  (0) 2013.09.25
07. SIP Messages  (0) 2013.09.25
06. Definitions  (0) 2013.09.25
05. Structure of the Protocol  (0) 2013.09.25

'Protocol/SIP' Related Articles

티스토리툴바