지난 4월 GSMA RCS-e 1.1이 나온 이후로 7개월만인 11월 RCS-e 1.2가 발행되었다. RCS-e 1.2의 경우 기능이나 서비스 측면에서 차이는 없으나, 다만 메세지를 처리하는 흐름에 영향을 줄 만한 요소 몇 가지가 있어 소개하고자 한다. 참고로, RCS-e 1.1과 RCS-e 1.2의 차이점에 대해서는 RCS-e 1.2의 ANNEX D. "Scope and summary of changes with respect to the previous version"에 정리되어 있다. 대부분은 RCS-e 1.1에서 언급은 되었으나 자세하 정의되지 않은 내용을 좀 더 상세화하는 내용에 해당하는 데 이 부분들은 본 포스팅에서는 제외되었다.
1. RLS 방식을 이용한 capability discovery 제거
RCS-e에서는 단말의 초기 등록 과정에서 RCS-e Client는 EAB의 각 contact에 대해 capability discovery 절차를 수행한다. RCS-e 1.1에서는 단말의 PRESENCE DISCOVERY가 1인 경우(단말이 presence기능을 이용한 capability discovery를 지원함을 의미), capability discovery 수행의 결과로 RCS-e 사용자라고 규명된 contact의 list(rcs list)를 Presence XDMS에 업로드 하고, 향후 서비스 과정에서 contact의 capability discovery를 수행하게 되는 경우 Presence의 RLS 방식을 이용한다. Presence의 RLS 방식에 의해 단말은 한 개의 Subscription/Notification 트랜젝션으로 RCS-e 사용자에 해당하면서 presence를 지원하는 contact들의 실시간 service capability를 알 수 있다.
반면 RCS-e 1.2에서는 이와 같은 RLS 방식이 삭제되었다. RLS 방식을 사용하지 않으므로 RCS-e Client는 초기 등록 과정에서 rcs list를 Presence XDMS에 업로드 하지 않으며 실시간 service capability를 알아야 하는 경우 anonymous fetch 기능을 이용해야 한다. 물론, Presence XDMS에서도 rcs list를 저장하는 기능은 제공되지 않는다.
RLS 기능이 RCS-e 1.2에 들어오면서 사라진 이유에 대해 몇 가지의 추론이 가능하겠으나, 개인적으로는 지금 단계에서 RLS를 사용하는 것에 대한 장점이 실제로는 크게 없었을 것 같다는 생각이 든다. RLS기능은 RCS-e 가입자 이면서 Presence 기능을 이용한 capability discovery를 지원하는 사용자가 많으면 많을 수록 트래픽을 절감할 수 있는 구조인데, 서비스 런치 후 초기 단계에서 서비스 가입자가 아직 많지 않을 것이기에, Presence의 복잡한 RLS기능을 굳이 구현해야 하는 가에 대한 문제제기가 있었을 수도 있겠다. 즉, 비용 효율적이지 않다는 것이다. 또 한편으로는 단말 및 서버에서의 복잡성의 증가를 그 이유로 들 수 있겠다. 단말의 contact list에서 RCS-e 가입자를 추리고 RCS-e 가입자 가운데 presence를 지원하는 contact를 추려서 해당 리스트를 SIP SUBSCRIBE의 body에 resource list의 형태로 encoding하여 전송해야 하는 과정이 필요하고, 서버에서도 back-end subscription을 처리할 수 있어야 한다. Back-end subscription 처리를 위한 트랜젝션 및 타이머의 관리, 단말로 Notification을 전송할 때 고려해야 하는 presence 데이타의 크기, Presence 정보를 제 때에 가져오지 못했을 경우의 데이타의 불일치 상황 등 고려해야 할 것들이 상당히 많아 지는 것이다. 이러한 복잡성은 다시 비용효율성이라는 이슈와 연관되어 있다.
2. 형상 데이타 추가
RCS-e 1.2에서는 다음의 두 개의 형상 데이타가 추가되었다.
DEVICE ID
단말에서 gruu 사용 시 기존에 IMEI 대신 UUID를 사용했던 것을 RCS-e 1.2에서는 DEVICE ID의 값에 따라 설정할 수 있게 되었다. 즉, DEVICE ID가 0인 경우 IMEI를 사용하고, 1인 경우 UUID를 사용한다.
IM START SESSION
착신 단말에서 응답 메세지를 전송하는 시점에 대해 기존에는 착신자가 응답 메세지를 작성하는 시점에 200 OK를 전송했으나 RCS-e 1.2에서는 IM START SESSION의 설정에 따라 시점을 달리 할 수 있게 되었다. 즉, 착신 메세지(SIP INVITE)에 대한 200OK를 전송하는 시점은 IM START SESSION이 '0'인 경우, Pop Up 창 터치 시, '1'인 경우 응답 메세지 작성 시, '2'인 경우 응답 메세지 작성을 완료하고 'send'버튼 터치시.로 정의된다.
3. End user confirmation
서비스 제공자가 종단 사용자의 답이 필요한 질의를 하게 되는 경우 SIP MESSAGE의 Contact Type을 application/end-user-confirmation-request+xml로 설정하여 전송한다. 착신 사용자는 SIP MESSAGE의 xml body를 통해 서비스 제공자가 필요로 하는 정보를 분석하고 그에 대한 답을 응답 메세지에 실어 서비스 제공자에게 전송한다. RCS-e1.1 의 경우 서비스 제공자로 전송되는 응답은 수신된 SIP MESSAGE에 대한 200 OK를 사용하거나 새로운 SIP MESSAGE를 사용하여 전송될 수 있었다. 그러나, RCS-e 1.2에서는 200 OK에 의한 응답 전송이 아닌 새로운 SIP MESSAGE만을 사용하도록 하고 있다. 서비스 제공자가 착신 Client의 동작을 제어하기 위해 사용되는 것이 'type' 파라미터인데, RCS-e 1.1과 RCS-e 1.2에서 다음과 같이 변경되었다.
RCS-e 1.1
|
RCS-e 1.2
|
|
type
|
Volatile: 응답 메시지를 200 OK응답에 전송. 응답을 전송하기 전에 time out이 나는 경우, 해당 메시지를 폐기
|
Volatile: 응답 메시지를 새로운 SIP MESSAGE응답에 전송. 응답을 전송하기 전에 time out이 나는 경우, 해당 메시지를 폐기
|
Persistent: 응답 메시지를 새로운 SIP MESSAGE로 전송. 메시지 time out 없음.
|
동일
|
종단 사용자에 대한 질의 메세지는 서비스 제공자가 종단 사용자의 identity를 확인하거나 서비스 약관등의 변경 사항에 대한 동의를 구하는 데에 매우 유용한 기능이다.
RCS-e 1.1에서 서비스 제공자가 type=volatile 로 설정하여 SIP MESSAGE를 전송했는데, 착신 사용자가 이에 대한 응답을 하지 않는 경우 해당 SIP MESSAGE에 대한 200 OK 응답이 발신측으로 전송되지 않기 때문에 불완전한 트랜젝션이 발생할 가능성이 있다. 이것은 물론, time out이 발생하여 다른 호처리에 영향을 미치지는 않지만, 효율적이지 않다는 의미이다. 또한 SIP MESSAGE를 전송하는 중간 노드가 Proxy가 아닌 B2BUA로 동작하도록 설계되어 있는 경우, 200 OK에 포함된 착신 사용자의 응답 메세지가 발신측까지 전달될 수 없으므로, 이 변경사항은 RCS-e 1.1에 대한 bug fix라고 볼 수 있다.
4. Initiating and Answering a Chat
RCS-e에서는 발신 Client가 SIP INVITE 전송 시 그 body에 사용자 메세지를 포함하도록 정의되어 있다. 원래 RCS-e 기술의 기반이 되고 있는 OMA SIMPLE IM에서는 SIP INVITE에 SDP 나 그룹 채팅을 위한 resource list외의 다른 정보가 실리지 않는 것을 감안하면 SIP INVITE의 body에 사용자 메세지를 담는 것은 RCS-e 고유의 방식이라 할 수 있겠다.
RCS-e의 SIP INVITE를 수신한 착신 단말은 해당 메세지의 body를 decoding하여 착신 사용자에게 보여주고 착신자가 답 메세지를 작성한다거나 하는 임의의 동작을 수행하는 경우 200 OK를 발신측으로 전송하여 MSRP 세션을 맺도록 하고 있다. RCS-e 1.1에서는 RCS-e 의 방식과 다른 경우, 즉 SIP INVITE의 body에 발신 사용자의 메세지가 실리지 않는 OMA SIMPLE IM 방식의 SIP INVITE 처리를 고려하지 않고 있으나, RCS-e 1.2로 오면서 이점에 대한 고려가 추가되었다. 즉, RCS-e Client는 수신된 SIP INVITE의 body에 사용자 메세지가 실리지 않아도 처리할 수 있어야 한다는 것이고, 이 경우 해당 메세지는 대화내역에 포함되지 않는다(SIP INVITE에 사용자 메세지가 없으니 대화내역으로 저장되지 않는 것은 당연해 보인다).
RCS-e 가 GSMA에서 고안한 새로운 방식의 IM 서비스를 제공하고는 있으나, SIP INVITE에 포함되는 feature tag도 같은 값(i.e., +g.oma.sip-im)으로 사용하는 마당에 기존 SIMPLE IM 기반 메세징 서비스와의 호환을 고려하지 않을 수 없었던 것으로 보인다.
이 밖에 RCS-e 1.2에서는 SIP INVITE에 대한 200 OK를 전송하는 시점을 IM START SESSION이라는 새로운 파라미터로 정의하고 있다.IM SESSION START 파라미터에 관해서는 위에 기술했으니 여기서는 생략한다. 다만, 참고로 IM START SESSION이 '2'인 경우 RCS-e Client는 해당 메세지를 버퍼에 잠시 저장해 놓았다가 세션 신호처리가 완료된 후 전송하게 된다.
5. 기타
이 밖에 그룹 채팅에서 RCS-e 1.1의 경우 실시간 capability discovery 절차를 수행하지 않으나, RCS-e 1.2에서는 capability discovery 절차를 수행하고 있다. 또한, 그룹 채팅을 위한 SIP INVITE 전달 시 RCS-e 1.1에서는 중간 노드가 모두 B2BUA로 동작하고 있으나, RCS-e 1.2의 경우 Proxy로 동작한다. 이는 기존 OMA SIMPLE IM에서 그룹 채팅을 위한 SIP INVITE를 Proxy로 처리하고 있기 때문에 이와의 호환을 고려한 것으로 보인다.
이상에서 살펴본 바와 같인 RCS-e 1.2는 RCS-e 1.1과 서비스 측면에서의 차이점은 없으나, 좀 더 현실적으로 time to market을 고려한 것으로 보인다(이동 통신사들이 얼마나 마음이 급할 지 가늠해 볼 수 있겠다). 복잡성을 유발할 수 있는 내용은 과감히 제거되었고 반면에 RCS-e Client나 서비스를 제어할 수 있는 방법은 좀 더 세분화되었다. 한편, OMA SIMPLE IM을 고려한 내용들이 다수 들어가 있는 것으로 보아, 나름대로 시장진입에 대한 고민이 있었던 것으로 보인다.
국내의 경우 2012년 1Q에 RCS-e 서비스가 이동 통신 3사에서 모두 동시에 제공될 것으로 보인다. 그러나, 이번엔 단말의 native client가 아닌 3rd-party application 형태로 제공될 예정이라 기존 카카오톡이나 요즘 뜨고 있는 틱톡등과 얼마나 경쟁할 수 있을지는 미지수다. 어쩌면 아마도 일종의 프로토타입 성격이 강하지 않을까 하는 생각이다. 처음부터 native client로 단말에 심어 서비스를 제공하는 위험을 부담하기 보다는 고객들의 반응을 우선 확인하고 좀 더 보완하여 궁극적으로는 애플의 iMessage 처럼 native client로 제공될 수 있을 것 같다.
References
-- Red Mouse
RCS-e 1.1에서 서비스 제공자가 type=volatile 로 설정하여 SIP MESSAGE를 전송했는데, 착신 사용자가 이에 대한 응답을 하지 않는 경우 해당 SIP MESSAGE에 대한 200 OK 응답이 발신측으로 전송되지 않기 때문에 불완전한 트랜젝션이 발생할 가능성이 있다. 이것은 물론, time out이 발생하여 다른 호처리에 영향을 미치지는 않지만, 효율적이지 않다는 의미이다. 또한 SIP MESSAGE를 전송하는 중간 노드가 Proxy가 아닌 B2BUA로 동작하도록 설계되어 있는 경우, 200 OK에 포함된 착신 사용자의 응답 메세지가 발신측까지 전달될 수 없으므로, 이 변경사항은 RCS-e 1.1에 대한 bug fix라고 볼 수 있다.
4. Initiating and Answering a Chat
RCS-e에서는 발신 Client가 SIP INVITE 전송 시 그 body에 사용자 메세지를 포함하도록 정의되어 있다. 원래 RCS-e 기술의 기반이 되고 있는 OMA SIMPLE IM에서는 SIP INVITE에 SDP 나 그룹 채팅을 위한 resource list외의 다른 정보가 실리지 않는 것을 감안하면 SIP INVITE의 body에 사용자 메세지를 담는 것은 RCS-e 고유의 방식이라 할 수 있겠다.
RCS-e의 SIP INVITE를 수신한 착신 단말은 해당 메세지의 body를 decoding하여 착신 사용자에게 보여주고 착신자가 답 메세지를 작성한다거나 하는 임의의 동작을 수행하는 경우 200 OK를 발신측으로 전송하여 MSRP 세션을 맺도록 하고 있다. RCS-e 1.1에서는 RCS-e 의 방식과 다른 경우, 즉 SIP INVITE의 body에 발신 사용자의 메세지가 실리지 않는 OMA SIMPLE IM 방식의 SIP INVITE 처리를 고려하지 않고 있으나, RCS-e 1.2로 오면서 이점에 대한 고려가 추가되었다. 즉, RCS-e Client는 수신된 SIP INVITE의 body에 사용자 메세지가 실리지 않아도 처리할 수 있어야 한다는 것이고, 이 경우 해당 메세지는 대화내역에 포함되지 않는다(SIP INVITE에 사용자 메세지가 없으니 대화내역으로 저장되지 않는 것은 당연해 보인다).
RCS-e 가 GSMA에서 고안한 새로운 방식의 IM 서비스를 제공하고는 있으나, SIP INVITE에 포함되는 feature tag도 같은 값(i.e., +g.oma.sip-im)으로 사용하는 마당에 기존 SIMPLE IM 기반 메세징 서비스와의 호환을 고려하지 않을 수 없었던 것으로 보인다.
이 밖에 RCS-e 1.2에서는 SIP INVITE에 대한 200 OK를 전송하는 시점을 IM START SESSION이라는 새로운 파라미터로 정의하고 있다.IM SESSION START 파라미터에 관해서는 위에 기술했으니 여기서는 생략한다. 다만, 참고로 IM START SESSION이 '2'인 경우 RCS-e Client는 해당 메세지를 버퍼에 잠시 저장해 놓았다가 세션 신호처리가 완료된 후 전송하게 된다.
5. 기타
이 밖에 그룹 채팅에서 RCS-e 1.1의 경우 실시간 capability discovery 절차를 수행하지 않으나, RCS-e 1.2에서는 capability discovery 절차를 수행하고 있다. 또한, 그룹 채팅을 위한 SIP INVITE 전달 시 RCS-e 1.1에서는 중간 노드가 모두 B2BUA로 동작하고 있으나, RCS-e 1.2의 경우 Proxy로 동작한다. 이는 기존 OMA SIMPLE IM에서 그룹 채팅을 위한 SIP INVITE를 Proxy로 처리하고 있기 때문에 이와의 호환을 고려한 것으로 보인다.
이상에서 살펴본 바와 같인 RCS-e 1.2는 RCS-e 1.1과 서비스 측면에서의 차이점은 없으나, 좀 더 현실적으로 time to market을 고려한 것으로 보인다(이동 통신사들이 얼마나 마음이 급할 지 가늠해 볼 수 있겠다). 복잡성을 유발할 수 있는 내용은 과감히 제거되었고 반면에 RCS-e Client나 서비스를 제어할 수 있는 방법은 좀 더 세분화되었다. 한편, OMA SIMPLE IM을 고려한 내용들이 다수 들어가 있는 것으로 보아, 나름대로 시장진입에 대한 고민이 있었던 것으로 보인다.
국내의 경우 2012년 1Q에 RCS-e 서비스가 이동 통신 3사에서 모두 동시에 제공될 것으로 보인다. 그러나, 이번엔 단말의 native client가 아닌 3rd-party application 형태로 제공될 예정이라 기존 카카오톡이나 요즘 뜨고 있는 틱톡등과 얼마나 경쟁할 수 있을지는 미지수다. 어쩌면 아마도 일종의 프로토타입 성격이 강하지 않을까 하는 생각이다. 처음부터 native client로 단말에 심어 서비스를 제공하는 위험을 부담하기 보다는 고객들의 반응을 우선 확인하고 좀 더 보완하여 궁극적으로는 애플의 iMessage 처럼 native client로 제공될 수 있을 것 같다.
References
[1] GSMA RCS-e v1.1, "RCS_e_Advanced_Comms_specification_v1_1_final", Apr.08.2011
[2] GSMA RCS-e v1.2, "rcs-e_advanced_comms_specification_v1.2", Nov.26.2011
-- Red Mouse
댓글 없음:
댓글 쓰기