The SIP Working Group met in conjunction with the 46th meeting of the IETF in Washington DC on November 8 and 10, 1999. There were two standard sessions, both of which were well attended (app. 200 persons), with very full agendas. In addition to ongoing working group efforts, seventeen Internet drafts were presented and discussed.
Dean Willis discussed the agenda, with no objections being raised. Jonathan discussed current mailing list topics including call termination procedures (cancel vs. bye) and feature availability headers (Supported/Unsupported/Desired/Required). The meeting consensus appeared to be that the apparent consensus reached on the mailing list with respect to bye and cancel overlaps is adequate for most cases of overlapping cancel/OK. We expect this to be clarified in the next SIP specification document. There seemed to be good consensus on the semantic range of feature availability using the four headers (Supported/Unsupported to describe availability, Desired/Required to describe rigidity of need). Further discussion of this topic is required on-list. Jonathan also introduced the concept of content-disposition for SIP message bodies. It may be that this mechanism can be adopted from HTTP to address the application semantics of SIP. We probably need a volunteer to analyze the HTTP usage and suggest applicability for SIP.
This is a WG charter item. The draft is fairly mature, and there is a strong consensus to adopt the INFO method as a SIP component. There wseemed to be a good consensus to publish as an extension to SIP rather than including INFO in the base spec at this time. The author agreed to finalize the draft with this intent (address nits) and resubmit it with the intent of moving rapidly to a WG last call.
Yet another MIME encoding for ISUP messages. No clear consensus has been reached. We propose that the authors of the various approaches get together and come up with a commom approach. Tom Taylor noted that some sort of version information in the encoding would be very helpful.
The draft discusses a SIP-PSTN interworking methodology. Discussion centered on limitations of the approach (for example, forking is not addressed and may be precluded). The opinion appeared to be that the work, while informational, may not yet constitute as "best current practice" as it does not seem to have been actually implemented anywhere. Jonathan Rosenberg called for input as to whether the SIP WG is the appropriate place to carry this work forward, with other alternatives including a specialized working group or an implementor's forum. Lawrence Conroy noted that there are really two pieces of work here -- a set of extensions to SIP, and a profile of SIP usage for telephony interworking, and that it should be possible to decompose the work along these lines. In the interest of preserving the agenda, further discussion was deferred to the WG list.
This draft deals with SG-MGC-MG architectures and the interworking between an MGC and a SIP UA, specifically with message flows for calls in both directions and parameter mappings. Gonzalo proposes that advanced ISUP feature mapping can be vendor specific -- and that we need standardization only on basic aspects. Accordingly, the draft is based on Q.767 rather than Q.763. Discussion centered on issue of coordination of work on mapping and references used. There may also be an need to clarify legal requirements on the GSTN side. There were no substantive disagreements voiced with the approach taken in the draft.
QSIG is essentially a suite of eer-to-peer protocols between PBXs used for feature signalling. The draft proposed a MIME encoding for QSIG and transport of the MIME encodings as SIP message bodies, with call flows and examples various examples. There was some discussion of the similarity between the QSIG and ISUP aproaches, with Henry Sinnreich asking if the various related drafts could be unified. Jonathan Rosenberg commented that the interworking difficulties not so obvious with ISUP, because of QSIG vs. SIP feature interactions, and that there are interesting situations that might occur when working between telephony and non-telephony endpoints, with QSIG transport less likely to be general-purpose because of its more direct conflict with SIP role. David Oran noted that QSIG in H.323 led to trouble, with customers requiring H.323 awareness of some features. Christian Huitema stated that awareness of the QSIG features in SIP collides directly with the purpose and transparency requirement of SIP. The basic consensus is that the approach for MIME types for ISUP, QSIG, etc. should be unified, and that QSIG interworking is a separate issue. The WG did not state an opinion on the need to carry out this interowking effort, with further discussion deferred to the list.
These two documents contain several hundred pages of detailed call flows showing a variety of SIP and SIP-PSTN sessions. The consensus of the group was that this is a critical contribution, and that the WG should adopt a call flow document as an ongoing effort. During the remainder of the meeting, several requests were made to add specific scenarios or feature invocations to the anthology. Jonathan Rosenberg proposed that these documents be combined with the test cases from the bake-offs into an informational RFC for issuance in January. This proposal received a loud hum of consensus.
This draft discusses approaches for exercising IN applications from SIP devices. It was noted by Jonathan Rosenberg to have some commonalities with a Lucent draft presented last year and that it might be possible to combine the efforts. One speaker noted a strong overlap with SPIRITS work, but it was noted that there is a need to fill in SIP as such as registration outside of SPIRITS. Jonathan noted that there had been discussion in the IPTEL meeting about a perceived lack of IN expertise in the IETF, making the IETF an inappropriate forum for this sort of work. Jonathan whether the SIP group feels moe confident in this effort. After some noncommital rsponses, Dean Willis suggested that this conversation could move to the list, which seemed to stimulate the conversation. Paul proposed that this task is equivalent to the ISUP mapping work, only this for INAP, and is therefore as appropriate in IETF as is ISUP mapping. Lawrence Conroy suggested that ITU SG-11 might be addressing the topic, and suggested submitting the draft there as well. Lawrence futher proposed that mapping to INAP should be done in ITU/ETSI, but that they moght not understand SIP well enough to do it right. Chip raised the question -- with respect to INAP mapping, what does the author asking this WG? The respnse is that the SIP WG would address the SIP enhancements needed to support INAP. Chip inquired as to what forum would work the protocol between the softSSF and SIP Proxy, and was told that it is not currently being worked. One speaker noted that third-party call control is being worked in IPTEL using CPL, raising the question as to whether multiple approaches are needed. Jonathan Rosenberg responded that the IN approach has value, but fails in different architectural contexts than the CPL approach, and that each should be used approporiately.
Jonathan presented the current state of work on caller preferences. The open issues include:
The session timer was presented in Oslo, with consensus to proceed. The current draft is quite mature. Discussion centered on whether to include this in the base spec or consider it an extension. By using the requires/supported approach, it could be made a separable extension. The consensus was to republish with this detail and nits corrected and proceed to WG last call as soon as possible.
An earlier version of this draft was presented in Oslo, with consensus to proceed. This draft realy includes two different elements which are needed for certain telephony interworking cases. One element is the addition of MIME bodies to provisional (1xx class) messages. This appears to have broad utility to other applications as well, but has a dependency on reliable provisional messages. The other element is the addition of a new method to indicate call progress. It was noted that 183 has been allocated, so a new number would need to be selected for the proposed feature. No consensus was reached as to whether each element should be included in base or prublished as an extension. One suggestion made was to divide the document into two discrete drafts and develop the elements separately. No conclusion was reached as to how to proceeed, and discussion was deferred to the list.
This document covers an interesting interdisciplinary approach to dealing with QoS, reporting, and settlement issues for SIP sessions crossing two or more carriers.
David Oran noted that the media path is not the same as the signaling path, which raises the question of how a SIP proxy knows which router to go to. This apparently is unresolved in DCS as well. Jonathan noted that mix of protocols suggests trotting through a series of WGs, but that this is not truly a SIP WG item because no SIP changes are proposed. KK suggested that there is a large community of interest here, which led Jonathan to suggest a joint WG meeting as an option. Discussion on how to contniue this work was deferred to the list. One speaker suggested adding these examples to the call flows draft. Steve Donovan noted the open SIP question of when to trigger QOS -- a SIP extension may be neeeded for this.
This draft suggests a novel use of modified SIP with a route header to probe for and establish MPLS paths. As this is interdisciplinary with MPLS, no consensus was reached to move forward with this as a SIP WG effort.
This draft discussed usage of the INFO method for transporting a variety of things including mid-call signaling, DTMF, and ohers, and proposed means for enhancing reliability and in-order delivery. Discussion rapidly devolved to a moderately heated exchange on DTMF-in-RTP vs DTMF-in-INFO, with no conclusion reached.
This draft discussed approaches for allowing multiple proxies to challenge a SIP method. It appears that this can be accomplished via a slight clarification of the response syntax and some discussion of proxy behavior without impacting the current SIP specification. These can be included in the next SIP draft. However, implications of hop-by-hop vs. end-to-en security remain to be considered.
This draft proposes extensions to SIP needed to support a host mobility management protocol potentially usful in 3G wireless and other environments. Further discussion is needed as to whether this work should be addressed in the SIP WG.
The SIP Servlet approach is promising for development of SIP srvices using Java. Discussion centered on finding an appropiate forum for further work, as there appeared to be a general consensus (reinforced by an area director) that the IETF is not an appropriate forum to refine software APIs. The proposal was made an accepted to establish a new mailing list for further discussion.
Modified December 13, 2001 13:22