parma

auto SSH using expect

noreply@blogger.com (muhammad syafar AZ) — Tue, 25 Oct 2011 16:48:00 PDT

Intro
Expect is a Unix automation and testing tool, written by Don Libes as an extension to the Tcl scripting language, for interactive applications such as telnet, ftp, passwd, fsck, rlogin, tip, ssh, and others. It uses Unix pseudo terminals to wrap up subprocesses transparently, allowing the automation of arbitrary applications that are accessed over a terminal. With Tk, interactive applications can be wrapped in X11 GUIs.

Expect serves as a "glue" to link existing utilities together. The general idea is to try to figure out how to make Expect utilize the system's existing tools rather than figure out how to solve a problem inside of Expect.
A key usage of Expect involves commercial software products. Many of these products provide some type of command-line interface, but these usually lack the power needed to write scripts. They were built to service the users administering the product, but the company often doesn't spend the resources to fully implement a robust scripting language. An Expect script can spawn a shell, look up environmental variables, perform some Unix commands to retrieve more information, and then enter into the product's command-line interface armed with the necessary information to achieve the user's goal. After looking up information inside the product's command-line interface, the script can make an intelligent decision about what action to take, if any.

Heres a working expect TCL script that can be invoke easily from the unix console, very useful when handling alot of multiple unix machine, save the script as ssh.exp.

#!/usr/bin/expect -f
# modified from dearvoid (MSN: dearvoid@263.net) enable-auto-ssh.exp script
set prefix "\033\[1;31m>>>\033\[0m"

proc usage {} {
    regsub ".*/" $::argv0 "" name
    send_user "Usage:\n"
    send_user "    $name \[user@]host password\n"
    exit 1
}

proc check_id_files {} {
    if {! [file exists $::id_file]} {
  send_user "$::prefix id file not found, try creating ...\n"
  if {[catch { spawn ssh-keygen -t rsa } error]} {
      send_error "$::prefix $error\n"
      exit 1
  }
  expect -nocase -re "\(.*\):"
  send -- "\r"
  expect -nocase -re "passphrase.*:"
  send -- "\r"
  expect -nocase -re "passphrase.*again:"
  send -- "\r"
  expect eof
  send_user "$::prefix id file successfully created\n"
    }
}

proc remove_known_hosts_entry {host} {
    regsub ".*/" $::argv0 "" name
    set tmp_file "/tmp/$name.tmp"
    set known_hosts "$::env(HOME)/.ssh/known_hosts"
    send_user "$::prefix trying to remove '$host' from ~/.ssh/known_hosts ... "
    if {[catch {
  set fd_known_hosts [open $known_hosts r]
  set fdTmp [open $tmp_file w]
  while 1 {
      gets $fd_known_hosts line
      if [eof $fd_known_hosts] {
    break
      }
      if [regexp "(\[^, ]+,)*${host}(,\[^, ]+)* " $line] {
    continue
      }
      puts $fdTmp $line
  }
  close $fd_known_hosts
  close $fdTmp
  file rename -force $tmp_file $known_hosts
  send_user "OK\n"
    } error]} {
  send_user "failed\n"
  send_user "$::prefix $error\n"
  exit 1
    }
}

set user@host [lindex $argv 0]
set passwd [lindex $argv 1]
set cmd ""
set src ""
set dst ""
set address_pos ""
if {[llength $argv] == 3} {
    set cmd [lindex $argv 2]
}
if {[llength $argv] == 5} {
    set src [lindex $argv 2]
    set dst [lindex $argv 3]
    set address_pos [lindex $argv 4]
}


set id_file "$env(HOME)/.ssh/id_rsa.pub"

set yes_no 0
set ok_string SUCCESS
set timeout 66
set done 0
while {!$done} {
    spawn ssh ${user@host} echo $ok_string
    expect {
  -nocase -re "yes/no" {
      set yes_no 1
      send -- "yes\r"
      set done 1
  }
  -nocase -re "password: " {
      set done 1
  }
  $ok_string {
      send_user "$prefix ok\n"
      exit 0
  }
  "@@@@@@@@@@@@@@@@@@@@" {
      expect eof
      set indexOfAtSign [string first "@" ${user@host}]
      incr indexOfAtSign
      set hostname [string range ${user@host} $indexOfAtSign end]
      remove_known_hosts_entry $hostname
  }
  eof {
      send_error "$prefix failed\n"
      exit 1
  }
  timeout {
      send_error "$prefix timeout\n"
            exit 16
  }
    }
}

if {$yes_no} {
    expect {
  $ok_string {
      send_user "$prefix ok\n"
      exit 0
  }
  -nocase -re "password: " {}
    }
}
send -- "$passwd\r"
expect {
    -nocase "try again" {
  send_error "$prefix passwd error\n"

  exit 11

    }
  
    -nocase "password:" {
  send_error "$prefix passwd error\n"
  
  exit 11
  

  
    }
 
    $ok_string {}
}
expect eof

sleep 1 

set timeout 10806 

if {[llength $argv] == 3} {
  spawn ssh ${user@host} "$cmd"
}
if {[llength $argv] == 5} {
    if { $address_pos == "RIGHT"} {
      spawn /opt/dms/bin/scp_echo -r "$src" "${user@host}:$dst" 
    }
    if { $address_pos == "LEFT" } {
      spawn /opt/dms/bin/scp_echo -r "${user@host}:$src" "$dst"
    }
}
expect -nocase -re "password:"
send -- "$passwd\r"

expect {
   -nocase -re "--exit code=.*=" {   
          exit 0
   }                             
   timeout {
    exit 16
   }
}

## END

save the script as ssh.exp, and u can call it from unix console by using.

#ex, getting filelist from remote server : ssh.exp root@192.168.1.2 syafar123 "ls"
ssh.exp {user}@{ip_address} {passwd} "{standard unix command/remote script}"

my family

noreply@blogger.com (muhammad syafar AZ) — Sun, 04 Sep 2011 15:51:00 PDT

cucu Jambek

My nephews

my nieces

Happy Eid Mubarak 1432H

noreply@blogger.com (muhammad syafar AZ) — Wed, 31 Aug 2011 12:23:00 PDT

Happy Eid Mubarak 1432H all, may Allah accept our fasts and prayers from the holy month of Ramadhan. To all my family, mom, kakak, abang, younger sister and all my nephews and nieces, love u all.

Brief Introduction to the SMS System

noreply@blogger.com (muhammad syafar AZ) — Sat, 20 Aug 2011 10:28:00 PDT

The SMC is a service processing system independent of the mobile network. It is responsible for submitting, storing, and forwarding short messages (SMs). It implements the interconnection with such networks as the public switched telephone network (PSTN),
integrated services digital network (ISDN) and packet switched public data network (PSPDN) to transfer SMs between extended short message entities (ESMEs) and mobile stations (MSs).

The SMC supports the SMC running mode and the FDA running mode. The license decides which running mode is used in the SMC.

In the SMC running mode, the SMC stores and forwards the SMs.
In the FDA running mode, the SMC does not store the SMs. Instead, the SMC delivers the SM once only. When a delivery fails, the system forwards the SM to the SMC with the function of storing SMs.

SMS System in the GSM Network
The system architectures of the CDMA, TDMA, and GSM networks are quite similar. Each of the three network systems is composed of the following four parts:
�� Network subsystem (NSS)
�� Base station subsystem (BSS)
�� Operation and maintenance center (OMC)
�� A great many mobile stations (MSs)

there are interfaces between various subsystems and functional entities within the subsystems. The specifications in the CDMA, TDMA, and GSMnetworks stipulate standard interfaces and communication protocols through which the functional entities can implement communications coordinately. Adopting different interface specifications and protocols, the three mobile networks are independent of each other.

NSS
In the mobile network, the NSS mainly implements the switching function and database
function. The database function is necessary for subscriber data management, mobility
management and security management.The NSS includes the following functional entities:
�� MSC
The MSC controls calls, manages the communication service of MSs within the local network and with other networks (such as PSTN/ISDN/PSPDN, and other mobile networks), and provides the charging information. Besides, in order to set up call routes to MSs, the MSC can also function as the GMSC, that is, querying location information of MSs. Short messages submitted by the MS pass the BSS and reach the MSC. Then the MSC
forwards them to the corresponding SMC. After receiving the SMs delivered by the SMC, the MSC queries the VLR and the HLR for the related routing and subscriber information, and then delivers them to subscribers through BSS.
�� VLR
The visitor location register (VLR) stores the relevant information of registered subscribers in the control area, and provides the mobile subscribers with necessary conditions for call connection. It can be regarded as a dynamic database.
�� HLR
The home location register (HLR) is the central database of a mobile network. It stores the information of all mobile subscribers in the control area. The HLR stores two kinds of information: subscriber data, and location information of MSs for setting up call routes to the MSs.
�� AuC
The AuC stores authentication algorithm and encryption key, which prevent illegal subscribers from accessing the system, thus ensuring the security of the mobile subscribers' communications through the radio interface.
�� EIR
The EIR stores the International Mobile Equipment Identity (IMEI.). Generally the AuC and the EIR are integrated physically.

