SIP Forum R. Parthasarathi Internet-Draft Aricent Intended status: Informational November 27, 2007 Expires: May 1, 2008 Field Challenges of SIP UA implementations draft-partha-field-challenges-ua-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six Months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 1, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This paper focuses on identifying call services interoperability issues observed in some of the existing SIP deployments. Call services and their interactions are not standardized in SIP but the building blocks for these call services are standardized. In the real world, SIP primitives (INFO, OPTIONS, REFER, INVITE with Join etc.) are used differently by different implementations owing to a lack of clear standardization for Call services realizations leading to complex UA architectures to ensure interoperability. This paper provides the challenges involved in implementing SIP UA which is capable of interoperating with multiple existing SIP network entities in terms of call services, configuration mechanism . Parthasarathi Expires May 1, 2008 [Page 1] Internet-Draft Field Challenges of SIP UA November 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. User Agent Modes . . . . . . . . . . . . . . . . . . . . . . 2 3. Call Services. . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Illustration of different call services implementation . 3 3.2. Emergency call (dialog) implementation . . . . . . . . . 5 3.3. Fax Call implementation. . . . . . . . . . . . . . . . . 6 3.4. Call Feature Interaction . . . . . . . . . . . . . . . . 6 4. Configuration mechanism usage. . . . . . . . . . . . . . . . 7 5. Media handling . . . . . . . . . . . . . . . . . . . . . . . 7 6. Current status of standardization. . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . 8 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . 10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Typically, for a UA vendor to be able to gain foot-hold in a telecom service provider network, it is incumbent upon the vendor to be able to interop with the SIP[1] network entities deployed by that provider. In the long run, this leads to a scenario where a UA vendor ends up having to accommodate SIP network entities from different vendors. It is observed that establishing a basic call (without any early media) is easily achieved with almost all SIP network entities. Additionally, network entities from different vendors also share a similar call flow for some of the call services. However, there can be subtle differences even in these similar flows and there are multiple ways to implement the same call service. So, the real challenge for UA vendors is to implement an UA which can interop with multiple vendors. For brevity, the SIP network entities (such as Proxy, B2BUA, SBC, Application Servers(AS)) are referred as SIP Servers in this paper. 2. User Agent Modes Call services can be classified into two categories: the services that can be implemented only by the SIP server (like Voice Call continuity(VCC), lawful intercept, forking) and the services that can be implemented either by the UA or by the SIP server (3-Way conference (3WC),Call Transfer, Call Waiting etc.). In this paper we are concerned with the latter category since it has an impact on UA implementations. Some SIP servers expect UAs to have the logic for handling call services while others expect the UAs is to merely convey User Parthasarathi Expires May 1, 2008 [Page 2] Internet-Draft Field Challenges of SIP UA November 2007 actions (like Hookflash, digits etc.) and handle the service logic themselves. Based on the above requirements, UA shall be expected to operate in two scenarios: Service logic in the network (hereby also referred to as Thin Client) and Service logic in the UA (hereby also referred to as Thick Client). When a UA is deployed in the Thin Client mode, SIP servers take care of the service logic based on 3PCC mechanism [2] and the UA is unaware of the service flows. An example for Thin client mode is the “loose coupling” procedure specified in PSTN/ISDN Emulation Subsystem [3]. Another common approach is to use the INFO method with a proprietary message body to convey User events to the network. In the Thick Client mode, call services and call control logic are implemented in the UA using primitives mentioned in call control framework [4]. Services like three way conferencing with local mixing can be done only in this mode. Some SIP servers enforce only one of these two modes of operation. Hence for the UAs to be interoperable with the whole spectrum of SIP servers by different vendors, it is recommended that UAs support both these modes. 3. Call Services 3.1 Illustration of different call services implementation Service functionality can be achieved in multiple ways using SIP as there are no binding standard specifications even for the basic services. Call Waiting (CW) is one of the commonly used services in which the User is alerted for a new call when the User is already involved in another call. On receipt of an appropriate trigger from the User, the new call is connected and the existing call is put on hold. The User has the option to toggle between the two calls. The following call flows illustrates different ways of implementing call waiting service. 3.1.1 INVITE-based Call flow in Thick Client mode CW in Thick Client mode call-flow is shown Fig 1. The incoming INVITE (call waiting INVITE) request from UA “C” is received at UA “A” when it is in call with UA “B”. When the user “A” triggers to accept the CW call, UA “B” is put on hold and the call waiting INVITE is accepted thereby establishing a call with UA “C”. This service is fully handled by the UA. 3.1.2 INVITE-based Call flow in Thin Client mode The second approach illustrates the mechanism in which the service Parthasarathi Expires May 1, 2008 [Page 3] Internet-Draft Field Challenges of SIP UA November 2007 +---+ +---------+ +---+ +---+ | A | | B2BUA | | B | | C | +---+ +---------+ +---+ +---+ | Call Established| | | |<-----------------|----------------->| | | INVITE (C) | INVITE (C) | | |<-----------------|<-----------------|----------------| | 180 (C) | 180 (C) | | |----------------->|------------------|--------------->| User | Re-INVITE(Hold B)| Re-INVITE(Hold B)| | ---->|----------------->|----------------->| | Trigger| 200 (B) | 200 (B) | | |<-----------------|<-----------------| | | ACK (B) | ACK (B) | | |----------------->|----------------->| | |200 (SDP A) | 200 (SDP A) | | |----------------->|------------------|--------------->| | ACK (C) | ACK (C) | | |<-----------------|<-----------------|----------------| | | | | Fig 1: Callflow for CW Thick Client is handled in SIP server and the user triggers are passed to the SIP server. The call-flow for this approach is shown in Fig 2 wherein the flow is same till UA “B” is put on hold. In receipt of the hold acknowledgement from UA “B”, the user trigger is passed to of SIP server using the new INVITE request with user trigger information. This new dialog is referred as User Trigger(UT) Dialog. The SIP server terminates the UA “A” sides dialog in the call between UA “A” and UA “B”, remembers the UA “B” sides dialog for the same call and cancel the UA “A” side CW INVITE dialog. Also, the SIP server sends 200 response towards UA “C” and 200 response with SDP C for UT dialog towards UA “A”. At the end of this service activity, UT dialog is the only dialog exists in the UA “A” and the media packets are exchanged between UA “A” and UA “C”. In this approach, the SIP server will decide which service has to be invoked depend upon the current context. 3.1.3 INFO-based Call flow in Thin Client mode Though there are proposal and discussion to discourage the usage of INFO method [5], there are couple of vendors support INFO method with proprietary messages to perform all the call services. In this approach, the service information is passed in the proprietary message within the dialog and there is only one dialog exist between SIP server and UA for a call as shown in Fig 3. The SIP server acts as a B2BUA. In the call waiting implementation using INFO, the INFO message is received with Call Waiting information and when the user trigger for CW, 200 OK response send for INFO message. The SIP server sends Re-INVITE message towards UA “A” to change the Parthasarathi Expires May 1, 2008 [Page 4] Internet-Draft Field Challenges of SIP UA November 2007 +---+ +---------+ +---+ +---+ | A | | B2BUA | | B | | C | +---+ +---------+ +---+ +---+ | Call Established| | | |<-----------------|----------------->| | | INVITE (C) | INVITE (C) | | |<-----------------|<-----------------|----------------| | 180 (C) | 180 (C) | | |----------------->|------------------|--------------->| User | Re-INVITE(Hold B)| Re-INVITE(Hold B)| | ---->|----------------->|----------------->| | Trigger| 200 (B) | 200 (B) | | |<-----------------|<-----------------| | | ACK (B) | ACK (B) | | |----------------->|----------------->| | |INVITE (UT Dialog)| | | |----------------->| | | | | 200 (SDP A) | | | |------------------|--------------->| | | ACK | | | |<-----------------|----------------| | 200(SDP C UT dia)| | | |<-----------------| | | | BYE (B) | | | |<-----------------| | | | CANCEL (C) | | | |<-----------------| | | | ACK (UT dia) | | | |----------------->| | | | 200 (BYE B) | | | |----------------->| | | | 200 (CANCEL C) | | | |----------------->| | | Fig 2: Callflow of CW Thin Client with special INVITE request media details from UA “B” to UA “C” and also, the SIP server sends hold Re-INVITE request towards UA “B”. In the illustrated three callflow for CW service, the service performed is same and also uses SIP protocol only. Some call services will have much more variation to achieve the service. 3.2 Emergency call (dialog) implementation In the Thick Client mode, UA identifies the emergency call by the special UI interface or by the configuration. One of the approaches to indicate about the emergency call to the SIP server is by adding the resource-priority [6] & proprietary headers. Within the emergency dialog, all the call services are disabled at UA end. Parthasarathi Expires May 1, 2008 [Page 5] Internet-Draft Field Challenges of SIP UA November 2007 +---+ +---------+ +---+ +---+ | A | | B2BUA | | B | | C | +---+ +---------+ +---+ +---+ | Call Established| | | |<-----------------|----------------->| | | INFO | INVITE (C) | | |<-----------------|<-----------------|----------------| | | 180 (C) | | | |------------------|--------------->| User | 200 (INFO) | Re-INVITE(Hold B)| | ---->|----------------->|----------------->| | Trigger| | 200 (B) | | | |<-----------------| | | | ACK (B) | | | Re-INVITE(SDP C) |----------------->| | |<-----------------| | | | 200 (SDP A) |200 (SDP A) | | |----------------->|------------------|--------------->| | ACK | ACK | | |<-----------------|<-----------------|----------------| | | | | Fig 3: Callflow of CW Thin Client using INFO In the Thin Client mode, the SIP server classify call as emergency based on SIP AOR and the UA is not aware that it is Emergency dialog. The forwarding the call to Public Safety Answer Point (PSAP) and disabling the services are done by SIP server. 3.3 Fax Call implementation UA can also acts as Fax machine wherein it may follow 2 modes of operation: T.38 fax relay as defined by the ITU-T T.38 recommendation or fax pass-through [7]. The fax call is always established after the initial call is established. The call services have to be disabled while the T.38 fax is going on. In the Fax pass- through mechanism, it is not possible to disable the call services as UA is not aware of the fax transmission. 3.4 Call Feature Interaction The Call Feature (service) interaction explains whether a service is allowed when another service is active on the same UA and also, whether two services can interact with each other. As there is no standard for the SIP services implementation, it is left to the UA implementors to decide whether to implement the interaction or not. In the Thin Client mode, there is no service interaction issues or very less interaction at UA side as there is only one dialog at UA at any of stable state of the call. The Call Services interaction is the most intricate decision to make in case the service logic implemented in UA as Re-INVITE is used in all of the services for modifying the media, it is used to refresh the session Parthasarathi Expires May 1, 2008 [Page 6] Internet-Draft Field Challenges of SIP UA November 2007 and also for fax call. The Call services interaction at UA has also to take care about the session timer interaction and Emergency call handling as part of the interaction. 4. Configuration mechanism usage The telecom service providers use different configuration mechanisms to configure the SIP stack and call control. The commonly used configuration mechanisms in UA are sipping-framework based [8], SIP MIB based [9], File download mechanism, DHCP-based [10], pre- configured, DSL forum’s TR-069 & TR-104. In the deployment of SIP entities, UA configuration mechanism is a crucial as the service provider should have the provision to manage the UA without physically reaching the UA. Though sipping-framework is getting standardized, only few implementations are available in the deployable stage. DHCP options are used to get the SIP servers details and it is used in the 3GPP standard. The file-download is a proprietary way to get the configuration details to the UA. The pre- configured mechanism is used in 3GPP standard wherein the Private identities, Public identity of the user are provided in SIM. In most of the implementations, some of the configuration mechanisms are coupled together to achieve the result. 5. Media Handling SIP uses the offer/answer model [11] to establish media sessions. This portion of SIP leads to lot of interop issue as explained in “SIP Usage of the Offer/Answer Model draft” [12]. Apart from this, few non-standardized methods are followed in lot of SIP servers. One of the common deviations is that of handling early media for initial INVITE request wherein one answer (Media server SDP) is provided in provisional response (18x) and another answer (Remote Party SDP) in the final response (200). Session-disposition[13] specifies the way to handle this but most of the SIP server does not support this mechanism. UA may need to support handling of different answers for the offer generated in the INVITE coming in provisional and final responses till the network entity adapts session-disposition mechanism 6. Current status of standardization There are working groups in IETF working for the better interoperability between multiple vendor implementations for SIP services. Basic Level of Interoperability for SIP Services (BLISS) WG [14] is a working group to facilitate effective feature interoperability for features sharing common functional primitives utilizing SIP in heterogeneous network environments. There is a another WG namely Emergency Context Resolution with Internet Technologies (ECRIT)[15] group which is created to solve emergency calls related issues. Parthasarathi Expires May 1, 2008 [Page 7] Internet-Draft Field Challenges of SIP UA November 2007 SIP service example callflow [16] draft shows the flow for basic services. These WGs & drafts are in the initial stage of the standardization process. 7. Security Consideration N/A 8. Conclusion Even though standardization of SIP call services is still under progress, field trials and deployments of SIP network are already underway. As a result UAs must be prepared to be compatible with different flavors of the early-bird SIP server implementations. To be able to achieve this, we recommend the following : 1. Support for both Thick & Thin Client modes of operation. 2. Support for service specific variations within each mode of operation to realize different services. 3. Support for multiple configuration mechanism UA implementors should have a concrete plan for the call service Interactions and configuration management. This approach may be continued by UA implementors till call services are standardized and/or the common practices are accepted and implemented by the SIP network vendors. 9. IANA Considerations This document makes no request of IANA. 10. Reference [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", RFC 3725, Apr 2004. [3] ETSI TISPAN, “IMS based PSTN/ISDN Emulation Stage 3 Specification”, ETSI TS 183 043, May 2006. [4] Mahy, R., Campbell, B., Sparks, J., Rosenberg, J., Petrie, D. and A. Johnston, “A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP),” draft- ietf-sipping-cc-framework-07, March 2007. [5] E. Burger, “Session Initiation Protocol (SIP) INFO Method Use”, Nov 2007 Parthasarathi Expires May 1, 2008 [Page 8] Internet-Draft Field Challenges of SIP UA November 2007 [6] Schulzrinne, H. and J. Polk, “Communications Resource Priority for the Session Initiation Protocol (SIP),” RFC 4412, February 2006. [7] Jean-Francois Mule, “SIP Support for Real-time Fax: Call Flow Examples And Best Current Practices”, Aug 2003 [8] Petrie., D, S. Channabasappa., Ed, “A Framework for Session Initiation Protocol User Agent Profile Delivery”, draft-ietf- sipping-config-framework-13, Oct 2007. [9] K. Lingle., J-F. Mule., J. Maeng., D. Walker., “Management Information Base for the Session Initiation Protocol (SIP)”, RFC 4780, Apr 2007 [10] H.Schulzrinne, “Dynamic Host Configuration Protocol (DHCP-for- IPv4) Option for Session Initiation Protocol (SIP) Servers”, RFC 3361, Aug 2002 [11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with SDP", RFC 3264, June 2002. [12] T. Sawada., P. Kyzivat., “SIP (Session Initiation Protocol) Usage of the Offer/Answer Model”, draft-ietf-sipping-sip- offeranswer-04.txt, Oct 2007. [13] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, Dec 2004. [14] J. Rosenberg, “Basic Level of Interoperability for Session Initiation Protocol (SIP)Services (BLISS) Problem Statement”, draft-ietf-bliss-problem-statement-01, Nov 2007 [15] H. Schulzrinne., R. Marshall, Ed., “Requirements for Emergency Context Resolution with Internet Technologies”, draft-ietf- ecrit-requirements-13, Mar 2007. [16] A. Johnston., Ed, R. Sparks, C. Cunningham, S. Donovan, K. Summers, “Session Initiation Protocol Service Examples”, draft- ietf-sipping-service-examples-13, July 2007. Author's Address R. Parthasarathi Aricent 4th Floor, Gamma Block, Sigma soft-tech park, White Field Road, Bangalore- 560017, India Phone: +91-80-4106-9088 Email: r.parthasarathi@aricent.com Parthasarathi Expires May 1, 2008 [Page 9] Internet-Draft Field Challenges of SIP UA November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Parthasarathi Expires May 1, 2008 [Page 10]