Minutes of SIP WG meeting at IETF 73
Edited by Dean Willis based on notes by:
Vijay Gurbani
Scott Lawrence
Paul Kyzivat
Alan Johnston

Session 1, Monday November 17, 2008, 1740-1930, Salon D

Topic: Agenda and Status
Led by Chairs
Slides presented

Agenda accepted as presented.


Issue: Interim in Jan 2009.

Proposed interim in Malta during January 2009 discussed. Note: This
interiom was cancelled later in the week.

Issue: SIP Location Conveyance

Ted Hardie and James Polk reported on status in GEOPRIV. They disagree
on how far from a consensus we are.


Issue: Dotson's Mutual Authentication draft

WG has consensus on pursuing, but ADs and Security Area adviser are
opposed to this work. Therefore, we will continue to ignore it until
further notice.



Topic: URI and Parameter Delivery
Led by Jonaathan Rosenberg
Slides presented
http://tools.ietf.org/id/draft-rosenberg-sip-target-uri-delivery-00.txt

Issue: Free Phone Numbers.

Agreed that there is no differentiation required here, they may be
treated as targets.

Issue: What is a "retarget" operation? This

Following discussion, Jonathan agreed to add a definition and
discussion of this to the draft.

Issue: Normative behavior update for RFC 4244

Consensus noted to revise RFC 4244, and fix some other known problems
with it at teh same time. MAry Barnes volunteered to edit the
document.

Issue: Reference to URNS.

Ted Hardie prposed removing teh reference to URNs, as incorrect and
confusing.

Issue: Discussion of P-Celled-Party-ID

Agreed that this needs furtehr work. Christer Holmberg will send text.

Issue: Parameter name conflict ("target") with RFC 4458.

Editor will change the name of the parameter.

Poll: Shall WG adopt this draft towards our charter deliverable on the
topic? Chairs reported a strong consensus to do so.



Topic: INFO Packages
Led by Eric Burger
Slides presented
http://tools.ietf.org/id/draft-ietf-sip-info-events-01.txt

Issue: The "send-info" set

Discussion focues on use cases, with DTMF being proposed and found
inadequate. Agreed to deprecate this from draft; each side to only
declare receive capabilities.

Issue: Info in SUBSCRIBE dialogs

Can INFO be used only in INVITE dialogs, or also in SUBSCRIBE dialogs?

Consensus on use only in INVITE dialogs. Robert Sparks is to send text
on topic to Eric.

Issue: To allow or not allow Contact header field in INFO

Agreed that we can use the existing rule for target-refresh
requests. Further text is to be solicited on-list.

Issue: Case sensitivity in INFO pakcage names

Noted that package identifiers are in the grammr as octets, therefore
case sensitive per RFC 3265.

Agreed that registry definition shall include text prohibiting
registration of names that differ only in case.

Issue: Specification Strength

Alternatives including "Specification Required", "No Registration
Required", "FCFS", were discussed.

No consensus detected.


Topic: Early Dialog Termination with 199
Led by Christer Holmberg
Slides presented
http://tools.ietf.org/id/draft-ietf-sip-199-02.txt

Issue: Is there a constituency for this work?

Noted by chairs that we had previously taken a poll on the topic, but
that very few people seem engaged in the work.

Chairs took a poll on interest levels, and "don't care" was observed
as the loudest of the results.

Noted that 3GPP has adopted the approach.

Noted that AT&T expects to be requiring this optimization from
vendors.

Noted that the draft is less interetsing if it does not solve
HERFP. There had been agreement in SIPPING not to work on a general
solution for HERFP. Therefore, the scope of this work was reduced to
exclude HERFP.

Discussion about the benefits of the optimization provided by the
draft ensued. These discussions were inconclusive.

Interested parties are asked to discuss constituency on-list.




Session 2, Thursday, November 21, 1300-1500 Salon D


Topic: Agenda and Announcements
Led by Chairs
Slides presented (one deck, same as Session 1)

Issue: SIP Location Conveyance

A revised draft was submitted Nov. 19. The WG is asked to review it.


Issue: draft-ua-sip-privacy, BCP or Info.

Concerned parties are asked to discuss on list, with the "default"
option being Info.



