Mobile VoIP is the application of Voice over IP technology to mobile handsets.
There are several methodologies by which a mobile handset can be integrated into a VoIP network. One implementation turns the mobile device into a standard SIP client, which then uses a data network to send and receive SIP messaging, and to send and receive RTP for the voice path. This methodology of turning a mobile handset into a standard SIP client requires that the mobile handset support, at minimum, high speed IP communications. In this application, standard VoIP protocols (typically SIP) are used over any broadband IP-capable wireless network connection such as EVDO rev A (which is synchronously high speed - both high speed up and down), HSDPA, WiFi or WiMAX.
Another implementation of mobile integration uses a softswitch like gateway to bridge SIP and RTP into the mobile network's SS7 infrastructure. In this implementation, the mobile handset continues to operate as it always has (as a GSM or CDMA based device), but now it can be controlled by a SIP application server which can now provide advanced SIP based services to it. Several vendors offer this kind of capability today, including Tango Networks, Outsmart, NewStep, BridgePort and BroadSoft.
Mobile VoIP will require a compromise between economy and mobility. For example, Voice over Wi-Fi offers potentially free service but is only available within the coverage area of a Wi-Fi Access Point. High speed services from mobile operators using EVDO rev A or HSDPA may have better audio quality and capabilities for metropolitan-wide coverage including fast handoffs among mobile base stations, yet it will cost more than the typical Wi-Fi-based VoIP service.
Mobile VoIP will become an important service in the coming years as device manufacturers exploit more powerful processors and less costly memory to meet user needs for ever-more 'power in their pocket'. Smartphones in mid-2006 are capable of sending and receiving email, browsing the web (albeit at low rates) and in some cases allowing a user to watch TV.
The challenge for the mobile operator industry is to deliver the benefits and innovations of IP without losing control of the network service. Users like the Internet to be free and high speed without extra charges for visiting specific sites. Such a service challenges the most valuable service in the telecommunications industry - voice - and threatens to change the nature of the global communications industry.
Mobile VoIP relies on two main technologies:
UMA - the Unlicensed Mobile Access Generic Access Network, designed to allow VoIP to run over the GSM cellular backbone
SIP - the standard used by most VoIP services, and now being implemented on mobile handsets
VoIP Mobile industry is estimated to grow to 12 Billion Dollars by 2010 in Europe alone. Four technologies are required for mobile VoIP functionality: a device, client software, a wireless network and a VoIP service.
Throughout the early 2000s, Hewlett-Packard, Symbol Technologies and others have been innovators in Wi-Fi-based handheld devices, as Personal digital assistant or handheld computers for warehousing and other applications. As successive generations of these devices gained in processing power and battery life, their potential use as a platform for mobile VoIP became practical. Using Microsoft Windows CE operating systems, in the summer of 2005 companies delivered practical client software to run on these class of Wi-Fi only, Windows-based PDAs.
In the summer of 2006, a SIP (Session Initiation Protocol) stack was introduced and a VoIP client in the E-series dual-mode Wi-Fi handsets (Nokia E60, Nokia E61, Nokia E70).
From a Wi-Fi network perspective there are several innovations, embedded in the most current vendor Wi-Fi networking equipment for the enterprise and municipal service provider, that makes them particularly powerful in a mobile VoIP context. These innovations include support for strong encryption making the conversation in a Wi-Fi context quite private (IEEE 802.11i), support for Quality of Service for real-time services such as mobile VoIP (see IEEE 802.11e) and in some cases support for wireless access point to access point call handoff.
VoIP server vendors, upon which VoIP service providers create the service have announced support for integrating mobile handsets into VoIP infrastructures, either natively using SS7 interfaces into the mobile network, or via software based clients running on the mobile handset. BroadSoft is one such vendor of a platform (BroadWorks) that enables mobile integration using either strategy. Enterprise IP PBX vendors have developed, tested and announced capabilities for mobile VoIP users interacting with their business IP-based phone systems.
One implementation of Fixed mobile convergence enables seamless roaming between WIFI and GSM or CDMA networks. Standards and alliances have been developed and technologies have been demonstrated as early as December 2005. Cisco and FirstHand Technologies demonstrated a Wi-Fi to GSM handoff in San Jose, December 5, 2005.
WiFiMobile, founded in 2002 were one of the first mobile VoIP providers with their own self developed VoIP client compatible with all Nokia E and Nseries smartphones.
Recently T-Mobile blocked the access to pure mobile VoIP numbers, which were issued by Truphone for the first time. The issue was widely discussed in the press and although Truphone won an injunction[1], the case is still in the courts while T-Mobile pay only a nominal termination fee.
Friday, January 25, 2008
Friday, January 11, 2008
IP aDDRESS
Every device connected to the public Internet is assigned a unique number known as an Internet Protocol (IP) address. IP addresses consist of four numbers separated by periods (also called a 'dotted-quad') and look something like 127.0.0.1.
Since these numbers are usually assigned to internet service providers within region-based blocks, an IP address can often be used to identify the region or country from which a computer is connecting to the Internet. An IP address can sometimes be used to show the user's general location.
Because the numbers may be tedious to deal with, an IP address may also be assigned to a Host name, which is sometimes easier to remember. Hostnames may be looked up to find IP addresses, and vice-versa. At one time ISPs issued one IP address to each user. These are called static IP addresses. Because there is a limited number of IP addresses and with increased usage of the internet ISPs now issue IP addresses in a dynamic fashion out of a pool of IP addresses (Using DHCP). These are referred to as dynamic IP addresses. This also limits the ability of the user to host websites, mail servers, ftp servers, etc. In addition to users connecting to the internet, with virtual hosting, a single machine can act like multiple machines (with multiple domain names and IP addresses).
Knowing your IP address can allow you (and others you tell) to access services running on your machine such as online games, servers (FTP, web, mail), and remote access utilities (PCAnywhere, GoToMyPC, MS Remote Desktop
Since these numbers are usually assigned to internet service providers within region-based blocks, an IP address can often be used to identify the region or country from which a computer is connecting to the Internet. An IP address can sometimes be used to show the user's general location.
Because the numbers may be tedious to deal with, an IP address may also be assigned to a Host name, which is sometimes easier to remember. Hostnames may be looked up to find IP addresses, and vice-versa. At one time ISPs issued one IP address to each user. These are called static IP addresses. Because there is a limited number of IP addresses and with increased usage of the internet ISPs now issue IP addresses in a dynamic fashion out of a pool of IP addresses (Using DHCP). These are referred to as dynamic IP addresses. This also limits the ability of the user to host websites, mail servers, ftp servers, etc. In addition to users connecting to the internet, with virtual hosting, a single machine can act like multiple machines (with multiple domain names and IP addresses).
Knowing your IP address can allow you (and others you tell) to access services running on your machine such as online games, servers (FTP, web, mail), and remote access utilities (PCAnywhere, GoToMyPC, MS Remote Desktop
Monday, January 7, 2008
PHP greatest security-SESSION SECURITY
1. Shared web servers
anyone else on the server can read your session files (typically in the /tmp directory) if PHP is running as an Apache module (so the session files belong to the web user) and possibly when PHP is used as a CGI (depending on how sessions are implemented).
Someone browsing the session files (probably) won’t know the site the server the sessions apply to (so may not be able to use a username / password combination they found) but you may still be putting sensitive info (like credit card details) somewhere for all to see. Plus they’ve got a list of valid session IDs…
If you’re just storing passwords in the session, you can get away with this by using md5() (preferably twice) to one-way encrypt the password. This does not help though if you need to recover the value of a session variable.
Using a custom session handler to store the sessions in a database is probably the best solution. You might consider MySQL HEAP tables if performance is an issue (assuming MySQL running on same machine as Apache). If it gets to very high traffic, it’s time to think about getting your own server…
2. XSS exploits (and session hijacking) - using JavaScript users can be fooled into giving away their active session_id.
All someone needs to “hijack” a session is the unique session id. It’s like the key to a railway station locker. The locker doesn’t check you’re the valid owner of the key, before allowing you to open it so anyone with the key can get in.
Research XSS and how to prevent it.
Accept that session hijacking cannot be entirely prevented (checks on IP address, for example, is foiled by AOL, who assign a new client IP on more or less every page request) so double check “critical actions” a user can perform when logged in e.g. when changing password - require the old password, which the session hijacker will (hopefully) not know. Displaying credit card information - do like Amazon and only display the last four digits. Basically limit the damage someone can do if they hijack a session.
3. Session IDs in URL (and hijacking) - if you’re using session IDs in the URL (as opposed to a session cookie), make sure off site links do not contain the session ID (or the remote site will be able to hijack) - PHP should take care of this. Also your visitors may give away the session ID in the referrer field - ideally pass off site links through a redirect page, to eliminate the referrer (although, unfortunately, some browsers keep the last 3 pages viewed I believe - unsure of facts).
Ideally, don’t pass session ids in the URL - require users to accept a cookie if they need to “log in”.
4. Session Fixation (pre-hijacking)
If you assign a session to a visitor to your site, before they are logged in (for example for click path analysis), make sure that you assign them a new session id when they do login, so that if someone pre-generated the initial session id for them, they won’t get the new ID.
For PHP 4.2.0+, see session_regenerate_id() (in particular the user submitted comments). For PHP < 4.2.0, you'll have to destroy the session and re-create it when the user logs in, carrying any stored data between the two. The session_id() function may also be useful (haven’t explored it in this context myself).
5. Sniffing Packets (use SSL [HTTPS]) - a session ID can be “sniffed” between the client and your server. If it’s a site where money is changing hands or other sensitive personal information is involved, SSL is a requirement.
Otherwise, without SSL, you have to live with the risk (just like you do every time you use that FTP client…).
6. Cookies are not for session data - on a related note, don’t use cookies for store sensitive information.
Cookie data, unlike sessions, gets stored on the client site. Apart from the “sniffing risk”, a large majority of Windows users have little idea of security and may be “owned by haxor”.
Otherwise, cookies (aside from session cookie PHP creates for you) are generally meant for long term (i.e. between visits) data persistence (e.g. “Remember Me”) rather than “active session” persistence.
anyone else on the server can read your session files (typically in the /tmp directory) if PHP is running as an Apache module (so the session files belong to the web user) and possibly when PHP is used as a CGI (depending on how sessions are implemented).
Someone browsing the session files (probably) won’t know the site the server the sessions apply to (so may not be able to use a username / password combination they found) but you may still be putting sensitive info (like credit card details) somewhere for all to see. Plus they’ve got a list of valid session IDs…
If you’re just storing passwords in the session, you can get away with this by using md5() (preferably twice) to one-way encrypt the password. This does not help though if you need to recover the value of a session variable.
Using a custom session handler to store the sessions in a database is probably the best solution. You might consider MySQL HEAP tables if performance is an issue (assuming MySQL running on same machine as Apache). If it gets to very high traffic, it’s time to think about getting your own server…
2. XSS exploits (and session hijacking) - using JavaScript users can be fooled into giving away their active session_id.
All someone needs to “hijack” a session is the unique session id. It’s like the key to a railway station locker. The locker doesn’t check you’re the valid owner of the key, before allowing you to open it so anyone with the key can get in.
Research XSS and how to prevent it.
Accept that session hijacking cannot be entirely prevented (checks on IP address, for example, is foiled by AOL, who assign a new client IP on more or less every page request) so double check “critical actions” a user can perform when logged in e.g. when changing password - require the old password, which the session hijacker will (hopefully) not know. Displaying credit card information - do like Amazon and only display the last four digits. Basically limit the damage someone can do if they hijack a session.
3. Session IDs in URL (and hijacking) - if you’re using session IDs in the URL (as opposed to a session cookie), make sure off site links do not contain the session ID (or the remote site will be able to hijack) - PHP should take care of this. Also your visitors may give away the session ID in the referrer field - ideally pass off site links through a redirect page, to eliminate the referrer (although, unfortunately, some browsers keep the last 3 pages viewed I believe - unsure of facts).
Ideally, don’t pass session ids in the URL - require users to accept a cookie if they need to “log in”.
4. Session Fixation (pre-hijacking)
If you assign a session to a visitor to your site, before they are logged in (for example for click path analysis), make sure that you assign them a new session id when they do login, so that if someone pre-generated the initial session id for them, they won’t get the new ID.
For PHP 4.2.0+, see session_regenerate_id() (in particular the user submitted comments). For PHP < 4.2.0, you'll have to destroy the session and re-create it when the user logs in, carrying any stored data between the two. The session_id() function may also be useful (haven’t explored it in this context myself).
5. Sniffing Packets (use SSL [HTTPS]) - a session ID can be “sniffed” between the client and your server. If it’s a site where money is changing hands or other sensitive personal information is involved, SSL is a requirement.
Otherwise, without SSL, you have to live with the risk (just like you do every time you use that FTP client…).
6. Cookies are not for session data - on a related note, don’t use cookies for store sensitive information.
Cookie data, unlike sessions, gets stored on the client site. Apart from the “sniffing risk”, a large majority of Windows users have little idea of security and may be “owned by haxor”.
Otherwise, cookies (aside from session cookie PHP creates for you) are generally meant for long term (i.e. between visits) data persistence (e.g. “Remember Me”) rather than “active session” persistence.
Subscribe to:
Posts (Atom)