본문 바로가기

Protocol/SIP

12. Dialogs



 


 


이 섹션에서는 request와 response에 의하여 dialog가 어떻게 생성되고 dialog안에서 request와 response가 어떻게 이용되는지 살펴봄


 


Dialog



  • User agent의 핵심 컨셉
  • 일정 시간동안 지속되는 두 UA간의 peer-to-peer SIP 관계
  • 메시지의 sequencing을 쉽게 함
  • SIP 메시지를 해석하기 위하여 context로 표현됨

 


Dialog ID



  • 각각의 UA를 증명
  • Call-ID, local tag, remote tag로 구성 됨
  • 각 UA의 dialog는 각기 다른 dialog id를 가짐
  • 각 tag는 유일한 dialog id를 만드는데 용이하게 쓰임
  • 모든 reponses, To 필드에 tag가 있는 request와 연관됨

  • dialog ID 생성 방법




    • UAC



      • Call-ID : 메시지의 Call-ID value
      • remote tag : To 필드의 tag
      • local tag : From 필드의 tag


    • UAS



      • Call-ID : 메시지의 Call-ID value
      • remote tag : From 필드의 tag
      • local tag : To 필드의 tag

 


Dialog는 후의 dialog의 메시지 통신을 위하여 몇몇의 state를 가지고 있음


 


state의 구성



  • dialog ID
  • local sequence number : UA에서 peer로 보낸 request의 순서
  • remote sequnce number : peer에서 UA로 보낸 request의 순서
  • local URI
  • remote URI
  • remote target
  • secure : boolean flag
  • route set : peer로 request를 보내기 위하여 거쳐야 할 서버의 URI 리스트

 


state의 종류



  • "early" state : provisional response를 받고 생성 되었을 경우
  • "confirmed" state : 2xx fianl response를 받았을 경우

 


12.1 Creation of a Dialog#


이 섹션에서는 메소드와 상관없이 dialog state를 생성하는 과정을 나타냄


 


Request에 대하여 특정 non-failure response들을 받았을 경우 dialog 생성 


INVITE request에 대하여 To 필드에 태그가 있는 2xx, 101~199 response를 받았을 경우 dialog


생성


Early dialog : non-final reponse에 의하여 "early"상태로 dialog가 생성되었을 경우


Extension에서는 dialog 생성이 다른 의미로 정의 될 수 있음 (MAY) ??????


 


UA들은 dialog ID 값을 할당 하여야 함(MUST)


12.1.1 UAS behavior#


Request에 대하여 response(INVITE에 대한 2xx와 같은)를 전송할때 dialog가 생성됨


 


Request에 있는 Record-Route 헤더 필드를 reponse에 카피 (MUST) : URI, URI parameter, Record-Route 헤더 필드 parameter등 UAS가 아는 정보부터 모르는 정보도 모두 포함함


위의 값들의 순서를 유지 똑 같이 유지 하여야 함(MUST)


Contact 헤더 필드



  • 추가하여야 함(MUST) : dialog에서 다음번의 request가 받기를 원하는 주소
  • SIP URI 또는 SIPS URI이여야 함(MUST)
  • request가 Request-URI 또는 Record-Route의 top 값이 SIPS URI이거나 contact 헤더 필드나 Record-Route 헤더 필드가 없다면 SIPS URI를 사용(MUST)
  • URI는 global scope여야 함(SHOULD) 

 


dialog state 생성



  • dialog 동안에 유지되어야 함(MUST)
  • Request-URI, secure flag : TLS를 통하여 request가 왔다면 Request-URI는 SIPS URI로 "secure" 플래그는 트루가 되어야 함

  • route set



    • request의 Record-Route 헤더 필드의 URI 리스트 값을 가짐(MUST)
    • URI의 순서는 유지 되어야 함(MUST)
    • Record-Route 값이 없다면 route set은 empty set이 되어야 함(MUST)
    • empty set이어도 pre-existing route set이 있다면 오버라이드함

  • remote target : request의 contact 헤더 필드의 URI가 됨 (MUST)
  • remote sequence number : request의 CSeq 헤더 필드 값으로 (MUST)
  • local sequence number : empty (MUST)

  • dialog ID



    • call identifier component  : reuqest의 Call-ID (MUST)
    • local tag component : request에 대한 response의 To 필드의 tag(MUST)
    • remote tag component  : request의 From tag(MUST), 만약 tag가 없으면 NULL로 간주(MUST)

  • remote URI : From 필드의 URI (MUST)
  • local URI  : To 필드의 URI (MUST)

 


