SIP 개념

                                                                                                                                                         

                                                                                                                                                                                                                   

                                                                                                                                                         

                                                                                                                                                                                                             

                                                                                                                                                                                                          

SIP란, 기본적으로 SIP message를 주고 받는 것이다. Session Initiation Protocol의 약자. OSI 계층 모델에서 애플리케이션 계층에서의 시그널링 처리 프로토콜이다. 

 

• SIP message
  • message란 server와 client 사이에서 주고받는 텍스트를 말한다.
  • message는 request와 response로 이루어진다. 

• 위의 그림과 같이 두 UA간에 Peer to Peer 관계가 일정 시간동안 유지되는 것을 다이얼로그(Dialog)라고 한다.
• 클라이언트로부터 보내진 처음의 request에서부터, 서버로부터 보내지는 (provisional response가 아닌) final response인 response까지를 트랜잭션(transaction)이라고 부른다. 

---

 

If the request is INVITE and the final response is a non-2xx, the transaction also includes an ACK to the response. The ACK for a 2xx response to an INVITE request is a separate transaction.

request가 INVITE고 final response가 아직 2xx가 아니면, final response가 나올 때까지 그 중간에 발생하는 모든 ACK들은 트랜잭션에 포함된다.

하지만 INVITE에 대한 2xx response의 ACK는 트랜잭션에 포함되지 않는다.

Three-way Hadnshaking

SIP request message는 다음과 같다. (아래의 request들을 다른 말로 method라고 한다.) 

 

---

 

• REGISTER

  • UA의 등록 절차 수행을 위해 사용되는 메소드

  • 다음의 정보들을 포함

    • 공인 식별자 / 논리 식별자 / public identifier

      • SIP URI로 표현된다.

        • link.dohk@gmail.com

      • To 헤더 필드에 포함된다.

    • 사용자의 위치

      • SIP URI로 표현된다.

        • link.dohk@213.33.12.3

      • Contact 헤더 필드에 포함된다.

  • UA는 지속적으로 바인딩 정보(user name과 IP주소가 묶인 정보)를 refresh하여 메세지의 만료를 막는다. 만약 Expires 헤더 필드를 0으로 설정하면 un-register의 의미가 되며, 더 이상 콜을 받지 않겠다는 의미다. 나의 전화번호를 계속 유지시키는 것

• INVITE

  • 두 UA간 콜 생성을 위해, UAC가 UAS에게 보내는 메소드

  • 적어도 한 개 이상의 Proxy를 거치게 된다.

  • UAS는 최종 200 OK 응답 reponse를 전송한다.

• 이 때 UAC와 UAS간에는 상호간에 어떠한 코덱을 사용할지에 대한 협상이 필요하다. 이 협상은 파라미터를 교환함으로써 이루어진다. 또한 상호간에 주소도 알려준다.

• Re-Invite
  • 이미 세션이 형성된 다이얼로그에 Invite요청 request를 재전송하여 파라미터를 수정하려는 것이다. (영상 통화에서 음성 통화로 전환하는 등의 협상 수정) 

---

• ACK

  • UAS는 최종 응답 메세지(final reponse)를 전송하게 되는데, 이 때 UAC가 최종 응답 메세지를 제대로 받았는지 확인하기 위해 ACK 메세지를 UAC로부터 받아야 한다. 즉 UAC는 최종 응답 메세지에 대한 ACK 메소드를 UAS에게 전송한다.

  • 주로 UDP와 같은 신뢰할 수 없는 프로토콜에서 사용된다.

 

• CANCEL

  • 이미 성립된 세션 요청(request)이 아닌 진행중인 요청을 취소한다.

 

• BYE

  • 이미 성립된 세션 요청을 취소한다.

  • UAS는 BYE request를 수신하게 되고, 세션을 종료해야 한다.

• OPTION

---

• SIP response message는 three-digit의 numeric한 status code다. (이 메세지는 UAS가 보내는 reponse이다.)

