SIP의 이해 - 9. INFO (RFC 2976)

                                                                                글 싣는 순서

                                                                                  1. SIP의 개요 (RFC 3261)
                                                                                  2. SDP의 개요 (RFC 4566 & RFC 3264)
                                                                                  3. Early Media in SDP (RFC 3959, RFC 3960)
                                                                                  4. RFC 3261의 주요 매쏘드 (I)             
                                                                                  5. RFC 3261의 주요 매쏘드 (II) 
                                                                                  6. RFC 3261의 Response의 이해
                                                                                  7. PRACK (RFC 3262) 
                                                                                  8. SUBSCRIBE (RFC 3265) & Nofity (RFC 3680) 
                                                                                  9. INFO  (RFC 2976) 
                                                                                 10. UPDATE (RFC 3311)
                                                                                 11. REFER (RFC 3515)
                                                                                 12. PUBLSIH (RFC 3903)
                                                                                 13. MESSAGE  (RFC 3428)

개요
지금까지 세션을 설립하고, 필요한 세션 파라미터의 교환 등에 대해 중점적으로 다루었습니다. 세션이 설립된 후 기존의 세션을 유지하면서 필요한 정보를 교환할려면, 어떤 요청이 필요한지 생각해 봅시다. 기존의 메쏘드는 설립의 설립, 종료에 대한 것이였습니다. 200 OK 이후 부터 BYE 이전까지 기존의 세션 내에서 UAC와 UAS간에 정보 교환을 할 수 있는 방법이 없습니다. 

세션이 생성된 후, 즉 200 OK 이후의 세션 관련 제어 정보는 INFO를 사용합니다. SIP INFO는 SIP Signaling 경로를 이용하여 어플리케이션 레벨의 정보를 전송하는 것이 목적입니다. 다양한 정보를 교환할 수 있지만, 다음과 같은 정보의 변경은 불가능합니다.

• SIP 호의 상태 변경
• 초기 설정된 세션 파리미터의 변경

위와 같은 변경을 하기 위해서는 UPDATE 나  re-INVITE를 통해 가능합니다. 단순히 세션 완료 전에는 UPDATE를 세션 완료 후에는 re-INVITE를 이용합니다. 물론, UPDATE는 세션 완료 후에도 사용되지만, 추천하지 않습니다. 어쨌든 UPDATE 및 re-INVITE는 다음장에서 다루기로 하겠습니다. 여기서는 세션과 관련된 미디어 속성을 변경하거나 세션 타이머를 업데이트를 할 떄는 UPDATE나 re-INVITE를, 어플리케이션 레벨의 세션 관련 제어 정보를 전송할 떄는 INFO를 사용한다고 이해하시면 되겠습니다.

SIP INFO가 전송하는 주요 정보는 RFC 2976 The SIP INFO Method 에 다음과 같다고 명시합니다. 

• PSTN 게이트웨이간에 PSTN Signaling 메세지 전송
• DTMF Digits 전송
• WIreless Mobility 어플리케이션 지원을 위해 무선 신호의 세기를 전송
• Account balance 정보 전송 (선불카드 시스템에서 사용되는 것으로 추정)
• 세션 참가자간에 이미지 또는 비 스트리밍 정보를 전송  

INFO 메쏘드의 호절차
항상 메쏘드에 대한 호 절차를 이해할 필요가 있습니다. SIP INFO를 사용하는 절차는 다음과 같습니다.

세션이 설립 후 Alice는 어플리케이션 레벨의 정보를 전송하기 위해 SIP INFO를 전달합니다. 여기에서는 DTMF를 전송한다고 가정합니다.

