India Latest Technology - NANO

The much awaited Tata small car, which is giving sleepless nights to its rivals, was finally unveiled at the Auto Expo 2008. The small car, which is priced at Rs100, 000 (2,500 dollars), has been named Nano. According to the Tata Motors, the Nano will hit the Indian roads later this year. Ever since the Tatas announced their intention of developing the 1 lakh car (touted as people’s car), the auto industry experts have been raising doubts over the price, features, safety and specifications of Tata Nano. Have a look at specifications and other aspects of the Tata Nano, the four door mini-hatchback.

Looks & Dimensions of Nano: Keeping in mind the young age group, the Tata Motors has strived well to give the Nano a contemporary and stylish look. The snub-nosed small car derives inspiration from Fiat 500 and Nissan Micra. As far as dimensions of the car are concerned, Nano is 3.1 metres (10.23 feet) long, 1.5 metres wide and 1.6 metres high and can accommodate four to five people.

Engine:
The small car sports a two cylinder 623 cc, 33 horsepower rear mounted multi-point fuel injection (MPFi) petrol engine. Tata claims that the car can touch the top speed of 105 kms.

Fuel Efficiency: Engineers at Tata Motors have designed an efficient engine that can run 20 Kms on every litre of petrol.

Pollution: Against the criticism and concerns of the environmentalists, Nano surpasses Indian regulatory requirements and Euro IV emission norms. In fact, Tata claims that the small car is less polluting than most of the bikes on Indian roads.

Safety: Tata says that they have tested the small car extensively for front, rear and side collisions and come out with a product that exceeds current regulatory requirements. The safety features of the Nano include a strong passenger compartment, intrusion resistant doors, seat belts, sturdy seats and anchorage.
Price: The base model of the car will sport a price tag of Rs 100,000 (2,500 dollars) which excludes taxes and transport costs. The high end/deluxe models will include air-conditioning and other features to be incorporated based on suggestions of the common people

Tuesday, January 8, 2008

MGCP - Media Gateway Control Protocol -III

Capabilities

Capabilities inform the Call Agent about endpoints' capabilities when
audited. The encoding of capabilities is based on the Local
Connection Options encoding for the parameters that are common to
both, although a different parameter line code is used ("A"). In
addition, capabilities can also contain a list of supported packages,
and a list of supported modes.

The parameters used are:

A list of supported codecs.
The following parameters will apply to all codecs specified in
this list. If there is a need to specify that some parameters,
such as e.g., silence suppression, are only compatible with some
codecs, then the gateway will return several Capability
parameters; one for each set of codecs.

Packetization Period:
A range may be specified.

Bandwidth:
A range corresponding to the range for packetization periods may
be specified (assuming no silence suppression). If absent, the
values will be deduced from the codec type.

Echo Cancellation:
"on" if echo cancellation is supported, "off" otherwise. The
default is support.

Silence Suppression:
"on" if silence suppression is supported for this codec, "off"
otherwise. The default is support.

Gain Control:
"0" if gain control is not supported, all other values indicate
support for gain control. The default is support.

Type of Service:
The value "0" indicates no support for type of service, all other
values indicate support for type of service. The default is
support.

Resource Reservation Service:
The parameter indicates the reservation services that are
supported, in addition to best effort. The value "g" is encoded
when the gateway supports both the guaranteed and the controlled
load service, "cl" when only the controlled load service is
supported. The default is "best effort".

Encryption Key:
Encoding any value indicates support for encryption. Default is
no support which is implied by omitting the parameter.

Type of network:
The keyword "nt", followed by a colon and a semicolon separated
list of supported network types. This parameter is optional.

Packages:
The packages supported by the endpoint encoded as the keyword "v",
followed by a colon and a character string. If a list of values
is specified, these values will be separated by a semicolon. The
first value specified will be the default package for the
endpoint.

Modes:
The modes supported by this endpoint encoded as the keyword "m",
followed by a colon and a semicolon-separated list of supported
connection modes for this endpoint.

