Last Modified: 2005-11-04
|Done||Submit Internet-Draft on SIP-Telephony Framework to IESG for consideration as a BCP|
|Done||Submit Internet-Draft on ISUP-SIP Mapping to IESG for consideration as Proposed Standard|
|Done||Submit Internet-Draft on Requirements for use of SIP to support telephony for the Hearing-Impaired to IESG for consideration as an Informational RFC|
|Done||Submit SIP 3rd party call control to IESG for consideration as BCP|
|Done||Submit Internet-Draft on 3G Requirements to IESG for consideration as an Informational RFC|
|Done||Submit Internet-Draft on Mapping ISUP Overlap Signaling to SIP to IESG for consideration as a Proposed Standard|
|Done||Submit Internet-Draft on Usage Guideline for Events (Subscribe-Notify) to IESG for consideration as an Informational RFC|
|Done||Submit Internet-Drafts Basic and PSTN Call Flows to IESG fro consideration as BCPs|
|Done||Requirements for Content Indirection in SIP|
|Done||Submit Message Waiting SIP event package to IESG for consideration as PS|
|Done||Using ENUM with SIP Applications to IESG for consideration as an Informational RFC|
|Done||Requirements for Reuse of Connections in SIP|
|Done||Submit Internet-Draft on T.38 Fax Call Flows to IESG for consideration as a BCP|
|Done||Requirements for SIP Request History|
|Done||Submit Internet-Draft on Requirements for AAA Application in SIP Telephony to IESG for consideration as an Informational RFC|
|Done||Sip Interworking with QSIG|
|Done||3pcc Transcoding to IESG as Info|
|Done||KPML to IESG as PS|
|Done||Conferencing Requirements to IESG as Info|
|Done||Conferencing Framework to IESG as Info|
|Done||Conferencing Call Control-Conferencing to IESG as BCP|
|Done||End-to-Middle Security Requirements to IESG as Info|
|Done||Configuration Framework to the IESG as a PS|
|Oct 2005||Revise Charter|
|Nov 2005||Requirements for Consent-based Communications in SIP to IESG as Info|
|Nov 2005||Submit I-D on Subscriptions to Ad-Hoc Resource Lists to the IESG as PS|
|Nov 2005||Submit I-D on Multiple REFER to the IESG as PS|
|Nov 2005||Submit I-D on Ad-Hoc Conferencing using URI lists to the IESG as PS|
|Nov 2005||Submit URI List Transport Mechanism to the IESG as PS|
|Nov 2005||Framework for Consent-based Communications in SIP to IESG|
|Nov 2005||Session Policy Requirements to IESG as Info|
|Dec 2005||Requirements on Trait-Based Authorization to IESG as Info|
|Dec 2005||Transcoding Framework to IESG as Info|
|Dec 2005||Transcoding with Conf Bridge to IESG as Info|
|Dec 2005||Service Quality Reporting to IESG as PS|
|Jan 2006||Session Independent Policy Mechanism to the IESG as PS|
|Jan 2006||Session Specific Policy Mechanism to the IESG as PS|
|Jan 2006||SIP Security Flows to IESG as Info|
|Feb 2006||SIP Service Examples to IESG as Info|
|Feb 2006||IPv6 Transition in SIP to the IESG as Info|
|Mar 2006||Revise Charter|
|RFC3324||I||Short Term Requirements for Network Asserted Identity|
|RFC3351||I||User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired individuals|
|RFC3372||BCP||Session Initiation Protocol (SIP) for Telephones (SIP-T): Context and Architectures|
|RFC3398||PS||Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping|
|RFC3485||PS||The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)|
|RFC3578||PS||Mapping of of Integrated Services Digital Network (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)|
|RFC3665||BCP||Session Initiation Protocol Basic Call Flow Examples|
|RFC3666||BCP||Session Initiation Protocol PSTN Call Flows|
|RFC3680||Standard||A Session Initiation Protocol (SIP) Event Package for Registrations|
|RFC3702||I||Authentication, Authorization and Accounting Requirements for the Session Initiation Protocol|
|RFC3725||BCP||Best Current Practices for Third Party Call Control in the Session Initiation Protocol|
|RFC3824||I||Using E.164 numbers with the Session Initiation Protocol (SIP)|
|RFC3842||Standard||A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)|
|RFC3959||Standard||The Early Session Disposition Type for the Session Initiation Protocol (SIP)|
|RFC3960||I||Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)|
|RFC4083||I||Input 3rd-Generation Partnership Project (3GPP) Release 5 requirements on the Session Initiation Protocol (SIP)|
|RFC4117||I||Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)|
|RFC4189||I||Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP)|
Minutes edited by Gonzalo Camarillo
Based on notes by Hisham Khartabil, Dean Willis, Jim McEachern,
Dorothy Gellert, and Steve S.
Meeting chaired by Dean Willis, Rohan Mahy, and Gonzalo Camarillo
Slides presented included in the proceedings
MONDAY, November 7, 2005, 1510-1710
Topic: Agenda Bash
Discussions led by: Chairs
Two ad-hoc meetings were announced: one on TISPAN-related issues and
another on peer-to-peer SIP. Oscar Novo was presented as the new
The chairs presented the status of all the SIPPING WG items. The
URI-list services drafts have passed WGLC and are ready, but they are
waiting for the consent framework to be ready. New revisions of the
RTCP summary and trait-based authorization drafts will be submitted
shortly. The chairs will request their publication as soon as the new
revisions appear in the archives.
The chairs presented the updated charter and milestones. It was noted
that the dialog usage draft has disappeared. The chairs will
investigate what happened with that draft.
Topic: Configuration Framework and Data Sets
Discussion led by: Dan Petrie
There were discussions on whether the text on merging should be
removed from the drafts. It seems easier to construct a data model
such that merging is easy than provide all nodes with a general
There were discussions on how much XML validation should be required
in the clients. The conclusion was to using the XML schema as used in
SIMPLE. At this point, there are no requirements for strong XML
validation at the client side.
There were discussions without a clear conclusion on whether, for
certain configuration data, user agents can be provided with the URI
of a single hop or they need a routing vector.
Data sets dealing with configurable elements defined by SIP or SIPPING
WG items will be WG items as well.
Topic: Session Policy Framework and Data Set Format
Discussion led by: Volker Hilt
The chairs will add a milestone date for the session policy framework
to the charter.
There was consensus that using an SDP format for session specific
policies would be OK.
Topic: Consent Framework
Discussion led by: Gonzalo Camarillo
There was consensus to remove the operations part from the permission
documents. Furthermore, there was consensus on having permissions that
are as simple as possible, given that they will be stored by servers
that do not any relation with the users uploading them.
Topic: Conference Bridge Transcoding Model
Discussion led by: Gonzalo Camarillo
The author will clarify how transcoders create their offers.
Topic: IPv6 Transition
Discussion led by: Vijay Gurbani
The topic of using TURN for IPv4/IPv6 transition will be further
discussed in the BEHAVE WG. Agreed that the draft should not contain
examples of network APIs.
It was noted that some interactions between DNS and dual-stack SIP
nodes could also belong to a future update of RFC 3263. It was
suggested to remove the general discussions on IPv6 transition
strategies from the draft.
The WG is interested in working on this, but remains undecided as to
whether to schedule this work immediately or defer it for a future
Topic: SIP-unfriendly Functions in Current Architectures
Discussion led by: Jani Jautakorpi
It was noted that this draft is not only useful for SBC implementers,
but also for UA implementers. Therefore, it is a good thing that the
draft is not only focused on SBCs.
It was suggested to document the requirements for features that SBCs
currently implement, how they are currently implemented, and how those
implementations break SIP. With all these things documented, the draft
would be useful to start new work that meets those requirements in a
more SIP-friendly way. The chairs will meet the authors to align
terminology and to determine the scope of the draft.
A few people agreed to send comments to the authors and to the list on
the examples in the draft.
There seems to be agreement that this document is useful and that
should eventually become an RFC.
Topic: Max Forwards Issues
Discussion led by: Robert Sparks
It was noted that loop detection would eliminate this problem. There
could be ways of implementing loop detection that require less state
information than the current proposals.
It was noted that RFC 3261 specifies loop detection for proxies, but
does not require its usage.
It was suggested that other solutions to this problem could consist of
limiting arbitrary registrations of contacts or limiting inter-domain
It was concluded that his discussion should continue in the SIP WG
since this is a bug in RFC 3261.
Topic: Multi Transcoding
Discussion led by: Tae-Gyu Kang
The draft deals with the following use case: if a call is placed
through a transcoder, and the transcoder cannot complete an
offer/answer exchange with the next hop, then a 488 response would
indicate a problem with the transcoder, not with the "far side". This
may justify a new response code.
The author will need to clarify what is the use case that gets us into
a situation with more than one or two transcoders when using the
conference bridge transcoding model (which is intended for simple
The first SIPPING session ended.
WEDNESDAY, November 9, 2005, 1300-1500
Topic: Redirection Issues
Discussion led by: John Elwell
The draft was not presented. The chairs informed the group that the
authors have realized that their requirements can be met by slightly
There was a discussion on the path for this draft, which will be AD
Topic: Extending the SIP Reason Header with Warning Codes
Discussion led by: Jani Hautakorpi
The authors clarified that the main purpose of this draft was to
trigger discussions on the usage of Warning header fields in SIP. At
this point, not many implementers use them, and according to RFC 3261,
their scope is limited to reporting problems related to session
It was noted that external SDOs are planning to propose SIP extensions
in the near future and they need to know whether proposing new Warning
codes to meet their requirements is appropriate, or if they should
propose new response codes instead.
There were discussions on whether or not response codes are
enough. The conclusion seemed to be that they are enough and that we
should not encourage new Warning code definitions at this point. In
any case, this discussion will be continued on the list.
There were discussions on whether the response code address space is
running out. Robert Sparks agreed to look into all the new response
codes being proposed (otherwise, they are not registered in the IANA
until they are documented in an RFC).
Topic: GRUU Reg Event Package
Discussion led by: Paul Kyzivat
Consensus to go with the draft as is and schedule its WGLC.
Topic: Requirements and Possible Mechanisms for File Transfer Services
Within the Context of SIP Based Communication
Discussion led by: Markus Isomaki
There were discussions on whether or not this work is useful and, if
it is, where should this work proceed. The conclusion was to write a
requirements document and discuss it in SIPPING.
Topic: SIP Identity Usage within Enterprise Scenarios
Discussion led by: Steffen Fries
There were discussions on the difference between device certificates
and user certificates. The topic needs to be clarified so that
everybody can understand it.
Topic: Calling Party Category
Discussion led by: Rocky Wang
There were discussions on whether it would make sense to do this with
SAML. The author will talk to the folks working on SAML.
Topic: Implementations of PRACK
Discussion led by: Rohan Mahy
In the MMUSIC session, some folks mentioned that people were trying
and avoiding implementing PRACK due to its complexity. There were some
discussions on what to do without a clear conclusion.
Topic: Payment for Services in SIP
Discussion led by: Jason Fischl
There were discussions on whether this work is useful for things that
are not SPIT or SPAM. It was proposed to use SAML, but not many people
were up to date with SAML.
Topic: URN for Services
Discussion led by: Henning Schulzrinne
It was concluded that this work should continue in the ECRIT WG.
The second SIPPING session ended.
The SIPPING WG organized two ad-hoc meetings during the week of the
IETF meeting. The minutes of the ad-hoc meeting on TISPAN-related issues can be
found here. The minutes of the ad-hoc meeting on peer-to-peer SIP issues can be