After receiving the SMs delivered by the SMC, the MSC queries the VLR and the HLR
for the related routing and subscriber information, and then delivers them to subscribers through BSS.
�� VLR
The visitor location register (VLR) stores the relevant information of registered
subscribers in the control area, and provides the mobile subscribers with necessary
conditions for call connection. It can be regarded as a dynamic database.
�� HLR
The home location register (HLR) is the central database of a mobile network. It stores the information of all mobile subscribers in the control area. The HLR stores two kinds of information: subscriber data, and location information of MSs for setting up call routes to the MSs.
�� AuC
The AuC stores authentication algorithm and encryption key, which prevent illegal
subscribers from accessing the system, thus ensuring the security of the mobile
subscribers' communications through the radio interface.
�� EIR
The EIR stores the International Mobile Equipment Identity (IMEI.). Generally the AuC
and the EIR are integrated physically.

OMC
The OMC is responsible for managing and controlling the whole GSM and CDMA networks.
MS
The MS is the mobile subscriber's device. It consists of the following two parts:
�� Mobile terminal (MT)
The MT implements such functions as voice coding, channel coding, information
encryption, information modulation and demodulation, information transmission and
reception.
�� Subscriber identity module/user identity module card (SIM/UIM card)The SIM/UIM card is an intelligent card, which keeps the subscriber identity information
and the management data related to the subscriber and network. An MT with an
SIM/UIM card inside can access the telecom network.

Position of the SMS System in the GSM Network
The position of the SMS system in the GSM network is as shown in the circle.
The physical entities related to the SMS system are the MSC, VLR and the HLR. Their
functions in the SM transmission are as follows:
�� MSC
− The SMs submitted by the MS pass the BSS and reach the MSC. Then the MSC
forwards them to the corresponding SMS system.
− After receiving the SMs delivered by the SMS system, the MSC queries the VLR and
the HLR for the related routing and subscriber information, and then delivers them to
subscribers through BSS.
�� VLR
The VLR stores the temporary information of a subscriber roaming in the local MSC
area. The subscriber must pass the authentication through the VLR before sending an SM,
and the MSC queries the route of a subscriber through the VLR before delivering an SM.
�� HLR
The HLR is a database for mobile subscriber management. It stores the subscription
information, position information, mobile station international ISDN number (MSISDN),
and international mobile station identity (IMSI) of a subscriber. Before delivering SM,
the SMS system finds which MSC the subscriber belongs to through the HLR.

Functions of the SMS System

This section describes the functions of the SMS system.
The functions of the SMS system are as follows:
�� Providing value-added services (VASs) and obtaining profits
As a basic telecom service of the mobile communication network, the SMS enables
subscribers to transmit information through SMs and obtain such useful information as
stock market, weather, sports and bank information, which greatly facilitates subscribers in getting information and gets subscribers into a better and closer relationship with operators. At the same time, operators can get direct revenue by providing VASs based on the SMS service.
�� Improving quality of service (QoS)
Mobile subscribers have high requirements for timely information transfer. In many
cases such as channel busy, masking or network coverage problems, communication is
difficult and information cannot be exchanged. With the SMS system, subscribers can
get information at the earliest time and smooth information transmission is ensured.
�� Improving connectivity and reducing congestion of the mobile network
According to statistics, over 30% of calls or faxes cannot be charged due to busy line or no reply, resulting in the waste of network resources. As a solution to this problem, the
SMS system can connect incoming calls manually or automatically and record the
information subscribers want to transmit, thus dredging the GSM network. In addition,the SMS system can reduce false load which is caused by repetitive dialing to an MS switched off, thus reducing network congestion.

Short message peer-to-peer protocol

noreply@blogger.com (muhammad syafar AZ) — Sat, 16 Oct 2010 15:59:00 PDT

The Short Message Peer-to-Peer (SMPP) protocol is a telecommunications industry protocol for exchanging SMS messages between SMS peer entities such as short message service centers and/or External Short Messaging Entities. It is often used to allow third parties (e.g. value-added service providers like news organizations) to submit messages, often in bulk.

SMPP was originally designed by Aldiscon, a small Irish company that was later acquired by Logica (now split off and known as Acision). In 1999, Logica formally handed over SMPP to the SMPP Developers Forum, later renamed as The SMS Forum and now disbanded. The SMPP protocol specifications are still available through the website which also carries a notice stating that it will be taken down at the end of 2007. As part of the original handover terms, SMPP ownership has now returned to Acision due to the disbanding of the SMS forum.

The protocol is based on pairs of request/response PDUs (protocol data units, or packets) exchanged over OSI layer 4 (TCP session or X.25 SVC3) connections. PDUs are binary encoded for efficiency.

The most commonly used versions of SMPP are v3.3, the most widely supported standard, and v3.4, which adds transceiver support (single connections that can send and receive messages). Data exchange may be synchronous, where each peer must wait for a response for each PDU being sent, and asynchronous, where multiple requests can be issued in one go and acknowledged in a skew order by the other peer. The latest version of SMPP is v5.0.

To date SMPP development is suspended and SMS forum is disbanded. From SMS forum website:

July 31, 2007 - The SMS Forum, a non-profit organization with a mission to develop, foster and promote SMS (short message service) to the benefit of the global wireless industry will disband by July 27, 2007

A press release, attached to the news, also warns that site will be suspended soon. In spite of this the site is still mostly functioning and specifications can still be downloaded (as of 23 December 2009).

Example

This is an example of the binary encoding of a 60-octet submit_sm PDU. The data is shown in Hex octet values as a single dump and followed by a header and body break-down of that PDU.

This is best compared with the definition of the submit_sm PDU from the SMPP specification in order to understand how the encoding matches the field by field definition.

The value break-downs are shown with decimal in parentheses and Hex values after that. Where you see one or several hex octets appended, this is because the given field size uses 1 or more octets encoding.

Again, reading the definition of the submit_sm PDU from the spec will make all this clearer.

Hexdump

00 00 00 3C 00 00 00 04 00 00 00 00 00 00 00 05 00 02 08 35 35 35 00 01 01
35 35 35 35 35 35 35 35 35

PDU Header

'command_length', (60) ... 00 00 00 3C
'command_id', (4) ... 00 00 00 04
'command_status', (0) ... 00 00 00 00
'sequence_number', (5) ... 00 00 00 05

PDU Body

'service_type', () ... 00
'source_addr_ton', (2) ... 02
'source_addr_npi', (8) ... 08
'source_addr', (555) ... 35 35 35 00
'dest_addr_ton', (1) ... 01
'dest_addr_npi', (1) ... 01
'dest_addr', (555555555) ... 35 35 35 35 35 35 35 35 35 00
'esm_class', (0) ... 00
'protocol_id', (0) ... 00
'priority_flag', (0) ... 00
'schedule_delivery_time', () ... 00
'validity_period', () ... 00
'registered_delivery', (0) ... 00
'replace_if_present_flag', (0) ... 00
'data_coding', (0) ... 00
'sm_default_msg_id', (0) ... 00
'sm_length', (15) ... 0F
'short_message', (Hello wikipedia) ... 48 65 6C 6C 6F 20 77 69 6B 69 70 65 64 69 61'

From Wikipedia, the free encyclopedia

VAS - Missed Call Alert system

noreply@blogger.com (muhammad syafar AZ) — Sat, 16 Oct 2010 15:52:00 PDT

The MCA Platform (MCAP) is a system intended to provide value-added information to subscribers by delivering notification messages called Who Called+ (WHC+) to the called party and Notify Me (NM) to the calling party.

Notification message generated due to several condition:

Off (absent subscriber)‏
Unreachable (detached or no coverage area, busy without call waiting)‏

Process flow overview

Location Based Service using MAP ATI

noreply@blogger.com (muhammad syafar AZ) — Sat, 16 Oct 2010 15:37:00 PDT

Overview

