22장. SIP INFO와 DTMF
1. SIP INFO의 이해
SIP 세션과 관련된 SIP 메쏘드는 다음과 같이 나눕니다.
SIP 세션 설립을 위한 메쏘드 : INVITE / 200 OK / ACK
SIP 세션 종료를 위한 메쏘드 : BYE
SIP 세션 변경을 위한 메쏘드 : UPDATE / re-INVITE
UA가 설립된 SIP 세션에 대한 정보를 요청할 필요가 있습니다. SIP OPTIONS 메쏘드는 SIP 세션이 아니라 UA에 대한 Capability 정보를 요청하는 것이므로 적절하지가 않습니다. 새로운 SIP 메쏘드가 필요합니다. SIP INFO는 RFC 2976 The SIP INFO Method에서 정의하고, 설립된 SIP 세션에 대한 정보 요청과 애플리케이션 레벨의 단순 정보 전송에 사용합니다. SIP INFO가 전송하는 정보는 다음과 같습니다.
PSTN 게이트웨이 간에 PSTN Signaling 메시지 전송
DTMF Digits(숫자) 전송
무선 모빌리티 애플리케이션 지원을 위한 무선 신호의 세기 전송
은행 계좌 잔액을 조회하는 정보
통화자 간에 이미지나 텍스트와 같은 비스트리밍 정보를 전송
2. SIP INFO 메시지 분석
SIP INFO는 전송할 정보는 SIP INFO의 헤더가 아닌 SIP 메시지 바디를 사용합니다. SIP INFO는 은행의 자동응답 시스템(ARS, Automatic Response System)과 연결하여 계좌번호나 비밀번호 등을 전달합니다.
<그림 22-1> SIP INFO 앨리스는 은행 ARS 시스템에 접속하여 요청받은 비밀번호를 전화기 키패드에서 숫자(Digits)를 눌러서 전달합니다. 실제는 다수의 SIP INFO와 200 OK로 구성됩니다.
1) 앨리스의 'INFO'
앨리스는 은행 ARS 자동응답 시스템에 접속한 후에 요청받은 정보를 전달합니다.
INFO sip:ARS@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
은행은 기존 Call-ID와 동일한 SIP INFO를 수신합니다. Content-Type을 text/plain으로 하여 3181962 번호를 전달합니다.
2) 응답
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 메쏘드를 받음
3. SIP INFO에서 Content-Type의 문제
RFC 2976에서 SIP INFO의 메시지 바디에 Digit을 실어 보내도록 되어 있지만, Content-Type에 대한 정확한 형식을 규정하지 않아 제조사별로 구현 방식이 다릅니다. 서로 다른 제조사의 장비 간의 DTMF 테스트 중일 때는 Contents-type을 동일하게 명기하는 지를 확인할 필요가 있습니다. DTMF를 위한 SIP INFO의 Content-Type 헤더 값이 다를 수 있습니다.
Contents-type; audio/telephone-event
Contents-type; application/vnd.networks.digits
Content-Type: text/plain
4. DTMF의 이해
DTMF는 Dual Tone Multi Frequency의 약어로 2 개의 주파수 성분을 갖는 신호를 의미합니다. DTMF는 전송할 숫자를 2 개의 주파수로 변환하므로 1개의 주파수를 사용하는 Pulse 보다 안정적입니다. 전화기의 키패드의 숫자를 누를 때마다 들리는 삐 소리가 주파수의 소리입니다. ARS 자동응답 시스템은 주파수를 듣고 숫자로 변환합니다. 즉, DTMF는 전화기가 전송하는 숫자(Digits)를 상대측 장비가 정확히 수신하도록 합니다. DTMF 전달 방식은 크게 두 가지로 두 가지로 나뉩니다.
1) Out of band 방식
Out of band 방식은 시그널링 경로로 DTMF 신호를 전달합니다. 전화기나 게이트웨이가 음성을 전달하는 미디어(RTP) 채널로 DTMF 신호음을 전달하지 않고 숫자로 변환하여 시그널링 채널로 전달합니다. H.323 네트워크에서는 H.245 채널을 이용하고 SIP 네트워크에서는 SIP INFO를 이용합니다.
Out of band 방식은 DTMF Duration에 대한 정보를 표현할 수 없으므로 숫자(Digit)를 길게 또는 짧게 누르는 것을 표현하지 못합니다. DTMF를 전달하려는 발신자 숫자를 누른 시간만큼 삐 소리를 듣지만, 수신자는 발신자가 Digit 버튼에서 손가락을 떼는 순간 시그널링 경로로 메시지만 전달되어 짧은 삐 소리만 듣습니다.
SIP INFO는 Out of band 방식으로 SIP 시그널링으로 전달되므로 안정적이고 잡음에 영향을 받지 않습니다.
2) In band 방식
In band 방식은 음성이 전달되는 Media 경로로 DTMF 신호를 전달합니다. 전화기나 게이트웨이가 음성을 전달하는 미디어(RTP) 채널에 DTMF 주파수를 그대로 전달하므로 DTMF Duration 까지도 전달합니다.
In band 방식은 시그널링과 상관없이 RTP를 사용하는 모든 프로토콜에서 사용되고, Bypass와 RFC 2833 방식으로 나뉩니다.
Bypass 방식
Bypass 방식은 숫자(Digit)를 RTP가 사용하는 압축코덱으로 음성과 같이 보냅니다. 별도의 형식이나 협상이 필요 없이 IP 전화기나 게이트웨이가 숫자에 맞는 주파수를 생성하여 음성 채널로 그대로 전달합니다. G.711이 아닌 G.729나 G.723과 같이 압축률이 높은 코덱을 사용할 경우 DTMF 톤이 변형되거가 정보가 손실될 가능성이 있습니다.
RFC 2833 방식
RFC 2833 방식은 음성과 같은 미디어 세션의 RTP 패킷에 DTMF의 번호와 볼륨, 시간(duration)을 명시하여 전송합니다. Out of Band의 단점인 주파수의 세기와 시간까지 전달하는 장점이 있습니다. RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals 권고안으로 정의합니다.
5. In band 방식의 SDP 협상
Bypass와 RFC 2833 방식은 RTP 채널로 DTMF를 전달합니다. SDP Offer / Answer 모델에서 진행되는 DTMF 협상을 살펴봅니다.
1) Bypass 방식의 SDP 협상
별도의 DTMF 협상 없이 음성 코덱만을 제안합니다. 전화기나 게이트웨이는 DTMF를 기존 설립된 RTP 채널로 음성과 함께 전달합니다.
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
2) RFC 2833 방식의 SDP 협상
RFC 2833 DTMF 협상을 위해 페이로드 타입 (Payload Type) 101을 협상합니다.
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
6. RFC 2833 DTMF의 정보 손실 방지 방안
RFC 2833 방식이 사용하는 RTP 채널은 UDP로 전달되므로 수신 측으로부터 수신 확인에 대한 응답을 받지 못합니다. RFC 2833은 DTMF 패킷 분실에 대한 위험을 분산하기 위해 하나의 숫자(digit)를 여러 번 전송힙니다. SIP 단말들은 RFC 2833 방식의 DTMF 방식 선택 시 몇 개의 패킷을 보낼지를 설정합니다. 같은 In Band 방식의 Bypass 방식은 패킷 분실에 대한 대응 방안이 없습니다.
<그림 22-2> RFC 2833 패킷캡쳐DTMF 전송 방식은 항상 장애나 분실에 대비하여 애플리케이션 레벨의 전송 확인하는 절차를 둡니다. IVR (Interactive Voice Response)이나 ARS 자동 응답 시스템은 수신된 숫자들(Digits)이 정확한지를 애플리케이션 레벨에서 확인하기 위해 재확인 멘트를 재생합니다. 예를 들어, "지금 전송한 회원번호가 XXXX이면 1번, 아니면 2번을 눌러 주세요"가 대표적입니다.
7. 흔한 DTMF 관련 장애
DTMF 전송에서 Out of band를 사용할 경우 DTMF가 두 번 중복으로 인식되는 경우가 있습니다. In band방식은 사용자가 digit 버튼을 누르는 시점에 DTMF 톤을 보내지만, Out of band 방식은 사용자가 digit 버튼을 떼는 순간 보내기 때문입니다. 수신 단말이 Out of Band로 들어온 DTMF 신호를 감지하면 RTP 채널에 있는 DTMF 신호를 제거해야 하는데 감지하는 속도가 떨어지면 초기의 DTMF 톤이 RTP를 통해 나간 후에 제거가 시작되기 시작합니다. 이런 경우에 DTMF를 수신하는 장비가 In band로 들어온 DTMF와 Outband로 들어온 DTMF를 각각 인식합니다. 따라서, 시차를 두고 전송되는 DTMF로 인해 사용자가 같은 숫자를 두 번 누른 것과 같은 현상이 발생할 수 있습니다.
전화기나 게이트웨이가 이런 문제를 일으킨다면 버그일 확률이 높습니다. VoIP 초장기와 달리 DTMF 전송 문제는 많이 개선된 편이지만 지금도 심심치 않게 발생합니다. DTMF 전송은 망 환경에 따라 차이가 많으므로 In band와 out of band를 모두 테스트하여 가장 최적인 방법을 이용합니다.
'엔지니어를 위한 인터넷 전화와 SIP의 이해'를 책으로 만들다
https://brunch.co.kr/@linecard/188
