Current Meeting Report
Slides


2.7.19 Session Initiation Protocol (sip)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 05-Nov-01
Chair(s):
Joerg Ott <jo@ipdialog.com>
Brian Rosen <brian.rosen@marconi.com>
Dean Willis <dean.willis@softarmor.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>
Transport Area Advisor:
Allison Mankin <mankin@isi.edu>
Mailing Lists:
General Discussion:sip@ietf.org
To Subscribe: sip-request@ietf.org
In Body: subscribe
Archive: www.ietf.org/mail-archive/working-groups/sip/current/maillist.html
Description of Working Group:
Note: There is another SIP email list for general information and implementations:

Discussion of existing sip: sip-implementors@cs.columbia.edu To Subscribe: sip-implementors-request@cs.columbia.edu In Body: subscribe Archive: http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors =======================================================================

The Session Initiation Protocol (SIP) working group is chartered to continue the development of SIP, currently specified as proposed standard RFC 2543. SIP is a text-based protocol, similar to HTTP and SMTP, for initiating interactive communication sessions between users. Such sessions include voice, video, chat, interactive games, and virtual reality. The main work of the group involves bringing SIP from proposed to draft standard, in addition to specifying and developing proposed extensions that arise out of strong requirements. The SIP working group will concentrate on the specification of SIP and its extensions, and will not explore the use of SIP for specific environments or applications. It will, however respond to general-purpose requirements for changes to SIP provided by other working groups, including the SIPPING working group, when those requirements are within the scope and charter of SIP.

Throughout its work, the group will strive to maintain the basic model and architecture defined by SIP. In particular:

1. Services and features are provided end-to-end whenever possible.

2. Extensions and new features must be generally applicable, and not applicable only to a specific set of session types.

3. Simplicity is key.

4. Reuse of existing IP protocols and architectures, and integrating with other IP applications, is crucial.

SIP was first developed within the Multiparty Multimedia Session Control (MMUSIC) working group, and the SIP working group will continue to maintain active communications with MMUSIC. This is particularly important since the main MIME type carried in SIP messages, the Session Description Protocol (SDP), specified in RFC 2327, is developed by MMUSIC and because MMUSIC is developing a successor to SDP which SIP will also use.

The group will work very closely with the (proposed) SIPPING WG, which is expected to analyze the requirements for application of SIP to several different tasks, and with the SIMPLE WG, which is using SIP for messaging and presence.

The group will also maintain open dialogues with the IP telephony (IPTEL) WG, whose Call Processing Language (CPL) relates to many features of SIP; will continue to consider the requirements and specifications previously established by the PSTN and Internet Internetworking (PINT) working group;: and will consider input from the Distributed Call Signaling (DCS) Group of the PacketCable Consortium for distributed telephony services, and from 3GPP, 3GPP2, and MWIF for third-generation wireless network requirements.

The specific deliverables of the group are:

1. bis: A draft standard version of SIP.

2. callcontrol: Completion of the SIP call control specifications, which enables multiparty services, such as transfer and bridged sessions.

3. callerpref: Completion of the SIP caller preferences extensions, which enables intelligent call routing services.

4. mib: Define a MIB for SIP nodes.

5. precon: Completion of the SIP extensions needed to assure satisfaction of external preconditions such as QoS establishment.

6. state: Completion of the SIP extensions needed to manage state within signaling, aka SIP "cookies".

7. priv: Completion of SIP extensions for security and privacy.

8. security: Assuring generally adequate security and privacy mechanisms within SIP.

9. provrel: Completion of the SIP extensions needed for reliability of provisional messages.

10. servfeat: Completion of the SIP extensions needed for negotiation ofserver features.

11. sesstimer: Completion of the SIP Session Timer extension.

12. events: Completion of the SIP Events extensions (Subscribe/Notify).

13. security: Requirements for Privacy and Security.

14. natfriend: Extensions for making SIP a NAT-friendly protocol.

Other deliverables may be agreed upon as extensions are proposed. New deliverables must be approved by the Transport Area Directors before inclusion on the agenda.

NOTE: milestones within the same month are shown in order of planned completion.

