What is Mobile Virtual Network Operator (MVNO)?

MVNO stands for Mobile Virtual Network Operator. A mobile virtual network operator (MVNO) is a company that provides mobile phone services but does not have its own licensed frequency allocation of radio spectrum, nor does it necessarily have all of the infrastructure required to provide mobile telephone service.

MVNE stands for Mobile Virtual Network Enabler which is a company that provides services to mobile virtual network operators such as billing, network element provisioning, administration, operations, support of base station subsystems and operations support systems, and provision of back end network elements, to enable provision of mobile network services like cellular phone connectivity.

An MVNO in reality is a re-seller of mobile products and services from an actual operator but under a different brand.

For example there is an operator A having all the infrastructure including network, switches, billing systems, provisioning system and customer care systems etc. Now if someone wants to start a telecom business by doing some minimum investment then MVNO is the option to proceed.

An MVNO will buy services in bulk from a well established operator and change the brand name as per theri convenience and market those product and services as an operator. Actual operator would remain transparent from th end customer and customer will have feeling like to be an end customer of MVNO.

Depending on the situation, an MVNO can buy one or more infrastructure components from an operator and pay them accordingly. For example, an MVNO may like to use only network from the operator or an MVNO can use network and charging system from the operator and rest of the components like customer care, provisioning etc can be set up by the MVNO.

MVNO’s have full control over the SIM card, branding, marketing, billing, and customer care operations.

The first commercially successful MVNO in the UK was Virgin Mobile UK,[3] launched in the United Kingdom in 1999 and now has over 4 million customers in the UK.

MVNO Services:

MVNO’s typically do not have their own infrastructure, but some leading MVNO’s deploy their own mobile IN infrastructure in order to facilitate the means to offer value-added services. MNVO’s can treat incumbent infrastructure such as radio equipment as a commodity, while the MVNO offers its own advanced and differentiated services based on exploitation of their own intelligent network infrastructure.

In this way, each MVNO and the network operator could focus on their own niche markets and form customized detailed services that would expand their customer reach and brand.

Most of the MVNO come in the market to target only pre-paid customers and provide them only pre-paid services like voice, SMS, MMS, data, broadband etc. with some nice value added services.

MVNO Billing:

Assuming an incumbent operator sell their infrastructure to an MVNO. There could be different business model and agreement between incumbent and MVNO. Following are most commonly used:

  • MVNO can brand their services and sell them in the market and MVNE will help in providing those services to the end customer. Here a fixed percent of commission will go to the MVNE.
  • MVNO can buy products and services in bulk at special discounted prices and then brand them with their name and sell in the market.
  • MVNO sell the products and services and based on the usage generated by the end customers, MVNO pays an amount to the MVNE.

In all the cases MVNO may be required to pay some amount of security deposit to the MVNE and then monthly settlement happens using simple reports generated by the MVNE.

An MVNE can add an MVNO in their billing system as a corporate customer as long as MVNO is providing post-paid services and can add all the products and services provided to MVNO. By the end of every month or usually after every two weeks, invoice can be generated and collection can be followed up.

But usually, most of the MVNO provide pre-paid services which are handled in Pre-Paid system. In such case MVNO functionality is achieved either using built-in functionality in the pre-paid system or by simply defining a separate service class. All the usage CDRs and other information is dumped into data warehouse from where reports can be generated to prepare invoice.

Reference : http://www.tutorialspoint.com/telecom-billing/mvno-billing.htm

Telecom Billing – Tariff Planning

Marketing department in a telecom operator company work hard to define rental & usage charges for different products and services. These charges are defined keeping other competitors and regulatory in mind. Broadly speaking there are two type of tariffs, also called rate or price plans depending terminology used in different billing system.

There could be different type of charges to be applied for a product and associated services. For a given product, an operator can define one or more of the following charges but they are not limited to only these charges, there could be some other type of charges depending on country, location and business situation:

  • Product Initiation Charges: These are one time charges which can be taken from the customer as a part of installation, activation, service or initiating a connection.
  • Product Periodic Charges: These are the charges which can be applied on monthly or bi-monthly or years basis as a rental of the product and service provided.
  • Product Termination Charges: These are the charges which can be applied on termination of the product and service.
  • Product Suspension Charges: These are the charges which can be applied if a product is suspended because of some reason, for example non-payment.
  • Product Suspension Periodic Charges: There could be a requirement to charge a customer periodically even if a customer is suspended because of some reason.
  • Product Re-activation Charges: Assuming a product was suspended due to some reason and now it needs it’s activation. An operator can apply re-activation charges for this service.
  • Product Usage Charges: This is most important type of charge which would be applied base on the usage of the service. For example call per minute, or per second, data download per MB etc.

All the above charges are defined (ie. configured) in different tariff catalogues inclusive or exclusive of applicable tax depending on regulatory. These catalogues vary billing system to billing system. Some billing systems keep all the prices in a single catalogue and some billing systems keep usage charges separate from other charges.

These catalogues are maintained in the billing system but they are also made available to front end system so that different tariffs can be applied to the customer which creating customer account.

All the prices are defined based on products and their packages as well. There could be different combinations of products giving different prices in different packages.

Following section would give you an idea on different concepts which are closely related to tariff definition:

In-Advance & In-Arrear Charges:

There may be situation when an operator would like to charge their customers in advance for some services and in the end of every month for some services.

Charges taken taken in advance before providing the services are called in-advance charging and charges taken after providing the services are called in-arrear charges.

For in-arrears charging the product charges are applied for a period up to at least the day before the current nominal bill date (or bill request date for non-periodic bills).

So while configuring different charges, billing system should give a provision to configure charges in advance and it is always optional for the operators if they want to configure a particular price in-advance or in-arrears.

NOTE: Usage charges can not be taken in advance until they are lump-sum because you never know how much usage a customer is going to generate in coming month. If they are lump-sum amount then you can take that amount in advance and let the customer use unlimited based on their requirement.

Proratable & Non-Proratable Charges:

Consider a situation when a customer takes phone connection in the middle of the month and his invoice needs to be generated on 1st of every month. If prices are non-proratable, billing system would charge the customer for the whole month which would not be fair with the customer. Same apply at the termination, if customer terminates a service in the middle of the month then operator may not be willing to charge the customer of rest of the month.

Pro-ratable pricing means that they would apply only for the number of days customer is going to use the service. For example, if monthly product rental is $30 and customer used this product for 10 days only then billing system should charge the customer only $10 for those 10 days.

So billing system should provide an option to configure particular prices to be pro-ratable as well as non-proratable and let the operator choose what suites them best.

Refundable & Non-Refundable Charges:

Now let us consider a situation where an operator is charging a customer in advance for the whole month, but customer leaves in the middle of the month after using a service for 10 days.

If prices were configured as non-refundable, then they would not be refunded to the customer but if they were configured as refundable, then they would be refunded to the customer. Second rule, if prices were configured as pro-ratable, then they would be refunded based on pro-ration otherwise they would be refunded as a whole.

Charge Overriding Option:

A good billing system provides an option to override base prices at the time they are given to the customer.