The terms mobile positioning and mobile location are sometimes used interchangeably in conversation, but they are really two different things. Mobile positioning refers to determining the position of the mobile device. Mobile location refers to the location estimate derived from the mobile positioning operation.

There are various means of mobile positioning, which can be divided into two major categories - network based and handset based positioning. The purpose of positioning the mobile is to provide location-based services (LBS), including wireless emergency services.

Mobile IN Technologies for Positioning - MAP ATI

Mobile IN can also be deployed to assist in the positioning process. GSM and ANSI-41 based networks may employ the use of the GSM MAP Any Time Interrogation (ATI) and Position Request (PosReq) messages respectively for positioning.

These mobile IN procedures entail a LBS application middle-ware as an Service Control Function (SCF) launching a message (MAP ATI or PosReq) to the HLR for position information. The HLR may respond with approximate information (such as the COO) or more precise information (such as TA or NMR as in the case with GSM).

The value of mobile IN is to leverage the SS7 and IN network to obtain location, especially for mid-call/session position updates. Mobile IN may also be quite valuable for idle call positioning, but requires integration on the mobile network side to ensure current position information is made available.

MAP-ATI is a service provided by the HLR (Home Location Register). This service will respond the CGI data related to an MSISDN (Cell ID, MCC, MNC, and LAC). Because HLR is such an important component in the network, access to the HLR must be in very tight control. Systems that may have direct interaction with the HLR are of course limited.

This is why MAP-ATI Gateway is built. MAP-ATI Gateway will act as a proxy for client applications which need the MAP-ATI service.

MAP-ATI Gateway system is comprised of the following components:
• Web Service
• Management Tool
• MAP-ATI Requester

Below diagram shows MAP-ATI Gateway application structure:

Push Protocol

noreply@blogger.com (muhammad syafar AZ) — Sat, 16 Oct 2010 15:15:00 PDT

1. Overview

Push protocol is an HTTP-based protocol that enables content applications to send an SMS to an MSISDN proactively and optionally receive its delivery report.

Below is a diagram that describes the interactions between the SMS Site Server and a content application.

The Push protocol defines:
• The HTTP POST/GET request for MT SMS from content applications to SMS Site Server
• The HTTP response XML from SMS Site Server to content applications, which acknowledges the MT SMS transmission request
• The HTTP GET request for delivery report from SMS Site Server to content applications
• The HTTP response from content applications to SMS Site Server acknowledging the delivery report

MT SMS: HTTP Request From Content to SMS Site Server

A content application sends an MT SMS to an MSISDN by sending HTTP POST/GET
request to SMS Site Server:

Simple Text Version: Request Parameters

Simple Text enables a content application to send an SMS text using the default alphabet with no delivery report. If parameter “text” is longer than 160 characters,

SMS Site Server will send two (2) or more MT SMS that form a concatenated long SMS as according to GSM 03.40.

Full Option: Request Parameters

Full Option enables a content application to send an SMS data including binary data such as Ringtones, Picture logos, WAP Push, etc. Full Option exposes the complete options for sending an SMS.

MT SMS: HTTP Response From SMS Site Server to Content

Upon receiving the HTTP request from a content application, SMS Site Server will respond back with HTTP status code 200 and a push response XML in the HTTP response body.

Serie A: Parma 1-1 Genoa

noreply@blogger.com (muhammad syafar AZ) — Sun, 19 Sep 2010 09:34:00 PDT

Match Summary (Sunday September 19, 2010 20:00)
Home Team	Final Score	Away Team
FC Parma	1 - 1	Genoa Cfc
Second Half
	1:1	86' - G.Mesto Chico'
	1:1	79' - - G.Sculli
V.Bojinov H.Crespo - 77'	1:1
C.Zaccardo - - 72'	1:1
	0:1	66' - R.Palacio G.Sculli'
	0:1	61' - M.Veloso H.Kharja'
M.Gobbi A.Candreva - 55'	0:1
	0:1	55' - - Rafinha
	0:1	52' - - L.Toni
First Half
	0:1	36' - - O.Milanetto
	0:1	35' - - M.Rossi
G.Paletta - - 29'	0:1
	0:1	28' - - L.Toni(pen)
C.Zaccardo - - 3'	0:0

Players
FC Parma		Genoa Cfc
Starting Lineup:
3.	Antonelli, Luca	1.	Eduardo
4.	Morrone, Stefano	3.	Dainelli, Dario
5.	Zaccardo, Cristian	4.	Criscito, Domenico
8.	Marques, Fernando	7.	Rossi, Marco
18.	Gobbi, Massimo	8.	Palacio, Rodrigo Sebastian
21.	Giovinco, Sebastian	9.	Toni, Luca
24.	Paci, Massimo	16.	Ranocchia, Andrea
29.	Paletta, Gabriel	18.	Rafinha
80.	Valiani, Francesco	20.	Mesto, Giandomenico
83.	Mirante, Antonio	42.	Veloso, Miguel
86.	Bojinov, Valeri	77.	Milanetto, Omar
Available Subs:
1.	Pavarini, Nicola	2.	Chico
7.	Candreva, Antonio	11.	Kharja, Houssine
9.	Crespo, Hernan	13.	Kaladze, Kakha
10.	Dzemaili, Blerim	14.	Sculli, Giuseppe
13.	Angelo	22.	Destro, Mattia
26.	Pisano, Marco	24.	Moretti, Emiliano
51.	Dellafiore, Hernan	73.	Scarpi, Alessio

Serie A: Catania 2-1 Parma

noreply@blogger.com (muhammad syafar AZ) — Sun, 12 Sep 2010 10:59:00 PDT

Match Summary (Sunday September 12, 2010 20:00)
Home Team	Final Score	Away Team
Calcio Catania	2 - 1	FC Parma
Second Half
	2:1	90' - - A.Lucarelli
	2:1	90' - - S.Giovinco
M.Antenucci(pen) - - 82'	2:0
M.Lopez M.Antenucci - 79'	1:0
	1:0	74' - - L.Antonelli
A.Potenza - - 69'	1:0
	1:0	62' - V.Bojinov H.Crespo'
	1:0	62' - M.Gobbi A.Candreva'
M.Izco A.Gomez - 58'	1:0
A.Ricchiuti E.Carboni - 57'	1:0
First Half
	1:0	41' - - F.Valiani
	1:0	27' - - A.Lucarelli
	1:0	26' - - V.Bojinov
	1:0	18' - - M.Paci
G.Mascara(pen) - - 12'	1:0

Players
Calcio Catania		FC Parma
Starting Lineup:
6.	Silvestre, Matias	3.	Antonelli, Luca
7.	Mascara, Giuseppe	4.	Morrone, Stefano
8.	Ledesma, Pablo	5.	Zaccardo, Cristian
11.	Lopez, Maxi	6.	Lucarelli, Alessandro
13.	Izco, Mariano Julio	8.	Marques, Fernando
19.	Ricchiuti, Adrian	18.	Gobbi, Massimo
21.	Andujar, Mariano	21.	Giovinco, Sebastian
22.	Potenza, Alessandro	24.	Paci, Massimo
23.	Spolli, Nicolas Federico	80.	Valiani, Francesco
27.	Biagianti, Marco	83.	Mirante, Antonio
33.	Capuano, Ciro	86.	Bojinov, Valeri
Available Subs:
2.	Alvarez, Pablo	1.	Pavarini, Nicola
3.	Terlizzi, Christian	7.	Candreva, Antonio
4.	Delvecchio, Gennaro	9.	Crespo, Hernan
5.	Carboni, Ezequiel Alejo	10.	Dzemaili, Blerim
9.	Antenucci, Mirko	26.	Pisano, Marco
17.	Gomez, Alejandro	29.	Paletta, Gabriel
30.	Campagnolo, Andrea	51.	Dellafiore, Hernan

Serie A: Parma 2-0 Brescia

noreply@blogger.com (muhammad syafar AZ) — Fri, 03 Sep 2010 21:05:00 PDT

Match Summary (Monday August 30, 2010 01:45)
Home Team	Final Score	Away Team
FC Parma	2 - 0	Brescia Calcio
Second Half
S.Giovinco M.Coppola - 85'	2:0
M.Gobbi M.Pisano - 81'	2:0
	2:0	80' - A.Caracciolo R.Feczesin'
V.Bojinov A.Paloschi - 68'	2:0
	2:0	62' - A.Diamanti Eder'
	2:0	56' - - D.Zoboli
	2:0	55' - A.Budel Cordova'
