한국어

네트워킹

온누리070 플레이스토어 다운로드
    acrobits softphone
     온누리 070 카카오 프러스 친구추가온누리 070 카카오 프러스 친구추가친추
     카카오톡 채팅 상담 카카오톡 채팅 상담카톡
    
     라인상담
     라인으로 공유

     페북공유

   ◎위챗 : speedseoul


  
     PAYPAL
     
     PRICE
     

pixel.gif

    before pay call 0088 from app


http://hongjoo71.blogspot.com/2011/10/gsma-rcs-e-v11-summary.html

GSMA RCS-e v1.1

전 세계의 다양한 이동 통신사업자와 글로벌 단말 제조업체 및 솔루션 업체들이 참여하고 있는 국제 표준화 단체인 GSMA에서는 지난 2008년부터 RCE(RIch Communication Ecosystem)라는 프로젝트를 통해 이동 통신의 고유영역인 통신서비스에 대한 표준을 만들어 오고 있다. 현재까지 제정된 RCS release 4 까지의 산출물은 OMA와 같은 다른 국제 표준 단체에 의해 이미 제정된 관련 기술들을 채택하고 조합하는 방식으로 이루어지고 있으며, 각 릴리즈 버전별로 지속적인 업그레이드가 이루어지고 있다.

그러나, 최근 몇 년간의 스마트폰의 보급과 함께 봇물처럼 쏟아지고 있는 mVoIP를 포함한 통신서비스를 제공하는 제3의 응용 서비스들은 이동통신사들로 하여금 Time to market에 대한 니즈를 가속화 시켰으며 이에 대한 대응으로 GSMA RCE에서도 기존의 RCS 릴리즈와는 별개로 time to market을 고려한 RCS-e 규격을 제정하게 되었다.

본 포스팅은 지난 2011년 4월에 발행된 RCS-e v1.1 규격을 정리한다.


1. 개요
RCS-e 규격의 정식명칭은 RCS-e Advanced Communications로서 주요 기능 및 범위는 RCS R2를 기반으로 하고 있다. 그러나 RCS R2의 모든 기능을 포괄하는 것은 아니며, time to market과 이동통신 사업자간의 상호운영성을 고려하여 몇몇 기능들은 수정되었고 RCS R2에는 없던 기능들도 다소 포함되었다. 그 개념도는 다음과 같다.




위 그림에서 보여주듯, RCS-e의 주요 서비스는 메세징, 파일전송, 이미지 및 비디오 공유 서비스로 구성된다. 소셜 프로파일 정보 관련 서비스는 Optional로 제공되도록 하고 있으며, RCS R2와 비교하여 추가되거나 변경된 기능은 다음과 같다.

  • Store and Forward
  • "displayed" Message Disposition
  • local black list
  • Conversation History
  • User Alias
  • Multiple Devices
  • Message Identification within SIP INVITE
  • Auto-acceptance of store and forward IM Server PUSH of stored notifications
  • IMDN


2. 초기화 절차
RCS-e 서비스의 절차는 서비스 및 형상 데이타 전송(Configuration Provisioning), 등록(Registration), 단말 및 사용자 정보 확인(Capability Discovery)으로 크게 세 단계로 나눌 수 있다. 사용자가 RCS-e 서비스를 사용할 수 있기 위해서는 IMS망과 RCS-e 클라이언트에 해당 사용자가 서비스에 접근하는 데 필요한 데이타가 이미 등록되어 있음을 전제로 한다. 즉, RCS-e 서버는 단말의 최초 등록을 감지하고 서비스에 필요한 데이타를 RCS-e 클라이언트와 IMS망의 필요한 Entity에 내려줄 수 있어야 한다. 이 절차는 백그라운드로 동작하여 사용자는 인지하지 못해야 한다. 한편, 등록절차는 다시 최초 등록(First time registration)과 일반 등록(Normal registration) 절차로 구분된다. 최초 등록은 주소록 상의 각 contact가 RCS-e 사용자인지를 확인하는 절차을 동반한다는 측면에서 일반등록과 구분된다.

다음은 이러한 절차를 보여주며, 각 절차에 대한 자세한 내용은 다음 하위절에서 설명한다.



2-1. 등록 절차
등록절차는 단말에 설치된 RCS-e 클라이언트가 기동하면서 RCS-e 네트웍(i.e., IMS)에 접속하는 과정을 의미한다. 세부적인 절차는 MNO마다 다를 수 있어 구체적인 제한을 두고 있지 않으나 그 인증방식에 대해서는 다음의 세 가지 형태를 지원할 것을 권고하고 있다.


