IMS에서 착신전환 설정은 SIP 통화 중간에 갑자기 생기는 값이 아닙니다. 사용자가 단말 메뉴에서 “항상 착신전환”, “통화 중 전환”, “무응답 전환”을 누르는 순간, 그 설정은 보통 XCAP를 통해 네트워크의 서비스 데이터로 저장됩니다. 실제 통화가 들어올 때는 S-CSCF와 TAS/AS가 그 값을 읽고, 통화를 받을지 다른 번호로 돌릴지 판단합니다.
핵심 요약
- XCAP는 IMS Supplementary Service 설정을 XML 문서로 조회·생성·수정·삭제하기 위한 HTTP 기반 프로토콜입니다.
- Call Diversion(CDIV)은 착신 통화를 다른 번호, 음성사서함, 또는 특정 서비스 대상으로 우회시키는 IMS 보조 서비스입니다.
- 사용자 단말은 보통 Ut 인터페이스를 통해 XCAP Server 또는 XDMS에 착신전환 설정을 저장합니다.
- 실제 착신 통화에서는 S-CSCF가 초기 필터 기준에 따라 TAS/AS를 호출하고, TAS/AS가 저장된 CDIV 규칙을 보고 전환 여부를 결정합니다.
- 로그 분석에서는 SIP REGISTER보다도 XCAP HTTP 요청/응답, XML rule, SIP INVITE의 diversion 처리, TAS 응답을 함께 봐야 원인을 빨리 좁힐 수 있습니다.
1. 왜 XCAP가 필요한가
VoLTE나 IMS 기반 음성 서비스를 볼 때 처음에는 SIP 메시지만 눈에 들어옵니다. REGISTER가 됐는지, INVITE가 나갔는지, 180 Ringing이 왔는지 같은 흐름이 가장 잘 보이기 때문입니다. 그런데 착신전환 문제를 분석하다 보면 SIP만으로는 설명이 안 되는 경우가 많습니다.
예를 들어 사용자는 단말에서 “무응답 시 010-xxxx-xxxx로 전환”을 켜 두었습니다. 이후 누군가 전화를 걸었고, 단말이 일정 시간 응답하지 않자 통화가 다른 번호로 넘어갑니다. 이때 전환 조건과 전환 대상 번호는 INVITE 안에서 갑자기 만들어지는 것이 아니라, 사전에 네트워크에 저장된 서비스 설정을 기반으로 적용됩니다.
이 설정을 다루는 대표적인 방식이 XCAP over Ut입니다. 쉽게 말하면, 사용자의 통화 서비스 설정을 XML 문서처럼 저장해 두고, 단말이나 클라이언트가 HTTP 방식으로 그 문서를 읽고 고치는 구조입니다.
XCAP Server가 직접 통화를 전환시키는 장비라고 생각하면 흐름이 꼬입니다. XCAP는 설정을 저장하고 조작하는 쪽이고, 실제 착신 통화에서 전환 판단을 수행하는 쪽은 보통 TAS/AS입니다.
2. IMS Call Diversion 전체 구조
Call Diversion은 단말 메뉴에서는 단순한 ON/OFF 기능처럼 보입니다. 하지만 IMS 내부에서는 설정 저장 경로와 통화 처리 경로가 나뉩니다. 이 둘을 구분해야 장애 분석이 쉬워집니다.
| 구분 | 역할 | 분석할 때 보는 지점 |
|---|---|---|
| UE | 착신전환 설정을 켜거나 끄고, 전환 대상 번호를 입력합니다. | 단말 UI, IMS 설정 메뉴, XCAP 요청 발생 여부 |
| Ut Interface | UE와 XCAP Server 사이에서 supplementary service 설정을 조작합니다. | HTTP method, Request-URI, 인증, 응답 코드 |
| XCAP Server / XDMS | 사용자별 서비스 XML 문서를 저장하고 수정합니다. | simservs 문서, rule 조건, target URI |
| S-CSCF | 착신 SIP INVITE를 초기 필터 기준에 따라 TAS/AS로 전달합니다. | iFC trigger, ISC routing, Route header |
| TAS / AS | CDIV 규칙을 적용해 착신 유지, 전환, 거절 등을 판단합니다. | 서비스 로직, diverted target, SIP 응답/재발신 |
3. XCAP와 Ut 인터페이스 동작 방식
XCAP는 특별한 마법 같은 프로토콜이라기보다, XML 문서를 HTTP로 다루기 위한 규칙에 가깝습니다. 클라이언트는 특정 URI에 대해 GET, PUT, DELETE 같은 HTTP method를 사용하고, 서버는 XML 문서 또는 응답 코드를 돌려줍니다.
IMS Supplementary Service에서는 이 구조를 이용해 사용자의 서비스 설정을 조작합니다. Call Diversion의 경우 “무슨 조건에서”, “어디로”, “활성화되어 있는지” 같은 값이 XML rule 형태로 저장됩니다.
자주 보이는 HTTP Method
| Method | 의미 | Call Diversion에서의 예 |
|---|---|---|
GET |
현재 저장된 서비스 설정을 조회합니다. | 착신전환이 켜져 있는지, 전환 대상 번호가 무엇인지 확인 |
PUT |
서비스 설정 문서 또는 특정 노드를 생성·수정합니다. | 무응답 전환 번호를 새로 저장하거나 활성화 상태 변경 |
DELETE |
특정 설정 또는 XML 노드를 삭제합니다. | 착신전환 rule 제거 |
여기서 중요한 점은 응답 코드입니다. 단말 UI에서는 “설정 실패” 한 줄만 보이지만, 실제로는 401, 403, 404, 409, 412, 500처럼 원인이 꽤 다르게 나타납니다. 인증 실패인지, 권한 문제인지, XML 문법 문제인지, 서버 내부 오류인지에 따라 확인 방향이 완전히 달라집니다.
4. Call Diversion 조건을 어떻게 이해하면 좋을까
Call Diversion을 한글로 옮기면 보통 착신전환입니다. 다만 실제 IMS 서비스에서는 단순히 “무조건 다른 번호로 넘긴다”보다 훨씬 많은 조건이 있습니다. 통화 중일 때만 넘길 수도 있고, 단말이 등록되어 있지 않을 때 넘길 수도 있으며, 응답이 없을 때 일정 시간 뒤에 넘길 수도 있습니다.
| 구분 | 사용자 관점 | 네트워크 관점 | 로그에서 보는 힌트 |
|---|---|---|---|
| CFU | 항상 착신전환 | 착신 시 조건 없이 target으로 전환 | Called UE 상태와 무관하게 바로 diversion 판단 |
| CFB | 통화 중 착신전환 | busy 조건에서 전환 | 486 Busy Here, busy 상태 판단, TAS 로직 확인 |
| CFNRy | 무응답 착신전환 | 타이머 만료 또는 no-reply 조건에서 전환 | 180/183 이후 일정 시간 경과, no-reply timer |
| CFNRc | 미등록/도달 불가 시 전환 | UE not reachable, not registered 조건에서 전환 | registration state, paging 실패, HSS/UDM 상태 |
| Selective CDIV | 특정 번호만 전환 | caller identity, time, media 조건 등과 조합 가능 | rule condition, identity matching, anonymous 처리 |
운영망에서 장애를 보면 “착신전환이 안 된다”는 말 안에 여러 케이스가 섞여 있습니다. 설정 자체가 저장되지 않은 경우, 설정은 저장됐지만 TAS가 읽지 못하는 경우, TAS는 읽었지만 조건이 맞지 않는 경우, 전환 대상 번호로 재호출이 실패하는 경우가 모두 다른 문제입니다.
5. 착신 통화에서 Call Diversion이 적용되는 흐름
이제 실제 통화 흐름을 따라가 보겠습니다. 단말이 이미 XCAP로 착신전환 설정을 저장해 둔 상태라고 가정합니다. 이후 발신자가 전화를 걸면 S-CSCF는 착신 사용자의 서비스 프로파일에 따라 TAS/AS를 호출합니다. TAS/AS는 저장된 CDIV 설정을 확인하고, 조건이 맞으면 원래 착신자 대신 전환 대상 번호로 통화를 넘깁니다.
- 사용자가 단말에서 착신전환을 설정합니다.
UE는 XCAP Client처럼 동작해 Ut 인터페이스로 XML 설정을 저장합니다. - XCAP Server는 사용자 서비스 문서를 갱신합니다.
전환 조건, 활성화 여부, target URI 같은 값이 저장됩니다. - 발신자가 착신 사용자에게 SIP INVITE를 보냅니다.
IMS Core는 착신 사용자의 S-CSCF까지 INVITE를 라우팅합니다. - S-CSCF는 iFC에 따라 TAS/AS를 트리거합니다.
CDIV 서비스가 필요한 세션이면 TAS/AS가 통화 처리 경로에 들어옵니다. - TAS/AS는 CDIV rule을 확인합니다.
무조건 전환, busy, no-reply, not reachable 같은 조건을 현재 세션 상태와 비교합니다. - 조건이 맞으면 전환 대상 번호로 세션을 진행합니다.
SIP 3xx 계열 응답을 쓰는 구현도 있고, AS가 B2BUA처럼 새 INVITE를 생성하는 구현도 있습니다. - 전환 후 통화가 성립되면 과금·표시·이력 정보가 함께 처리됩니다.
Diversion 관련 header, History-Info, P-Asserted-Identity, privacy 처리 등을 함께 확인해야 합니다.
SIP 메시지만 보고 판단하면 놓치는 부분
Call Diversion은 통화 시점의 SIP 메시지와 사전 설정된 XCAP 데이터가 만나야 동작합니다. 그래서 SIP INVITE만 보면 “왜 갑자기 다른 번호로 갔지?”처럼 보일 수 있습니다. 반대로 XCAP 설정만 보면 “분명 설정은 저장됐는데 왜 실제 통화에서 적용이 안 되지?”라는 상황이 생깁니다.
실무에서는 두 흐름을 같이 봐야 합니다. 설정 변경 시점의 XCAP 로그와 통화 발생 시점의 SIP 로그를 시간축으로 나란히 놓으면 원인이 빨리 보입니다.
6. 로그 분석 시 확인 포인트
장애 티켓에서 “착신전환이 안 됩니다”라는 문장을 받으면 먼저 문제를 둘로 나누는 것이 좋습니다. 설정이 안 되는 문제인지, 설정은 되지만 통화 때 적용이 안 되는 문제인지입니다. 이 구분만 해도 확인 범위가 절반으로 줄어듭니다.
| 증상 | 우선 확인할 로그 | 가능한 원인 |
|---|---|---|
| 단말에서 착신전환 설정 실패 | XCAP HTTP 요청/응답 | 인증 실패, Ut 접속 불가, XML 문법 오류, 권한 부족 |
| 설정은 성공했는데 조회하면 값이 없음 | GET/PUT URI, ETag, document selector | 다른 문서 경로에 저장, 조건 노드 누락, 서버 동기화 지연 |
| 통화 중 전환만 안 됨 | SIP busy 처리, TAS service log | busy 조건 미충족, 단말 응답 코드 차이, AS rule mismatch |
| 무응답 전환 시간이 이상함 | no-reply timer, 180/183 이후 시간 | 타이머 설정 불일치, 단말 ringing 처리 차이, 사업자 정책 |
| 전환 대상 번호로 연결 실패 | AS가 생성한 INVITE, number normalization | 번호 포맷 오류, barring, 라우팅 실패, 과금/권한 제한 |
| 로밍 또는 VoWiFi에서만 실패 | IMS APN/PDN, P-CSCF, Ut routing | Ut 접근 경로 차이, DNS/프록시 문제, 인증 정책 차이 |
HTTP 응답 코드 해석 팁
XCAP 장애는 HTTP 응답 코드만 잘 봐도 방향이 잡힙니다. 401은 인증 흐름, 403은 권한이나 서비스 가입 상태, 404는 URI 또는 문서 경로, 409는 XML 문서 충돌이나 제약 조건, 412는 ETag/If-Match 계열 조건 실패를 먼저 의심할 수 있습니다.
예시 관찰 순서
1) UE가 XCAP Server 주소를 제대로 찾았는가?
2) HTTP 인증 또는 IMS AKA 기반 인증이 완료됐는가?
3) Request-URI의 XUI, application usage, document selector가 맞는가?
4) PUT body의 XML namespace와 rule 구조가 맞는가?
5) 서버 응답 이후 GET으로 같은 값이 조회되는가?
6) 착신 INVITE 시 TAS/AS가 해당 rule을 읽고 적용했는가?XML rule에서 자주 보는 부분
XML 본문에서는 활성화 여부, condition, action, target이 핵심입니다. 사업자 구현마다 표현이 조금씩 다를 수 있지만, 분석 감각은 비슷합니다. “이 rule이 켜져 있는가?”, “어떤 조건에서 동작하는가?”, “전환 대상이 정상적인 SIP URI 또는 전화번호 형식인가?”를 순서대로 보면 됩니다.
<communication-diversion active="true">
<ruleset>
<rule id="cfu-rule">
<conditions>
<!-- unconditional, busy, no-answer, not-registered 등 -->
</conditions>
<actions>
<forward-to>
<target>sip:+821012345678@example.ims</target>
</forward-to>
</actions>
</rule>
</ruleset>
</communication-diversion>착신전환 장애는 “기능이 안 됨”으로 들어오지만, 막상 보면 번호 포맷 문제인 경우가 꽤 있습니다. 사용자는 010으로 저장했다고 생각하지만, 네트워크에서는 E.164 형식, SIP URI 형식, 국내 번호 변환 정책을 따로 적용합니다. 그래서 target 값은 항상 원문 그대로 확인하는 습관이 좋습니다.
7. XCAP Call Diversion을 한 문장으로 정리하면
XCAP는 사용자가 단말에서 바꾼 착신전환 설정을 IMS 네트워크가 이해할 수 있는 XML 서비스 데이터로 저장하는 통로이고, Call Diversion은 그 설정을 실제 착신 통화에서 TAS/AS가 적용하는 서비스 로직입니다.
그래서 이 주제를 볼 때는 XCAP와 SIP를 따로 떼어 보면 안 됩니다. 설정은 Ut/XCAP에서 보고, 통화 적용은 SIP/TAS 흐름에서 봐야 합니다. 두 흐름이 같은 사용자, 같은 조건, 같은 target을 바라볼 때 착신전환은 정상적으로 동작합니다.
Q1. XCAP Server가 통화를 직접 착신전환하나요?
보통 그렇게 보지 않습니다. XCAP Server는 사용자의 서비스 설정을 저장하고 조작하는 역할에 가깝습니다. 실제 착신 통화에서 전환 여부를 판단하고 SIP 세션을 처리하는 쪽은 TAS/AS입니다.
Q2. Call Diversion과 Call Forwarding은 같은 말인가요?
사용자 관점에서는 착신전환, Call Forwarding이라고 부르는 경우가 많습니다. 3GPP IMS 문서에서는 Communication Diversion, 줄여서 CDIV라는 이름으로 다룹니다.
Q3. 착신전환 설정은 SIP REGISTER 때 같이 내려오나요?
일반적으로 SIP REGISTER는 IMS 등록 절차이고, 착신전환 같은 supplementary service 설정 조작은 Ut 인터페이스의 XCAP 흐름으로 별도 처리되는 경우가 많습니다. 단말 구현이나 사업자 정책에 따라 조회 시점은 다를 수 있습니다.
Q4. XCAP 로그에서 가장 먼저 봐야 할 것은 무엇인가요?
Request-URI, HTTP method, 응답 코드, XML body를 먼저 봅니다. 특히 같은 사용자의 설정을 PUT한 뒤 GET으로 다시 조회했을 때 값이 그대로 보이는지 확인하면 저장 문제와 통화 적용 문제를 구분할 수 있습니다.
Q5. 무응답 착신전환 시간이 단말 표시와 다르게 보일 수 있나요?
가능합니다. 단말 UI에 보이는 시간, 네트워크의 no-reply timer, TAS의 서비스 정책이 항상 같은 값으로 보장되지는 않습니다. 실제 로그에서는 180 Ringing 이후 언제 전환 판단이 발생했는지를 함께 봐야 합니다.
Q6. 전환 대상 번호는 어떤 형식으로 저장되나요?
구현에 따라 전화번호, SIP URI, E.164 형식 등이 사용될 수 있습니다. 장애 분석에서는 사용자가 입력한 번호와 서버에 저장된 target 값이 어떻게 정규화되었는지 확인하는 것이 중요합니다.
- 3GPP TS 24.623 - XCAP over the Ut interface for Manipulating Supplementary Services
- 3GPP TS 24.604 - Communication Diversion using IMS Core Network subsystem; Protocol specification
- 3GPP TS 24.229 - IMS call control protocol based on SIP and SDP; Stage 3
- 3GPP TS 23.228 - IP Multimedia Subsystem; Stage 2
- IETF RFC 4825 - The Extensible Markup Language Configuration Access Protocol
- IETF RFC 3261 - SIP: Session Initiation Protocol
- IETF RFC 7044 - An Extension to the Session Initiation Protocol for Request History Information
- IETF RFC 3325 - Private Extensions to SIP for Asserted Identity within Trusted Networks