Alice's Bank는 IVR이라고 생각하면 됩니다. 세션 설립 후 IVR이 주민 번호 또는 회원번호를 요구한 것이라고 생각할 수 있습니다. Alice's Bank는 기존의 Call-ID와 동일하므로, SIP INFO를 받아들이고, 200 OK를 전송합니다. RFC 2976에는 Content-Type에 대해 정의하지 않기에 필요에 따라 사용할 수 있습니다. 여기에서는 메세지 바디가 text/plain으로 되어 있다고 나타니며, 전송된 정보는 Digits 3181962 입니다. 이에 대해 정상적으로 처리 되었으므로 200 OK가 전송되었으며, 아래와 같이 다양한 응답이 발생할 수 있습니다.

• 481 Call leg / Transaction Dosenot Exist
  만일 INFO 요청을 받은 UAS가 기존의 Call leg와 매치가 되지 않을 때
  
• 415 Unsupported Media Type
  UAS가 이해할 수 없는 메세지 바디를 포함했으므로, 처리할 수 없을 때
  
• 200 OK (정상)
  UAS가 이해할 수 있는 메세지 바디를 포함했고, 처리할 때
  
• 487 Request Terminated
  SIP INFO 요청을 처리 중인 가운데 CANCEL 메쏘드를 받았을 때  

DTMF 전송의 개요
SIP INFO를 말하면서 DTMF 전송을 말하지 않고 넘어갈 수 없습니다. 이 부분은 Sunnyside81@naver.com 님의 "VoIP 상에서의 DTMF 전송 비교" 라는 글을 참조하여 작성하였습니다. 언젠가 제가 다운로드를 받아놓은 자료입니다. 언제나 다시 읽어도 좋은 자료입니다. 인터넷에서 찾아서 한 번 읽어보시면, DTMF에 대한 전체적인 이해에 도움이 되실 것입니다.

SIP를 통한 DTMF 전송방식은 Out of band와 In band 방식으로 구분됩니다.

• Out of band
  Signaling 메세지 및 Signaling Path를 사용 
  DTMF duration에 대한 정보가 없으므로 사용자가 Digit을 길게 또는 짧게 누르는 것을 표현할 수 없음
  SIP INFO 가 대표적
  
• In band
  RTP 메세지를 사용
  사용자가 Digit을 길게 또는 짧게 누르는 것을 표현할 수 있음
  Bypass 및 RFC 2833이 대표적
  

Out of band를 사용하는 INFO에 대해서는 위의 호 절차에서 설명하였습니다. Out of band의 경우 DTMF Duration을 전달할 수 없으므로, 사용자가 길게 Digit 버튼을 누를 때 발신자는 Tone을 누른 기간 만큼 듣지만, 수신자는 아무소리도 듣을 수 없습니다. 발신자가 Digit 버튼을 떼는 순간 Signaling을 통해 메세지가 전달되어 수신자가 Tone을 듣을 수 있습니다. 

In band의 Bypass 방식은 Digit을 RTP가 사용하는 코덱으로 압축해서 음성과 같이 보내는것입니다. 압축 코덱을 사용할 경우(g.711이 아닌 g.723, g.729 등) DTMF tone이 변형되거나 정보 손실이 발생할 가능성이 있습니다. 이러한 가능성이 상존하므로 잘 사용하지 않지만, 실제에서는 거의 정보 손실이 없었습니다. RFC 2833을 이용한 방식은 RTP 패킷에 DTMF의 번호와 볼륨, duration이 명시되어 전송되므로 정보 손실의 가능성이 적지만, UDP 기반에서 동작하므로 패킷이 분실될 수 있기에 하나의 digit을 여러 번 전송하여 정보 손실 가능성을 낮춥니다.

RFC 2976에서 보듯이 INFO의 Body에 Digit을 실어보낼 수 있다고 되었지만, 정확한 형식에 대한 규정은 없어 제조사별로 고유한 방식을 사용합니다. 따라서, 서로 다른 제조사의 장비를 연결할 경우 SIP INFO는 항상 문제를 일으킬 수 있습니다. 아래 두개의 SIP INFO 메세지를 보시면 최초에 설명한 Content-Type 헤더 부분의 정의가 모두 다름을 알 수 있습니다.

