2.7.13 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:

       http://www.softarmor.com/sipwg/ -- Additional SIP Page
NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-12

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 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. compression: SIP mechanisms for negotiating and guidelines for using 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 URI).

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
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
Feb 04  Upgrade S/MIME requirement for AES in 3261 to IESG (PS)
Feb 04  Replaces header to IESG (PS) Mar 04 Presence Publication to IESG (PS)
Done  The SIP Join Header submitted to IESG for Proposed Standard
Mar 04  Application Interaction to IESG (BCP)
Mar 04  Resource Priority signaling mechanism to IESG (PS)
Apr 04  Guidelines for Authors of SIP extensions submitted as Informational
Apr 04  Connection reuse mechanism to IESG (PS)
Apr 04  Enhancements for Authenticated Identity Management to IESG (BCP)
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-13.txt
  • - draft-ietf-sip-callerprefs-10.txt
  • - draft-ietf-sip-mib-07.txt
  • - draft-ietf-sip-guidelines-07.txt
  • - draft-ietf-sip-sctp-04.txt
  • - draft-ietf-sip-replaces-05.txt
  • - draft-ietf-sip-referredby-03.txt
  • - draft-ietf-sip-compression-02.txt
  • - draft-ietf-sip-congestsafe-02.txt
  • - draft-ietf-sip-content-indirect-mech-03.txt
  • - draft-ietf-sip-join-03.txt
  • - draft-ietf-sip-authid-body-02.txt
  • - draft-ietf-sip-smime-aes-01.txt
  • - draft-ietf-sip-history-info-02.txt
  • - draft-ietf-sip-resource-priority-02.txt
  • - draft-ietf-sip-callee-caps-03.txt
  • - draft-ietf-sip-connect-reuse-01.txt
  • - draft-ietf-sip-uri-parameter-reg-01.txt
  • - draft-ietf-sip-parameter-registry-01.txt
  • - draft-ietf-sip-publish-03.txt
  • - draft-ietf-sip-rfc3312-update-00.txt
  • - draft-ietf-sip-gruu-01.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
    RFC3361 PS DHCP Option for SIP Servers
    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
    RFC3420 PS Internet Media Type message/sipfrag
    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
    RFC3428 PS Session Initiation Protocol Extension for Instant Messaging
    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
    RFC3313 I Private Session Initiation Protocol (SIP)Extensions for Media Authorization
    RFC3515 PS The Session Initiation Protocol (SIP) Refer Method
    RFC3319 PS Dynamic Host Configuration Protocol (DHCPv6)Options for Session Initiation Protocol (SIP) Servers
    RFC3581 PS An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing
    RFC3608StandardSession Initiation Protocol Extension Header Field for Service Route Discovery During Registration

    Current Meeting Report

    Minutes, SIP WG,  IETF 59

    Reported by Ben Campbell
    Edited by Dean Willis

    Chairs: Status and Opening Comments


    • No new RFCs, 6 docs post last call, 3 in ed queue
    • Security ad-hoc to discuss discuses on auth-id
    • IETF last call 8 more, wglc on resource priority, almost closed.
    To Do: Chairs: Conclude on resource priorty.

    Group recognized Henry Sinnreich as the "Godfather of SIP" and applauded.

    Status for app interaction:

    Moved to SIP. integrated normative lang for GRUU. Need to harmonize with KPML. Nts review after KPML alignment. Call for 4-6 reviewers.

    Connection Reuse:

    More explanatory text. Please read to make sure it makes sense.


    Author wants to replace this with generic mech for 3rd party mods and assertions. Proposed to merge with other requirements into a generic mechanism if possible before San Diego. Ad-hoc on Tuesday.

    Cullen requests reviews on draft-jennings-sip-sec-flows-01.

    Mary Barnes: Request History Mechanism.


    • Editorial nits
    • Merged sipping wg reqs into solution draft.
    • Removed redirect server from ISSUER-req.
    • Addied explicit privacy requirement for proxy to maintain privacy asssociated withe captured r-uri.
    • Clarified syntax. Removed compact form.
    • Added application consideration summary section. Added more text on what to do if history is not available.

    Issue: Privacy:

    Proposed adding filed to tag HI entries that are added when privacy is imposed.

    Issue Limitation on number of entries?

    Options: Pruning mechanism, or just leave to endpoints. Needs more email discussion.
    Cocnlusion: No apparent support for limit.

    Next Steps:

    • More email feedback on open issues -- Text requested.
    • Update flows.
    • Dependency on the e2m security body manipulation.
    • Discussion on proxy manipulation of bodies--will be discussed in ad hoc.

    Question: Any implementers want to comment on limit?

    (no response.)

    Cullen Jennings: Voicemail URI

    Changed to use reason header, rather than separate one.

    Issue: Should this be a parameter, or a header?

    Conclusion: Support for parameter.

    Issue: Should we do history instead?

    • Cullen proposed yes.
    • Lots of semantics discussion.
    • Mixed support for using history info.
    • Suggestion that VM service parameters are different than generic reason header.
    Conclusion: Remove reason header, put explicit service invocation parameters.

    Question: Anyone plan to implement?

    Very few responses. (History being held on whether URI is better.) Need to design something soon.

    Question: Can  history and voicemail can be complementary.

    Discussion indicates yes -- they are different mechanisms that can sometimes, but not always, be used to solve similar problems.

    Question: on whether voicemail URIs should be standard, informational, or abandoned.

    Conclusion: No consensus on whether this should be wg item or not. Consensus not to make it an individual effort.

    Culleng Jennings: Binary Encoding

    Bodies use content transfer encoding. 3261 gives no guidance on what sort of encoding. Proposal to change it so say you SHOULD use binary, but need to be able to receive any.

    Question: What about indirect content?

    Discussion indicates that indirect content woul be contyrolled by the rules of whatever protocol and data format is being indirected to.

    Question: Do we have base64 in SIP specs we need to expunge?

    Robert volunteered to help editors change examples to show binary encoding, using scripts he used for the torture test draft.

    Question: Why couldn't this be on the list.

    No discussion, just muttering.

    Conclusion: Only binary, no requirement to receive non-binary. Will go into errata in a prominent way.

    Hisham Khartabil: Policy URI and purpose

    Issues: proposal to make purpose uri specific for conference policy, rather than policy in general. conf-policy-uri rather than policy-uri.

    Conclusion: accept proposal.

    Issue: Should we set up an IANA registry for purpose parameter?

    Discussion on whether iana registry is just for conflict avoidance, or whether it is a central point to document things.

    Conclusion: No registry.

    Hisham: authentication issue skipped for time.

    Jon Peterson pointed out RotK one big at the Academy award.

    Robert Sparks : Non-invite Transactions


    Split in 3--analysis, agreed changes, controversial changes.

    Open issue: draft says SHOULD cache unreachable destinations. Is this enough?

    Failover for next attempt will not happen if not chached. propose making this MUST.

    Argument on what should means.

    Conclusion: none

    Issue: draft says time-to-live of cache should be short. Can we specifiy a concrete duration?

    We do have a concrete duration if retry-after is specified. Proposal: keep current text.

    Conclusion: none.

    Next Steps:

    Will do the stuff on the last slide

    Cullen Jennings: GRUUS and Instance Identifiers Requirements

    Cullen described some use cases and requirements: client generated, stable across reboot, unique, multiple allowed per host, possible to know identifier without taking phone out of box.

    Conclusions: No clear conclusions.

    Jonathan Rosenberg: GRUU Mechanism and Device ID


    listed on slide.

    Issue: Registration Conflict.

    Crash/reboot may cause two contacts with same instance ID.

    Options: requests for gruu fork (with a bad fork), registrar should reject registration (telling client to query and delete), registrar should delete old registration.

    Proposal: registrar rejects, client then deletes.  New response code a good idea.

    Conclusion: No consensus. Need to think about performance impact on registrar.

    Issue: should this be a caller prefs param?

    Currently it is a calle capability parameter.

    Proposed: Keep current, add text advising against using with accept/reject contact. Use GRUU instead.

    Conclusion: Accept proposal.

    Issue: Format of instance ID

    Is it a URN? do we specify computation?

    Proposal: Do not specify computation, must be formatted as quoted string, merely require temporal and spatial uniqueness.

    Comments: hard to guarantee global uniqueness in quoted strings without specifying computation. URNs may be better. Does privacy apply?

    Conclusions: No consensus, need to work on this some more?

    Issue: GRID usage outside of GRUU. Should this be a generic URI parameter?

    GRID survives proxy translations. Is a form of sub-addressing. Should this be a generic URI parameter?

    Proposal: generic URI parameter. Can be applied to other mechanisms. Only makes sense in the context of URIs that represent an instance.

    Conclusions: No comments. Does this mean we accept it?

    Issue: Document Other uses of GRUU here?

    Proposal: No, specific problem.

    Conclusion: No comments. assume accepted.


    GRUU Mechanism and Device ID
    MIME Encoding
    Voicemail URI
    Request History Information
    Issues with HTTP Authentication for SIP
    Conveying Policy URI in Call-info purpose