2.8.17 Session Initiation Protocol (sip)

NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01

Chair(s):

Joerg Ott <jo@tzi.uni-bremen.de>
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: majordomo@cs.columbia.edu In Body: subscribe sip-implementors 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

Internet-Drafts:
Request For Comments:

RFC

Status

Title

RFC2976

PS

The SIP INFO Method

Current Meeting Report

Minutes prepared by Dean Willis, based mostly on notes by Tom Taylor, without whom we would cease to report.

SIP Working Group met at IETF 51 for two long sessions, a total of 5 hours of meeting time. The revised agenda was completed, with the exception that several of the Rosenberg drafts listed in conjunction with alternative views were not discussed in detail. Instead, Jonathan addressed only the significant differences between his approach and the alternative presented.

The WG also scheduled three adhoc after-hours sessions: 1) Security, 2) Privacy and Outbound Services from Non-Adjacent Proxies, and 3) Firewall Traversal. A fourth adhoc on call Control was proposed by Rohan Mahy, but the proposal was withdrawn before the meeting.

Slides are posted at: http://www.softarmor.com/sipwg/meets/ietf51/slides/

Work Plan status
-----------------

Approximately half of the extant SIP drafts have been tentatively moved to SIPPING. The managed Last Call process is now starting to flow, and it looks like we'll be able to work through the backlog. We have a near-term requirement to reset several milestones, which will be executed on-list.

REFER Method
-----------------

This is part of the "call control" work, which addresses call transfers and thrid-part all control. The existing draft draft-ietf-sip-refer-00.txt was recently split off from the "transfer" draft. Open issues: 1) The "referred by" information is similar to the Remote-Party-ID of the Privacy work. Can these two share a general mechanism? 2) The draft defines a crude integrity mechanism for referred-by, but this should use a general-purpose header integrity mechanism. Consensus to advance draft by deleting integrity mechanism and referring to SIP Security work. 3) The MIME-type of the REFER body remains unresolved, and a number of security questions were raised with various proposals.

Replaces Header
-----------------

This header indicates which call leg the call leg mentioned in a REFER is to replace. This work is fairly mature, and no issues were raised.

SIP Events
-----------

Issues with authentication, 1) DoS attacks, and amplification, 2) Forking, 3) Record-Route, 4) Expires, 5) event package names, and 6) Call-leg correlation, 7) partial-vs-full state transmission were raised.

1 ) DoS/Amplification: Each SUBSCRIBE produces one response and one notification, which could make a 2-to-1 amplifiier. Consensus to define general "anonymous" authentication mechanism in bis.

2) Forking: No technical problems preclude support for forking of SUBSCRIBE if forking of INVITES is supported.

3) Record-Route: current draft's wording seems ambiguos and has resulted in variant interpretations. Consensus to clarify in revised draft.

4) Expires: Current draft overloads Expires header in NOTIFY to indicate when subscription will expire. This is an overload of header. There is a proposal to use a new header, Subscription-Expires, which may offeer semantic advnatge in subscription migration. Weak consensus for propsal.

5) Event Package Names: Debate is to whether to allow private event package names. Consenus seems to be to establish IANA registry on a first-served basis, no RFC or expert review.

6) Call-Leg Correlation: Question is how to correlate a NOTIFY -- is it with a "call" or a "call leg". This is mostly an issue on whether or not SUBSCRIPTIONS are initated within an extsing call leg. Current draft correlates with a call leg, but this may not solve all cases. Conensus to examine removing prohibition on mapping between notification and specific call as to whether this affects existing implementation semantics.

7) Partial vs. Full State transmission: Most interpretations of existing work seem to indicate that NOTIFYs will contain full states (SHOULD). State deltas may be important for many applications, but are problemactic in constructing full state because of possible missed messages. Consensus to consider body versioning techniques for state deltas.

Early Media
-------------

Many open issues, primarily with telephony interworking and QoS. Fundamental architecture issue is that early media is "forced" not "offered", and as a consequence we have no effective negotiation mechanism. This all seems to derive from need to map PSTN behavior exactly, and can be resolved if different user interface is allowed. There will be a lot more discussion on this topic.

NAT Friendliness
------------------

Current proposal includes several techniques for symmetric and semisymmetric NATS, including new SIP Translate header with semantics of "I don't know where I am, please use the address and port this came from". Consensus to split into at least two drafts, including Translate header (question: do we need a charter adjustment or new milestone declared here?) and seperate "NAT detection protocol for RTP" to be pursued outside SIP.

SIP SRC Indication
-------------------

Propsal to include source IP address in port in SDP describing sesion, and to expicitly differentiate RTCP port information. This would allow building SIP ALGs and firewalls much more easily (esp. "line" as opposed to "cone" binding devices), as much less information would have to be deduced. It also reduces the opportunity for RTP port spamming, as attacker would have to know source IP and port as well as SSRC. However, it poses complications for current simple-NAT proposals. There will be further discussion of this topic.

Extended HTTP-type-Authentication
-------------------------------------

Discussion included drafts from Rosenberg and Undery. The basic idea is finding ways to get more mileage, such as mesage integrity protection, out of digest autnetication techniques already specified in SIP. This has all sorts of open isses. Furtehr discussion moved to Security ad-hoc and to mailing list, with no clear consensus reached in the meeting.

Proxy-Supported Negotation
------------------------------

Idea is to determine whether at least one proxy in signaling path supports a specific feature. Existing negotiation technique can detect if ALL proxies in path support a feature. There has been ongoing list debate as to whether this is needed. Consensus reached in meeting that no requirement for this behavior, such as a specific application, has been identified and that work on the approach can be deferred until such time as a requirement has been identified.

Reliability of Provisional Messages
-----------------------------------

Alternative mechanism to 100Rel proposed. List discussions had been inconclusive. Consensus from meeting that proposed alternative offers no significant advantage in general case.

Session Timer
--------------

Two open isses: 1) New draft allows lower-bounding on sesssion-timer. Current proposal is to overload session-expires, with suggestion to establish new error code like 422-Minimum-Session-Expires. Consenus on proposal for new error code. 2) Absolute vs. relative timers. Consensus to deprecate absolute timers.

SIPbis Open Issues
--------------------

A bug tracking system is being used to track the large number of open issues in the bis draft. The meeting discussed several issues and attempted to get consensus for various propsed resolutions.

1) Issue 7: Allow CANCEL for non-INVITE methods. Current spec has muliple interpretations. Weak consensus to clarify indicating use of CANCEL only with INVITE.

2) Issue 10: Use of maddr: If client sends INVITE using maddr paremeter from route, should it strip the maddr off of the generated request URI? Consensus is yes, as documented in rfc2453-bis-03.

3) Issue 11: Record-routing for mid-call methods other than INVITE. This is intertwingled with Issue 138. Conensus is to allow mid-call record record-route on a case by case basis.

4) Issue 138: Forking of non-INVITE requests: Consensus to allow forking for non-INVITE methods on a case-by-case basis.

5) Issue 20: Mixing unicast & multicast in offer/answer . If offer SDP contains uni, can response contain multi? Proposal: general rule: answer should be something offeror can do. Hence don't send multicast in respons to unicats. If required, re-INVITE. Conensus to acdept proposal and add scenario to conferencing models draft.

6) Issue 23: dynamic PT reuse. SDP usage in 2543 says you can't reuse a dynamic PT number used previously for a different codec type. This limits number of codecs in a call to 127. It should be possible to reuse a PT once the transaction in which it was used has been completed. Consensus that this is not yet an issue for SIP and therefore there is no need to change.

7) Issue 146: Reuse disabled streams. SDP usage spec says once you have disabled a stream by setting port = 0that hat stream cannot be reused. This is important to maintain exlpicit ordering of codecs, but means the SDP size keeps increasing in on-off hold operations. Proposal: cannot remove disabled stream But if new one added, can take disabled stream's slot within SDP. No restriction on media type. This preserves ordering without increasing size of SDP. FID discussed as possible solution, but this doesn't seem to work completely. Further discussion is required.

8) Issue 58: Rejected mid-call SDP in 2xx: Question is what to "fall back to". Proposal to use general approach of using some signalling means to say that previous session description should be rtetained. Jonathan will consider in revised draft.

9) Issue 133: on-hold indication: Current SDP usage for on-hold is to set address/port number of all 0. This turns out to break RTCP, is IPv4 specific, and is generally ugly. Proposal to use a=inactive for non-sending codecs and a=sendonly for sending codecs, and preserve backward compatibility by accepting but not sending all-zeroes. This may have implications for QoS, and requires further analysis.

SIP Security Work Plan
------------------------

We are beginning to see common themes in security questons that suggest a possible path for generalization. Proposal to seperate discussion of "outside" vs. "inside" attacks and advance independently. This would include basic "outside" defenses like IPSec and TLS in rfc2543bis. The HTTP-derived authentiation mechanisms would be reqtined in bis, and all other security considerations seperated. Individual extensions would be constrained from proposing cryptosolutions pending general solutions.

Work Program: Develop Threats and Requirments draft. Finalize base requirments in bis and feeze. Define framework for popular auth mechnisms and focus on simple scheme provising UA-Proxy and Proxy-Proxy protections aliged with SRTP and SDP work.

Slides

Agenda
SIP & SIPPING Working Group Last Call Process & Status
REFER
SIP Events: Open Issues
SIP Security Status
SIP Authentication and Integrity
'draft-hoeneisen-sip-proxy-supported-00'
Proxy Supported Flow Examples
SPRACK vs. PRACK
Early Media Issues
'draft-boer-sip-src-00'
Open Issues in bis
SIP Slides - Rosenberg