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 <email@example.com>
Rohan Mahy <firstname.lastname@example.org>
Transport Area Director(s):
Allison Mankin <email@example.com>
Jon Peterson <firstname.lastname@example.org>
Transport Area Advisor:
Allison Mankin <email@example.com>
Dan Romascanu <firstname.lastname@example.org>
General Discussion: email@example.com
To Subscribe: firstname.lastname@example.org
In Body: subscribe
Description of Working Group:
Note: There is another SIP email list for general information and
Discussion of existing sip: email@example.com
To Subscribe: firstname.lastname@example.org
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
10. servfeat: Completion of the SIP extensions needed for negotiation
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
|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
|Apr 04|| ||Connection reuse mechanism to IESG (PS) |
|Apr 04|| ||Enhancements for Authenticated Identity Management to IESG
|May 04|| ||Mechanism for obtaining globally routable unique URIs to IESG
|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) |
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 |
|RFC3608||Standard||Session 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
To Do: Chairs: Conclude on resource
- 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.
Group recognized Henry Sinnreich as the "Godfather of SIP" and
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.
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.
Proposed adding filed to tag HI entries that are added when privacy is
Issue Limitation on number of entries?
Options: Pruning mechanism, or just leave to endpoints. Needs more
Cocnlusion: No apparent support for
- 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
Question: Any implementers want to comment on limit?
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?
Conclusion: Remove reason header, put
explicit service invocation parameters.
- Cullen proposed yes.
- Lots of semantics discussion.
- Mixed support for using history info.
- Suggestion that VM service parameters are different than generic
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
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
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
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
Failover for next attempt will not happen if not chached. propose
making this MUST.
Argument on what should means.
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.
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
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
GRUU Mechanism and Device ID
Request History Information
Issues with HTTP Authentication for SIP
Conveying Policy URI in Call-info purpose