Notes, SIP, IETF 58

Reported by Vijay Gurbani

SIP WG Meeting, Wednesday Nov 12th, 2003.

No changes to Agenda.

Changes since ietf 57:
rfc 3319 published, rfc3608 (service route) and rfc3581 (symmetric
response).  In queue, SIP compression.

PAst ietf last call: sctp, replaces, content indirection.  In
various stages of feedback for these.

Pub requested on 5 I-Ds: session timer, authid body, callee caps,
caller prefs and referred by.

wglc: parameter registry, sip uri parameter, sip smime aes and
sip join.

Old milestones, reset.  4 remain incomplete: MIB, Join header,
revising the charter, and SIP extensions guidelines.  Dean would
like everyone to feed in implementation experience in order to
move the MIB work forward. 

New milestones: presence publication to iesg as proposed, replaces
header to iesg as proposed, connection reuse mechanism to iesg
as proposed, resource priority signaling to iesg as proposed,
app interactio to iesg as BCP, request history to iesg as proposed.

Cullen: on closing the wg, what about the 28 I-Ds which we are now
discussing in the SIP WG.
Rohan: If there is something that does not look like its a mile-
stone delivery, it'll be discarded.  Question: what work do we
need to add?
Jon: Do we need to do anything for SMIME/AES?
Hisham: what happens to work in the SIPPING WG?
Dean: The milestone says "consider" closing the WG; could be
we re-charter.
Robert: What if identify a core protocol issue when WG close?
Rohan: Other wgs which have been closed have resulted in individual
I-Ds by authors that continue to live after wgs have closed.
Allison: good point about not closing the wg is the work in
sipping; fairly unlikely that the wg will close.  Maybe it'll
go dormant and the work will continue over email.

Congestion Safety, Dean Willis

3 proposals: 1: modify signaling in SIP so that you can be
assured that UDP is not being used.  2: deprecate UDP from
SIP (unfavorably met).  3: provide a BCP that explains
congestion management and provide design guidelines on
how to deploy SIP.
Aki: What do you mean by removing UDP completely since there
is transport layer stuff in rfc3261 which mandates UDP use
if no TCP is honored?
Dean: further separation of the distinction: modify the
default behavior so that TCP is the preferred mode.  Or
we can completely deprecate UDP.  Latter is too draconian.
Rohan: In a request, you can say do not send over UDP.
Gonzalo: We are tackling two things: fragmentation problem
of UDP and congestion safety.  We need to separate them.
Jon: hard to remove UDP based on congestion problem only.
Do you want to discuss only the congestion issues?
Dean: History: large MESSAGE method requests if delivered
over UDP will be fragmented.  Since there aren't any rate
controls on fragments, they contribute to congestion.  Now
with SMIME etc. the messages are become larger.  Problem
manifested with MESSAGE, but now we realize that this
is a problem with all if not many methods.
Jonathan: current implementations are not always rfc3261
compliant since they do not implement TCP (which they should
according to the specs).
Cullen: Need to provide implementation experience in using
TCP for scalablity -- managing hundreds of thousands of
connections.
Gonzalo: change the title; congestion safety is a solved
topic.  But we are going beyond that.
Allison: transport safety?
Hisham: discourage putting NAPTR records for UDP and
encourage for TCP.  Make the default transport TCP.
Dean: Maybe need a BCP for connection management for long
lived connections.
Vijay: I presented an I-D at the Atlanta IETF that discussed
the issues with TCP transports.  This is more critical when
you use TLS.  Maybe we can use that I-D as a start for a
BCP.

Gonzalo Camarillo RFC3312 update.

rfc3312 assumes static sessions.  Cannot downgrade QoS
in answers.  UAs should be able to downgrade the current
status of a direction even if it does not have local
information about it.  This should be backwards compatible.
rfc3312 compliant implementations would simply ignore
downgrades.  Not a big issue.  This is needed; how do
we proceed with this?  WG item?  Individual? 
Dean: From ADs conensus is to move as a WG item.  SIP WG
will set a new milestone for it.

Aki Niemi, Publish.

Pretty much out of open issues.  Recent discussions: R-URI
or To header to identify the resource.  Consensus: Use R-URI.
Suggestions to include text discussing etags in more details
(how to manage etags, use them, etc.).  Etags use here is
different than in http, so I will provide more info in the
draft.

Should we talk about rate of publications?  Suggestion: Yes.
Henning: This worries me since we are trying to predict
behavior when we don't know what the usage will be.  In the
end there is no mechanism to enforce it.  Why is 10% more
of that value bad and 10% less good?  We don't have
restrictions on webdav updates on Web servers?
Aki: I agree that this is handwaving, but should we have
text limiting this?
Rohan: Put in SHOULD strength text referring to the event
package.
Henning: There will be many other sources publishing as
well.  One device will not know how many other sources
are.
Rohan: One suggestion is simply do not talk about this.
Other suggestions, please post on the list.

Mary Barnes, History information.'

Changes from -00: misc. editorial changes,  removoved
definition of new terms.  More details on privacy
requirements.  Added more details on security.

Issues: Currently, R-URI is captured as the request
is forwarded.  This appears to make security even
more complex.

Next steps: complete additional details on the flows.
Dependency on the security solution.

Value proposition: improve overall security and tracing.
Applicability to voicemail.

Rohan: What do we want to do with this?
Robert: I don't think that HI will succeed.  It is turning
into a perseverance race.  The apps you are trying to
enable will require all things in the network to work in
a coherent manner.
<It was decided that Mary and Robert will hold an offline
conversations to sync up>

Robert Sparks, Non-INVITE transactions
<Presented highlights and presented 3 ways to solve the issues
outlined in the I-D.  No decision reached on which is the best
way to move forward.  Some hums taken but no final decision
reached>.

Jonathan Rosenberg, GRUU mechanism

Status: two I-Ds submitted; one as a reqs doc and other as a
solution.  Mechanism simple: you obtain a GRUU using REGISTER.

Rohan: I like it, but mention in the document that stateless
behavior is possible but it is an implementation decision.
Don't include an algorithm.
Jonathan:

Issue: GRUU lifecycle management.  Can a GRUU change during
registration?  Decision: No.
If a GRUU parameter is placed in a REG request, it'll be
ignored.  A registrar is not allowed to change GRUUs in
response.

Dialog reuse: GRUUs can allow us to eliminate dialog
reuse.  Should we tackle GRUUs in the REFER draft.
Rohan: No.
Adam: No.
Robert: probably too strong for GRUU spec to say that
dialog reuse is possible.  Maybe we can put pressure in
the future on new drafts that GRUU is a better way to do
dialog reuse.
Jonathan: Recap: Not address this in the GRUU spec, but another
spec.

Locally generated GRUUs.  Putting a GRUU in a Contact header
will end direct signaling.  A UA can generate its own local
GRUU and use that.
Dean: Procedural proposal: split out the local GRUU out of the
main draft so the main draft can progress.

Rohan Mahy, Join and semantics of REFER

Did a WGLC and got 0 comments.  People do care (show of
hands).  Need to hear from people before we ask the chair
to proceed forward.

Semantics of REFER: rfc3515 says it's ok to put any URI in
a Refer-To header.
<Could not capture the rest of discussion>.