Chapter 3. SIP Method on RFC 3261

SIP 호 절차를 이해하기 위해서는 SIP 메세지에 포함된 SIP헤더를 잘 알아야 합니다. SIP헤더에 대한 기본적인 내용만 알고 있어도 쉽게 호절차를 분석할 수 있습니다. 특히, 이기종 장비간 SIP Trunk 연동이나 단말 연동 시 장애가 발생할 경우에 SIP 패킷을 수집하여 분석하는 과정을 거치게 됩니다. SIP 헤더를 알지 못하면 수집된 패킷은 암호문일 뿐입니다. UC 엔지니어들의 SIP에 대한 피상적인 곁눈질를 넘어 체계적으로 SIP 기술을 이해할 수 있를 도록 SIP 헤더를 살펴보겠습니다.  


1. SIP주소 체계

PTSN 전화망은 E.164 주소 체계를 사용하고, 인터넷망은 IP 주소 체계를 사용합니다. E.164 주소체계는 사람이 인식하기 쉬운 주소 체계이지만, IP 주소체계는 어렵습니다. 인터넷에서 유트브나 네이버를 접속하기 위해 IP주소를 웹브라우저에 입력하여 접속할 수 있지만, 사람들은 도메인 네임인 www.youtube.com 이나 www.naver.com이라는 도메인 네임 주소로 접속합니다. IP 주소 체계보다 도메인 네임 체계가 훨씬 이해하기 쉽기 때문입니다. 전자메일도 마찬가지입니다.

SIP를 이용한 통화를 위한 주소체계는 다양한 형식의 주소 방식을 지원합니다. 

  • FQDN (Fully-Qualified Domain Names)
    인터넷 서핑을 할 때 웹브라우저에 입력하는 도메인 주소 체계입니다. 도메인의 앞 자리에 사용자명 또는 단말기명을 붙여서 사용합니다.  
    예)sip:bob.cisco.com


  • SMTP와 같은 Domain Names (RFC2368)
    메일 주소와 같은 방식을 사용합니다.

    예) sip:
    bob@cisco.com


  • E.164와 같은 주소 
    사용자이름 부분에 전화번호를 넣어서 사용합니다. 
    예) sip:14085551234@gateway.com; user=phone


  •  혼합된 주소 체계
    IP 주소를 함께 사용할 수 있습니다. 
    예) sip:14085551234@10.1.1.1; user=phone
         sip:bob@10.1.1.1


6. 주요 SIP Header 분석

일반적으로 SIP 헤더에 포함되는 정보는 다음과 같습니다. 
 

 INVITE sip:bob@biloxi.com SIP/2.0
 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
 Max-Forwards: 70
 To: Bob <sip:bob@biloxi.com>
 From: Alice <sip:alice@atlanta.com>;tag=1928301774
 Call-ID: a84b4c76e66710@pc33.atlanta.com
 CSeq: 314159 INVITE
 Contact: <sip:alice@pc33.atlanta.com>
 Content-Type: application/sdp
 Content-Length: 142

 

