2.8.19 Session Initiation Protocol (sip)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.
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: 2004-11-01


Dean Willis <dean.willis@softarmor.com>
Rohan Mahy < rohan@ekabal.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: http://www.ietf.org/mail-archive/web/sip/index.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
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
Done  Session Timer spec, revised to IESG
Done  Caller preferences specification submitted to IESG
Done  Submit SIP Identity documents to IESG for Proposed Standard
Done  The SIP Join Header submitted to IESG for Proposed Standard
Done  Replaces header to IESG (PS)
Done  Upgrade S/MIME requirement for AES in 3261 to IESG (PS)
Mar 04  Application Interaction to IESG (BCP)
Mar 04  Resource Priority signaling mechanism to IESG (PS)
Done  Presence Publication to IESG (PS)
Apr 04  Connection reuse mechanism to IESG (PS)
Apr 04  Enhancements for Authenticated Identity Management to IESG (BCP)
Done  Guidelines for Authors of SIP extensions submitted as Informational
May 04  Mechanism for obtaining globally routable unique URIs to IESG (PS)
Jun 04  MIB spec to IESG
Sep 04  Review WG status (consider closing) and/or submit a future milestones plan to IESG
Sep 04  Request History mechanism to IESG (PS)


  • draft-ietf-sip-session-timer-15.txt
  • draft-ietf-sip-mib-08.txt
  • draft-ietf-sip-guidelines-08.txt
  • draft-ietf-sip-sctp-04.txt
  • draft-ietf-sip-compression-02.txt
  • draft-ietf-sip-content-indirect-mech-05.txt
  • draft-ietf-sip-identity-03.txt
  • draft-ietf-sip-history-info-04.txt
  • draft-ietf-sip-resource-priority-05.txt
  • draft-ietf-sip-connect-reuse-03.txt
  • draft-ietf-sip-uri-parameter-reg-02.txt
  • draft-ietf-sip-parameter-registry-02.txt
  • draft-ietf-sip-rfc3312-update-03.txt
  • draft-ietf-sip-gruu-02.txt
  • draft-ietf-sip-anat-usage-00.txt

    Request For Comments:

    RFC2976 PS The SIP INFO Method
    RFC3204 PS MIME media types for ISUP and QSIG Objects
    RFC3261 PS SIP: Session Initiation Protocol
    RFC3262 PS Reliability of Provisional Responses in SIP
    RFC3263 PS SIP: Locating SIP Servers
    RFC3265 PS SIP-Specific Event Notification
    RFC3310 I Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)
    RFC3311 PS The Session Initiation Protocol UPDATE Method
    RFC3312 PS Integration of Resource Management and SIP
    RFC3313 I Private Session Initiation Protocol (SIP)Extensions for Media Authorization
    RFC3319 PS Dynamic Host Configuration Protocol (DHCPv6)Options for Session Initiation Protocol (SIP) Servers
    RFC3323 PS A Privacy Mechanism for the Session Initiation Protocol (SIP)
    RFC3325 I Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks
    RFC3326 PS The Reason Header Field for the Session Initiation Protocol (SIP)
    RFC3327 PS Session Initiation Protocol Extension for Registering Non-Adjacent Contacts
    RFC3329 PS Security Mechanism Agreement for the Session Initiation Protocol (SIP) Sessions
    RFC3361 PS DHCP Option for SIP Servers
    RFC3420 PS Internet Media Type message/sipfrag
    RFC3428 PS Session Initiation Protocol Extension for Instant Messaging
    RFC3515 PS The Session Initiation Protocol (SIP) Refer Method
    RFC3581 PS An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing
    RFC3608 Standard Session Initiation Protocol Extension Header Field for Service Route Discovery During Registration
    RFC3840 Standard Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)
    RFC3841 Standard Caller Preferences for the Session Initiation Protocol (SIP)
    RFC3853 Standard S/MIME AES Requirement for SIP
    RFC3891 Standard The Session Inititation Protocol (SIP) 'Replaces' Header
    RFC3892 Standard The SIP Referred-By Mechanism
    RFC3893 Standard SIP Authenticated Identity Body (AIB) Format
    RFC3903 Standard An Event State Publication Extension to the Session Initiation Protocol (SIP)
    RFC3911 Standard The Session Inititation Protocol (SIP) 'Join' Header

    Current Meeting Report

    Minutes of SIP WG: IETF 61

    Monday, November 8 Session
    Agenda bash and Status - Chairs

    Seven RFCs since last IETF, including PUBLISH
    WGLC - GRUU, non-Invite-Transaction
    Some things are late
    Proposing new milestones
    - two REFER drafts - two different milestones?
    Rohan has new sponsor and new e-mail address

    Connection Reuse
    Rohan Mahy, Cullen Jennings - draft-ietf-sip-connect-reuse-03.txt
    Non-trivial security problems with existing digest-based reuse mechanisms
    Now support reuse of mutual-authenticated TLS connections
    Cullen has an open issue (the only one on the table)
    Based on Via: header with ;alias
    Certificate could contain multiple domain names URIs
    Cullen suggests basing the alias on the TLS peer value
    Vulnerable to DNS cache poisoning, but easier to do
    Rohan suggests going with existing proposal
    - Lots of discussion about many other ways to authorize connections
    - Long discussion ensued about the scope. Is there any time you don't want to reuse a connection? Yes, for load balancing. How does this mechanisms interact with existing DNS SRV weighting algorithm from RFC3263.
    - Jonathan taking action to provide scenarios

    Cullen - lots of problems between UA and proxy - firewalls, etc.
    Proxy keeps track of "connection" (whether TCP or UDP four-tuple).
    1. TCP keepalive every periodic number of seconds? CRLF? REGISTER? New message (PING)?
    - REGISTER is horrifically expensive - not a general solution
    - CRLF doesn't generate an application ACK - have to wait for TCP keepalives. question about if standard TCP interface allows check. We think we can check unacked bytes in most(?) socket interfaces and use CRLF.

    2. UDP keepalive - same problem plus small residential NAT rebooting can't be detected (still respond to PINGs)
    Use STUN for UDP "connections"? No objections in the meeting
    3. Redundant connections? Need a unique device id in the registration
    Allow this? yes
    May need Quick Reconnect to reduce proxy load on avalanche restarts, etc. - the limiting factor on scaling most deployments. Don't add load when the proxy is most loaded!

    Identity - Jon Peterson - draft-ietf-sip-identity-03.txt

    New version of the draft, removes response identity text, added examples
    Added text on privacy and providing identities for telephone numbers ("punting until later")
    Identity-Info schemes: allow CID? DNS URLs? but don't be TOO generous (interoperability problems)
    Commment: What's the mandatory-to-implement scheme? RFC 3840 already has "schemes I support".
    Q: Does everyone implement CID URI? apparently not, at least not the people in the room :-)

    What's the relationship to the -certs draft? We're concerned about required modifications to installed base
    Rohan - normative dependence on -certs not a good thing. the draft does not require UAs to implement certs draft.

    Shopping for response codes? can't dereference Identity-Info, don't like your certificate, bad Identity in From field...
    Do we need three new response codes? We only have 100 4XX response codes, so ...
    Room concensus is three new response codes
    Q: we're assuming use of global PKI. It's harder than it looks
    A: but it does work for the WWW today, and no root or trust model is mandated by the draft
    Q: but on the WWW, users are making choices. In this case, proxies are making choices. That's harder.
    Q: Is "don't like your certificate" a provisional response? No, it's final.
    Jon believes it is possible for servers to make these decisions in some scenarios.
    Look at message-identity draft - it's 44 pages of analysis about how we got where we are today!

    GRUU - Jonathan Rosenberg - draft-ietf-sip-gruu-02.txt

    General problem - what should gruu specification say about sips and gruu?
    Want to avoid two two registrations to get a sip and sips URI for the same resource.
    Existing spec allows upgrade from sip to sips (resource must be the same for both schemes)
    Assume both don't have to exist, but if they do, they must point to the same resource.
    If contact is sip, GRUU is sip URI, but server creates sips URI, too.
    If contact is sips, GRUU is sips URI, but server does not create sip URI.
    Does this work for everyone?
    Q: if sips URI is created and then used, we may/may not be able to tell a connection is secure. This is bad.
    Q: creating sips GRUU is implicit behavior (client didn't request this)
    A: creating a sips GRUU doesn't mean much - don't have to create a TLS connection, etc.
    Q: problem is that if we're not doing TLS, we may be doing something else (present or future protocols)
    Q: The recipient can do the same upgrade to sips anyway.
    Q: Does this require unnecessary resources on the server?
    A: We have the same problem with people trying to connect to people who don't support SIPS now
    Q: When we register, do we see sip and sips URIs?
    A: Depends on what you send as the contact URIs. Should work the same as AOR registrations
    Jonathan to add text reflecting his proposal

    Connection reuse/GRUU reuse has been problematic - when we have multiple connections, we get wrapped around the axle
    Allow multiple contacts in a GRUU for redundancy (all to the same instance)?
    Q: If my TCP connection dies and comes back, is my connection-id the same? If so, it's not a connection-id...
    Q: If I'm hosting these things, how many do I know to create?
    A: Maybe just two, but this is provider policy - does the client know how many interfaces it has? Maybe...
    Who understands the issue here? a critical mass - please send e-mail to list/Jonathan and chairs
    Conflict Resolution - current spec requires since contact per instance, which helps avalanche restarts
    Does AOR map to a GRUU? how does edge proxy know it should record-route? Should not record-route if client uses GRUU
    - this happens in IMS architecture, for instance
    200 OK contains Supported: GRUU EP? Remove record-route on response
    Q: Shouldn't edge router be authoritative anyway and route without GRUU?
    A: IMS proxy may be in a different domain (HSP and VSP domains) - spiral is expensive - don't use GRUU in these cases
    * (resumed here)
    Does GRUU map to AOR? AORs map to contacts, so do you redirect to a GRUU or to a contact?
    You get different proxy behaviors for AOR->GRUU and GRUU->contacts
    Q: If GRUU was just a higher-priority contact, would that solve this problem?
    A: Would depend on the logic of routing
    Proposal: AOR -> GRUU -> contacts? Register and refresh up the chain, AOR -> GRUU mapping disppears when GRUU contacts disappear
    Q: This is the wrong direction, we're going to explode. Enumerate new behavior reflecting GRUU extension
    We have a real terminology problem with contacts and connections - sometimes they are headers, sometimess not
    Cullen - we're confused, we need a room with a white board
    Q: Should reg-extension be merged with this draft?

    Content Indirection - Eric Burger - draft-ietf-sip-content-indirect-mech-05.txt

    05 draft provides optional content, content-disposition entity header now a MUST (from SHOULD)
    Using hash, not base64

    Open Issues - e-tags and content-ID? work this week
    URI scheme negotiation - full negotiation needed? ("yes" = hack SDP, out of scope)

    History Info - Mary Barnes - draft-ietf-sip-history-info-04.txt

    Added protocol structure text as descriptiove
    Added text on scenario when TLS not available
    Some editorial changes
    Should -> MUST for applications lacking History-Info and privacy impacts
    Updated response processing to reflect privacy
    Added text for reason header in response
    Added appropriate characters for escaped example URI
    Have identified indexing error, 480 timeouts should be 408s, missing quote on "Busy Here"
    WGLC ends on November 29
    Feedback, especially with text, is always appropriate, especially now.

    SIP Working Group Meeting: Session 2, 11-11-04

    Resource Lists : Adam Roach
    - Updated Schema
    - Added text on S/MIME Handling
    - Open Issue: Credential Transfer How can you be sure user has authorized being on resource list? Using Identity covers 95% of cases: for now, resource list server needs to be either in the domain of the subscriber of the list or in the domain of the notifier. Will put off solving the three domain model (list server is in an orthogonal domain), but make sure text doesnt prevent doing this in the future.

    Resource Priority: James Polk
    - Updates from 04 to 05 were extremely controversial. Intended to address expected IESG concerns on interoperability, normative inspecificity, and IANA registration.
    - Proposal to remove confusion about Modes. Agreed to Remove Semi-strict Mode.
    - Editor proposed New Table describing Resource Priority namespaces for IANA.
    - Big fight occurred here: 04 vs 05
    agreement on specifically defining terms
    people adjourned, and issues will be brought to the list

    Refer Extensions Orit Levin
    - Split refer extensions into two separate drafts: REFER with no implicit Subscription, and Feature tags with REFER
    - Refer with no implicit subscription should be included

    Cert Usage: Cullen Jennings
    - Draft describes both HTTP and SIP method for Fetching Certs and Credentials. One open issue: Which mechanism is mandatory to SUBSCRIBE over SIPS or HTTPS GET:
    - Using HTTPS expected to scale easier (no subscriptions) and is lower bar for server implementation, while SIP mechanism allows for automatic certificate revocation and reuse of a protocol known to be implemented in the client.
    - There was very rough consensus to go forward with SUBSCRIBE/NOTIFY as the mandatory mechanism

    SAML for SIP
    - Latest draft Covered Identified Problems in previous version
    - Need to Document Assertion Constraints and scope solution approaches
    - Comments were solicited

    Rough Consensus on making multipart-mime mandatory in all SIP implementations to be taken to list


    Connection Re-Use
    Request History
    Content Indirection
    Event Lists
    Resource Priority
    REFER extensions
    SIP Certificates