Goals and Milestones:
Done   Server Features Negotiation submitted to IESG
Apr 01   Complete IESG requested fixes to provrel and servfeat
May 01   Session Timer spec to IESG
Jun 01   Transfer spec to IESG
Jun 01   NAT-awareness extension on REGISTER submitted to IESG.
Jul 01   Caller preferences specification submitted to IESG
Jul 01   SIP Privacy and Security Requirements to IESG
Jul 01   SIP Privacy specification (from DCS) to IESG
Sep 01   MIB spec to IESG
Sep 01   Preconditions extensions (manyfolks) spec to IESG
Sep 01   SIP Events specification to IESG
Dec 01   Revised proposed standard version of SIP (2543bis) submitted to IESG
Dec 01   Review WG status (consider closing) and/or submit a future milestones plan to IESG
Jan 02   SIP over SCTP specification and applicability statement
Internet-Drafts:
Request For Comments:
RFCStatusTitle
RFC2976PSThe SIP INFO Method

Current Meeting Report

Minutes, SIP WG, IETF 52

------------------------------------------------------------------------

Reported by Dean Willis 14Jan02

Agenda accepted as proposed.

General
Issues with bis alugnment: Consensus to go through pending drafts and realign with bis. All non-imminent drafts should reference bis.

Changes in bis-05 and Open Issues (Rosenberg):

Issue #24 reuse of disabled streams, recorded consensus to allow, as proposed by JDR

Issue #81 Caching of SIP Proxy Creds, recorded consensus to proceed as proposed by JDR

.

Issue #109, Allow cancel of non-INVITE, Proposal to ignore (JDR). Recorded consensus to accept as proposed.

Issue #113, Overlapping forward transactions. No resolution reported for INVITEs. Consensus on JDR proposal to allow overlapping non-INVITEs.

Issue #126, No-ACK recoved on BYE, consensus to proceed as propased by JDR

Issue #128, SRV processing, consensus to proceed as propsed by JDR

Issue #131, Challenging Gateways, no resolution reported

Issue #144, Branch ID= Transaction ID. Proposal modified to incoude identity of sender. Consensus to accept.

Issue #145, Stateless SRV part 1. Some controversy involving coordination with SRV people. No conclusion reported.

Issue #150, Don't Send. No resolution reported.

Issue #164, Proxy Auth Info. No resolution reported

SIP Routing Operations (Sparks):
Extended discssion, with general consensus for Sparks to continue with document development

End of Session 1

Security: (Thomas, others)
Goal is to put clear rationale and basic framework into bis. Consensus that end-to-end is alow priority item for bis. Suggestions to deprecate basic http authentication in bis accepted with strong consensus. Cuation against adding too many features late in games, better to complete work on table first. Consensus that digest auth as currently speced is inadequate and that enhanced digest and EAP mechanisms may be required.

Events (Roach):
Consensus to make events dependent on bis. Forking of SUBSCRIBE discussed, consus to allow with default being to accept first response. Consesnus to adopt immediate NOTIFY for all SUBSCRIBES. Discussion of use as implicit with REFER passed to list. Consensus to accept subscription-state header.
Consensus that event parameters will be defined in event packages.
Discussion of problems with multiple INVITE/SUBSCRIBE per dialog noted.

Caller Preferences (Rosenberg):
Accept-contact decisons relgated to list

SCTP (Camarillo):
Open question over use of stream ID as lightweight transaction ID deferred to list. Consensus reported that IDs are explicityly scoped by the connection.

Privacy (Andreasen):
Controversy over insertion of RPID by UA and proxy-removal of RPIDs inserted by untrusted proxy or UA. General consensus seems to indicate need for multiple RIPSs with crypto/signing mechanism indicating responsible party vouching for each RPID.

Manyfolks (Marshall):
Issues with early media. SDP in PRACK matching 200 reposnse conflicts with early-media offer-answer proposal. Further work required.

Early Media (Rosenberg):
Consensus to proceed seperately from bis, and to work on as WG effort. Open issue is whetehr to require backward compatibility. Proposal to establish design team.

Slides

SIP WG Early Media Issues
The new bis
'manyfolks' and 'call-auth' drafts
SIP Extension Changes
SIP Security
SIP Events: Open Issues
Open Issues in bis
EAP Authentication for SIP
SCTP as a Transport for SIP
SIP Security
SIP Routing Operations, Policy, and Request-URI Discussion
SIP Extensions for Caller Identity and Privacy
The new bis
'manyfolks' and 'call-auth' drafts
SIP Extension Changes