First Half
S.Morrone - - 45'	2:0
	1:0	45' - - G.Martinez
	1:0	18' - - S.Dallamano
V.Bojinov - - 11'	1:0

Players
FC Parma		Brescia Calcio
Starting Lineup:
3.	Antonelli, Luca	2.	Zoboli, Davide
4.	Morrone, Stefano	6.	Bega, Francesco
5.	Zaccardo, Cristian	8.	Vass, Adam
6.	Lucarelli, Alessandro	9.	Caracciolo, Andrea
8.	Marques, Fernando	12.	Leali, Nicola
18.	Gobbi, Massimo	15.	Zambelli, Marco
21.	Giovinco, Sebastian	18.	Possanzini, Davide
24.	Paci, Massimo	19.	Budel, Alessandro
80.	Valiani, Francesco	22.	Sereni, Matteo
83.	Mirante, Antonio	23.	Dallamano, Simone
86.	Bojinov, Valeri	26.	Martinez, Gilberto
Available Subs:
1.	Pavarini, Nicola	1.	Arcari, Michele
9.	Crespo, Hernan	7.	Eder
10.	Dzemaili, Blerim	11.	Cordova
11.	Paloschi, Alberto	14.	Feczesin, Robert
26.	Pisano, Marco	17.	Baiocco, Davide
29.	Paletta, Gabriel	21.	De Maio, Sebastian
32.	Coppola, Manuel	28.	Berardi, Gaetano
51.	Dellafiore, Hernan

PARMA : Transfer Market 2010/11

noreply@blogger.com (muhammad syafar AZ) — Sun, 01 Aug 2010 07:39:00 PDT

Gabriel Paletta, 23, adalah terbaru Parma FC tiba beberapa hari lalu dari Boca Juniors. Pemain tengah Argentina menjanjikan, sudah datang ke Eropa untuk Liverpool beberapa tahun yang lalu, sekarang di Italia dengan maksud untuk mengungkapkan kepada masyarakat umum dan tidak membiarkan ini kesempatan kedua untuk melarikan diri. Berikut adalah laporan pemain selama presentasi resminya kemarin: "Saya memilih Parma karena merupakan kesempatan yang sangat baik untuk kembali ke sepakbola Eropa. Klub telah membuat proposal yang senang dan aku diterima. Saya adalah seorang pendukung kuat, ketika aku masuk lapangan, fans akan mengakui kemampuan saya. Saya selalu bermain di empat kembali. Namun, aku tidak memiliki masalah bermain kembali tiga. Aku memutar kembali pusat. Saya berharap untuk segera membicarakan dengan Hernan Crespo, yang akan menceritakan semua Parma. "

Transfer Market 2010/11

Transfers IN

DF	Bright Addae	All Stars FC	FULL TRANSFER
DF	Rolf Feltscher	Grasshopper	FULL TRANSFER
GK	Antonio Mirante	Sampdoria	FULL TRANSFER
DF	Luca Tedeschi	Treviso	FULL TRANSFER
DF	Filipe Oliveira	Braga	FULL TRANSFER
MF	José Fernando Marqués	Espanyol	FULL TRANSFER
ST	Valeri Bojinov	Manchester City	FULL TRANSFER
DF	Gabriel Paletta	Boca Juniors	FULL TRANSFER
MF	Francesco Lunardini	Rimini Calcio	FULL TRANSFER
ST	Alberto Paloschi	A.C. Milan	CO-OWNERSHIP
DF	Andrea Rispoli	Brescia	CO-OWNERSHIP
ST	Milan Djuric	Cesena	CO-OWNERSHIP
MF	Blerim Dzemaili	Torino	CO-OWNERSHIP
MF	Gabriele Paonessa	Bologna	CO-OWNERSHIP
MF	Daniele Galloppa	Siena	CO-OWNERSHIP
DF	Marcos Diniz	A.C. Milan	LOAN
MF	Ze Eduardo	Mago	LOAN
DF	Marco Rossi	Sampdoria	LOAN RETURN
DF	Pablo Fontanello	Tigre	LOAN RETURN
MF	Manuel Coppola	Torino	LOAN RETURN
ST	Julio César de León	Torino	LOAN RETURN
MF	Cristiano Lucarelli	Livorno	LOAN RETURN

Transfers OUT

ST	Jonathan Biabiany	Inter Milan	FULL TRANSFER
MF	McDonald Mariga	Inter Milan	FULL TRANSFER
MF	Nicolas Cordova	Brescia	FULL TRANSFER
MF	Alessandro Budel	Brescia	FULL TRANSFER
MF	Daniele Dessena	Sampdoria	FULL TRANSFER
ST	Julio Cesár de León	Shandong Luneng	FULL TRANSFER
ST	Daniele Paponi	Bologna	CO-OWNERSHIP
ST	Reginaldo	Siena	CO-OWNERSHIP
DF	Paolo Hernán Dellafiore	Palermo	LOAN RETURN
ST	Davide Lanzafame	Palermo	LOAN RETURN
DF	Pablo Fontanello	Gimnasia	LOAN
MF	Pietro Baccolo	Südtirol-Alto Adige	LOAN
DF	Marco Rossi	Bari	LOAN
ST	Riccardo Pasi	Modena	LOAN
DF	Damiano Zenoni	Contract Expired	FREE TRANSFER
Last updated 31 July 2010

PARMA : Serie A 2010/11 fixtures

noreply@blogger.com (muhammad syafar AZ) — Sun, 01 Aug 2010 07:28:00 PDT

The fixture list for the 2010/11 Serie A season was released tonight during the official presentation in Milan.

Parma will kick off their Serie A campaign at home to newly promoted Brescia on Sunday 28 August 2010.

While Parma’s closing fixture is also at home against Cagliari on Sunday 22 May 2011.

Other fixtures of note include the Emilia Romagna derbies against Cesena and Bologna on Sundays October 17 and December 19 respecitively.

While Parma fans will have to wait until the new year to face Juventus in the first match after the winter break on Thursday 06 January 2011.

July

SAT 17	Levico	0-8	Parma	Levico Terme	400	Pre Season
WED 21	Parma	2-0	Feralpi Salò	Levico Terme	400	Pre Season
THU 22	Parma	8-0	US Borgo	Levico Terme	400	Pre Season
SUN 25	Parma	3-1	Spal	Levico Terme	400	Pre Season
FRI 30	Parma	1-2	Al Sadd	Levico Terme	300	Pre Season

August

THU 05	Parma	-	R.Santander	Ennio Tardini	Pre Season
SAT 07	Parma	-	Cesena	Ennio Tardini	Pre Season
SAT 07	Parma	-	Chievo	Ennio Tardini	Pre Season
SAT 21	Parma	-	Deportivo	Ennio Tardini	Pre Season
SUN 29	Parma	-	Brescia	Ennio Tardini	Serie A TIM

September

SUN 12	Catania	-	Parma	Angelo Massimino	Serie A TIM
SUN 19	Parma	-	Genoa	Ennio Tardini	Serie A TIM
WED 22	Lecce	-	Parma	Via del Mare	Serie A TIM
SUN 26	Fiorentina	-	Parma	Artemio Franchi	Serie A TIM

October

SUN 03	Parma	-	Milan	Ennio Tardini	Serie A TIM
SUN 17	Cesena	-	Parma	Dino Manuzzi	Serie A TIM
SUN 24	Parma	-	Roma	Ennio Tardini	Serie A TIM
SUN 31	Parma	-	Chievo	Ennio Tardini	Serie A TIM

November

SUN 07	Napoli	-	Parma	San Paolo	Serie A TIM
WED 10	Parma	-	Sampdoria	Ennio Tardini	Serie A TIM
SUN 14	Bari	-	Parma	San Nicola	Serie A TIM
SUN 21	Parma	-	Lazio	Ennio Tardini	Serie A TIM
SUN 28	Inter Milan	-	Parma	San Siro	Serie A TIM

December

SUN 05	Parma	-	Udinese	Ennio Tardini	Serie A TIM
SUN 12	Palermo	-	Parma	Renzo Barbera	Serie A TIM
SUN 19	Parma	-	Bologna	Ennio Tardini	Serie A TIM

January

THU 06	Juventus	-	Parma	Olimpico di Torino	Serie A TIM
SUN 09	Parma	-	Cagliari	Ennio Tardini	Serie A TIM
WED 12	Parma	-	TBA	Ennio Tardini	Coppa Italia
SUN 16	Brescia	-	Parma	Mario Rigamonti	Serie A TIM
SUN 23	Parma	-	Catania	Ennio Tardini	Serie A TIM
SUN 30	Genoa	-	Parma	Luigi Ferraris	Serie A TIM

