Figure 5.14 SIP/H.323 Gateway Independent
P.153
[IP Telephony Cookbook] / Setting Up Advanced Services
-/ 5.1.4.2 Call from SIP to H.323
The SIP/H.323 Gateway operations are described only when it acts as an active intervention.
Since, when the SIP/H.323 Gateway contains a SIP Proxy and registrar, the SIP registration information is also available through the H.323 Gatekeeper and any H.323 entity can resolve the address of SIP entities reachable via the SIP server.Thus, an active intervention is performed only in the case of calls originating from the SIP domain towards the H.323 one.
In such a case, if a SIP user agent wants to talk to another user located in the H.323 network, it sends a SIP INVITE message to the SIP server, which, in turn, forwards an H.323 location request (LRQ) to the configured gatekeeper. If no gatekeeper was configured, then a broadcast LRQ is sent.The gatekeeper responds with the IP address of the H.323 user, making the SIP
server able to route the call to the destination. Drawbacks of this approach are that the H.323
Gatekeeper may be highly loaded because of all the registrations in the SIP network.
Of course, when the SIP/H.323 Gateway is independent of proxy or gatekeeper, it must query the other network for user location, acting an active intervention in the call.
-/ 5.1.4.3 Call from H.323 to SIP
Similar to the previous case, calls from the H.323 domain to the SIP one only require an active intervention of the SIP/H.323 Gateway when the originating domain contains an H.323
Gatekeeper. Such a consideration applies since H.323 terminals appear to the SIP user agents as SIP URLs within the same domain (for further information on how H.323 addresses are translated to SIP URLs, please refer to ‘Inter-working between SIP/SDP and H.323’).
In this case, if an H.323 user wants to talk to a user located in the SIP network, it sends an admission request (ARQ) to its gatekeeper.The gatekeeper has to send the location request (LRQ) to all the gatekeepers it has configured as neighbours. If the SIP/H.323 built-in gatekeeper receives the LRQ, it tries to resolve the address of a SIP user.This address resolving is done by sending a SIP OPTIONS request. If this operation succeeds and the user is currently available to be called, the SIP/H.323 Gateway replies to the H.323 network gatekeeper with the location confirmation (LCF), after the H.323 terminal knows that the destination is reachable.
Drawbacks of this approach are, as in the previous case, that the SIP Proxy has to store all H.323
registration information.
Of course, when the SIP/H.323 Gateway is independent of proxy or gatekeeper, it must query the other network for user location, making an active intervention in the call.
-/ 5.1.4.4 Media switching and capability negotiation
A SIP/H.323 Gateway should be configured in order to have media transport directly connected between the SIP and the H.323 entities.When, in some cases, this is not possible, the SIP/H.323
Gateway should have a built-in media switching fabric activated to forward RTP and RTCP
packets from one client to the other. A great inter-working effort is carried out in P.154
[IP Telephony Cookbook] / Setting Up Advanced Services
capabilities-negotiation.While SIP offers media with the INVITE message, the normal H.323
mode is to open a separate H.245 channel. In this case, the SIP/H.323 Gateway has to start a muted SIP call, and re-negotiate the capabilities later, unless the H.323 client supports the use of the FastStart procedure. If both of these conditions can not be ensured, the gateway must use the default codecs for both sides and, eventually, perform media transcoding.
-/ 5.1.4.5 Call termination
Since a call can be terminated from both H.323 and SIP clients, appropriate message translation/forwarding is required from the SIP/H.323 Gateway: a SIP BYE message is mapped to an H.323 Release Complete message and vice-versa.
-/ 5.1.4.6 Configuration guidelines
In this section, basic configuration principles are given, abstracting them from specific software in order to give general guidelines and give information rapidly becoming out-of-date. Apart from low-impact configuration information (log files location, log level setting), in order to configure a SIP/H.323 Gateway, it is likely that there will be a need to configure:
- enabling/not enabling of built-in SIP Proxy/registrar and related configuration. Please refer to the section on setting up SIP services for information on how to configure a SIP
Proxy/registrar server;
- the remote address/port of the H.323 network gatekeeper (either if SIP built-in proxy/
registrar is enabled and no broadcast requests have to be sent, or if the SIP/H.323 Gateway is independent of proxy or gatekeeper);
- enabling/not enabling of a built-in H.323 Gatekeeper and related configuration. Please refer to section on setting up H.323 services for information on how to configure an H.323
Gatekeeper;
- the remote address/port of the SIP network proxy/registrar (either if H.323 built-in gatekeeper is enabled, or if the SIP/H.323 Gateway is independent of proxy or gatekeeper).
-/ 5.1.5 Accounting Gateways
Accounting may be performed both on gatekeepers and on gateways. Even if, in principle, accounting done on gateways is possible, the best solution is to centralise the accounting on gatekeepers, which are able to maintain all the call information (if configured in call signalling routed mode). Information on how to perform accounting may be found in Section 4.3.
-/ 5.2 Supplementary services
This section deals with supplementary services both using H.323 and using SIP.These supplementary services are intended to be used in addition to the basic ones, but still in a telephony-like environment.The supplementary services are protocol-specific and are intended to P.155
[IP Telephony Cookbook] / Setting Up Advanced Services
replicate all the wide range of services we are already used to in the PSTN networks. Section 5.2.1 will deal with the supplementary services using the H.323 protocol, while Section 5.2.2 will deal with supplementary services using the SIP protocol.
-/ 5.2.1 Supplementary services using H.323
This section describes the supplementary services of the H.323 protocol as specified in the H.450.x supplementary services recommendations.
The supplementary services of H.323 are defined in the H.450 series, which establishes the signalling between endpoints necessary to implement the telephone-like services. Although some of these services have the same functionalities as the equivalent ones developed for the circuit-switched networks, it is relevant to note that the paradigm of H.323 is completely different.
The peculiar characteristic of the supplementary services of H.323 is that the protocol actions needed for their control are performed using peer-to-peer signalling. In other words, the protocols are designed in such a manner that functional entities communicate with their peer entities (clients, gatekeepers, gateways etc.) directly without requiring network intervention.
The services are distributed in the endpoints, based on the suitability of the service at that endpoint. For example, an H.323 client maintaining the state of the calls is suitable for the implementation of services such as call transfer, call forwarding, call waiting, and so on. Since a peer-to-peer model is used by the supplementary services of H.323, the payload and the signalling of the services are transparently sent through the network without requiring the processing of any network element.
Considering also that the state of the calls is distributed to the endpoints involved in the calls, it can be deduced that services for H.323 can be deployed by any manufacturer and sold directly to the end-user for deployment.This feature of the service deployment leads to a low cost entry for the service provider and a service cost for customer characterised by an initial cost for the software implementing the service for unlimited use.This last aspect implies that new services can be distributed to VoIP users in the same way as any other software is sold in the market today.
This scenario raises problems related to the subscription-control of these supplementary services.
To this aim, the signalling necessary for these services should be routed through the gatekeeper (or other proxy elements) containing a service database description that permits charging for the use of supplementary services or their blocking when they are not subscribed to by the customer.
Another issue related to the peer-to-peer approach used in the H.323 supplementary services is service incompatibility. In H.323, the clients exchange their capabilities and hence, they are only able to use those services that are common to both clients.Therefore, services that are present in one client are simply not used if they are not present in the other client involved in the call.
In the case of hybrid networks, e.g., PSTN and H.323, the supplementary service functionality and availability on the calls between legacy and H.323 networks depend on the capabilities of the gateway, which must perform the signalling translation necessary to guarantee the services.
Moreover, the gateway can be used by the provider to charge for the service.
P.156
[IP Telephony Cookbook] / Setting Up Advanced Services
Supplementary services in H.323 are specified in a multi-tier approach. Basic services consist of building blocks or primitives from which more complex services can be developed. Compound services are developed from two or more basic services. For example, in a consultation transfer service, the user needs to put a multimedia call on hold and retrieve it later, to call another person and possibly alternate between the two calls, and to transfer the two calls together. Hence, this service is simply obtained combining basic supplementary services.The basic supplementary services defined in the H.450 series are described in the following;
- H.450.2 - Call Transfer. It enables a user A to transform an existing call (user A - user B) into a new call between user B and a user C selected by user A;
- H.450.3 - Call Diversion. It is also known as call forwarding and comprises the services: call forwarding unconditional, call forwarding busy, call forwarding no reply and call deflection. It applies during call establishment by providing a diversion of an incoming call to another destination alias address. Any of the above variants of call forwarding may operate on all calls, or selectively on calls fulfilling specific conditions programmed or manually selected by the user;
- H.450.4 - Call Hold. It allows the served user (holding user), which may be the originally calling or the called user, to interrupt communications on an existing call and then subsequently, if desired, re-establish (i.e., retrieve) communications with the held user. During the call interruption, the holding user provides some form of media for the held user, and may perform other actions while the held user is being held, e.g., consulting another user;
- H.450.5 - Call Park and Pickup.This is a service that enables the parking user A to place an existing call with user B to a parking position and to later pick up the call from the same or other terminal;
- H.450.6 - Call Waiting. It permits a served user while being busy with one or more calls to be informed of an incoming call from a new user by an indication.The served user then has the choice of accepting, rejecting or ignoring the waiting call.The user calling the busy party is informed that the call is a waiting call at the called destination;
- H.450.7 - Message Waiting Indication. It provides general-purpose notifications of waiting messages, including the number, type and subject of the messages;
- H.450.8 - Name Indication.This service permits to a user A to be informed of an incoming or existing call or of the alerting state by a user B.The notification can be provided from a server or directly from user B;
- H.450.9 - Call Completion. It enables a calling user A to have the call toward a user B
completed without having to make a new call attempt, when the first call procedure has been not completed since user B was busy or, though alerted, did not answer;
- H.450.10 - Call Offer. It permits to a calling user A, encountering a busy destination user B, to
‘camp-on’ to the busy user.This means that the call is indicated to user B and kept in a waiting state until user B reacts to the indication, rather than being released due to the busy condition;
- H.450.11 - Call Intrusion. It enables a calling user A, encountering a busy destination user B, to establish communication with user B by breaking into an established call between user B and a third user C;.
- H.450.12 - Common Information Additional Network Feature (ANF-CMN).This is an additional network feature that enables the exchange of Common Information between ANF-CMN endpoints.This Common Information is a collection of miscellaneous information that relates to the endpoint or equipment at one end of a connection and includes one or more of the following: Feature Identifiers, Feature Values, or Feature Controls.This information, when received by an ANF-CMN endpoint, can be used for any purpose, e.g., as the basis for indications to the local user or to another network or in order to filter feature requests.
P.157
[IP Telephony Cookbook] / Setting Up Advanced Services
The following examples can be useful to understand how the supplementary services can be implemented. In the example, attention will be focused mainly on the signalling procedure, considering that the peer-to-peer approach adopted by the H.323 supplementary services concentrates the problems related to the service implementation to the endpoint or gatekeeper used as service server.
-/ 5.2.1.1 Call transfer supplementary service
Supplementary Service Call Transfer (SS-CT) is a supplementary service which enables the served user (user A or transferring user) to transform an existing call with user B (primary call) into a new call between user B and a user C (transferred-to user) selected by user A.
It is relevant to note that the primary call between user A and user B must be answered before transfer can be initiated. On successful completion of SS-CT, user B and user C can communicate with each other and user A will no longer be able to communicate with user B or user C.
The signalling necessary to use the service is implemented using a set of messages forming the Application Protocol Data Unit (APDU), which are transported within user-to-user information elements in call control and FACILITY messages as defined in the ITU-T Recommendation H.450.1.
As an example, Figure 5.15 reports the signalling messages exchanged to perform the Call Transfer from the primary call between user A and user B to the new call involving user B and user C. In particular, when it decides to perform the Call Transfer, user A sends to user B the FACILITY
message with the APDU denoted as CallTransferInitiate.Invoke, containing the address of the user C. Using this information, user B initiates the procedure to open the new call with user C
transmitting the SETUP message with the CallTransferSetup.Invoke APDU.The user C
accepts the call, sending the CONNECT message with the appropriate APDU.When user B
receives the CONNECT message, it tears down the primary call with user A, transmitting the RELEASE COMPLETE message with the appropriate APDU.
Figure 5.15 Messages exchanged to implement the CT-SS without gatekeeper The example refers to the case where the gatekeeper is absent or the direct signalling model is adopted. In this case, only the software able to process and to generate the APDUs is necessary to implement the service. An example is given in Figure 5.16 where we report an Ohphone (an openh323 application) interface modified with, the addition, of a Call Transfer Supplementary P.158
[IP Telephony Cookbook] / Setting Up Advanced Services
services button. In this case, simply pressing the Transfer button makes the application of an open dialogue screen, allowing the insertion of the H.323 ID of the called party and generating the necessary APDUs.
Figure 5.16 An example of Call Transfer Supplementary Service without gatekeeper - Ohphone-modified interface
5.2.1.1.1 Gatekeeper role in the call transfer
In the case of the gatekeeper-routed model, the gatekeeper either transparently transports or performs the operations necessary to offer the service. In particular, the gatekeeper can provide CT-SS, when one or both endpoints are unable to support the service.
Hence, in order to provide the service, the gatekeeper can decide to perform the actions applicable to the transferred endpoint, to the transferred-to endpoint or both.When the gatekeeper handles the Call Transfer signalling on behalf of an endpoint, it should perform further procedures as defined for the transferred and the transferred-to endpoints.
These further procedures are the sending of a FACILITY message with an appropriate APDU
used to inform the transferred user (or the transferred-to user when it manages the signalling on behalf of transferred-to user) that it has been transferred. Furthermore, the gatekeeper should instruct the endpoint (or endpoints), that it manages the signalling on behalf of the new set of media channels to connect.
To accomplish this, the gatekeeper uses the H.323 procedures for third party re-routing.These procedures require the gatekeeper to send an empty terminal capability set (one which indicates that the remote entity has no receive capabilities) to endpoints A and B, causing A and B to close their logical channels.Then, the gatekeeper exchanges the H.245 command end session with endpoint A and sends a RELEASE COMPLETE message containing the resulting APDU to release the call signalling channel.
When it receives a non-empty terminal capability set from endpoint C, the gatekeeper forwards the capability set to endpoint B to cause it to reset its H.245 associated state to that which it is in when H.245 has just completed (the first) terminal capability set exchange in the initial call establishment sequence.Then the gatekeeper takes part in master/slave determination, and opens appropriate logical channels with endpoint C.
P.159
[IP Telephony Cookbook] / Setting Up Advanced Services
To better understand the signalling procedure used, Figure 5.17 illustrates the messages exchanged for the CT-SS when the gatekeeper manages the signalling on behalf of the transferred user, i.e., B user.
Figure 5.17 Messages exchange for gatekeeper-managed CT-SS
After the reception and the processing of the FACILITY message, indicating that user A wants to transfer the current call, the gatekeeper sends a SETUP message with a callTransferSetup.invoke APDU to the transferred-to endpoint C.Then, the reception of the ALERTING or CONNECT message with the appropriate APDU transmitted by the user C
enables the gatekeeper to send a FACILITY message with the APDU informing the endpoint B
that it has been transferred (joining).
To instruct the endpoint for the new set of media channels, the gatekeeper sends an empty terminal capability set (it is defined as a terminalCapabilitySet message that contains only a sequence number and a protocol identifier) to endpoints A and B, causing A and B to close their logical channels, and to endpoint C, causing this endpoint to enter in the transmitter side paused state.
While in this state, an endpoint does not initiate the opening of any logical channels, but accepts the opening and closing of logical channels from the remote end, based on the usual rules, and continues to receive media on open logical channels opened by the remote endpoint.This procedure allows gatekeepers to re-route connections from endpoints that do not support supplementary services, and endpoints to receive announcements (e.g., pre-connect call progress) where the announcing entity does not wish to receive media from the endpoint.
The transmitter side paused state is left by the endpoint on reception of any terminalCapabilitySet message, other than an empty capability set. On leaving this state, an endpoint resets its H.245 state to that which it was in just after the H.245 transport connection was made at call establishment time (i.e., the beginning of phase B), but it preserves state information relating to any logical channels that are open.
P.160
[IP Telephony Cookbook] / Setting Up Advanced Services
This puts the endpoint in a known H.245 state after the pause, allowing an endpoint to be connected to a different endpoint when it is released from the paused state. After leaving the transmitter side paused state, an endpoint proceeds with normal H.245 procedures: it takes part in master/slave determination signalling and proceeds with normal open logical channel signalling procedures.
After these procedures, necessary to set the new call between B and C, the gatekeeper sends a RELEASE COMPLETE message containing callTransferInitiate return result APDU to release the call signalling channel of the primary calls, i.e., between A and B.
-/ 5.2.1.2 Call Diversion Supplementary Service
The signalling procedures and the protocols needed to implement the Call Diversion Supplementary Service are defined in the Recommendation H.450.3.The service permits to a user, denoted as the served user and receiving a call from an originating user to redirect it to another user, denoted as the diverted-to user.This operation leads to the connection of the originating user with the diverted-to user, and it is possible only when the served and originating users are not in a call.There are four kinds of call diversion service. Supplementary Service Call Forwarding Unconditional (SS-CFU) permits a served user, independent of its status, to forward incoming calls addressed to the served user's number to another number. CFU is provided on a per number basis. On the contrary, in the case of the Supplementary Service Call Forwarding Busy (SS-CFB), the call forwarding is made by the served user only when it is busy. A bit different is the Supplementary Service Call Forwarding No Reply (SS-CFNR), where the call forwarding begins when the served user does not establish the connection within a defined period of time.
All of these kinds of services may be either permanently activated or activated/deactivated under user control.The user control can be provided locally, at the served endpoint, remotely by another endpoint or both. Other than the activation/deactivation procedures, the H.450.3 defines the interrogation and the registration procedures.
The interrogation procedure provides information to the interrogating endpoints such as the activated or deactivated state of the supplementary service, and, if the service is activated, the diverted-to number, whether activated for all basic services or an individual basic service and the identity of the individual basic service.The registration permits the provision of the information related to the activated service, and it is performed on the activation procedure.
Indeed, to activate these services, the served user supplies the diverted-to number and optionally, further parameters, depending on the capabilities of the specific implementation.Verification that the diverted-to number exists may be carried out before accepting the activation request.
In the same recommendation, Call Deflection (SS-CD)is also defined, which permits a served user to respond to an incoming call offered by the served endpoint by requesting diversion of that call to another number specified in the response. Hence, the service does not require activation/deactivation/information/registration procedures.The diversion request is only allowed before the called user has answered the call and, in particular, when the served user is in the alerting state.
P.161
[IP Telephony Cookbook] / Setting Up Advanced Services
On acceptance of the CD request, the served endpoint performs the diversion towards the indicated diverted-to number.The original call at the served user remains in the alerting state and the served user is still able to accept the call until the diverted-to endpoint enters an alerting state.
When the diverted-to endpoint enters the alerting state, the call to the served user is cleared.
5.2.1.2.1 Gatekeeper role in the call diversion
The gatekeeper can be either transparent to the Call Diversion Service or directly manage it. In the first case, the implementation of the service is directly on the user endpoint or in the proxy server.
When the service is managed by the gatekeeper, the messages related to the activation/deactivation/interrogation/verification of the diverted-to number are received and processed by it, acting as a served endpoint.Thus, when the originating user sends the ARQ
message to contact the forwarding terminal for sending the
activation/deactivation/interrogation/verification messages, the gatekeeper responds returning the ACF message containing its own call signalling address, rather than the call signalling address of the forwarding terminal.
The invocation of the service depends on the kind of call diversion invoked. In particular, when the SS-CFU is activated in the gatekeeper for an incoming call destined for user B (being the served user), the gatekeeper acts as served endpoint and invokes the call forwarding unconditional for this call. Furthermore, if the option served user notification applies, the gatekeeper sends the notification to the called terminal.
In the case of the SS-CFB, the gatekeeper continues the H.225 call establishment procedure to endpoint B, where the user B (being the served user) is. If the endpoint B results busy, i.e., if a RELEASE COMPLETE message is received from endpoint B containing cause value user busy, the gatekeeper acts as served endpoint and invokes the call forwarding on busy for this call. Also in this case, the gatekeeper sends the notification to the called terminal, if the option served user notification applies.
For the provision of the SS-CFNR service by the gatekeeper, when a call arrives, destined for user B (being the served user), the gatekeeper starts a local no-response timer and continues the H.225 call establishment procedure to endpoint B. If the local no-response timer expires during the alerting phase of the call, the gatekeeper acts as served endpoint, invokes the call forwarding on no reply for this call and, if the option served user notification applies, sends the notification to the called terminal.
-/ 5.2.1.3 Call Waiting Supplementary Service
The Supplementary Service Call Waiting (SS-CW), defined in the H.450.6 Recommendation, permits a busy user B to be informed of an incoming call while being engaged with one or more other calls.
In other words, SS-CW operates in case of an incoming call (from user C, calling user) when a busy condition within the endpoint is encountered. Note that, in general, a busy condition may also be encountered if the user is busy with workflow applications (e.g., writing e-mails).
P.162
[IP Telephony Cookbook] / Setting Up Advanced Services
When the SS-CW is invoked, user B is given an appropriate indication of the waiting call and the calling user C may be informed about SS-CW being invoked at the destination by being provided with an appropriate indication. After receiving the call waiting indication, user B has the choice of accepting, rejecting or ignoring the waiting call. During the call w