For example, for a particular product base prices in the catalogue are defined $30 per month but customer is not ready to pay $30 per month and based on some bargaining, he is ready to pay $25 per month. In such situation customer service representative (CSR) should be able to override defined base price $30 and add them as $25 at the time of customer creation in the system.

Billing system should give an optional provision to the operators if a particular price can be overridden or not and let the operators decide if they want to override some charges at the time of sale or they are fixed in all the situation.

Revenue Segregation by Revenue Codes:

All the operators would like to know how much they have earned using a particular product, its rental, suspension or usage etc.

While defining different prices in the catalogue, billing system should give a provision to associate some kind of revenue codes or keywords with different type of charges. This helps in generating different reports based on the codes associated with the revenue.

Tariffs Classification:

An operator may define different tariffs which can be offered to different people having different credit class. For example, a 5mbps data line at a cost of $100 per month can be offered to a customer having monthly income more than $1000/month and a 1mbps data line can be offered to a customer having minimum monthly income $500/month.

All the billing systems gives option to define different credit classes which can be assigned to customers based on their credit history and income and may be based on some other parameters defined by the operator.

All the products and services can have different tariff plans which can be offered different class of people ranging from general class to VIP class.

Parameters for Usage Charges:

There are number of parameters which can be used while defining usage charges. For example:

  • Calls in day time usually called peak time, will be charged on higher rate and in night time ie. off peak time rate will be relatively low.
  • If calls are terminating with-in the same network usually called on-net calls , would be charged at relatively low prices.
  • Calls during weekend ie. Sat and Sun would be charged at low prices.
  • Calls to a particular destination would be charged at high prices.
  • Calls during some festival would be charged at special prices.
  • Data download from a particular site would be free of cost.
  • Sending SMS to a particular code would be charged at high rate.
  • Calls with-in a particular group of numbers usually called closed user group (CUG), would be charged at zero prices.
  • Sending international or national MMS would be charged at the same prices.

Billing systems provide lots of flexibility to define various such rules to charge voice, data, SMS or MMS usage generated by the customer.


Reference : http://www.tutorialspoint.com/telecom-billing/tariff-planning.htm

Advanced NFC for Android

This document describes advanced NFC topics, such as working with various tag technologies, writing to NFC tags, and foreground dispatching, which allows an application in the foreground to handle intents even when other applications filter for the same ones.

Working with Supported Tag Technologies

When working with NFC tags and Android-powered devices, the main format you use to read and write data on tags is NDEF. When a device scans a tag with NDEF data, Android provides support in parsing the message and delivering it in an NdefMessage when possible. There are cases, however, when you scan a tag that does not contain NDEF data or when the NDEF data could not be mapped to a MIME type or URI. In these cases, you need to open communication directly with the tag and read and write to it with your own protocol (in raw bytes). Android provides generic support for these use cases with the android.nfc.tech package, which is described in Table 1. You can use the getTechList() method to determine the technologies supported by the tag and create the corresponding TagTechnology object with one of classes provided by android.nfc.tech

Table 1. Supported tag technologies

Class Description
TagTechnology The interface that all tag technology classes must implement.
NfcA Provides access to NFC-A (ISO 14443-3A) properties and I/O operations.
NfcB Provides access to NFC-B (ISO 14443-3B) properties and I/O operations.
NfcF Provides access to NFC-F (JIS 6319-4) properties and I/O operations.
NfcV Provides access to NFC-V (ISO 15693) properties and I/O operations.
IsoDep Provides access to ISO-DEP (ISO 14443-4) properties and I/O operations.
Ndef Provides access to NDEF data and operations on NFC tags that have been formatted as NDEF.
NdefFormatable Provides a format operations for tags that may be NDEF formattable.

The following tag technlogies are not required to be supported by Android-powered devices.

Table 2. Optional supported tag technologies

Class Description
MifareClassic Provides access to MIFARE Classic properties and I/O operations, if this Android device supports MIFARE.
MifareUltralight Provides access to MIFARE Ultralight properties and I/O operations, if this Android device supports MIFARE.

Working with tag technologies and the ACTION_TECH_DISCOVERED intent

When a device scans a tag that has NDEF data on it, but could not be mapped to a MIME or URI, the tag dispatch system tries to start an activity with the ACTION_TECH_DISCOVERED intent. The ACTION_TECH_DISCOVERED is also used when a tag with non-NDEF data is scanned. Having this fallback allows you to work with the data on the tag directly if the tag dispatch system could not parse it for you. The basic steps when working with tag technologies are as follows:

  1. Filter for an ACTION_TECH_DISCOVERED intent specifying the tag technologies that you want to handle. SeeFiltering for NFC intents for more information. In general, the tag dispatch system tries to start aACTION_TECH_DISCOVERED intent when an NDEF message cannot be mapped to a MIME type or URI, or if the tag scanned did not contain NDEF data. For more information on how this is determined, see The Tag Dispatch System.
  2. When your application receives the intent, obtain the Tag object from the intent:
    Tag tagFromIntent = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG);
  3. Obtain an instance of a TagTechnology, by calling one of the get factory methods of the classes in theandroid.nfc.tech package. You can enumerate the supported technologies of the tag by callinggetTechList() before calling a get factory method. For example, to obtain an instance ofMifareUltralight from a Tag, do the following:

Reading and writing to tags

Reading and writing to an NFC tag involves obtaining the tag from the intent and opening communication with the tag. You must define your own protocol stack to read and write data to the tag. Keep in mind, however, that you can still read and write NDEF data when working directly with a tag. It is up to you how you want to structure things. The following example shows how to work with a MIFARE Ultralight tag.

package com.example.android.nfc;

import android.nfc.Tag;
import android.nfc.tech.MifareUltralight;
import android.util.Log;
import java.io.IOException;
import java.nio.charset.Charset;

public class MifareUltralightTagTester {

    private static final String TAG = MifareUltralightTagTester.class.getSimpleName();

