본문 바로가기
SIP의 이해

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

라인하트 2014. 12. 4. 08:30

Chapter 3. SIP Method on RFC 3261


8.  CANCEL의 개요 
지금까지 발신자가 전화를 걸면 반드시 통화가 되는 과정을 설명하였지만, 현실에서는 전화를 걸다가 갑자기 수화기를 내려놓는 경우가 종종 있습니다. 전화번호를 잘못 눌렀다던지 상사분이 갑자기 부른다던지 상대방이 전화를 받지 않는다던지 하는 경우입니다. SIP는 어떻게 처리할까요? 


기존의 요청을 취소하기 위해 SIP CANCEL 매쏘드를 이용합니다. CANCEL은 취소 요청이므로 응답이 발행되기 전에 사용해야 합니다. 만일 INVITE 요청에 대해 200 OK 응답를 수신하면 통화중인 상태이므로 CANCEL 이 아닌 BYE를 이용합니다.  


CANCEL의 메세지를 분석해 보겠습니다. 


    • CANCEL
      INVITE 요청에 대한 200 OK 응답 전에 CANCEL을 송신합니다.

       CANCEL sip:bob@192.168.10.20 SIP/2.0
       Via: SIP/2.0/TCP 10.1.3.33;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: 10197 CANCEL
       Contact: <sip:alice@atlanta.com>
       Reason: SIP ;cause=486 ;text=“Busy Here”
       Content-Length: 0

      CALCEL은 취소 사유를 명기하기 위해 Reason 헤더를 이용합니다. 위의 메세지에서 Reason 헤더에 표시된 취소 사유는 486 Busy Here 입니다.  


    • 200 OK
      엘리스의 CANCEL 요청에 대해 정상처리하였음을 통지하는 200 OK 응답입니다. 

      SIP/2.0 200 OK
       Via: SIP/2.0/TCP 10.1.3.33
       From: Alice <sip:alice@atlanta.com>;tag=1928301774
       To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
       Call-ID: a84b4c76e66710@pc33.atlanta.com
       CSeq: 10197 CANCEL
       Content-Length: 0

      200 OK가 INVITE에 대한 것인지 CANCEL에 대한 것인지를 확인하기 위해서는 CSeq 헤더를 참조합니다.    


위의 그림에서 CANCEL의 트랜잭션은 요청과 응답으로 정상 처리가 되었습니다만, INVITE 요청은 아직 아무런 응답을 받지 못했습니다. 밥의 전화기는 INVITE에 대한 응답으로 487 Request Terminated를 발행하고 엘리스는 ACK를 전송하면서 마무리합니다. 


INVITE에 대한 응답이 200 OK가 아닌 경우가 처음입니다. 4xx 응답에 대한 수신 확인을 위해 항상 ACK 가 발행됩니다. 487 응답에 대한 메세지를 분석해 보겠습니다.

    • 487 Request Terminated
      밥의 전화기는  CANCEL 요청을 수신한 후에 200 OK를 송신한 후 기존의 INVITE 세션 요청에 대한 처리를 중지하고 487 응답을 발행합니다. 
       
       SIP/2.0 487 Request Terminated
       Via: SIP/2.0/TCP 10.1.3.33
       From: Alice <sip:alice@atlanta.com>;tag=1928301774
       To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
       Call-ID: a84b4c76e66710@pc33.atlanta.com
       CSeq: 314159 INVITE
       Content-Length: 0

      CSeq 헤더를 통해 INVITE에 대한 응답임을 알수 있습니다. 


    • ACK
      엘리스는 ACK를 전송하여  487 응답을 정상 수신하였음을 통지합니다. 

       ACK sip:bob@192.168.10.20 SIP/2.0
       Via: SIP/2.0/TCP 10.1.3.33;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 ACK
       Content-Length: 0



9. CANCEL - 200 OK 발행과 동시에 CANCEL 을 수신했을 경우  

발생 확률은 매우 적지만 INVITE에 대한 200 OK 발행하자마자 CANCEL이 수신되었을 때를 생각해 봅시다. 원격지 단말간에 네트워크로 전송되는 트래픽이므로 충분히 발생할 가능성이 있습니다.


  



문제점은 CANCEL은 200 OK 응답 전에 사용한다는 전제를 위배하는 것입니다. 이를 해결하기 위한 방법은 위의 그림과 같이 새로운 메쏘드를 만들거나 프로세스를 강제로 종료시키는 것이 아닌 기존 트랜잭션을 그대로 활용하는 방법을 사용합니다.  


엘리스의 전화기는 CANCEL 을 발행하자마자 INVITE에 대한 200 OK를 수신하지만 당황하지 않고 200 OK를 정상 수신했음을 통지하기 위해 ACK를 발행합니다.  밥의 전화기도 마찬가지로 당황하지 않고 CANCEL에 대한 200 OK를 발행합니다. 엘리스의 전화기와 밥의 전화기는 기존의 CANCEL과 INVITE에 대한 트랜잭션을 완료한 후 이미 설립된 세션을 종료하기 위해 BYE 를 전송합니다.


