The Intelligent Network separates service logic from network control, using service control points for the former and signal switching points for the latter. (Rosenberg et. al., Existing Models, page 67).
The answers, in no particular order and approximately verbatim:
The Intelligent Network has four layers namely
Service layer
— which in IPM can help in call forwarding like things.
Global functional layer — which acts at machine level to
understand semantics at abstract level.
Distributed functional layer
— which is like the transport layer to establish calls.
Physical layer — which is like the physical layer of an
IPN.
IPN works very much similar based on IN model.
Intelligent Network (IN) is a model that front-ends services in the PSTN. It describes services, functions, a state machine for controlling call features and in apps commands of the switches. It is used at the top level to model CPL-based en-point services where the user's capabilities to modify services must be limited. Description a “directed” graph-type language that limits end user capabilities is derived from the top to levels.
The SIP CGI functions can be envisaged in levels 2–3 where the SIP server is controlled. Here code requires full power to branch and loop.
For implementing services in an IT network, above model [figure omitted] of intelligent network helps create new services by modifying SIP server. This can be done following ways: 1) rewrite existing SIP server for specific service. 2) Create specialized servers for service which can interact with existing SIP server. 3) Write servlets in SIP server for additional services or 4) Create CGI programs for services which will be created during an instance of service and then terminated.
The PSTN, Intelligent Network was introduced to separate the service logic from the normal execution of the switches. In this way a service can be added or modified without changing the switches.
Similarly, the Internet telephone service logic has been separated from the servers. In intelligent Network, services are defined in various layers, and they have decision graphs which help in adding new services.
The SIP message body can carry arbitrary information arbitrarily formatted. In particular, it could carry XML-RPC or SOAP calls that could be further elaborated by the notification receiver. (Rosenberg and Arabshian, Toward a SIP-Based Notification Architecture, page 45).
The answers, in no particular order and approximately verbatim:
In SIP event notification system uses SIP server to handle vent notification and uses SIP protocol. SIP protocol has data field which can be used to add more information during emergency alerts, such as hurricane location, direction, category, wind speed also like rain forecast, thunderstorm, etc.
In SIP, headers are in textual form and the message body can be of different types; it can carry MIME or SDP, etc. So, more information can be passed through message body.
SIP server allows information to travel both ways. Emergency information can be forked out appropriately and regional information about local disaster effects can propagate back up to responders because of the server system that provides not only information, but detailed location information. The SIP event notification can also provide more information because it is more resistant; killing a few nodes does not disturb it’s capabilities.
Along with traditional event notifications or radio & television SIP can provide notifications to users who've subscribed for it on the Internet. With the help of options like call forwarding it can be forwarded to any device for the person. Also SIP supports forking. So notifications can be sent parallel or in series.
SIP services may require several interactions between the CGI program and the invoking server; while waiting for a server response the CGI program must maintain (persist) the current service's state. For example, the service may require a proxy, and the results of the proxy should be sent back to the CGI script for further processing. In HTTP, the CGI program and the server have a simple, one-shot request-response relation that doesn't require persistence. (Rosenberg et. al., Basic Operations of SIP CGI, page 68).
The answers, in no particular order and approximately verbatim:
In SIP CGI even if the server crashes and reboots it does not affect anything. This is because each request has a token with which the server can know the state it was in before it crashes. The token is a script which the server runs.
SIP CGI is for to provide additional services on IT network, and it may add additional delay to create service and terminate the service during IT call. HTTP CGI runs on a web server. SIP CGI can be written tin any language. HTTP CGI is not a time sensitive as compared to SIP CGI. SIP CGI is controlled by SIP server and it runs isolated with SIP server and send outcome to SIP server provide better security.
An HTTP CGI has no persistence. Once an action is performed it is forgotten. Because SIP server may use proxies, information is retained in the SIP server. The SIP-CGI server sends “copies” to the SIP server that help it remember how to react. The SIP-CGI server can also send commands at any time.
In HTTP CGI, once the output is read by the server, script terminates. But in SIP CGI, script may remain active even if the service is fulfilled. It is possible that once the call's request is fulfilled by SIP CGI, they (script) can transfer their state to the server in the form of cookies. And when needed can be reloaded all the information from the cookies present in the server. Thus, SIP CGI can be persistent while HTTP CGI are not.
Citizen authentication prevents spoofing or masquerading attacks when one citizen attempts to receive events in another citizen's name. Citizen authorization insures a citizen only receives the notifications appropriate for the citizen. (Schulzrinne and Arabshian, Authentication and Authorization, page 45).
The answers, in no particular order and approximately verbatim:
There is a possibility that one person can register multiple times or even can represent their neighbors. For example, they can modify the “from” content of the SIP message and can register for event notifications.
There could be prank calls from citizens trying to register for event notifications. Also there could be spoofing of calls. Authentication & authorization will limit the spoof calls and prevent unnecessary prank calls.
Authentication insures that end point users are who they say they are. This helps prevent spoofing.
Authorization prevents the ordinary citizen from using more of the event notification system than they should. This prevents the enterprising user from sending out false alarms and D)S attacks.
1) Spoofing: when user is registering for event notification; service
provider or event notification system must ensure that nobody intercept
messages and redirect to other users.
2) Service theft: to prevent
unauthorized and unauthenticated user to access registered
services.
3)Secured delivery of event notification.
| This page last modified on 7 August 2008. |