Chapter 6. SIP Method
9. REFER Method의 이해
REFER 메쏘드는 RFC 3261 SIP 및 RFC 3515 The SIP Refer Method 에 정의되었으며, UA가 REFEER 메쏘드에 의해 제공되는 자원 (Resources)를 참조 하도록 합니다. 즉, REFEER 메쏘드의 “Refer-To” 헤더 정보에 포함된 자원을 활용하기 위해 UA가 제 3의 UA로 INVITE를 발행하게 합니다. REFEER 메쏘드는 Call Transfer (호전환)과 삼자통화 같은 서비스에서 주로 활용됩니다.
UA가 새로운 INVITE 요청을 발송할 수 있도록 “Refer-To”헤더는 정확한 목적지 주소가 명기되어야 하며, 응답은 반드시 “202 Accepted”로 합니다. Refer-To 헤더는 다음과 같은 다양한 형식의 URI를 사용하도록 명시하여 다양하게 응용될 수 있도록 하였습니다.
- Refer-To: sip:alice@atlanta.example.com
- Refer-To: <sip:bob@biloxi.example.net?Accept-Contact=sip:bobsdesk.
biloxi.example.net&Call-ID%3D55432%40alicepc.atlanta.example.com> - Refer-To: <sip:dave@denver.example.org?Replaces=12345%40192.168.118.3%3B
to-tag%3D12345%3Bfrom-tag%3D5FFE-3994> - Refer-To: <sip:carol@cleveland.example.org;method=SUBSCRIBE>
- Refer-To: http://www.ietf.org
REFEER를 수신한 UA는 실행 여부 및 결과를 NOTIFY 메쏘드를 이용해 통보합니다. NOFITY의 메세지 바디에는 REFER 메세지에 의해 요청된 이벤트 상태를 나타냅니다.
- SIP/2.0 100 Trying
현재 REFER에 의해 요청된 이벤트가 처리중임 - SIP/2.0 200 OK
현재 REFER에 의해 요청된 이벤트가 성공적으로 처리되었음 - SIP/2.0 503 Service Unavailable
현재 REFER에 의해 요청된 이벤트가 실패했음 - SIP/2.0 603 Declined
현재 REFER에 의해 요청된 이벤트를 수신했지만, 거절되었음
10. RFC 3515의 REFER 예제
Refer의 동작을 이해하기 위해 RFC 3515의 REFER Call Flow를 바탕으로 설명드리겠습니다.
- REFER (Refer-to: Server)
통화중에 Agent A는 Agent B에게 특정 URI에 액세스하도록 Refer 메쏘드를 보냅니다.
REFER sip:b@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK2293940223
To: <sip:b@atlanta.example.com>
From: <sip:a@atlanta.example.com>;tag=193402342
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 93809823 REFER
Max-Forwards: 70
Refer-To: (whatever URI)
Contact: sip:a@atlanta.example.com
Content-Length: 0
- 202 Accepted
Agent B는 REFER 메쏘드를 정확히 수신했으므로 202 Accepted로 응답합니다
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK2293940223
To: <sip:b@atlanta.example.com>;tag=4992881234
From: <sip:a@atlanta.example.com>;tag=193402342
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 93809823 REFER
Contact: sip:b@atlanta.example.com
Content-Length: 0
- NOTIFY
Agent B는 서버와의 통신 결과를 NOFITY 메쏘드로 Agent A에게 통보합니다. 메세지 바디의 SIP/2.0 100 Trying 은 현재 Refer에 의해 요청된 사항을 처리중임을 나타냅니다. NOTIFY 메쏘드에 새롭게 추가된 "Subsription-State" 헤더는 서버의 상태를 명시합니다.
NOTIFY sip:a@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9922ef992-25
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993402 NOTIFY
Max-Forwards: 70
Event: refer
Subscription-State: active;expires=(depends on Refer-To URI)
Contact: sip:b@atlanta.example.com
Content-Type: message/sipfrag;version=2.0
Content-Length: 20
SIP/2.0 100 Trying
- 200 OK
SIP/2.0 200 OK
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9922ef992-25
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993402 NOTIFY
Contact: sip:a@atlanta.example.com
Content-Length: 0
"Subscription-State" 헤더는 상대측이 이벤트 처리중일때는 active로 표시하지만, 이벤트 처리가 완료되면 Subscription-State:terminatd;reason=noresource로 명기합니다.
11. REFEER 메쏘드의 활용 - 호전환 (Call Transfer)
REFEER를 가장 많이 활용하는 부가 서비스는 호전환입니다. 호 전환 서비스를 구현하는 방식에 따라 Blind Transfer 와 Consultative Transfer로 나뉩니다. 각 구현 방식별로 Call Flow를 살펴보겠습니다.
- Blind Transfer
앨리스와 통화중이던 밥은 “Transfer” 버튼을 누르면, 밥의 전화기는 앨리스의 전화기로 re-INVITE를 전송하여 호 보류(Call Hold)를 시키면서 호전환 시킬 대상의 전화번호 수집을 위해 대기합니다. 밥이 캐롤의 전화번호를 누르면 밥의 전화기는 캐롤의 전화기로 호를 전환시키라는 REFEER 메세지를 앨리스의 전화기로 전달되면서 앨리스의 전화기와 캐롤의 전화기는 INVITE/200 OK/ACK를 주고 받으면서 통화를 시작합니다. REFEER를 수신했던 앨리스의 전화기는 캐롤의 전화기와의 호 상태를 NOTIFY로 밥에게 통지하면서 기존 밥과의 호를 종단합니다.
이 과정에서 캐롤은 앨리스의 통화가 밥을 통해서 호전환된 것인지 앨리스가 직접 전화를 건 것인지를 인지하지 못합니다. 물론, 캐롤의 전화기 액정에는 밥에 의해 호전환된 호임을 표시합니다. 밥과 캐롤이 별도의 통화채널을 구성하지 않았기 때문에 이런 표현을 사용하였으며, 이를 Blind Transfer라 합니다.
- Consultative Transfer
Blind Transfer와 동일하게 밥이 앨리스와 통화 중 “Transfer” 버튼을 누른 후 캐롤의 전화번호를 누릅니다. 밥은 캐롤과 먼저 통화 채널을 구성하여 캐롤에게 앨리스의 전화가 왔음을 알려줍니다. Consultative Transfer는 밥이 캐롤과 통화채널의 구성한 후에 앨리스가 캐롤과 통화하도록 호전환을 하는 것입니다.
마치며
REFEER 메쏘드를 이해하는 것에 초점을 맞추어 지난 "SIP의 이해"에서 다룬 REFEER를 이용한 삼자통화 부분은 제외하였습니다.
"다시쓰는 SIP의 이해" 연재는 올 초에 마무리하려고 했던 글인데 개인적인 사정으로 인해 많이 지체되었습니다. 이번 달 안으로 마무리하고 CUCM Features Deepdive에 대한 글을 다시 정리해 보겠습니다.
"다시쓰는 SIP의 이해" 연재의 다른 글
2015/07/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 22편 Chapter 8. RTP의 이해
2015/07/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 21편 Chapter 7. 가끔 보는 SIP Method
2015/07/08 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 20편 Chapter 7. 가끔 보는 SIP Method
2015/05/20 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 19편 Chapter 7. 가끔 보는 SIP Method
2015/05/18 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 18편 Chapter 7. 가끔 보는 SIP Method
2015/05/07 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 17편 Chapter 6. SIP Method
2015/02/26 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 16편 Chapter 6. SIP Method
2015/02/23 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 15편 Chapter 6. SIP Method
2015/02/11 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 14편 Chapter 6. SIP Method
2015/01/30 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 13편 Chaper 5.SDP
2015/01/29 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 12편 Chapter 5. SDP
2015/01/05 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 11편 Chapter 5. SDP
2014/12/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 10편 Chapter 4. SIP Response
2014/12/04 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 9편 Chapter 3. SIP Method on RFC 3261
2014/12/03 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 8편 Chapter 3. SIP Method on RFC 3261
2014/12/02 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 7편 Chapter 3. SIP Method on RFC 3261
2014/11/26 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 6편 Chapter 2. SIP Overview
2014/11/21 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 5편 Chapter 2. SIP Overview
2014/11/19 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 4편 Chapter 1. VoIP의 이해 (3)
2014/11/11 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 3편 Chapter 1. VoIP의 이해 (2)
2014/11/05 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 2편 Chapter 1. VoIP의 이해 (1)
라인하트 유씨누스 (CCIEV #18487) --------------------------------------
ucwana@gmail.com (라인하트의 구글 이메일)
http://twitter.com/nexpertnet (넥스퍼트 블로그의 트위터, 최신 업데이트 정보 및 공지 사항)
http://groups.google.com/group/cciev (시스코 UC를 공부하는 사람들이 모인 구글 구룹스)
http://groups.google.com/group/ucforum (UC를 공부하는 사람들이 모인 구글 구룹스)
세상을 이롭게 하는 기술을 지향합니다. ______________________________________________
