본문 바로가기
SIP의 이해

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

라인하트 2015. 2. 26. 08:00


Chapter 6. SIP Method


6. INFO의 이해

UAC와 UAS가 기존 SIP 세션을 종료하거나 변경하지 않으면서 단순히 상대방의 SIP 관련 정보를 요청할 필요가 있습니다. 지금까지 살펴본 SIP 메쏘드는 세션의 설립, 변경 및 종료를 위한 것으로 정보 요청을 위해 사용하기에는 적합하지 않습니다.  

  • SIP 세션을 설립을 위한 메쏘드 : INVITE / 200 OK / ACK 
  • SIP 세션을 종료를 위한 메쏘드 : BYE
  • SIP 세션의 상태 변경을 위한 파라미터 변경을 위한 메쏘드 : UPDATE / re-INVITE

따라서, SIP 세션이 생성 후 - 200 OK 이후 부터 BYE전까지 - 세션 관련 제어 정보를 교환하기 위한 새로운 메쏘드가 필요합니다. SIP는 단순 정보 전송을 위해 SIP INFO 메쏘드를 정의하였습니다. 


SIP INFO는 RFC 2976 The SIP INFO Method에 정의되었으며, SIP 시그널링 경로를 활용하여 어플리케이션 레벨의 정보를 전송하는 것을 목적으로 합니다. SIP INFO를 통해 교환하는 정보의 예는 다음과 같습니다.

  • PSTN 게이트웨이간에 PSTN Signaling 메세지 전송
  • DTMF Digits 전송
  • WIreless Mobility 어플리케이션 지원을 위해 무선 신호의 세기를 전송
  • 계좌의 잔액 조회 정보 등 
  • 세션 참가자 간에 이미지나 비 스트리밍 정보를 전송  


SIP INFO 메쏘드는 정보가 SIP INFO 헤더로 전송 가능하더라도 SIP 메세지 바디에 실어서 전송합니다. INFO 메쏘드를 가장 많이 사용하는 것이 ARS ( Automatic Response System) 자동응답 시스템과 연결된 전화기에서 DTMF를 전송할 때입니다.  





위의 그림과 같이 앨리스는 은행 ARS 시스템에 접속한 후에 요청한 숫자를 다이얼 패드를 통해 전달하는 과정을 표시한 것입니다. 실제로는 다수의 SIP INFO와 200 OK로 구성됩니다.  




SIP INFO 메세지를 정상적으로 수신한 후 200 OK로 응답하지만, 상황에 따라 다음과 같이 응답할 수 있습니다.  

  • 481 Call leg / Transaction Dose not Exist
    수신된 INFO 가 기존의 Call leg와 매치가 되지 않을 때 

  • 415 Unsupported Media Type
    UAS가 이해할 수 없는 메세지 바디를 포함하여 처리할 수 없을 때 

  • 487 Request Terminated
    SIP INFO 요청을 처리 중인 가운데 CANCEL 메쏘드를 받았을 때 


RFC 2976에서 SIP INFO의 메세지 바디에 Digit을 실어 보낼 수 있다고 되었지만, Content-Type에 대한  정확한 형식을 규정하지 않아 제조사별로 다른 방식을 사용합니다. 이기종 장비간의 상호 연동에 문제를 일으킬 수 있으므로 Contents-type을 UAC와 UAS간에 동일하게 사용하는 지를 확인해야 합니다. DTMF를 위한 SIP INFO 헤더의 Content-Type 헤더 부분에 대한 정의는 아래와 같이 제조사별로 다르게 사용합니다.
 

  • “Contents-type; audio/telephone-event”
  • “Contents-type; application/vnd.networks.digits”
  • “Content-Type: text/plain”




7. DTMF의 이해

SIP INFO의 대표적인 응용 사례가 DTMF 전송이므로 DTMF 전송에 대해 자세히 살펴보겠습니다. DTMF는 Dual Tone Multi Frequency 의 약어로 2 개의 주파수 성분을 갖는 신호를 가리킵니다. 전화기가 발신전화번호를 전화국의 PBX에 정확하게 전달하기 위해 사용합니다. 전화기의 수화기를 들고 다이얼패드의 숫자를 누를때마다 늘리는 소리가 DTMF 신호음으로 숫자가 주파수로 변환된 것입니다. 전화통화중에 상대방이 다이얼패드의 Digit을 누르면 “삐~”하는 소리를 들었던 기억이 있을 것입니다. DTMF 신호음은 사람이 들을 때는 잡음이지만, ARS 자동응답 시스템은 주파수를 인식하고 정확하게 숫자로 변환합니다. 