• 1xx 
  • 이 메세지는 임시(provisional; 먼저 보여주는) 메세지로서 일단 먼저 전송되고 난 후, final message들(2xx~6xx)이 전송된다.
  • Request 메세지를 수신하였고, 요청 메시지 처리가 계속 진행중이다.
• 2xx 
  • 해야 하는 동작;action이 무엇인지 이해했다, 그 동작을 받아들였다, 수행했다
  • Request가 수신자 측에서 성공적으로 받아들여졌다.
• 3xx
  • re-direction;방향 재설정
  • 새로운 UA에 대한 정보를 응답으로 전송하겠다.
• 4xx 
  • syntax가 잘못된 request를 받았거나, client단의 문제로 인해서 server에서 request를 fulfill(명령을 이행하다, 처리하다, 완료하다)할 수 없다.
  • 또는 해당 주소를 찾을 수 없다.
• 5xx
  • 명백한 request였지만(client에는 문제가 없다), server에 문제가 있어서 명령을 처리하지 못했다
• 이와 같이 첫번째 자리의 숫자는 response의 클래스를 정의한다. 

---

SIP message를 주고 받기 위해서는 메세지를 받을 곳의 주소가 필요하다. 이 주소는 다음과 같이 표현된다.

SIP URI(Universal Resource Idetifier)로 표현되며, 이 URI에 의해 SIP user나 SIP server가 식별된다. 

 

---

• SIP 메시지 포맷

  • 텍스트 기반

  • CRLF; Carriage Return and Line Feed

    

     

  • Request 메시지

    

    • 시작라인은 ‘요청 라인(request line)’이라고 불림

    • Method의 자리엔 INVITE나 REGISTER 등의 메소드 종류가 옴

    • Request-URI의 자리엔 해당 요청을 전달받을 사용자. 반드시 필요한 정보. primary key 역할

  • Response 메시지

    

    • 시작라인은 ‘상태 라인(Status line)’이라고 불림

  • 헤더필드

    

    

    

    • 파라미터는 필드값 다음에 세미콜론으로 구분된다.

      

    • FROM 필드

      • UAC의 public identifier(공인 식별자, 논리적인 식별자, Address of Record(AOR)/SIP URI)

      • 다이얼로그를 식별하기 위해 tag 파라미터를 반드시 포함하고 있어야 한다.

    • TO 필드

      • UAS의 공인 식별자(SIP URI)

      • UAC가 설정하며, 도중에 거쳐가는 프록시들에 대해서는 설정 불가능  

      • 프록시들의 TO 헤더필드는 바뀌지 않는다.

 

• Call-ID
  • 보았듯이, 여러 개의 proxy들을 거치게 되는데, 이 때 request와 response가 여럿 발생한다.
  • 이렇게 여러 개의 request와 reponse들을 하나의 dialog로 인식하기 위한 방법
  • 하나의 세션에 여러 개의 다이얼로그가 생기면 안되기 때문임 

---

• Via

  • request정보가 전송된 프록시 경로 그대로 reponse를 보내기 위해서, Via 헤더 필드를 이용하여 지나온 경로를 표시(IP주소와 포트번호가 Via에 주어지는 것이다!)

  • 각 프록시들은 Via필드에 자신의 IP 주소를 기록하여 자신으로 다시 reponse가 오도록 한다.

  • Via 헤더 필드는 순서대로 가장 위에 최근의 것이 놓이며, 하나씩 헤더가 삭제된다.

  • branch 파라미터

  • received 파라미터

• Contact

• UAC가 자신의 주소 정보를 contact 값으로 지정한다.

• 추후엔 UAS가 UAC에게 직접 전송 가능. 이 때 부턴 시그널링 패스 상에 있는 프록시들이 무시될 수 있음

• Record-Route

• Via와 비슷한 기능을 갖는다.
• 다른 점은, proxy server를 식별하기 위한 SIP URI 또는 FQDN을 사용한다는 점이다.
• 순서가 중요해보인다.

 

