2.6.23 SIP/IN Interworking (sin) bof

Current Meeting Report

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


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.


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

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:

(Unfortunately, the discussion had to be curtailed because of lack of time.)


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.


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.


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.


None received.