SIPCORE, 80th IETF, Prague, Czech Republic
Date: Wednesday,
March 30, 2011
Location: Prague, Czech Republic
Chairs: Adam Roach, Paul Kyzivat
Note Taker: John Elwell
Minutes Editor: Paul Kyzivat
Jabber Scribes: Cullen Jennings, Ben Campbell
Jabber Transcript: TBD
Agenda and Status
Presenter: Adam Roach, Paul
Kyzivat
Slides: http://www.ietf.org/proceedings/80/slides/sipcore-1.pdf
Document: draft-ietf-sipcore-rfc3265bis
Adam Roach: Event header field parameters issue has arisen - what is the scope of the parameters.
Document: draft-ietf-sipcore-event-rate-control
Robert Sparks: Some minor corrections needed.
Location Conveyance with SIP
Presenter: James Polk
Slides: http://www.ietf.org/proceedings/80/slides/sipcore-0.pdf
No issues raised.
Delivering request-URI and parameters to UAS via proxy
Presenter: Mary Barnes
Slides: http://www.ietf.org/proceedings/80/slides/sipcore-3.pdf
Document: draft-ietf-sipcore-rfc4244bis-04
Issue of when to add Reason header field. Proposal to add for all responses except 100 and 2xx responses. No objection to this.
John Elwell: I did not review all sections, so some sections have not been reviewed. Need additional reviewers.
|
Hadriel Kaplan, Andrew Allen and Dale Worley volunteered to review the document. |
Cullen Jennings: It does not tell me how to USE the information.
Mary Barnes: The call flows document.
Cullen Jennings: I will review it carefully.
|
Reviews required within next few weeks. |
Keith Drage: Asked about compatibility with RFC 4244.
Mary Barnes: That is needed (there are some existing implementations) and there is some text, but I will look to improving it.
Andrew Allen: Asked what would be impact on 3GPP specifications that reference RFC 4244.
Mary Barnes: It should be possible just to change the reference to 4244bis, although the specifications and any implementations might want to take advantage of the new features in 4244bis.
On call flows document (draft-barnes-sipcore-rfc4244bis-callflows-01):
Cullen Jennings: I think we should adopt it as WG item now. But there is confusion between the two documents, and the two documents don't tell me how to use the information.
Mary Barnes: 4244bis provides a building block and does not define the services.
Cullen Jennings: Somewhere we should write down how we solve the problems this document is meant to solve.
Mary Barnes: It is in 4244bis.
Cullen Jennings: I will read it.
Keith Drage: Keep the call flows fully informative.
Mary Barnes: They are not normative.
Keith Drage: Yes, but if anything does need to be normative, it should be in 4244bis.
Martin Dolly: Agree with Mary this is a base capability and how to use it does not need to be defined any further.
Dale Worley: Comparison with REFER, we don't need to specify how you used H-I, but should specify what it means when you receive it.
Mary Barnes: Yes, and it is indeed clearly defined in terms of SIP terminology.
Dale Worley: So the approach we are taken does seem to be OK.
Only a few people have read the flows document.
|
Will take consensus call on adoption of flows document to
list, |
Proxy Feature Tags
Presenter: Christer Holmberg
Slides: http://www.ietf.org/proceedings/80/slides/sipcore-2.pdf
Document: draft-holmberg-sipcore-proxy-feature-01
Christer is only asking do we want to work on this problem, not about specific solution.
Andrew Allen: This is useful.
Christer Holmberg: In reply to a question from John Elwell, clarified that the entities concerned really are proxies, using Record-Route, and not B2BUAs. Not in a position to be able to overwrite the contact.
Cullen Jennings: Thinks Christer makes a compelling argument and would be useful also outside 3GPP context.
Chair: Does Cullen see any specific non-3GPP use cases.
Cullen Jennings: Let me go try and find some of those - there were some.
Dale Worley: Don't want to enforce the use of B2BUAs. But it would be good if a proxy could signal its capabilities differently in the two directions.
Christer Holmberg: Yes, this is something we need to be able to deal with.
Keith Drage: Fine to go and look for old use cases, but make sure they are still current.
Andrew Allen: Mentioned BLISS work where a UA might want to identify capabilities of a proxy.
Hum: those who want to add this to charter. Strong hum in favour, and nobody opposed.
|
Chair declared consensus for adopting milestone for solving this problem. |
A reasonable number of people have read the document.
Chair: Can we adopt this document?
John Elwell: We haven't discussed the technical solution.
Andrew Allen: There may be some issues that need to be addressed.
Chair: Just asking if this is roughly the right direction.
Keith Drage: Just ask on list, and give people the option of saying if there are any sections not suitable for adoption.
Andrew Allen: Happy to adopt the draft, because feature tags will be part of the solution, but not the whole solution.
Hum: Those in support of using this document as the basis for the milestone, if created. Good support, none against.
|
Chair declared consensus in room - will be taken to list. |