오류가 발생하지만 모든 트랜잭션을 정상 처리하면서 마무리짓습니다.  

 


10. CANCEL의 적용 사례 - Call Forking

사용자는 한 개의 전화번호나 URI와 같은 AoR 사용하면서 다수의 단말을 보유합니다. 호가 인입되면 SIP Proxy는 AoR과 바인딩된 모든 단말에 INVITE를 송신하게 되고 200 OK를 보내는 단말을 제외한 나머지 전화기들은 벨이 울리는 것을 멈추도록 기존의 INVITE를 취소해야 합니다.



Biloxi.com Proxy 서버는 밥에게 온 INVITE 메세지를 등록된 3개의 단말로 전송합니다. 3 개의 INVITE는 Via헤더의 서로 다른 branch 값을 가집니다. Call Forking 은 시간 간격을 두고 벨을 울리게 하는 순차적인 방법과 동시에 벨을 울리게 하는 방법이 있습니다. Call Forking 시 Proxy 서버는 200 OK를 송신하지 않은 다른 단말의 호 진행을 중단하기 위해 CANCEL 을 발행합니다. 


  • CANCEL
    CANCEL 메세지는 기존에 살펴본 것과 동일하며 Reason 헤더의 값만 200 "Call completed elsewhere"로 다릅니다. 

     CANCEL sip:bob@192.168.10.20/TCP SIP/2.0
     Via: SIP/2.0/TCP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
     Max-Forwards: 70
     To: Bob <sip:bob@biloxi.com>
     From: Server10 <sip:server10.biloxi.com>;tag=1928301774
     Call-ID: a84b4c76e66710@pc33.atlanta.com
     CSeq: 6187 CANCEL
     Contact: <sip:server10.biloxi.com>
     Reason: SIP ;cause=200 ;text=”call completed elsewhere”
     Content-Length: 0


11. OPTIONS의 개요
OPTIONS 메쏘드는 UA가 다른 UA나 SIP Proxy의 Capability 확인을 목적으로 사용합니다. INVITE 요청을 통한 세션 설립과정에서 확인할 수 있는 내용이지만 세션 설립 전에 확인할 수 있다는 것이 장점입니다. OPTIONS를 이용하여 확인할 수 있는 내용은 다음과 같습니다.

    • 지원 가능한 매쏘드
    • 지원 가능한 컨텐츠 타입
    • 확장 헤더
    • 코덱 등


OPTIONS 메세지를 분석해 보겠습니다.  

OPTIONS 및 200 OK에 새롭게 나타난 헤더에 대해 살펴보겠습니다. 

    • Contact : 자신에게 연결가능한 Contact address
    • Allow : 지원 가능한 메쏘드 리스트
    • Accept-language : 지원 언어
    • Accept : Message Body type (Accept 헤더가 없을 경우 “application/sdp”로 가정) 


OPTIONS 요청은 긴급을 요하는 메세지가 아니므로 UA가 응답할 수 없는 상황에서는 “486 Busy Here” 와 같은 응답으로 대신할 수 있습니다.  


12. OPTIONS 적용 사례 - OPTIONS PING
UA와 SIP Proxy  서버간의 Keepalive 매커니즘은 REGISTER 메쏘드를 이용합니다. UA는 등록이 해제(Expires)되기 전에 일정 간격으로 재등록을 시도합니다. 일반적으로 SIP Trunk 구간에서 상호간에 등록을 하지 않으므로 REGISTER 메쏘드를 이용한 Keepalive 매커니즘을 사용할 수 없으므로 INVITE가 발행되기 전까지는 대상 장비의 Keepalive 상태를 확인할 수 없습니다. SIP 트렁크로 연결된 장비간에 Keepalive매커니즘을 제공하가 위해 OPTIONS 메쏘들를 이용합니다.  


OPTIONS 메세지를 이용한 Keepalive를 주기적으로 주고 받다가 문제가 있는 장비로 INVITE 메세지를 전송하지 않도록 합니다. 만일 OPTIONS PING을 사용하지 않으면 SIP Trunk 구간에서 INVITE에 대한 응답이 수신될 때까지 장비는 기다리거나 TImeout 이 완료되어서야 우회루트로 재송신합니다. OPTIONS PING은 INVITE에 처리를 빠르게 하기 위한 방법입니다. 


OPTIONS PING은 장비와 장비간의 직접적인 Keepalive 체크이므로 DNS가 아닌 IP주소를 사용합니다. 만일 FQDN을 이용할 경우 다른 백업 서버로 자동으로 넘어가므로 상대방과의 keepalive  매커니즘에 문제가 발생할 수 있습니다. 

 


마치며
RFC 3261에서 설명하는 6개의 메쏘드를 정리하였고, 다음장에서는 SIP Response에 대해 정리합니다.





"다시쓰는 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를 공부하는 사람들이 모인 구글 구룹스) 
세상을 이롭게 하는 기술을 지향합니다. ______________________________________________



저작자표시 비영리

'SIP의 이해' Related Articles

티스토리툴바