SIP 헤더의 내용을 대충 이해할 수만 있어도 위의 메세지가 앨리스가 밥에게 보내는 SIP INVITE 메세지로 통화 요청을 위해 생성되었음을 알 수 있습니다. 왜 이렇게 이해할 수 있는 지를 각 SIP헤더를 살펴보면서 이해해보겠습니다.   


  • INVITE sip:bob@biloxi.com SIP/2.0
    메세지의 첫 줄에는 Method와 메세지를 수신하는 최종 단말의 주소와 버전이 명기되므로 메세지가 생성된 목적을 확인할 수 있습니다.  
    - INVITE : 요청한 메쏘드
    - sip:bob@biloxi.com : Request URI
    - SIP/2.0:  버전
    Request-URI는일반적으로는 To 필드의 URI값을 이용하여 표시합니다. 

    이 줄은 Biloxi.com 도메인에 속해 있는 밥에게 전화를 걸고 싶다는 의미입니다.


  • Via: SIP/2.0/UDP  pc33.atlanta.com;branch=z9hG4bK776asdhds 
    Via 헤더는 요청에 대한 응답을 위한 경로를 나타냅니다. branch는 시공간에서 유일한 값을 가지며, 
    트랜잭션 식별자입니다. 트랜잭션은 호 설정 또는 호 종료와 같은 단위작업을 의미하며 User Agent 간에 생성됩니다.  

    이 줄은 SIP INVITE요청에 대한 응답인 200 OK를 앨리스에게 바로 전송하지 말고 pc33.atlanta.com을  경유할 것을 요청한다는 의미입니다.  


  • Max-Forwards: 70 
    시그널링 경로 상에 SIP 서버의 최대 홉 수를 나타냅니다. IP네트워크의 TTL (Time to Live)과 같습니다.


  • To: Bob <sip:bob@biloxi.com>
    From: Alice <sip:alice@atlanta.com>;tag=1928301774
    SIP 메세지의 출발지와 목적지를 나타내지만, 실제 메세지의 라우팅에 사용되지 않으며 Display Name의 의미를 가집니다. 

    이 줄은 앨리스가 밥에게 세션 설립을 요청하는 다이얼로그라는 의미입니다.

    From과 To 헤더는 현재 세션의 진행방향을 의미하는 것으로 현재 메세지의 발신자와 수신자를 의미하는 것이 아닙니다. 따라서 S
    IP INVITE 메세지의 응답인 200 OK에서 From 과 To 헤더의 내용이 바뀌지 않습니다. From과 To의 값이 엉뚱하게 적혀있어도 SIP 프로토콜이 진행되는 데는 문제가 없습니다만, 요즘에는 SIP 보안이 강화가 되면서 From 과 To 헤더가 잘못 명기되면 호가 진행되지 않기도 합니다. 


  • Call-ID: a84b4c76e66710@pc33.atlanta.com
    세션에 대한 global unique identifier로 사용하며, 호스트 네임 또는 IP address와 시간을 조합하여 생성됩니다. To/ From/ Call-ID가 결합으로 엘리스와 밥간의 Pee-to-peer SIP 관계를 정의합니다.

    Call-ID가 같은면 하나의 다이얼로그로 인식하므로 세션의 설립과 종료사이의 모든 SIP 메세지는 동일한 Call-ID를 가집니다.  SIP 호 분석 시에 다수의 호가 혼재되어 있어도 Call-ID를 기준으로 개별 호에 대한 분석이 가능합니다. 다이얼로그는 다수의 트랜잭션으로 이루질 수 있으므로 트랜잭션의 식별은 Via헤더의 branch 값으로 추적하고, 다이얼로그의 식별은 Call-ID와 From 및 To의 Tag로 추적합니다.


  • CSeq: 314159 INVITE
    Commnad Sequence또는 Sequence Number는 정수와 메쏘드 이름으로 나타냅니다. 새로운 요청을 생성할 때마다 1씩 증가시킵니다. 이 요청에 대한 응답인200 OK에서도 같은 값을 확인할 수 있습니다. 

    하나의 요청과 응답은 같은 CSeq값을 가집니다.  


  • Contact: <sip:alice@pc33.atlanta.com>
    SIP URI 포맷으로 되어 있으며, 요청을 보낸 사용자에 대한 직접적인 경로를 나타냅니다.

    일반적으로 FQDN (Fully qualified domain name)나 IP주소를 선호합니다.
      Via 헤더 필드가 요청에 대한 응답 경로를 나타내고, Contact 헤더 필드는 미래의 요청을 보낼 경로를 말합니다. 요청에 대한 응답은 Via 헤더 필드를 참조하며, 신규 요청을 생성할 경우는 Contact 헤더 필드를 참조한다는 것입니다.  


  • Content-Type: application/sdp
    메세지 바디가 있을 경우 메세지 바디에 대한 설명입니다.applicaiton/sdp는 SIP 메세지 바디가 SDP 메세지로 구성되었다는 의미입니다.  


  • Content-Length: 142
    메세지 바디의 크기를 옥텟 (바이트)로 표시합니다. 메세지 바디가 142 바이트로 구성되었다는 의미입니다.


지금까지 기본적인 SIP Header를 살펴보았습니다. 이 후에 나오는 SIP Method별로 추가되는 헤더가 무엇인지를 살펴볼 것입니다. 


  


