GSMA RCS Blackbird(이하 RCS BB)는 시기적으로는 RCS 5.1 이후에 등장했으나 서비스 기능 측면에서 RCSe와 RCS 5.1의 중간 버전에 해당한다. RCSe가 단순히 IP기반 채팅에 무게를 두고 있고, RCS 5.1이 다양한 커뮤니케이션 서비스(e.g., 음성,영상,메세징)를 네트웍 기반에서 모두 융합하고 있는 서비스라면, RCS BB는 단말 UX/UI를 기반으로 해당 서비스들을 사용자 경험 측면에서 통합하고 있는 서비스라고 할 수 있다. RCS BB에서 정의하는 Converged Inbox나 Integrated Messaging과 같은 UX/UI 관련 내용들은 기존 IP Chat 기능과 Legacy Messaging Service, IP Voice Call/IP Video Call 기능을 동일한 UX/UI Context 상에서 제공함으로써 통합된 사용자 경험을 제공하기 위한 방법이다. RCS BB에서의 Voice over Wi-Fi call 이나 IP Video Call은 모두 best effort network 상에서 제공될 수 있도록 정의되고 있으나, 이후 RCS 5.x에서는 VoLTE를 통합한다. 또한, RCS BB에서는 RCSe의 IMS Core 레벨의 forking과는 구별하여 서비스 레벨의 forking을 제공함으로써 사용자의 멀티디바이스 환경 지원에 관한 기술을 구체화 하고 있다.
본 글에서는 GSMA RCS BB에서 정의하고 있는 기능들을 RCSe 및 RCS 5.1의 기능과 비교하여 정리한다. 각 항목에는 RCSe를 기준으로 RCS BB에 새롭게 추가된 기능만 기술되었다.
OPTIONS-AS for SIP OPTIONS based discovery
기존 RCSe에서의 SIP OPTIONS기반 service capability discovery 에서는 발/착신 RCS 클라이언트가 IMS Core를 통해 SIP OPTIOS를 교환하는 방식이었다. 이 방법에서는 사용자가 복수단말을 가지는 경우를 지원하지 않는다. IMS Core 기반의 forking 방식에서는 사용자의 각 단말의 service capability를 취합하는 기능이 없기 때문이다. RCS 에서는 복수단말을 가지는 사용자의 각 RCS 클라이언트의 service capability를 취합할 수 있도록 서비스 레벨의 forking 방식을 사용할 것을 권고하고 있고 이를 위한 네트웍 Component를 Options-AS라 정의하고 있다. RCS에서 정의하는 Options-AS는 발신단말이 전송한 SIP OPTIONS를 착신자의 각 단말로 forking하고, 착신자의 각 단말로부터 수신되는 각 service capability를 취합하여 발신단말로 전송한다. SIP OPTIONS를 수신한 각 단말은 단말 자체의 device capability외에 네트웍 상태나 사용자 설정정보(i.e., user preference)와 같은 요소들을 고려할 수 있어야 한다.
10. IP Video Call
RCS BB에서의 IP Video Call은 종단간 best effort network을 통해 이루어진다. IP Video Call은 종단 사용자가 모두 IP Video Call을 지원하는 경우에만 사용이 가능하다. IP Voice Call 과 마찬가지로 IP Video Call 도 best effort network을 통해 이루어지지만, 네트웍 bandwidth가 허용하는 범위안에서 최적화된 비디오 품질을 제공할 수 있어야 한다. RCS 사용자는 UX/UI 에서 제공되는 기능을 통해 주소록의 contact에게 직접 IP Video Call을 시도하거나 또는 IP Voice Call 에서 IP Video Call로 전환할 수도 있다. IP Video Call 사용자는 비디오 통화 중 자신의 비디오 스트리밍을 제거할 수도 있다.
본 글에서는 GSMA RCS BB에서 정의하고 있는 기능들을 RCSe 및 RCS 5.1의 기능과 비교하여 정리한다. 각 항목에는 RCSe를 기준으로 RCS BB에 새롭게 추가된 기능만 기술되었다.
1. Configuration Provisioning
Provisioning over non-PS
RCS BB에는 PS를 통해서 네트웍에 접근하는 단말과 함께 Wi-Fi와 같은 non-PS를 통해 접근하는 단말에 대한 configuration provisioning을 제공한다. 단말이 Wi-Fi와 같은 non-PS를 통해 접근하는 경우는 사용자의 primary device가 기동 할 때 어떠한 이유로든 PS 접속이 원활하지 않거나 또는 사용자가 secondary device를 사용하는 경우에 해당한다. RCS configuration provisioning에서는 단말 인증방법에 대해 구체적으로 기술하지 않고 있고, 사업자에 따라 IMSI(International Mobile Subscriber ID) 기반 인증 또는 단말의 source IP기반 인증과 같은, 망 상황에 따른 다양한 방법이 사용되고 있다.
RCS BB에는 PS를 통해서 네트웍에 접근하는 단말과 함께 Wi-Fi와 같은 non-PS를 통해 접근하는 단말에 대한 configuration provisioning을 제공한다. 단말이 Wi-Fi와 같은 non-PS를 통해 접근하는 경우는 사용자의 primary device가 기동 할 때 어떠한 이유로든 PS 접속이 원활하지 않거나 또는 사용자가 secondary device를 사용하는 경우에 해당한다. RCS configuration provisioning에서는 단말 인증방법에 대해 구체적으로 기술하지 않고 있고, 사업자에 따라 IMSI(International Mobile Subscriber ID) 기반 인증 또는 단말의 source IP기반 인증과 같은, 망 상황에 따른 다양한 방법이 사용되고 있다.
하지만, 단말이 Wi-Fi를 통해 접근하는 경우 기존의 방법으로는 한계가 있다. 이를 테면, 단말이 네트웍 접근 단계에서 DHCP(Dynamic Host Configuration Protocol) 기반으로 private IP를 할당 받았다던지, 단말이 SIM(Subscriber Identity Module) Card가 없는 secondary device인 경우에 해당한다. Private IP는 사업자 네트웍에서 인증할 수 있는 방법이 없으므로 결국 MSISDN(Mobile Station International Directory Number)에 기반한 인증이 필요하다.
따라서, 이 경우 RCS에서는 OTP(One Time Passcode)기반의 인증을 수행할 것을 권고하고 있다. 이는 일반적인 3rd-party 어플리케이션들이 사용자를 인증하는 방법이기도 하다. OTP 기반 인증은 configuration server에서 생성한 OTP를 SMS로 단말까지 전송하고, 단말의 RCS Client의 초기화 단계에서 해당 OTP를 입력함으로써 사용자를 인증하는 방법을 의미한다.
SMS based authentication(OTP)
Configuration Server에서 생성된 OTP를 단말로 전송하는 방식으로는 일반적으로 SMS가 사용된다. 이는 대부분의 OTT 서비스들이 채택하고 있는 방식이기도 하다. OTP를 포함한 SMS를 단말로 전송하기 위해서는 사용자 단말의 MSISDN이 필요하므로, 단말 클라이언트는 어플리케이션 셋업 절차에서 UX/UI를 통해 해당 정보를 사용자에게 요구할 수 있다. RCS 표준에서는 OTP에 대한 사용자의 개입을 최소화하기 위해 OTP를 포함하는 SMS가 SMS 클라이언트가 아닌, 단말내의 RCS 클라이언트로 직접 전달될 수 있도록 MAP 포맷을 정의하고 있다. RCS 서비스는 opt-out 서비스 이므로, 원칙적으로는 단말에서 configuration provisioning 요청 시 SIM Card의 MSISDN을 읽어 HTTP GET 에 포함시킬 수 있어야 한다. 만일 MSISDN이 없다면, IMSI로 부터 MSISDN을 추출할 수 있어야 한다. User Interaction이 없이 자동으로 가입절차를 밟을 수 있기 위해서다. 그러나, 사업자에 따라, 국가에 따라 이러한 요구사항이 모두 만족되지 않을 수 있기 때문에, 결국 이 경우 사용자로부터 MSISDN을 입력받을 수 있어야 한다.
Configuration Server에서 생성된 OTP를 단말로 전송하는 방식으로는 일반적으로 SMS가 사용된다. 이는 대부분의 OTT 서비스들이 채택하고 있는 방식이기도 하다. OTP를 포함한 SMS를 단말로 전송하기 위해서는 사용자 단말의 MSISDN이 필요하므로, 단말 클라이언트는 어플리케이션 셋업 절차에서 UX/UI를 통해 해당 정보를 사용자에게 요구할 수 있다. RCS 표준에서는 OTP에 대한 사용자의 개입을 최소화하기 위해 OTP를 포함하는 SMS가 SMS 클라이언트가 아닌, 단말내의 RCS 클라이언트로 직접 전달될 수 있도록 MAP 포맷을 정의하고 있다. RCS 서비스는 opt-out 서비스 이므로, 원칙적으로는 단말에서 configuration provisioning 요청 시 SIM Card의 MSISDN을 읽어 HTTP GET 에 포함시킬 수 있어야 한다. 만일 MSISDN이 없다면, IMSI로 부터 MSISDN을 추출할 수 있어야 한다. User Interaction이 없이 자동으로 가입절차를 밟을 수 있기 위해서다. 그러나, 사업자에 따라, 국가에 따라 이러한 요구사항이 모두 만족되지 않을 수 있기 때문에, 결국 이 경우 사용자로부터 MSISDN을 입력받을 수 있어야 한다.
NOTE
RCS에서는 OTP 전송을 위해 SMS외에 EUCR을 이용하는 방법도 정의하고 있으나 이 기능은 RCS 5.1부터 지원하도록 되어있다.
Network Initiated Provisioning
네트웍의 configuration server가 RCS 클라이언트로 하여금 configuration provisioning을 요청하도록 트리거링하는 기능을 의미한다. RCS에서 언급되고 있는, Network initiated provisioning이 필요한 경우는 다음과 같다.
- RCS 서비스 관련 설정이 변경된 경우
- RCS 어플리케이션의 버전이 변경된 경우
- 단말에서 비활성화 되어있던 RCS client를 활성화 시키려 하는 경우.
RCS 클라이언트를 트리거링하기 위해 RCS 시스템은 정해진 포맷의 SMS 메세지 또는 EUCR을 단말로 전송한다. Configuration provisioning을 위한 메세지(i.e., SMS 또는 EUCR)를 수신한 단말은 IMS네트웍으로부터 de-registration 후 configuration provisioning 절차를 수행한다.
User Messages Using EUCR(End User Confirmation Request)
사업자에 따라 사용자의 RCS 서비스 가입 시 서비스 약관등에 대한 사용자의 동의가 필요하거나 서비스 관련 공지사항을 사용자에게 전송해야 하는 경우가 있다. 이 기능은 RCSe에서는 자세히 다루어지지 않고 있으나 RCS BB로 오면서 좀 더 구체적으로 기술되었다. EUCR은 RCS BB 이후 버전부터 configuration provisioning을 위한 OTP나 사용자 메세지를 전송하기 위한 방법으로 폭넓게 사용되고 있다. 사용자 메세지는 독립적인 SIP MESSAGE로 전송될 수 도 있고, 단말이 configuration provisioning 절차에서 수신하게 되는 HTTP 200 OK에 configuration parameter와 함께 body에 포함되어 전송될 수도 있다. 서비스 로직에 따라 RCS 클라이언트는 수신된 EUCR을 확인하고 해당 메세지를 단말 화면상에 팝업시켜 사용자의 입력을 받을 지 seamless하게 내부적으로 처리할 지를 판단할 수 있어야 한다.
RCS BB Configuration management
RCS BB는 RCS 5.1에 정의된 configuration parameter를 그대로 사용한다. 다만, RCS 5.1 보다 기능 제약이 많으므로, 이와 관련된 일부 configuration parameter의 값은 상수로 설정된다.
2. Service Capability Discovery
기존 RCSe에서의 SIP OPTIONS기반 service capability discovery 에서는 발/착신 RCS 클라이언트가 IMS Core를 통해 SIP OPTIOS를 교환하는 방식이었다. 이 방법에서는 사용자가 복수단말을 가지는 경우를 지원하지 않는다. IMS Core 기반의 forking 방식에서는 사용자의 각 단말의 service capability를 취합하는 기능이 없기 때문이다. RCS 에서는 복수단말을 가지는 사용자의 각 RCS 클라이언트의 service capability를 취합할 수 있도록 서비스 레벨의 forking 방식을 사용할 것을 권고하고 있고 이를 위한 네트웍 Component를 Options-AS라 정의하고 있다. RCS에서 정의하는 Options-AS는 발신단말이 전송한 SIP OPTIONS를 착신자의 각 단말로 forking하고, 착신자의 각 단말로부터 수신되는 각 service capability를 취합하여 발신단말로 전송한다. SIP OPTIONS를 수신한 각 단말은 단말 자체의 device capability외에 네트웍 상태나 사용자 설정정보(i.e., user preference)와 같은 요소들을 고려할 수 있어야 한다.
NOTE RCS BB에서는 service capability discovery에 대한 복수단말 지원기능을 Optional로 정의하고 있다.
Capability Exchange Optimization
RCS 클라이언트에서 Service Capability Discovery를 수행하는 시점은 다음과 같다.
- 최초 수행: 단말 기동 시 단말 주소록의 모든 contact에 대한 수행
- 주기적 수행: 주소록의 contact에 대한 polling period기반의 주기적 수행
- 실시간 수행: 사용자가 채팅/파일전송/위치정보 공유/비디오 공유등의 서비스 요청 시 수행
- New User Discovery: 주소록에 새로운 contact추가 되는 경우 RCS 클라이언트는 해당 contact이 RCS 사용자인지를 알기 위해 SIP OPTIONS based Service Discovery를 수행.
RCS에서는 SIP OPTIONS기반 service capability discovery가 유발할 수 있는 대량의 트래픽을 적절히 제어할 것을 권고하고 있다. 예를 들어, RCS BB에서는 1-1 chat에서 MESSAGING CAPABILITIES VALIDITY 파라미터를 이용해 클라이언트에서 획득한 contact의 service capability의 유효시간을 정의하고, 해당 유효시간 안에 있는 contact에 대해서는 service capability discovery를 수행하지 않는 방식을 제안한다. 예를 들어, 사용자가 임의의 contact에게 chat을 시도하고 클라이언트가 알고 있는 해당 contact의 capability가 유효시간안에 있는 경우, 해당 contact에 대한 service capability discovery는 수행되지 않는 식이다.
그러나 RCS 규격에 언급된 방식도 특정 상황, 예를 들어, 특정 지역의 네트웍이 일시적으로 접속이 불가능했다가 다시 재개 됨에 따라 거의 동시에 다수의 단말들이 네트웍에 접속하여 service capability discovery를 수행하는 상황을 통제할 수는 없다. 따라서, 서로 다른 RCS 클라이언트간 트래픽이 겹치는 것을 최소화하고 대량의 트래픽으로 부터 네트웍을 보호하기 위한 구현관점의 적절한 알고리즘이 RCS 클라이언트와 서버에 모두 필요하다.
NOTE
RCS BB에서는 RCSe에서 Optional로 정의되었던 Presence 기능이 제외되었다. Presence 기능은 이후 RCS 5.1에서 다시 도입된다.
RCS BB에서는 RCSe에서 Optional로 정의되었던 Presence 기능이 제외되었다. Presence 기능은 이후 RCS 5.1에서 다시 도입된다.
3. 1-1 Chat
RCS BB에서의 1-1 Chat은 RCSe와 마찬가지로 SIMPLE IM에 기반하며 멀티디바이스 관련 고려사항을 빼고는 RCSe의 방식을 그대로 따른다.멀티디바이스를 가진 착신자에게 전송된 RCS 메세지는 착신자의 각 단말에게 전송된다. 착신자가 어느 한 단말로부터 응답(200 OK)을 하는 경우 해당 착신자의 다른 단말로 전송된 SIP INVITE는 취소(SIP CANCEL)된다. 발신자가 멀티디바이스를 가진 경우, IMDN은 발신자가 RCS 메세지를 전송한 해당 단말로 전송되어야 한다. RCS에서는 RCS 메세지에 대한 forking을 RCS 시스템에서 수행하는 서비스 레벨에서 하도록 기술하고 있다. RCS 시스템은 착신자의 복수단말 가운데 1-1 Chat 기능을 제공하는 특정 단말을 구분하고 forking을 수행할 수 있어야 한다.
4. Group Chat
Handling of involuntary leaving
RCS BB에서의 RCS 시스템은 참여자의 involuntary leaving을 감지할 수 있어야 한다. 이는 RCS 시스템이 착신자로 부터 명시적인 SIP BYE를 수신하지 않은 경우에 해당한다. RCS 시스템(PF)은 참여자의 voluntary/in-voluntary leaving을 감지함으로써 해당 참여자를 그룹 세션에서 제외할 지 또는 해당 참여자에게 store and forward 서비스를 제공할 지를 결정할 수 있어야 한다. 그룹 대화에 참여하고 있는 참여자의 involuntary leaving을 감지하는 기준은 RCS 시스템 및 IMS Core의 정책에 따른다. RCS 클라이언트가 store and forward 기능을 지원하지 않는 경우 RCS 시스템(PF)은 involuntary leaving 감지 시 해당 참여자 대신 그룹 세션내에서 SIP BYE를 전송해 해당 세션을 종료하고 해당 참여자에 대한 더 이상의 메세지를 수신하지 않는다. 그러나, RCS 클라이언트가 store and forward를 지원하는 경우 RCS 시스템(PF)은 사용자 대신 종단점의 역할을 수행할 수 있어야 한다.
Store and forwad in a group session(basic, full)
그룹 대화에 참여하고 있는 사용자가 메세지를 수신할 수 없는 상태인 경우 해당 메세지를 임시로 RCS 시스템에 저장하고 이후 착신자가 다시 메세지를 수신할 수 있는 상태가 되면 저장된 메세지를 전송한다. 이 기능은 기존 RCSe에서 1-1 Chat에만 적용되었던 store and forward 기술을 Group chat으로 확장한 것이다.
NOTE RCS BB에서는 기술적 측면에서 그룹대화에서의 full/basic stored and forward 기능을 지원하지 않는 것으로 명시하고 있다. 그러나, 사용자 경험 측면에서 그룹 대화 참여자는 일시적인 네트웍 상태 불안등의 이유로 그룹 세션으로 부터 이탈했다가 다시 참여하게 된 경우(re-joining)라도 그동안 자신에게 온 메세지를 모두 받아볼 수 있도록 하고 있다. 이렇게 사용자 경험측면의 기술과 기술적 측면에서의 기술사항이 다른 것은 1-1 Chat에서의 store and forward 기능을 그대로 그룹 세션에 적용하고자 하는는 것으로 이해되지만(i.e., PF에 의한 store and forward), 본 글에서는 RCS 5.1의 그룹 대화에서의 store and forward 기능을 사실상 채택한 것이라 간주하고 본 기능을 RCS BB의 범위에 포함시켰다.
(1) Basic store and forward
그룹 대화에 참여하고 있는 참여자가 involuntary leaving으로 메세지를 수신할 수 없고 해당 사용자가 그룹 세션에서의 store and forward 기능을 지원하는 경우 RCS 시스템(PF)은 해당 참여자를 대신하여 종단점 역할을 수행한다. 이를 위해 사용자의 단말은 service capability discovery 단계에서 basic store and forward 기능 지원여부를 명시해야 한다. 착신자를 대신하여 RCS 시스템에 저장된 메세지가 얼마나 오랫동안 저장되어 있어야 하는 지는 시스템의 로컬 정책에 따른다. 이후, 착신자가 다시 서비스에 접속한 경우, 해당 그룹 세션의 종료여부와 무관하게 RCS 시스템은 저장되었던 메세지를 착신 단말로 전송한다.
(2) Full store and forward
그룹 대화 요청에 대한 착신자의 수락이 늦어지고 해당 착신자가 full store and forward를 지원하는 경우 RCS 시스템(PF)은 해당 참여자를 대신하여 종단점 역할을 수행한다. 이는 RCS 시스템은 착신자가 늦게라도 그룹 대화에 참여할 것을 가정하여 착신단말 대신 200 OK를 보내고 대화에 참여함을 의미한다. 이후 착신자가 대화에 참여(i.e., 200 OK 수신)하면 그동안 저장되었던 메세지를 해당 단말로 전송한다. 해당 메세지를 얼마나 오랫동안 RCS 시스템에 저장하고 있을지는 시스템의 로컬 정책 또는 사업자 정책에 따른다. 만일 착신자가 명시적으로 그룹 세션 요청을 거절한 경우(603 Decline), RCS 시스템은 해당 사용자에 대한 그룹 세션내의 저장된 메세지를 모두 폐기한다.
NOTE
그룹 대화에서의 store and forward를 위한 메세지 저장 기간과 참여자에게 전송된 SIP INVITE 타이머, involuntary leaving 감지 정책, 그룹 세션이 종료될 때까지 참여 수락을 하지 않은(무응답) 착신자에 대한 처리등은 구현 관점에서 고려되어야 한다.
Restart the group session(Long Lived Group)
그룹세션이 종료된 후, 사용자는 RCS 클라이언트에 저장되어 있는 대화내역(conversation history thread)을 통해 해당 그룹 세션을 재개할 수 있다. 이를 위해 참여자는 RCS 클라이언트의 해당 대화내역에서 새로운 메세지(e.g., 채팅, 파일전송, 위치정보 공유, 비디오 공유등)를 전송한다. RCS 시스템은 종료된 그룹 세션의 정보(e.g., conference uri, 참여자 정보, 그룹 속성 및 정책 등)를 일정기간 유지하고 있어, 참여자로부터 종료된 그룹 세션에 대한 SIP INVITE를 수신하면 해당 그룹세션을 다시 생성할 수 있어야 한다. RCS 에서는 RCS 시스템에서 종료된 그룹 세션 정보를 저장하고 있는 기간을 최소 1개월로 권고하고 있고 이 기간은 사업자가 변경할 수 있어야 한다.
NOTE 사용자가 그룹 대화 재개를 요청하는 시점이 너무 늦었거나(i.e., CF에서 해당 그룹 세션의 Session Identity를 삭제) 또는 그룹 대화를 재개할 권한을 가지지 않은 경우 RCS 시스템은 실패응답을 전송할 수 있다.
Re-joining the group session
그룹 대화 참여자는 네트웍의 불안 또는 단말 자체의 문제와 같은 예상치 못한 이유로 본인의 의사와는 무관하게 그룹 세션으로 부터 이탈될 수 있다(involuntary leaving). 이후 해당 문제가 해결되면 참여자는 해당 그룹 세션에 다시 참여할 수 있다. 이를 위해 RCS 클라이언트는 그룹 세션의 session identity를 일정기간 저장하고 있어야 한다. 참여자의 involuntary leaving을 감지한 RCS 시스템(PF)은 해당 RCS 클라이언트가 basic store and forward 기능을 지원하는 경우 해당 클라이언트 대신 종단점의 역할을 수행하고, 이후 RCS 클라이언트가 해당 그룹 세션에 re-joining 하는 경우 저장된 메세지를 전송한다. 만일, 해당 RCS 클라이언트가 store and forward 기능을 지원하지 않는 경우 RCS 시스템에서 착신 단말 대신 SIP BYE를 전송하고 그룹대화를 종료한다. 한편, 그룹대화 참여자가 명시적으로 해당 그룹 세션을 이탈한 경우(i.e., SIP BYE 전송), 해당 참여자의 이름이 그룹 세션의 참여자 명단에서 삭제되므로 현재 참여중인 사용자로부터 별도의 초대를 받지 않는 이상 re-joining은 불가능하다.
IMDN Delivery & aggregation
기존 RCSe의 IMDN 기능이 1-1 Chat에서만 지원되고 있던 것을 확장하여, RCS BB에서는 그룹 세션에서의 delivery notification을 지원하도록 하고 있다. 만일 착신 RCS 클라이언트가 그룹 세션에서의 IMDN을 지원하지 않는 경우 RCS 시스템(PF)은 착신단말을 대신하여 delivery notification을 전송할 수 있어야 한다.
NOTE 그룹 세션에서의 displayed notification은 RCS 5.x부터 지원한다.
Multiple devices
RCS BB에서의 그룹 대화 서비스는 사용자 경험의 일관성을 위해 primary device 에서만 가능하다. 이는 사용자가 멀티디바이스 환경에서 그룹 세션에 대해 서로 다른 단말로 re-joining 또는 re-start를 수행하는 경우 사용자의 서비스 경험 일관성에 영향을 줄 수 있기 때문이다.
Group Session Policy
RCSe에서는 그룹 대화 생성자가 해당 그룹 세션을 이탈하는 경우 그룹 세션이 종료되었으나, RCS BB에서는 그룹 대화 생성자의 이탈 여부가 그룹 세션의 종료에 영향을 주지 않는다. RCS BB에서는 해당 그룹 세션에 한 명 밖에 남지 않거나 그룹 세션에서 일정 시간동안 대화가 이루어지지 않는 경우 해당 그룹 세션은 자동으로 종료된다. 이밖에 사업자는 사용자에게 다양한 형태의 그룹 세션 정책을 제공할 수 있다.
Auto Accept
RCS 클라이언트는 provisioning 받은 IM SESSION AUTO ACCEPT GROUP CHAT 파라미터를 통해 그룹 대화 요청을 자동으로 수락할 지를 설정할 수 있다. RCS BB에서는 해당 파라미터의 값을 1로 설정하여 그룹 대화 요청을 항상 수락할 수 있도록 하고 있다. 다만, 사용자가 멀티디바이스 환경에 있는 경우 RCS BB에서의 그룹 대화 자동 수락 기능은 primary device로 제한된다. Secondary device 에서 그룹 세션 자동 수락 기능은 지원되지 않는다.
NOTE RCS BB에서는 네트웍 기반 메세지 스토리지가 제공되지 않으므로 멀티디바이스에서의 대화내역에 일관성이 보장되지 않는다. 그룹 대화 기능 및 Auto Accept 기능들이 primary device로 제한되는 것은 이 때문이다.
5. File Transfer
HTTP based File Transfer
6. Geolocation
7. Contents Sharing
RCS BB에서의 컨텐츠 공유서비스는 음성 통화 세션에 의존성을 가지기 때문에 멀티디바이스를 지원하지 않는다. 사용자는 음성 통화가 이루어지고 있는 단말에서만 비디오 공유 서비스를 진행할 수 있다.비디오 공유 서비스가 이루어지는 가운데, 음성 통화가 Call On Hold, Multiparty Call, Call Forwarding 로 전환되는 경우 해당 비디오 스트리밍 세션은 종료된다.
RCS BB에서의 파일전송 서비스는 기존 RCSe의 MSRP기반 파일전송 방식외에 HTTP 기반 파일전송 방식을 지원하고 있다. RCS BB에서의 HTTP 기반 파일 전송방식에서는 Thumbnail Preview, Pause and Resume, Group File Transfer, Store and forward와 같은 다양한 부가적 기능들을 지원하고 있다. MSRP 방식에서의 부가 기능에 대한 지원은 RCS 5.x 이후부터 정의된다.
HTTP based File Transfer
RCS BB에서는 기존 RCSe에서의 MSRP기반의 파일전송 외에 HTTP 기반의 파일전송을 지원한다. HTTP 기반 파일전송에서 발신단말은 파일 및 thumbnail을 네트웍상의 컨텐츠 서버에 저장한 후, 저장된 컨텐츠의 location url를 xml 형태로 메세지에 실어 착신측으로 전송한다. 즉, Indirect Delivery 방식이다. 발신 클라이언트는 xml을 착신측으로 전송하기 위해 Chat Invitation (e.g., SIP INVITE) 또는 Standalone Messaging 을 전송할 수 있다. 파일 전송 요청 메세지를 수신한 착신자는 해당 파일전송을 수락 또는 거부할 수 있다. 착신자가 해당 파일 전송 요청을 수락한 경우, 착신 클라이언트는 수신된 xml에 포함된 파일의 location url로 부터 해당 파일을 다운로드 한다.
NOTE RCS BB에서는 기존 RCSe에서의 MSRP 기반 파일전송을 그대로 사용할 수 있지만, 파일 전송을 위한 기본 메카니즘으로는 HTTP 방식을 채택하고 있다.
Group File Transfer(HTTP)
RCS BB에서는 그룹 타겟에 대한 파일전송을 지원한다. 그룹 타겟에 대한 파일전송은 기존 그룹 대화 세션내에서 이루어질 수도 있고, 독립적인 그룹 파일전송의 형태로 수행될 수도 있다. RCS BB에서는 그룹 세션 내에서 멀티미디어 전송이 지원되지 않는다. 따라서, 참여자가 전송하는 멀티미디어는 파일 전송 메카니즘을 통해 전송되며, 파일 전송을 위한 별도의 세션이 생성된다. RCS 클라이언트는 서로 다른 세션을 통해 전송된 컨텐츠는 동일한 대화 내역 컨텍스트에 표현할 수 있어야 한다.
Store and forward(HTTP)
RCS BB에서는 1-1 및 그룹에 대한 파일전송의 store and forward 기능을 지원한다. 컨텐츠 서버에 저장되어 있는 파일은 저장 만료 시간 종료 후 폐기된다.
Thumbnail preview(HTTP)
착신자는 파일 전송 요청을 수락하기 전에 해당 파일의 thumbnail을 확인할 수 있다. 이를위해 발신자는 전송 파일의 thumbnail을 파일 컨텐츠와 동일하게 컨텐츠 서버에 저장하고 해당 thumbnail의 location url을 파일의 location url과 함께 전송할 수 있어야 한다.
Pause and Resume(HTTP)
발신자가 파일을 컨텐츠 서버에 업로드하는 과정 또는 착신자가 컨텐츠 서버로부터 파일을 다운로드하는 과정에서 사용자의 요청 또는 네트웍 불안정 상태에 의해 파일전송이 중단될 수 있다. 전송이 중단된 파일 정보는 일정 기간동안 단말에서 유지되고 있으며 이후 발신자 또는 착신자가 해당 파일전송을 재개하는 경우 마지막 종료 지점부터 파일전송이 재개된다. 직전 중단된 파일 전송의 마지막 지점을 찾을 수 없는 경우 파일 전송은 처음부터 다시 수행될 수 있다. 네트웍 불안정 또는 여타의 이유로 파일 전송이 반복해서 중단될 수 있는데, 이 경우 RCS 시스템에서는 서비스 정책에 따라 최대 파일 전송 시도 횟수를 제한할 수 있다.
IMDN Delivery
MSRP 기반 파일전송의 경우 파일 전송 자체가 스트리밍 형태로 이루어지므로 종단간 파일 전송의 종료 여부 및 성공/실패 여부를 알 수 있다. 따라서, 별도의 display notification은 필요하지 않다. 그러나, HTTP 기반 파일 전송의 경우 파일 전송이 네트웍 상의 컨텐츠 서버를 통한 Indirect Delivery 방식이므로, 별도의 delivery notification과 display notification이 모두 지원되어야 한다. 착신 클라이언트는 발신자로부터 파일의 location url이 포함된 메세지를 받은 후 delivery notification을 전송한다. Display notification은 착신 클라이언트에 의해 파일 다운로드가 성공적으로 이루어진 후에 전송된다. 파일 전송이 채팅 컨텍스트 내에서 이루어지는 경우, RCS 클라이언트는 채팅 관련 IMDN과 파일전송 IMDN을 통합하어 전송할 수 있어야 한다.
Auto Acceptance
사용자는 단말에서 파일전송에 대한 자동수락 기능을 설정할 수 있다. 사용자가 파일 전송 자동 수락을 허용한 경우, RCS 클라이언트는 파일전송 요청에 대해 별도의 착신자 수락과정을 거치지 않는다. 단말에서의 파일 전송 자동 수락기능은 전송되는 파일의 크기가 configuration provisioning 에 의해 설정된 최대 파일 크기를 넘어서지 않는 경우에 한한다. 파일 전송 자동 수락기능은 멀티디바이스 환경에서는 지원되지 않는다.
Support of multiple devices
사용자가 멀티디바이스를 가지는 경우, 각 단말에서 제공하는 파일전송 기능은 모두 동일해야 한다. 즉, 사용자의 어느 한 단말이 HTTP 기반 파일전송 기능을 지원하지 않는 경우, 사용자의 다른 단말에서도 HTTP 기반 파일전송 기능은 off되어야 한다. 사용자의 primary device에서 HTTP 기반 파일전송을 지원하는 경우에만, 사용자의 secondary device에서 동일한 기능이 제공될 수 있다. 사용자의 primary device에서 RCS BB를 제공하는 경우 다른 단말에서 제공되는 legacy RCS 서비스(i.e., Joyn Hotfix)는 모두 off 되어야 한다. 네트웍의 configuration sever는 멀티디바이스를 가진 사용자의 각 단말의 RCS 클라이언트를 제어할 수 있어야 한다.
RCS 사용자는 서로 위치 정보를 교환할 수 있다. 단말의 위치 정보는 단말에 내장되어 있는 GPS 기능또는 MNO의 위치 서비스 인프라에 의해 획득될 수 있다. 그러나, 후자의 경우 GPS 기능이 없는 legacy device에 해당하는 것이므로, 스마트폰의 보급률이 높은 요즈음 고려할 필요는 없어 보인다. RCS에서 사용자간 위치정보를 교환하기 위한 방법으로 파일 전송 기술을 준용하고 있다. RCS 사용자는 자신의 위치 정보를 주소록상의 다른 RCS contact에서 전송할 수도 있고(push), 주소록의 RCS contact에게 위치 정보를 요청(pull)할 수도 있다. 획득된 상대방의 위치 정보는 RCS 클라이언트에서 제공하는 지도위에 표시(shows on the map)될 수 있다. RCS BB에서는 geolocation push 만 지원하고 geolocation pull 기능은 RCS 5.x부터 제공된다.
사용자가 멀티디바이스 환경인 경우, geolocation push 요청은 RCS BB를 지원하는 사용자의 primary device에서만 수신될 수 있다. Geolocation Push 요청 메세지 전송 시 RCS 시스템은 착신단말의 service capability를 고려해야 한다.
RCS 사용자의 위치정보를 교환하는 방법은 geolocation push/pull 외에 social presence information의 location information을 활용하는 방법도 있으나, 이 기능은 RCS 5.x 부터 지원된다.
RCS BB에서의 Conents Sharging은 RCSe의 방식을 그대로 이어받는다. 다만, RCS BB에서는 RCSe와 비교하여 사용자 경험 및 UX/UI와 관련하여 보다 자세하게 가이드하고 있다.
RCS 사용자는 음성통화 상대방과 이미지 또는 비디오를 공유할 수 있다. 이미지 공유는 RCSe와 마찬가지로 GSMA IR.79에 기반하고 있으며 기술적으로는 파일전송 방식을 따른다. 비디오 공유는 음성 통화 상대방과 비디오 스트리밍을 교환하는 기능을 의미하며 기술적으로는 RCSe와 마찬가지로 GSMA IR.74에 기반한다. 비디오 공유는 종단 사용자간 양방향 스트리밍이 가능한데 이 때 각 방향으로의 비디오 스트리밍 세션은 서로 분리되어야 한다. GSMA IR.74기반 비디오 공유 서비스가 음성 통화 서비스와 동시에 이루어지므로 간섭을 피하기 위해 음성 데이타는 전송되지 않는다.
NOTE 비디오 공유 서비스 기술은 이후 GSMA IR.84에서 음성 통화 세션에 의존하지 않는 독립된 서비스로 정의된다. GSMA IR.84 방식은 이후 RCS 5.x에서 채택되고 있다.
8. Integrated Messaging
9. IP Voice Call(Voice over Wi-Fi)
RCS BB에서는 best effort network을 통한 Voice over Wi-Fi Call을 지원한다. RCS 사용자는 Wi-Fi 를 이용하여 주소록의 contact에게 음성통화를 시도할 수 있다. 착신자가 CS 또는 VoLTE 네트웍에 있는 경우 Wi-Fi Voie Call은 사업자 네트웍의 VoIP break-out 기능을 통해 착신자에게 전달될 수 있어야 한다. 반대로, 발신자가 CS 또는 VoLTE 호로 발신을 한 경우라도 RCS 사용자는 해당 호를 Wi-Fi Voice call로 수신(i.e., VoIP break-in)할 수 있어야 한다. RCS BB의 Voice over Wi-Fi Call이 best-effort network을 통해 이루어지지만, 주어진 네트웍 bandwidth 내에서 최적의 음성품질을 제공할 수 있어야 한다.
8. Integrated Messaging
RCS BB에서는 RCS 5.x와는 달리 네트웍 기반의 Legacy Message Interworking 기능을 제공하지 않지만 UX/UI를 이용하여 사용자 경험 측면에서 통합한다. 이들을 통합하기 위해 RCS BB는 두 가지 방법을 제시하고 있다.
(1) Converged Inbox UX/UI
RCS메세지 및 SMS/MMS를 모두 RCS 클라이언트에서 관리하되 SMS/MMS thread와 RCS thread는 분리된다. 대화 내역 창의 분리된 thread 를 통해 RCS 사용자는 메세지 전송 시 SMS/MMS를 사용할 지 RCS를 사용할 지를 결정할 수 있어야 한다.
(2) Integrated Messaging UX/UI
RCS 메세지와 SMS/MMS가 모두 하나의 thread에서 관리된다. 사용자는 메세지 전송 시 RCS 메세지를 전송할 지 SMS/MMS 를 전송할 지를 분리하여 결정할 필요가 없다. RCS 클라이언트는 사용자의 메세지 전송 요청에 대해 RCS 메세지로 전송할 지 SMS/MMS로 전송할 지를 contact의 service capability를 기반으로 결정할 수 있어야 한다. RCS BB에서는 native RCS 클라이언트에 대해 Integrated Messaging 방식을 따르도록 하고 있다. 사용자가 멀티디바이스를 가지는 경우 SMS/MMS는 SIM Card가 있는 primary device에서만 발/수신이 가능하므로 RCS와 SMS/MMS를 번갈아 사용하는 경우 사용자의 secondary device에서는 사용자 대화내역의 일관성이 보장되지 않을 수 있다.
NOTE RCS 5.x에서는 네트웍 기반의 legacy messaging interworking 기능(i.e., IWF)과 네트웍 기반 메세지 스토리지 기능이 제공되므로, 멀티디바이스 환경에서 사용자 경험의 일관성이 제공된다.
9. IP Voice Call(Voice over Wi-Fi)
이 밖에, RCS BB에서 제공하는 최소한의 음성 부가서비스는 다음과 같다.
- Caller ID
- Communication On Hold
- Communication Waiting
NOTE RCS BB에서는 아직 단말에서 제공하는 CS 및 VoLTE 기능이 RCS클라이언트와 통합되지 않고 있다.
10. IP Video Call
IP Video Call에서 제공가능 한 부가서비스는 IP Voice Call과 동일하다.
마치며
- Caller ID
- Communication on Hold
- Communication Waiting
마치며
GSMA의 RCS Blackbird 는 현재 v3.0까지 정의되어 있다. RCS Blackbird는 RCS 5.x 보다 서비스 측면에서 많은 제약을 가지고 있지만, 제공되는 기능에 한해서는 RCS 5.x 에서 정의된 기술을 상당부분 수용하고 있다. RCS blackbird 규격이 정의된 시점이 RCS 5.1 이후인 점과 그럼에도 불구하고 서비스 측면에서 RCSe와 RCS 5.1의 중간 버전에 해당 됨을 감안하면 GSMA 에서 활동하고 있는 사업자들 간에 time to market에 대한 고민이 많았음을 짐작해 볼 수 있다. GSMA에서 제공하는 RCS서비스에 대한 accreditation program 역시 현재로서는 RCS blackbird 까지만 제공되고 RCS 5.x에 대한 accreditation program은 아직 마련되어 있지 않다.
RCS blackbird에서는 RCS 5.x의 기능을 기술적으로 수용하고 있지는 않지만, 대신 사용자 경험 측면에서 서로 다른 서비스(i.e., IP Chat, SMS/MMS, IP Voice, IP Video)를 통합하고자 하는 노력이 엿보인다. RCS 서비스 역시 서로 다른 서비스 silo를 동일한 사용자 경험으로 통합하고자 하는 큰 흐름에 동참하고 있고, 이러한 흐름은 이미 라인이나 카카오톡, 그 이전의 PC기반의 수많은 메신저 서비스들이 주도하고 있던 흐름과 무관하지 않다.
최근 북미와 유럽의 대표적인 OTT 서비스인 What's app이 페이스북에 인수되고, 한국의 카카오톡과 다음 커뮤니케이션즈라고 하는 거대 포털이 힘을 합치고 있는 시장의 흐름을 보면서, 그리고 태생부터 이미 네이버라는 또 다른 거대 포털과는 뗼 수 없는 관계였던 4억 가입자를 보유한 라인을 보면서, 커뮤니케이션 서비스 시장의 경쟁 상황이 결코 녹록하지 않음을 확인하게 된다. 인프라 측면에서 보나, 보유 가입자 측면에서 봤을 때 조인이라는 브랜드로 대표되는 RCS 서비스가 결코 그들보다 못하지 않은 것으로 보이지만, 그럼에도 불구하고 초기 RCSe 기술기반의 조인 서비스가 실패로 끝나고 있는 점은 많은 것을 시사한다. 이런 점에서 컨텐츠의 중요성과 생태계의 중요성은 아무리 강조해도 지나치지 않을 것이다.
그동안 네트웍 서비스 및 기술에 역량을 집중했던 통신 사업자가 이후 커뮤니케이션 서비스에서 헤게모니를 놓치지 않기 위해서는 OTT 사업자가 보여주고 있는 패러다임의 변화를 배울 필요가 있다. 여기서의 패러다임의 의미는 서비스와 사용자에 대한 사업자의 마인드셋(mindset)을 포함한다. 이와 더불어, 사용자 입장에서 봤을 때, 조인 서비스가 사용자 가운데 자리를 잡지 못한 큰 이유중의 하나는 서비스 안정성을 제공하지 못했기 때문인 것으로 풀이된다. 이미 서비스 안정화를 이룬 기존 OTT서비스에 비해, 조인 서비스는 아직 UX/UI 측면의 불완전성이 많고 메세지 전달 역시 불안정하다. 이는 조인 서비스의 근간을 이루고 있는 Access 및 IMS 네트웍, 서로 다른 사업자간 연동기능의 복잡성에도 어느 정도 원인이 있지 않을까 한다. RCS 서비스는 서비스 오류를 줄이고 SMS/MMS와 같은 수준의 안정적 서비스를 제공하는 것을 최우선 과제로 삼아야 한다. OTT서비스 사용자들도 서비스가 불안하다 싶으면 바로 SMS/MMS를 이용하는 것 처럼, 적어도 조인이 통신사들이 제공하고 있는 레가시 메세징 서비스의 안정성과 그에 대한 높은 신뢰도를 물려 받을 수 있어야 생태계든 컨텐츠든, 그 다음을 도모할 수 있는 것이다.
최근 국내 사업자들이 TTA 에 모여 다시 RCS 5.x에 대한 논의를 시작한다고 한다. 모쪼록 사용자에게 좀 더 한발자국 다가설 수 있는 RCS 서비스를 위한 논의가 되기를 기대해 본다.
Blackbird 4.0
이 글을 쓴 후 2014년 10월 RCS Blackbird PDD v4.0이 나왔다. GSMA는 Time to market을 고려해 기존 v3.0의 일부 기능을 삭제하기로 한 것으로 보인다. 그 삭제된 기능들은 다음과 같다.
- Converged Messaging
- Geoloation Push
- vCard
- Wi-Fi Voice
- RCS IP Voice Call
Wi-Fi Voice 를 뺀 것은 것은 개인적으로는 실망스러운 부분이다. 몇가지 기능을 제외함으로써 time-to-market을 만족할 수 있을지는 모르나, 어쩌면 RCS는 그나마 있던 가지고 있던 중요한 서비스 차별점 하나를 포기한 것이 아닐지. RCS가 원래 맞추었어야 하는 time-to-market은 어차피 지나버린지 오래다. 하지만, 라인, 카카오톡과 같은 메시징 시장을 지배하고 있는 대부분의 메신저는 이미 무료 Wi-Fi Voice를 제공하는 터라, RCS 사업자 입장에서는 규격과는 상관없이 이 부분을 고려하게 되지 않을까 싶다.
Blackbird 4.0
이 글을 쓴 후 2014년 10월 RCS Blackbird PDD v4.0이 나왔다. GSMA는 Time to market을 고려해 기존 v3.0의 일부 기능을 삭제하기로 한 것으로 보인다. 그 삭제된 기능들은 다음과 같다.
- Converged Messaging
- Geoloation Push
- vCard
- Wi-Fi Voice
- RCS IP Voice Call
Wi-Fi Voice 를 뺀 것은 것은 개인적으로는 실망스러운 부분이다. 몇가지 기능을 제외함으로써 time-to-market을 만족할 수 있을지는 모르나, 어쩌면 RCS는 그나마 있던 가지고 있던 중요한 서비스 차별점 하나를 포기한 것이 아닐지. RCS가 원래 맞추었어야 하는 time-to-market은 어차피 지나버린지 오래다. 하지만, 라인, 카카오톡과 같은 메시징 시장을 지배하고 있는 대부분의 메신저는 이미 무료 Wi-Fi Voice를 제공하는 터라, RCS 사업자 입장에서는 규격과는 상관없이 이 부분을 고려하게 되지 않을까 싶다.
Red Mouse
