Thursday, March 30, 2017
Monday, March 27, 2017
Android FCM what is notification message and data message?
To send notification messages, set the notification key with the necessary predefined set of key options for the user-visible part of the notification message. For example, here is a JSON-formatted notification message in an IM app. The user can expect to see a message with the title "Portugal vs. Denmark" and text "great match!" on the device:
{
"to" : "bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification" : {
"body" : "great match!",
"title" : "Portugal vs. Denmark",
"icon" : "myicon"
}
}
Notification messages are delivered to the notification tray when the app is in the background. For apps in the foreground, messages are handled by these callbacks:
didReceiveRemoteNotification: on iOS
onMessageReceived() on Android. The notification key in the data bundle contains the notification.
See notification payload support for the full list of predefined keys available for building notification messages.
Data messages
Set the data key with your custom key-value pairs to send a data payload to the client app. Data messages can have a 4KB maximum payload.
For example, here is a JSON-formatted message in the same IM app as above, where the information is encapsulated in the data key and the client app is expected to interpret the content:
{
"to" : "bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"data" : {
"Nick" : "Mario",
"body" : "great match!",
"Room" : "PortugalVSDenmark"
},
}
On iOS, FCM stores the message and delivers it only when the app is in the foreground and has established a FCM connection. On Android, a client app receives a data message in onMessageReceived() and can handle the key-value pairs accordingly.
Note these further platform-specific details:
On Android, the data payload can be retrieved in the Intent used to launch your activity.
On iOS, the data payload is found in didReceiveRemoteNotification:.
{
"to" : "bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification" : {
"body" : "great match!",
"title" : "Portugal vs. Denmark",
"icon" : "myicon"
}
}
Notification messages are delivered to the notification tray when the app is in the background. For apps in the foreground, messages are handled by these callbacks:
didReceiveRemoteNotification: on iOS
onMessageReceived() on Android. The notification key in the data bundle contains the notification.
See notification payload support for the full list of predefined keys available for building notification messages.
Data messages
Set the data key with your custom key-value pairs to send a data payload to the client app. Data messages can have a 4KB maximum payload.
For example, here is a JSON-formatted message in the same IM app as above, where the information is encapsulated in the data key and the client app is expected to interpret the content:
{
"to" : "bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"data" : {
"Nick" : "Mario",
"body" : "great match!",
"Room" : "PortugalVSDenmark"
},
}
On iOS, FCM stores the message and delivers it only when the app is in the foreground and has established a FCM connection. On Android, a client app receives a data message in onMessageReceived() and can handle the key-value pairs accordingly.
Note these further platform-specific details:
On Android, the data payload can be retrieved in the Intent used to launch your activity.
On iOS, the data payload is found in didReceiveRemoteNotification:.
AMR Compilation on Linphone - Which all files getting compiled?
Linphone AMR NB compilation, which files are getting built along as we compile the library?
Well, here are they ... We can see in the build log that is generated.
0%] codecs/amrnb/amrnb/wrapper.cpp.o
[ 1%] codecs/amrnb/opencore/codecs_v2/audio/gsm_amr/amr_nb/common/src/add.cpp.o
[ 1%] codecs/amrnb/opencore/codecs_v2/audio/gsm_amr/amr_nb/common/src/az_lsp.cpp.o
[ 2%] codecs/amrnb/opencore/codecs_v2/audio/gsm_amr/amr_nb/common/src/bitno_tab.cpp.o
[ 3%] codecs/amrnb/opencore/codecs_v2/audio/gsm_amr/amr_nb/common/src/bitreorder_tab.cpp.o
[ 3%] codecs/amrnb/opencore/codecs_v2/audio/gsm_amr/amr_nb/common/src/c2_9pf_tab.cpp.o
--
---
--
---
[100%] Linking CXX static library libopencore-amrnb.a
Friday, March 24, 2017
AMR vs Opus & AAC
The AMR-WB (AMR Wideband) codec is the de facto standard for HD voice in the cellular arena. It has been turned up in over 50 3G networks (and growing) and is the standard codec for Voice over LTE (VoLTE). However, onerous licensing issues for software developers are limiting its proliferation beyond cell phones and mobile networks, opening the way for the open-source Opus codec and Fraunhofer's "Full HD voice" AAC codec.
Patents for AMR-WB are held by Ericsson, France Telecom/Orange Nokia and VoiceAge. A patent pool -- basically, a one-stop place to license the patents -- for AMR-WB device usage was announced in 2009. Managed by VoiceAge, the licensing is designed for application to consumer devices -- basically phones and tablets.
Software developers, on the other hand, have to negotiate with each of the individual patent holders. I've heard from two companies -- one that makes soft clients, the other core network server functions -- who went through the process. Both told the same story: Each patent holder has a different set of terms, conditions, and pricing. That's four different contracts, unlike the one-stop patent pool VoiceAge runs for device manufacturers.
Opus has become all the rage among the developer community and early adopters, driven by its incorporation into the browser for WebRTC. It's open source, royalty free, you use it, and it supports everything from narrowband voice in limited bandwidth conditions to streaming music at 510 kbps with sampling rates between 8 kHz to 48 kHz. Since you can find WebRTC in Google's Chrome and Mozilla's Firefox browser, you can get a high-quality audio experience by just pulling up a Web page.
Among the services and companies that have vowed support for Opus are CounterPath and TruPhone. CounterPath is the largest commercial soft client shop around while TruPhone will join Line2 in adding Opus support for its service/apps when it comes to client-to-client communications.
Compare AMR-WB to Opus or the royalty-enabled Fraunhofer AAC codecs and it becomes a grim contest. Opus and AAC both provide a wider and more flexible range of uses, with either simplifying implementation of sound playback to a single codec set capable of delivering everything from narrowband voice to high quality streaming music. Opus is royalty-free while you typically end up getting AAC thrown into/onto mobile devices via versions of Android and Apple iOS.
AMR-WB has two attributes going for it at this time: Bandwidth and CPU usage/battery life. A full blown AMR-WB call uses 24 kbps. Opus uses less bandwidth in the wideband mode, but has the potential of running up to 128 kbps for so-called "full band" stereo usage. Service providers would no doubt like to have the option to throttle bandwidth usage in certain use cases.
Battery life becomes the most interesting question. Since Opus is a software-based codec, processing takes place using RAM and CPU time, thereby placing more power demands on the battery. But since nobody has (yet) run a side-by-side power comparison between an Opus call of one minute and 10 minutes to an AMR-WB call, it isn't clear how much of a power hit takes place. AMR-WB advocates would argue that on a performance-per-watt basis, its codec would beat Opus and AAC. In the real world, with plenty of people already opting to use Skype and Apple Facetime videoconferencing, the arguments for AMR-WB power efficiency might be academic rather than user driven. Apply Moore's Law for continued performance-per-watt efficiency and potentially some silicon tinkering/optimization for Opus usage and the argument continues to diminish.
references:
http://www.webrtcworld.com/topics/webrtc-world/articles/339560-amr-wb-its-future-hd-voice.htm
Patents for AMR-WB are held by Ericsson, France Telecom/Orange Nokia and VoiceAge. A patent pool -- basically, a one-stop place to license the patents -- for AMR-WB device usage was announced in 2009. Managed by VoiceAge, the licensing is designed for application to consumer devices -- basically phones and tablets.
Software developers, on the other hand, have to negotiate with each of the individual patent holders. I've heard from two companies -- one that makes soft clients, the other core network server functions -- who went through the process. Both told the same story: Each patent holder has a different set of terms, conditions, and pricing. That's four different contracts, unlike the one-stop patent pool VoiceAge runs for device manufacturers.
Opus has become all the rage among the developer community and early adopters, driven by its incorporation into the browser for WebRTC. It's open source, royalty free, you use it, and it supports everything from narrowband voice in limited bandwidth conditions to streaming music at 510 kbps with sampling rates between 8 kHz to 48 kHz. Since you can find WebRTC in Google's Chrome and Mozilla's Firefox browser, you can get a high-quality audio experience by just pulling up a Web page.
Among the services and companies that have vowed support for Opus are CounterPath and TruPhone. CounterPath is the largest commercial soft client shop around while TruPhone will join Line2 in adding Opus support for its service/apps when it comes to client-to-client communications.
Compare AMR-WB to Opus or the royalty-enabled Fraunhofer AAC codecs and it becomes a grim contest. Opus and AAC both provide a wider and more flexible range of uses, with either simplifying implementation of sound playback to a single codec set capable of delivering everything from narrowband voice to high quality streaming music. Opus is royalty-free while you typically end up getting AAC thrown into/onto mobile devices via versions of Android and Apple iOS.
AMR-WB has two attributes going for it at this time: Bandwidth and CPU usage/battery life. A full blown AMR-WB call uses 24 kbps. Opus uses less bandwidth in the wideband mode, but has the potential of running up to 128 kbps for so-called "full band" stereo usage. Service providers would no doubt like to have the option to throttle bandwidth usage in certain use cases.
Battery life becomes the most interesting question. Since Opus is a software-based codec, processing takes place using RAM and CPU time, thereby placing more power demands on the battery. But since nobody has (yet) run a side-by-side power comparison between an Opus call of one minute and 10 minutes to an AMR-WB call, it isn't clear how much of a power hit takes place. AMR-WB advocates would argue that on a performance-per-watt basis, its codec would beat Opus and AAC. In the real world, with plenty of people already opting to use Skype and Apple Facetime videoconferencing, the arguments for AMR-WB power efficiency might be academic rather than user driven. Apply
references:
http://www.webrtcworld.com/topics/webrtc-world/articles/339560-amr-wb-its-future-hd-voice.htm
for VoLTE is AMRWB required?
AMR-WB is specified by 3GPP as the mandatory codec to be supported by wideband mobile terminals for a wide range of communication services. This is mentioned here.https://tools.ietf.org/html/draft-marjou-rtcweb-audio-codecs-for-interop-01#ref-AMR-WB
This includes the massively deployed circuit switched mobile telephony services and new multimedia telephony services over IP/IMS and 4G/VoLTE as specified by GSMA as voice IMS profile for VoLTE in IR92. Hence, AMR-WB is strongly increasing with deployment in more than 60 networks from 45 countries and more than 130 types of terminals. In that use case, if OPUS and G.711 remain the only codecs supported by the WebRTC endpoints, a gateway must then transcode these codecs into AMR-WB, and vice-versa, in order to implement the use-case. As a consequence, a high number of calls are likely to be affected by transcoding operations producing a degradation of the user quality experience for many customers. This will have a very significant business impact for all service providers on both sides, not only with respect to the transcoding costs but mainly with respect to user experience degradation.
The drawbacks of transcoding are recalled below:
Cost issues: transcoding places important additional costs on network gateways for example codec implementation and license costs, deployments costs, testing/validation costs etc... However these costs can be seen as just transferred from the terminal side to the network side. The real issue is rather the degradation of the quality of service affecting the end user perceived quality which will be harmful to all concerned service providers.
Intrinsic quality degradation: Subjective test results show that intrinsic voice quality is significantly degraded by transcoding. The degradation is around 0.2 to 0.3 MOS for most of transcoding use cases with AMR-WB at 12.65 kbit/s. It should be stressed that if transcoding is performed between AMR-WB and G.711, wideband voice quality will be lost. Such bandwidth reduction effect clearly degrades the user perceived quality of service leading to shorter and less frequent calls (see ref_gsma). Such a switch to G.711 will not be accepted anymore by customers. If transcoding is performed between AMR-WB and OPUS, wideband communication could be maintained. However, as the WB codecs complexity is higher than NB codecs complexity, such WB transcoding is also more costly and degrades the quality: MOS scores of transcoding between AMR-WB 12.65kbit/s and OPUS at 16 kbit/s in both directions are significantly lower than those of AMR-WB at 12.65kbit/s or OPUS at 16 kbit/s. Furthermore, in degraded conditions, the addition of defects, like audio artifacts due to packet losses, and the audio effects resulting from the cascading of different packet loss recovery algorithms may result in a quality below the acceptable limit for the customers.
Degraded interactivity due to increased latency: Transcoding means full de-packetization for decoding of the media stream (including mechanisms of de-jitter buffering and packet loss recovery) then re-encoding, re-packetization and re-sending. The delays produced by all these operations are additive and may increase the end to end delay beyond acceptable limits like with more than 1s end to end latency.
As a consequence, re-using AMR-WB would be beneficial for the specific usage of WebRTC technology over mobile networks. With the strong increase of the smartphone market the capability to use such a mobile codec could strongly enforce and extend the market penetration of the Web RTC technology.
references:
https://tools.ietf.org/html/draft-marjou-rtcweb-audio-codecs-for-interop-01#section-4.1
This includes the massively deployed circuit switched mobile telephony services and new multimedia telephony services over IP/IMS and 4G/VoLTE as specified by GSMA as voice IMS profile for VoLTE in IR92. Hence, AMR-WB is strongly increasing with deployment in more than 60 networks from 45 countries and more than 130 types of terminals. In that use case, if OPUS and G.711 remain the only codecs supported by the WebRTC endpoints, a gateway must then transcode these codecs into AMR-WB, and vice-versa, in order to implement the use-case. As a consequence, a high number of calls are likely to be affected by transcoding operations producing a degradation of the user quality experience for many customers. This will have a very significant business impact for all service providers on both sides, not only with respect to the transcoding costs but mainly with respect to user experience degradation.
The drawbacks of transcoding are recalled below:
Cost issues: transcoding places important additional costs on network gateways for example codec implementation and license costs, deployments costs, testing/validation costs etc... However these costs can be seen as just transferred from the terminal side to the network side. The real issue is rather the degradation of the quality of service affecting the end user perceived quality which will be harmful to all concerned service providers.
Intrinsic quality degradation: Subjective test results show that intrinsic voice quality is significantly degraded by transcoding. The degradation is around 0.2 to 0.3 MOS for most of transcoding use cases with AMR-WB at 12.65 kbit/s. It should be stressed that if transcoding is performed between AMR-WB and G.711, wideband voice quality will be lost. Such bandwidth reduction effect clearly degrades the user perceived quality of service leading to shorter and less frequent calls (see ref_gsma). Such a switch to G.711 will not be accepted anymore by customers. If transcoding is performed between AMR-WB and OPUS, wideband communication could be maintained. However, as the WB codecs complexity is higher than NB codecs complexity, such WB transcoding is also more costly and degrades the quality: MOS scores of transcoding between AMR-WB 12.65kbit/s and OPUS at 16 kbit/s in both directions are significantly lower than those of AMR-WB at 12.65kbit/s or OPUS at 16 kbit/s. Furthermore, in degraded conditions, the addition of defects, like audio artifacts due to packet losses, and the audio effects resulting from the cascading of different packet loss recovery algorithms may result in a quality below the acceptable limit for the customers.
Degraded interactivity due to increased latency: Transcoding means full de-packetization for decoding of the media stream (including mechanisms of de-jitter buffering and packet loss recovery) then re-encoding, re-packetization and re-sending. The delays produced by all these operations are additive and may increase the end to end delay beyond acceptable limits like with more than 1s end to end latency.
As a consequence, re-using AMR-WB would be beneficial for the specific usage of WebRTC technology over mobile networks. With the strong increase of the smartphone market the capability to use such a mobile codec could strongly enforce and extend the market penetration of the Web RTC technology.
references:
https://tools.ietf.org/html/draft-marjou-rtcweb-audio-codecs-for-interop-01#section-4.1
What is CAT-iq?
Cordless Advanced Technology—internet and quality (CAT-iq) is a technology initiative from the Digital Enhanced Cordless Telecommunications (DECT) Forum, based on ETSI TS 102 527 New Generation DECT (NG-DECT) European standard series.
NG-DECT contains backward compatible extensions to basic DECT GAP functionality which allow bases and handsets from different vendors to work together with full feature richness expected from SIP terminals and VoIP gateways.
CAT-iq defines several profiles for high quality wideband voice services with multiple lines, as well as low bit-rate data applications.
The CAT-iq profiles are split between voice and data service, with the following mandatory features: [1]
CAT-iq 1.0 - "HD Voice" (ETSI TS 102 527-1): narrow-band (32 kbit/s G.726 ADPCM) and wideband (64 kbit/s G.722 sub-band ADPCM) audio, calling party line and name identification (CLIP, CNIP)
CAT-iq 2.0 - "Multi Line" (ETSI TS 102 527-3): adds multiple lines, line name/id, call waiting, call transfer, phonebook, missed calls list, DTMF signalling, hands-free headset, handset locator, synchronisation of call lists, phonebook, and settings
CAT-iq 2.1 - "Green" (ETSI TS 102 527-5): adds 3-party conference, call intrusion, caller blocking (CLIR), answering machine control, SMS on handsets, power-saving modes for handset and base
CAT-iq 3.0 - "Internet Ready" (ETSI TS 102 527-4): light data services, software upgrade over the air (SUOTA)
CAT-iq 4.0 - "Intelligent Networking" (planned): Smart Home connectivity (IOT) using DECT Ultra Low Energy (ETSI TS 102 939)
The CAT-iq profiles require a stricter set of mandatory features than the relevant ETSI NG-DECT standards, which make many advanced features optional.
Optional voice codecs include 64 kbit/s G.711 ยต-law/A-law PCM (narrow band), 32 kbit/s G.729.1 (wideband), 32 kbit/s MPEG-4 ER AAC-LD (wideband), and 64 kbit/s MPEG-4 ER AAC-LD (super-wideband).
Within the voice profiles, the revisions are sequential: CAT-iq 1.0 provides basic wideband voice, while CAT-iq 2.0 and 2.1 add new functions which expand and supersede parts of the lower profiles.
The data profiles CAT-iq 3.0 and 4.0 can either be considered in isolation for data only devices or as a complementary service to the voice enabled devices.
references:
https://en.wikipedia.org/wiki/CAT-iq
NG-DECT contains backward compatible extensions to basic DECT GAP functionality which allow bases and handsets from different vendors to work together with full feature richness expected from SIP terminals and VoIP gateways.
CAT-iq defines several profiles for high quality wideband voice services with multiple lines, as well as low bit-rate data applications.
The CAT-iq profiles are split between voice and data service, with the following mandatory features: [1]
CAT-iq 1.0 - "HD Voice" (ETSI TS 102 527-1): narrow-band (32 kbit/s G.726 ADPCM) and wideband (64 kbit/s G.722 sub-band ADPCM) audio, calling party line and name identification (CLIP, CNIP)
CAT-iq 2.0 - "Multi Line" (ETSI TS 102 527-3): adds multiple lines, line name/id, call waiting, call transfer, phonebook, missed calls list, DTMF signalling, hands-free headset, handset locator, synchronisation of call lists, phonebook, and settings
CAT-iq 2.1 - "Green" (ETSI TS 102 527-5): adds 3-party conference, call intrusion, caller blocking (CLIR), answering machine control, SMS on handsets, power-saving modes for handset and base
CAT-iq 3.0 - "Internet Ready" (ETSI TS 102 527-4): light data services, software upgrade over the air (SUOTA)
CAT-iq 4.0 - "Intelligent Networking" (planned): Smart Home connectivity (IOT) using DECT Ultra Low Energy (ETSI TS 102 939)
The CAT-iq profiles require a stricter set of mandatory features than the relevant ETSI NG-DECT standards, which make many advanced features optional.
Optional voice codecs include 64 kbit/s G.711 ยต-law/A-law PCM (narrow band), 32 kbit/s G.729.1 (wideband), 32 kbit/s MPEG-4 ER AAC-LD (wideband), and 64 kbit/s MPEG-4 ER AAC-LD (super-wideband).
Within the voice profiles, the revisions are sequential: CAT-iq 1.0 provides basic wideband voice, while CAT-iq 2.0 and 2.1 add new functions which expand and supersede parts of the lower profiles.
The data profiles CAT-iq 3.0 and 4.0 can either be considered in isolation for data only devices or as a complementary service to the voice enabled devices.
references:
https://en.wikipedia.org/wiki/CAT-iq
Thursday, March 23, 2017
Swift 3.0 How to make CGColorRef from UIColor
This is pretty easy. For e.g
button.layer.borderColor = UIColor.white.cgColor
button.layer.borderColor = UIColor.white.cgColor
Subscribe to:
Posts (Atom)