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 PageNOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.
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: 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
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
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
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
Agenda modified to substitute discussion of body part modification
instead of resource priority..
Topic: Status of Working Group
Discussion led by chairs. Slides presented.
Discussion of Non-Invite Transaction Drafts: <>Consensus reported
that
two Non-Invite drafts are ready for WGLC:
draft-sparks-sip-nit-problems-01.txt and
draft-sparks-sip-nit-actions-01.txt.
The chairs are to arrange for WGLC.
"SIPPING 16": Proposed that the WG should prepare a document denying
that there is some set number of possible SIP features. Discussion
centered on whether or not this should be an RFC. Resolved: We will
sart with a draft and consider it as usual.
Topic: Content Indirection
Discussion led by Dean Willis acting as Editor. Slides presented.
Issue: Editor. Volunteers were requested to replace Seann Olson, who is
not able to contribute at this time. Eric Burger volunteered.
Issue: Do we need content expiration? Do we have to update RFC 2017 to
add it? Rough consensus seem to be to retain this function, as it
was present for WGLC and IETF LC. The document editor is to discuss the
addition on the ietf-types mailing list and determine whether a change
to RFC 2017 is needed.
Issue: Hash format. Consensus that the hash parameter should be named,
as per "hash-sha1". The hash value shall be wrapped in double quotes.
The editor is tasked with reviewing the hash parameter on the
ietf-types list.
Issue: Partial rejection of content. Noted that some RFC (3359?) allows
rejecting non-critical content. The editor is directed to clarify this
in the text, potentially discarding confusing section 5.10 text .
Topic: Body Part Modification by Proxies
Discussion led by Rohan Mahy as Author. Slides presented.
Background of problem presented along with use cases and a variety of
topologies including triangle, trapezoid, and local as well as foreign
piggybacking.
Discussion was heated and active. This is clearly a controversial topic.
Notable points from the discussion:
This is related to the policy discussion.
Modification of bodies has a significant impact on the security
model, and seems to require that S/MIME be applied on a per-part basis
rather than per-message basis.
Having individual body parts signed by different entities is
problemactic.
Any solution is going to have to address a large number of uses
cases.
Discussion will continue, with no consensus recorded at this time.
Topic: Connection Reuse
Discussion led by Rohan Mahy as Author. Slides presented.
The main issue seems to be around identifying a specific connection in
a manner suitable for use as a reference. The URI doesn't provide
adequate context, except in the case of a GRUU which is instantiated by
the element using the reference.
Discussion will continue, with no consensus recorded at this time.
Topic: Authenticated Identity
Discussion led by Jon Peterson as Author. Slides presented.
Issue: Retargeting vs. Redirection. The proposed approach effectively
denigrates retargeting in cases where identify functions are performed
by the retargeting element. Noted that this isn't all bad --
redirection offers a majority of the capabilities needed, without the
problems introduced by retargeting including response identity,
multiple forking response resolution, and so on. However, it does NOT
provide some of the benefits, including proxy control,
proxy-facilitated NAT traversal (especially with connection-reuse), and
privacy control.
Does non-local retargeting go away so we can get identity? Don’t want
security property downgrading – more choices allow more downgrading. If
identity is critical, we’ve got to go there – not with a flag day, but
we’ve got to go there.
Specific aspects discussed include:
Does this contradict caller preferences? Jonathan thinks “no”.
This doesn’t mess up request-history (after thinking about it a
while).
Do all the applications work? Extra RTTs are OK, although they'll
chafe the wireless community.
Need to make requirements so we can make sure we meet them.
Cost-benefit from a speed perspective is subtle (and probably
small as well). Almost all forwards are local forwards, and almost all
phone calls have local forwards today.
“The main thing is to make sure this actually works in a
practical sense, and I’m not there yet.”
RFC 3261 limits recursion – but was this text ever coherent?
Would we clarify this text?
This probably will slow down call setup in wireless domains, but
it’s not unreasonable for retargeted calls to be slower. SIGCOMP helps
here, too.
RFC 3261 is pretty clear on who can muck with Request-URI – this
should work.
It was observed that few participants in the room displayed confidence
in their understanding of the problem or the proposal, and that further
study would be a Good Thing.
Topic: GRUU
Discussion led by Jonathan Rosenberg asAuthor. Slides presented.
Issue: URN Equality. Consensus indicated to use lexical equality
where a specific quality function for a URN is not specified and known
to the element.
Issue: Ramp-up problem. The current text requires that registrars
refuse registrations resulting in a conflict, after which restarting
devices that caused the conflict can remove the old registration before
trying to re-register. This reduces the capacity during a restart by a
factor of four over simply overwriting the old registration. Proposals
include overriding the old registration, or keeping both contacts.
Several alternatives and issues were discussed, with key comments
including.
Question: Does having two registrations for same instance violate
a critical GRUU property?
Worry: Keeping both might contribute to another avalanche restart
problem, and is more complicated<>
<>Preference: (Paul K). prefers overriding
oldregistration.Comment
(Rosenberg) - Ok to have multiple routes/connections for an instance,
so #1 above is "no".
<>
Question: (Rohan) Could we use a flag or special response
code to tell the registering mobile than an existing instance has been
overridden and that something odd must have happened?
Worry: Multiple contacts with the same instance id
complicates the way proxies handle certain errors. Complicates a lot
of things.
<>
Comment: (Sparks) - Sounds familiar with Etag and
XCAP.
No consensus observed on the ramp-up issue.
Session Two, Thursday, August 5 1300-1500
Topic: SIP MIB
Discussion led by Rohan Mahy as Chair.
Proposals to close 3 of the 4 known open issues were made on the list.
One issue remains. Rohan propsoes that the MIB functions related to
configuring SIP UAs be deleted, as we have a seperate UA configuration
framework. Some elemenst would remain, but as read-only. The group
indicated a consensus to proceed with this approach.
New issue raised: We added an application index to all these tables.
The problem is to define application name may end up in the same name
repeated. Is this legal? The problem is that the same application is an
instance of the same application. RFC 2788 seems to say one entry per
application. The MIB spec is restricted in the name. A suffix to the
application name may solve the issue, although this point is not
agreed. Follow up on the list.
Topic: The History of History and Voicemail, A Diatribe by Cullen
Jennings
Discussion led by Cullen Jennings as Amicus Curae, with slides
presented.
Two solutions for users with voice mail.
1. History: proxies retarget include information
about where and why they retargeted.
2. Voicemail uri: proxies figure out what services
they want voicemail to provide and tell the voicemail the voicemail to
do that
Slides: A long list of drafts that request this issue.
Slides: reviewed the history of changes in voicemail-uri.
Proposal: The possibility of using both: Cullen indicates that both
seem to be needed and not mutually exclusive..
Recommendation: chose something now: History, URI, Both. The
recommendation is to use both, since the do different things and they
work together.
Rohan, as chair: We are already doing History. So the question is: we
do History alone or we do History AND URI.
Poll: Anyone implementing voicemail URI? No answers.
Suggestion by Dean as Chair: to take voicemail URI as an individual
submission heading to informational RFC, and proceed with History as
planned in the working group. There seemed to be general consensus to
proceed with thsi approach.
Topic: Request History
Discussion led by Mary Barnes as Author. Slides presented.
Mary goes through the changes from -02 (see slides)
Issue: Section 4.1 has normative statements that appear to overlap with
the normative ABNF. Resolved that the author will make the text
explicative rathen than using requirements language therein.
Broader review is now desirable. The author feels that the document is
ready for WGLC, and there seems to be a consensus in the room to
proceed with last call.
Mary presents an analysis of History-Info vs robust security:
comparison with draft-ietf-sip-identity-02 and
draft-ietf-mahy-sipping-add-body (see slides).
Mary also presents an analysis of History-Info versus Privacy.
Discussion ensued, with key lements being:
Jon: People are much confortable with the request portion than
with the response portion in the request identity draft. Suggest to
split<>the request-identity in two drafts. Considering to work on
two optionsfor request-history as well, since they are
incompatible.<>Rohan:
transition mechanism that the P-Asserted-Identity to thegeneral
internet.
Jon: the request identity draft just says that a proxy
cannot add a body.<>Keith: we need to solve the ientity stuff
before
the history, not the other way round.<>
Rohan: is is sufficient to say in history-info that a proxy
that retargets to a non-local then it should redirect. This will
work. Other mechanisms may be specified later. If a proxy want to
convey history-info securily, then you can redirect to TLS.
Rohan is to send text to Mary as per above.
Topic: Connected Party -- who am I talking to?
Discussion led by Cullen Jennings as Author. Slides presented.
Problem description in the slides. Possible solutions:
1) update of state in the dialog;
2) transfer to a new user.
Noted that 1) has two
subsolutions:
1a) Update To or From, although is not compatible to 2543.
1b) update with a new header, body, AIB, etc. Compatible with 2543, but
a 2543 phone will not update its display.
Jonathan: With respect to 1A, I hope people are not using To and
From as the primary source of information for the user.
Rohan: WRT solution 1a and 2543. A 2543 implementation will
return 481. To and From are useless today.
Andrew: don't depend on To and From headers, the UA will not use
them.
Jon: email contains From and To headers, and they are useful and
intuitive. They can be forged, and that's why we need identity, and
this is approach taken by identity, making them meaningful. it requires
a lot of motivation to make the to/from header less meaningful.
Jiri: In forwarding scenarios across different domains, there is
not traces of the original sender.
Keith: the problem is reusing a header for different usage. This
is the problem why we end up with so many identities.
Rohan: the semantics of from/to: To is a semantics of to which
you address the dialog. Cullen suggests the semantics of to who you are
communicating. The identity work addresses part of this correlation.
Rohan: if we go with 1a and do not change the To header, someone
has to change a bunch of stuff in Section 26 of 3261 to indicate how to
do things now with S/MIME.
Hisham: ok to change To/From, if you authenticate the user you
don't authenticate the To/From. If I want to change my name, I can
re-INVITE to change my From.
Cullen: sort of agree with Hisham. right now we don't have a
mechanism to change the name. Solution 2 is about INVITE/Replaces, not
about REFER.
Jonathan: Think about the way many people visualize billing
systems toay -- the billing system charges the user on INVITE and
BYE. This is wrong. The billing system should take information about
"what happens" during the call, and figure out that information when
the call started/ stopped.
Jonathan: don't understand the serious security issues (see
slide, solution 2).
Rohan: replaces has requirements for authorization of the
replacement,and the way to do it is to look at the Referred-By header
and correlated.
Jonathan: a solution: GRUU + cryptographicly random grids
Chair: I think I sense a developing consensus to look at the
cryptographic technics of the GRUU and the dialog usage. Poll of the
room about the possible solutions: Room prefers support for Replaces
with GRUU and cryptographic randoms (solution 2). If that does not
work, then try a new header (solution 1b).
Topic: SIP State Update
Discussion led by John Elwell as Author. Slides presented.
Proposed: Treat the contents as clarifications to existing RFCs as bug
fixes and add similar clarifications to authid-body and future drafts.
Discussion: How does this related to the previous presentation. Do we
need to put this on hold until we resolve the previous proposal?
Chair proposal: Bring the list of bugs, one at a time, to the mailing
list, so we can get attention focused on each and work through it.
Topic: Making S/MIME Work With Certs
Discussion led by Cullen Jennings as Author, with slides presented
Issue: Fetching credentials: options are
use notification
use
config framework
use https
Discussion follows.
Several points were raised.
The trick to make this deployable is to have one certificate
per domain instead of a certificate per user.
Tieing the lifetime of the certificate with the lifetime of the
subscription solves a bunch of problems.
Using HTTS to fetch a certificate could avoid a bunch of SIP
messages.
Jonathan: we can do this with zero call setup delay. buddylist
provides a context to get certificate from my buddy. You can add a flag
to a presence document "hasCert".
Rohan: if I received a signed message from someone I don't have a
certificate, for then HTTPS is better. From deployment perspective
it's easier.
Jonathan: this is easier to deploy with SIP. In which way the is
the HTTP solution superior to the SIP solution?
Maintaining a large number of subscriptions is server side state.
The
HTTP solution has no server side state. However, we already have the
subscriptions for the buddy list.
The subscription solution offers immediate notification of
certificate revocation. However, the short subscription timer in
certificates cannot be used, since
it is
expensive to generate certificates.
Note that fetching the cert does not require TLS -- certs can be
sent safely via plain HTTP.
If HTTP is used, how does
one compute the HTTP URI? SRV may already solve the problem.
Further discussion deferred to list.
Chair: we have a lot of dependencies on making S/MIME to work. There
is strong consensus to make this work. Proposed to make this a WG
item. Poll to the room indicates strong consensus to adopt this as WG
item. Chairs are to work this out with the ADs.
Topic: How offer/answer interacts with multipart/alternative in SIP
Discussion led by Cullen Jennings, with slides presented.
The problem of first trying a secure call and then the insecure, is
that the secure call is prioritized (e.g, if the voicemail implements
secure, S/MIME, SRTP, the voicemail will always answer).
Proposed Solution: Content-ID in each multipart entity in the offer and
a Content-Reference in the answer.
AD: This is probably in the scope of the MIME WG.
Issue: do we need a Require header. Proposal: yes
Jonathan: weak feeling. If I do SRTP I need to encrypt the SDP. Better
to start with the problem statement. The problem: I cannot use SRTP
because it is a backward compatibility problem.
Cullen: the solution to the bid down attack is the auth body and
encrypt everything.
Jonathan: there is two problem statements. Another problem is due to
the consequences of sending secured multipart, the nonencrypting UA
will reject.
Dean: problem 1) how to find out if the other party can do SRTP or
not. Solution: multipart. Alternative: send an offer encrypted, if
rejected, send offer unencrypted, but what happens with forking.
Jean Francois: the number of alternatives is big (encrypted voice,
non-encrypted audio type of things). This may increase complexity and
size of the multipart.
Dave: Should it be possible to accept the session but reject the
offer. Get a 200 OK, but sending something that "I want to establish
the session, but there is something in the SDP that I don't
understand".
Hisham: yes, you can reject everyhig in the answer
Hisham: Can you offer both RTP and SRTP as options?
Cullen: the problem is tha tif you do SRTP you need to encrypt.
Aki: about the tag, inspire in the security agreement.
Jonathan: may need to look at preconditions as a solution.
Rohan: backwards compatibility is an issue, so preconditions does not
help.
Discussion is deferred to the list
Using SAML for SIP -- Hannes Tschofenig
draft-tschofenig-sip-saml-00.txt
Hannes goes through the slides. No comments.
Chair To-Do List
WGLC draft-sparks-nit-problems
WGLC draft-sparks-nit-actions
Work with MIB team to delete UA configuration.
Rohan to send text to Mary clarifying that proxy retargeting to a
non-local destination will redirect instead. When this is incorporated
into request-history-mech, the draft will be WGLCed.
