SIP TRUNKING THE ROUTE TO THE NEW VOIP SERVICES

Transcription

1 SIP TRUNKING THE ROUTE TO THE NEW VOIP SERVICES Ivan Gaboli Italtel Virgilio Puglia Italtel ABSTRACT This work gives an overview of SIP-Trunking solution and explains the existing difficulties in implementing VoIP services, when this architecture is deployed in multivendor environment. The causes of these problems are explained with two existing approaches used by carrier to solve interoperability: they are Full Jacket SIP-Trunk and Customized SIP-Trunk. A solution to cover the lackings of SIP standards is the introduction of a SIP adaptation device called Inter-Domain Adaptation Device which will increase the potentiality of SIP-Trunking based solutions. It is also proposed a method for assessing the complexity of different approaches to SIP-Trunking applications. Keywords SIP-Trunking, T.38, MTP, SBC, PBX. 1. INTRODUCTION There is an evident evolution of technology used by Telecom Providers tending to migrate voice services from traditional TDM networks to new VoIP networks, especially involving SIP-Trunking solutions. The number of this type of migrations is expected to grow dramatically at 106% Compound Annual Growth Rate (CAGR) in the next few years, to reach nearly in 2012 in West Europe [1]. The main driver of this migration is reduction in capital expenditures (CAPEX) and decrease of the operational expenditures (OPEX). But this migration determines also a slight quality of voice service reduction; depending on speech coder of VoIP the Mean Opinion Score (MOS) [2] may vary and usually is near to 4 [3] a bit less than the traditional TDM fixed networks but similar to mobile users experience. The technology change determines also migration problems for already deployed services. If it s problematic to implement consolidated services like analogical fax and modem (see e.g. Sip-Forum that realizes a FoIP Task Group [4],[5]), it s also easy to understand how it s difficult to deploy new services like IP Automated Trading Desk or complex mandatory services like support for handicapped (bars brail, hearing, etc.). The introduction of new VoIP solutions at Enterprise level is a great opportunity to redesign and standardize services. SIP-Trunking makes possible to implement new services (like Presence, videoconference, telepresence, virtual-fax) accessible as advanced communications as a service and that can change customer perception and improve productivity, collaboration and travels costs reduction. Service Providers (SPs) can obtain savings in terms of CAPEX and OPEX, but this new solution introduces interoperability problems between different technologies and vendors. This situation is similar to the ISUP solution in the beginning of 90 [6]; but today there are a wide range of players that develop VoIP products for business market like s and Corporate Switching Nodes (CSN). There are big vendors (like Alcatel-Lucent, Ericsson, ) as well as small software houses that develops applications [7] on commercial hardware. This implementation simplicity determines solutions based on different interpretation of SIP protocol, permitted by laxity of SIP standards, which leaves room for proprietary adjustments in features such as advanced calling features, security or QoS. Hence compliance with SIP standards doesn t guarantee seamless communication between end-users that leverage on different systems. The SIP-Forum [8] tries to solve this problem with an architecture framework proposal (SIPconnect) that define a minimal set of IETF and ITU-T standards that must be supported and provides precise guidance in the areas where the standards leave multiple implementation options and specifies a minimal set of capabilities that should be supported by the SPs and enterprise s networks [9]. Some vendors try to promote the sharing of knowledge and experience through on-line community [10]. All this approaches demonstrate the existing difficulty in SIP- Trunking Architecture deployment, specifically in very large and multi country scenarios; but new services and voice traffic cost reduction push Large Enterprises to issue Request For Quotation for SIP-Trunking solutions in order to put in competition SPs and gain the best ROI (Return Of Investment). So customers ask for quick deployment and SPs must be able to respect customers requirements. This paper addresses some topics encountered during the implementation of complex systems integration projects implemented by Italtel for Large Enterprises and Service Providers. 2. SIP STANDARDIZATION MODEL The SIP protocol is standardized by IETF Requests For Comments (RFCs) developed in an open and communal environment. To have the greatest possible consensus in committees and satisfy the largest number of participants, usually the RFC bloated in both size and flexibility. The specifications are full of weak terms like "May" and "Should" that allows the developers of SIP-based systems /CFP1038E Kaleidoscope

