SIPCORE, 82nd IETF, Taipei, Taiwan

Status and Agenda

Agenda accepted as proposed. Status presented as shown in slides.

Requirements for a mechanism to indicate proxy capabilities

Robert Sparks: Asked about difference between REQ-8 and REQ-9

Christer Holmberg: Not sure - will clarify with Dale

Robert Sparks: REQ-10 should be that the indications must be visible.

Robert Sparks: REQ-8 needs to be rewritten to be on the mechanism, not on existing entities

Robert Sparks: REQ-13 should say need to avoid collisions of names

Chairs asked who had read the document

Chairs asked if anyone thought more requirements were needed

Hadriel Kaplan: What about users of this mechanism

Cullen Jennings: document doesn't say what is this going to be used for, and how could it be used?

Robert as individual: one use case is useful, the other one is opaque

Robert Sparks: is there a significant architectural impact of this extension? Still vague even after working on requirements. Answer affects whether it needs to be done in SIPCORE or just anywhere. Question: is reasonable use to indicate Energy Star compliance?

Christer Holmberg: OK if doesn't affect session at all

Robert Sparks: Is this stated clearly in requirements?

Christer Holmberg: REQ-8 and REQ-9 do this.

Hadriel Kaplan: Could just state this in draft

Cullen Jennings: Not sure you really want this in all use cases. How to decide on uses

Hadriel Kaplan: Could have expert review on uses

Gonzalo Camarillo: Superset or subset of existing feature tags?

Christer Holmberg: Only new feature tags, not existing ones

Robert Sparks: Which requirement rules out History-Info as the mechanism

Christer Holmberg: Direction usage requirement makes History-Info difficult. Also can't use in REGISTER

Mary Barnes: History-Info can be used in REGISTER

Hadriel Kaplan: History-Info can be inserted by elements that can not use this mechanism since they not in the dialog

Cullen Jennings: Is that in requirement?

Hadriel Kaplan: We could add this requirement to say session stateful or B2BUA only use this mechanism

Christer Holmberg: Could say elements using this mechanism must Record-Route

Robert Sparks: Sounds like a requirement on the mechanism

Chairs: Any objections to this new requirement?

None raised.

New requirement will be added to the document to reflect this agreement.

Chairs: We can now move onto the mechanism and move this doc to WGLC

Feature-Caps mechanism

Cullen Jennings: Don't call all non-UAs B2BUAs

Cullen Jennings: These aren't feature tags so create new IANA registry. Need better guidelines on how and when they are used, or need IETF consensus expert review

Robert Sparks: Agree with Cullen. Which working group should work on this? Does it need architectural review by SIPCORE?

Christer Holmberg: Registry must reference spec that says what the feature means

Hadriel Kaplan: We need expert review. Hard to decide if Energy Star example is valid

Cullen Jennings: Hard to write expert review text. This approach might evolve.

Jon Peterson: Worried about interoperability. Need conservative registration process

Adam Roach as individual: How does this work if UAs understand tags? Will behavior change?

Christer Holmberg: Can include option tags in feature tags

Hadriel Kaplan: Example of switching handoff feature.

Robert Sparks: Example of intermediary storing dialog state, allowing UA to subscribe to get this information. Is this valid?

Christer Holmberg: This is a valid use case. It doesn't change the existing dialog.

Jon Peterson: This doesn't relate to SIP option tags since intermediaries and proxies cannot do this.

Cullen Jennings: Another SDO could use these feature caps to circumvent IETF option tag processes. What prevents this?

Robert Sparks: Can tags be parameterized or include a URI?

Christer Holmberg: If URI is needed, then a URI parameter would be used

Hadriel Kaplan: Expert review could solve this.