February

WED 02	Parma	-	Lecce	Ennio Tardini	Serie A TIM
SUN 06	Parma	-	Fiorentina	Ennio Tardini	Serie A TIM
SUN 13	Milan	-	Parma	Giuseppe Meazza	Serie A TIM
SUN 20	Parma	-	Cesena	Ennio Tardini	Serie A TIM
SUN 27	Roma	-	Parma	Olimpico	Serie A TIM

March

SUN 06	Chievo	-	Parma	Marc’Antonio Bentegodi	Serie A TIM
SUN 13	Parma	-	Napoli	Ennio Tardini	Serie A TIM
SUN 20	Sampdoria	-	Parma	Luigi Ferraris	Serie A TIM

April

SUN 03	Parma	-	Bari	Ennio Tardini	Serie A TIM
SUN 10	Lazio	-	Parma	Olimpico	Serie A TIM
SUN 17	Parma	-	Inter Milan	Ennio Tardini	Serie A TIM
SUN 24	Udinese	-	Parma	Friuli	Serie A TIM

May

SUN 01	Parma	-	Palermo	Ennio Tardini	Serie A TIM
WED 08	Bologna	-	Parma	Renato Dall’Ara	Serie A TIM
SUN 15	Parma	-	Juventus	Ennio Tardini	Serie A TIM
SUN 22	Cagliari	-	Parma	Sant’Elia	Serie A TIM

iSMS Protocol

noreply@blogger.com (muhammad syafar AZ) — Fri, 25 Jun 2010 13:58:00 PDT

Overview

iSMS protocol is an HTTP-based protocol that enables the SMS Site Server to pass a mobile originating (MO) SMS to a content application/service and get a response back from the content application that will be sent back to the originating mobile as a mobile terminated (MT) SMS. iSMS protocol also includes a mechanism of passing a delivery report from SMS Site Server to a content application.

The iSMS protocol defines:
• The HTTP POST request for MO SMS from SMS Site Server to content applications
• The iSML (Interactive SMS Markup Language) that a content application must send
back to SMS Site Server in the HTTP response for MO SMS
• The HTTP GET request for delivery report from SMS Site Server to content
applications
• The HTTP response from content applications to SMS Site Server acknowledging the
delivery report

iSMS Protocol Description

When a mobile sends an SMS that is received by SMS Site Server from the SMSC, SMS Site Server will decide which content application the MO SMS belongs to and forward it to the correct one.

iSML Description

iSML is an XML document that defines the SMS response from a content application.
Example of a simple iSML response:

Hello World!

When SMS Site Server receives the above iSML from a content, it will send an MT SMS
back to the originating mobile containing the text “Hello World!”
Example of an empty iSML response:

When SMS Site Server receives the above iSML from a content, it will not send any MT
SMS back to the originating mobile.

Interactive Session

The previous iSML examples are simple, i.e. a mobile sends an MO SMS and the content
sends back a reply MT SMS and it stops there.

Interactive SMS Session Example

User sends an SMS, which will be routed to the survey content service.
The content service will respond back with an SMS prompting the user to enter his
name.When the system receives the name, it will send back the first survey question and so
forth. This kind of survey application can be implemented with the following iSML
documents:

First document:

Halo, terima kasih atas ketersediaan anda ikut survey
Silakan ketik nama anda.

In the above iSML example, whatever response the user sends will cause the SMS Site Server
to issue an HTTP POST request to URI path /savename.jsp (the same host and port as the
current context), passing the usual header and request parameters (see section 2.1 MO SMS:
HTTP Request From SMS Site Server To Content).
Your application at /savename.jsp should process the SMS, which should contain the user
name. Then your application will produce the following second document (either by
redirecting to another URL or outputting it directly on the response).
Second document (after you process the user name in /savename.jsp in the above example):

<%=username%>, setujukan anda Abubakar Baasyir divonis 4 tahun sebagai
teroris?
SETUJU
TIDAK

This time the above document tells the SMS Site Server to send back an SMS to the user and
present the two options, i.e. SETUJU or TIDAK. When the user responds with an SMS
“SETUJU”, the SMS Site Server knows that it has to issue an HTTP POST request to the
URL /setuju.jsp.

If the user responds with an SMS other than SETUJU or TIDAK (and assuming there is no
other application matching that answer keyword defined for the short code), SMS Site Server will issue an HTTP POST request to URL /showhelp.jsp, as indicated by the nomatch element.

Note that in order to take advantage of this feature, the interactive session must be explicitly enabled for your content application. Please contact the operator administrator.

iSML DTD

Introduction to All-IP Network (AIPN)

noreply@blogger.com (muhammad syafar AZ) — Thu, 20 May 2010 13:53:00 PDT

The All-IP Network (AIPN) is an evolution of the 3GPP system to meet the increasing demands of the mobile telecommunications market. Primarily focused upon enhancements of packet switched technology, AIPN provides a continued evolution and optimisation of the system concept in order to provide a competitive edge in terms of both performance and cost. Moreover, it is important that developments of the 3GPP system are compliant with Internet protocols. The AIPN is not limited to consideration of only the transport protocol used within the 3GPP system but adheres to the general concept of a network based upon IP and associated technologies, able to accommodate a variety of different access systems. Although, it is possible to use a variety of different access systems to connect to the AIPN, the AIPN provides an advanced, integrated service set independent as far as possible from the access system used.

The high level objectives of introduction of the AIPN are to realise:

universal seamless access
improved user experience
reduction of cost (for AIPN operators)
flexibility of deployment.

There are also a number of motivations and drivers for the introduction of the AIPN which include but are not limited to:

diversification of mobile services
need to satisfy user experience of early adopters
anticipation of PS traffic to surpass CS
desire to encompass a variety of access systems
need for increased system efficiency and cost reduction (OPEX and CAPEX) and
advances of next generation radio access systems and broadband wireless IP-based networks.

The key aspects of the AIPN can be summarised as follows:

Support for a variety of different access systems
Common capabilities provided independent to the type of service provided with convergence to IP technology considered from the perspective of the system as a whole
High performance mobility management that provides end-user, terminal and session mobility
Ability to adapt and move sessions from one terminal to another
Ability to select the appropriate access system based on a range of criteria
Provision of advanced application services as well as seamless and ubiquitous services
Ability to efficiently handle and optimally route a variety of different types of IP traffic including user-to-user, user-to-group and ubiquitous service traffic models
High level of security and support for user privacy e.g. location privacy, identity privacy
Methods for ensuring QoS within and across AIPNs
Appropriate identification of terminals, subscriptions and users
Federation of identities across different service providers

Further Reading:
3GPP TS 22.258: Service Requirements for the All-IP Network (AIPN);
Stage 1

3GPP TR 22.978: All-IP Network (AIPN) feasibility study

http://3g4g.blogspot.com

Cell Broadcast

noreply@blogger.com (muhammad syafar AZ) — Thu, 20 May 2010 13:29:00 PDT

Cell Broadcast (CB) messaging is a mobile technology feature defined by the ETSI’s GSM committee and is part of the GSM standard. It is also known as Short Message Service - Cell Broadcast (SMS-CB). Cell Broadcast is designed for simultaneous delivery of messages to multiple users in a specified area. Whereas the Short Message Service - Point to Point (SMS-PP) is a one-to-one and one-to-a-few service, Cell Broadcast is a one-to-many geographically focused messaging service. Cell Broadcast messaging is also supported by UMTS, as defined by 3GPP.

Cell Broadcast messaging was technologically demonstrated in Paris for the first time in 1997. Some mobile operators use Cell Broadcast for communicating the area code of the antenna cell to the mobile user (via channel 050), for nationwide or citywide alerting, weather reports, mass messaging, location based news, etc. Not all operators have the Cell Broadcast messaging function activated in their network yet, and many handsets do not have the capability to support cell broadcast.

Cell Broadcast is a technology that allows a text or binary message to be defined and distributed to all mobile terminals connected to a set of cells. Whereas SMS messages are sent point-to-point, Cell Broadcast messages are sent point-to-area. This means that one Cell Broadcast message can reach a huge number of terminalsa at once. In other words, Cell Broadcast messages are directed to radio cells, rather than to a specific terminal. A Cell Broadcast message is an unconfirmed push service, meaning that the originator of the message does not know who has received the message, allowing for services based on anonymity. Mobile telephone user manuals describe how the user can switch the receiving of Cell Broadcast messages on or off.

