SIP INFO

Overview

원문은 이곳<ref>http://www.nexpert.net/148</ref>에서 확인할 수 있다.

SIP 세션이 설립된 후 기존의 세션을 유지하면서 필요한 정보를 교환하려면 어떻게 해야할까? 기존의 메소드는 세션 설립/종료에 관한 것이었다. 200 OK 이후부터 BYE 이전까지 기존의 세션 내에서 UAC와 UAS 간에 정보 교환을 할 수 있는 방법이 없다.

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

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

위와 같은 변경을 하기 위해서는 UPDATE나 re-INVITE를 통해 가능하다. 단순히 세션 완료 전에는 UPDATE 를 세션 완료 후에는 re-INVITE를 이용한다. 물론, UPDATE는 세션 완료 후에도 사용되지만, 추천하지 않는다. 단지 세션과 관련된 미디어 속성을 변경하거나 세션 타이머를 업데이트할 때는 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를 전송한다고 가정해보자.

INFO sip:Alice's_Bank@192.168.10.20 SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776asegma
Max-Forwards: 70
To: Bank <sip:Bank@Bank_URI.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 22756 INFO
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: text/plain
Content-Length: 16

3 1 8 1 9 6 2

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

• 481 Call leg / Transaction Deesnot Exist

만일 INFO 요청을 받은 UAS가 기존의 Call leg와 매치가 되지 않을 때

• 415 Unsupported Media Type

UAS가 이해할 수 없는 메시지 바디를 포함했으므로, 처리할 수 없을 때

• 200 OK (정상)

UAS가 이해할 수 있는 메시지 바디를 포함했고, 처리할 때

• 487 Request Terminated

SIP INFO 요청을 처리 중인 가운데 CANCEL 메소드를 받았을 때

DTMF 전송의 개요

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

• Out of band

Signaling Message 및 Signaling Path 를 사용.

DTMF duration에 대한 정보가 없으므로 사용자가 Digit를 길게 또는 짧게 누르는 것을 표현할 수 없음.

SIP INFO 가 대표적

• In band

RTP 메시지를 사용.

사용자가 Digit를 길게 또는 짧게 누르는 것을 표현할 수 있음.

Bypass 및 RFC 2833 이 대표적

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 는 항상 문제를 일으킬 수 있다.

In-Band 로 DTMF 를 전송할 경우, Bypass 와 RFC2833 두가지 방법이 있다. Bypass는 별도의 형식이나 정의가 필요없다. 아무런 정의가 없으면, Bypass로 전달한다. RFC 2833은 메시지 바디에 다음과 같은 내용이 포함되게 된다.

v=0
o=- 2100438784 2100438784 IN IP4 10.132.0.14
s=MB 1.0
c=IN IP4 10.132.0.14
t=0 0
m=audio 19498 RTP/AVP 8 0 98 109 107 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:98 AMR/8000
a=rtpmap:109 AMR-WB/16000
a=rtpmap:107 opus/48000/2
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:20
a=sendrecv

위의 m 필드를 보면, Payload Type 4 는 사용할 코덱에 대해서는 alaw, ulaw, AMR, AMR-WB, opus 를 사용하고, Playload Type 101 은 Telephony-event 를 정의한다. 이 Payload Type 101 을 이용하여 Digits 를 전달한다. RFC 2833은 같은 RTP 세션을 사용하지만, 서로 다른 Payload Type 을 사용하여 구분한다.

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

v=0
o=- 2100438784 2100438784 IN IP4 10.132.0.14
s=MB 1.0
c=IN IP4 10.132.0.14
t=0 0
m=audio 19498 RTP/AVP 8 0 98 109 107
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:98 AMR/8000
a=rtpmap:109 AMR-WB/16000
a=rtpmap:107 opus/48000/2

DTMF 전송 시의 에러

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

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를 두번 전송하는 결과를 초래한다.

ETC

DTMF 를 Out-of-band 로 전송하는 것은 H.323, SIP, MGCP 프로토콜 별로 다양하다. 여기에서는 SIP 에 대해 이야기하므로, SIP 부분만을 정리하였다. 결국 SIP 를 이용하여 이기종 장비간에 DTMF를 전송할 경우 이기종 장비간에는 RFC 2833 또는 Bypass가 현실적인 대안일 것이다.

References

<references />