재등록 절차는 통상적인 SIP 등록 절차와 동일하게 처리된다[RFC3261]. 단, 꼭 필요한 경우 이외의 재등록 절차는 생략된다.

등록절차를 완료한 RCS-e 클라이언트가 Presence 메카니즘을 지원하는 경우, 자신의 communication capability 정보를 프레즌스 서버에 등록하는 절차를 수행한다. 이 과정은 Presentity가 자신의 상태를 Publication하는 통상적인 프레즌스 절차를 따르며, 그 흐름도는 다음과 같다.






2-2. 서비스 및 형상 데이타 전송
RCS-e 서비스를 제공하는 망은 RCS-e 클라이언트의 최초 접속을 인지할 수 있어야 하며 어느 Entity가 어떻게 인지하는 지에 관한 내용은 RCS-e v1.1에는 언급되어 있지 않으므로, 각 망 사업자의 구현이슈로 간주된다. RCS-e 클라이언트를 탑재한 단말의 접속을 인지한 망은 서비스 제공을 위해 필요한 망 내의 entity 및 단말로 서비스 및 형상 데이타를 전송한다. 사용자 경험을 위해 이 절차는 사용자에게 노출되지 않아야 한다.

RCS-e v1.1에서 정의한 서비스 및 형상 데이타는 다음과 같다.


서비스 및 형상 데이타를 전송하는 방식은 통상 OMA DS(Data Synch)나 OMA CP(Contents Provisioning) 방법을 사용할 수 있으나 RCS-e 에서는 별도의 configuration server를 두고 HTTP(S)를 이용해 전송하는 방식도 사용할 수 있음을 배제하지 않고 있다. 즉, Time To Market을 고려하여 망 상황에 따라 접근하기 쉬운 방법을 선택할 수 있도록 되어 있다.

단말의 SIM 카드의 교체나 단말의 리셋이 실행되는 경우 형상 데이타를 안전하게 백업할 수 있어야 한다. 이는 원래의 SIM 카드가 다시 사용되는 경우 해당 SIM카드에 저장되어 있는 Identity에 대한 형상 데이타를 다시 사용할 수 있도록 하기 위해서이다.

본 절차는 단말의 IMS Identity(i.e., TEL-URI, SIP-URI)가 변경되지 않는 이상 반복되지 않는다.

2-3. 단말 및 사용자 정보 확인
RCS-e 클라이언트는 최초 등록시 주소록에 등록되어 있는 각 contact에 대해 RCS-e 사용자 여부 및 각 contact의 device capability를 확인한다. 이를 위해 단말간 SIP OPTIONS 가 사용된다. RCS-e 에서는 device capability를 위해 각 service feature에 대한 별도의 feature tag를 다음과 같이 정의하고 있다.


NOTE  실제 서비스 흐름(i.e., SIP INVITE)에서 IM/Chat과 FIle Transfer의 경우 +g.oma.sip-im을 공통으로 사용할 수도 있으나 이를 구분하고자 하는 경우 위에 정의된 feature tag가 사용될 수 있다.

위 표에서도 알 수 있듯이, RCS-e 클라이언트의 주요 기능은 메세징(IM/Chat), 파일전송, 이미지 및 비디오 공유라고 할 수 있다. 또한, 선택적으로 소셜 프레즌스 정보 교환 기능이 제공될 수 있다. 각 기능에 대한 세부 내용은 다음 장에 기술하기로 한다. 다음은 RCS-e 클라이언트의 capability를 결정할 수 있는 몇 가지 경우의 수를 나열한다.

  • MNO가 특정 서비스를 지원하지 않거나 허용하지 않는 경우
  • 단말의 HW가 저사양인 경우
  • 단말의 상태가 특정 서비스를 임시로 수용할 수 없는 경우(e.g., 용량초과)
  • 망 연결 상태 또는 연결된 망의 capability
  • IM/Chat 서비스는 조건과 관계 없이 제공된다.

이와 더불어, RCS-e 에서는 Store and Forward 기능을 지원한다. Store and Forward는 착신단말이 메세지를 수신할 수 없는 경우 메세지를 임시로 서버에 저장했다가(deferred) 향후 착신 단말이 등록되었을 때 이를 감지하고 착신시켜주는 메카니즘을 말한다.

