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.