2.7.13 Session Initiation Protocol (sip)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN 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: 2005-01-31


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
Done  Request History mechanism to IESG (PS)


  • draft-ietf-sip-session-timer-15.txt
  • 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-04.txt
  • draft-ietf-sip-history-info-06.txt
  • draft-ietf-sip-resource-priority-06.txt
  • draft-ietf-sip-connect-reuse-03.txt
  • draft-ietf-sip-rfc3312-update-03.txt
  • draft-ietf-sip-gruu-03.txt
  • draft-sparks-sip-nit-problems-02.txt
  • draft-sparks-sip-nit-actions-03.txt
  • draft-ietf-sip-anat-usage-00.txt
  • draft-ietf-sip-refer-with-norefersub-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
    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)

    Current Meeting Report

    Minutes, SIP IETF62

    Minutes, SIP at IETF 62

    Revised 4/8/2005

    Minutes edited by Dean Willis based on notes by Paul Kyzivat, Spencer
    Dawkins, Vijay Gurbani, Amy Pendleton, and Miguel Angel Garcia-Martin.

    Monday, 1930-2200

    Topic: Agenda Bash and Status
    by Chairs
    Slides presented and to be included in proceedings.

    Agenda accepted as presented.

    Chairs reviewed status of current work. It was noted that the current
    charter and milestones are completely obsolete, despite having had
    changes submitted several times by the chairs and the ADs. Apparently
    there is some sort of process problem with the IETF web site.

    Topic: GRUU Remaining Issues (Knowing AOR, Rewriting by SBC, etc.)
    by Jonathan Rosenberg
    see draft-ietf-sip-gruu-03.txt
    Slides presented and to be included in proceedings.

    Changes to previous doc reviewed. The redundancy issue has been
    declared out of scope, and discussion suggested that this should
    perhaps be placed into the Jennings "outbound" draft. The current
    model assumes that both "sip" and "sips" versions of a GRUU are
    created when a GRUU is, and that they route to the same resource. The
    URI scheme of the "To:" header is used to select the appropriate
    GRUU. It was suggested that this should be clarified in RFC 3261,
    perhaps as an errata.

    Several record-routing cases were discussed based on slides. There was
    inconclusive discussion of a scenario where the use of GRUU creates an
    undesirable "tromboning" effect back to the upstream entity after

    1) Open Issue: Discovering AoR from A GRUU

    Discussed issue about getting AOR from gruu - why this is/isn’t a
    need.  Objections were raised to the proposed compromise in the
    draft. Various other alternatives discussed. Cullen Jennings didn't
    see a compelling reason for it. Paul Kyzivat (who had raised the issue
    initially) said he no longer found this a need- solutions other than
    GRUU were sufficient. Aki Niemi and Orit Levin still expressed a
    desire for this feature. Dean, as chair, said we have no requirement
    for this, and a domain can do it anyway if it wants. Inconclusive
    discussion followed.

    2 )Open Issue: relationship of Identity to GRUU

    The relationship between these two elements was discussed without
    conclusion, although Jon Peterson (author of the Identity work)
    asserted an pinion that a GRUU and an identity are not the same thing.

    Topic: Non-Invite Transactions
    by  Robert Sparks
    see draft-sparks-sip-nit-future-01.txt
    Slides were presented and should be included in the proceedings.

    1) Proposed that we accept and refine Time left concept, and not define
    general "Try again later" behavior. This approach uses a new header
    indicating how much time the downstream element has left.  Adam roach
    argued that it was not a good idea - if we don't get any hints from
    proxies who are not aware of this extension, we will go round in
    circles.  Robert called for a hum on if this work should continue or
    not. The consensus was for neither the timeline nor the "try again
    later" work to continue.

    2) Proposed that we pursue address success and failure caching.  The
    goal is to allow next NIT to avoid non-responding address.  Question
    is how often to probe the non-responding address?  No concrete way.
    Jonathan Rosenberg proposed that we use Jenning's outbound I-D.  Cullen
    Jennings stated that this may work for UA - Proxy, but Proxy-Proxy may
    not quite work. Robert Sparks proposed that for now we carry a
    blacklist; put these addresses in a cache with a timeout (let the
    developer determine the timeout).  And we continue to pursue Cullen's
    outbound I-D as a possible better answer. Discussion followed. The
    conclusion was that for now we will use some weighted back to list
    algorithm that will be fleshed out on the mailing list.

    Topic: REFER Extensions
    by Orit Levin
    see draft-ietf-sip-refer-with-norefersub-01.txt
    Slides were presented that should be included in proceedings.

    Only one open issue remained for the draft since its WGLC. This was
    "How does a REFER-Issuer enable the feature?". Alternatives include:
    a) Commonly preceded by OPTIONS, b) supported header in the request,
    c) required header in the response, d) require header in the request.

    Discussion agreed that the Supported header is the wrong approach, as
    it indicates which features are supported by the sender, not required
    for the respondent.

    Discussion became prolonged, and the participants were moved to the
    hallway for a focused discussion. This discussion reached the
    following conclusion:

      1) Add a new header to be used with REFER request and the
          corresponding response
      2) Keep option tag
      3) Including this option tag in Require header is NOT RECOMMENDED.

    This conclusion was shared with the WG, and no objections were noted.

    The "hallway" conversation necessitated a slight juggling of the
    agenda, with Resource Priority being discussed during the hallway

    Topic SIP Resource Priority
    by James Polk
    See: draft-ietf-sip-resource-priority-06.txt
    Slides were presented and should be included in proceedings

    It was noted that this draft is just 2 weeks shy of its 5th
    anniversary, making it one of our longer-lived discussions. Changes
    since previous version were discussed. The plan of record is to submit
    and WGLC a revision of this draft with minor cleanup as proposed
    here. The authors requested: "For those who care, please approach us
    and let us know of any concerns.  If someone can read this as an
    innocent bystander and provide comments, please do".

    The chairs polled the room: "Does everyone who cares about this draft
    think their issue have essentially been met?" The consensus of the
    room was favorable and no issues were raised. It should be noted that
    Mike Pierce, a long time participant in this discussion, was not
    present as of this poll.

    Topic: Request Identity
    by Jon Peterson
    See: draft-ietf-sip-identity-04.txt
    Slides were presented and should be included in the proceedings.

    New open issues:

    1) Display name handling - should identity signature
    cover the display name?  All clients (MS Outlook,
    for instance) use the display name, and not the name-addr.

    Jonathan noted that this is usually a good thing; the service provider
    bears the burden of coming up with the display name and the client is
    provided a bit-by-bit rendering of the display name. Following
    discussion indicated a strong consensus to protect the display name if

    The consensus was to protect display name, and in the display name,
    just put quoted strings and prohibit LWS. In the security section of
    the draft there should be a discussion of the disadvantages of
    including display names (account minting a la Yahoo!)...)

    2) Applicability to REGISTER - why provide authentication info to a
    authentication server as well as to the registrar? Jonathan Rosenberg
    presented an acceptable use case, and the authors concluded that they
    would amend the draft to indicate the usability of Identity in
    REGISTER transactions.

    Topic: Response Identity
    by Jon Peterson

    No slides presented.

    Jon lead a discussion about the meaning and critical aspects of
    response identity.

    Jon says he has lost his way on this draft. The sip-identity work
    doesn't work for responses because of retargeting. Who do responses
    actually come from?  What are intermediaries allowed to do when
    routing SIP requests? How would a UAC make authentication decisions
    based on response identity?  Anyone can impersonate a requester, but
    impersonating a responder is a lot harder - need dialog identifiers,
    etc.  Improve channel security to make it even harder to impersonate a
    responder? Provide causal trace after-the-fact? Let UAC explore new
    targets for a request?  Assume bar is high enough for impersonators
    now? - what if the real responder tries to impersonate someone else?

    Jonathan Rosenberg said major threat is if someone fakes a connected
    party id, assuming we had that, and that such is a requirement. Rohan
    Mahy thought History-Info is the right solution and said he plans to
    write up something about it.

    Consensus: We're generally headed in the right direction but have a
    long way to go.

    Topic: Accept-Disposition
    by Gonzalo Camarillo
    See: draft-camarillo-sip-accept-disposition-00.txt
    Slides presented and should be included in proceedings

    open question: How do we say we don't understand content-disposition?
    Add Accept-Disposition (equivalent to Accept header)?  We have several
    ways to require support for something - method, option tag, body with
    handling=required. Want to pick one and clarify content disposition
    handling Combining two problems - Accept is used as hint about how you
    goofed. Isn't Warning closer to what we're getting at? Accept headers
    became useless because everyone Accept: * (everything). Don't we
    really want an explicit code that tells us what we want to know?  How
    to tell refusal from lack of comprehension?  What is scope of

    Conclusion: Rather than pursue this approach, for the application
    (exploder) that stimulated this draft there was a decision to use an
    option tag to negotiate support for the needed combination of

    Separately, there was interest by some (at least Gonzalo and Paul) in
    starting to investigate the underspecification of Content-Disposition.

    Tuesday, 1300-1500

    Agenda by Chairs Agenda accepted as proposed in slides. The proposed
    topic of "Connection Reuse" was withdrawn by author Rohan Mahy. If
    time allows, a discussion of retargeting led by Jon Peterson will be

    Topic: SIP Interaction Framework
    by  Jonathan Rosenberg
    See: draft-ietf-sipping-app-interaction-framework-04.txt
    Slides presented and should be included in proceedings

    The current state of the draft has raised a requirement for other work
    that Jonathan calls the "target dialog" approach and has fleshed
    out. Discussion of this approach ensued. Alan Johnston noted that an
    option tag is needed. Robert Sparks spoke in favor of the
    approach. Following discussion, the chairs polled the room and a
    consensus to proceed with this approach was reported. The chairs are
    instructed to work with the Area Director to add the target dialog
    draft to the working group charter.

    Topic; Management of Outbound Connections
    by Cullen Jennings
    See: draft-jennings-sipping-outbound-01.txt
    Slides were presented and should be included in proceedings

    Open issue: Do we need an option tag to know if registrar supports
    flow-id and if UA supports this.  Rohan argued against the option
    tag. Jonathan proposed that it would be needed it in the Require in
    the REGISTER.  Rohan countered that one could check in the response
    what it came back, and perhaps add a Contact header field parameter to
    discover if the functionality is supported by the registrar.  Alan H.
    noted that if the registrar does not support the functionality, you
    end up with a wrong binding that you have to fix later.

    After discussion, there were no sustained objections to adding an
    option tag, and a quick poll indicated consensus for this
    approach. Cullen agreed to make this change in the next revision.

    Topic: Using Certificates with SIP
    by Cullen Jennings
    see draft-ietf-sipping-certs-01.txt
    Slides were presented and should be included in proceedings

    1) Robert Sparks commented that the draft needs further text about
    caching certs, and checking certificate revocation.

    2) Jon Peterson suggested that we make sure to clarify subscription
    duration, which Cullen noted should not cache beyond validity time

    3) Rohan observed that we need to refresh the subscription even if the
    cert is still is valid, when there hasn't been a NOTIFY for some long
    period of time.

    4) Francois Audet noted issues with retargeting and forking. For
    example,the sales group example does not work properly. An other case
    is retargeting. Use case: the help desk. You don't care who is going
    to answer, but the requirement is the conversation to be
    encrypted. Cullen observed that the assumption of this draft is indeed
    that all devices for the ID have the same credentials. Jon Peterson
    suggested that RFC 3261 with SIPS resolves theses cases. Cullen
    observed that there are separate problems: a) to determine who the
    certificate belongs to, and b) acquiring the certs. This draft
    addresses only b.  It was resolved that the scope of the draft should
    be clarified, and that we should change the name to "credential
    management" instead of "certificate management".

    5) Jonathan asked:"What happens if I send a SUBSCRIBE for a GRUU? Do I
    get the cert for the AOR?" Cullen responded that the draft discusses
    users, not devices. Jon Peterson stated that this problem should be
    resolved in the identity draft, not here.

    Topic: End-to-middle security
    by Kumiko Ono
    see draft-ono-sipping-end2middle-security-04.txt
    Slides were presented and should be included in proceedings

    Chairs noted that they expect this work to migrate from SIPPING to SIP
    fairly soon, as has gone beyond the requirements consensus and into

    1) Open issue: Signatures inside, encryption outside or the other way

    Jon reported that we did some analysis about this when drafting RFC
    3261, and think the signature should go inside, the encryption
    outside.  Cullen believes that signature inside the encrypting part
    will give better security properties (from the security group).
    Catherine also stated that the crypto community thinks signature
    inside is generally better, although there are sometimes exceptions.

    Conclusion: consensus to have signature inside.

    2 )Open issue: How a proxy can tell a UA to disclose a body while
    protecting data integrity?

    Options include new error response, existing resp with warning header,
    or existing resp instruct UA one task at a time.

    James Polk asked if we could use CID and Reason header? Jon Peterson
    noted that CID is valid is the scope is a partial body of the
    multipart, but if you talk about the whole body, you don't need a CID.

    Dean asked: can the proxy request a body? Jon responded: if it is
    undecipherable, how can it point to one body? The proxy only knows the
    whole multipart body, not the individual parts. It is better to do it
    at the high level -- the proxy says I need to read this body, without
    indicating which one.

    Dean and Jonathan noted that Content-Disposition may also be applicable.

    No conclusion noted for this issue.

    Chairs Poll: This is a proposal for an implementation of the
    end-to-middle requirements established by SIPPING. Do we wish to adopt
    this as a working group item? A consensus in favor of adoption was
    reported, and the chairs are instructed to work with the D to get this
    item added to the SIP WG milestone list.

    Topic: Extension Negotiation
    by Volker Hilt
    See: draft-hilt-sip-ext-neg-00.txt

    Slides were presented and should be included in the proceedings.

    Discussion followed.

    Paul K noted that this aggregates on not being clear of what is the
    scope of what an Accept header is. Does it apply to OPTIONS?  Severe
    discussion about when to include or not the Accept header, in which
    methods.  Jonathan replied: There is not a not clear answer, but
    interoperability is maximized when you put everything you support in
    the header. OPTIONS carries a permanent scope: this is what I support.
    Gonzalo observed that, at the end of the day what we want to disclose
    is the desired Content-Disposition.  Dean also observed that RFC 3261
    scopes the Accept header to the duration of a dialog and that RFC 3264
    scopes the Accept header for the duration of a SUBSCRIBE dialog.

    Dean suggested that this would be a good time time to have guidelines
    for Accept headers. Cullen and Jonathan maintain that it is simpler to
    populate the Accept header with everything that is supported, even if
    this set becomes very large.

    Jonathan clarifies that the use case is when the server can provide an
    alternative extension in case the client does not support a given
    extension. The example: if the presence server knows that the client
    does not support RPID, then the server might put the contents of
    activity elements in note elements.

    Adam noted that there is currently no way for the server to determine
    that something is not supported at the client.

    There does not seem to be a clear path forward, and we should perhaps
    look more closely at use cases.

    Topic: Retargeting
    by Jon Peterson
    Slides presented and should be included in proceedings.

    Discussion followed.

    Rohan Mahy observed that sometimes an unanticipated respondent is a
    desirable outcome. And sometimes it isn't.

    Keith Drage proposed that response identity should be connected party

    Jon observed that the response identity problem is defined as the
    ability from the UAC to determine that the response came from an
    impersonator. Implementation of connected party is likely to occur
    security problems, and a UAC doing wrong authorizations.

    Jonathan suggested that we reduce the scope of the requirements to
    something that we can solve today. There are other harder problems
    that we can't solve today.

    Jon proposed that we need to solve the problem that ends up in SRTP,
    starting from SIP identity, SIP certs, Mikey, SRTP.

    Discussion of endpoint vs proxy trust followed, with the general
    consensus being that, at least to some extent, proxies must be
    trusted, because "the SIP proxy allocates you with a SIP URI and can
    take it out of you at any time".

    Jon proposed that we takes this work as an informational document in
    SIPPING discussing the kind of attacks.

    Jonathan noted that we need to update the SIPS behavior in SIP, there
    are a few open holes.

    Jon restated that the scope of this work is to detect that there has
    been a retargeting, not to prevent that retargeting to happen.

    No further conclusions were noted.

    The meeting of the SIP working group concluded on schedule.


    Status and Agenda
    NIT Futures
    REFER Extensions
    Resource priority
    Application Interaction
    SIP Outbound Connections
    SIP certificate Usage
    End to Middle
    Extension Negotiation
    Retargeting (from SIPPING)