SIP INFO: Difference between revisions
(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를 이용한다. 물론, | 위와 같은 변경을 하기 위해서는 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 메소드를 받았을 때 | ||
RFC 2976 에서 SIP INFO 메시지 바디에 Digit 를 실어 보낼 수 있다고 되었지만, Content-Type 에 대한 정확한 형식을 규정하지 않아 제조사 별로 다른 방식을 사용한다. 이기종 장비간의 상호 연동에 문제를 일으킬 수 있으므로 Contents-type 을 UAC 와 UAS 간에 동일하게 사용하는지를 확인해야 한다. DTMF를 위한 SIP INFO 헤더의 Content-Type 헤더 부분에 대한 정의는 아래와 같이 제조사별로 다르게 사용한다. | |||
SIP 를 | <pre> | ||
“Contents-type; audio/telephone-event” | |||
“Contents-type; application/vnd.networks.digits” | |||
“Content-Type: text/plain” | |||
</pre> | |||
: | |||
== 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 를 사용하는 절차는 다음과 같다.
세션이 설립 후 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 />