3. 세부 기능
3-1.  단말 정보 획득(Device Capability Discovery)
단말 정보 획득 기능은 주소록에 있는 각 contact의 단말 정보를 획득하는 기능으로써 다음과 같은 상황에서 수행된다.
  • 최초 등록시 주소록의 각 contact에 대한 등록상태와 default capabilities를 획득
  • 주소록 변경시
    • 주소록에 새로운 contact이 추가된 경우
    • contact의 primary MSISDN이 변경되거나 새로운 MSISDN이 추가된 경우
  • 실시간 확인
    • 특정 contact와 communication하기 위해 해당 contact의 가용한 RCS-e service capability 확인(e.g., call, IM/Chat)이 필요한 경우.
    • Voice call, IM, File transfer 수행 도중 상대방의 가용한 communication capability 변경 시.
    • Communication event(e.g., text, email, call, IM, etc) 발생 시.
  • POLLING PERIOD에 정의된 주기에 따라 주소록에서 communication capability가 획인이 안된 contact을 대상으로 수행

NOTE  이미 communication capability discovery 절차가 수행된 지 얼마 안된 경우엔 생략 가능하다.

단말 정보 획득 절차
단말 정보를 획득하는 방법은 단말의 Capability에 따라 다음과 같다.

1) SIP OPTIONS
2) Presence 

1)의 경우 watcher가 되는 단말은 주소록의 모든 contact에 대해 각각 SIP OPTIONS를 교환한다. 2)의 경우 Presence 메카니즘을 재사용하므로 watcher와 Presence Server의 RLS간에 한번의 트랜젝션으로 복수 contact의 device capability를 확인할 수 있다. 다만, 후자의 경우, 각 contact가 Presence capability가 있음을 알아야 하므로, 각 contact에 대해 최소한 한 번은 1)의 방법을 사용해야 한다. 

최초  SIP OPTIONS를 통해 획득한 contact의 feature tag가 "Capability discovery via Presence"를 지원하는 경우, 이후 부터 해당 contact에 대한 capability discovery는 presence를 통해 수행된다. 또한, 자신의 device capability 정보를 공개하는 presentity가 되는 단말은 anonymous subscription을 지원해야 한다. 이에 대한 흐름도는 다음과 같다.


Presence를 지원하는 contact의 목록은 watcher 사용자의 XDMS에 저장된다.

NOTE  단말이 Anonymous subscription을 지원해야 하는 이유는 RCS-e에 명시되지는 않았으나, Presentity 단말의 입장에서 상대방이 해당 단말의 주소록에 등록되지 않은 contact일 수도 있기 때문일 것으로 판단된다.


RCS-e 사용자 확인
SIP OPTIONS의 응답으로 RCS-e IM service feature tag를 수신한 경우 해당 contact이 RCS-e 사용자 인것으로 간주한다. 실패 응답의 경우는 다음과 같이 처리한다.
  • 480 Temporarily Unavailable - 변화 없음
  • 408 Request TImeout - 변화 없음
  • 404 Not Found - non-RCS-e 사용자

Capability Polling
주소록에 있는 contact에 대한 device capability정보는 상황에 따라 주기적으로 또는 실시간으로 획득되는데, 다음은 주기적으로 획득되는 경우에 해당한다.
  • non-RCS-e 사용자
  • RCS-e 사용자이나 capability 정보가 없는 경우
  • Capability 정보 유효시간 만료


3-2.  메세징(IM/Chat)
RCS-e에서는 Pager Mode 메세징을 지원하지 않는 대신, 해당 기능을 세션 기능과 통합시킨 것이 특징이다. 즉, RCS-e 클라이언트는 세션 기반 메세징(IM/Chat)을 전송하기 위해 SIP INVITE를 착신측으로 전송하게 되는데, 이때 SIP INVITE 내에 CPIM body를 포함해 보내고자 하는 메세지를 실어 보내게 된다. 즉, 발신자 입장에서는 대화창을 열어 메세지를 입력하고 'send'를 누르는 순간에 SIP INVITE가 첫번째 메세지(payload)와 함께 전송되는 것이다. 착신단말의 입장에서는 SIP INVITE를 수신하는 순간 발신측으로 부터 전송된 첫번째 메세지를 확인하게 된다. 착신자가 수신된 메세지의 팝업을 터치하는 순간 대화창이 열리며, 이와 동시에 발신측으로는 200 OK가 전송되어 IM/Chat을 할 수 있는 세션이 열리게 된다. 그러므로 착신자가 무응답인 상태에서 발신자가 계속 메세지를 보내게 되면 SIP INVITE가 그만큼 여러개 전송되는 셈이다. 종단간 세션이 맺어진 후의 메세지는 MSRP를 통해 전송된다. 다음은 이에 대한 흐름도를 도시한다.