3. SIP 헤더 분석하기 - SIP Proxy가 없는 경우
지금까지 살펴본 SIP 헤더를 기준으로 SIP 호 절차를 분석해 보겠습니다. 실제 구현되는 일반적인 사례는 아니지만, SIP메세지를 이해하기 쉽도록 SIP 전화기 두 대 사이에 SIP Proxy가 존재하지 않고, 앨리스의 전화기는 밥의 전화기 IP주소를 알고 있다고 가정합니다.  



  • INVITE
    앨리스가 수화기를 들고 밥의 전화번호를 누르는 순간 아래와 같이 INVITE 메세지가 전송됩니다.  

     INVITE sip:bob@192.168.10.20 SIP/2.0
     Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776asdhds
     Max-Forwards: 70
     To: Bob <sip:bob@biloxi.com>
     From: Alice <sip:alice@atlanta.com>;tag=1928301774
     Call-ID: a84b4c76e66710@pc33.atlanta.com
     CSeq: 314159 INVITE
     Contact: <sip:alice@pc33.atlanta.com>
     Content-Type: application/sdp
     Content-Length: 142

    From과 To 헤더를 보니 앨리스가 밥에게 보내는 INVITE 요청입니다. INVITE의 요청에 대한 응답은 Via 헤더에서 표시한 pc33.atlanta.com을 경유하라고 표시되어 있으며, CSeq를 보니 314159 번의 INVITE 메세지입니다. Content-Type 헤더에 메세지를 보니 SIP 메세지에 SDP가 포함되어 있음을 알수 있습니다. SDP는 나중에 다루겠습니다. 
     
  • 200 OK
    밥의 전화기는 INVITE를 수신 후에 벨 소리를 재생합니다. 밥이 수화기를 드는 순간 200 OK 메세지가 앨리스에게 전달됩니다.  

     SIP/2.0 200 OK
     Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=10.1.3.33
     To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
     From: Alice <sip:alice@atlanta.com>;tag=1928301774
     Call-ID: a84b4c76e66710@pc33.atlanta.com
     CSeq: 314159 INVITE
     Contact: <sip:bob@192.168.10.20>
     Content-Type: application/sdp
     Content-Length: 131

    From과 To 헤더는 현재 메세지의 출발지와 목적지가 아닌 호의 진행방향을 나타내는 것으로 INVITE 메세지의 From과 To헤더와 동일합니다.

    CSeq 헤더는 314159 INVITE 요청에 대한 응답임을 나타냅니다. 패킷 분석 시 여러 호가 동시에 진행될 때 어떤 호에 대한 응답인지를 판단할 때 CSeq를 통해 확인합니다. 
     
  • ACK
    앨리의 전화기가 200 OK를 수신하였음을 확인하는 ACK를 전송합니다.  

     ACK sip:bob@192.168.10.20 SIP/2.0
     Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bKnashds8
     Max-Forwards: 70
     To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
     From: Alice <sip:alice@atlanta.com>;tag=1928301774
     Call-ID: a84b4c76e66710@pc33.atlanta.com
     CSeq: 314159 ACK
     Content-Length: 0

    CSeq가 31459 이므로 앞의200 OK에 대한 ACK임을 확인합니다.  


  • BYE
    BYE 세션은 발신자와 수신자 누구나 생성할 수 있습니다. 수화기를 먼저 내리는 쪽에서 BYE가 전송됩니다.  

     BYE sip:alice@10.1.3.33 SIP/2.0
     Via: SIP/2.0/TCP 192.168.10.20;branch=z9hG4bKnashds8
     Max-Forwards: 70
     To: Alice <sip:alice@atlanta.com>;tag=1928301774
     From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
     Call-ID: a84b4c76e66710@pc33.atlanta.com
     CSeq: 231 BYE
     Content-Length: 0  

    From 과 To 헤더를 보니 세션의 진행방향은 밥이 앨리스에게 요청하는 다이얼로그이므로 밥이 먼저 수화기를 내려놓았습니다.


  • 200 OK
    CSeq를 보니 BYE 에 대한 200 OK임을 알 수 있습니다.  
     
     SIP/2.0 200 OK
     Via: SIP/2.0/TCP 192.168.10.20
     To: Alice <sip:alice@atlanta.com>;tag=1928301774
     From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
     Call-ID: a84b4c76e66710@pc33.atlanta.com
     CSeq: 231 BYE
     Content-Length: 0


SIP 패킷을 캡쳐하여 분석할 경우에 유용합니다. 이제 본격적으로 SIP 네트워크에 SIP Proxy가 있는 경우를 살펴보겠습니다.  



3. SIP 헤더 분석하기 - SIP Proxy가 있는 경우

