지난 2012년 말 몇몇 유럽국가와 한국에서 시작한 조인(Joyn)서비스는 GSMA에서 정의한 RCS(Rich Communication Suite) 기술을 사용하고 있으며, 여러 개의 버전 가운데 가장 초기 버전인 RCSe 1.2 기반하고 있다. 이후 GSMA는 IP기반 통합 커뮤니케이션 서비스를 지향하며 지속적으로 기술규격을 진화시켜 오고 있다. RCSe가 IP Chat 이라는 가장 초기 형태의 IP 기반 서비스에 무게중심을 두고 있다면, 이후에 나온 RCS 5.x는 IP Chat을 중심으로 SMS/MMS를 통합하고, CS기반의 음성/영상 통화기능과 IP기반의 음성/영상 통화 기능을 통합하고 있다. 또한 RCS는 통합된 UX/UI를 제공함으로써, 서로 다른 형태의 서비스에 대한 사용자 경험의 융합을 꾀하고 있다. 이동 통신사들은 RCS를 통해 단기적으로는 예전부터 제공해 오던 CS기반의 음성 및 메세징 커뮤니케이션 서비스를 IP기반으로 확장하고, 나아가 그 위에 다양한 컨텐츠와 3rd-party 서비스를 수용함으로써 신규 수익을 창출할 수 있는 기반을 마련할 수 있기를 기대하고 있다.
지난 5월에 GSMA에서 발행한 RCS 5.2는 기존 RCS 5.1에서 기술되었던 내용 가운데 명확하지 않았던 부분을 좀 더 구체적으로 기술함과 동시에 몇몇 새로운 기능들이 추가되었다. 이번 포스팅에서는 RCS 5.2에서 달라진 내용들을 간략하게 추려 보고자 한다.
1. 네트웍 기반 메세지 스토리지(Network based Message Storage)
네트웍 기반 메세지 스토리지는 RCS 4.0 이후 OMA CPM의 Architecture를 채택하면서부터 제공되어오고 있는 컴포넌트로 사용자의 모든 대화 내역을 네트웍에 저장하고, 메세지 스토리지와 단말간 저장되어 있는 대화내역에 대한 동기화 기능을 제공한다. 이번 RCS 5.2에서는 대화내역 동기화 가운데서도 레가시 메세지 동기화 관련 내용이 대폭 보강되었다.
일반적인 경우라면, RCS 가입자가 아닌 일반 사용자에게 전송되는 RCS 메세지는 SMS/MMS로 변환되어 레가시 네트웍으로 연동되고 착신자로 부터 전송되는 모든 SMS/MMS는 RCS 메세지로 변환되어 시스템으로 유입된다. 이 때 대화내역이 메세지 스토리지에 저장되는 시점은 RCS 메세지가 다른 형태의 메세지로 변환되기 전이거나 다른 형태의 메세지가 RCS 메세지로 변환된 후 이므로, 저장되는 메세지데이타는 사용자 메세지(payload)와 함께 Contribution-ID, Conversation-ID, IMDN-Message-ID와 같은 SIP 헤더값들을 포함하고 있다. RCS에서는 사용자 메세지를 저장하기 위한 메세지 스토리지 내의 루트 폴더로 "RCSMessageStore"를 정해 놓고 있다. 사용자의 모든 메세지를 저장하기 위한 하위 폴더는 모두 이 루트 폴더아래에 생성되며, 사용자가 임의로 삭제/변경할 수 없도록 되어 있다. RCS 5.2에서는 특히 SMS/MMS 로 변환되었거나 또는 SMS/MMS로 부터 변환된 RCS 메세지를 저장하는 경우, 해당 메세지가 SMS인지 MMS인지에 대한 기록을 남기기 위해 message-context 파라미터를 정의하고 있다.
- message-context: "pager-message" | "multimedia-message"
그러나, 어떠한 이유에서건 RCS 서비스를 사용할 수 없는 경우 사용자는 SMS/MMS를 이용하게 되는데, 이 경우 메세지는 네트웍상의 메세지 스토리지에 저장되지 못하고 사용자의 단말에만 저장된다. 사용자 단말의 SMS/MMS 클라이언트가 이미 RCS 클라이언트에 통합되어 있음을 가정하면 해당 메세지들은 나중에 RCS의 메세지 스토리지와 동기화가 이루어져야 하는 대상이다. 단말에 저장되어 있는 SMS/MMS 메세지는 RCS 메세지가 아니므로, 메세지 스토리지와의 대화내역 동기화 시 중복성 여부를 체크(correlation check)할 수 있는 데이타 즉, Conversation-ID나 Contribution-ID와 같은 내용들을 가지고 있지 않다. 이러한 이유로, RCS 5.2에서는 각각 SMS와 MMS에 대한 중복성 체크를 위해 해당 메세지 저장 시 다음과 같은 정보를 저장하도록 하고 있다.
- message-context
- RCS-SMS-Context: SMS payload 140 byte
- Message-ID: MMS 메세지를 정의하는 ID
위의 파라미터를 이용하여, SMS/MMS의 동기화 시 SMS는 From/To 값과 함께 RCS-SMS-Context를 비교하고 MMS는 Message-ID를 비교하여 중복성 여부를 판단한다. 메세지 동기화 시 중복성 여부를 체크할 지의 여부는 SMS, MMS 에 대해 각각 provisioning configuration인 SMS MESSAGE STORE와 MMS MESSAGE STORE를 통해 결정된다. 동기화가 완료된 메세지는 저장된 폴더명과 함께 UID, UIDVALIDITY 값의 조합에 의해 유일하게 정의된다.
2. 파일 스토리지(Common File Store)
파일 스토리지는 파일 전송에 의해 전송된 파일을 저장하는 컴포넌트로 RCS 5.2에서 새롭게 도입되었다. HTTP 기반의 파일전송에서 사용되는 컨넨츠 서버(Contents Server)와 함께 파일 스토리지 역시 파일에 대한 "indirect dleivery"를 위해 사용된다. 즉, 발신자가 파일을 스토리지에 업로드 하고 그 location url을 착신자에게 전송하면, 착신자는 해당 location url을 통해 실제 파일을 다운로드 받는 방식이다. 파일 스토리지가 컨텐츠 서버와 다른 점은 파일의 Permanent 저장을 목적으로 하고 있다는 점과 저장된 파일의 단말에 대한 동기화 기능을 제공한다는 점이다. 파일 전송 메세지 전체를 저장하기 위해 파일 스토리지는 메세지 스토리지와 함께 조합을 이루어야 한다. 즉, 파일 전송을 위한 시그널 메세지는 메세지 스토리지에 저장되고 그 payload에 해당하는 파일은 파일 스토리지에 저장되는 식이다.
이 외에 RCS 5.2는 File Localization Function을 제공한다. File Localization Function은 발신 네트웍의 파일 스토리지에 저장되어 있는 파일을 파일 다운로드 요청자(i.e., 착신자)의 Home Network에 있는 파일 스토리지로 가져와 저장하는 역할을 수행한다. 이를 위해서는 발신자가 전송하는 location url을 착신 메세징 서버에서 적절하게 변경해 줄 수 있어야 한다. 착신 메세징 서버는 원래 발신자의 파일 스토리지 또는 컨텐츠 서버에 저장되어 있는 특정 파일의 위치를 가리키는 location url이 착신 네트웍의 File Localization Function을 가리키도록 변경한다. 이에 따라 File Localization Function은 착신자의 파일 다운로드 요청에 의해 트리거링 된다.
3. 음성 녹음 메세지
RCS 5.2는 음성녹음 메세지를 새롭게 정의하고 있다. 발신자는 음성을 녹음하여 착신자에게 전송할 수 있다. 녹음되는 음성파일의 최대 길이는 provisioning configuration인 MAX RRAM DURATION에 의해 제한된다. 발신자의 음성 녹음 메세지의 전송 절차는 일반적인 파일전송과 동일하다. 다만, 이 경우, 파일 전송의 경우와는 달리 해당 음성 녹음 메세지의 시간 및 날짜, 길이등이 함께 전송된다. 음성 녹음 메세지의 전송절차가 파일전송과 동일하므로, 이 기능은 파일전송이 가지는 다음의 기능들을 그대로 사용할 수 있다.
- MSRP 또는 HTTP 기반의 파일전송(i.e., DEFAULT FT MECH값에 따라 결정)
- Store and Forward
- Auto Acceptance
- IMDN notifciations
4. RCS Extensions
RCS Extension은 RCS Client 기반 위에서 자유롭게 정의될 수 있는 부가 서비스를 의미한다. RCS 5.2에서 새롭게 정의된 이 기능은 해당 규격에서 다음과 같이 정의하고 있다.
이 기능을 이용해 오퍼레이터는 자사 상황에 맞는 특정 형태의 서비스를 자유롭게 정의하여 RCS Client 위에 탑재할 수 있다. 이렇게 탑재된 RCS Extension은 RCS의 infrastructure의 모든 또는 일부 기능을 사용하여 다른 RCS client 또는 특정 RCS Extension과 통신할 수 있다. RCS 5.2는 RCS Extension을 수용하기 위한 ICSI, IARI 및 feature tag를 따로 정의한다. 또한 오퍼레이터는 RCS Extension의 사용 여부를 ALLOW RCS EXTENSION을 이용해 허용/제한(enabler/disable)하거나 EXTENSIONS MAX MSRP SIZE를 이용해 RCS Extension에 의한 MSRP의 길이를 제한할 수도 있다. RCS Extension을 허용/제한하는 방법으로는 EUCR을 이용한 System Request가 사용될 수도 있다.
5. 전송 메세지 취소 기능(Message Revocation)
RCS 5.2는 전송메세지에 대한 취소기능을 추가했다. 메세지 취소 기능은 아직 착신이 완료되지 않은 RCS 메세지를 발신 RCS 클라이언트나 발신 메세징 서버에서 취소할 수 있는 기능이다. 이는 사용자의 의지에 의해서 취소되는 기능이 아닌, 오퍼레이터의 정책에 의해서 일정 시간 후에 자동으로 취소되는 기능이다. CHAT REVOKE TIMER는 발신 클라이언트가 메세지 전송 후 delivery notification을 수신하기까지의 최대시간으로 provisioning 시 단말로 전송된다. 해당 타이머가 만료되면 발신 클라이언트는 자동으로 취소 메세지를 전송하게 되며 메세지 전송 취소가 성공적으로 완료되면 발신 클라이언트는 해당 메세지를 SMS등으로 전송할 수 있다. CHAT REVOKE TIMER 값이 0인 경우, 메세지 전송 취소 기능은 비활성화(disable)된다.
메세지 전송 취소는 착신 메세징 서버에서만 제어할 수 있다. 메세지 전송 취소 메세지를 수신한 착신 메세징 서버는 내부적으로 해당 메세지를 삭제한다. 메세지 전송 취소는 메세지의 전송이 완료되지 않은 상황에서만 가능하므로 다음의 경우 메세지 전송 취소요청은 실패한다.
- 착신 메세지가 SMS/MMS 로 interwokring 된 경우
- 착신 메세지에 대한 delivery notification을 착신 메세징 서버에서 이미 수신한 경우
- 착신 메세지가 착신자의 메세지 스토리지에 저장이 된 경우.
마치며.
RCS 5.2에 새로 추가된 기능 가운데 RCS Extension 은 최근 통신사의 니즈를 그대로 반영하고 있다. RCS가 상용서비스로 세상에 모습을 드러낸 지 1년 6개월이 지나고 있는 지금, 사용자들에게 그렇게 많은 반향을 일으키지 못하고 있고 초기 단계부터 RCSe 버전에 기반해 서비스를 제공하던 몇몇 오퍼레이터들의 시도도 사실상 실패로 끝나고 있기 때문이다. 무엇보다도 오퍼레이터들은 조인 서비스의 수익성에 대한 고민이 깊다. 아직까지 성공적인 조인서비스의 사례를 전세계적으로 찾아볼 수 없을 뿐더러 여러 글로벌 OTT 서비스들이 이미 통신산업의 신진세력이 되어 가고 있는 지금, 많은 오퍼레이터들이 RCS의 경쟁력에 대해 신뢰를 하고 있지 못하다. 이런 가운데, RCS Extension은 오퍼레이터로서 각자의 상황에 맞는 형태의 부가서비스를 마음껏 올릴 수 있도록 하는 길을 열어주고 있다. 오퍼레이터는 RCS의 기술과 RCS infrastructure를 이용하면서 자기만의 OTT와 같은 서비스를 가질 수 있으며 동시에 globally interoperable한 통신망을 통해 시장을 키워 나갈 수 있다. 물론, 이러한 달콤한 시나리오는 해당 서비스 또는 feature가 충분히 매력적임을 전제로 하지만 말이다.
파일 스토리지는 조금 특별한 의미를 가진다. OMA CPM 표준화 당시 메세지 스토리지와 파일 스토리지를 분리하기 위한, NSN과 Acision을 중심으로 한 몇몇 회사의 강력한 시도가 있었으나 다른 참여 회사들의 반대로 결국은 유야무야 되었다. 그 파일 스토리지가 다시 GSMA RCS에서 되살아 난 셈이다. 파일스토리지의 의미는 장기적으로 사용자의 컨텐츠를 모아 공유할 수 있는 서비스를 제공할 수 있는 토대를 만드는 것에 있어 보인다. 한국의 경우 다음의 마이피플이 이와 비슷한 시도를 했던 것으로 기억한다. 이를 테면 클라이드에 각 사용자들의 컨텐츠를 모으고, 그 콘텐츠들을 서로 공유하는 형태의 부가서비스를 생각해 볼 수 있다. 이미 3rd-party 사업자들 사이에서 많이 시도되고 있는 서비스이긴 하지만, 어쨌든 파일 스토리지를 통해 조인 서비스가 클라우드 기반 컨텐츠 서비스와 연계할 수 있는 가능성을 열어 놓은 것이 아닐까 하는 생각이다.
마지막으로 RCS 5.2에서는 메세지 스토리지에서 단말에 저장되어 있는 SMS/MMS를 동기화할 수 있는 기능을 보다 구체적으로 기술하고 있다. 미루어 짐작컨데, GSMA RCS에서 서로 다른 형태의 커뮤니케이션 서비스를 통합하고자 하는 노력이 지속적으로 이루어지고 있는 것으로 보인다. GSMA는 RCS blackbird에서 Integrated UX/UI를 통해 사용자 경험의 통합을 유도했고, RCS 5.x로 오면서 OMA CPM architectur를 도입함으로써 레가시 메세징 서비스의 기술적인 통합을 이루어냈다. RCS 5.2에서는 메세지 스토리지에서 레가시 메시지 동기화 알고리즘을 구체적으로 제공함으로써, 기존 메세징 서비스와 RCS의 통합을 보다 완전하게 하고 있다.
Red Mouse
