Notes, SIP WG, IETF 58
Reported by Ben Campbell
Administrivia:
Usual stuff
Status:
3319,3608,3581 published. draft-ietf-sip-compression-02 in queue. Post
IETF last call: content-indirection-mech-03, sctp, replaces. Last call
on session-timer,authid-body,callee caps, callerprefs,referredby
Wglc parameter-registery, Uri parameter,smime-aes,join
New milestones, no objections. Possible closing in June?
Concern about mib progress, people please look!
App-ineraction framework: (Jonathan) Discovered need for
normative text, does it belong in framework doc? Discuss going for
Proposed Standard in SIP.
JP: Any work needed on smime-aes? No.
General: If we close in June, what happens to existing unfinished docs,
sipping requirements, any new core issues, etc?
AD: Sipping reqs may indicate not closing wg, significant outside
players watching, probably would not close but may go dormant.
Congestion Safety (Dean)
3 proposals: Extend SIP to ensure UDP not used, deprecate UDP entirely,
or offer guidance explaining problems, how to avoid—probably BCP.
Call for consensus.
Aki: What does it mean to remove UDP? Real problem is UDP failover. One
suggestion is to prefer tcp, allow udp if really needed. Other is no
udp at all.
Draft allows you to say you would rather have request fail than use
UDP.
Gonzolo: Two problems-fragmentation, congestion safety.
JP: The UDP issues are not just congestion. Do we want to consider just
congestion, or all UDP issues?
Rohan: Propose yanking 515,516, just leave the parts about forcing TCP.
Positive errors if not supported or no non-UDP path.
JP: Can we just dep MESSAGE. Dean: Problem applies to all.
JDR: lots of UDP only endpoints—need to get them to be 3261 compliant
for TCP.
Rohan:3263 makes default udp, should we change that?
Connect-reuse draft may be vehicle for encouraging TCP.
Fluffy: Why would people turn (tcp) on? NATs cause need for long-lived
connections, TCP fanout is a problem at proxies. Need to either support
massive TCP at proxies or do something else.
Dean: would dccp help? Does not solve fragmentation, wont go through
nats.
May need to describe to implementers how to scale TCP.
Gonzolo: fragmentation and congestion are 2 different things, recommend
changing draft name. Alison suggests transport-safety.
Suggest bcp discouraging naptr records for UDP, make default transport
TCP.
Dean Recap: suggestions to yank 515,516, clarify congestion vs
fragementation. Suggest BCP on tcp usage, add more to connection-reuse
to encourage tcp.
JDR: Need to expand connection-reuse. More important to encourage TCP,
requires only for specific usages.
More discussion on why this is not just about MESSAGE.
What would scope of tcp encourage doc? Jdr: PS with normative behavior.
Allison: TCP is the right transport for much of what we are talking
about. Need long-lived connections, proxies just have to learn to do
that. Likes bcp or ps that gathers all the threads, gets naptr stuff
right, etc.
Call for volunteers to work on said document.
Long lived connections also needed for TLS point of view.
RFC 3312 Updates (Gonzalo)
(Manyfolks)
Cannot downgrade with answers—must use new offer. UA cannot downgrade
qos of a direction that it does not have info about.
Assumptions change with session mobility (changing endpoint of media
stream.) UAs should be able to downgrade in an answer, and even if they
don’t have info about it.
Need to change a couple of tables in 3312, minor normative text
changes. Backwards compatible with 3312.
How should we proceed? Individual vs wg item?
ADs suggest wg item if no objections. No objections.
Conclusion: adopt draft as wg item, negotiate milestone.
Publish (draft-ietf-sip-publish-01) (aki)
Mostly out of open issues. Thread about r-uri vs to. Consensus r-uri.
Need more text clarifying etag usage. Etag usage slightly different
than HTTP. Many docs for a resource, each has separate etag. Etag like
a receipt, must present receipt whenever updating.
Should etag be updated on every publish? Aki: same mechanism as http,
but the usage scenarios are different.
Conclusion: If different semantics than HTTP etag, we should rename.
Need to investigate differences.
Should we talk about default rate of publication? Aki suggests to
inherit the rate limit defined in event package.
Lots of discussion over whether this makes sense.
Conclusion: Send concrete suggestions to list.
Out of time…
Request History (Mary)
Lots of editorial changes, re-writing for clarity.
Document dependent on separate security draft (middle to end?)
Fix bug in Reason description.
Issue: r-uri captured anytime request is forwarded. Proposal: Only add
reason for history entries added due to retargeting.
Privacy proposal: information not included when there are privacy
considerations. (when uas sets session or header level privacy)
Next steps: complete flow detail. Do we want to fold reqs into doc as
front matter? Request more mailing list feedback. Dependency on mid-end
security draft.
Presentation of applicability to voicemail.
What now? Proceed with this? Concrete proposal for nearly 3087 approach
to vm routing from Cullen.
Robert: does not think it will have legs, will give reasons in email.
Turning into a perserverance race.
RJS: Applications will not work if not implemented. Optionality is
handwaving. We are avoiding fight over whether proxy’s must
participate. Market forces will require all proxies to support.
Ben: Suggest stronger language to suggest applications gracefully
degrade in absence of history.
General consensus: Work should continue, but more thinking about
optionality needed. RJS and Mary to talk offline.
Non-invite (RJS)
Problem not specific UDP.
Alternatives: a: keep current non-invite, with small tweaks.
B: radical surgery—allow non-invite to pend. Remove timer F. All
problems remived. Cancel becomes meaningful. Retran rules don’t change.
Can get chatty. Bw compatible. Forces invite uas level state at
intermediates.
A: reduce probability of loosing reace, reduce useless traffic, address
delayed vs no response. No non-100s to NITs. Allow 100 after it will
not damage lost message recovery. (after T2 with udp, whenever with
tcp). No 408 to non-invite. Proxies Don’t forward stray responses to
non-invite.
A3: Umpove uas knowledge of remaining time (Dave O hates it.)
A4: strengthen 3263 chacing lang. Make the success caching suggestion
SHOULD.
A5: try again later behavior.
Dave Oran: Why no 3 way handshakes?
Hum on B: inconclusive. Hum on do nothing: no-one. Hum on part of A:
inconclusive. Hum on no clue: deafening.
Conclusion: need more understanding—take to list.
GRUUs (Jonathan)
Reqs in sipping, solution proposed in sip.
GRUU parameters returned on register contacts., parameter contains a
URI that will route to the contact. User part construction up to local
policy—could use it to hold state allowing stateless behavior at
registrar.
Mechanisms for generating multiple gruus for same seed gruu and grid
param. Good for apps when unique gruus used to correlate things.
Rohan: Doc should mention stateless behavior possible, but don’t
include sample algorithm. Otherwise will require security area review.
JDR: Afraid they will do it wrong without guidance—mixed feelings.
Fluffy: possible to show example algo with no encryption.
Open Issues:
Gruu lifetime management. Can a gruu change during a registration? No,
gruu is good for lifetime of registrations, refreshes get same gruu.
Need guarantee of difference between registrations? Probably no,
discuss on list.
Dialog reuse—no longer a need with gruu. Should gruu spec deprecate
dialog resuse if both peers support gruu? (Impacts refer, other
subscribe usage).
Conclusion: Do not address in gruu spec, address in other drafts, put
pressure on future work to avoid dialog resuse.
Gruu interferes with e2e signaling. UA can try to generate a local
gruu, could use ice-like mechaninsm to decide if it is reachable.
Propose to add to draft, but never try to put local address in contact
header without using the mechanism.
Chair suggestion: Put statement about not using local gruu in gruu
draft, put “iceing” in separate draft. JDR agreed.
Adam: MUST NOT use locally generated gruu is too strong. JDR:
Definition of local gruu is one with a different domain part than AoR,
MUST does not apply to Adam's examples.
Join Header (Rohan)
No comments in wglc. Room shows interest, but no one has implemented.
Wants some comments on list before sending to IESG.
Refer semantics (Rohan)
draft-olson-sipping-refer-extensions
draft-mahy-sip-remote-cc
3515 says you can use arbitrary URIs in refer-to. What does this mean?
How do you authorize? (i.e. How do you know what to do with a
particular URI?)
Need to determine way to distinguish between a receiver that does not
understand what you want it to do, and one that requires more
credentials, etc.
<list of semantics for various semantics using various URI schema
with various contexts like in or out of dialog>
Likely that existing implementation only understands transfer. Need to
understand what each scenario means.
Jonathan: Is this equivalent to specifying fixed services? If we have
to specify all the services/features, then the refer approach has
failed.
How do you put refer requests in a context? Dialog reuse? Separate
GRUUs? Explicit refer-to header parameters?
Eric Burger: May require per-scheme semantics in addition to context.
Paul K: Need more than context—how do you know what an endpoint will do
with a particular URI scheme?
Dave O: Not useful for authorization, because referee cannot decide if
issuing the request could be bad. Another motivation that is relevant
is to determine how to render the UI for the action.
Rohan asks for concrete alternatives.
RJS: this does not mean fixing refer, it means adding something new to
it.
How do we proceed? Refer for other than transfer unlikely to work on
today’s UAs. Rohan suggests defining semantics for baskets of
functionality. Use option tags to make sure they are supported. Propose
explicit dialog parameters for refer-to. Provide guidance for remote
call control vs. remote UI invocation.
Take discussion to list. Interested parties to contact rohan and try to
reach consensus.