    public void writeTag(Tag tag, String tagText) {
        MifareUltralight ultralight = MifareUltralight.get(tag);
        try {
            ultralight.writePage(4, "abcd".getBytes(Charset.forName("US-ASCII")));
            ultralight.writePage(5, "efgh".getBytes(Charset.forName("US-ASCII")));
            ultralight.writePage(6, "ijkl".getBytes(Charset.forName("US-ASCII")));
            ultralight.writePage(7, "mnop".getBytes(Charset.forName("US-ASCII")));
        } catch (IOException e) {
            Log.e(TAG, "IOException while closing MifareUltralight...", e);
        } finally {
            try {
            } catch (IOException e) {
                Log.e(TAG, "IOException while closing MifareUltralight...", e);

    public String readTag(Tag tag) {
        MifareUltralight mifare = MifareUltralight.get(tag);
        try {
            byte[] payload = mifare.readPages(4);
            return new String(payload, Charset.forName("US-ASCII"));
        } catch (IOException e) {
            Log.e(TAG, "IOException while writing MifareUltralight
            message...", e);
        } finally {
            if (mifare != null) {
               try {
               catch (IOException e) {
                   Log.e(TAG, "Error closing tag...", e);
        return null;

Using the Foreground Dispatch System

The foreground dispatch system allows an activity to intercept an intent and claim priority over other activities that handle the same intent. Using this system involves constructing a few data structures for the Android system to be able to send the appropriate intents to your application. To enable the foreground dispatch system:

    1. Add the following code in the onCreate() method of your activity:
      1. Create a PendingIntent object so the Android system can populate it with the details of the tag when it is scanned.
        PendingIntent pendingIntent = PendingIntent.getActivity(
            this, 0, new Intent(this, getClass()).addFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP), 0);
      2. Declare intent filters to handle the intents that you want to intercept. The foreground dispatch system checks the specified intent filters with the intent that is received when the device scans a tag. If it matches, then your application handles the intent. If it does not match, the foreground dispatch system falls back to the intent dispatch system. Specifying a null array of intent filters and technology filters, specifies that you want to filter for all tags that fallback to the TAG_DISCOVERED intent. The code snippet below handles all MIME types for NDEF_DISCOVERED. You should only handle the ones that you need.
        IntentFilter ndef = new IntentFilter(NfcAdapter.ACTION_NDEF_DISCOVERED);
            try {
                ndef.addDataType("*/*");    /* Handles all MIME based dispatches.
                                               You should specify only the ones that you need. */
            catch (MalformedMimeTypeException e) {
                throw new RuntimeException("fail", e);
           intentFiltersArray = new IntentFilter[] {ndef, };
      3. Set up an array of tag technologies that your application wants to handle. Call theObject.class.getName() method to obtain the class of the technology that you want to support.
        techListsArray = new String[][] { new String[] { NfcF.class.getName() } };
    2. Override the following activity lifecycle callbacks and add logic to enable and disable the foreground dispatch when the activity loses (onPause()) and regains (onResume()) focus.enableForegroundDispatch() must be called from the main thread and only when the activity is in the foreground (calling in onResume() guarantees this). You also need to implement the onNewIntent callback to process the data from the scanned NFC tag.
public void onPause() {

public void onResume() {
    mAdapter.enableForegroundDispatch(this, pendingIntent, intentFiltersArray, techListsArray);

public void onNewIntent(Intent intent) {
    Tag tagFromIntent = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG);
    //do something with tagFromIntent

See the ForegroundDispatch sample from API Demos for the complete sample.

Reference : http://developer.android.com/guide/topics/connectivity/nfc/advanced-nfc.html

NFC Basics for Android

This document describes the basic NFC tasks you perform in Android. It explains how to send and receive NFC data in the form of NDEF messages and describes the Android framework APIs that support these features. For more advanced topics, including a discussion of working with non-NDEF data, see Advanced NFC.

There are two major uses cases when working with NDEF data and Android:

  • Reading NDEF data from an NFC tag
  • Beaming NDEF messages from one device to another with Android Beam™

Reading NDEF data from an NFC tag is handled with the tag dispatch system, which analyzes discovered NFC tags, appropriately categorizes the data, and starts an application that is interested in the categorized data. An application that wants to handle the scanned NFC tag can declare an intent filter and request to handle the data.

The Android Beam™ feature allows a device to push an NDEF message onto another device by physically tapping the devices together. This interaction provides an easier way to send data than other wireless technologies like Bluetooth, because with NFC, no manual device discovery or pairing is required. The connection is automatically started when two devices come into range. Android Beam is available through a set of NFC APIs, so any application can transmit information between devices. For example, the Contacts, Browser, and YouTube applications use Android Beam to share contacts, web pages, and videos with other devices.

The Tag Dispatch System

Android-powered devices are usually looking for NFC tags when the screen is unlocked, unless NFC is disabled in the device’s Settings menu. When an Android-powered device discovers an NFC tag, the desired behavior is to have the most appropriate activity handle the intent without asking the user what application to use. Because devices scan NFC tags at a very short range, it is likely that making users manually select an activity would force them to move the device away from the tag and break the connection. You should develop your activity to only handle the NFC tags that your activity cares about to prevent the Activity Chooser from appearing.

To help you with this goal, Android provides a special tag dispatch system that analyzes scanned NFC tags, parses them, and tries to locate applications that are interested in the scanned data. It does this by:

  1. Parsing the NFC tag and figuring out the MIME type or a URI that identifies the data payload in the tag.
  2. Encapsulating the MIME type or URI and the payload into an intent. These first two steps are described inHow NFC tags are mapped to MIME types and URIs.
  3. Starts an activity based on the intent. This is described in How NFC Tags are Dispatched to Applications.

How NFC tags are mapped to MIME types and URIs

Before you begin writing your NFC applications, it is important to understand the different types of NFC tags, how the tag dispatch system parses NFC tags, and the special work that the tag dispatch system does when it detects an NDEF message. NFC tags come in a wide array of technologies and can also have data written to them in many different ways. Android has the most support for the NDEF standard, which is defined by the NFC Forum.

NDEF data is encapsulated inside a message (NdefMessage) that contains one or more records (NdefRecord). Each NDEF record must be well-formed according to the specification of the type of record that you want to create. Android also supports other types of tags that do not contain NDEF data, which you can work with by using the classes in the android.nfc.tech package. To learn more about these technologies, see theAdvanced NFC topic. Working with these other types of tags involves writing your own protocol stack to communicate with the tags, so we recommend using NDEF when possible for ease of development and maximum support for Android-powered devices.

Note: To download complete NDEF specifications, go to the NFC Forum Specification Download site and seeCreating common types of NDEF records for examples of how to construct NDEF records.

Now that you have some background in NFC tags, the following sections describe in more detail how Android handles NDEF formatted tags. When an Android-powered device scans an NFC tag containing NDEF formatted data, it parses the message and tries to figure out the data’s MIME type or identifying URI. To do this, the system reads the first NdefRecord inside the NdefMessage to determine how to interpret the entire NDEF message (an NDEF message can have multiple NDEF records). In a well-formed NDEF message, the first NdefRecordcontains the following fields:

3-bit TNF (Type Name Format)
Indicates how to interpret the variable length type field. Valid values are described in described in Table 1.
Variable length type
Describes the type of the record. If using TNF_WELL_KNOWN, use this field to specify the Record Type Definition (RTD). Valid RTD values are described in Table 2.
Variable length ID
A unique identifier for the record. This field is not used often, but if you need to uniquely identify a tag, you can create an ID for it.
Variable length payload
The actual data payload that you want to read or write. An NDEF message can contain multiple NDEF records, so don’t assume the full payload is in the first NDEF record of the NDEF message.

The tag dispatch system uses the TNF and type fields to try to map a MIME type or URI to the NDEF message. If successful, it encapsulates that information inside of a ACTION_NDEF_DISCOVERED intent along with the actual payload. However, there are cases when the tag dispatch system cannot determine the type of data based on the first NDEF record. This happens when the NDEF data cannot be mapped to a MIME type or URI, or when the NFC tag does not contain NDEF data to begin with. In such cases, a Tag object that has information about the tag’s technologies and the payload are encapsulated inside of a ACTION_TECH_DISCOVERED intent instead.

Table 1. describes how the tag dispatch system maps TNF and type fields to MIME types or URIs. It also describes which TNFs cannot be mapped to a MIME type or URI. In these cases, the tag dispatch system falls back to ACTION_TECH_DISCOVERED.

For example, if the tag dispatch system encounters a record of type TNF_ABSOLUTE_URI, it maps the variable length type field of that record into a URI. The tag dispatch system encapsulates that URI in the data field of anACTION_NDEF_DISCOVERED intent along with other information about the tag, such as the payload. On the other hand, if it encounters a record of type TNF_UNKNOWN, it creates an intent that encapsulates the tag’s technologies instead.

Table 1. Supported TNFs and their mappings

Type Name Format (TNF) Mapping
TNF_ABSOLUTE_URI URI based on the type field.
TNF_EXTERNAL_TYPE URI based on the URN in the type field. The URN is encoded into the NDEF type field in a shortened form: <domain_name>:<service_name>. Android maps this to a URI in the form: vnd.android.nfc://ext/<domain_name>:<service_name>.
TNF_MIME_MEDIA MIME type based on the type field.
TNF_UNCHANGED Invalid in the first record, so falls back to ACTION_TECH_DISCOVERED.
TNF_WELL_KNOWN MIME type or URI depending on the Record Type Definition (RTD), which you set in the type field. See Table 2. for more information on available RTDs and their mappings.

Table 2. Supported RTDs for TNF_WELL_KNOWN and their mappings

Record Type Definition (RTD) Mapping
RTD_SMART_POSTER URI based on parsing the payload.
RTD_TEXT MIME type of text/plain.
RTD_URI URI based on payload.

How NFC Tags are Dispatched to Applications

When the tag dispatch system is done creating an intent that encapsulates the NFC tag and its identifying information, it sends the intent to an interested application that filters for the intent. If more than one application can handle the intent, the Activity Chooser is presented so the user can select the Activity. The tag dispatch system defines three intents, which are listed in order of highest to lowest priority:

  1. ACTION_NDEF_DISCOVERED: This intent is used to start an Activity when a tag that contains an NDEF payload is scanned and is of a recognized type. This is the highest priority intent, and the tag dispatch system tries to start an Activity with this intent before any other intent, whenever possible.
  2. ACTION_TECH_DISCOVERED: If no activities register to handle the ACTION_NDEF_DISCOVERED intent, the tag dispatch system tries to start an application with this intent. This intent is also directly started (without starting ACTION_NDEF_DISCOVERED first) if the tag that is scanned contains NDEF data that cannot be mapped to a MIME type or URI, or if the tag does not contain NDEF data but is of a known tag technology.
  3. ACTION_TAG_DISCOVERED: This intent is started if no activities handle the ACTION_NDEF_DISCOVERED orACTION_TECH_DISCOVERED intents.

The basic way the tag dispatch system works is as follows:

  1. Try to start an Activity with the intent that was created by the tag dispatch system when parsing the NFC tag (either ACTION_NDEF_DISCOVERED or ACTION_TECH_DISCOVERED).
  2. If no activities filter for that intent, try to start an Activity with the next lowest priority intent (eitherACTION_TECH_DISCOVERED or ACTION_TAG_DISCOVERED) until an application filters for the intent or until the tag dispatch system tries all possible intents.
  3. If no applications filter for any of the intents, do nothing.

Figure 1. Tag Dispatch System

Whenever possible, work with NDEF messages and the ACTION_NDEF_DISCOVERED intent, because it is the most specific out of the three. This intent allows you to start your application at a more appropriate time than the other two intents, giving the user a better experience.

Requesting NFC Access in the Android Manifest

Before you can access a device’s NFC hardware and properly handle NFC intents, declare these items in yourAndroidManifest.xml file:

  • The NFC <uses-permission> element to access the NFC hardware:
    <uses-permission android:name="android.permission.NFC" />
  • The minimum SDK version that your application can support. API level 9 only supports limited tag dispatch via ACTION_TAG_DISCOVERED, and only gives access to NDEF messages via the EXTRA_NDEF_MESSAGESextra. No other tag properties or I/O operations are accessible. API level 10 includes comprehensive reader/writer support as well as foreground NDEF pushing, and API level 14 provides an easier way to push NDEF messages to other devices with Android Beam and extra convenience methods to create NDEF records.
    <uses-sdk android:minSdkVersion="10"/>
  • The uses-feature element so that your application shows up in Google Play only for devices that have NFC hardware:
    <uses-feature android:name="android.hardware.nfc" android:required="true" />

    If your application uses NFC functionality, but that functionality is not crucial to your application, you can omit the uses-feature element and check for NFC avalailbility at runtime by checking to see ifgetDefaultAdapter() is null.

Filtering for NFC Intents

To start your application when an NFC tag that you want to handle is scanned, your application can filter for one, two, or all three of the NFC intents in the Android manifest. However, you usually want to filter for theACTION_NDEF_DISCOVERED intent for the most control of when your application starts. TheACTION_TECH_DISCOVERED intent is a fallback for ACTION_NDEF_DISCOVERED when no applications filter forACTION_NDEF_DISCOVERED or for when the payload is not NDEF. Filtering for ACTION_TAG_DISCOVERED is usually too general of a category to filter on. Many applications will filter for ACTION_NDEF_DISCOVERED orACTION_TECH_DISCOVERED before ACTION_TAG_DISCOVERED, so your application has a low probability of starting. ACTION_TAG_DISCOVERED is only available as a last resort for applications to filter for in the cases where no other applications are installed to handle the ACTION_NDEF_DISCOVERED orACTION_TECH_DISCOVEREDintent.

Because NFC tag deployments vary and are many times not under your control, this is not always possible, which is why you can fallback to the other two intents when necessary. When you have control over the types of tags and data written, it is recommended that you use NDEF to format your tags. The following sections describe how to filter for each type of intent.


To filter for ACTION_NDEF_DISCOVERED intents, declare the intent filter along with the type of data that you want to filter for. The following example filters for ACTION_NDEF_DISCOVERED intents with a MIME type oftext/plain:

    <action android:name="android.nfc.action.NDEF_DISCOVERED"/>
    <category android:name="android.intent.category.DEFAULT"/>
    <data android:mimeType="text/plain" />

The following example filters for a URI in the form of http://developer.android.com/index.html.

    <action android:name="android.nfc.action.NDEF_DISCOVERED"/>
    <category android:name="android.intent.category.DEFAULT"/>
   <data android:scheme="http"
              android:pathPrefix="/index.html" />


If your activity filters for the ACTION_TECH_DISCOVERED intent, you must create an XML resource file that specifies the technologies that your activity supports within a tech-list set. Your activity is considered a match if a tech-list set is a subset of the technologies that are supported by the tag, which you can obtain by calling getTechList().

For example, if the tag that is scanned supports MifareClassic, NdefFormatable, and NfcA, your tech-list set must specify all three, two, or one of the technologies (and nothing else) in order for your activity to be matched.

The following sample defines all of the technologies. You can remove the ones that you do not need. Save this file (you can name it anything you wish) in the <project-root>/res/xml folder.

<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">

You can also specify multiple tech-list sets. Each of the tech-list sets is considered independently, and your activity is considered a match if any single tech-list set is a subset of the technologies that are returned by getTechList(). This provides AND and OR semantics for matching technologies. The following example matches tags that can support the NfcA and Ndef technologies or can support the NfcB and Ndef technologies:

<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">

<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">

In your AndroidManifest.xml file, specify the resource file that you just created in the <meta-data> element inside the <activity> element like in the following example:

    <action android:name="android.nfc.action.TECH_DISCOVERED"/>

<meta-data android:name="android.nfc.action.TECH_DISCOVERED"
    android:resource="@xml/nfc_tech_filter" />

For more information about working with tag technologies and the ACTION_TECH_DISCOVERED intent, seeWorking with Supported Tag Technologies in the Advanced NFC document.


To filter for ACTION_TAG_DISCOVERED use the following intent filter:

    <action android:name="android.nfc.action.TAG_DISCOVERED"/>

Obtaining information from intents

If an activity starts because of an NFC intent, you can obtain information about the scanned NFC tag from the intent. Intents can contain the following extras depending on the tag that was scanned:

To obtain these extras, check to see if your activity was launched with one of the NFC intents to ensure that a tag was scanned, and then obtain the extras out of the intent. The following example checks for theACTION_NDEF_DISCOVERED intent and gets the NDEF messages from an intent extra.

public void onResume() {
    if (NfcAdapter.ACTION_NDEF_DISCOVERED.equals(getIntent().getAction())) {
        Parcelable[] rawMsgs = intent.getParcelableArrayExtra(NfcAdapter.EXTRA_NDEF_MESSAGES);
        if (rawMsgs != null) {
            msgs = new NdefMessage[rawMsgs.length];
            for (int i = 0; i < rawMsgs.length; i++) {
                msgs[i] = (NdefMessage) rawMsgs[i];
    //process the msgs array

Alternatively, you can obtain a Tag object from the intent, which will contain the payload and allow you to enumerate the tag’s technologies:

Tag tag = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG);

Creating Common Types of NDEF Records

This section describes how to create common types of NDEF records to help you when writing to NFC tags or sending data with Android Beam. Starting with Android 4.0 (API level 14), the createUri() method is available to help you create URI records automatically. Starting in Android 4.1 (API level 16), createExternal() andcreateMime() are available to help you create MIME and external type NDEF records. Use these helper methods whenever possible to avoid mistakes when manually creating NDEF records.

This section also describes how to create the corresponding intent filter for the record. All of these NDEF record examples should be in the first NDEF record of the NDEF message that you are writing to a tag or beaming.


Note: We recommend that you use the RTD_URI type instead of TNF_ABSOLUTE_URI, because it is more efficient.

You can create a TNF_ABSOLUTE_URI NDEF record in the following way:

NdefRecord uriRecord = new NdefRecord(
    NdefRecord.TNF_ABSOLUTE_URI ,
    new byte[0], new byte[0]);

The intent filter for the previous NDEF record would look like this:

    <action android:name="android.nfc.action.NDEF_DISCOVERED" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:scheme="http"
        android:pathPrefix="/index.html" />


You can create a TNF_MIME_MEDIA NDEF record in the following ways.

Using the createMime() method:

NdefRecord mimeRecord = NdefRecord.createMime("application/vnd.com.example.android.beam",
    "Beam me up, Android".getBytes(Charset.forName("US-ASCII")));

Creating the NdefRecord manually:

NdefRecord mimeRecord = new NdefRecord(
    NdefRecord.TNF_MIME_MEDIA ,
    new byte[0], "Beam me up, Android!".getBytes(Charset.forName("US-ASCII")));

The intent filter for the previous NDEF records would look like this:

    <action android:name="android.nfc.action.NDEF_DISCOVERED" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:mimeType="application/vnd.com.example.android.beam" />


You can create a TNF_WELL_KNOWN NDEF record in the following way:

public NdefRecord createTextRecord(String payload, Locale locale, boolean encodeInUtf8) {
    byte[] langBytes = locale.getLanguage().getBytes(Charset.forName("US-ASCII"));
    Charset utfEncoding = encodeInUtf8 ? Charset.forName("UTF-8") : Charset.forName("UTF-16");
    byte[] textBytes = payload.getBytes(utfEncoding);
    int utfBit = encodeInUtf8 ? 0 : (1 << 7);
    char status = (char) (utfBit + langBytes.length);
    byte[] data = new byte[1 + langBytes.length + textBytes.length];
    data[0] = (byte) status;
    System.arraycopy(langBytes, 0, data, 1, langBytes.length);
    System.arraycopy(textBytes, 0, data, 1 + langBytes.length, textBytes.length);
    NdefRecord record = new NdefRecord(NdefRecord.TNF_WELL_KNOWN,
    NdefRecord.RTD_TEXT, new byte[0], data);
    return record;

the intent filter would look like this:

    <action android:name="android.nfc.action.NDEF_DISCOVERED" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:mimeType="text/plain" />


You can create a TNF_WELL_KNOWN NDEF record in the following ways.

Using the createUri(String) method:

NdefRecord rtdUriRecord1 = NdefRecord.createUri("http://example.com");

Using the createUri(Uri) method:

Uri uri = new Uri("http://example.com");
NdefRecord rtdUriRecord2 = NdefRecord.createUri(uri);

Creating the NdefRecord manually:

byte[] uriField = "example.com".getBytes(Charset.forName("US-ASCII"));
byte[] payload = new byte[uriField.length + 1];              //add 1 for the URI Prefix
byte payload[0] = 0x01;                                      //prefixes http://www. to the URI
System.arraycopy(uriField, 0, payload, 1, uriField.length);  //appends URI to payload
NdefRecord rtdUriRecord = new NdefRecord(
    NdefRecord.TNF_WELL_KNOWN, NdefRecord.RTD_URI, new byte[0], payload);

The intent filter for the previous NDEF records would look like this:

    <action android:name="android.nfc.action.NDEF_DISCOVERED" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:scheme="http"
        android:pathPrefix="" />


You can create a TNF_EXTERNAL_TYPE NDEF record in the following ways:

Using the createExternal() method:

byte[] payload; //assign to your data
String domain = "com.example"; //usually your app's package name
String type = "externalType";
NdefRecord extRecord = NdefRecord.createExternal(domain, type, payload);

Creating the NdefRecord manually:

byte[] payload;
NdefRecord extRecord = new NdefRecord(
    NdefRecord.TNF_EXTERNAL_TYPE, "com.example:externalType", new byte[0], payload);

The intent filter for the previous NDEF records would look like this:

    <action android:name="android.nfc.action.NDEF_DISCOVERED" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:scheme="vnd.android.nfc"

Use TNF_EXTERNAL_TYPE for more generic NFC tag deployments to better support both Android-powered and non-Android-powered devices.

Note: URNs for TNF_EXTERNAL_TYPE have a canonical format of:urn:nfc:ext:example.com:externalType, however the NFC Forum RTD specification declares that theurn:nfc:ext: portion of the URN must be ommitted from the NDEF record. So all you need to provide is the domain (example.com in the example) and type (externalType in the example) separated by a colon. When dispatching TNF_EXTERNAL_TYPE, Android converts the urn:nfc:ext:example.com:externalType URN to a vnd.android.nfc://ext/example.com:externalType URI, which is what the intent filter in the example declares.

Android Application Records

Introduced in Android 4.0 (API level 14), an Android Application Record (AAR) provides a stronger certainty that your application is started when an NFC tag is scanned. An AAR has the package name of an application embedded inside an NDEF record. You can add an AAR to any NDEF record of your NDEF message, because Android searches the entire NDEF message for AARs. If it finds an AAR, it starts the application based on the package name inside the AAR. If the application is not present on the device, Google Play is launched to download the application.

AARs are useful if you want to prevent other applications from filtering for the same intent and potentially handling specific tags that you have deployed. AARs are only supported at the application level, because of the package name constraint, and not at the Activity level as with intent filtering. If you want to handle an intent at the Activity level, use intent filters.

If a tag contains an AAR, the tag dispatch system dispatches in the following manner:

  1. Try to start an Activity using an intent filter as normal. If the Activity that matches the intent also matches the AAR, start the Activity.
  2. If the Activity that filters for the intent does not match the AAR, if multiple Activities can handle the intent, or if no Activity handles the intent, start the application specified by the AAR.
  3. If no application can start with the AAR, go to Google Play to download the application based on the AAR.


Note: You can override AARs and the intent dispatch system with the foreground dispatch system, which allows a foreground activity to have priority when an NFC tag is discovered. With this method, the activity must be in the foreground to override AARs and the intent dispatch system.

If you still want to filter for scanned tags that do not contain an AAR, you can declare intent filters as normal. This is useful if your application is interested in other tags that do not contain an AAR. For example, maybe you want to guarantee that your application handles proprietary tags that you deploy as well as general tags deployed by third parties. Keep in mind that AARs are specific to Android 4.0 devices or later, so when deploying tags, you most likely want to use a combination of AARs and MIME types/URIs to support the widest range of devices. In addition, when you deploy NFC tags, think about how you want to write your NFC tags to enable support for the most devices (Android-powered and other devices). You can do this by defining a relatively unique MIME type or URI to make it easier for applications to distinguish.

Android provides a simple API to create an AAR, createApplicationRecord(). All you need to do is embed the AAR anywhere in your NdefMessage. You do not want to use the first record of your NdefMessage, unless the AAR is the only record in the NdefMessage. This is because the Android system checks the first record of anNdefMessage to determine the MIME type or URI of the tag, which is used to create an intent for applications to filter. The following code shows you how to create an AAR:

NdefMessage msg = new NdefMessage(
        new NdefRecord[] {

Beaming NDEF Messages to Other Devices

Android Beam allows simple peer-to-peer data exchange between two Android-powered devices. The application that wants to beam data to another device must be in the foreground and the device receiving the data must not be locked. When the beaming device comes in close enough contact with a receiving device, the beaming device displays the “Touch to Beam” UI. The user can then choose whether or not to beam the message to the receiving device.

Note: Foreground NDEF pushing was available at API level 10, which provides similar functionality to Android Beam. These APIs have since been deprecated, but are available to support older devices. SeeenableForegroundNdefPush() for more information.

You can enable Android Beam for your application by calling one of the two methods:

An activity can only push one NDEF message at a time, so setNdefPushMessageCallback() takes precedence over setNdefPushMessage() if both are set. To use Android Beam, the following general guidelines must be met:

  • The activity that is beaming the data must be in the foreground. Both devices must have their screens unlocked.
  • You must encapsulate the data that you are beaming in an NdefMessage object.
  • The NFC device that is receiving the beamed data must support the com.android.npp NDEF push protocol or NFC Forum’s SNEP (Simple NDEF Exchange Protocol). The com.android.npp protocol is required for devices on API level 9 (Android 2.3) to API level 13 (Android 3.2). com.android.npp and SNEP are both required on API level 14 (Android 4.0) and later.

Note: If your activity enables Android Beam and is in the foreground, the standard intent dispatch system is disabled. However, if your activity also enables foreground dispatching, then it can still scan tags that match the intent filters set in the foreground dispatching.

To enable Android Beam:

  1. Create an NdefMessage that contains the NdefRecords that you want to push onto the other device.
  2. Call setNdefPushMessage() with a NdefMessage or call setNdefPushMessageCallback passing in aNfcAdapter.CreateNdefMessageCallback object in the onCreate() method of your activity. These methods require at least one activity that you want to enable with Android Beam, along with an optional list of other activities to activate.In general, you normally use setNdefPushMessage() if your Activity only needs to push the same NDEF message at all times, when two devices are in range to communicate. You usesetNdefPushMessageCallback when your application cares about the current context of the application and wants to push an NDEF message depending on what the user is doing in your application.

The following sample shows how a simple activity calls NfcAdapter.CreateNdefMessageCallback in theonCreate() method of an activity (see AndroidBeamDemo for the complete sample). This example also has methods to help you create a MIME record:

package com.example.android.beam;

import android.app.Activity;
import android.content.Intent;
import android.nfc.NdefMessage;
import android.nfc.NdefRecord;
import android.nfc.NfcAdapter;
import android.nfc.NfcAdapter.CreateNdefMessageCallback;
import android.nfc.NfcEvent;
import android.os.Bundle;
import android.os.Parcelable;
import android.widget.TextView;
import android.widget.Toast;
import java.nio.charset.Charset;

public class Beam extends Activity implements CreateNdefMessageCallback {
    NfcAdapter mNfcAdapter;
    TextView textView;

    public void onCreate(Bundle savedInstanceState) {
        TextView textView = (TextView) findViewById(R.id.textView);
        // Check for available NFC Adapter
        mNfcAdapter = NfcAdapter.getDefaultAdapter(this);
        if (mNfcAdapter == null) {
            Toast.makeText(this, "NFC is not available", Toast.LENGTH_LONG).show();
        // Register callback
        mNfcAdapter.setNdefPushMessageCallback(this, this);

    public NdefMessage createNdefMessage(NfcEvent event) {
        String text = ("Beam me up, Android!\n\n" +
                "Beam Time: " + System.currentTimeMillis());
        NdefMessage msg = new NdefMessage(
                new NdefRecord[] { createMime(
                        "application/vnd.com.example.android.beam", text.getBytes())
          * The Android Application Record (AAR) is commented out. When a device
          * receives a push with an AAR in it, the application specified in the AAR
          * is guaranteed to run. The AAR overrides the tag dispatch system.
          * You can add it back in to guarantee that this
          * activity starts when receiving a beamed message. For now, this code
          * uses the tag dispatch system.
        return msg;

    public void onResume() {
        // Check to see that the Activity started due to an Android Beam
        if (NfcAdapter.ACTION_NDEF_DISCOVERED.equals(getIntent().getAction())) {

    public void onNewIntent(Intent intent) {
        // onResume gets called after this to handle the intent

     * Parses the NDEF Message from the intent and prints to the TextView
    void processIntent(Intent intent) {
        textView = (TextView) findViewById(R.id.textView);
        Parcelable[] rawMsgs = intent.getParcelableArrayExtra(
        // only one message sent during the beam
        NdefMessage msg = (NdefMessage) rawMsgs[0];
        // record 0 contains the MIME type, record 1 is the AAR, if present
        textView.setText(new String(msg.getRecords()[0].getPayload()));

Note that this code comments out an AAR, which you can remove. If you enable the AAR, the application specified in the AAR always receives the Android Beam message. If the application is not present, Google Play is started to download the application. Therefore, the following intent filter is not technically necessary for Android 4.0 devices or later if the AAR is used:

  <action android:name="android.nfc.action.NDEF_DISCOVERED"/>
  <category android:name="android.intent.category.DEFAULT"/>
  <data android:mimeType="application/vnd.com.example.android.beam"/>

With this intent filter, the com.example.android.beam application now can be started when it scans an NFC tag or receives an Android Beam with an AAR of type com.example.android.beam, or when an NDEF formatted message contains a MIME record of type application/vnd.com.example.android.beam.

Even though AARs guarantee an application is started or downloaded, intent filters are recommended, because they let you start an Activity of your choice in your application instead of always starting the main Activity within the package specified by an AAR. AARs do not have Activity level granularity. Also, because some Android-powered devices do not support AARs, you should also embed identifying information in the first NDEF record of your NDEF messages and filter for that as well, just in case. See Creating Common Types of NDEF records for more information on how to create records.

Reference : http://developer.android.com/guide/topics/connectivity/nfc/nfc.html

Session Initiation Protocol (SIP) for Android

Android provides an API that supports the Session Initiation Protocol (SIP). This lets you add SIP-based internet telephony features to your applications. Android includes a full SIP protocol stack and integrated call management services that let applications easily set up outgoing and incoming voice calls, without having to manage sessions, transport-level communication, or audio record or playback directly.

Here are examples of the types of applications that might use the SIP API:

  • Video conferencing.
  • Instant messaging.

Here are the requirements for developing a SIP application:

  • You must have a mobile device that is running Android 2.3 or higher.
  • SIP runs over a wireless data connection, so your device must have a data connection (with a mobile data service or Wi-Fi). This means that you can’t test on AVD—you can only test on a physical device. For details, see Testing SIP Applications.
  • Each participant in the application’s communication session must have a SIP account. There are many different SIP providers that offer SIP accounts.

SIP API Classes and Interfaces

Here is a summary of the classes and one interface (SipRegistrationListener) that are included in the Android SIP API:

Class/Interface Description
SipAudioCall Handles an Internet audio call over SIP.
SipAudioCall.Listener Listener for events relating to a SIP call, such as when a call is being received (“on ringing”) or a call is outgoing (“on calling”).
SipErrorCode Defines error codes returned during SIP actions.
SipManager Provides APIs for SIP tasks, such as initiating SIP connections, and provides access to related SIP services.
SipProfile Defines a SIP profile, including a SIP account, domain and server information.
SipProfile.Builder Helper class for creating a SipProfile.
SipSession Represents a SIP session that is associated with a SIP dialog or a standalone transaction not within a dialog.
SipSession.Listener Listener for events relating to a SIP session, such as when a session is being registered (“on registering”) or a call is outgoing (“on calling”).
SipSession.State Defines SIP session states, such as “registering”, “outgoing call”, and “in call”.
SipRegistrationListener An interface that is a listener for SIP registration events.

Creating the Manifest

If you are developing an application that uses the SIP API, remember that the feature is supported only on Android 2.3 (API level 9) and higher versions of the platform. Also, among devices running Android 2.3 (API level 9) or higher, not all devices will offer SIP support.

To use SIP, add the following permissions to your application’s manifest:

  • android.permission.USE_SIP
  • android.permission.INTERNET

To ensure that your application can only be installed on devices that are capable of supporting SIP, add the following to your application’s manifest:

  • <uses-sdk android:minSdkVersion="9" />. This indicates that your application requires Android 2.3 or higher. For more information, see API Levels and the documentation for the <uses-sdk> element.

To control how your application is filtered from devices that do not support SIP (for example, on Google Play), add the following to your application’s manifest:

  • <uses-feature android:name="android.hardware.sip.voip" />. This states that your application uses the SIP API. The declaration should include an android:required attribute that indicates whether you want the application to be filtered from devices that do not offer SIP support. Other <uses-feature>declarations may also be needed, depending on your implementation. For more information, see the documentation for the <uses- feature> element.

If your application is designed to receive calls, you must also define a receiver (BroadcastReceiver subclass) in the application’s manifest:

  • <receiver android:name=".IncomingCallReceiver" android:label="Call Receiver"/>

Here are excerpts from the SipDemo manifest:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
     <receiver android:name=".IncomingCallReceiver" android:label="Call Receiver"/>
  <uses-sdk android:minSdkVersion="9" />
  <uses-permission android:name="android.permission.USE_SIP" />
  <uses-permission android:name="android.permission.INTERNET" />
  <uses-feature android:name="android.hardware.sip.voip" android:required="true" />
  <uses-feature android:name="android.hardware.wifi" android:required="true" />
  <uses-feature android:name="android.hardware.microphone" android:required="true" />

Creating a SipManager

To use the SIP API, your application must create a SipManager object. The SipManager takes care of the following in your application:

  • Initiating SIP sessions.
  • Initiating and receiving calls.
  • Registering and unregistering with a SIP provider.
  • Verifying session connectivity.

You instantiate a new SipManager as follows:

public SipManager mSipManager = null;
if(mSipManager == null) {
    mSipManager = SipManager.newInstance(this);

Registering with a SIP Server

A typical Android SIP application involves one or more users, each of whom has a SIP account. In an Android SIP application, each SIP account is represented by a SipProfile object.

SipProfile defines a SIP profile, including a SIP account, and domain and server information. The profile associated with the SIP account on the device running the application is called the local profile. The profile that the session is connected to is called the peer profile. When your SIP application logs into the SIP server with the local SipProfile, this effectively registers the device as the location to send SIP calls to for your SIP address.

This section shows how to create a SipProfile, register it with a SIP server, and track registration events.

You create a SipProfile object as follows:

public SipProfile mSipProfile = null;

SipProfile.Builder builder = new SipProfile.Builder(username, domain);
mSipProfile = builder.build();

The following code excerpt opens the local profile for making calls and/or receiving generic SIP calls. The caller can make subsequent calls through mSipManager.makeAudioCall. This excerpt also sets the actionandroid.SipDemo.INCOMING_CALL, which will be used by an intent filter when the device receives a call (seeSetting up an intent filter to receive calls). This is the registration step:

Intent intent = new Intent();
PendingIntent pendingIntent = PendingIntent.getBroadcast(this, 0, intent, Intent.FILL_IN_DATA);
mSipManager.open(mSipProfile, pendingIntent, null);

Finally, this code sets a SipRegistrationListener on the SipManager. This tracks whether the SipProfilewas successfully registered with your SIP service provider:

mSipManager.setRegistrationListener(mSipProfile.getUriString(), new SipRegistrationListener() {

public void onRegistering(String localProfileUri) {
    updateStatus("Registering with SIP Server...");

public void onRegistrationDone(String localProfileUri, long expiryTime) {

public void onRegistrationFailed(String localProfileUri, int errorCode,
    String errorMessage) {
    updateStatus("Registration failed.  Please check settings.");

When your application is done using a profile, it should close it to free associated objects into memory and unregister the device from the server. For example:

public void closeLocalProfile() {
    if (mSipManager == null) {
    try {
       if (mSipProfile != null) {
     } catch (Exception ee) {
       Log.d("WalkieTalkieActivity/onDestroy", "Failed to close local profile.", ee);

Making an Audio Call

To make an audio call, you must have the following in place:

  • SipProfile that is making the call (the “local profile”), and a valid SIP address to receive the call (the “peer profile”).
  • SipManager object.

To make an audio call, you should set up a SipAudioCall.Listener. Much of the client’s interaction with the SIP stack happens through listeners. In this snippet, you see how the SipAudioCall.Listener sets things up after the call is established:

SipAudioCall.Listener listener = new SipAudioCall.Listener() {

   public void onCallEstablished(SipAudioCall call) {

   public void onCallEnded(SipAudioCall call) {
      // Do something.

Once you’ve set up the SipAudioCall.Listener, you can make the call. The SipManager methodmakeAudioCall takes the following parameters:

  • A local SIP profile (the caller).
  • A peer SIP profile (the user being called).
  • SipAudioCall.Listener to listen to the call events from SipAudioCall. This can be null, but as shown above, the listener is used to set things up once the call is established.
  • The timeout value, in seconds.

For example:

 call = mSipManager.makeAudioCall(mSipProfile.getUriString(), sipAddress, listener, 30);

Receiving Calls

To receive calls, a SIP application must include a subclass of BroadcastReceiver that has the ability to respond to an intent indicating that there is an incoming call. Thus, you must do the following in your application:

  • In AndroidManifest.xml, declare a <receiver>. In SipDemo, this is <receiver android:name=".IncomingCallReceiver" android:label="Call Receiver"/>.
  • Implement the receiver, which is a subclass of BroadcastReceiver. In SipDemo, this isIncomingCallReceiver.
  • Initialize the local profile (SipProfile) with a pending intent that fires your receiver when someone calls the local profile.
  • Set up an intent filter that filters by the action that represents an incoming call. In SipDemo, this action isandroid.SipDemo.INCOMING_CALL.

Subclassing BroadcastReceiver

To receive calls, your SIP application must subclass BroadcastReceiver. The Android system handles incoming SIP calls and broadcasts an “incoming call” intent (as defined by the application) when it receives a call. Here is the subclassed BroadcastReceiver code from SipDemo. To see the full example, go to SipDemo sample, which is included in the SDK samples. For information on downloading and installing the SDK samples, see Getting the Samples.

/*** Listens for incoming SIP calls, intercepts and hands them off to WalkieTalkieActivity.
public class IncomingCallReceiver extends BroadcastReceiver {
     * Processes the incoming call, answers it, and hands it over to the
     * WalkieTalkieActivity.
     * @param context The context under which the receiver is running.
     * @param intent The intent being received.
    public void onReceive(Context context, Intent intent) {
        SipAudioCall incomingCall = null;
        try {
            SipAudioCall.Listener listener = new SipAudioCall.Listener() {
                public void onRinging(SipAudioCall call, SipProfile caller) {
                    try {
                    } catch (Exception e) {
            WalkieTalkieActivity wtActivity = (WalkieTalkieActivity) context;
            incomingCall = wtActivity.mSipManager.takeAudioCall(intent, listener);
            if(incomingCall.isMuted()) {
            wtActivity.call = incomingCall;
        } catch (Exception e) {
            if (incomingCall != null) {

Setting up an intent filter to receive calls

When the SIP service receives a new call, it sends out an intent with the action string provided by the application. In SipDemo, this action string is android.SipDemo.INCOMING_CALL.

This code excerpt from SipDemo shows how the SipProfile object gets created with a pending intent based on the action string android.SipDemo.INCOMING_CALL. The PendingIntent object will perform a broadcast when the SipProfile receives a call:

public SipManager mSipManager = null;
public SipProfile mSipProfile = null;

Intent intent = new Intent(); 
PendingIntent pendingIntent = PendingIntent.getBroadcast(this, 0, intent, Intent.FILL_IN_DATA); 
mSipManager.open(mSipProfile, pendingIntent, null);

The broadcast will be intercepted by the intent filter, which will then fire the receiver (IncomingCallReceiver). You can specify an intent filter in your application’s manifest file, or do it in code as in the SipDemo sample application’s onCreate() method of the application’s Activity:

public class WalkieTalkieActivity extends Activity implements View.OnTouchListener {
    public IncomingCallReceiver callReceiver;

    public void onCreate(Bundle savedInstanceState) {       IntentFilter filter = new IntentFilter();
       callReceiver = new IncomingCallReceiver();
       this.registerReceiver(callReceiver, filter);

Testing SIP Applications

To test SIP applications, you need the following:

  • A mobile device that is running Android 2.3 or higher. SIP runs over wireless, so you must test on an actual device. Testing on AVD won’t work.
  • A SIP account. There are many different SIP providers that offer SIP accounts.
  • If you are placing a call, it must also be to a valid SIP account.

To test a SIP application:

  1. On your device, connect to wireless (Settings > Wireless & networks > Wi-Fi > Wi-Fi settings)
  2. Set up your mobile device for testing, as described in Developing on a Device.
  3. Run your application on your mobile device, as described in Developing on a Device.
  4. If you are using Eclipse, you can view the application log output in Eclipse using LogCat (Window > Show View > Other > Android > LogCat).

Reference : http://developer.android.com/guide/topics/connectivity/sip.html



Suppose to rename datafileDATA201009.dbftodatafileDATA201009_02.dbf

Step 1: Check path of datafile on tablespace

In the command below, we can detect the datafile with the same name but different paths, which determine what should rename datafile, avoid mistakes

SELECT file_name, tablespace_name

FROM dba_data_files

WHERE FILE_NAME like ‘%DATA201009.dbf%’;

Step 2 :Offline tablespacecontaining thehave datafile which rename

altertablespace“DATA201009” offline immediate;

Step 3 : Login operating system by user oracle or administrator to copy datafile to new location.

–         Use parameter -i in commandcp to datafile in path2 not overwrite

–         You should check path2 before execute.

cp-i path1/DATA201009.dbf path2/DATA201009_02.dbf

Step 4 : Rename datafile.

altertablespaceDATA201009 rename datafile‘/u02/oradata/DATA201009.dbf’ to ‘/u02/oradata/DATA201009_02.dbf’

Step 5 :Online tablespace.

alter tablespace“DATA201009” online ;

Step 6 :Check all datafile again in tablespace have tablespace name.

SELECT file_name, tablespace_name

FROM dba_data_files

WHERE file_nameLIKE ‘%DATA201009.dbf%’;