본문 바로가기
Protocol/SIP

10. Registrations

aucd29 2013. 9. 25. 18:01

 


10.1       Overview#


discovery capability 제공


AOR과 하나 이상의 contact address와 바인딩


Location service의 contents는 다양한 방법으로 생성 가능


Registrar : REGISTER request를 처리하는 특수한 형태의 UAS


 


 


10.2       Constructing the REGISTER Request#


REGISTER request



  • 바인딩의 추가, 삭제, query
  • dialog를 생성하지 않음
  • MUST include : Request-URI(location servier domain), To(AOR), From(registration person), Call-ID, CSeq, Contact
  • MAY include : Contact
  • Contact header field 파라매터 : action (사용 X), expires(바인딩의 유효시간)

 


예)



                                                 bob
                                               +----+
                                               | UA |
                                               |    |
                                               +----+
                                                  |
                                                  |3)INVITE
                                                  |   carol@chicago.com
         chicago.com        +--------+            V
         +---------+ 2)Store|Location|4)Query +-----+
         |Registrar|=======>| Service|<=======|Proxy|sip.chicago.com
         +---------+        +--------+=======>+-----+
               A                      5)Resp      |
               |                                  |
               |                                  |
     1)REGISTER|                                  |
               |                                  |
            +----+                                |
            | UA |<-------------------------------+
   cube2214a|    |                            6)INVITE
            +----+                    carol@cube2214a.chicago.com
             carol

 


10.2.1     Adding Bindings#


REGISTER request



  • Contact header field : Contact address, 일반적으로 SIP 또는 SIPS URI, 다른 URI sheme 사용 가능
  • To header field : AOR

 


2xx response to the REGISTER



  • AOR에 대한 모든 Contact address를 Contact header field에 포함

 


AOR이 SIPS URI라면 Contact address로 SIPS URI여야 함, 다른 secure 프로토콜을 사용한다면 SIP URI도 가능


 


10.2.1.1   Setting the Expiration Interval of Contact Addresses#

Expires header field



  • "expires" Contact header parameter가 없는 바인딩에 대하여 해당 값으로 expire 설정

 


"expires" Contact header parameter



  • 해당 바인딩의 expire 설정

 


둘다 없다면 서버가 선택


 


10.2.1.2   Preferences among Contact Addresses#

"q" 파마매터를 이용하여 Contact address들의 우선순위를 줄 수 있음


 


 


10.2.2     Removing Bindings#


expire가 0이 되면 바인딩 제거 됨


 


REGISTER request의 Contact header field의 값이 "*"이고 Expires header field의 값이 0이라면 모든 바인딩 삭제


 


 


10.2.3     Fetching Bindings#


Contact header field 없이 REGISTER request를 보낸다면 response로 모든 Contact address가 포함되어서 옴


 


10.2.4     Refreshing Bindings#


expiration 시간을 조정하여 바인딩을 refresh 함


같은 Call-ID를 사용하여야 함


 


10.2.5     Setting the Internal Clock#


response의 Data header field를 이용하여 internal clock를 설정 할 수 있음


 


10.2.6     Discovering a Registrar#


AOR 주소 이용


미리 정의


멀티캐스트


 


10.2.7     Transmitting a Request#


Request를 보낸 수 transaction layer에서 timeout이 발생하면 재시도


 


10.2.8     Error Responses#


423 (Interval Too Brief) response를 받았다면 expiration time을 Min-Expires보다 크게 하여 재시도


 


10.3 Processing REGISTER Requests#


UAS : REGISTER request에 respond, proxy, redirect서버에게 바인딩된 리스트를 제공


 


Registrar



  •  6xx response를 보내지 않음 (MUST)
  • REGISTER request를 redirect 할 수도 있음 (MAY)
  • Record-Route 헤더 필드는 무시함 (MUST)
  • REGISTER request에 대한 response에는 Record-Route 헤더 필드를 보내지 않음(MUST)

 


REGISTER request를 받았을 때, resistar동작



  1. Request-URI를 보고 자신의 도메인인지 확인, 아닐 경우 레지스트라가 프록시도 동작할 경우는 request를 포워딩 함(SHOULD)(sectio 16)
  2. Require 헤더 필드 처리(MUST) - 필요한 확장을 보증하기 위하여
  3. UAC 인증(SHOULD) - 인증 방법은 Section 22에서, 인증을 안쓰는 경우라면 From의 주소를 originator의 인증 주소로 가정
  4. 인증한 유저가 해당 AOR에 대하여 바인딩 수정이 가능한지 확인(SHOULD) - 아닐 경우 403(Forbidden) 에러, third-party가 여러 AOR에 대하여 수정할 경우가 있음
  5. Request의 헤더 필드에서 AOR 주소를 착출, Request-URU가 도메인에 적합하지 않으면 404(Not found) 에러 전송, URI를 적합한 폼으로 변경(MUST)-URI 파라매터 제거, escaped 문자->unescaped 문자

  6. Contact 헤더 필드가 있는지 확인



    • 없을 경우 : 마지막 스텝으로 이동

    • 하나의 contact 필가가 '*'를 보함하고 Expire 필드를 가졌을 경우



      • Call-ID가 각각의 바인딩에 대하여 저장이 가능하다면 모든 바인딩을 제거(MUST), 가능하지 않다면 request의 CSeq 값이 바인딩 된 값보다 큰 것들만 제거
      • 또다른 contact 필드가 있거나 Expire 값이 0이 아니라면 400(invalid request) 에러


  7. 각각의 contact address에 대하여 처리




    • expiration 설정 방법



      • expires 파라매터가 있을 경우 : 그 값을 exopiration으로 설정 (MUST)
      • 파라매터가 없고 Expires 헤더 필드가 있을 경우 : 그 값을 expiration 으로 설정(MUST)
      • 둘다 없을 경우 : local에서 결정한 기본값으로 설정 (MUST)

    • 요청한 expiration interval이 0보다 크고, 1시간 보다 작으면서 레지스트라 화경의 최소값 보다 작다면 : 423(interval too brief) 에러, response에 Min-Expires 헤더 값을 넣어야 함(MUST)
    • expiration이 너무 빈번하게 일어난다면 좋지 않음.... 추가 설명 필요 ;;;;;;;;;;;;;

    • 바인딩 리스트와 비교



      • 존재 하지 않을 경우 : 임시로 추가

      • 존재 할 경우



        • Call-ID가 다를 경우 : expiration 값이 0일 경우 바인딩 제거(MUST), 아닐경우는 update???

        • Call-ID가 같을 겨우



          • CSeq값이 클 경우 : expiration값을 보고 제거 혹은 update
          • CSeq 값이 작을 경우 : update 취소, request 실패(MUST)

    • 같은 UA에서 오는 out-of-order request는 무시됨
    • 각 바인딩은 request의 Call-ID와 CSeq값을 기록
    • 바인딩 update는 commited 되어 져야 함(MUST), 만일 update시 하나라도 실패가 발생하면 500(Server Error) 에러 발생시킨후 임시 바인딩 업데이트를 모두 제거(MUST)

  8. 200(OK) response 리턴, Contact 헤더 필드에 현재의 바인딩 정보를 넣어야 함 (MUST),

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

12. Dialogs  (0) 2013.09.25
11. Querying for Capabilities  (0) 2013.09.25
09. Canceling a Request  (0) 2013.09.25
08. General User Agent Behavior  (0) 2013.09.25
07. SIP Messages  (0) 2013.09.25

'Protocol/SIP' Related Articles

티스토리툴바