Current Meeting Report
2.8.18 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 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.
Last Modifield: 07/03/2002
J. Ott <email@example.com>
Brian Rosen <firstname.lastname@example.org>
Dean Willis <email@example.com>
Transport Area Director(s):
Scott Bradner <firstname.lastname@example.org>
A. Mankin <email@example.com>
Transport Area Advisor:
A. 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. natfriend: Extensions for making SIP a NAT-friendly protocol.
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|| ||SIP extensions for media authorization (call-auth)
submitted as Informational |
|Done|| ||The UPDATE Method submitted for Proposed Standard |
|Done|| ||Preconditions extensions (manyfolks) spec to IESG |
|Done|| ||SIP Privacy specification to IESG |
|Done|| ||SIP Privacy and Security Requirements to IESG |
|JUL 02|| ||The Replaces Header submitted for Proposed Standard |
|JUL 02|| ||The MESSAGE Method submitted for Proposed Standard |
|JUL 02|| ||Refer spec to IESG |
|JUL 02|| ||Caller preferences specification submitted to IESG |
|JUL 02|| ||Session Timer spec, revised to IESG |
|AUG 02|| ||Guidelines for Authors of SIP extensions submitted as
|AUG 02|| ||SIP NAT extension submitted to IESG |
|SEP 02|| ||SIP over SCTP specification and applicability statement |
|OCT 02|| ||MIB spec to IESG |
|NOV 02|| ||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|
|RFC3265|| PS ||SIP-Specific Event Notification|
|RFC3262|| PS ||Reliability of Provisional Responses in SIP|
|RFC3263|| PS ||SIP: Locating SIP Servers|
Current Meeting Report
SIP WG Meeting at the 54th IETF
Minutes by Joerg Ott (firstname.lastname@example.org)
Notes by Renee Cohen, Vijay Gurbani, and Joerg Ott.
The SIP Working Group met twice at the 54th IETF; the sessions were chaired Dean Willis, Brian Rosen, and Joerg Ott.
Agenda Bashing and Status Uppdate (Chairs)
The meeting agenda was accepted; the only minor change was that the discussion of MIME types was postponed from the first to the second session, pending input from the ADs.
A brief overview of the status of the drafts was given, noting that the most important ones are published and quite a few had been finalized (see overview slide from Rohan Mahy) and several ones are moving ahead in the process. One draft, defining the REFER method, had issues found during last call and went back to WG item status (as discussed below).
REFER: Open Issues (Robert Sparks)
The draft on the REFER method lacked clean documentation on how to use SIP events. A separate document was created (draft-sparks-sip-refer-3265disc-00.txt) that suggests clarifying wording and also defines a mechanism to signal whether or not an implicit subscriptions on reception of a REFER have been created. A poll on the list, however, showed that no one has actually implemented optional subscriptions and hence this mechanism is not needed. It has been agreed to make implicit subscriptions mandatory; a new revision of the REFER draft (-06) will be issued this week including the clarifying text and reflecting the list agreement. The AD (Allison Mankin) remarked that this change will not require another IETF Last Call; as no one saw a need for another WG Last Call was, the document will be send to the IESG queue where it left off when the issues were encountered.
As another change the REFER draft was split into two parts after the SIP interim meeting, factoring out the Referred-By: header (which had strong security issues that were not resolved in the original document). The Referred-By draft now makes use of the S/MIME mechanism. So far, there has been only very little discussion on the list and no issues have come up that would warrent discussion at the meeting. People are encouraged to review the draft.
MESSAGE: Open Issues (Ben Campbell)
The MESSAGE draft is currently in IETF Last Call and is waiting for IESG feedback. Minor changes have been made so far in response to feedback.
The major issue of this draft is congestion control. Quite some concern has been raised about the artificial message size limit. The updated draft provides compromise wording for this: while specifying a size limit, it also states that this may be exceeded if the sender is sure that all links on the path are congestion-safe. The draft does not specify how a UAC determines that this condition is satisfied. A new draft on SIP and congestion control (discussed later in this session) addresses this issue.
Furthermore, the use of the Expires: header has been clarified: it is now suggested that a value of 0 shall indicate that immediate delivery is requested. Delta-time stamps (from the Date: header, if present, or time of reception, otherwise) are provided for as absolute times. If an Expires: header is present, a Date: header should also be provided. Treatment of expired messages is up to the local policy at the UAS.
Finally, it has been suggested that UACs "MUST" register with the parameter methods="MESSAGE", which is currently a SHOULD. Discussion has shown that people are in favor of leaving this a "SHOULD" (as with all other methods) as is written in the current draft. It was agreed to keep the "SHOULD".
Caller Preferences Open Issues (Jonathan Rosenberg)
The caller preferences work has been around for quite some time and has experienced little use in the past. The latest update of the draft makes use of RFC 2533, with significant simplifications though to keep caller preferences simple and straightforward to implement: the the general idea is used, the allowable input is significantly restricted, however, and the syntax is kept backward compatible. In particular, only a conjunctive normal form is needed, i.e. a disjunction with each term being expressed as a conjunction of feature tags. Computing the interscetion between two such terms can be done linearly without the complexity that comes with the full RFC 2533 algorithm. Note also that RFC 2533 is used only internally: the syntax on the wire has not been changed but the internal processing rules have, to comply with the simplified version of RFC 2533.
A number of semantics changes have also been made: firstly, RFC 2533 already supports MIME types, but differently from how caller preferences have been using it before. The "type" tag as already registered by RFC 2533 allows only complete MIME types, no wildcards as were used before. Therefore, two tags are now used by caller preferences: the "type" tag as per RFC 2533 and an additional "media" tag carrying top level types for alignment with existing tags. Note that this breaks backwards compatibility here. A Boolean "automata" tag has been added to indicate e.g. voice mail server, robots, etc. and an "events" tag to indicate support for RFC 3265 event types. There have also been some changes in priority matching rules: multiple ones can be specified and Accept-Contact: header allows for explicitly asking for a certain priority. The weighing parameter Q now needs to be the last parameter amongst the Accept/Reject-Contact header values.
New is also the way of explicitly specifying preferences: previously, methods and priority information were handled differently from other preferences; while the latter were explicitly specified, the former were inferred from the request method and the priority header. The revised version of the draft allows to also specify those explicitly. The implicit variant is still supported but is overridden by the explicit one.
Further changes include a significantly restricted URI matching: either user and host are matched or just the host. In all cases, URI parameters are now ignored. Also, the feature sets that can be present in Accept-Contact: (INVITE) and Contact: (REGISTER) headers have been unified and are now able to express exactly the same information. Finally, the "&" construct has been removed for a single tag as each tag represents one axis in an n-dimensional space; the feature collection is represented as a point in this n-dimensional space and there must not be more than one value on the same axis; hence, the "&" construct does not make sense here. During the discussion, the need was identified to express more than one value for some given tags (e.g. audio, video for media) and hence those cannot be part of the same dimension. It was suggested to use a Boolean tag for each media type instead (e.g. audio=yes, video=yes) so that independent dimensions are created. As this approach was agreed, the issue was raised how to manage the resulting name space: for each new MIME type, a new tag would need to be registered and name clashes may come up. Proxies do not have to be aware of registered values; they just process "tag=value" pairs, regardless of whether or not "tag" or "value" are registered. Therefore, this was deemed a minor problem that should be dealt with when real (rather than theoretical) issues arise. For now, some clarifying statement regarding the modified use of the tags will be included in the next revision of the draft.
Finally, two open issues were discussed: When used in the Contact: header within an INVITE transaction to declare one's own features, various parameters overlap with SIP headers (e.g. methods and Allow:, Events: and Allow-Events:, etc.). This can be resolved in numerous ways: (1) allow both and define one to take precedence over the other, (2) forbid caller preferences from using parameters that are also present through headers, and (3) disallow the use of caller preferences in INVITE/200. The proposal to choose (1) with headers taking priority was accepted.
The other issue refers to extensions to parameters that result from work other than caller preferences: there is no way to indicate that a certain Contact: parameters actually belongs to caller preferences as opposed to being some other extension. Discussion has shown that it actually does not matter: unless the same parameter is present in both the calling and the called entity's Contact: parameters, they will simply be ignored. This is found to also address the issue of the earlier discussion on naming and registration of tags. The revised draft will state this as an issue but will also point out that it does not really matter.
At least one more revision of the draft will be needed, taking into account discussions during this meeting as well as feedback received by mail.
SIP NAT Open Issues (Jonathan Rosenberg)
The previous version of the draft addressed two different problems: (1) receiving responses through a NAT ("rport" parameter) and (2) receiving requests through a NAT (Translate: header in REGISTER). The Translate: header had various issues: for UDP, frequent re-registrations are required; it introduces NAT-specific parameters; and it duplicates STUN. The revised draft is scoped to do exactly what is needed to make SIP work with STUN, SPAN, and TURN -- no more, no less. As a result, only the "rport" parameter remains as, without this, STUN would not work. In the long run, TCP (or better: TLS) is the right answer and, in this case, only the registration problem needs to be solved. A point was made that MMUSIC was already dealing with such efforts but Jonathan responded that the MMUSIC work affected the SDP and thus the media streams; the work he presented here was purely for SIP. Some discussion arose around encouraging people to move to IPv6 (as opposed to applying fixes to "evil" IPv4 equipment such as NATs). The point was made, however, that the SIP NAT has actually broader applicability and does not just deal with NATs. This will be reflected in a renaming of the draft in the next revision, then again as a -00 draft. The document is now rather short and cleaned up; WG Last Call will be issued soon.
Session Timer (Brian Rosen)
No one in the group had any issue with session timer.
Digest Authentication Enhancement Open Issues (James Undery)
Current authentication for SIP is essentially based upon RFC 2617: it is deployed today, it is simple, and works for UAC-to-UAS as well as for UAC-to-proxy. The last revision of the authentication enhancement draft was perceived by far too complex so quite some complexity was taken out and only a few core items remain: fixes to authentication, bid-down protection, and header integrity protection. A "realm" parameter was added to Authentication-Info: and a generic extension mechanism was included in case future authentication algorithms would need different parameters from those required by digest authentication. To counteract bid-down attacks, the proposed algorithms and the "qop" parameter are included in the nonce. To provide header integrity protection, a message/sipfrag may be included in the body.
The only open issue raised was on the acceptance of this work in general: do people find this extension too much or do they want it. Numerous people strongly supported the idea; in particular, the work was viewed as urgently needed: it should be progressed quickly or halted (to pursue some other approach) -- but not hang around endlessly. S/MIME was brought up as desirable but others stated that, particular with small devices, not too many of them will be doing S/MIME (just for the purpose of registration). Hence a simpler way is needed. Basically, S/MIME can be shrunk or digest can be extended. For the former, however, there had been no proposals so far. So this draft may be the right way ahead. Other comments were made to provide more detail on bidding down attacks and possibly make recommendations which algorithms (not) to use. Another comment raised that digest itself is insecure and should not be used at all. James indicated that the algorithm he proposed was not specific to digest; if the two ends decide to use digest they know that they took a concious decision without interference from a man-in-the-middle.
The chairs concluded that they'll have a discussion with their security advisors on this and try to move this work along.
SIP Congestion Safety (Dean Willis)
Dean presented the general problem background on SIP and congestion control. SIP allows for UDP and TCP/SCTP as transport protocols. The use of UDP brings along a number of problems. With TCP and SCTP, multiple transactions may share the same transport connection including their retransmission timers. For UDP, however, SIP defines retransmission timers with exponential backoff on a per transaction basis. Using UDP, a node may be involved in a number of independent transactions at the same time, without having those transactions share the congestion state (timers, etc.) with each other. No standard way is defined to adapt (re)transmission behavior across multiple independent transactions to changing network conditions. Proxies may even change the transport to UDP, so the originating UA has no knowledge whether or not TCP or SCTP will be used all the way. A similar problem exists if the proxies do not re-use TCP connections but rather open up new ones for new transactions (but for TCP, connection re-use is at least being defined to deal with this problem). Another issue with UDP are large SIP messages: if messages get larger than the MTU size, IP fragmentation will result in sequences of fragments with no inter-fragment rate limiting. RFC 3261 "solves" the problem by imposing an artificial upper limit of 1300 bytes on a message sent by a UA if the messages may ever traverse a non-congestion controlled link. As transport may be changed by proxies, UAs should essentially never send messages larger than 1300 bytes -- but messages of larger size will be required, e.g. because of S/MIME, MESSAGE bodies, etc. RFC 3261 does not provide a solution -- unless networks are engineered in a way that only TCP is used between proxies. Some backwards compatibility issues are raised indicating that one may be required to use UDP (which is countered stating that even RFC 2543 need to support TCP).
Dean further presented traffic models to outline the problem; this part provoked quite some discussion on suitability of the model presented and how much it represented actual traffic on the Internet. It was also questioned that TCP-style congestion control could be applied to all kinds of traffic in the Internet. The discussion continued for quite some time before being brushed away by the AD (Allison Mankin) aksing people to focus again on SIP congestion issues rather than engaging in general debates on congestion control. As a valid point remaining from the discussion, it was also noted that the first traffic model did not actually compare UDP to TCP but rather a single "connection" to a number of independent parallel "connections". But this was addressed by Dean anyway in his "Corrected Scenario".
After this background discussion, Dean discussed the contents of the draft itself: it essentially defines the congestion problem and congestion-safe behavior by making a couple recommendations: it states a strong preference for TCP/SCTP over UDP and disallows two concurrent transactions in the same direction between any two nodes (which essentially enforces a 2*RTT rate lock step rate limiting). It also sets out to define mechanisms that allow UAs to determine that their requests will be handled in a congestion-safe manner. An issue was brought up whether this would also apply to traffic which is not best-effort but somehow treated preferentially; since in essence, one cannot know what kinds of lower layer services to expect, the same behavior as for best-effort is expected. Just using TCP, however, is not enough: TCP with connection re-use is what is needed; this was reinforced several times. It was also pointed out that proxies must be able to restrict the overall traffic they transmit: in case they talk to 500 other proxies with bits of traffic sent to each of these, this will gain very little in terms of congestion control, unless the proxies consider all the traffic it is sending to the network. The congestion-safety framework should not preclude this. Another speaker felt the draft was talking too little about considerations for big messages and the implications for that. As something like that was intended to be in there, further text will be provided.
In addition, proxies could be enabled to reject large requests in case they know the following path is not congestion-safe, thereby asking the client to send smaller pieces and pace itself. In response, it was pointed out that it's not just the request, however: the response has far less choices of which ways to take and there is no way to signal to its sender that it is too big.
Dean also outlined two simplifications that have been proposed: the use of UDP could be restricted to the link between a wireless UA and its edge proxy (3G scenario). In SIP, however, there is no way to determine up front whether the next hop is going to be a proxy or a UA; hence this would need to be ensured by network design. Also, it has been proposed to deprecate UDP entirely from being used in the SIP spec (which, of course, bears a huge backwards compatibility issue). Dean does not believe it can be simplified to either or the too but he is willing to undertake the effort if there is strong support.
Another issue to discuss (and there has been quite some controversy among the draft authors) is when congestion-safe behavior should be followed by proxies: always or only if the UA explicitly "requires" it. The former would greatly reduce the UDP throughput, while the latter would prevent non-upgraded endpoints from flooding the network with packets. This is an open issue. A strong position was taken to make congestion control a top priority in the WG. This work should not be seen as an extension to SIP but rather as a task migrate from existing behavior to something new. And this new behavior should then be applied all the time. There will be some time before SIP goes to draft standard (1.5 - 2 years) and this time can be used to upgrade all the SIP elements (UAs that do only UDP, proxies that are not congestion-safe) to match this new behavior; hence there is sufficient time for everyone to adapt. The approach must be backwards compatible but, as the proxies already are required to support TCP, new elements can just replace old ones piece by piece. Strong support was expressed that this behavior should be exercised all the time. There may not be all the right mechanisms at hand now but the group is definitly on the right track. While TCP may sometimes increase load for few and small messages, small messages will go away and so will the possibility to use UDP all. It was emphasized again that in the mid-term UDP should go away.
Some minor implementation issues were discussed regarding TCP fan outs from UAs and proxies. It was established that practice has proven that large-scale fan-outs can be done.
A mechanism to indicate that congestion-safe treatment is required. While only a Require: header is present in the current draft, a Proxy-Require: header is needed as well.
The final question raised was whether the mechanisms just outlined and discussed are strong enough to ensure reasonably good behavior of SIP proxies and UAs. The general feeling seems to be: yes. Some work on the rules and mechanisms is still required.
With ten minutes agenda time left, an open mike session was started which, after a brief discussion on WG items, again took up the issue of congestion control. The group agreed to make congestion control a WG item. Some further discussion emerged with the point being made that just using TCP would, by the nature of the traffic, not solve the congestion problem as a whole (one needs to do more). Also, it's not just congestion control why one would want to use TCP in the first place but security: from making it more complicated to inject packets to being able to fully secury connections. As for congestion, traffic peaks in proxies also need to be dealt with -- by using the mechanisms available today in SIP. Another issue: there may be messages the size of which cannot be reduced in case a proxy rejects them; in this case, a different route may need to be used. Mechanisms may be needed that allow a proxy to reject a request indicating that a different transport should be used. It was also pointed out that TCP keep-alives need to be turned off as they would cause too much traffic otherwise.
The second session started with a modification in the agenda: the discussion of a draft on SIP-ISUP mapping which had been left over from the SIPPING meeting on the previous day was added right in the beginning.
Beforehand, a the enormous achievements of the editors and ADs involved in making the huge task of RFC 3261 happen were recognized with a big applause. Following this, it was agreed to publish the changes between bis-09 and RFC 3261 rather quickly and a process for logging and collecting bugs in RFC 3261 was outlined. The plan is to go to draft standard after some time and the logging procedure shall help to ensure that all issues encountered in the past are actually rolled in.
SIP-ISUP Mapping (John Elwell)
This draft originates from ECMA (European Computer Manufacturer Association) who have developed QSIG. QSIG is a standard for interconnecting PBXes in private networks. The QSIG-SIP interworking draft is intended to enable integration of traditional telephony and SIP-based VoIP within an enterprise and thus allow a smooth evolution of enterprise networks from QSIG to SIP. The draft specifies a mapping from QSIG to SIP and vice versa; it does not handle encapsulation. The draft complements the work on SIP to ISUP mapping.
The following issues were identified: Q.850 cause mapping is not yet entirely done; there are still differences compared to the ISUP draft but those should be compatible. Work has progressed during the IETF week and there will eventually be a line cause mapping. Another issue is overlap sending; the QSIG work is technically in line with the ISUP work but, since the other draft is written using ISUP terms, the text could not just be referenced but needed to be adapted. A final issue is whether or not ISDN (DSS1) interworking should be specified in the draft. Because of numerous (partially large) differences between QSIG and ISDN and numerous scenarios that could be/would need to be specified, it is suggested to keep this work entirely separate.
A comment was raised that the draft should include extra functionality as well and not restrict itself to addressing the basic call scenario. John responded that, as basic calls are a prerequisite for the rest, this should be addressed first. The rest should follow in later RFCs. Another commenter pointed out that MIME encapsulation for QSIG is specified separately and can just be used. It was found that the draft seems to take the right direction and commenters agreed with keeping DSS1 mapping separate.
The work should move ahead but, as the charter is currently pretty full, it should take one more round as individual draft before becoming a SIPPING WG item (aimed at PS). The way ahead for the draft will be discussed on the mailing list; the WG chairs will consult with their ADs beforehand.
Identity open issues (Jon Peterson)
The SIP privacy and network asserted identity have passed IESG and are thus finished: in just six weeks from a -00 draft to RFC, some kind of a record. A comment was made that this pace was only possible because many comments were ignored. However, the presenter claimed that the concerns were addressed and debated on the list in length and this should not be repeated right now. The chairs pointed out that rough consensus is good enough for the IETF, unanimity is not needed; so this work is done and one should move on.
The next draft discussed addresses SIP identity in the long term, moving away from the closed trust domain model required to assert and verify the identity as it has been developed for 3G needs. This work is already a WG item even though it has been submitted as an individual contribution once more this time. The revised draft incorporates numerous comments received on the initial version, some of which are significant open issues as discussed in the following.
The first major open issue is how to identify the authentication service in a given administrative domain as the hostname convention used in -00 has been removed and was not replaced by something else. This leaves open who -- i.e. which (single) entity in a domain -- is responsible for asserting an identity and thus can be verified by recipients of the asserted identity. Related to this is what information about the authentication service can be derived from knowing this entity: is it *the* host responsible for the entire domain (e.g. yahoo.com) or just *one* host within this domain (e.g. xyz.yahoo.com); this may have an impact on how trustworthy the asserted identity is to the receiver. Discussion came up that this depended on what the asserted identity and the knowledge about the asserting entity should be used for. One might not care which host actually did the signing/assertion (hosts may change daily anyway) as long as the signature was ok and one could verify it came from the right party. In essence, a UA should be able to express/restrict who is supposed and/or allowed to sign the asserted identity so that the right representative is chosen. This requires a naming convention of some sort but that name should/need not be a host name. It would be nice if the receiver could, by some convention, determine which is the privileged entity for a given domain without the need for any pre-arrangements; this is the property sought (which got lost by removing the host name convention). It was also noted, however, that the asserting identity need not be part of the same domain and hence such (host) naming convention might not even make sense. The necessary feature could, as was recommended by some security folks, be attached as new certificate properties; involving new certificate characteristics and certification authorities, such an approach was felt to take a while to be realized and hence impractical for the shorter term. The discussion concluded in recognizing that the entire problem may not be that well understood at this point in time and further experience will be required. As a consequence, the group may not want to say anything specific right now; but the desire was expressed to do better than this and continue to try to find some solution here.
Another issue was whether to include and thus sign the entire SIP message or just parts of it -- the basic question of how many headers need to be signed. The solution right now in the draft is to allow for both message/sip as well as message/sipfrag as MIME contents to be signed. At least three headers are required, more are allowed.
Finally, the privacy pieces of the draft were aligned with the short-term network asserted identity draft to get unified behavior.
There is other minor stuff to be done. Work is continuing.
BINDing URIs to SIP AORs (Henning Schulzrinne)
This new draft addresses the issue of associating data intended for or carried in an external protocol as well as actions with a SIP address-of-record. Providing CPL and SIP CGI scripts, uploading presence information, user provisioning and configuration are examples. There are many facets to this problem and many ways of solving it. The present proposal defines just one approach.
The idea is to associate a SIP AoR or a SIP UA's URL with one or more URIs that can be used to retrieve data or to invoke the desired actions. This allows for binding information, modifying information, and deleting bindings. Various types of indirection are supported: a URI may point to the information which may be retrieved from an external location or included in a message body; small amounts of information may also be encoded within the URI itself. The binding concept discussed here and the concept of content indirection have some commonalities in that both refer to external data but the semantics are different: content indirection is used to replace data otherwise carried within a message body by the data the URI references while bindings are used to link external data to an AoR (with this binding being valid for more than just a single message).
The document proposes a Binding: header field with a number of parameters ("disposition", "expires", and "etag") to control the actions to be taken for a particular binding. Any number of Binding: headers may be present in a message. In addition, a specific BIND method is defined to decouple creating and modifying bindings from user registration; its basic implementation is pretty similar to the REGISTER method.
The first open issue raised by Henning was whether or not this approach solves some of the problems that we have in a reasonably generic fashion. The second question is whether the proposal addresses the right set of applications. Third, may a generalized version of PUBLISH solve the binding problems as well? While Henning sees views this to be unlikely, it still may need to be discussed. Henning also talked about a few details but wanted the discussion to focus on the general problem. He also pointed out that, not yet contained in the draft, BIND requests may be routed following caller preferences and thus need not go to the registrar, effectively allowing any entity to become a repository for bindings.
There was strong agreement that bindings are needed (and that they are needed soon) and also that the mechanisms are likely to be different from the PUBLISH method. It was also found that this may go well together with service route discovery, configuration, boot strapping, and other work that has been going on recently. Overall, it is important to carefully scope this work: one may do quite a bit with such an approach but, at the same time, it can also turn out to be an infinite rathole of potential abuses (with quite some difficulty to tell what is an abuse and what is not). It is unclear what types of "disposition" are legitemately bound to a URI and which are not. People felt that nothing was wrong with the mechanism but that semantics would need to be more clearly understood and defined and so should be the intended uses. If one finds alternatives for each single use case, this specific proposal may not be needed at all. Another speaker pointed out that this could be a nice and lightweight rendezvous mechanisms for simple devices; abuse should be avoided, however. The author pointed out that, if pursued further, the mechanism should stay relatively simple.
From the overall argument, the group appears to be split: some people want this yesterday, others may not want it at all. Humming revealed quite some support but also opposition, thus confirming the impression from the debate.
SIP Compression open issues (Carsten Bormann, Gonzalo Camarillo)
Carsten Bormann presented on the current status of SIP compression. The signaling compression work is essentially complete; the documents are in the RFC editor's queue and have even been assigned RFC numbers. There are two loose ends remaining which may fit into the SIP WG: the static dictionary for signaling compression and the integration of signaling compression with SIP.
The static dictionary contains a set of well-defined strings that are used by SIP and SDP; currently, this table is about 4,000 bytes in size and is partitioned into five priorities. There are only a few open issues remaining: the recent changes in SIP documents need to be tracked and corresponding additions/modification need to be incorporated in the dictionary. The most interesting issue here is when to stop tracking.
There is obviously no single right point in time for doing so. The dictionary should be as complete as possible to gain most efficient compression from the very first message exchange. However, while developed in the context of 3G requirements, the dictionary is of much broader applicability, so one should not wait too long to enable devices and applications to make use of it as soon as possible. Since the dictionary, once published, is not going to change anymore, it should still be as complete as possible. Hence, one of the key questions is which additional words are missing right now; along with this, it should be rationalized which keywords will be included and which ones won't. Headers that are too specific should not be included; the size of the dictionary should not double. A key point here are P- headers: many people may have P- headers they want to see documented tomorrow, but the most likely ones (such as those from the 3G community) should be; the proposal is to separate the "P-" from the remaining header name and just put in "words". This approach was accepted and all the SIP specs will be reviewed again to make sure that nothing important is missing. The group agreed that the best thing would be stop adding to the dictionary "now", i.e. as soon as this review is complete.
As second speaker, Gonzalo Camarillo addressed how to signal compression within SIP. The current draft specifies a new parameter -- "comp=sigcomp" -- for use in two places: in the SIP URI and in the Via: header. The parameter is meant to express willingness to compress rather than support for compression; this distinction shall help to use compression only where is makes sense. The draft is quite short and Gonzalo expects it to be uncontroversial but still asks for feedback about the general idea. Humming indicated quite some support and only a bit of opposition. The WG will consider this as a WG item, pending AD approval.
The next steps are (1) to determine how to get SIP URI with the "comp=sigcom" parameter in it and (2) to do an interop -- a real or a virtual one -- on this work. The SIP interop meeting in Atlanta in October is considered a suitable place for such an event. Robert Sparks has volunteered to contribute to organizing the interop and generating the test cases.
The first issue, how to identify that a certain SIP URI can and/or should be contacted using sigcomp, provoked further discussion. In particular, that "comp=sigcomp" is attached to a SIP URI needs to be learned dynamically. This holds true for endpoints as well as for first hop (outbound) proxies (for the first message they send). To make use of the dictionary (for the first message) at all, a SIP entity that wants to transmit a message needs to know up front whether it can compress it or not. There may also be more options one may want to discover than just sigcomp, linking this to configuration in general. Configuration protocols such as DHCP (where a SIP option already is included, even though it is insufficient for this purpose) or PPP should provide this information, preferrably in URI parameters as opposed to numerous independent options; but they don't: URIs are not supported by these protocols which limits the applicability and extensibility of those configuration protocols. (SIP implementation may also not have control of the configuration protocols, making extensions difficult to implement.) As a SIP mechanism, UAs use REGISTER and thus the proxy can learn their compression and other capabilities. To learn about the proxy, the UA can use the OPTIONS method to inquire the proxy; the Max-Forwards: header may be used to "direct" the message to a particular (the first-hop) proxy. A further remark was made on the use of TLS in conjunction with this: when setting up a TLS connection, encryption as well as compression algortihms are negotiated; this should also be considered in a revised draft.
From the discussion, a workable solution seems possible and the draft authors are asked to flesh out more details on how this is supposed to work. There is another question on whether or not this is a SIP WG item or if this is much broader in scope (i.e. configuration in general) and should be looked at somewhere else in the IETF. Whatever the approach will be, this does not affect the rest of the draft.
Referrals from SIPPING (chairs)
The SIPPING WG has done requirements work in a number of areas and has identified various places where SIP extensions are required and where the requirements work has matured. The work items discussed for taking in in the SIP WG were:
* Content indirection: referring to a piece of information by means of a URL rather than including the information itself in a message. It was agreed to accept Content Indirection as a work item and adopt draft-olson-sip-content-indirect-mech-00.txt as basis for future work.
* Join: A UA's pushing itself into an ongoing call thus turning it into a three-way conference (e.g. to implement single line extensions); note that this is different from joining an ongoing conference. This work item was adopted for the SIP WG.
* IEPREP: since there are no firm requirements available, this work item cannot be taken up right now.
The was also a brief discussion on SIP requirements for hearing-impaired: requirements have been done in the SIPPING WG and a design team is working on some mechanisms. But the scope is not yet clearly defined, so it is too early to consider this as SIP WG item. At least a reasonable Internet Draft is needed to go for the next step. An a-hoc group meeting on this subject was announced, the agenda being to which pieces are to be worked out next.
Future Work Planning (chairs)
The general idea is to move RFC 3261 to Draft Standard. Besides this master plan, there are a number of other work items on the plate to be moved through the process -- and typically new work items keep coming around. Another important issue is the migration from IPv4 to IPv6 and interworking between the two; a charter item needs to be defined for this. List discussion, ideas, drafts, etc. on this subject are solicited. It was found that the NGTRANS WG also started looking into SIP; they prefer this being looked at by the SIP community. The work may involve the SIPPING WG for some requirements as well as MMUSIC for negotiation. It was decided to start the discussion on the SIPPING list. Furthermore, an implementers guide was suggested; a work item also belonging to SIPPING.
Finally, some discussion the state and cookies drafts came up. People were not sure whether or not those were really needed. ITU and 3GPP had expressed some need; other people felt they might use those mechanisms if available but do something different if not. One of the core issues with state/cookies is that the requirements have never been clearly defined -- and hence it is hard to devise (potentially cleaner) alternative mechanisms. This motivated the idea to push the work back to the SIPPING WG to develop a clear requirements spec. A deadline shall be set and, if by then no requirements have been defined, the work may as well be disappear altogether.