Cell Broadcast messaging has a number of features that make it particularly appropriate for emergency purposes:

* It is not as affected by traffic load; therefore, it may be usable during a disaster when load spikes tend to crash networks, as the 7 July 2005 London bombings showed. Another example was during the Tsunami catastrophe in Asia. Dialog GSM, an operator in Sri Lanka was able to provide ongoing emergency information to its subscribers, to warn of incoming waves, to give news updates, to direct people to supply and distribution centres, and even to arrange donation collections using Celltick's Cell Broadcast Center, based on Cell Broadcast Technology.

Cell broadcast is widely deployed since year 2008. In Europe, most handsets do have cell broadcast capability, and the major European operators have deployed the technology in their networks.

Cell Broadcast is a mobile technology that allows messages (up to 15 pages of up to 93 characters) to be broadcast to all mobile handsets and similar devices within a designated geographical area. The broadcast range can be varied, from a single cell to the entire network.

Technology

Cell Broadcast Entities (CBE) are connected to the Cell Broadcast Centre. Cell Broadcast messages are then sent from the Cell Broadcast Centres to the cells, in accordance with the CBC's coverage requirements. Advanced infrastructures make use of GIS-based interfaces for definition of the used areas.

A Cell Broadcast message page comprises 82 octets, which, using the default character set, equates to 93 characters. Up to 15 of these pages may be concatenated to form a Cell Broadcast message. Each page of such a CB message will have the same message identifier (indicating the source of the message), and the same serial number. Using this information, the mobile telephone is able to identify and ignore broadcasts of already received messages.

Cell Broadcast doesn't use the frequency space reserved for call setup, calls and data but a separate specially defined area. This area is divided into 65,000 channels, the channels from 0 to 999 can be switched on by the terminal user, from 999 to 65,000 can only be switched on via OTA (over-the-air activation) but all channels can be switched off by the user. Cell Broadcast will be more useful when it keep continuing from 2G network to 3G network and future technology with some sound which can alert the user in case of an emergency rather than just broadcast message which will be more meaningful.

Broadcast messages will be used in the United States to send emergency alerts, using the CMAS C-interface protocol, which has been specified jointly by ATIS and TIA. All four major providers have agreed to take part.

SMS Cell Broadcast

SMS Cell Broadcast is designed for simultaneous delivery of messages to multiple users in a specified area. Whereas the Short Message Service (SMS) is a one-to-one and one-to-a-few service, Cell Broadcast is one-to-many geographically focused service. It enables messages to be communicated to multiple mobile phone customers who are located within a given part of its network coverage area at the time the message is broadcast. Cell Broadcast is more akin to other mass distribution media such as teletext or Radio Data System (RDS).

SMS Cell Broadcast is defined within Phase 2 of the GSM standard in GSM 03.49. Cell Broadcast has some similarities with SMS since both services use the GSM network's signaling path. A (Each) Cell Broadcast message may be from 1 to 15 pages in length. Each page can be up to 93 alphanumeric characters or 82 octets of binary data in length. Additionally, up to 15 Cell Broadcast messages can be concatenated. Cell Broadcast messages are transmitted to the applicable Base Station Controllers (BSCs) for subsequent broadcast. The Message Destination is described in terms of cell identifiers which the BSC uses to route the message content to Base Transceiver Station Cells. Messages are broadcast for a user defined number of broadcasts with a user specified broadcast repetition rate. Cell Broadcast messages may be updated or removed from the BSC and subsequent BTS/ Cells anytime during the message broadcast period. (The BTSs are selected to determine the area over which the message is broadcast).

On Cell Broadcast the GSM operators send different news or data. Often they offer business news, weather forcast and so one. The German GSM operator Mannesmann D2 offers a way to build your own Cell Broadcast channel. The costs of that service will be charged to the owner of the service, to the user of that service or the costs can be shared.

The potential of Cell Broadcast technology

The ability to broadcast messages has been around since the GSM Phase 2 Technology Specification was introduced in 1995. However, only in the last few years have network operators, started to deploy cell broadcast-based services.

Why did they take so long? The answer is simple: business managers at wireless operators did not think they could generate a profit with a one-directional, subscriptionless broadcast service. However, it is now clear that cell broadcast is a useful service with profit potential that enables operators to provide broadcast information to specifically targeted subgroups of their subscriber base.

In today's handsets, selecting a channel can be a tedious task. Another helpful GSM feature is "Over the Air programming of the SIM card." Potentially, subscribers could select their preferred channels on the carrier's Web site and have them downloaded onto the SIM card in their handsets via this technology (under full control of the carrier).

Cell broadcast technology is in an early adoption stage in North America. The technology is available, but work needs to be done to package it and offer it as a product to subscribers. For GSM network operators, it is a challenge to define services that will use the cell broadcast capability of their network. Currently a cell broadcast service is also being defined for CDMA. It is a matter of time before the first cell broadcast-based service will be launched in the U.S. This is yet another opportunity for GSM operators to differentiate themselves from PCS competitors.

wiki

Session Initiation Protocol and Session Description Protocol

noreply@blogger.com (muhammad syafar AZ) — Thu, 20 May 2010 12:43:00 PDT

The two standard protocols that govern session control are the Session Initiation Protocol (SIP) and Session Description Protocol (SDP). These standards were originally intended for loosely controlled multimedia conferencing over the Internet; however, they have developed into a functional alternative to the H.323 suite. In particular, the combination of SIP and SDP is functionally equivalent to that of H.225.0 and H.245.

SIP (see RFC 2543) was initially standardized by the Multiparty Multimedia Session Control (mmusic) (see www.ietf.org/html.charters/mmusic-charter.html ) working group in the IETF Transport area. As the work had grown, a specialized SIP working group was created (see www.ietf.org/html.charters/sip-charter.html ).

SIP was designed to create and tear down multimedia sessions. In its syntax, SIP is similar to the Hypertext Transfer Protocol (HTTP)—defined in RFC 2616—and it reuses many HTTP header fields (such as authentication). Like HTTP, SIP is ASCII text encoded. Unlike HTTP, however, SIP was developed with the intention of addressing human users, for which reason the uniform resource identifier (URI) defined by SIP looks more like an e-mail address than the address of a World Wide Web page. For example, sip:hui-lan.lu@bell-labs.com is a SIP URI. For the purposes of integrating the PSTN and the Internet, it is important to note that SIP message headers can also carry other URIs (such as telephone URLs, defined by the IETF).

SIP is a client-server protocol: A client generates a request, to which a server sends one or more responses. A (potential) session participant can both generate and receive requests, which suggests that the end systems should have both the client and server capabilities. SIP also supports transaction capabilities. The RFC 2543 definition of a transaction is:

A SIP transaction occurs between a client and a server and comprises all messages from the first request sent from the client to the server up to a final . . . response sent from the server to the client.

Transactions are assigned the command sequence (CSeq) numbers. The SIP nomenclature (similar to that of SNMP and HTTP) alludes to the object-oriented model by defining the following methods that are carried in SIP requests (one method per request):

INVITE. Conveys the information about the call to invited participants. It is issued in order to set up a call, and once the call is set up, it can be issued by any party to the call in order to change the call parameters or to add another party.
BYE. Terminates a connection.
OPTIONS. Solicits information about a user’s capabilities.
CANCEL. Terminates the search for the user.
REGISTER. Makes the user’s location known to a SIP server.
ACK. Invokes the reliable message exchange for invitations. (Note that SIP has its own mechanism for invitation exchange; thus, it can run on top of an unreliable transport layer protocol such as UDP.)

The invitation to a session is accompanied by the Session Description Protocol (SDP) defined in RFC 2327, also developed by the mmusic working group (WG). SDP provides the description format (not the protocol) of the multicast and unicast addresses, the number and types (that is, audio, video, data, control) of streams involved, the codecs involved (that is, the payload types to be carried by the transport protocol), the transport protocol itself (for example, RTP or H.320), the UDP port, the list of starting and stopping times of the session, encryption keys, and so on. Keep in mind that SDP is only one possible payload of SIP; SIP can also carry all Multipurpose Mail Extensions (MIME) types, for example.

In the following section, we discuss location of clients and servers. In a perfectly valid degenerated case, both a client and server can be located in the same host. The opposite extremity, which is strategic to network-wide applications of SIP, is when several SIP servers located in different hosts act as proxies. In this case, server A, after having received a request from a client, may consult a local directory (by using LDAP, for example), only to find out that there is another SIP server, server B, which is better suited to respond to the request. Server A forwards the request to server B, which, from now on, will route its responses through server A.

