2.7.15 Session Initiation Protocol (sip)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. 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: 2005-07-25


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)
Done  Application Interaction to IESG (BCP)
Done  Presence Publication to IESG (PS)
Done  Resource Priority signaling mechanism to IESG (PS)
Apr 04  Connection reuse mechanism to IESG (PS)
Done  Guidelines for Authors of SIP extensions submitted as Informational
Done  Enhancements for Authenticated Identity Management to IESG (BCP)
May 04  Mechanism for obtaining globally routable unique URIs to IESG (PS)
Done  MIB spec to IESG
Sep 04  Review WG status (consider closing) and/or submit a future milestones plan to IESG
Done  Request History mechanism to IESG (PS)


  • draft-ietf-sip-mib-09.txt
  • draft-ietf-sip-guidelines-09.txt
  • draft-ietf-sip-sctp-06.txt
  • draft-ietf-sip-content-indirect-mech-05.txt
  • draft-ietf-sip-identity-05.txt
  • draft-ietf-sip-history-info-06.txt
  • draft-ietf-sip-resource-priority-10.txt
  • draft-ietf-sip-connect-reuse-04.txt
  • draft-ietf-sip-gruu-04.txt
  • draft-sparks-sip-nit-problems-02.txt
  • draft-sparks-sip-nit-actions-03.txt
  • draft-ietf-sip-refer-with-norefersub-02.txt
  • draft-ietf-sip-target-dialog-01.txt
  • draft-ietf-sip-location-conveyance-01.txt
  • draft-ietf-sip-refer-feature-param-00.txt
  • draft-ietf-sip-e2m-sec-00.txt
  • draft-ietf-sip-outbound-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
    RFC3486 Standard Compressing the Session Initiation Protocol
    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
    RFC3968 BCP The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)
    RFC3969 BCP The Internet Assigned Number Authority (IANA) Universal Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)
    RFC4028 Standard Session Timers in the Session Initiation Protocol (SIP)
    RFC4032 Standard Update to the Session Initiation Protocol (SIP) Preconditions Framework
    RFC4092 Standard Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)

    Current Meeting Report

    Minutes, SIP at IETF 63

    Minutes, SIP WG, IETF 63

    Reported by Dean Willis and Adam Roach
    Edited by Dean Willis

    Session 1

    Status, presented by Rohan Mahy

    Slides presented.

    Note that content-indirection has finally cleared security review and requires a small RFC editor note that will be drafted by Allison.

    Discussion of milestones:

    Suggested that it would be a good idea to have a regular report on status for WGLC, etc.

    The WG will consider getting a WG secretary as an assigned role.

    Noted that if we can't track the work we have, we shouldn't accept new work.

    Proposed that we delete the response identity work from our work plan. We plan to reopen this during the discussion of the related draft in the Tuesday session.

    Discussion on priority of resource conveyance. Proposed schedule is for Spring 06. James Polk thinks we can get it done sooner, and should due to dependencies. We agreed to reopen the schedule discussion after the WG discussion of this draft in the Tuesday session.

    Discussion of SIP Security Flows

    There seems to be some support for this work, and a consensus that this stuff if important.  Possibility raised that we might also need to update 3261 and related documents, either to add clarity or to fix bugs, and that this is more important than getting example flows. We also have references to outdated security documents, and common implementations may also not be acceptable for current security review. It was noted that S/MIME implementation issues have been common at SIPIts. Poll: Who has an implementation of S/MIME? At least 5 in the room, and two others at last SIPit who are not represented in this room. consensus: We do not have all required expertise in this room. A significant problem is that there is a knowledge gap between the implementation community and the IETF security area. We'll work on a plan for reducing that gap. An important goal is to move the knowledge from this document (once it's there) into the broader community.

    Topic: GRUU

    Discussion led by Jonathan Rosenberg
    Slides presented

    Changes since last version reviewed.

    Comment: Opaque parameter: Cullen offered a lengthy comment supporting the idea that nodes other than proxies be able to extract the AOR from the GRUU. The current text seems to allow this if the opaque parameter is used. Rohan will send to Jonathan commentary on an apparent error in the current text.

    Comment: We may need to discuss the situation where a client has two connections to different proxies.

    Comment: Would like to see more discussion on the opaque parameter. Jonathan will plan to clarify the general usage and synchronize the work with the SIP outbound dual-registration use case.

    Comment: When is the GRUU assigned? Is it a function of registering a contact, or is it a function of someone needing the GRUU? Jonathan considers this to be a function of domain policy. It would appear that it cannot be constructed after the registration, but could be constructed before. Further discussion of this can be added to the GRUU document.

    Comment: There needs to be something about the ability of a user agent to determine whether an AOR is or is not a GRUU when it receives a GRUU. This relates somehow to use of the GRUU in transfer cases. One possibility might be a ";user=gruu" parameter. Discussion seem to indicate that the receiver just has to try the URI and see if it works -- it can't really care whether or not the contact is a GRUU. Proposed to keep as-is, except for clarification.

    Comment: We have a September milestone. Will we make it? This seems to depend on the acceptance of today's proposals.

    Issue: The Double Role of GRUU

    Proposed three solutions 1) GRUU for new requests only, 2) Amend use of Contact in mid-dialog request, 3) , keep as is

    Comment: The SBCs are going to ruin GRUU in all the usages proposed. This may more strongly affect #2, and favors #1.

    Comment: The contact information is usually wrong anyhow. This favors #2.

    Comment: Currently, route sets in a dialog are immutable. The ability  to use applications at the end point is dependent on  this,

    Comment: #2 is favorable, because it also encourages endpoints to deal properly with.  Draft should note that when used with Replaces, INVITES to a GRUU should only get automatic and not interactive service treatments.  This will require some changes in the document relating to edge proxy behavior and moving treatment.

    Comment: After the preceding discussion, Cullen no longer favors #2.

    Comment: Multiple implementations have proposed to use multiple contacts in dialog as a failover mechanism, This does not favor idea 2.

    Poll: Does anyone strongly object to "keeping the text as is"? for this issue with clarification as discussed above)? Consensus on this position is reported.

    Topic: Dialog retargeting
    Discussion led by Jonathan Rosenberg
    Slides included in GRUU deck

    No open issues, currently in WGLC

    Topic: End to Middle Security

    Discussion led by Kumiko Ono
    Slides presented

    Issue #1 UA reaction to (undecipherable) error? If there is only 1 error code and the UAC doesn't support e2m, they don't really know what to do.

    Comment: What we want here is the client to encrypt the body and add the proxy to the keying. This differs from the current usage, in which we want the UAC to change the target of the body rather than adding a key.

    Comment: The confusion on this relates to confusions on the 493 response, and that leads to the question of response identity. It might be possible to use SIPS to target the alleged proxy.

    Comment: We must be careful to not accidentally introduce errors that lead to "base 400" style behavior. This favors a separate error code.

    Proposed that we move forward with a separate response code.

    Issue #2: How does a proxy indicate disclosure of a specific content type or whole body?

    Proposed that an error code without body type have semantics of "disclose whole body". No objections were noted to this proposal.

    Issue #3: Do we need a labeling mechanism to instruct a server to validate a signature

    Proposed: No. No objection noted.

    Issue #4: How does a UA know if the target proxy server complied to  the UA's request?

    Proposed that if  we don 't have a use case for this and one is not forthcoming, that we discard this requirement. Further discussion deferred to list.

    Noted that we expect to go to WGLC with the next rev of the dratf.

    Topic: Outbound Connections

    Discussion led by Cullen Jennings
    Slides presented.

    Changes in terminology since last draft reviewed. Critical terms are "flow" and "flow ID".

    Comment: The terminology is still confusing. Some definition changes were discussed, including use of the term "epoch" to refer to a set of TCP and UDP connections.

    Issue: default max retry time is 30 minutes. Does this need to change? No changes were suggested.

    Issue: Keepalive. Proposed that we use STUN keepalives for both TCP and UDP. This would require changes to the STUN document.

    Comment: ICE also uses STUN over TCP.

    Comment: The client needs to know that this is supported. Currently, this is done as a URI parameter.

    Discussion of this followed, without conclusion.

    Issue; Keepalive Times? Proposed that this be 30s for UDP and 10 minutes for TCP. Noted that 1% of one operator's boxes have UDP timeouts of 15s on their NAT bindings.

    Comment: We are not doing this because TCP's keepalive does not work, but because the feedback is not delivered fast enough to the SIP system

    Comment: Need to make sure that the document shows that the timer resets on each instance of normal traffic.

    Comment: Do we know enough about the performance and congestion impact of this?

    Proposed:  30s for UDP and 2min for TCP.

    Comment: If UAs do this at startup, we have a potential for a restart avalanche. Discussion on this is deferred.

    Issue: Flow questions:

    Noted that we cannot assume that all UAs using this will have multiple flows.

    Issue:  Transport integrity for flow matching.

    Do we want the security section say that this only works with integrity protection? general consensus on "no".

    Further issues taken to list, including route construction logic.

    Session 2

    Topic: Refer: Feature Tags

    Discussion led by Orit Levin
    Slides presented

      - Topic of discussion: Which feature tags do we want to include
        in the REFER? Does the referer include all features it knows
        about? Only the ones that it thinks are relevant for the call?

        - Paul Kyzivat: Allowing the referer to pick which features
          to include is a slippery slope. Doesn't think disclosing
          feature tags is a security risk. Proposes that the referer
          should (or must) include all feature tags it knows about

        - JDR: Disagree with Paul on the security issue. Also, has
          a concern that people will start using these to bypass normal
          SIP negotiation (e.g. not offering video if the referer does
          not indicate support for video). Further, thinks it is realistic
          to pick which feature tags make sense to include: presumably,
          the purpose of the mechanism is to allow changes in the user
          interface, and it should be possible to identify which features
          might have an impact on the interface.

        - Paul Kyzivat: Don't feel strongly about the topics -- seems to
          hinge on security. If there are no security reasons to not
          include *all* feature tags, then including all feature tags
          can only be a good thing.

        - Cullen Jennings: We need to make sure this isn't going to rely
          on implementors deciding what things to include. Also, the list
          of features can grow to be quite long, if you include everything.
          Propose that we set up a concrete registry of feature parameters
          that should be included in REFER requests.

        - Rohan Mahy: Would it be reasonable to include only those features
          that cannot be discovered via SIP negotiation?

        - Proposal: Use MAY and SHOULD recommendations around which official
          tags are to be included in REFER requests. The text will be vetted
          on the list.

        - Cullen: This is tricky; as an implementor, I can't tell which tags
          I should include in a REFER -- and I can't count on what other people
          will send.

        - Rohan: There are really only two options. You can either have an
          explicit list of what must be included. This will always be out
          of date (and consequently always wrong). Alternately, you can leave
          it up to the discretion of the implementors, in which case it will
          only sometimes be wrong, which is better than always being wrong.

        - Cullen: That doesn't make sense. An IANA registry makes a lot more

        - Paul Kyzivat: I don't know why we need this at all. How does knowing
          ahead of time that the thing to be invited is a focus make a

        - Orit: Consider isfocus. Most of the time, you're not going to be
          talking to a focus. But somtimes you are, and you can either
          find out ahead of time, or have to query for it.

        - Paul: No, you don't. You get that fact in the 180 or 200 response
          to the INVITE.

        - Dean Willis: I'm confused and my head hurts. Are we reaching a

        - Consensus: no.

        - Chair proposal: We will have a group of interested parties get
          together after the meeting to come up with a plan to conclude the

    Topic Refer: Norefersub

    Discussion led by Orit Levin
    Slides presented

      - Should we use a "Refer-Sub: false" mechanism, or a Supported/Require

        - Adam Roach: We already decided this. Let's not re-open this.

        - RjS: This is not the timme to do this.

        - JDR: The new proposal doesn't seem to be general in any way.

        - Consensus: Leave it as we defined previously.

      - Should remove the use-case discussing single-hop? There was an
        explicit request to do this.

        - RjS: This seems to work.
        - JDR: It's impractical.
        - RjS: I've seen deployments that do this.
        - JDR: Okay. It's not worth debating.

        - Cullen: Is this a recommendation, or simply an observation?

        - Consensus: Just an observation. The draft should reflect this fact.

    Topic: Location Conveyance

    Discussion led by James Polk

      - Topic: Location Header Option-tags

        - HGS: This seems to be a table of contents for the body. If
          we're going to do that, it should be more generic. We would
          basically want this for any non-SDP body type. (Some discussion
          around this point, but basically results in agreement with
          Henning's comments)

        - Dave Oran: I'm not sure how these specific option tags allow
          a user agent that doesn't know its location but having the
          wherewithal to select, e.g., between civic or geoloc
          information. (Longer discussion, taken offline).

        - Cullen: SHould look at whether this can be based on the
          SIP identity work. (James expresses some concerns that the
          ECRIT work shouldn't block on SIP identity).

        - Unknown Speaker 1: Is it possible to include information both
          from the terminal and by the proxy?

        - James: What do you do in the case of conflicts?

        - Unknown 1: Use what the UA provides.

        - James: Service providers don't want to trust that.

      - Topic: Dean doesn't like using OPTIONS to fetch UAC's location.

        - Several: Dean isn't the only one.

        - Consensus: This should be a SUB/NOT mechanism. (e.g. UA
          subscribes to own presence).

        - Open Issue: Which event package should be used? (Presence,
          new one defined in SIPPING, or new one defined somewhere else)

        - Several Speakers: Presence is done, filtering has had a lot
          of work done on it. It makes no sense to do this work all over
          again with the same end result.

        - Others: It may be too heavy to expect people to deploy presence
          just for emergency services. It's a bit complicated.

        - Rohan: I will put together an email discussing why presence
          isn't the right way to do this.

        - Proposal: Take this text out of the draft, put it elsewhere,
          and progress it separately.

        - Will be taken to the list. If we can't close quickly, we will
          split the draft.

    Topic: Response Identity

    Discussion led by Feng Cao
    Slides presented

      - HGS: This appears to be reinventing TLS using HTTP-digest-like

      - JDR: We need a way to figure out a way to verify that the
        connected party is who they say they are.

      - Jon Peterson: Don't conflate the party or parties who respond
        with the party to whom you are connected.

      - General discussion: It's not clear what this document solves
        that TLS does not. The response authentication stuff simply
        doesn't make sense, given that SIP mandates TLS.

    Topic: SIP SAML

    Discussion led by Jon Peterson
    Slides presented

      - Several people spoke up in support of role-based authorization.
        This was followed by a dogpile of varying use cases.

      - HGS: The barrier to entry seems to be high -- doing the work
        to put in the first installation is wasted, since there's no
        one to talk to.

      - High level issue: should we split framework from mechanism?

        - Cullen: We don't want to freeze the framework before we start
          on the mechanism.

      - Poll for consensus: Should we take this on as a working group

        - Cullen: Where does this go in our schedule?

        - Result: Rough consensus to add as a working group item.

    Topic: Answer and Alert Mode Extensions

    Discussion led by Dean Willis
    Slides presented

      - Paul Kyzivat: The emphasis thing doesn't seem to make much sense.
        Semantics are unclear.

      - Dave Oran: I'm not confused. I'm sure it's bogus. You can use
        an "Alert-Info" header that specifies a different mode of
        ringing operation. You can use "Priority" if you want to emphasize
        a call.

      - Andrew Allen: We're not sure how priority is getting used.

      - JDR: This presumes a discrete set of policies, which need to be
        well-defined at the UAS -- otherwise, this is pretty useless.

      - Francois Audet: We definitely need to have better defined
        semantics for this, including examples.

      - JDR: Yes, this does need to have applicablity outside the OMA.
        Also, note that this benefits from role-based authorization.

      - Paul Kyzivat: In the general case, this has significant ability
        to be abused. Loopback and push-to-talk don't allow covert listening.
        Once it is applied to two-way calls, you need to have much stronger
        security considerations.

      - Several others spoke in favor of having stronger requirements
        around security and policy.

      - JDR: There are two seperable issues here. First, the policy needs
        to be clearer, so that we understand how the override and emphasis
        stuff works precisely. As a separate issue, we need to be able to
        determine how users are authorized to request these kinds of

      - Comment: OMA has an authorization model around this mechanism that it may be possible to

    [Meeting Ends]

      RjS = Robert Sparks
      JDR = Jonathan Rosenberg
      HGS = Henning Schulzrinne


    GRUU and Target Dialog
    End to Middle Security
    REFER extensions
    Location Conveyance
    Response Identity
    SAML with SIP
    Answer and Alert Modes
    Certificates with SIP
    Route Construction