실제 SIP망을 구성할 때는 SIP Proxy 서버나 IP PBX가 항상 존재합니다. IP PBX는 제품에 따라 SIP Proxy로 구현하거나 B2BUA로 구현됩니다. 앨리스의 전화기는 밥의 전화기 주소를 알지 못하므로INVITE 메세지를 SIP Proxy로 전송하는 과정부터 살펴보겠습니다.  




앞에서 설명 부분과 다른 SIP헤더를 위주로 살펴보겠습니다.  


    • INVITE (앨리스가 SIP Proxy 서버로 보내는 것)
      앨리스는 밥에게 전송할INVITE 메세지를 SIP Proxy서버로 전송합니다.

       INVITE sip:bob@biloxi.com/TCP SIP/2.0
       Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776asdhds
       Max-Forwards: 70
       To: Bob <sip:bob@biloxi.com>
       From: Alice <sip:alice@atlanta.com>;tag=1928301774
       Call-ID: a84b4c76e66710@pc33.atlanta.com
       CSeq: 314159 INVITE
       Contact: <sip:alice@pc33.atlanta.com>
       Content-Type: application/sdp
       Content-Length: 142



    • INVITE (SIP Proxy 서버가 밥에게 보내는 것)
      SIP  Proxy 서버를 경유한 INVITE 메세지는 다음과 같이 Via 헤더와 Max-Forwards 헤더에 변화가 생겼습니다.  

      INVITE sip:bob@192.168.10.20/TCP SIP/2.0
      Via: SIP/2.0/TCP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
      Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776asdhds ;received=10.1.3.33
      Max-Forwards: 69
      To: Bob <sip:bob@biloxi.com>
      From: Alice <sip:alice@atlanta.com>;tag=1928301774
      Call-ID: a84b4c76e66710@pc33.atlanta.com
      CSeq: 314159 INVITE
      Contact: <sip:alice@pc33.atlanta.com>
      Content-Type: application/sdp
      Content-Length: 142

      첫 번째 Via 헤더는 SIP Proxy 서버가 삽입한 것으로 INVITE 요청에 관한 응답이 SIP Proxy를 경유하도록 요청합니다. Max-Forwards 헤더가 70에서 69로 줄었습니다. 한 개의 SIP 서버를 지날 때마다 1씩 줄어듭니다. 

      CSeq 와 Call-ID가 SIP Proxy를 지나가지만 변경되지 않았습니다. SIP Proxy 서버는 제한적으로 메세지를 추가 삭제할 수 있지만, 새로운 세션을 생성하지 않는다는 것을 의미합니다. 
        

       

    • 200 OK (밥이 SIP Proxy 서버로 보내는 것)
      밥은 INVITE의 Via 헤더를 그대로  복사하여 200 OK에 포함하였으므로 200 OK가 SIP Proxy 서버를 경유합니다.    

       SIP/2.0 200 OK
       Via: SIP/2.0/TCP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 ;received=192.168.10.1
       Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=10.1.3.33
       To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
       From: Alice <sip:alice@atlanta.com>;tag=1928301774
       Call-ID: a84b4c76e66710@pc33.atlanta.com
       CSeq: 314159 INVITE
       Contact: <sip:bob@192.168.10.20>
       Content-Type: application/sdp
       Content-Length: 131


    • 200 OK (SIP Proxy 서버가 앨리스로 보내는 것)
      Via 헤더가 하나 줄었습니다. SIP Proxy 서버가 임의로 삽입한 Via헤더는 엘리스의 전화기에는 필요가 없으므로 SIP Proxy가 삭제합니다.

       SIP/2.0 200 OK
       Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=10.1.3.33
       To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
       From: Alice <sip:alice@atlanta.com>;tag=1928301774
       Call-ID: a84b4c76e66710@pc33.atlanta.com
       CSeq: 314159 INVITE
       Contact: <sip:bob@192.168.10.20>
       Content-Type: application/sdp
       Content-Length: 131


    • ACK
      앨리스의 전화기는 밥의 200 OK를 정확히 수신했음을 확인하는 ACK를 밥의 전화기로 바로 보냅니다. ACK는 새로운 신규 요청이므로 다이얼로그 상의 Contact 헤더를 따라 직접 전달됩니다. 
       

