2.8.15 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 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.
Last Modified: 2003-11-04
Dean Willis <firstname.lastname@example.org>
Rohan Mahy <email@example.com>
Transport Area Director(s):
Allison Mankin <firstname.lastname@example.org>
Jon Peterson <email@example.com>
Transport Area Advisor:
Allison Mankin <firstname.lastname@example.org>
Dan Romascanu <email@example.com>
General Discussion: firstname.lastname@example.org
To Subscribe: email@example.com
In Body: subscribe
Description of Working Group:
Note: There is another SIP email list for general information and
Discussion of existing sip: firstname.lastname@example.org
To Subscribe: email@example.com
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 |
|Jan 03|| ||Guidelines for Authors of SIP extensions submitted as
|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 |
|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 |
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 58
Official Scribe, Ben Campbell
Supplementary Scribe, Vijay Gurbani
Minutes Edited by Dean Willis
Topic: Call to Order and Agenda Bash
No issues raised.
Topic: Status, Chairs
New milestones proposed. No schedule objections raised, but it was
proposed that the app-interaction framework be published as a proposed
standard instead of BCP. Concerns about MIB status raised. Noted that
SIP should certainly plan to operate at least through the current
work-elevation plan from SIPPING, which extends through December 2004.
Topic: Congestion Safety, Dean Willis
There appears to be little interest in implementing this draft.
Some suggestions for simplifying it were made. It was also suggested
that we need to change RFC 3263to prefer TCP over UDP, explain
congestion issues and avoidance in a BCP, and complete the connection
reuse work in order to encourage TCP deployment. Many endpoints now
implement only UDP. We also need to differentiate fragmentation and
congestion. It was noted that this problem does not just apply to
MESSAGE, but can be frequently expected with NOTIFY, and with INVITES
using S/MIME protection. DCCP is only a partial solution. Several
people volunteered to work on this proposed BCP.
It was also suggested that the current draft could be simplified to
eliminate new response codes 515 and 516, providing a minimal "NO UDP"
Topic: RFC 3312 Updates, Gonzalo Camarillo
Suggested that we adopt as WG item. No objections were raised.
Conclusion: adopt draft as wg item, negotiate milestone.
Topic: Publish, Aki Niemi
Issue: Should etags be updated on every publish? Consensus: Usage
should be made consistent with HTTP. If it cannot be, we should call
these something else.
Issue: Publication rate. Proposed that rate from event package be used.
Noted that this is probably an irrelevant and meaningless number, as
there may be multiple publishers with no knowledge of each other. Much
debate ensued, with no resolution Further discussion deferred to
the mailing list.
Topic: Request History, Mary Barnes
Issue: r-uri captured anytime request is forwarded. Proposal: Only add
reason for history entries added due to retargeting.
Issue: Privacy. Proposal: information not included when there are
considerations. (when uas sets session or header level privacy)
Next steps: complete flow detail. Do we want to fold reqs into doc as
front matter? Request more mailing list feedback. Dependency on mid-end
Presentation of applicability to voicemail.
Issue: Optionality. Suggested that we apply stronger language to
suggest applications gracefully
degrade in absence of history.
Issue: Implementability: Concerns raised by Robert Sparks, who will
detail on mailing list.
Issue: Security. Note that this in-general seems to depend on the
middle-to-end and end-to-middle security work.
Conclusion: Work should continue, but more thinking about
optionality is needed. RJS and Mary to talk offline.
1400 Non-Invite Transactions, Robert Sparks
Noted that this problem is not related to the transport protocol, but
is specific to the SIP-layer transaction reliability mechanism for all
transactions other than INVITE.
Several alternatives were presented:
A) a series of tweaks
B) Eliminate Timer F, allowing non-invite transactions to pend.
C) USe path-timing estimation techniques to improve UAs knowledge of
D) Revise 3263 caching language to reduce severity of impact.
E) Ignore the problem
Suggested that SIP be revised to use 3-way handshake like INVITE on all
transactions. This might be made backward-compatible through use of an
Polls indicated no consensus on any action, and that the working
group didn't understand the nature of problem or disagreed as to its
severity. Despite the objections of Morton Thiokol engineers, the
shuttle was launched in cold-weather conditions under which it had
never been tested, and the O-rings in the boosters failed.
Conclusion: None. Further discussion deferred to the mailing list.
Topic: GRUU, Jonathan Rosenberg
Issue: GRUU generation for stateless proxy behavior. Consensus that we
need a sample algorithm for understanding.
of a GRUU. Can a gruu change during a registration? Conclusion: No,
gruu is good for lifetime of registrations, refreshes get same gruu.
Do we need a guarantee of difference between registrations? Probably
discuss on list.
Issue: Dialog reuse—no longer a need with gruu. Should gruu spec
dialog resuse if both peers support gruu? (Impacts refer, other
Conclusion: Do not address in gruu spec, address in other drafts, put
pressure on future work to avoid dialog resuse.
Issue: Does Gruu interferes with e2e signaling. UA can try to generate
gruu, could use ice-like mechaninsm to decide if it is reachable.
Propose to add to draft, but never try to put local address in contact
header without using the mechanism.
Chair suggestion: Put statement about not using local gruu in gruu
draft, put “iceing” in separate draft. Author agreed.
Issue: MUST NOT use locally generated gruu is too strong.
Clarified that definition of local gruu is one with a different domain
part than AoR,
MUST does not apply to the examples given.
Topic: Join, Rohan Mahy
Noted that no comments in wglc. Room shows interest, but no one has
We want more list discussion before sending to IESG.
Topic: REFER Semantics, Rohan Mahy
Basic premise is that the semantics of the various uses of REFER
are under-specified. Much discussion ensued.
Issue: Is this equivalent to specifying fixed services? If we have
to specify all the services/features, then the refer approach has
Issue: How do you put refer requests in a context? Dialog reuse?
GRUUs? Explicit refer-to header parameters?
Noted that it may require per-scheme semantics in addition to context.
Issue: Need more than context—how do you know what an endpoint will do
with a particular URI scheme?
Issue: Not useful for authorization, because referee cannot decide if
issuing the request could be bad. Another motivation that is relevant
is to determine how to render the UI for the action.
Sugested: this does not mean fixing refer, it means adding something
Discussion on proceeding: How do we proceed? Refer for other than
transfer unlikely to work on
today’s UAs. Rohan suggests defining semantics for baskets of
functionality. Use option tags to make sure they are supported. Propose
explicit dialog parameters for refer-to. Provide guidance for remote
call control vs. remote UI invocation.
No conclusion, further discussion deferred to list. Interested parties
are to contact Rohan and work on it.
App Interaction Framework -- change from BCP to PS.
Add milestone for RFC 3312 update as PS.
Discuss publication rate on mailing list.
Interactions of Preconditions with Session Mobility in SIP
Request History - Solution
draft-ietf-sip-join and Semantics of REFER