The proxies can form a routing chain of any length. Figure 1 demonstrates such a chain. You have probably noticed a striking similarity between this figure and Figure 1. This similarity is actually profound, and it has been among the major factors that have influenced the pint working group to adopt SIP as the foundation of the PINT Protocol. SIP also offers a natural solution to the problem of gateway discovery, which is being worked on in the IP Telephony (iptel) working group (www.ietf.org/html.charters/iptel-charter.html).

Figure 1: SIP routing.

http://simple-telecom.blogspot.com

Serie A : Parma 4 - 1 Livorno

noreply@blogger.com (muhammad syafar AZ) — Sun, 16 May 2010 16:24:00 PDT

Match Summary (Sunday May 16, 2010 20:00)
Home Team	Final Score	Away Team
FC Parma	4 - 1	AS Livorno
Second Half
H.Crespo - - 90'	4:1
	3:1	72' - - T.Danilevicius
A.Lucarelli Jimenez, Luis - 64'	3:0
	3:0	64' - C.Bellucci D.Marchini'
Biabiany, Jonathan V.Bojinov - 61'	3:0
	3:0	55' - M.Lignani L.Simeoni'
S.Morrone - - 49'	3:0
D.Lanzafame - - 46'	2:0
First Half
D.Lanzafame - - 45'	1:0
A.Mirante N.Pavarini - 44'	0:0
	0:0	22' - F.Galante W.Oussou'
A.Lucarelli - - 10'	0:0

Players
FC Parma		AS Livorno
Starting Lineup:
3.	Antonelli, Luca	6.	Galante, Fabio
4.	Morrone, Stefano	8.	Bergvold, Martin
5.	Zaccardo, Cristian	9.	Danilevicius, Tomas
6.	Lucarelli, Alessandro	20.	Bellucci, Claudio
9.	Lanzafame, Davide	22.	Prutsch, Jürgen
14.	Galloppa, Daniele	26.	Lignani, Matteo
15.	Dellafiore, Hernan	44.	Bernardi, Alessandro
20.	Biabiany, Jonathan	77.	Raimondi, Cristian
77.	Crespo, Hernan	87.	Vitale, Luigi
80.	Valiani, Francesco	91.	Modica, Samuele
83.	Mirante, Antonio	92.	Bardi, Francesco
Available Subs:
1.	Pavarini, Nicola	1.	De Lucia, Alfonso
7.	Castellini, Paolo	5.	Marchini, Davide
8.	Lunardini, Francesco	19.	Di Gennaro, Davide
10.	Dzemaili, Blerim	24.	Mozart
11.	Jimenez, Luis	30.	Oussou, W.
34.	Gigli, Abel	46.	Pieri, Mirko
86.	Bojinov, Valeri	90.	Simeoni, Luca

Serie A : Juventus 2 - 3 Parma

noreply@blogger.com (muhammad syafar AZ) — Sun, 09 May 2010 12:28:00 PDT

Match Summary (Sunday May 9, 2010 14:00)
Home Team	Final Score	Away Team
Juventus Turin	2 - 3	FC Parma
Second Half
V.Iaquinta - - 90'	2:3
	1:3	84' - - J.Biabiany
P.De Ceglie F.Grosso - 81'	1:2
	1:2	78' - Crespo, Hernan P.Castellini'
C.Poulsen D.Trezeguet - 76'	1:2
P.De Ceglie - - 73'	1:2
	1:2	66' - D.Lanzafame F.Lunardini'
Diego A.Candreva - 62'	1:2
First Half
	1:2	40' - - D.Lanzafame
	1:1	29' - - D.Galloppa
	1:1	20' - - D.Lanzafame
A.Del Piero - - 16'	1:0

Players
Juventus Turin		FC Parma
Starting Lineup:
1.	Buffon, Gianluigi	3.	Antonelli, Luca
2.	Caceres, Martin	4.	Morrone, Stefano
3.	Chiellini, Giorgio	5.	Zaccardo, Cristian
4.	Melo, Felipe	6.	Lucarelli, Alessandro
5.	Cannavaro, Fabio	9.	Lanzafame, Davide
8.	Marchisio, Claudio	14.	Galloppa, Daniele
9.	Iaquinta, Vincenzo	15.	Dellafiore, Hernan
10.	Del Piero, Alessandro	20.	Biabiany, Jonathan
18.	Poulsen, Christian	77.	Crespo, Hernan
28.	Diego	80.	Valiani, Francesco
29.	De Ceglie, Paolo	83.	Mirante, Antonio
Available Subs:
6.	Grosso, Fabio	1.	Pavarini, Nicola
11.	Amauri	7.	Castellini, Paolo
13.	Manninger, Alex	8.	Lunardini, Francesco
16.	Camoranesi, Mauro	16.	Baccolo, Pietro
17.	Trezeguet, David	30.	Dall Agnol Vinicius, Fedrigo
26.	Candreva, Antonio	86.	Bojinov, Valeri
33.	Legrottaglie, Nicola	90.	Pasi, Riccardo

Serie A : Parma 1 - 2 Roma

noreply@blogger.com (muhammad syafar AZ) — Sun, 02 May 2010 07:17:00 PDT

Match Summary (Saturday May 1, 2010 23:00)
Home Team	Final Score	Away Team
FC Parma	1 - 2	Roma
Second Half
	1:2	90' - F.Totti Baptista, Julio'
	1:2	90' - - F.Totti
Jimenez, Luis - - 88'	1:2
D.Lanzafame - - 86'	1:2
D.Lanzafame - - 82'	1:2
	0:2	75' - - R.Taddei
B.Dzemaili D.Lanzafame - 64'	0:1
A.Lucarelli - - 58'	0:1
B.Dzemaili - - 55'	0:1
	0:1	50' - - M.Cassetti
	0:1	46' - J.Menez P.Mexes'
	0:1	46' - M.Vucinic L.Toni'
V.Bojinov H.Crespo - 46'	0:1
First Half
	0:1	15' - - S.Perrotta
Jimenez, Luis - - 6'	0:1
	0:1	5' - - F.Totti

Players
FC Parma		Roma
Starting Lineup:
3.	Antonelli, Luca	4.	Juan
6.	Lucarelli, Alessandro	9.	Vucinic, Mirko
7.	Castellini, Paolo	10.	Totti, Francesco
10.	Dzemaili, Blerim	11.	Taddei, Rodrigo
11.	Jimenez, Luis	16.	De Rossi, Daniele
14.	Galloppa, Daniele	17.	Riise, John Arne
15.	Dellafiore, Hernan	20.	Perrotta, Simone
20.	Biabiany, Jonathan	27.	Julio Sergio
80.	Valiani, Francesco	29.	Burdisso, Nicolas
83.	Mirante, Antonio	77.	Cassetti, Marco
86.	Bojinov, Valeri	94.	Menez, Jeremy
Available Subs:
1.	Pavarini, Nicola	1.	Lobont, Bogdan
8.	Lunardini, Francesco	5.	Mexes, Philippe
9.	Lanzafame, Davide	7.	Pizarro, David
16.	Baccolo, Pietro	19.	Baptista, Julio
27.	Tamasi, Zsolt	24.	Cerci, Alessio
34.	Gigli, Abel	30.	Toni, Luca
77.	Crespo, Hernan	33.	Brighi, Matteo

Serie A : Bologna 2 - 1 Parma

noreply@blogger.com (muhammad syafar AZ) — Mon, 26 Apr 2010 04:37:00 PDT

Match Summary (Sunday April 25, 2010 20:00)
Home Team	Final Score	Away Team
Bologna FC	2 - 1	FC Parma
Second Half
	2:1	85' - D.Galloppa D.Lanzafame'
E.Moras M.Britos - 78'	2:1
F.Casarini R.Guana - 62'	2:1
Adailton A.Pisanu - 62'	2:1
M.Di Vaio - - 50'	2:1
First Half
	1:1	44' - V.Bojinov A.Gigli'
	1:1	43' - M.Paci F.Lunardini'
M.Di Vaio - - 39'	1:1
	0:1	29' - - C.Zaccardo
	0:1	23' - - Biabiany, Jonathan
S.Lanna - - 20'	0:0
	0:0	10' - - M.Paci