Topic: SIP Draft Stadnards Work
Led by Robert Sparks
No slides
http://tools.ietf.org/id/draft-sparks-sip-steps-to-draft-00.txt

Issue: Should we go for draft?

Extensive discussion ensued, with many opinions offered.

There seems to be a general cosnensus that some part of the work,
perhaps SDP and Offer-Answr, or perhaps the grammar, can be carved off
and worked on independently. However, there is no conclusion on the
larger question.

Robert proposed that we concentrate in the near term on collecting
interoperability statements and essential corrections. We shall also
continue to discuss revisable sections of work. Robert will act as a
facilitator for this effort.


Topic: Keepalive Without Outbound
Led by Christer Holmberg
Slides presented
http://tools.ietf.org/id/draft-holmberg-sip-keep-02.txt

Christer reviewed problem statement and scope of work, including a
presentation of use cases. Four requirements are presented in the
slides.

Issue: Requirements

We seem to have general consensus on Req 1-3, but not 4. Hadriel also
thinks there is a missing requirement on negotiating the frequency of
refresh.

Issue: Can we add this back to outbound?

Noted that this approach was rejected earlier in the outbound
work. However, the most recent Outbound editor (Francois Audet) claims
that Outbound has left a hook for thsi approach, and supports it going
forward as a separate document. Also noted that some participants
don't care about Outbound, but do need keepalive negotiation.

Poll: How many people have ready the draft? Chair noted the result as
a "fair number", indicating more than expected.

Poll: Are there questions in the draft that we should solve? Chair
noted the result as "rough consensus".

Poll; Do we have consensus on the proposed mecahnism: Answer "No".


Topic: Return Routability Check Using RFC 4235, aka DERIVE
Led by Victor Pascual Ávila
Slides Presented
http://tools.ietf.org/id/draft-kuthan-sip-derive-00.txt

Issue: Does sending a DERIVE check tell the caller he isn't trusted?

Discussion conoted that if one is sending a DERIVE check to every
caller that doesn't use RFC 4474, this isn't a statement of distrust.

Issue: E.164 numbers

Since we are unlikely to have return-routability to a phone number,
this mechanism doesn't seem to work there. Or at least it proves
nothing about the identity of the caller, although it might (with a
GRUU) get us a UA-liveness check.

Issue: B2BUA/SBCs

Will B2BUAs respond on behalf of the calling party? If they do, is the
result useful? Opinions expressed on both sides, with the usefulness
dependent on which SBC responds. If it is the caller's SBC, the result
might be useful. If it is the called SBC, the result probably
isn't useful. And we have no way for the UAS to determine which case
occurred, short of an RFC 4474 signature on the response, which would
have made the whole thing moot anyhow. No consensus noted on resolving
this issue. (Editor note: this is isomorphic to the E.164 identity
problem, good luck on solving it!).

Noted that Security Considerations section needs work.

Issue: Requirements

EKR proposed that we are thrashing in the solution space with adequate
requirements here. What exactly are we trying to solve?

Discussion ensued, with a wide range of positions noted.

Noted that return rouatbility checks have proven useful in other
spaces.

Noted that if this works with off-the-sehf UAs, then the incentive
structure is right: the party doing the added work (called) is the one
that gets the benefit from it. This is the inverse of the RFC 4474.

No final consensus noted.


Topic: Path forward on Identity Issues
Led by Jon Peterson
Slides Presented
No draft

Issue: Desirable Properties

Desirable properties:
- Generality ? one universal mechanism is a good thing.
- Avoids bid-downs.
- Authentication
- enables media security
- useful to decide whether or not to accept a request

Hadriel noted that these are all good, but we can't have them. What
are we willing to settle for tha twe can actually deliver? Several
others voiced similar positions on the "noble but futile" theme.

Issue: Configurability

Proposed that some level of flexibility on what headers get signed
might be acceptable.

Hadriel suggested that we come up with a set of rules that
intermediaries could comply with. Sam Hartman suggested that we
further need a compromise about what we need to sign to get secure
media that shows up as secure on the other end, with a spec that
provides it. If we can't get it in this working group, we may need
work that spans the entire IETF to get it.

Further discussion ensued.

No conclusions were noted.