IMDN 전송
RCS-e에서는 'delivered'와 'displayed' notification을 지원한다. RCS-e에서는 SIP INVITE가 payload를 포함하고 있으므로 이에 대한 delivered notification이 전송되어야 하며, 이를 위해 SIP MESSAGE를 사용한다. 세션이 수립된 상태에서 delivered notification이 전송되는 경우 MSRP SEND를 사용한다. 반면에 Displayed notification은 착신자가 메세지 확인을 위해 화면상의 팝업을 터치하여 대화창을 열었음을 의미하므로 MSRP 세션이 성립된 후에만 전송된다. 따라서, displayed notification 전송은 항상 MSRP SEND를 사용한다.

세션 확장
사용자는 1-1 IM/Chat을 Group IM/Chat으로 확장할 수 있다. 이때, 세션확장을 요청하는 단말은 세션에 참여할 각 contact가 이 기능을 지원하는지를 SIP OPTIONS를 통해 확인한다. UI 관점에서 원래 세션에 참여했던 참여자는 세션의 확장과 관계없이 동일한 대화창을 사용할 수 있어야 한다.

그룹 IM/Chat
RCS-e 단말에게는 서비스 초기화 시 conference factory uri 값이 provisioning된다. 사용자는 단말의 RCS-e 주소록에서 Ad-hoc 형태로 그룹 IM/Chat 세션을 생성할 수 있고 RCS-e 클라이언트는 SIP INVITE 전송 시 저장된 conference factory uri값을 사용한다. 그룹 IM/Chat 세션을 생성하는 과정에서 별도의 capability discovery 절차는 생략되며, IMDN도 전송되지 않는다. 이후 각 착신자의 수락/거부 과정을 거쳐 그룹세션이 생성되면 각 RCS-e 클라이언트는 conference event package를 서버에 요청하여 참여자의 정보를 확인할 수 있다. 그룹 IM/Chat 요청은 store and forward 되지 않는다. 그룹 IM/Chat 서비스는 RCS-e 클라이언트가 초기화 과정에서 conference factory의 uri를 provisioning 받아야 하므로 RCS-e 사용자가 아닌 경우 참여할 수 없다.

그룹 세션에 참여한 각 참여자는 다른 참여자를 초대할 수도 있고 해당 세션을 종료할 수 있다. 그룹 세션은 서비스 정책에 따라 최소인원을 만족하지 않는 상태에 도달하면 해당 세션이 종료된다.


3-3.  지연 메세지 처리(Store and Forward)
착신 단말이 메세지를 수신할 수 없는 경우 해당 메세지는 RCS-e 서버에 임시로 저장되고, 향후에 해당 단말이 서비스에 접속하면 저장된 메세지를 꺼내어 착신시키는 절차를 의미한다.

Store and Forward 기능은 서버는 Optional이고 단말은 mandatory이므로, configuration provisioning 단계에서 본 기능을 단말에서 지원해야 하는 지를 클라이언트에게 알려준다.

Store and forward 기능은 원칙적으로 착신측 RCS-e 서버가 처리하도록 정의한다. 그러나, 착신 RCS-e 서버가 해당 서비스를 지원할 수 없는 경우, 발신측 RCS-e 서버가 이를 처리할 수 있어야 한다. 또한, Store and forward 기능은 사용자 메세지 뿐만이 아니라, IMDN에도 동일하게 적용된다.

메세지가 store and forward로 착신되는 경우 RCS-e 서버는 P-Asserted-Identity 헤더에 store and forward feature tag("standfw@operator.com")를 설정하여 전송하고, store and forward 메세지를 수신한 단말은 사용자와의 interaction없이 자동으로 이 메세지를 수락할 수 있어야 한다.


3-4.  복수 단말 처리(Multiple devices)
사용자의 복수단말 처리를 위해 GRUU 메카니즘을 이용한다. 단말에서 GRUU를 획득하는 절차는 IMS에 정의된 절차를 그대로 따른다.

사용자가 한 개 이상의 단말을 등록한 경우 RCS-e 서버는 이를 처리할 수 있어야 한다. 복수 단말에게 전송된 IM/Chat 메세지(SIP INVITE)는 [RFC3261]에 정의된 통상적인 절차에 따라 IMS망에서 forking하고 궁극적으로 하나의 착신단말과 세션을 맺는다.