DTMF를 이용하여 숫자를 전달하는 방법은 크게 두가지로 나뉩니다. 


  • Out of band 방식
    Out of band 방식은 시그널링 경로를 이용하여 DTMF 신호를 전달합니다. 전화기나 게이트웨이가 음성을 전달하는 RTP에 DTMF 신호음을 그대로 전달하지 않고, 숫자로 변환하여 시그널링 채널로 전달합니다. H.323 네트워크에서는 H.245 채널을 이용하고, SIP 네트워크에서는 SIP INFO를 이용합니다.

    Out of band 방식은 DTMF Duration에 대한 정보를 표현할 수 없으므로 숫자(Digit)를 길게 또는 짧게 누르는 것을 표현하지 못합니다.     DTMF를 발신하는 사용자는 Digit을 누른 기간 만큼 톤을 듣지만,  수신자는 발신자가 Digit 버튼을 떼는 순간 Signaling을 통해 메세지가 전달되므로 짧은 톤 만을 듣습니다. 


  • In band 방식
    In band 방시은 실제 음성이 전달되는 Media 경로를 이용하여 DTMF 신호를 전달합니다. 전화기가 게이트웨이가 음성을 전달하는 RTP에 DTMF 신호음을 그대로 전달하므로 DTMF Duration 까지도 전달됩니다. In band 방식은 시그널링과 상관없으므로 모든 VoIP 프로토콜에서 사용되며, Bypass와 RFC 2833있습니다. 

    -     Bypass 방식
    바이패쓰 방식은 Digit을 RTP가 사용하는 코덱으로 압축해서 음성과 같이 보냅니다. 별도의 형식이나 협상이 필요없이 사용자가 digit을 누르면 전화기나 게이트웨이가 숫자에 맞는 주파수를 생성하여 음성과 함께그대로 전달합니다. G.711이 아닌 G.729나 G.723과 같은 압축률이 높은 코덱을 사용할 경우 DTMF 톤이 변형되거가 정보가 손실될 가능성이 있습니다.

    Bypass 방식의 Offer는 다음과 같이 미디어 협상에서 음성 코덱만을 교환합니다. 

       v=0
       o=alice 2890844526 2890844526 IN IP4 atlanta.com
       c=IN IP4 10.1.3.33 
       t=0 0
       m=audio 49172 RTP/AVP 18 
       a=rtpmap:18 G729/8000 


    - RFC 2833 방식
    RFC 2833 방식은 음성과 같은 미디어 세션의 RTP 패킷에 DTMF의 번호와 볼륨, duration이 명시되어 전송됩니다. 이 방식은 이름 그대로 RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals 권고안을 따릅니다.  

    RTP는 전송프로토콜로 UDP를 사용하므로 수신자로부터 수신 확인 응답을 받지 못합니다.     패킷이 분실될 경우에 재전송할 수 있는 방법이 없으므로 하나의 digit을 전송할 때 여러번 전송하여 손실 가능성을 낮춥니다. 

    RFC 2833은 Offer/Answer교환 시 DTMF 전송 방법을 협상합니다. 다음은 RFC 2833의 Offer 메세지 입니다. 

       v=0
       o=alice 2890844526 2890844526 IN IP4 atlanta.com 
       c=IN IP4 10.1.3.33
       t=0 0
       m=audio 49172 RTP/AVP 18 101
       a=rtpmap:18 G729/8000 
       a=rtpmap:101 telephone-event/8000

    m= 필드의 Payload Type 18은 음성 코덱 G.729를 표시한 것이며, Payload Type 101은 RFC 2833 telephony-event를 표시한 것으로 DTMF를 전달합니다. 

    RFC 2833으로 전송된 패킷을 캡쳐하게 되면 In-band Bypass 방식과 달리 전동되는 DTMF Digits을 확인할 수 있습니다. 다수의 패킷으로 같은 DTMF 숫자를 보내는 것은 패킷 손실로 인한 정보 손실 가능성을 낮추기 위함입니다. 





DTMF는 전송간이 에러가 발생할 수 있는 여지가 있으므로 어플리케이션 레벨에서 확인하는 절차가 반드시 필요합니다. DTMF 를 많이 사용하는 IVR (Interactive Voice Response)이나 ARS 자동 응답 시스템은 수신된 Digits 이 정확한지를 어플리케이션 레벨에서 다시 확인하는 절차를 만들기도 합니다. 어플리케이션 레벨의 확인 절차 예는 "지금 전송한 회원번호가 XXXX이면 1번, 아니면 2번을 눌러 주세요" 와 같이 재확인 멘트를 재생하는 것이니다.   


8. 가장 흔한 DTMF 관련 장애     

DTMF 전송에서 Out of band 를 사용할 경우 DTMF가 두 번 중복으로 인식되는 경우가 있습니다. In band방식은 사용자가 digit 버튼을 누르는 시점에 DTMF 톤을 보내지만, Out of band 방식은 사용자가 digit 버튼을 떼는 순간 보내기 때문입니다. 전화기가 DTMF 신호를 감지하면  RTP를 제거해야 하는데 감지하는 속도가 떨어지면 초기의 DTMF 톤이 RTP를 통해 나간 후에 제거가 시작되기 시작합니다. 이런 경우에 DTMF를 수신하는 장비가 In band로 들어온 DTMF도 전송하고 Outband로 들어온 DTMF도 전송합니다. 따라서, 시차를 두고 전송되는 DTMF로 인해 사용자가 같은 숫자를 두번 누른 것과 같은 현상이 발생할 수 있습니다.

전화기나 게이트웨이가 위와 같은 문제로 장애를 일으킨다면 100% 버그입니다. VoIP 초장기와 달리 DTMF 전송 문제는 적은 편이지만, 지금도 심심치 않게 발생합니다. DTMF 전송은 망환경에 따라 차이가 많으므로 In band와 out of band를 모두 테스트하여 가장 최적인 방법을 이용합니다. 




마치며
"SIP의 이해" 보다 쉽게 이해할 수 있도록 "다시쓰는 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를 공부하는 사람들이 모인 구글 구룹스) 
세상을 이롭게 하는 기술을 지향합니다. ______________________________________________


저작자표시 비영리

'SIP의 이해' Related Articles

티스토리툴바