•  

• Route

  • UAC로부터 request를 받은 UAS가 reponse를 보낼 때(즉 UAS의 입장에서는 request를 보내는 입장), 수신한 Record-Route를 기반으로 Route 헤더 필드를 생성

• Cseq

• • Cseq는 순서번호(sequential number)와 메소드(method)로 구성된다; Cseq: 5 INVITE
• Max-Forwards
  • 목적지까지 도달하는 데에 경유할 수 있는 최대 홉(hop; proxy server)의 개수를 나타낸다. 값이 0이 되면 요청(request) 메시지는 거절된다. 
    • 바디필드
      • Proxy는 메시지 바디에 내용을 추가, 변경, 삭제할 수 없다.
      • 메시지 바디와 관련된 SIP 필드 종류들은 다음과 같다.
        • Content-Type
          • 바디의 미디어 타입; SDP
        • Content-Length
          • 바디의 길이
        • Centent-Encoding
          • 바디에 적용된 추가적인 인코딩 방식이 무엇인가
        • Centent-Disposition
          • 바디를 어떻게 해석해야 하는지에 대한 정보

            

             

---

SIP가 주로 하는 일은 다음과 같다;

위의 그림은 SIP의 생성과 변경, 종료를 모두 담고 있는데 이것이 바로 SIP가 하는 일이다.

 

철수가 영희에게 세션을 게시해달라는 요청을 한다면, 철수로부터 영희에게까지 라우팅이 되어야 한다. 이 요청은 IP network상에서 이루어지기 때문에 IP주소를 기반으로 라우팅 메세지가 전송된다. 

세션 요청이 영희에게 도달한다고 할 때, 영희에게 있는 device가 여러 개 일 수 있다. 따라서 영희의 현재 위치를 알아내기 위하여, 공인 식별자와 함께 영희의 현재 위치 정보가 필요하다.

따라서 사용자의 구체적인 위치를 알아내기 위해 다음과 같은 매핑 테이블이 필요하다;

 

위와 같은 기능을 구현하기 위하여 SIP에서는 사전에 사용자로부터 등록 절차를 밟게하여 등록 서버(registrar)에 사용자 위치를 저장한다.

보통 이러한 등록절차는 AS기사가 사용자의 계정을 이용하여 자사의 회사에 등록하여 이루어진다.

 

SIP등록 절차가 완료되면, 철수에게 오는 전화는 모두 특정 서버를 거쳐서 철수에게 도달하게 된다.

 

---

 

SIP는 몇 가지의 개체(entity)들로 이루어져 있다.

• entity 1> User Agent; 유저 에이전트는 다시 두 가지로 나누어지는데, 매번 무슨 역할을 하느냐에 따라 UAC와 UAS로 나누어진다. 

  • UAC; SIP 요청 메세지를 생성하고,해당 요청 메세지에 대한 응답 매세지를 받는다.

  • UAS; SIP 요청 메세지를 받고, 응답 메세지를 만들어서 보낸다.

• entity 2> 등록 서버(registrar);

  • UA로부터 등록 요청을 받아들인다.

  • UA는 공인 식별자(또는 논리적 식별자)와 자신의 위치를 registrar에 등록한다.

  • UA는 자신에게 들어오는 콜을 받기 위해 이렇게 등록해야 한다.

    • 

  • registrar는 받아들인 정보를 Location service라는 데이터베이스에 사용자의 공인 식별자와 사용자의 위치(contact address; FQDN(Fully Qualified Domain Name))를 매핑한다.

  • 로케이션 서비스는 매핑 정보를 갖고 있다.

• addresses of record; 공인 SIP 식별자 / 논리 식별자

• contact addresses ;사용자의 위치

• entity 3> Proxy 서버

  • 프록시는 중계자라는 의미인데, 일종의 라우터라고 보면 된다.

  • UAC에서 UAS까지 여러 개의 프록시들을 거쳐가게 되는데, UA를 대신하여 request를 만든다.

  • 대표적으로 outbound proxy와 inbound proxy가 있다.

    • outbound proxy는 바깥으로 나가려는(outgoing) 요청을 라우팅한다.

