SIP INFO: Difference between revisions

From 탱이의 잡동사니
Jump to navigation Jump to search
(Created page with "== Overview == 원문은 이곳<ref>http://www.nexpert.net/148</ref>에서 확인할 수 있다. SIP 세션이 설립된 후 기존의 세션을 유지하면서 필요한 정...")
 
No edit summary
 
(10 intermediate revisions by the same user not shown)
Line 9: Line 9:
* 초기 설정된 세션 파라미터의 변경
* 초기 설정된 세션 파라미터의 변경


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


SIP INFO가 전송하는 주요 정보는 RFC 2976 The SIP INFO Method 에 다음과 같다고 명시한다.
SIP INFO가 전송하는 주요 정보는 RFC 2976 The SIP INFO Method 에 다음과 같다고 명시한다.
Line 52: Line 52:
: SIP INFO 요청을 처리 중인 가운데 CANCEL 메소드를 받았을 때
: SIP INFO 요청을 처리 중인 가운데 CANCEL 메소드를 받았을 때


== DTMF 전송의 개요 ==
RFC 2976 에서 SIP INFO 메시지 바디에 Digit 실어 보낼 수 있다고 되었지만, Content-Type 에 대한 정확한 형식을 규정하지 않아 제조사 별로 다른 방식을 사용한다. 이기종 장비간의 상호 연동에 문제를 일으킬 있으므로 Contents-type 을 UAC 와 UAS 간에 동일하게 사용하는지를 확인해야 한다. DTMF를 위한 SIP INFO 헤더의 Content-Type 헤더 부분에 대한 정의는 아래와 같이 제조사별로 다르게 사용한다.
SIP 를 통한 DTMF 전송방식은 Out of band 와 In band 방식으로 구분된다.
<pre>
 
“Contents-type; audio/telephone-event”
* Out of band
“Contents-type; application/vnd.networks.digits”
: Signaling Message 및 Signaling Path 를 사용.
“Content-Type: text/plain”
: DTMF duration에 대한 정보가 없으므로 사용자가 Digit를 길게 또는 짧게 누르는 것을 표현할 없음.
</pre>
: 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을 실어보낼 수 있다고 되었지만, 정확한 형식에 대한 규정은 없어 제조사별로 고유한 방식을 사용한다. 따라서, 서로


== References ==
== References ==
<references />
<references />
[[category:SIP protocol]]

Latest revision as of 13:45, 3 February 2020

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 를 사용하는 절차는 다음과 같다.

Sip info dialog.png

세션이 설립 후 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 메소드를 받았을 때

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”

References

<references />