Original topic:

Rich Communication Services (RCS) #GalaxyTechfluencer

(Topic created on: 04-03-2020 06:05 PM)
747 Views
Girishankar
Active Level 10
Options
Tech Talk
Rich Communication Services (RCS) is a communication protocol between mobile telephonecarriers and between phone and carrier, aiming at replacing SMS messages with a text-message system that is richer, provides phonebook polling (for service discovery), and can transmit in-call multimedia. It is part of broader IP Multimedia Subsystem.
image

RCS is a set of communication standards for SMS, MMS and calling that will make text messages look and feel more like dedicated messaging apps like WhatsApp, Telegram, Facebook Messenger, Google Hangouts and so many others. Basically, it aims to bring "texting" up to the modern standards with features we expect from messaging apps.

In 2007 a group of telecommunication industry companies founded the Rich Communication Suite industry initiative to use new technologies to create inter-operator communication services based on IMS (IP Multimedia Subsystem). Text messages and phone calls generally work well, but they're pretty bland and don't make use of the full capabilities of the network they're being sent on. They had three primary goals:

Use a better contacts list that included things like more information about your people, if they were available and if they have seen the message you've sent.

Build a better messaging system that enables extras like instant chat, emojis and sharing data between the people participating.

Support enhanced calls with features like video calling and data sharing in real time.

Encryption — RCS messages are not end-to-end encrypted. Messages are encrypted during transit from you to a service provider (whether it be Google or a carrier) and from the provider to the destination, but the provider does have access. Google says messages will be deleted once they are received, but attachments may be held until all recipients have downloaded them. End-to-end encryption is something that can be added to RCS, but until that happens, you need to know that the service provider will have access to your messages.


 Graphics Interchange Format (GIF /dʒɪf/ JIF or /ɡɪf/ GHIF) is a bitmap image format that was developed by a team at the online services provider CompuServe led by American computer scientist Steve Wilhite on June 15, 1987.[1] It has since come into widespread usage on the World Wide Web due to its wide support and portability between applications and operating systems.

The format supports up to 8 bits per pixel for each image, allowing a single image to reference its own palette of up to 256 different colors chosen from the 24-bit RGB color space. It also supports animationsand allows a separate palette of up to 256 colors for each frame. These palette limitations make GIF less suitable for reproducing color photographs and other images with color gradients, but it is well-suited for simpler images such as graphics or logos with solid areas of color. Unlike video, the GIF file format does not support audio.

GIF images are compressed using the Lempel–Ziv–Welch (LZW) lossless data compression technique to reduce the file size without degrading the visual quality. This compression technique was patented in 1985. Controversy over the licensing agreement between the software patent holder, Unisys, and CompuServe in 1994 spurred the development of the Portable Network Graphics (PNG) standard. By 2004 all the relevant patents had expired.

File formatEdit


image


File:Empty.gif in a hex editor

Conceptually, a GIF file describes a fixed-sized graphical area (the "logical screen") populated with zero or more "images". Many GIF files have a single image that fills the entire logical screen. Others divide the logical screen into separate sub-images. The images may also function as animation frames in an animated GIF file, but again these need not fill the entire logical screen.

GIF files start with a fixed-length header ("GIF87a" or "GIF89a") giving the version, followed by a fixed-length Logical Screen Descriptor giving the pixel dimensions and other characteristics of the logical screen. The screen descriptor may also specify the presence and size of a Global Color Table, which follows next if present.

00000000 47 49 46 38 39 61 01 00 01 00 80 00 00 00 00 00 |GIF89a..........| 00000010 ff ff ff 21 f9 04 01 00 00 00 00 2c 00 00 00 00 |...!.......,....| 00000020 01 00 01 00 00 02 01 44 00 3b |.......D.;| 0000002a

Thereafter, the file is divided into segments, each introduced by a 1-byte sentinel:

An image (introduced by 0x2C, an ASCII comma ',')

An extension block (introduced by 0x21, an ASCII exclamation point '!')

The trailer (a single byte of value 0x3B, an ASCII semicolon ';'), which should be the last byte of the file.

An image starts with a fixed-length Image Descriptor, which may specify the presence and size of a Local Color Table (which follows next if present). The image data follows: one byte giving the bit width of the unencoded symbols (which must be at least 2 bits wide, even for bi-color images), followed by a linked list of sub-blocks containing the LZW-encoded data.

Extension blocks (blocks that "extend" the 87a definition via a mechanism already defined in the 87a spec) consist of the sentinel, an additional byte specifying the type of extension, and a linked list of sub-blocks with the extension data. Extension blocks that modify an image (like the Graphic Control Extension that specifies the optional animation delay time and optional transparent background color) must immediately precede the segment with the image they refer to.

The linked lists used by the image data and the extension blocks consist of series of sub-blocks, each sub-block beginning with a byte giving the number of subsequent data bytes in the sub-block (1 to 255). The series of sub-blocks is terminated by an empty sub-block (a 0 byte).

This structure allows the file to be parsed even if not all parts are understood. A GIF marked 87a may contain extension blocks; the intent is that a decoder can read and display the file without the features covered in extensions it does not understand.

The full detail of the file format is covered in the GIF specification.[2]

0 Comments