SIP INVITE에 대한 IMDN 전송 시 발신측이 복수 단말인 경우 해당 INVITE 메세지를 전송한 특정 단말에게만 IMDN 전송될 수 있어야 한다. 착신측이 복수 단말인 경우 발신측으로는 한 개 이상의 IMDN이 전송될 수 있는데, 이를 수신하는 단말은 최초 수신된 IMDN이외의 IMDN은 무시한다.

마지막으로 SIP OPTIONS 처리 시 착신측이 복수단말인 경우라 하더라도 발신측으로는 한 개의 200 OK만 전송되어야 하므로 SIP OPTIONS를 처리하는 중간 노드에서 복수단말로부터 수신되는 여러 개의 200 OK를 하나로 취합하여 전송하는 기능이 요구된다.

Device Switching
RCS-e 서비스에서는 복수단말을 가진 사용자가 서비스 도중 단말을 교체할 수 있는 기능을 제공한다.

착신자의 active 단말이 어떠한 이유로 de-active되어 RCS-e 서버가 메세지를 전송할 수 없는 경우, RCS-e 서버는 착신자의 등록된 다른 단말로 SIP INVITE를 전송하여 세션을 맺은 후 아직 전송되지 못했던 나머지 메세지를 전송한다.

사용자가 IM/Chat 도중 단말을 바꿔 메세지를 발신하는 경우, RCS-e 서버는 이를 감지하여 해당 사용자의 기존 단말과는 세션을 종료하고 새로운 단말과의 세션을 맺어 서비스를 지속한다. 단, 기존 단말에게 전송될 IMDN이 남아 있는 경우 IMDN 전송을 모두 마무리한 후 세션을 종료할 수 있어야 한다.


3-5. 파일 전송(FIle Transfer)
RCS-e의 파일전송은 RCS R2의 기술을 그대로 적용한다. UI/UX 관점에서 파일전송은 채팅창과 통합되어 제공되지만 세션은 독립적으로 동작한다. 파일전송은 일방향 전송이므로 착신측이 파일전송에 대한 응답 메세지(payload)를 전송하지 않는 한 IM/Chat 세션은 열리지 않는다.

파일전송 요청시 해당 파일의 크기와 타입을 착신자가 알 수 있어야 한다. 착신자는 주어진 정보를 참고로 해당 요청을 수락/거부 할 수 있다.

다음은 파일전송이 오류가 발생하는 경우를 나열한다.

  • 사용자의 명시적 취소
  • 망과의 연결 단절
  • 단말의 저장 공간 부족
  • 단말에서의 service capability 미지원


3-6. 비디오/이미지 공유(Video/Image Share)

RCS-e 단말은 서비스 초기화 과정에서 상대 contact이 Video/Image Share 기능을 가지는 지를 확인할 수 있다. VIdeo/Image Share의 미디어는 단방향으로 전송되며 기존 세션과는 독립된 별개의 세션을 사용된다. 스트림은 각각 RTP와 MSRP를 사용하며 H.264/MPEG-4 Part 10/AVC(Advanced Video Coding)을 지원한다. RCS-e의 Video/Image Share는 [IR.74]와의 역호환성을 지원하며 동시에 LTE를 지원한다. 다만, LTE에서 어떻게 Video Share를 구현할 것인지에 대한 내용은 아직 논의중이다. RCS-e에서의 Video/Image Share는 1-1 CS call 상태에서만 사용이 가능하며 1-1 CS call이 multiparty call로 전환하는 경우 SIP OPTIONS를 이용해 capability 정보를 갱신하고 Video/Image Share 서비스를 더 이상 사용할 수 없음을 사용자에게 알린 후 서비스를 종료한다. 그 밖에 CS call 상태에서 통화 중 대기로 전환하는 경우 Video/Image Share 서비스를 사용할 수 없게 된다. 이를 정리하면 Video/Image Share 서비스가 동작하기 위한 조건은 다음과 같다.
  • 종단간 active CS call 세션이 존재
  • CS call은 다자간 통화나 통화 중 대기 상태가 아님.
  • Call forward나 Call Divert 상황이 아님.


3-7. 기타
RCS-e서비스는 추가적으로 이모티콘이나 스팸필터 기능을 지원할 수 있다.


4.  정리
여기서는 지금까지 본문에서 다뤄진 RCS-e 표준의 내용들을 기반으로 그 특징들을 간략하게 정리하고자 한다.