Players
Bologna FC		FC Parma
Starting Lineup:
1.	Viviano, Emiliano	3.	Antonelli, Luca
9.	Di Vaio, Marco	5.	Zaccardo, Cristian
13.	Portanova, Daniele	7.	Castellini, Paolo
18.	Moras, Evangelos	14.	Galloppa, Daniele
23.	Lanna, Salvatore	15.	Dellafiore, Hernan
24.	Busce, Antonio	20.	Biabiany, Jonathan
25.	Zalayeta, Marcelo	24.	Paci, Massimo
26.	Mudingayi, Gaby	77.	Crespo, Hernan
32.	Casarini, Federico	80.	Valiani, Francesco
84.	Raggi, Andrea	83.	Mirante, Antonio
85.	Adailton	86.	Bojinov, Valeri
Available Subs:
6.	Britos, Miguel Angel	1.	Pavarini, Nicola
7.	Pisanu, Andrea	8.	Lunardini, Francesco
11.	Succi, Davide	9.	Lanzafame, Davide
14.	Guana, Roberto	10.	Dzemaili, Blerim
15.	Colombo, Roberto	16.	Baccolo, Pietro
20.	Gimenez, Henry	34.	Gigli, Abel
30.	Modesto, Francesco	90.	Pasi, Riccardo

Serie A : Parma 2 - 3 Genoa

noreply@blogger.com (muhammad syafar AZ) — Sun, 18 Apr 2010 07:59:00 PDT

Match Summary (Sunday April 18, 2010 20:00)
Home Team	Final Score	Away Team
FC Parma	2 - 3	Genoa Cfc
Second Half
D.Lanzafame B.Dzemaili - 86'	2:3
	2:3	85' - R.Palacio D.Lazarevic'
L.Antonelli R.Pasi - 80'	2:3
	2:3	73' - - I.Fatic
	2:2	71' - G.Mesto I.Fatic'
A.Lucarelli - - 68'	2:2
S.Bocchetti (og) - - 62'	2:2
C.Zaccardo - - 60'	1:2
	0:2	56' - R.Palladino G.Sculli'
	0:2	52' - - R.Palacio
F.Lunardini V.Bojinov - 46'	0:1
First Half
	0:1	33' - - R.Palacio

Players
FC Parma		Genoa Cfc
Starting Lineup:
3.	Antonelli, Luca	3.	Dainelli, Dario
5.	Zaccardo, Cristian	8.	Palacio, Rodrigo Sebastian
6.	Lucarelli, Alessandro	9.	Acquafresca, Robert
8.	Lunardini, Francesco	10.	Palladino, Raffaele
9.	Lanzafame, Davide	15.	Papastathopoulos, Sokratis
11.	Jimenez, Luis	20.	Mesto, Giandomenico
14.	Galloppa, Daniele	21.	Zapater, Alberto
15.	Dellafiore, Hernan	26.	Bocchetti, Salvatore
24.	Paci, Massimo	40.	Tomovic, Nenad
77.	Crespo, Hernan	73.	Scarpi, Alessio
83.	Mirante, Antonio	77.	Milanetto, Omar
Available Subs:
1.	Pavarini, Nicola	13.	Fatic, Ivan
7.	Castellini, Paolo	14.	Sculli, Giuseppe
10.	Dzemaili, Blerim	18.	Boakye, Richmond
16.	Baccolo, Pietro	22.	Gucher, Robert
34.	Gigli, Abel	27.	Lazarevic, Dejan
86.	Bojinov, Valeri	32.	Amelia, Marco
90.	Pasi, Riccardo	34.	Terigi, Leonardo

Serie A : Napoli 2 - 3 Parma

noreply@blogger.com (muhammad syafar AZ) — Sat, 10 Apr 2010 11:36:00 PDT

Match Summary (Saturday April 10, 2010 23:00)
Home Team	Final Score	Away Team
Ssc Napoli	2 - 3	FC Parma
Second Half
G.Grava E.Hoffer - 90'	2:3
	2:3	87' - - A.Jimenez Garces
F.Quagliarella - - 84'	2:2
	2:2	81' - J.Biabiany M.Paci'
M.Hamsik - - 78'	2:2
	1:2	75' - - P.Castellini
M.Pazienza L.Cigarini - 74'	1:2
S.Aronica M.Bogliacino - 73'	1:2
	1:2	68' - - A.Lucarelli
	1:1	63' - - L.Antonelli
S.Aronica - - 58'	1:0
P.Cannavaro - - 54'	1:0
	1:0	53' - - H.Dellafiore
	1:0	46' - D.Galloppa P.Castellini'
	1:0	46' - V.Bojinov H.Crespo'
First Half
	1:0	37' - - J.Biabiany
	1:0	34' - - F.Valiani
	1:0	20' - - A.Lucarelli
F.Quagliarella - - 3'	1:0

Players
Ssc Napoli		FC Parma
Starting Lineup:
2.	Grava, Gianluca	3.	Antonelli, Luca
5.	Pazienza, Michele	5.	Zaccardo, Cristian
6.	Aronica, Salvatore	6.	Lucarelli, Alessandro
7.	Lavezzi, Ezequiel	11.	Jimenez, Luis
14.	Campagnaro, Hugo	14.	Galloppa, Daniele
16.	Zuniga, Camilo	15.	Dellafiore, Hernan
17.	Hamsik, Marek	19.	Zenoni, Damiano
23.	Gargano, Walter	20.	Biabiany, Jonathan
26.	De Sanctis, Morgan	80.	Valiani, Francesco
27.	Quagliarella, Fabio	83.	Mirante, Antonio
28.	Cannavaro, Paolo	86.	Bojinov, Valeri
Available Subs:
1.	Iezzo, Gennaro	1.	Pavarini, Nicola
9.	Hoffer, Erwin	7.	Castellini, Paolo
18.	Bogliacino, Mariano	8.	Lunardini, Francesco
21.	Cigarini, Luca	9.	Lanzafame, Davide
33.	Rullo, Erminio	10.	Dzemaili, Blerim
77.	Rinaudo, Leandro	24.	Paci, Massimo
91.	Maiello, Raffaele	77.	Crespo, Hernan

Serie A : Parma 1 - 1 Fiorentina

noreply@blogger.com (muhammad syafar AZ) — Sat, 03 Apr 2010 12:40:00 PDT

Match Summary (Saturday April 3, 2010 14:00)
Home Team	Final Score	Away Team
FC Parma	1 - 1	ACF Fiorentina
Second Half
H.Dellafiore - - 90'	1:1
	1:1	77' - - P.Kröldrup
M.Paci D.Zenoni - 70'	1:1
F.Valiani - - 69'	1:1
V.Bojinov - - 67'	1:1
P.Castellini H.Crespo - 65'	0:1
	0:1	65' - - C.Natali
	0:1	57' - G.Comotto J.Vargas'
L.Antonelli D.Lanzafame - 53'	0:1
	0:1	53' - - G.Comotto
	0:1	46' - C.Zanetti M.Donadel'
First Half
	0:1	45' - - C.Zanetti
A.Lucarelli - - 38'	0:1
	0:1	22' - - L.De Silvestri

Players
FC Parma		ACF Fiorentina
Starting Lineup:
3.	Antonelli, Luca	1.	Frey, Sebastien
5.	Zaccardo, Cristian	2.	Kröldrup, Per
6.	Lucarelli, Alessandro	8.	Jovetic, Stevan
7.	Castellini, Paolo	11.	Gilardino, Alberto
11.	Jimenez, Luis	14.	Natali, Cesare
15.	Dellafiore, Hernán	15.	Zanetti, Cristiano
20.	Biabiany, Jonathan	16.	Felipe
24.	Paci, Massimo	18.	Montolivo, Riccardo
80.	Valiani, Francesco	24.	Santana, Mario Alberto
83.	Mirante, Antonio	25.	Comotto, Gianluca
86.	Bojinov, Valeri	29.	De Silvestri, Lorenzo
Available Subs:
1.	Pavarini, Nicola	4.	Donadel, Marco
4.	Morrone, Stefano	6.	Vargas, Juan Manuel
8.	Lunardini, Francesco	21.	Babacar, El Khouma
9.	Lanzafame, Davide	22.	Ljajic, Adem
19.	Zenoni, Damiano	28.	Bolatti, Mario
77.	Crespo, Hernan	39.	Keirrison
90.	Pasi, Riccardo	90.	Seculin, Andrea

first leg battle of total football

noreply@blogger.com (muhammad syafar AZ) — Wed, 31 Mar 2010 15:06:00 PDT

i know that this does not related to Parma, but i think this match is the most prestigious match of the year. first leg uefa champions league of Arsenal Vs. Barcelona, the battle of total football.

i wish someday Parma would be like these teams ;))