• inbound proxy는 수신되는 요청을 처리하는 proxy이다. 

• 도메인 내에 존재하는 해당하는 UA로 incoming request를 라우팅한다.

• 따라서 위와 같은 상황이 되는데, 이를 SIP trapezoid(사다리꼴) 구조라고 한다.

• 이와 같이 inbound proxy, outbound proxy, registrar가 하나의 SIP 서버 안에 마련될 수도 있다.

• Forking

  • 논리적 식별자(Address of Record)로 찾은 사용자가 여러 위치에 등록되어 있을 수 있다.

  • 즉 서로 다른 IP 주소에서 서로 다른 단말기를 통해 등록되어 있을 수 있다.

  • 이럴 경우, 프록시가 상황을 판단하여 서로 다른 위치에 있는 사용자 단말로 찾아가기 위한 별도의 알고리즘을 수행하게 된다.

    • Sequential Search

• • 존에게 전화가 오는 상황이다. 이 때 존이 여러 개의 device로 위치가 등록되어 있을 때, 세션이 성립될 때까지 서버가 순차적으로 위치를 찾아나가는 방식이 Sequential Search이다. 

• Parallel Search

• 역시 존에게 전화가 오는 상황이다. 이 때 동시에 call이 가서 모든 device에 요청이 온다. 어느 device든 세션을 확립하면 세션이 열리게 된다.

• entity 4> Redirect Server

• Redirect Server는 UAC로부터 request를 수신하면 ‘다시 어디어디로 request해야 합니다’라는 정보를, 해당 요청 메세지를 보낸 UAC에게 보낸다.

• Back-to-Back User Agents

---

• SIP 라우팅
  • SIP 노드(hop, proxy)가 다음 노드(hop, proxy)를 결정하는 과정을 말한다. 즉 SIP request를 어디로 포워딩할지를 결정한다.
  • 1. next-hop의 SIP URI를 결정한다.
    • 처음에 사용자가 전화를 걸고자 명시한 URI가 설정되고, 로컬들에 의해 route 헤더가 설정된다.
  • 2. next-hop에 도달하기 위한 IP주소, port, 전송 프로토콜을 찾는다. 

    • 

    • DNS를 이용하여 IP주소와 port 정보등을 알 수 있게 된다.
  • 시나리오
    • 두 단말이 직접 세션을 설정하는 경우(즉 proxy가 없는 경우)
      • 철수가 직접 영희의 IP주소로 SIP URI를 Request-URI로 설정한다. (TO 헤더 필드에도 설정한다.)
      • 포트와 전송 프로토콜의 경우는 디폴트로 설정된다; port=5060, UDP
    • proxy를 통한 세션 설정을 하는 경우(단, 발신측의 proxy는 없는 경우)
      • 철수가 영희의 공인 식별자만 아는 경우임
      • 이럴 경우, 철수는 직접 Location Service에 쿼리하여 DNS만으로 영희의 inbound proxy의 Location SIP URI인 contact address를 구한다.(즉 사전에 영희가 registrar에 자신의 공인 식별자와 위치 정보를 등록해놓은 상태이다.)
      • 영희의 inbound proxy는 마찬가지로 Location 쿼리 후에 최종적으로 영희가 있는 Location URI를 구하여 전송한다.
    • proxy를 통한 세션 설정을 하는 경우(단, 발신측의 outbound proxy가 있는 경우)
      • 철수는 단지 영희의 공인 식별자를 알려주기만 하면 된다.
      • 철수 대신에 outbound proxy가 영희가 있는 곳까지 쿼리를 대신 수행하게 된다. 
      • 철수의 모든 전화시도는 outbound proxy가 대신한다.
      • 즉 철수의 모든 request 요청은 철수의 outbound proxy로 전달된다. 

 

---