2 2010 ITU-T Kaleidoscope Academic Conference to make plenty of free decisions. So two VoIP systems may be incompatible with each other while being both compliant with specs; e.g. there are many standard ways to transport DTMF (Dual-tone multi-frequency) tones: - RFC2833 [11]: specialized payload packets in the ; - RFC4730 [12]: SIP-NOTIFY with XML docs; - SIP-INFO [13]: a SIP message with specific payload. This approach is entirely different from ITU-T specifications that the Telecommunications Industry was regulated or standardized for the last four decades. Hence the problem does not start with the technology, but with the approach in creating standards. 3. SIP BUSINESS TRUNKING ARCHITECTURAL MODEL The SIP Business-Trunking reference architecture is a five level hierarchical architecture divided into two domains: Public and Private. The Public Domain has two levels represented by: - Class 5 softswitches (SSW-C5), that are the first level of the network model; - Network Border-Elements (second level) that is the frontier of the public domain towards customers. The Private Domain has three hierarchical levels: - Corporate Border-Element, the frontier towards the public network; - Corporate Switching Node (CSN); - s. Public Domain Private Domain AS CSN Very Large Enterprise Class 5 Softswitch SIP SIP-I ISUP Media NGN Border Elements Figure 1: Network Architectural Model Medium/Large Enterprise PSTN/PLMN The SSW-C5 are generally connected northbound to the SP s transit network (Class-4 Exchange) via ISUP or via SIP-I/SIP-T whereas southbound SSW-C5 provides a SIP User to Network Interface (UNI) that allows the end user access to the PSTN/PLMN; the Business-Trunking UNI is defined combining a set of RFCs with appropriate policy defined by the carrier. Between the SSW-C5 and Private Domains there is a layer of Border-Elements () that provide the following main features: network topology hiding; application layer firewalling; NAT-SIP aware. These devices provides termination and reorigination of both signaling and media between Public and Private domain. The CSN can be inserted in the architecture when the private VoIP network is very large and there are benefits having a local session routing capabilities. The CSN provides the following main functionalities: Corporate s interconnection point; Centralized session routing; On-Net/Forced On-Net calls management; Corporate s private numbering plan management; signaling mediation between Corporate VoIP network and SP s Business Trunking UNI; private/public phone identity translation. The CSN represents also the Network Element (NE) that interconnects Application Server like: Fax-Server, Microsoft Office Communicator, Presence-Server, etc.. Lower the CSN there are multiple with attested IP- Phones. The described architecture can be declined in two different ways depending on the treatment modality of the user-plane ( flow) that can be: Fixed-Media modality; Variable-Media modality. 3.2 Fixed vs Variable media In the VoIP world the stream (user-plane) typically is peer-to-peer, this means that end-points negotiate end-toend media informations and they are always involved in each media stream variation (e.g.: when an hold with music is invoked). The signaling passes end-to-end through al network elements involved in the path. This type of userplane treatment is called Variable-Media. In the traditional ISDN-PBX the media is anchored by the PBX itself that terminates BRA/PRA links and, when needed, perform signaling and media loop splitting the call in two different legs.

