[Sip] Revised minutes, SIP at IETF 70

Dean Willis <dean.willis@softarmor.com> Thu, 03 January 2008 17:27 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JATqf-0001aw-SZ; Thu, 03 Jan 2008 12:27:17 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JATqd-0001ar-UK for sip-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 12:27:15 -0500
Received: from [] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JATqd-0001Z5-Fl for sip@ietf.org; Thu, 03 Jan 2008 12:27:15 -0500
Received: from nylon.softarmor.com ([]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JATqb-0004Av-E3 for sip@ietf.org; Thu, 03 Jan 2008 12:27:15 -0500
Received: from [] (cpe-76-185-142-113.tx.res.rr.com []) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m03HRBTi027298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <sip@ietf.org>; Thu, 3 Jan 2008 11:27:12 -0600
Mime-Version: 1.0 (Apple Message framework v753)
Content-Transfer-Encoding: 7bit
Message-Id: <7A5F403E-D25B-44CB-BAEE-C8BD2418443E@softarmor.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: "sip@ietf.org List" <sip@ietf.org>
From: Dean Willis <dean.willis@softarmor.com>
Date: Thu, 3 Jan 2008 11:26:59 -0600
X-Mailer: Apple Mail (2.753)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3d1fcc6feccbcc611b6c309986f05f7
Subject: [Sip] Revised minutes, SIP at IETF 70
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

James Polk pointed out I forgot to include the breakout session we  
had on Location Conveyance. I've added this to the minutes. Copies of  
these minutes are also posted in the iETF Proceedings and in the SIP  
WIKI on the Softarmor site.

Please point out any more issues.

Revised minutes follow:

Minutes, SIP at IETF 70

Edited by Dean Willis based on notes by Ben Campbell, Miguel Angel
Garcia-Martin and Brian Rosen

Session 1

Topic: Agenda and Status
led by Chairs
Slides presented and included in proceedings

Issue: How to deal with extensions in experimental RFCS like "e2m"

Proposed that we change the process of RFC 3427 to allow experimental
track RFCs to register SIP extension headers. Discussion concluded
that using an "X-" prefix in the registry would be
self-defeating. There are also concerns about setting the bar too low
-- we want any registered extension headers fields to be both
reasonable and well-documented. The group reached a consensus on
making a change to RFC 3427 allowing any RFC produced by the SIP
working group to register extension headers.

Issue: Robert's fork-loop-fix draft

Not enough people appear to have read the draft yet for us to have a
strong sense of whether the changes satisfy issues raised in WGLC. The
consensus is that the chairs shall conduct another short WGLC.

Topic: Location Conveyance
led by James Polk
Slides presented and included in proceedings

Issue: Should we have an error message to describe what's bad about
the civic address data contained in a prior message?

Several points were raised in discussion, including whether we have
enough of an understanding of location validation to be able to do
this sort of detailed response coding at this time. The current draft
allows for a human-readable string, and this may suffice for current
needs. Whether this is sufficient depends in large part on whether we
expect automata to be able to respond to a a validation error, correct
the location data, and resubmit it. There may also be the possible
that the automata could parse the error response and ask a human a
specific question, such as "What floor are you on?" if needed.

No conclusion was reached in the meeting, and the author was asked to
lead a discussion of the issue on the mailing list.

Issue: What are the semantics of the "recipient" parameter in the
Geolocation header?

Debate centered on whether this parameter is a hint, a provider of
context, or a binding constraint on authorization to access the
location information. The discussion became somewhat heated.

The working group did indicate a strong consensus to develop a
protocol mechanism for location-based routing.

Debate during the meeting session was inconclusive, and it was
proposed that we have an ad-hoc breakout session on this topic.

The ad-hoc session resolved to move this semantic into the geopriv
object itself, and to send the work item for this back to GEOPRIV to

Issue: Are the error codes proposed too complex or too granular?

Debate centered on whether the error codes helped users or
automata recover from correctable conditions or are intended
for post mortem debugging. Debate was extensive, with no
immediate consensus forthcoming, so this topic was also deferred
to the the breakout session.

The breakout session resulted in a consensus on restructuring the
error response codes. Minutes of this session are included
later in this document.

Topic: Info Harmful
led by led by Eric Burger
Slides presented and included in proceedings

Discussion was deferred until after the presentation of the INFO
Events draft.

Topic: Info Events
led by Christer Holmberg
Slides presented and included in proceedings

Issue: If an endpoint can receive an info package (i.e., indicates it
can receive such events), does that mean it will do something useful
with an event if it receives it?

Discussion seems to indicate that each INFO event package will
determine the requirements for that package, with the general trend
being "only say you know it if you want it". So, event packages, where
available, would be higher-priority than older techniques with less
negotiation flexibility.

Issue: If the other end doesn't understand an INFO event you want to
send, what do you do?

Discussion concluded that a node can only send events that the other
side has indicated a willingness to receive, so if the other end
doesn't understand something, don't send it. This may mean that
event-dependent applications won't work, or that one might have to do
something tricky like falling back to actually talking to the other
party instead of sending events.

Issue: Backward Compatibility

Noted that in the bad-old-days of INFO, all backward compatibility was
handled manually by configuration. That technique can still be
used. However, for the ISUP and QSIG uses, we can provide for backward
compatibility using Accept header fields as these payloads have MIME
types that are not used in other contexts. Also noted that we need to
consider these sort of backward compatibility issues in each event

Issue: Do we want to enable transmission of user-to-user information
in an INVITE initiated dialog? This was one of the arguments against
dialogs of MESSAGE methods.

Discussion indicated that we're probably OK with this for the class of
things we seem to think will end up in INFO events. It was noted by a
chair that there is little sense in trying to "protocol police" this
sort of thing -- the requirement is just t make sure that the protocol
allows the applications involved to understand what they're doing and
not step on each other's extensions.

Issue: Use cases?

Whether DTMF is a convincing use case was discussed without conclusion.

Noted that other SDOs appear to be developing things using INFO. This
MAY be because INFO is the right thing, or it may be simply because
they don't have to negotiate with IETF to use it, and that if we
adjust INFO to encourage them to work with IETF, they might just find
some other loophole like X-headers.

Proposed that there are non-DTMF needs for end to end traffic, but
that these needs may be better met by end-to-end sessions like MSRP.
Of course, this raises the issue of negotiating the semantics of these
end-to-end sessions, like "Why are you sending me these JPEG images in
an MSRP session? What AM I supposed to do with them?", so there would
still be a need for some sort of package definition. However, DTMF may
be unique in being both signaling and media, and we might solve much
of the problem by just finding a fix at the SIP level for DTMF and
ignoring the remainder of the problem.

Discussion on whether use cases could motivate the work. At one point,
a poll by the chairs indicated that few of the people opposed to INFO
events would be persuaded even if confronted with a large number of
valid use cases.

Issue: Registration policy. If we were to define INFO events, what
would the IANA policy be on registering an INFO event package?

Chair Dean Willis proposed that the policy be "specification
required", given that our goal is not to police the architectures of
everybody who wants to use SIP, but that we do need to make sure that
the feature negotiation mechanism work well enough that conflicts are
avoided. We really should NOT have to use SIP working group time to
discuss whether or not some other SDO's use of their SIP-absed
signaling channel is valid.

Issue: Where to go from here?

Noted that there ARE other SDOs actively engaged, and that we are not
servicing the community well by giving no guidance.

Eric Burger noted that the two drafts are not incompatible, and that
the INFO events draft solves all of the "harmful" aspects of current
INFO use noted in his draft.

The meeting concluded with an agreement to further consider use cases,
but no commitment to further action. (Note: subsequent discussion
occurred on-list, shortly after the meeting session).

Session 2

Topic: Agenda and Status
led by Chairs
Slides presented and included in proceedings

Discussion of Essential Corrections will be added to the agenda if
time allows.

The XCAP Diff event draft will be revised and submitted as

Connection reuse was rescoped to allow some requests in the reverse
direction and discourage connection reuse for virtual servers. Some
further clarifications are needed.

Topic: Outbound
led by Rohan Mahy
Slides presented and included in proceedings

Issue:  TCP Keepalive

Current text removed. Noted that even if you use TCP keepalive, you
still need to do the keepalives as specified in this draft.

Issue:  interaction with GRUU.

Group seemed to indicate consensus on the proposal by Rohan for the
2nd option listed in the slides -- GRUU should check that an incoming
REGISTER matches any Call-ID already registered by this device. This
would appear to require a change in the GRUU document.

Issue: What error does the registrar send if it gets a register with
require: outbound but the edge proxy doesn't support outbound?

Christer Holmberg suggested that most cases would need a 500-class.

Jonathan Rosenberg noted that this depends on what might happen if the
requested were to be retried. If it is always going to fail, the
response would be in the 400 class. If success on retry is possible, a
500 might be more reasonable.

Cullen Jennings noted that It is also important to consider what
clients will do with the response.

Adam Roach observed that a 420 response would make it hard to debug
the problem from a client perspective, and that a new error code would
be better.

Jonathan suggested using a proxy require that the proxy would
translate to require, but Rohan reminded us of prior discussion where
we had decided this would not work.

Christer concurred with Adam, saying that this problem is more
general, essentially an "invalid path".

The resolution is to develop a new 400 class response code indicating
the problem with this path. Adam Roach volunteered to send text.

Issue: How do subsequent in-dialog requests follow across an Outbound
edge link?

Proposed by Rohan that the Outbound proxy MUST record route if the top
Route header has an :ob" parameter.

Extended discussion followed, noting that this makes us dependent on
proxies for mid-dialog requests, which has impacts on reliability

Francois Audet noted that the current text is hard to understand.

Chairs conclude that the room seems to mostly support the resolution
proposed by Rohan, but that the final text needs to be reviewed and
agreed on-list.

Issue: The "keep" parameter.

Ted Hardie  argued for  keeping the text as-is.

Aki Niemi argued in favor of deprecating the "keep" parameter, based
on its lack of usefulness and potential to confuse people.

Christer Holmberg suggested deprecating the parameter when used with
an outbound proxy, but allowing it for non-outbound cases.

Poll by chairs indicated strong consensus for removing the "keep"

Issue: Replace timed-keepalive parameter with a new header

Proposed by Aki that weuse a new header, such as "Flow-Timer" to be
returned in register response.

Noted by Rohan that this might fix the non-outbound case for

Christer questions this, as it is still necessary to know if keepalive
is supported.

Poll by chairs indicated strong consensus to define a new header for
this purpose.

Issue: Detecting client support for keepalives without "outbound"

Proposed new option tag for client support, included by client in

Poll by chairs indicated preference to consider this approach outside
of the Outbound draft. Christer Holmberg may pursue a draft on this

Procedural point: Francois Audet has volunteered to act as the
protocol shepherd for getting this draft through the process.

Derek reminded Rohan to add text relating to the route construction
issue. Derek will try to send text on this to Rohan.

Topic: Resource Priority Header in Responses
led by Janet Gunn
Slides presented and included in proceedings

Discussion centered on the role of the RPH header in a response and
the assumptions underlying a network in which it would be useful.  The
key issue is that since SIP cannot challenge responses that if the
response is not signed (as in SIP Identity) then there is no way to
tell upstream where the RPH header came from. There may be no coupling
between the proxy layer and the access network for media priority

Noted by EKR that given the security model, where the user is not
trusted but all the proxy nodes are, that this requires integrity
protection on the connections, with peer authentication. A proxy
receiving a response with RPH has to know that it's getting this
response from a trusted proxy and not somebody else.

Several parties suggested that this sort of mechanism is more
appropriate for a P-header with an applicability statement that
explains the transitive trust model.

Keith Drage, as chair, asked people to consider the stateless proxy
use case from James' draft relative to the security assumptions,
P-header concept, and authentication issues.

Topic: Media Identity
led by Dan Wing
Slides presented and included in proceedings

Issue: SBCs break 4474 because SDP signed by Identity is rewritten by

Francois observed that this problem may only occur when it is an SBC
outside the domain of the Identity server that is doing the rewriting.

Hannes suggested extending IDENTITY to be like DKIM, which can
selectively sign pieces.

General discussion revealed that most of the material in the signaling
is problematic from a signature perspective. IP Addresses are
essentially meaningless, especially across domain boundaries. Phone
numbers are little better, with end-nodes having no real way to test
assertions about them (and perhaps a service provided signature is the
best we can do here).  RFC 4474 already documents limitations with
respect to telephone numbers.

There seems to be an emerging thread of consensus here that what we
need is some way to bind media to signaling -- that is, to by
inspection of the media and the signaling be able to say with some
level of certainty that they are related -- and specifically, to say
"this media is a result of that signaling".

Chairs noted that there is additional work required her to be able to
frame this into the sort of requirement that could be added to a

Topic: DTLS Framework
led by Jason Fischl
Slides presented and included in proceedings

Issue: 4474 for phone numbers

We may be lacking documentation on when RFC 4474 does and does not
work, and what security we get when using it with phone numbers. Jon
Peterson seems to think that 4474 already offers this guidance.
Jonathan Rosenberg disagrees and believes the text in 4474 is
inadequate and more is needed.

Consensus noted that even if we do need more here, it is outside of
the scope of the DTLS framework. However, the framework should at
least note the issue.

Issue; Anonymity

Agreed that text must be updated to say it does not break existing

Issue: Middle boxes.

SBCs may block key exchange before 200 OK. This is not specific to

Proposed by Christer that we at least mention this issue in the draft.

EKR noted that much of this SBC difficulty should be documented in
Brian's middlebox draft.


Consensus: DTLS-SRTP over TCP rather than RTP over TLS.

Issue: Priority for advancing.

Chairs observed that an AVT document is dependent on this, making this
a high priority to move along, However, the AVT chair reported that
the AVT document is not as ready as we might have thought.

Topic: Essential Corrections
led by Keith Drage
Slides presented and included in proceedings

Issue: general intent of essential corrections

We seem to have some disagreement as to the intent and value of the
essential corrections process. The chairs restated the goal as being
to batch together the updates to RFC 3261 so that readers do not have
to look in many places to find the current "corrected" specification.

Issue: record-route-fix

Is this an essential correction or an enhancement? It does identify
specific failure cases that occur if RFC 3261 is used as-is. The
chairs noted that drafts making normative changes to a standards track
draft need to be standards track themselves, not BCPs. However, BCPs
would be appropriate for documents that, for example, argue for using
one option in an an existing standards-track document over an
alternative in that document.

Robert argues that this fix is needed, although it would be acceptable
to advance it individually rather than in the essential-corrections

Conclusion: robert and Jonathan are to go discuss this and come back
with a recommendation.

Issue: IPV6 ABNF error

Consensus that this is an essential correction we would consider
anything that behaves as per 3261 to be erroneous.

Issue: 503 corrrection

JDR argues that it is known that 3261 doesn't perform well in overload
conditions, and that we have ongoing work to improve this behavior.

Volker Hit concurs, noting that the overload team is still working to
get better simulation results.

Conclusion: We'll continue to discuss this document but not move
towards WGLC yet.

Issue: Mutual authentication

Noted that there does seem to be a use case for this extension in IMS
and cable networks, but that it probably doesn't meet the litmus test
for an essential correction.

Conclusion: It shall be discussed as an extension.

Issue: invfix

Conclusion: this is an essential correction. Author Robert Sparks is
to revise for WGLC.

Topic: INFO

Chairs proposal is for Hadriel and Christer to continue their draft,
rolling in the supporting motivation from Eric's draft. We will also
discuss use cases for the INFO package model. if we don't find three
agreeable use cases by the next meeting, we'll go ahead and publish
Eric's "INFO Considered Harmful" draft so that there will be some firm
guidance in RFC format.

Session: Location Ad-Hoc

An additional break-out session was held to discuss issues related to
location conveyance and SIP, due to the failure to reach consensus
on key issues during the regular session.

Notes reported by Dean Willis
Session chaired by Keith Drage

Note-Well reviewed

Discussion led by James POlk
Slides presented

Issue: Error codes in Geolocation-Error header

Issues raised in SIP meeting include general sense that current error
codes are just "too much" and should be reduced.

Discussion of actionable vs. diagnostic errors ensued (started by
James Winterbottom). Are the text strings fixed so that they can be
processed by automata? Are we doing trend analysis or trying to make a
call succeed that was failing?

Comment by Henning Schulzrinne: Not really a question of whether 14 or
17 is the right number, but as to whether the civic address (CA) type
information is appropriately included in the responses. Just including
a CA type doesn't help solve the problem and may confuse the
situation. Robots cannot usefully "fix" defective CA information, but
require human interaction. I fear that the software will say "A1 and
A7 are wrong" and the user will have no idea what to do.

Response: Do you want to be able to say things like "The city field
was missing and we need it." We could put this in the current draft
for now.

Counteproposal: We should leave CA types out for now and add them back
in only if experience shows that they would have been useful. It's
better to drop it now.

We seem to have a consensus to delete the CA type information from  
error responses.

As for other error codes, EKR suggests that those that are repairable
by automata be included. Henning agrees, suggesting we also have one
error code for human-fixable errors that can be communicated in text.

Ted Hardie categorizes errors in 3 groups : 1) Same things that might
work later, 2) vague "something you gave me is wrong", 3)
bit-toggleable "permission" errors. Possibly a 4th class, "things an
automata can fix", like refreshing its location calc and resending.

Noted that SIP "Accept-Language" mechanism provides the
human-language negotiation mechanism.

Poll: does anybody have issues with Ted's plan?

Mostly agreed: James will revisit.

Issue: Recipient=

Henning discussed differences between URN routing and URI routing in
the presence of a location body. He has concerns that it might not be
possible to make a reasonable determination in an implementation and
this has lawsuit potential.

Ted counter-argues that this was concluded in GEOPRIV.

Massive debate ensued.

Proposed: Easy solution for SIP working group is to move the
functionality formally known as "recipient =" out of SIP and into
PIDF-LO as a routing-allowed flag. This will require deleting the
subject from the SIP draft and creating a new GEOPRIV draft. Jon
Peterson volunteered to write the GEOPRIV draft.

NOTE: The GEOPRIV draft will require careful definition of
"retransmission" so as to not interact with the fact that SIP proxies
operate by retransmitting SIP requests.

Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip