2.8.18 Session Initiation Protocol (sip)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional SIP Page

Last Modified: 2003-08-25

Dean Willis <dean.willis@softarmor.com>
Rohan Mahy <rohan@cisco.com>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Allison Mankin <mankin@psg.com>
Technical Advisor(s):
Dan Romascanu <dromasca@avaya.com>
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

Discussion of existing sip: sip-implementors@cs.columbia.edu
To Subscribe: sip-implementors-request@cs.columbia.edu
In Body: subscribe Archive:

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

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. compression: SIP mechanisms for negotiating and guidelines for
    signaling compression as defined in ROHC.

15. content indirection: a Proposed Standard Mechanism to reference
    SIP content indirectly (by reference, for example using an external

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
Goals and Milestones:
Done  Server Features Negotiation submitted to IESG
Done  Complete IESG requested fixes to provrel and servfeat
Done  Revised proposed standard version of SIP (2543bis) submitted to IESG
Done  SIP Events specification to IESG
Done  The UPDATE Method submitted for Proposed Standard
Done  SIP extensions for media authorization (call-auth) submitted as Informational
Done  Preconditions extensions (manyfolks) spec to IESG
Done  SIP Privacy specification to IESG
Done  SIP Privacy and Security Requirements to IESG
Done  The MESSAGE Method submitted for Proposed Standard
Done  The Replaces Header submitted for Proposed Standard
Done  Refer spec to IESG
Done  SIP NAT extension submitted to IESG
Done  SIP over SCTP specification and applicability statement
Jan 03  Guidelines for Authors of SIP extensions submitted as Informational
Done  Mechanism for Content Indirection in SIP submitted to IESG for Proposed Standard
Done  The SIP Referred-By Header submitted to IESG for Proposed Standard
Feb 03  Session Timer spec, revised to IESG
Feb 03  Caller preferences specification submitted to IESG
Apr 03  The SIP Join Header submitted to IESG for Proposed Standard
Apr 03  Submit SIP Identity documents to IESG for Proposed Standard
Jul 03  MIB spec to IESG
Jul 03  Review WG status (consider closing) and/or submit a future milestones plan to IESG
  • - draft-ietf-sip-session-timer-11.txt
  • - draft-ietf-sip-callerprefs-09.txt
  • - draft-ietf-sip-mib-07.txt
  • - draft-ietf-sip-guidelines-06.txt
  • - draft-ietf-sip-sctp-03.txt
  • - draft-sparks-sip-mimetypes-03.txt
  • - draft-ietf-sip-replaces-04.txt
  • - draft-ietf-sip-referredby-03.txt
  • - draft-ietf-sip-compression-02.txt
  • - draft-ietf-sip-scvrtdisco-04.txt
  • - draft-ietf-sip-congestsafe-01.txt
  • - draft-ietf-sip-content-indirect-mech-03.txt
  • - draft-ietf-sip-symmetric-response-01.txt
  • - draft-ietf-sip-join-02.txt
  • - draft-ietf-sip-identity-01.txt
  • - draft-ietf-sip-authid-body-02.txt
  • - draft-ietf-sip-smime-aes-01.txt
  • - draft-ietf-sip-history-info-00.txt
  • - draft-ietf-sip-resource-priority-01.txt
  • - draft-ietf-sip-callee-caps-00.txt
  • - draft-ietf-sip-connect-reuse-00.txt
  • - draft-ietf-sip-uri-parameter-reg-00.txt
  • - draft-ietf-sip-parameter-registry-00.txt
  • Request For Comments:
    The SIP INFO Method (RFC 2976) (17736 bytes)
    MIME media types for ISUP and QSIG Objects (RFC 3204) (19712 bytes)
    SIP: Session Initiation Protocol (RFC 3261) (647976 bytes)
    Reliability of Provisional Responses in SIP (RFC 3262) (29643 bytes)
    SIP: Locating SIP Servers (RFC 3263) (42310 bytes)
    SIP-Specific Event Notification (RFC 3265) (89005 bytes)
    DHCP Option for SIP Servers (RFC 3361) (12549 bytes)
    Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) (RFC 3310) (36985 bytes)
    The Session Initiation Protocol UPDATE Method (RFC 3311) (28125 bytes)
    Integration of Resource Management and SIP (RFC 3312) (65757 bytes)
    Internet Media Type message/sipfrag (RFC 3420) (14745 bytes)
    A Privacy Mechanism for the Session Initiation Protocol (SIP) (RFC 3323) (54116 bytes)
    Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks (RFC 3325) (36170 bytes)
    Session Initiation Protocol Extension for Instant Messaging (RFC 3428) (41475 bytes)
    The Reason Header Field for the Session Initiation Protocol (SIP) (RFC 3326) (15695 bytes)
    Session Initiation Protocol Extension for Registering Non-Adjacent Contacts (RFC 3327) (36493 bytes)
    Security Mechanism Agreement for the Session Initiation Protocol (SIP) Sessions (RFC 3329) (51503 bytes)
    Private Session Initiation Protocol (SIP)Extensions for Media Authorization (RFC 3313) (36866 bytes)
    The Session Initiation Protocol (SIP) Refer Method (RFC 3515) (47788 bytes)
    Dynamic Host Configuration Protocol (DHCPv6)Options for Session Initiation Protocol (SIP) Servers (RFC 3319) (14444 bytes)

    Current Meeting Report

    Minutes, SIPWG IETF57
    Recorded by Alan Johnston (alan.johnston@mci.com)
    Edited by Dean Willis (dean.willis@softarmor.com)
    Revised 17Jul2003
    Meeting July 16, 2003,  0900
    Meeting called to order by chairs.
    Proposed agenda reviewed and accepted.
    Announcement: Jon Peterson has retired as SIP co-chair.
    Brian Rosen volunteered as chat room moderator.
    Alan Johnston volunteered as scribe.
    Status of Drafts - Chairs
    New Pubs: RFC 3515 REFER published
    MIB: Volunteers to review a section of MIB: Orit Levin, Mary Barnes, 
    Cullen Jennings, and Kent (Rohan has his info). Rohan will assign some more 
    congest-safe:  Proposal for author to remove UDP kludge.  No 
    objections or discussion.
    PUBLISH - Aki Niemi
    Open Issue: collision recovery.  Proposed solution: query principle, may 
    subscribe to package. No objections or discussion.
    Open Issue: PUBLISH and dialogs.  Proposed solution: add text about 
    dialogs, discourage reuse. No objections or discussion.
    Open Issue: atomicity. Proposed solution: relax restriction about 
    overlapping requests.
    Comment: Go with a simpler model - all tuples are independent.  Solve 
    using composition and authorization instead of publication.  Or, most 
    recent publisher overrides any others.
    Comment: Agree with comment. Don't reinvent Webdav.  Don't make 
    endpoint behavior too complex.  
    Comment: Agree with comment that this is an authorization problem.
    Comment: Not clear we can relax overlap with congestion issues.
    Conclusion: Author will take to the list for more discussion.
    Resource Priority - Henning Schulzrinne
    Issue: error handling.  Proposed solution: 503 or 403 or 417 (Unknown 
    Resource Priority - only if Require is used. No objections or 
    Believed to be ready for WGLC
    Comment: Pointers to name spaces are in draft.
    Comment: Role based authorization is still moving forward.
    Volunteers to review the next draft: Paul Kyzivat, Ben Campbell
    Caller Prefs - Jonathan Rosenberg
    Issue in Callee Caps - URI-user and URI-domain - duplication: 
    Suggested  Use a Device ID (Contact URI attribute) instead? No 
    conclusion in this discussion.
    Comment: Device ID is interesting, but could be overloaded. Should 
    recommend GRUU for attended transfer.
    Comment: Expiration of device ID is unpredictable.
    Conclusion: Quick list consensus on adding device ID.  Recommend GRUU 
    instead for transfer case.
    Caller Prefs
    Comment: Enumeration is better
    Open Issue: redirection - RFC 3261 proxy merging q-values is broken.  
    Proposal: include text saying this.
    Question: Do we need to mandate this?  Questioner will send a short use 
    case to mailing list.
    Open Issue: lost use cases due to changes.
    Comment: This is a feature.
    Comment: Can be done with multiple requests.
    Conclusion: no changes needed.
    Open Issues in Use Cases: No discussion.
    Comment: Does basing on RFC 2533 provide any value?
    Comment: Should RFC 2533 reference just be an informational 
    SIP Identity - Jon Peterson
    Topic: AIB
    No issues or comments.
    Topic: AES and S/MIME 
    Question: Should we redo S/MIME examples in RFC 3261?
    Proposal: Cullen Jennings could do some examples.  
    Comment: Base-64 encoding issue causes interoperability problems. 
    (Binary encoding is better)
    Comment: No commercial SIP stacks support S/MIME and TLS.
    Comment: There were 2 implementations of S/MIME at last SIPit.
    History Info - Mary Barnes
    Open Issue: Index.  Proposal: Make it mandatory and clarify loose 
    routing behavior.
    Open Issue: Internal Retargeting.  Proposal: Include some normative text and 
    Open Issue: Privacy.  Proposal: Add text.
    Comment: Draft needs major clarification on privacy, redirection, 
    backwards compatibility, others. Will discuss on list.
    Comment: Include in security section - this header solves a useful 
    problem that a requestor could verify that appropriate proxies have 
    retargeted a request.
    Conclusion: Much more work needed.
    Securing SIP Identity Headers - Mary Barnes
    (SIPPING draft but discussed here for convenience)
    Comment: Question on question not solution.  Do we need to do this?
    Comment: This is a type of middle-to-end security problem. We need to 
    solve this problem.
    Comment: If we redid Proxy-Auth header, we would use a body instead of a 
    Parameter Registry - Gonzalo Camarillo
    Open Issue: Which URI parameters should be registered?
    Comment: Do we want p-parameters?
    Comment: Lets not make the same mistake twice.
    Comment: Want to increase interoperability and avoid collisions.
    Comment: To prevent conflicts during Internet-Draft stage, should use this 
    Comment: C language analogy -- this is like requiring C developers to go 
    back to Standard C committee and register every variable name they use as a 
    language keyword. The registry could be flooded with requests.  Propose 
    that we should only register URI parameters that are global in nature.
    Comment: Have informal non-IANA registry instead (webpage)
    Comment: Should do the same thing for parameters (headers and URIs) as 
    Comment: Similar to standardization of headers across protocols effort.
    Conclusion:   A Hum was taken which supported the creation of an IANA 
    registry for parameters defined by  RFCs. No consensus on the rest of the 
    issue - more list discussion needed.
    Connection Reuse - Rohan Mahy
    Open Issue: Clarity on which is original and which is alias.
    Open Issue: Security - explaining Mutual TLS and digest
    A Humm was taken which supported that people care about the work.
    A Humm was taken which supported that this mechanism is reasonable.
    Comment: Need to describe how to handle when multiple parties claim the 
    same alias (
    Conclusion: A Humm was taken which supported that the chairs request a 
    charter modification to adopt as a WG item.
    SIP Security and S/MIME - Cullen Jennings
    Comment: Mechanism could be used for certificate or raw keys.
    Comment: Identity work avoided UAS having to do any PKI operation.  
    Identity document also only identifies the domain,
    not the individual user.
    Question: Does this work in both ways?  Answer: Yes, but not exactly.
    Many more comments until we ran out of time.
    Hum taken on interest of working group in solving this problem.  Strong 
    interest indicated.
    Conclusion: The WG will continue discussion of this topic.


    SIP WG Status
    Request History - Solution
    Caller Prefs and Friends
    URI and header field Parameter Registries
    Certificate Directory for SIP
    Connection Reuse in SIP: IETF 57, SIP