3 Beyond the Internet? Innovations for future networks and services s vendors have realized some dedicated elements that perform media anchoring and emulates traditional PBX behavior called Fixed-Media; for example Cisco has MTP (Media Termination Point) function [14] and Avaya has Prowler Cards [15]. The Fixed-Media architecture in dramatically simplifies the interconnection with carriers via SIP- Trunking because all the calling scenarios are reduced to a basic-call ; so the Fixed-Media Architecture is characterize by the presence of anchoring equipments. Unfortunately elements like MTP etc., increase costs without added value to the customer and in some cases creating limitations to the evolution of the services (for example they are not able to treat video); hence recommended choice is to adopt Variable-Media model. 3.4 SIP Business Trunking Benefits The SIP Business-Trunking allows to realize a centralized dedicated telephony infrastructure at the enterprise s premises that permits to conform services delivered to all offices with the added value of customizing them to the needs of the end users. A centralized platform management permits the control of the delivered service s quality (think of companies with so many small/medium sites all around the world, where telecommunication is a commodity). SIP also revolutionizes the way through which Enterprises can realize interconnection with SPs; so it is possible to concentrate the interconnection with the public network in a centralized point with a substantial saving of cost of interconnection. Moreover the Large Enterprises can choose more than one SPs and can choose the trunk to be used depending on type of traffic (towards PLMN, PSTN, international ) and rate applied by the SP s. 4. SIP BUSINESS TRUNKING SIGNALING MODEL The setup of a voice call with SIP protocol is based on signaling flow that allows the network to perform the session routing and the bearer capabilities are negotiated by the endpoints through the offer/answer procedure as specified in the RFC3264 [16]. Referring to the SIP business trunking architectural model, in the following figure an example of a VoIP signaling call flow is depicted. The call is initiated by an IP-Phone directing towards PSTN, through a SIP-Trunk interconnection. The call is terminated by a SSW-C5 with trunking gateway functionalities and redirected toward PSTN. In the example is supposed that CSN use an Inter- Cluster-Trunk protocol to dialog with corporate s s and the s use custom protocols versus controlled IP Phones (e.g. Cisco Skinny Protocol). Private Domain Custom IP Phone Skinny Skinny Skinny IPPBX CSN CSN SSW-C5 MGW 1. INVITE (no SDP) Trying ringing (g729, sendrcv) 14. PRACK (g729) OK OK (g729) 23. ACK (g729) 3. INVITE (no SDP) Trying ringing (g729, sendrcv) 15. PRACK (g729) OK OK (g729) 24. ACK (g729) Figure 2: Call Setup in the reference architecture The signalling model varies depending on whether you choose the Fixed-Media or the Variable-Media modality; depending on the choice made for media we will speak respectively about: ISDN-like SIP-trunk signalling model; Pure SIP-trunk signalling model. ISDN-like SIP-trunk model is not detailed in this paper because it does not give any added advantage as described in 3.2; so we will focus our attention on Pure SIP-trunk model and we will introduce a newly proposed Hierarchical SIP-model that maintains the flexibility of pure model and simplifies the interworking between different technologies. 4.1 Pure SIP trunk signaling model SIP SIP H.248 ISUP 5. INVITE (no SDP) Trying ringing (g729, sendrcv) 16. PRACK (g729) OK OK (g729) 25. ACK (g729) (Ring Back Tone) 7. IAM 8. ACM 9. CRCX (g711, g729, T.38) 10. OK (g729) In a pure SIP signaling model with variable media, it is expected that messages originated in a corporate premise will be propagated to other corporate premises involved in the scenario. The following figure is an example of the simplified signaling flow after a successful call setup, the called user performs a blind call transfer towards a PSTN number: SIP 15. ANM Public Domain PSTN Figure 3: Call flow example (simplified without CSN)

4 2010 ITU-T Kaleidoscope Academic Conference The initial INVITE-200OK-ACK [23] exchange determines the establishment of the call; after that the end-user performs a call transfer. The call transfer invoked by the user of Enterprise-B, triggers a sequence of signaling that cross all the network elements and impacts also the of Enterprise-A (see REFER [17] in figure 3 that crosses all the network). The of Enterprise-A must be able to understand signaling and perform requested service; in this example it must manage the REFER method and implement the call transfer service. In the pure SIP signaling model the service logic is distributed only between the two, whereas the SSW-C5 performs the routing functions. This is a simplified approach but implies that all the IP- PBX are able to perform requested service logics and, when a new behavior is introduced in the network by a new element, all the interoperability tests must be performed to be sure that no regression happened. In the figure s example there is also another point of attention (marked with *): in the signaling flow proposed by RFC5589 [18] a new INVITE is issued by transferee. The INVITE could not be correctly associated to the call transfer service, so the transferee can be in the condition to be charged for the entire leg of the call (from transferee to target). The transferor will not be charged for the second leg of the call (and this can be not compliant with country charging requirements). By the way plain SIP networks are simpler than hierarchical one but the latter better fulfill SP s requirements like Call Detail Records generation (CDR), (crucial for billing purposes) and SP s UNI technical specifications. 4.2 Hierarchical SIP signaling model To establish successfully sessions between two users and to manage the various scenarios that can happen during the call, it is important to consider and manage different aspects such as: Identity management & certification; Voice-codec compatibility; DTMF interoperability; Encryption; Fax support; CDR generation. The call-flow in figure 3 highlights how each new NE or new service introduced in the network may have impacts towards all other NEs present in the Public or Private domains. The pure SIP signaling model has a big constraint so in this period of standardization laxity it is better to implement a hierarchical architecture where it is foreseen some harmonization functions that split various domains and simplify the interworking procedures. The harmonization function can be performed either in a dedicated network element or embedded in the SSW-C5 or. The right choice depends on the specific characteristics of the network; a hierarchical architecture allows adopting some specific rules on the SSW-C5 that force a well defined behavior on the UNI and guarantee SPs to maintain the control on user s operations. 5. GO TO MARKET APPROACH Waiting for an efficient standardization of SIP, the SPs have two possibilities: Full Jacket (FJ) If the volume (number of enterprise customers) is high, the SP can define some pre-packaged solutions. This approach is usually utilized by the incumbent Carrier Customer Tailored (CT) The SP tries to satisfy all the customer s requests without imposing technical limitations or prepackaged service bundles 5.1 Full Jacket The Full Jacket approach defines all the various equipments and services that can be supported by the solution and combine them into bundles; each bundle is pre-certified and can be sold as an out-of-the-shelf product. The SP sells to the Enterprise all the necessary platform and terminals to provide services. It s more easy to propose a FJ bundle when the customer is a green field. Each time it is required to introduce a new service and/or a new device, it is necessary to update the bundle with dedicated study and test sessions. The expected effort for this kind of activity can be evaluated as a proportion of the possible combinations between all the devices as show in the following formula: [1],, Where TF is the total number of functionalities that must be supported, NS is the number of Enterprises, n, is the number of typology devices that are involved for the f function on the enterprise i. The k, is the number of typology devices that are involved for the f function on the enterprise j. The effort to validate the solution is made at the first implementation, with this approach we operate every time in a Homogeneous Domain (HoDo). 5.2 Customer Tailored The Customer Tailored approach complies with all the requests of the customer case-by-case. This means that all the devices, terminals and services are selected by the Enterprise based on its commercial/technological requirements. All the devices and terminals are customer ownership and usually are managed by the SP with a specific contract of maintenance. The delivery effort depends on the typology

