sipd plays three roles in the CINEMA system. Name them and
explain each role's responsibility in the system.
The three roles are the usual ones assigned to SIP servers: proxy, redirector, and registrar. In the proxy role the server is an intermediary between the two end-points; in the redirector role the server receives an address and responds with a translation of that address; in the registrar role, the server receives end-point information and stores it in a database, making it available for later queries (Cinema Components, page 65, Jiang et al.).
The answers, in no particular order and approximately verbatim:
SIP server sipd plays roles of proxy agent, routing agent and also administrative server. Proxy maintains user's identification on network (Internet), while routing agent direct call to proper link and administrative server maintains log of resource usage.
Registration/Subscription: registers how users and subscribers to
PSTN to get notifications of an event.
Trigger & notification: fires a
trigger when event occurs and notifies the user.
proxy & authentication:
acts as a proxy server and also authenticates the users.
proxy server – helps route the
canonical address to the desired place/places. Uses forking!! Forking
→ asynchronous addressing.
authentication server – decides who has what
privileges, does accounting.
multimedia server – handles requests for
multimedia streaming, joint viewing of web pages, teleconferencing,
etc.
The SIP server handles all incoming requests coming from the PSTN/SIP gateway. The SIP also handles requests for voice mail accessed through the telephone system. It also handles network device control using the HIO [?] protocol.
SIP server sipd performs following three
activities:
– Registration: it registers the
users.
– Authentication: It authenticates whether the
user is correct or not.
– Proxy: sipd server acts like a
proxy. They help in determining the correct domain of the called id number.
They send request/response on behalf of the user.
A dialog always starts off with a notification that the dialog has begun, which means that a dialog service needs a notification service to get started. A notification service, however, doesn't necessarily lead to a dialog, as is the case when a SMS is delivered to an end-point as an instant message (Section V, page 574, Gurbani and Sun).
The answers, in no particular order and approximately verbatim:
Dialog-oriented services require two parts “S” and “N”. “S” is the service request. Service requests may or may not require action. Sometimes they are just used for bookkeeping. “N” is the notification. This part requires action.
Notification services are simple services. They purpose is to notify the Internet host.
Dialog-oriented services are quite complicated. ICW, i.e., Internet call waiting, is an example for it. In this service, Internet host is notified about the call and then if user wants, he can disturb the Internet service and take up the call or forward the call to another number.
Dialog services can be extended. They still exist even if the response is sent, depending on the Internet host.
Thus, a dialog oriented service can also act like notification services, but since thy can go beyond notification, therefore notification services cannot be dialog-enabled services.
Dialog oriented services or IVR allows user to choose a service he wants and it could trigger notification services. Dialog oriented services are request-response kind of services. Notification services notify a user for an event he has subscribed to. It is not an interactive service. Hence it cannot imply a dialog-oriented service.
From PSTN-to-Internet crossover services, does not require dialog-oriented services or notification services because at every 25 ms [?] PSTN data can be packed into packets and send it to Internet. But from Internet-to-PSTN requires notification services to make sure end user is available and also resources are available.
The need to share state among the responding servers is the bottleneck. A single central database doesn't scale with respect to read or write requests. Distributed databases scales with respect to reads (each read can go to the closest database), but not with respect to writes (each write has to be sent to all databases) (Scalability, page 71, Jiang et al.).
The answers, in no particular order and approximately verbatim:
One of the major problems of random request distribution is updating. There are hundreds of requests and even if they are distributed randomly the sharing is inevitable, i.e., the servers will share data for updating. You will have to replicate and update but this will also create a bottle neck.
Random request distribution is not scalable because it uses more resources and can not handle many requests per unit.
In random request distribution, request service is decided randomly. It doesn't consider the tine at which request was made. So, there may be situations, in which, a request earlier is not given service for a long interval of time. And hence service-volume scalability is not desirable.
Random requests can't handle volume alone because the authentication server would either be bottle necked or each node would require its own authentication database.
Hard to say, but probably not. A sensible ITN-to-PTN architecture should treat the PTN as a special kind of end-point with a protocol visible at the gateway interface. Internal states of the PTN, such as DPs, would be hidden from the ITN. On the other hand, a service is initiated in the Internet may want to keep track of service state as it progresses through the PSTN, in which case access to DPs may be appropriate, particularly given Gurbani and Sun's claim that low-level signals should be presented as is and not abstracted at higher-level interfaces. (Section II, page 573, Gurbani and Sun).
The answers, in no particular order and approximately verbatim:
Detection points lies between the transition states, i.e., when a call is made in PSTN. They basically work as a trigger. Through detection points SSP can connect to SCP like for example, in case of 1-800 number translation, SCP helps in giving the geographic location.
I think for originating services in an Internet telephony, these issues are already handled by protocols like SIP. There are SIP servers like proxy servers which handles this.
Interesting question. Since the Internet telephony network is potentially unlimited, you would need a lot of detection points. Even then, you would have a limited probability of detecting a given call. Each request could potentially go through a different route. That would make life even tougher. The smart thing to do is once you detect a “call of interest” to force it to route over a fixed route afterward (if you are tapping). If you are using data for performance statistics, you just let the chips fall where thy may, provided you have enough points. Detection once you are in the PSTN is easier because nodes retain state. Detection points for tapping or traffic analysis are more practical once you are in the PSTN side. PSTN routes are often dedicated and are always hierarchical.
Detection pints (DPs) would be useful in an architecture for originating services in an Internet telephony network. Using DPs can enable Internet originated call pass through PSTN and also able to switch signals from PSTN to Internet and vice-versa.
DPs will not be useful in an architecture for originating services in an Internet telephony network & terminating them in public telephone network because the data sent will be packetized and there could be packet loss & delay.
| This page last modified on 28 July 2008. |