In-Band로 DTMF를 전송할 경우, Bypass와 RFC 2833 두가자 방법이 있다고 말씀드렸습니다. Bypass는 별도의 형식이나 정의가 필요없습니다. 아무런 정의가 없으면, Bypass로 전달합니다. RFC 2833은 메세지 바디에 다음과 같은 내용이 포함됩니다.

위의 m 필드를 보시면,Payload Type 4는 사용할 코덱에 대해서는 G723을, Payload Type 101은 Telephony-event를 정의합니다.  이 Payload Type 101을 이용하여 Digits을 전달합니다. RFC 2833은 같은 RTP 세션을 하지만, 서로 다른 Payload Type을 사용하여 구분합니다. Payload Type에 대해서는 "RTP 패킷 분석" 블로그를 참조하시기 바랍니다.

아래는 Bypass를 사용할 경우의 메세지 바디입니다.  일반적인 코덱 정보외에는 다른 협상정보가 없습니다. 따라서, 이럴 경우 Bypass를 사용하는 것입니다.

DTMF 전송 시의 에러
이러한 DTMF 전송은 IVR (Interactive Voice Response)과 같은 자동 응답 시스템에서 많이 사용됩니다. 일반적으로 IVR은 수신된 Digits을 재 확인하는 절차를 반드시 거치므로 전송간에 문제가 발생하더라도 사용자가 다시 Digits을 송출하도록 하여 문제를 제거하는 절차가 필요합니다.  

Out of band signal을 통해 DTMF 를 전달할 경우 Inband 로는 DTMF tone을 전송하지 말하야 하나 어떤 단말기는 사용자가 digit 버튼을 누르는 시점의 초기에 DTMF의 Inband tone을 보내기도 한다. 이것은 단말기가 DTMF 신호를 감지하면 해당 RTP를 제거해야 하는데 감지하는 속도가 떨어지면 초기의 DTMF tone이 RTP를 통해 나간 후에 제거가 시작되는 데서 발생하는 것이다. 이러한 경우 수신한 Gateway 에는 Inband로 들어온 DTMF tone도 전송하고 Outband로 들어온 시그날도 DTMF tone으로 변경하여 전송하므로 이 두 가지가 시차를 가지고 들어오는 경우 같은 digit를 두번 전송하는 결과를 초래합니다. 

마치며..
DTMF를 Out-of-band로 전송하는 것은 H.323, SIP, MGCP 프로토콜 별로 다양합니다. 여기에서는 SIP에 대해 이야기하므로, SIP 부분만을 정리하였습니다. 결국 SIP를 이용하여 이기종 장비간에 DTMF를 전송할 경우 이기종 장비간에는 RFC 2833 또는 Bypass가 현실적인 대안일 것입니다. 또한, RFC 2833에 대해서 여기에서 정리하는 것은 좀 무리가 있을 듯합니다. 언제 한 번 시간이 되면, RFC 2833에 대해 자세히 정리해 보도록 하겠습니다. "SIP의 이해"를 연재하면서, 다른 부가적인 얘기를 함께 꺼내야 한다는 것이 더 큰 부담입니다.

저번 글에서 이글을 두개의 글로 나눌려고 했던 가장 큰 이유는 DTMF 때문이였습니다. 그러나, SIP에 대해 이야기 하는 데 너무 밖으로 세기만해서는 이 연재를 마치기 어렵다는 생각과 이글을 읽으시는 분들이 기본적인 지식은 있다고 믿기에 SIP 위주로 전개하기로 결정하였습니다. 또한, RFC 2833 을 처음 듣는 분들을 위해 "SIP의 이해" 연재가 마무리 되면, 한 번 정리할 기회를 갖도록 하겠습니다.

다음 장에서는 UPDATE 메쏘드에 대해 살펴보겠습니다.

-------------------------
라인하트 (CCIEV #18487)
linecard@naver.com