5 Beyond the Internet? Innovations for future networks and services and the number of devices involved, not only in current implementation, but also in the previous one. So from the SP s point of view the complexity increases with the increase of acquired customers. The expected effort can be evaluated as indicate in the formula [1]. Each time a new Enterprise with different devices is added to SP s network, the effort put in solving the problems can be evaluate as show in the following formula: [2], Where n is the number of typology devices involved in the f function by the new enterprise. NS is the number of already existing Enterprise. The k, and TF are the same of formula [1]. With this approach we operate every time in a Inhomogeneous Domain (InDo). Usually an Enterprise which selects InDo has the trend to realize multi vendor domains in their premise, so the interoperability problems start already at customer s home. 6. RECONCILATION TWEEN THE APPROACHES Both approaches (FJ and CT) can have serious compatibility problems with the volumes expected in the next three years in the SIP business trunk market. Each SP will have a complex InDo, composed by islands of HoDo; there is a concrete risk to have an unmanageable network with exponential growth of OPEX. We propose to adopt the SIP Business Trunking and signaling architectural model (cfr. 3, 4.2) with a new network function (or element) denominated Inter-Domain Adaptation Device (IDAD) which understands simultaneously all the standard SIP-messages and call flows and can harmonize them. The IDAD perform the following main functionalities: Media Anchoring; Dynamic Audio/Video transcoding; Signaling decoupling & normalization; Interdomain features harmonization; Session Admission Control; Fax adaptation; DTMF interworking; Encryption termination. Italtel has developed a feature called Media Termination Function (MTF) on board of its own Softswitch (i-ssw [19]) that performs some of IDAD s functionalities. 6.1 Media Anchoring In a standard SIP session the flow goes peer-to-peer; Media Anchoring feature allows IDAD to anchor the media stream splitting the flow in two segments and to monitor both session s user and control plane and perform transcoding if necessary. The usage of this feature makes also possible to perform signaling normalization as described in 6.3. The anchoring point represents a unique interworking point for all other domains towards which the originating domain will be connected with. Enterprise A No Media Anchoring Class 5 Softswitch Figure 4: Media path with/without media anchoring The singularities of the originating domain will be managed by IDAD preserving other domains thus simplifying interoperability. The Media Anchoring is also an opportunity to be able to complete successfully a session between two domains with no common shared codec (IDAD intercepts the and performs the required media transformation). 6.2 Dynamic Audio/Video transcoding Enterprise B Class 5 Softswitch IDAD During the SIP session setup it is performed the offer/answer procedure [16] that is used by user agents (UA) to agree codecs that must be used for communication. If the two parties don t have a common audio/video codec, the negotiation will fail unless IDAD intercept the codec mismatch and engage transcoding resources. Depending on the session setup scenario the IDAD can decide to book transcoding resources based on one of the following events: The originating domain presents a set of codecs insufficient for the destination domain (based on provisioning information); Catching an error response received by destination UA. In the first case the IDAD enriches the codec bouquet with all codecs defined by provisioning information and, if the answer will select a codec that the origin domain doesn t support, IDAD will perform requested transcoding. In the second case when IDAD reveals an error message for codec mismatch, it will issue a new INVITE with an SDP with all codecs supported by IDAD and performs requested transcoding. An alternative to perform a provisioning of codecs supported by various domains can be represented by the auto-learning feature of IDAD that will learn dynamically (based on error messages revealed during session instauration) the set of supported codecs by various domains and it applies resource reservation and transcoding following self-learned rules. Enterprise A Media Anchoring Enterprise B

