Reported by Joerg Ott}, edited slighty by Dean Willis
Agenda Bash
-----------
-> accepted
Workplan
--------
Session Timer (bis update) -> Apr
Caller (dto.) -> May
Preconditions -> on track
Privacy -> on track
Media Auth
MIB -> needs bis update
- reasonable to make it by May?
REFER -> security update; to IESG by May
MESSAGE -> ready for WGLC?
- C: hopefully sooner
Path: header
-> needs rev from editor (May)
NAT awareness
-> author will update
-> JDR: is a SIPPING draft?
SIP Privacy & Security req to IESG
-> June may be too optimistic
-> user vs. network provided privacy
-> hgs: what is this going to buy us
-> jp: want to go beyond requirements
-> Keith: how does this relate to what needs to go through sipping want
-> something concrete to work form here
SIP over SCTP
-> Gonzalo has the token
-> basically ready
-> can be earlier than July
Revise milestones towards draft standard sip
other charter items
- state cookies
-> RM: Dean's draft is perfectly fine
Other bodies looks at this kind of work, too
-> JDR: Nobody does it because everyone uses Record-Route:
-> Flemming: ...
-> Comment: ...
-> JDR: new loose-routing mechanisms enables this
-> Comment: you cannot change state; you can only push state with RR
-> JDR: well, if there is more than just dialog message routing
document this use
-> BR: thinks it is useful
-> HGS: How does the scheduling work? Do we want to do conssecutive
or parallel WGLCs?
-> BR: will do something also these lines; a few parallel ones ok
Want to get out what has been hanging around (as long as they
match the charter)
-> C: need a priority list
-> JDR: bundling is helpful; focus the discussion
-> BR: it may help if drafts actually relate to one another
- guidelines to authors for SIP extensions
-> JDR: perceived useful; little feedback though
-> AM [Allison]: get sip-change BCP'ed first
What to do with:
- 3pcc -> sipping
- conferencing-models -> sipping
- app-components
- sip-vxml
(3261)
SIP change process
------------------
Allison Mankin
people said there is no need to control the extensions
counter-example: imagine the Replaces:
- 4 weeks IETF last call
- publish as BCP
brief review
- what do you need a standards track document for?
- some further description
- P- headers; need to be an RFC
(but don't require SIPPING requirements, SIP change process)
allow for Informational, Experimental
HGS: naming characteristic
problem with backward compatibility
1. Naming issue: disagree
2. Applicability issues: agree
is there a need to couple the two?
can we avoid the name change as soon as a standards track RFC
comes up
Practical problem: registration w/o standards track RFC (P- process)
- no advantage of labeling the header this
- changing the name is going to cause problems
People are that the P- shall be possible to be kept when moving towards a standards track document.
AM: P- is anti-press release
Additional wording needed about compliance to IETF standards.
DO: Naming conventions vs. algorithmic consequences
JDR: option tag names have no relation to header name
HGS: emphasizes what JDR just said
The text needs clarification here.
UPDATE method
-------------
Jonathan Rosenberg
*** Open issues:
Glare with PRACK
- UPDATE only specifies glare resolution with itself
- but may occur also with PRACK
-> use same mechanism
-> don't want to reject PRACKs
-> UPDATE wins? [NO]
-> extend the existing mechanism to work with PRACK
-> bad, see above
-> avoid: can't send UPDATE if PRACK is outstanding
-> (was supposed to say that in the first place, but it doesnt)
-> one can still respond with a 488 to PRACK
Proposal: the last one
wording is needed to really clarify this; will be done
Other issues:
- is 493 (undecipherable) a repairable code?
- proposal: include it
add text saying it retries if it would otherwise retry that response
-> accepted
Generate 155 instead of 4xx
- MAY or SHOULD
- SHOULD would work better with ignorant proxies
-> accept the SHOULD proposal
C: what about the reason header?
JDR: yes, this is why it is there. But this work here is time
sensitive; so we vaguely point to it wihtout explicitly
requiring it; reason header is on a slower track
alternatives: sigfrag; ...
RM: suggestion: pulling 155 out of the draft
GC: leave both (UPDATE and 155) together
no consensus whatsoever; need further discussion
Manyfolks Open Issues
---------------------
Gonzalo Camarillo
current approach
- framework for preconditions
- current vs. desired status
- two status types: e2e; segmented
*** Open Issues
- unknown preconditions
- Require: understanding the framework; vs. understanding a certain prec. type
- What to do?
- refuse the offer and provide a list of what you understand
- accept the offer if the preconditions can be met w/o your intervention
- no immediate conclusion
Reason Codes for SIP
--------------------
Gonzalo Camarillo
- same functionality needed in several WG items
- ISUP/SIP mapping, BYE/CANCEL (manyfolks, offer/answer), HERFP, 3PCC,
JDR: fork request to several phones; phone behavior may depend on
the reason (e.g. entry in callback list or not)
DO: two separate pieces of information
- why something was sent vs.
- why something was sent to some particular entity
Keith: there are several headers that feed back information why
something went wrong
JDR: no overlap; we need to convey information in addition to
the status line/request line
EB (Eric Burger): This is H.450 all over again?
Comment: There is some overlap; should be considered
HGS: ...
C: What about the SIP change process here?
Jiri: How do I get additional information into replies?
Can we include a "location" in addition? Which hop sent this?
GC: This is another problem; you also have this without the reason
header just for general error conditions.
Decide on what to do?
- do we have sufficiently crisp requirements? do we understand what
we try to do? only then we can move ahead.
- or don't we? if not, need to go through sipping
50:50 humming result
chairs: do a more crisp requirements document
we have some requirements;
DO: different hum proposal
- we MUST NOT address the issue of identity
-> out of scope
-> accepted
requirements document to be done quickly
resolution to be provided before Yokohoma
SIP Media Auth
--------------
Flemming Andreasen
Overview of changes
- informational -> P-Media-Authorization
- applicability statement
SIP proxy and PDP must be part of same admin domain
- updates rules when to add a header
- additional security considerations
- do not pass PMA header to untrusted entities
- entities may need to look into the SDP
- misc editorial changes
Open Issues
- none so far
JDR: security considerations section needs more substance
authorize media for what?
- authenticate the caller?
- authenticate the callee?
FA: you do not have to authenticate the callee; it's like telephony;
the caller pays for everything
JDR: just want more discussion on this in the security considerations
section
Currenly in WGLC
chairs: pretty much done.
will move forward
SIP Extensions for Instant Messages
-----------------------------------
Ben Campbell
- 5th version
- remove cpim mapping
- update references
- would like to include in 3rd bundle
(- do not touch message sessions!)
Open issues
- need editorial changes
- anything else?
one further revision with editorial stuff; then WGLC
let's get this done real soon!