Lack of support for a capability can also be indicated by excluding
the parameter from the capability set.

An example capability is:

A: a:PCMU;G728, p:10-100, e:on, s:off, t:1, v:L,
m:sendonly;recvonly;sendrecv;inactive

The carriage return above is included for formatting reasons only and
is not permissible in a real implementation.

If multiple capabilities are to be returned, each will be returned as
a separate capability line.

Since Local Connection Options can be extended, the list of
capability parameters can also be extended. Individual extensions
may define how they are reported as capabilities. If no such
definition is provided, the following defaults apply:

* Package Extension attributes: The individual attributes are not
reported. Instead, the name of the package is simply reported in
the list of supported packages.

* Vendor Extension attributes: The name of the attribute is reported
without any value.

* Other Extension attributes: The name of the attribute is reported
without any value.


Coding of Event Names

Event names are composed of an optional package name, separated by a
slash (/) from the name of the actual event. The
wildcard character star ("*") can be use to refer to all packages.
The event name can optionally be followed by an at sign (@) and the
identifier of a connection (possibly using a wildcard) on which the
event should be observed. Event names are used in the
RequestedEvents, SignalRequests, ObservedEvents, DetectEvents, and
EventStates parameters.

Events and signals may be qualified by parameters defined for the
event/signal. Such parameters may be enclosed in double-quotes (in
fact, some parameters MUST be enclosed in double-quotes due to
syntactic restrictions) in which case they are UTF-8 encoded [20].

The parameter name "!" (exclamation point) is reserved for future use
for both events and signals.

Each signal has one of the following signal-types associated with it:
On/Off (OO), Time-out (TO), or Brief (BR). (These signal types are
specified in the package definitions, and are not present in the
messages.) On/Off signals can be parameterized with a "+" to turn the
signal on, or a "-" to turn the signal off. If an on/off signal is
not parameterized, the signal is turned on. Both of the following
will turn the vmwi signal (from the line package "L") on:

L/vmwi(+)
L/vmwi

In addition to "!", "+" and "-", the signal parameter "to" is
reserved as well. It can be used with Time-Out signals to override
the default time-out value for the current request. A decimal value
in milliseconds will be supplied. The individual signal and/or
package definition SHOULD indicate if this parameter is supported for
one or more TO signals in the package. If not indicated, TO signals
in package version zero are assumed to not support it, whereas TO
signals in package versions one or higher are assumed to support it.
By default, a supplied time-out value MAY be rounded to the nearest
non-zero value divisible by 1000, i.e., whole second. The individual
signal and/or package definition may define other rounding rules. All
new package and TO signal definitions are strongly encouraged to
support the "to" signal parameter.

The following example illustrates how the "to" parameter can be used
to apply a signal for 6 seconds:

L/rg(to=6000)
L/rg(to(6000))

The following are examples of event names:

-----------------------------------------------------------
| L/hu | on-hook transition, in the line package |
| F/0 | digit 0 in the MF package |
| hf | Hook-flash, assuming that the line package|
| | is the default package for the endpoint. |
| G/rt@0A3F58 | Ring back signal on connection "0A3F58" |
-----------------------------------------------------------

In addition, the range and wildcard notation of events can be used,
instead of individual names, in the RequestedEvents and DetectEvents
parameters. The event code "all" is reserved and refers to all
events or signals in a package. The star sign ("*") can be used to
denote "all connections", and the dollar sign ("$") can be used to
denote the "current" connection.

The following are examples of such notations:

---------------------------------------------------------
| M/[0-9] | Digits 0 to 9 in the MF package. |
| hf | Hook-flash, assuming that the line package|
| | is a default package for the endpoint. |
| [0-9*#A-D]| All digits and letters in the DTMF |
| | packages (default for endpoint). |
| T/all | All events in the trunk package. |
| R/qa@* | The quality alert event on all |
| | connections. |
| G/rt@$ | Ringback on current connection. |
---------------------------------------------------------

0 comments:

NANO Car

NANO Car

Get paid to read mails

Technologiwa

Loading...