6 2010 ITU-T Kaleidoscope Academic Conference 6.3 Signaling decoupling & normalization The IDAD, in combination with SSW-C5, performs a decoupling of the signaling among domains terminating and re-originating SIP session in a Back-to-Back logic. This behavior allows IDAD to perform a normalization of headers used/expected from/by various domains. A typical example: SIP Diversion Header [20] and History Info Header [21], both permitted by standards to indicate in which point a session has suffered a transfer. IDAD performs requested adaptation to make different SIPdialects compatible by different vendors. 6.4 Interdomain features harmonization Some features or methods not declared mandatory by standards, can create interworking problems between IP- PBX of different vendors; for example some domains are using UPDATE method [22] while others do not support it or direct fax session setup with Fax Relay (T.38). The IDAD performs the interdomain harmonization by interpreting and filtering the particular features used by a specific domain and spreading only basic and more common procedures towards others domains. For example a fax call that starts directly in T.38 (without a previous establishment of a session that uses a voice codec) the IDAD can emulate towards called domain a more widespread behavior that consists in setting up as first step a G.711 session and try later to negotiate a T.38 fax relay codec; in this way the percentage of a successful session setup is higher and the fallback to fax pass-through mode is guaranteed. But a well designed access can also go in defect for some rare events when the profile of traffic heavily violates the traffic model considered in design phase. The Session Admission Control performed by IDAD allows to monitor the saturation of available bandwidth; IDAD per each access considers the used codec and the bandwidth occupation. When the amount of occupied bandwidth surpasses a specific percentage threshold new sessions request will no more be authorized for the specific access. The IDAD can also differentiate the admission policy depending on the codec used, so for example video can be allowed only when e specific percentage of bandwidth is available or for a limited number of sessions. 6.6 Fax Adaptation In the IP world there are two common ways to transmit fax: Fax Passthrough (G.711 clear channel); Fax Relay (T.38). This two methods are incompatible with each other; the best practice is to use T.38 which is more reliable, but sometimes T.38 cannot be used. So in the real world a SP can have domains that use T.38 (with no fallback to G.711 capability) and others that support only Fax Passthrough. In this case IDAD is able to detect the incompatibility of fax codecs during the session setup phase and perform the necessary transcoding operations and signaling adaptation to have a successful fax transmission. 6.7 DTMF in-band/out-of-band transformation Once the session is established it s possible for user agents to exchange DTMF end-to-end. DTMF can be transmitted in two different modalities: Figure 5: Signalling harmonization 6.5 Session Admission Control The access bandwidth (data link between enterprise and SP) is a parameter subject to the contract s Service Level Agreement negotiated between SP and Enterprise; so the amount of access bandwidth should be determined as the trade-off between traffic expected and bandwidth s cost. In Band The digit is transmitted in the media flow marking in a particular way an packet following RFC2833[11] ; Out-of-band The digit is transmitted following the signaling path using: o SIP-INFO Method o KPML (RFC4730 [12]) SIP-INFO is more widely supported although less well standardized. In this heterogeneous DTMF transmission modes present today, the IDAD presence in the network resolves DTMF exchanging problems performing transformation among various methods.