12.1.2 UAC Behavior#


UAC는 INVITE와 같은 request를 보냄으로 dialog 생성


request의 contact 헤더 필드



  • global scope여야 함
  • Request-URI나 topmost Route 헤더 필드가 SIPS URI라면 반드시 SIPS URI이어야 함(MUST)

 


Response를 받으면 dialog state 생성



  • dialog 동안에 유지되어야 함(MUST)


  • Request-URI, secure flag : TLS를 통하여 request를 보냈다면 Request-URI는 SIPS URI로 "secure" 플래그는 트루가 되어야 함

  • route set



    • responset의 Record-Route 헤더 필드의 URI 리스트 값을 가짐(MUST)
    • URI의 순서는 역순이 되어야 함 (MUST)
    • Record-Route 값이 없다면 route set은 empty set이 되어야 함(MUST)
    • empty set이어도 pre-existing route set이 있다면 오버라이드함

  • remote target : request의 contact 헤더 필드의 URI가 됨 (MUST)
  • remote sequence number : request의 CSeq 헤더 필드 값으로 (MUST), remote UA가 request를 보내면 생성됨
  • local sequence number : empty (MUST)

  • dialog ID



    • call identifier component  : reuqest의 Call-ID (MUST)
    • local tag component : request의 From 필드의 tag(MUST)
    • remote tag component  : response의 To필드의 tag(MUST), 만약 tag가 없으면 NULL로 간주(MUST)

  • remote URI : To 필드의 URI (MUST)
  • local URI  : From 필드의 URI (MUST)

 


12.2 Requests within a Dialog#


UA 간에 dialog가 생성되면 dialog안에서 새로운 transaction   이 필요 할 수도 있음(MAY)


12.2.1 UAC Behavior#


12.2.1.1 Generating the Request#

Dialog내에서의 request는 dialog 부분으로 상태를 저장하고 있는 많은 component들에 의해 만들어 짐


 


request



  • To : remote URI
  • To tag : remote tag, 값이 NULL이면 생략
  • From : local URI
  • From tag : local tag, 값이 NULL이면 생략
  • Call-ID : Call-ID
  • CSeq : strictly monotonically increasing (increasing-by-one)
  • Request-URI, Route : remote target, route set

  • Contact : target refresh request를 받은 적이 있다면 update된 target URI로 아니라면 이전과 동일


     


12.2.1.2 Processing the Responses#

Transaction layer로 부터 request의 response를 받음, timeout 발생시 408 (Request Timeout) response을 받을 것처럼 처리


3xx response : Section 8.1.3.4와 동일하게 처리


2xx response to a target refresh request :  response에 Contact header field가 있다면 target URI를 업데이트


481 (Call/Transaction Does Not Exist) or a 408 (Request Timeout) : dialog 종료


 


12.2.2 UAS Behavior#


Dialog 안에서의 request는 atomic 함


존재하는 dialog과 매칭


To header field에 tag가 있지만 존재하는 dialog가 없을 경우, 견고함을 위하여 dialog를 복구 할 수도 있음


dialog를 복구하지 않는다면 481 (Call/Transaction Does Not Exist) response를 생성, 전달


dialog의 상태를 변화하지 않는 reqeust는 dialog 밖에서 처리하는 것과 같이 처리


remote sequence number



  • 비어 있을 경우 : request의 CSeq header field 값으로 설정

  • 비어 있지 않을 경우



    • CSeq 값이 remote sequence number 보다 작다면 500 (Server Internal Error) response
    • 위가 아닐 경우는 CSeq값을 remote sequence number로 셋

target refresh request : Contact header field를 target URI로 셋팅


 


12.3 Termination of a Dialog#


early dialog : method에 독립적


Confirmed dialog : method에 의존적, BYE에 의하여 종료

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

14. Modifying an Existing Session  (0) 2013.09.25
13. Initiating a Session  (0) 2013.09.25
11. Querying for Capabilities  (0) 2013.09.25
10. Registrations  (0) 2013.09.25
09. Canceling a Request  (0) 2013.09.25