페이저 메세징과 세션 메세징의 통합
RCS-e 의 가장 큰 변화는 기존 IM에서 별개로 제공하던 pager mode 와 session mode 메세징을 하나로 통합했다는 것이다. 이는 사용자 경험측면에서 사용자가 상대방에게 SMS/MMS를 전송할 지 채팅을 요청할 지를 구분하지 않도록 하겠다는 것과 같은 맥락이라고 생각된다. 사용자의 행동은 '메세지 전송 요청'인 것 뿐이라는 것이다. 일면 국내에서 서비스되고 있는 카카오톡 서비스가 떠오른다. 지금까지 카카오톡 서비스는 페이저 메세징을 구현하고 사용자의 UI를 세션기반으로 제공하여 사용자 관점에서 사실상 페이저와 세션의 구분없는 통합된 형태의 메세징 서비스를 제공하고 있다.
(이러한 변화에 대한 개인의 의견은 별도의 포스팅에서 언급하려고 한다)

메세지 전송성공률 극대화
RCS-e 에서는 store and forward 및 multiple device 지원 기능을 통해 발신자를 떠난 메세지가 반드시 착신자에게로 전송될 수 있도록 하고 있다. 망이나 서비스의 중간 노드의 오류로 메세지가 유실되는 상황이 아니라면 착신자가 해당 발신자를 block 하지 않는 한 메세지는 반드시 전송될 것이다. 사실, 이 기능은 OMA의 SIMPLE IM이나 OMA CPM에서도 'deferred message'의 형태로 제공되는 기능이긴 하지만, RCS-e 의 경우 다른 Enabler와는 달리 의도적이든 비의도적이든 착신자로 하여금 사용자 설정을 이용하여 착신 메세지 처리 방법을 다양하게 할 수 있는 옵션을 제공하고 있지 않기 떄문에 착신자에게 전송된 메세지는 지극히 예외적인 상황을 제외하고는 모두 전송될 것으로 보인다.

부가 서비스 제공
RCS-e에서는 비디오 및 이미지 공유 서비스, 이모티콘 전송 등과 같은 부가 서비스를 제공한다. 사용자들이 비디오 및 이미지 공유와 같은 서비스에 얼마나 열광할 지는 모르겠지만 어쨌든 기존의 단순한 테스트 기반의 커뮤니케이션에 나름의 임팩트를 주고 싶었는지도 모르겠다.

복수 단말 지원
사용자의 복수단말 지원기능은 OMA CPM에도 있는 기능이나 RCS-e에서는 이를 매우 단순하게 접근하였다. OMA CPM에서 사용자가 복수 단말을 하나 하나 제어할 수 있도록 하는 여러가지 옵션들을 사용자 설정을 통해 제공했다면 RCS-e에서는 복수단말을 제어하는 IMS의 고유기능을 그대로 이용하고 있다. 다만, SIP OPTIONS 처리라든지 IMDN 처리 같은 측면에서 어느정도 사용자 경험을 고려한 것으로 보인다. Device switching 기능이 들어가 있는 것이 눈에 띄는데 이 기능은 기존에 Nateon이나 MSN 이 동시에 두 개의 단말에서 메신저에 로그인 하는 기능을 막아놓았던 것과 같은 동일한 기능이라고 보여진다. 서로 다른 단말간의 seemless한 서비스 연속성을 제공하는 것은 아니라는 것이다.

현재 이동통신 3사에서는 오는 2012년 상반기까지 RCS-e v1.1 기준의 메세징 서비스를 제공하고자 자체적으로 준비하고 있다. TTA에서는 이동통신 3사를 중심으로 RCS 실무반(PG7035)을 꾸려 이동 통신 3사간의 연동 규격을 제정하고 있다. 현재까지 0.9버전까지 만들어졌으며 향후 올해 말이나 2012년 1Q쯤 IOT를 거쳐 1.0 버전을 내 놓을 계획이다.


내년에 출시될 이동통신 3사의 RCS-e 클라이언트도 iMessage 처럼 단말에 native app 형태로 제공된다고 하니 내년 이맘때쯤 통신시장이 향후 어떻게 전개되어 있을지 궁금해진다.



조회 수 :
86518
등록일 :
2012.05.07
22:38:33 (*.160.42.233)
엮인글 :
http://webs.co.kr/index.php?document_srl=5067&act=trackback&key=f5a
게시글 주소 :
http://webs.co.kr/index.php?document_srl=5067
List of Articles