7 Beyond the Internet? Innovations for future networks and services Class 5 Softswitch TF [4] n DTMF Out-of-Band /C- INFO (DTMF2) IDAD INFO (DTMF2) Packet DTMF 2 RFC 2833 /C- DTMF In-Band Where n is the number of typology devices that are involved for the f function on the added enterprise. The effort without IDAD is significantly major than with IDAD as showed by the following formula: TF [5], n UII DTMF 2 7. DISCUSSIONS AND CONCLUSIONS Figure 6: DTMF transformation Based on the domains characteristics IDAD decides when it is necessary anchor the media flow and to perform DTMF transformation ensuring interoperability. 6.8 Encryption termination There are some enterprises which request to have the voice encryption. Typically this kind of requirement can be satisfied inside the customer premises but sometimes this requirement exists also between different enterprises that belongs to the same group. It is difficult for SP s to provide encryption in this enlarged scenario with different methods of encryption used in different domains, non sharing of key/certificate between different organizations, obligation to be able to apply lawful interception. The IDAD allows SPs to offer encryption of voice flow between different enterprises maintaining the capability to intercept the voice stream if requested by the authorities; indeed IDAD can anchor the user-plane and perform the required decryption/encryption process. 6.9 Simplification of the complexity The deployment of a new technology domain implies a campaign of certification tests that covers all possible combinations between different technologies for their interworking because of weak standardization of SIP- Trunk interface. With the introduction of IDAD platform, the expected effort to insert a new HoDo, will be proportional to the possible combinations between all the devices and the IDAD. See the following formula: TF NH D [3] n, Where NHoDo is the number of Enterprise in the new HoDo. The TF and n, are the same of formula [1]. For example when a new island HoDo, realized by a single enterprise, is inserted, the effort can be evaluate as show in the following formula: The objective of this paper was to provide an overview of SIP-Trunking solution, their state of art and show the tendencies of their development. Some problems that impact on the services were analyzed. We strongly believe the most likely evolution of VoIP will be SIP-Trunking, that will permit the creation of new services for end users. But both models used today by Carrier (FJ and CT) may have serious compatibility problems with the market volumes expected in the next years. The strengthening of the standards is the main way to go forward for multi-vendor interoperable solutions, but we must also consider the market presence of many smallmedium players coming onto the world of telecommunications with the advent of VoIP. These players prefer the development of products/services that are partially compliant with product of other vendors, but meet the needs and timing of the market. It is difficult that these players will waiting for standard s maturity. For these reasons in this study we have proposed a solution (IDAD) to cover the lapses/lackings of SIP standard, without limiting the network flexibility. We hope this study will serve as a stimulus for improve the SIP standardization and for further research in above-mentioned subject area. REFERENCES [1] Salmeron, Western European SIP-Trunking Market, , Decembre 2008, IDC #WS06Q, volume:1; [2] ITU-T Recommendation P.800 Methods for subjective determination of transmission quality; [3] D.Collins, Carrier Grade Voice Over IP,McGraw-Hill; [4] SIP Forum Fax_Over_IP_Task_Group Problem Statement V1.0; [5] SIP Forum Fax_Over_IP_Task_Group Addressing the Identified Problems; [6] Cazzaniga,Garavelli, Implementation of SS7: Italtel's experience,ieee, jul.1990,vol.28; [7] [8] [9] SIPconnect Whitepaper, The SIPconnect Technical Recommendation,rev1; [10] [11] H.Schulzrinne,S.Petrack, RFC2833, Payload for DTMF Digits, Telephony Tones and Telephony Signals ; [12] E.Burger,M.Dolly, RFC4730, A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML) ; [13] S.Donovan, RFC2976, The SIP INFO method ;

8 2010 ITU-T Kaleidoscope Academic Conference [14] m/admin/3_1_1/ccmsys/a05mtp.html#wp ; [15] [16] J.Rosenberg,H.Schulzrinne, RFC3264 An Offer/Answer Model with the Session Description Protocol (SDP) ; [17] R.Sparks, RFC3515, The Session Initiation Protocol (SIP) Refer Method ; [18] R.Sparks,A.Johnston,D.Petrie, RFC5589 Session Initiation Protocol (SIP) Call Control Transfer ; [19] [20] S.Levy, Internet Draft, Diversion Indication in SIP draft-levy-sip-diversion-11 ; [21] M.Barnes, RFC4244, An extension to SIP for request history information ; [22] J.Rosenberg, RFC3311, The Session Initiation Protocol (SIP) UPDATE Method ; [23] J.Rosenberg,H.Schulzrinne,G.Camarillo, RFC3261 SIP: Session Initiation Protocol ;