모든 SIP 메세지를 SIP Proxy서버를 경유하게 하기
Via 헤더를 통해 INVITE에 대한 200 OK는 SIP Proxy서버를 경유하지만, ACK 이하의 모든 신규 요청 메세지는 Contact 헤더를 참조하여 단말끼리 직접 송수신합니다. 


기업의 IP PBX는 호의 상태를 관리 및 과금 데이타 생성을 위해 호 절차의 따른 모든 시그널링 메세지가 IP PBX 를 경유하도록 합니다. B2BUA가 아닌 SIP Proxy 서버가 자신에게 등록된 모든 단말의 시그널링이 경유되도록 하기 위해서는 기존 SIP 헤더를 변경하거나 새로운 SIP 헤더가 필요합니다. 
  


질문

모든 시그널링 메세지가 SIP Proxy 서버를 경유하도록 하기 위해 INVITE 메세지가 SIP Proxy 서버를 경유할 때 새로운 SIP 헤더를 삽입해야 합니다. 어떤 헤더가 필요할까요?






"다시쓰는 SIP의 이해" 연재의 다른 글  


2015/07/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 22편 Chapter 8. RTP의 이해


2015/07/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 21편 Chapter 7. 가끔 보는 SIP Method


2015/07/08 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 20편 Chapter 7. 가끔 보는 SIP Method


2015/05/20 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 19편 Chapter 7. 가끔 보는 SIP Method


2015/05/18 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 18편 Chapter 7. 가끔 보는 SIP Method


2015/05/07 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 17편 Chapter 6. SIP Method


2015/02/26 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 16편 Chapter 6. SIP Method


2015/02/23 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 15편 Chapter 6. SIP Method


2015/02/11 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 14편 Chapter 6. SIP Method

2015/01/30 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 13편 Chaper 5.SDP


2015/01/29 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 12편 Chapter 5. SDP


2015/01/05 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 11편 Chapter 5. SDP


2014/12/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 10편 Chapter 4. SIP Response


2014/12/04 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 9편 Chapter 3. SIP Method on RFC 3261


2014/12/03 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 8편 Chapter 3. SIP Method on RFC 3261


2014/12/02 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 7편 Chapter 3. SIP Method on RFC 3261


2014/11/26 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 6편 Chapter 2. SIP Overview


2014/11/21 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 5편 Chapter 2. SIP Overview


2014/11/19 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 4편 Chapter 1. VoIP의 이해 (3)


2014/11/11 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 3편 Chapter 1. VoIP의 이해 (2)


2014/11/05 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 2편 Chapter 1. VoIP의 이해 (1)




라인하
트 유씨누스 (CCIEV #18487)
  --------------------------------------
ucwana@gmail.com (라인하트의 구글 이메일) 
http://twitter.com/nexpertnet (넥스퍼트 블로그의 트위터, 최신 업데이트 정보 및 공지 사항) 
http://groups.google.com/group/cciev (시스코 UC를 공부하는 사람들이 모인 구글 구룹스) 
http://groups.google.com/group/ucforum (UC를 공부하는 사람들이 모인 구글 구룹스) 
세상을 이롭게 하는 기술을 지향합니다. ______________________________________________



저작자 표시 비영리
신고
Posted by 라인하트
TAG ,

댓글을 달아 주세요

  1. mc545 2014.12.03 19:11 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 글 감사합니다 ^_^
    많이 배우고 갑니다 ^^

  2. plrmsu 2015.04.02 11:46 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 글 감사합니다^^
    혹시 궁금 한게 있는데

    "3. SIP 헤더 분석하기 - SIP Proxy가 있는 경우"에서
    발신 invite via 의 branch 값과 invite에 대한 200ok의 branch 값이 동일 해야 되지 않나여? 그래야지 같은 트랜잭션으로 인식을 할것 같은데.. 아닌가여?^^;

  3. X 2015.04.22 16:31 신고  댓글주소  수정/삭제  댓글쓰기

    그런데 위의 설명에는 Alice->proxy INVITE의 via branch 값과 proxy->Alice 200OK의 branch 값이 다르게 표시 되 있어서 저도 위의 분과 마찬가지로 궁금해서 글 올립니다. 단순 오탄가여 아니면 제가 잘 못 이해한건가요 ㅠ

  4. X 2015.04.23 10:12 신고  댓글주소  수정/삭제  댓글쓰기

    ^^항상 글 잘 읽고 있습니다. 정말 감사드립니다.



티스토리 툴바