Prepared by Hui-Lan Lu based on notes taken by Alec Brusilovsky and Kumar Vemuri, to whom thanks!. The SIN BOF took place from 14:15 to 15:15, August 1, 2000. Hui-Lan Lu chaired the BOF alone; Lev Slutsman, the other designated co-chair, unfortunately fell ill, but his effort in preparing the BOF has been invaluable. About 200 people attended the BOF. The agenda for the meeting was as follows: 1. Introduction - Chairs, 5 mins 2. Problem statement - I. Faynberg, 5 mins (draft-schulzrinne-sin-01.txt) 3. SIP and IN - H. Schulzrinne, 10 mins (draft-schulzrinne-sin-01.txt) 4. Implementation experience with SIP-enabled IN services - V. Gurbani, 5 mins (draft-gurbani-iptel-sip-in-imp-00.txt, draft-gurbani-iptel-sip-to-in-02.txt, draft-lslutsman-sip-iin-framework-00.txt) 5. Relevant ITU-T Activities - D. Lebovits, 5 mins (draft-lebovits-sip-in-00.txt) 6. Open discussion - all, 25 mins 7. What's next - all, 5 mins INTRODUCTION The chair noted that the purpose of the BOF is to determine whether a work item on the interworking of SIP and Intelligent Network (IN) is needed in the IETF, and, if so, whether the relevant work is to be carried in an existing working group or a new working group is to be created. PROBLEM STATEMENT Igor Faynberg presented the problem statement. He emphasized that the SIP/IN Interworking is considered here so as to support existing IN-based applications in a SIP-based IP telephony environment for IP-Host-to-Phone calls. There are many telephony applications based on IN: 800 (freephone), PSTN VPN, credit card calling, to name a few. One approach is to reuse existing IN service logic in the PSTN. Specifically, this requires · Interpreting IN Call Models for the SIP environment · Mapping IN messages into (sequences of) SIP messages and vice versa · Mapping IN parameters into SIP parameters and vice versa · Defining SIP extensions, if necessary SIP and IN Henning Schulzrinne's presentation focused on what needs NOT be done in addressing the SIP/IN (or more precisely SIP/INAP/TCAP) issues. He stressed that there is no need for a new protocol and exporting SIP states to a new box. A preferred approach would be to have a SIP user agent invoking INAP/TCAP services by using a mechanism similar to the SIP Common Gateway Interface (CGI). In contrast to sip-cgi, which is transaction-oriented, the mechanism may need to be call-oriented. In such a case, it should be defined as generic as possible, not just limited to the support of INAP/TCAP. Henning also suggested to avoid working in a lengthy cycle of requirements, pre-SIN implementations, architecture, protocol, MIB and so on. Finally, he noted that it was not clear why the SIN work cannot be done in the SPIRITS WG. (Alec Brusilovskk, a SPIRITS WG co-chair, responded that this item does not fit the SPIRITS charter.) The presentation generated the following discussion: · Exporting SIP states may be desirable in some cases so as to keep certain SIP elements simple. · There doesn't seem to be sufficient work for a new working group and what needs to be done could be done in an existing one such as SPIRITS. It was noted that SIN issues are outside the SPIRITS charter. · For SIP to interwork with IN, a database protocol is sufficient. There is no need to extend SIP. · SIP extensions should be minimized in order to keep it simple and independent of specific applications and to avoid interoperation issues. · In the PSTN, with IN, a call for ordering pizza is routed to the pizza store geographically closest to the caller. When a call is originated in an IP network, instead of the pizza store closest to the caller, the call is routed to the one closest to the gateway to which the caller happens to be connected. SIN should be able to solve this problem. · SIN seems worthwhile work but more input from carriers would be helpful. · There is no need to standardize the SIP-INAP mapping. A BCP or informational RFC may be sufficient. (Unfortunately, the discussion had to be curtailed because of lack of time.) IMPLEMENTATION EXPERIENCE WITH SIP-ENABLED IN SERVICES Vijay Gurbani highlighted issues based on his implementation experience with SIP-enabled IN services, such as originating call screening and call forwarding. (He co-prototyped a SIP call controller that maps IN call states to those of the SIP protocol state machine.) In particular, two issues were specific to SIP: 1) there are no acknowledgements for provisional responses and 2) provisional responses are optional. Vijay noted that there are at least three ways to deal with the issues. He also mentioned issues for further investigation, for example those concerning non-digit URIs, mid-call triggers and DTMF tones. There was a comment from the floor that SIP is intended to support services beyond IN and there is no need to burden SIP to interwork with IN. In response, it was re-iterated that there is a practical need for SIP/IN interworking and solving the problem should not interfere with any other SIP development. RELEVANT ITU-T ACTIVITIES Doris Lebovits described the work on interworking between IP and IN-supported networks, which is underway in ITU-T Study Group 11. Two items, related to PINT and SPIRITS, are progressing in coordination with the IETF. Draft Recommendations Q.1241, Q.1244, and Q.1248 contain the current view. In particular, an initial functional model for SIP/IN interworking has been proposed. The model includes a soft Service Switching Function (SSF) and a Call Manager Function (CMF). So far, ITU-T SG 11 doesn't plan to standardize the interface between the soft SSF and CMF. In general, it relies on the IETF to work SIP issues. Doris suggested the IETF to adopt the soft SSF-CMF interface as a work item. Finally, in response to a question on the upcoming ITU-T restructuring for the new study period, Doris said that the IN work in ITU-T is expected to continue in the next study period. WHAT'S NEXT Very little meeting time remained at this point. The chair admitted the last comment before drawing the BOF to a conclusion: there is a strong interest for carriers (e.g., AT&T) in SIP/IN interworking so as to leverage existing IN-based applications in an IP telephony environment. Scott Bradner suggested three options going forward: doing nothing, creating a new working group, and forming an independent design team. (No additional options were proposed by others.) Based on a show of hands, the independent design team approach emerged as the preferred way moving forward. Scott invited those interested in joining the design team to get in touch with him. The meeting adjourned. Meanwhile, this reporter has set up a mailing list for the SIN discussion (ietf-sin@lists.bell-labs.com). To subscribe, please follow the instructions at http://lists.bell-labs.com/mailman/listinfo/ietf-sin.