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 one but still in a telephony-like environment. The supplementary services are protocol-specific and are intended to 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.
This section describe 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 H.450 series, which establish the signaling between endpoints necessary to implement the telephone-like services. Although some of these services have the same functionalities of the equivalent ones developed for the circuit-switched networks, it is relevant to note that the paradigm of the 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 signaling. 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 service such as call transfer, call forwarding, call waiting and so on. Since the peer-to-peer model used by the supplementary services of H.323, the payload and the signaling 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, we can deduce 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 characterized by an initial cost for the software implementing the service for unlimited use. This last aspect implies that new services can be distributed to the VoIP users in the same way as any other software is sold in the market today.
This scenario raises up problems related to the subscription control of these supplementary services. To this aim, the signaling necessary to these services should routed through the Gatekeeper (or other proxy elements) that, accessing to back-end services containing a service database description, permits, for example, the charging for the use of supplementary services or their blocking in the case there are not subscribed by the customers.
Another issue related to the peer-to-peer approach used in the H.323 supplementary services is the service incompatibility. In H.323, the clients exchange their capabilities and hence, they are able to only 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 signaling translation necessary to guarantee the services. Moreover, the gateway can be used by the provider to charge the service.
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.
The following examples can be useful to understand how the supplementary services can be implemented. In the example, the attention will be focused mainly on the signaling 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.
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 signaling necessary to use the service are 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.10 reports the signaling 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.
The example refers to the case where the Gatekeeper is absent or the direct signaling model is adopted. In these cases, only the software able to process and to generate the APDUs is necessary to implement the service.
In the case of the gatekeeper routed model, the gatekeeper shall either transparently transport or perform the operations necessary to offer the service. In particular, the Gatekeeper can provides 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 signaling 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 signaling on behalf of transferred-to user) that it has been transferred. Furthermore, the Gatekeeper should instruct the endpoint (or endpoints), that it manages the signaling 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 result APDU to release the call signaling 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.
To better understand the signaling procedure used, Figure 5.11 illustrates the messages exchanged for the CT-SS when the Gatekeeper manages the signaling on behalf of the transferred user, i.e. B user.
After the reception and the processing of the FACILITY message indicating that user A wants 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.
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 signaling and proceeds with normal open logical channel signaling 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 signaling channel of the primary calls, i.e. between A and B.
The signaling 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 Served user, receiving a call from an Originating user to redirect it to another user, denoted as Diverted-to user. This operation leads to connect the Originating user with the Diverted-to user, and it is possible only when Served and Originating user are not in a call. There are four kinds of Call Diversion service.
Supplementary Service Call Forwarding Unconditional (SS-CFU) permits a Served user, independently from 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 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 to provide the information related to the activated service, and it is performed on the activation procedure.
Indeed, to activate these services, the Served user shall supply 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 is defined also the Call Deflection (SS-CD), 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.
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.
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 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, which acts as 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 signaling address, rather than the call signaling 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 arrives a call destined for user B (being the served user), the Gatekeeper starts a local "no-response" timer and continues 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.
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. To note that in general, a busy condition may also be encountered if the user is busy with workflow applications (e.g. writing e-mails).
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 waiting condition, the calling user C has the option to release the call or to invoke other supplementary services, e.g. message waiting callback.
In the case of endpoints able to simultaneously manage different calls, the SS-CW is invoked only when an attempt for a new call (i.e. the H.225.0 SETUP message from user C arrives to endpoint B) is made to exceed the maximum number of calls the endpoint B can simultaneously hold. This condition leads the served endpoint B to return an ALERTING message towards the calling user C containing the appropriate APDU.
Meanwhile, the endpoint B locally provides a call waiting indication to the user B. The busy User B can free resources to accept a waiting call by:
- releasing an existing call according to the procedures of recommendation H.225.0;
- using the Call Hold Supplementary Service on an existing call according to the procedures of Recommendation H.450.4;
- using the Call Park Supplementary Service on the existing call according to the procedures of Recommendation H.450.5.
If the served user B accepts the waiting call, the served endpoint sends the CONNECT message to the calling user and proceeds with normal call establishment procedures.
After the reception of the ALERTING message containing the APDU indicating the invocation of the SS-CW by the endpoint B, the calling endpoint provides a call waiting indication to the calling user, which has the following options:
- wait until the waiting call gets accepted (connected) by the served user B;
- release the call;
- invoke other supplementary services, e.g. message waiting callback;
- perform other actions (e.g. sending e-mail).
In the case of the Gatekeeper routed model, the Gatekeeper passes on SS-CW operations transparently. When a Gatekeeper has appropriate knowledge about the served endpoint B status, it may act on behalf of the served endpoint by means of inserting the APDU indicating the invocation of the CW-SS into an ALERTING message received from endpoint B before sending on the ALERTING message towards the calling endpoint.
The Cisco MCM gatekeeper does not support any H.450 features, even though it is itself capable of H.323 proxying. However, Cisco gateways do support an extensive range of H.450 features and can play a significant role in supporting supplementary services for H.450 capable endpoints that would like to reach the PSTN.
The Radvision ECS gatekeeper, being based on a H.323 v.4 protocol stack, implements a number of the H.450 features. On the ECS configuration interface, check the Settings Tab, under the category "Supplementary Services", where you can enable the following:
- Unconditional forward (H.450.3): endpoints may select to redirect calls to other endpoints in all cases.
- Forward on busy (H.450.3): endpoints may select to redirect calls to other endpoints when they are themselves busy.
- Forward on no response (H.450.3): endpoints may select to redirect calls to other endpoints when they could not respond to a call after x minutes.
After enabling the above services, the gatekeeper administrator can define forwarding rules by utilizing the Forwarding Tab. Rules for specific endpoints (Standard), as well as mass-application (Wildcard) rules for whole prefixes can be applied for all three forwarding conditions: unconditional, on busy, on no answer.
For all supplementary services to function, the administrator must enable full routing mode (Settings Tab, category Calls). Make note that the ECS administrator can also initiate calls between endpoints, by using the Call Control Tab, and the Make Call button.
The GNU gatekeeper does not support any H.450 features either. However, some dynamic routing functionality can be implemented by utilizing the "virtual queues" or "CTI agents" feature of the GNU gatekeeper, which allows the operation of a simple model of aliasing a name and the forwarding of calls to a dynamic queue of "agent" endpoints.
This section demonstrates the use of legacy telephony features in SIP. Note that the general SIP design concept has been to leave the description of such features out of protocol specifications. It is responsibility of implementations to introduce new services on top of well defined protocol specification. There are only few well defined protocol elements such as REFER method (RFC 3515). Such elements can be used for a variety of services without having to undergo the burdensome standardization process again and again. With the particular REFER example, the REFER method may be used for several variations of call transfer, click-to-dial application as described in the next section, interaction with conference bridges, etc. The application logic may be completely hidden in a SIP element, or it can use some established service building mechanisms such as Call Processing Language or SIP-CGI (RFC 3050).
To show the proper use of protocol elements for building frequently used services, the IETF issued an informational document Session Initiation Protocol Service Examples . The document presents call flows for many services, including on-hold, transfers, conferencing. Another essential document is A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP) by Rohan Mahy et al. The document shows the concepts of building more complex services based on SIP and also presents multiple design choices for many of them. Yet another usage document related to implementation of telephony services is Third-party call control, which shows how to implement complex multi-stage multi-party telephony conversations using external SIP-based call control.
The rest of this section demonstrates the most frequently used SIP services, gives a brief overview on provisioning of such services, and also describes how the signalling looks like.
With SIP, on-hold is implemented as a peer-to-peer feature. A phone putting the other telephone on hold does so by sending a specially-formed re-INVITE request. In response to such a request, the other phone stops sending media to save bandwidth and it indicates to user that he is on hold. (It may be silent, display status using user interface, play local music, etc.) There are subtle differences in how "on-hold" is signaled in earlier and current SIP version. RFC 2543 used dummy IP address 0.0.0.0 to indicate on-hold condition whereas RFC 3261 uses SDP sendonly attribute. Call-flow on Figure 5.12 presents on-hold signalling implemented according to RFC 2543. The key message is re-INVITE, number 3, which puts other party on hold. The SDP payload of numbered SIP messages is shown in detail (SIP headers have been removed because they are not important in this case).
The following message is regular INVITE establishing a call
1. INVITE [SIP headers not shown] v=0 o=Cisco-SIPUA 997 27044 IN IP4 192.168.2.32 s=SIP Call c=IN IP4 192.168.2.32 t=0 0 m=audio 21112 RTP/AVP 0 8 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15
The previous INVITE is replied using the following 200 OK
2. 200 OK [SIP header not shown] v=0 o=CiscoSystemsSIP-GW-UserAgent 2451 1894 IN IP4 195.37.77.110 s=SIP Call c=IN IP4 195.37.77.110 t=0 0 m=audio 18202 RTP/AVP 0 c=IN IP4 195.37.77.110 a=rtpmap:0 PCMU/8000 a=direction:passive
The following message puts the remote party on hold. Note the 0.0.0.0 on the line beginning with “c=”.
3. re-INVITE [SIP headers not shown] v=0 o=Cisco-SIPUA 4919 16082 IN IP4 192.168.2.32 s=SIP Call c=IN IP4 0.0.0.0 t=0 0 m=audio 21112 RTP/AVP 0 8 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15
The following message confirms the on hold state. There is nothing special in the SDP
4. 200 OK [SIP headers not shown] v=0 o=CiscoSystemsSIP-GW-UserAgent 2451 1895 IN IP4 195.37.77.110 s=SIP Call c=IN IP4 195.37.77.110 t=0 0 m=audio 18202 RTP/AVP 0 c=IN IP4 195.37.77.110 a=rtpmap:0 PCMU/8000 a=direction:passive
The call transfer is one of the most frequently used telephony services. The protocol element used in SIP to implement call transfer is the REFER method. The REFER method is a very powerful mechanism, which allows anybody to ask a SIP device to initiate a call to a specific destination. Call transfer is only one application which relies on REFER -- “click to dial” and conference management can utilize REFER as well. Even call transfer may be implemented in a variety of ways in SIP telephones.
“Unattended transfer” (also called “Blind Transfer”) transfers a call participant to another party, whereas the transfer originator drops the initial conversation.
In “Attended transfer” (also called “Transfer with consultation”), the transferor first initiates a short conversation with the transfer target before connecting it to the transfered party.
Other variations may include a short introductory conference during the call transfer or keeping the original conversation active until the transfer succeeds. (the NOTIFY request is used to report on success of call transfer in SIP.)
The following call flow demonstrates the use of REFER for unattended call transfer. The key requests are REFER (red) by which the callee suggests the caller to establish a conversation with the transfer target. The caller does so by sending the INVITE (blue). The callee exits the original conversation by sending BYE (green) without awaiting the completion of the call transfer.
The following REFER message (red in the call flow) asks the caller to establish a call to the transfer agent. Note that the message contains the “Refer-To” header field containing SIP URI of the transfer agent and “Referred-By” header field which contains the SIP URI of the initiator (the callee).
REFER sip:195.37.77.101:5060;lr SIP/2.0 Via: SIP/2.0/UDP 192.168.2.32:5060 From: <sip:callee@iptel.org>;tag=00036bb90fd300 To: <sip:caller@iptel.org>;tag=992d8f53-ca7e Call-ID: 90bdee69-eb4f@192.168.0.130 CSeq: 103 REFER Contact: sip:callee@192.168.2.32:5060 Route: <sip:caller@193.175.135.38:40012> Content-Length: 0 Refer-To: sip:transfer_agent@195.37.77.101 Referred-By: <sip:callee@iptel.org<
The following INVITE message (blue in the call flow) establishes a call from the caller to the transfer agent. Note that the value from the “Refer-To” header field of the REFER message has been put into the Request-URI and “To” header field.
INVITE sip:transfer_agent@195.37.77.101 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.130 From: <sip:caller@iptel.org>;tag=32e189db-ec7e To: <sip:transfer_agent@195.37.77.101> Contact: <sip:caller@192.168.0.130> Call-ID: 205e377f-7042-b00c-0@192.168.0.130 CSeq: 20142 INVITE Max-Forwards: 70 Content-Type: application/sdp Content-Length: 258 v=0 o=caller 0 0 IN IP4 192.168.0.130 s=- c=IN IP4 192.168.0.130 t=0 0 m=audio 5004 RTP/AVP 0 8 4 18 2 15 a=ptime:20 a=rtpmap:0 PCMU/8000
The following BYE message (green in the call flow) terminates the call between caller and callee.
BYE sip:195.37.77.101:5060;lr SIP/2.0 Via: SIP/2.0/UDP 192.168.2.32:5060 From: <sip:callee@iptel.org>;tag=00036bb90fd3000 To: <sip:caller@iptel.org>;tag=992d8f53-ca7e-c73f Call-ID: 90bdee69-eb4f-3e1c-9833-499857a5b2b2@192.168.0.130 CSeq: 104 BYE Content-Length: 0 Route: <sip:caller@193.175.135.38:40012>
User's ability to determine call processing is a great strength of IP telephony. With SIP in particular, users are able to associate any number of devices with their address of record. SIP telephones register their whereabouts automatically using the SIP REGISTER request. Users may also introduce additional contacts by the means of provisioning. Upon receipt of an incoming call request (INVITE method), a proxy server forwards the request to all registered contacts. Eventually, all registered phones start ringing in parallel and the conversation begins with the device on which the user picks up.
The ability to manipulate contacts allows users to determine handling of incoming calls. For example, a user may wish to decide that all incoming calls will be ringing his cell phone as well. The following set of examples shows how the manipulation of registered user contacts can be used for forwarding purposes. The examples use SER and its command line control tool, serctl, to manipulate contacts of a user. Typically, this job is done through web interface such as Serweb because it is more convenient. The commands used are “ul add USER SIP_CONTACT” for introducing a new forwarding address and “ul show USER” for displaying currently registered contacts.
Let us begin with inspecting the current status of registered contacts. The command reveals that a SIP phone registered a contact from IP address 212.202.42.68.
jiri@fox:~$ serctl ul show jiri <sip:212.202.42.68:55723<;q=0.00;expires=272
To enable forwarding of incoming calls also to cell phone, introduce contact to the PSTN gateway. If a call arrives, the proxy server will ring both -- previously registered SIP phone and manually provisioned cell phone contact.
jiri@fox:~$ serctl ul add jiri sip:123456@iptel.org
sip:123456@iptel.org
200 Added to table
('jiri','sip:123456@iptel.org') to 'location'
jiri@fox:~$ serctl ul show jiri
<sip:123456@iptel.org>;q=1.00;expires=1073741820
<sip:212.202.42.68:55723>;q=0.00;expires=21
Callees frequently wish to redirect incoming calls to an alternative destination if primary destination fails to answer. The reasons for failure are multi fold. They may include busy callee, disconnected callee's phone, user who currently does not answer, or user denying the incoming call. The alternative destination is typically a voicemail system but it may be also another human or some other SIP device.
The following configuration fragment demonstrates how set up such a feature using SER:
# if invitation recipient off-line, forward to voicemail
if (!lookup("location")) {
rewritehostport("voicemail.iptel.org");
t_relay_to_udp("voicemail.iptel.org", "5060");
break;
};
# user on-line, forward INVITE to him; also set up a failure
# handler so that we can redirect to voicemail if the
# call is not established successfully
if (method=="INVITE") {
t_on_failure("1");
};
t_relay();
....
# alas, the call was not established successfully; well,
# let's retry with voicemail then
failure_route[1] {
revert_uri(); # resend to voicemail with original request URI
rewritehostport("voicemail.iptel.org");
append_branch();
t_relay_to_udp("voicemail.iptel.org", "5060");
}
Whereas this example demonstrates a global site policy which is applied to each user, some subscribers may wish to formulate their specific call processing preferences. How the preferences are formulated and provisioned in the SIP server is not necessarily governed by standards. SIP servers may have their own proprietary user provisioning interfaces, typically with a web front-end. On the other hand, a standardized way of call handling allows easier service portability. The IETF standard for describing callee's preferences is called Call Processing Language, CPL shortly. It is a simple XML-based language, that allows subscribers to determine how the server handles calls for them. It is a special-purpose language that support specification of most common types of call processing. CPL does not allow script writers to affect the behaviour of the server in a way which could compromise the security of the server.
Whereas it is simple enough, most users will not be willing to write SER scripts. It is envisioned that CPL scripts will be generated and edited by applications with a convenient user interface. The following picture shows a screen snapshot of iptel.org's CPL editor.
