Download
slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Mary Barnes (WG co-chair) Gonzalo Camarillo (WG co-chair) Oscar Novo (WG secretary) PowerPoint Presentation
Download Presentation
Mary Barnes (WG co-chair) Gonzalo Camarillo (WG co-chair) Oscar Novo (WG secretary)

Mary Barnes (WG co-chair) Gonzalo Camarillo (WG co-chair) Oscar Novo (WG secretary)

127 Views Download Presentation
Download Presentation

Mary Barnes (WG co-chair) Gonzalo Camarillo (WG co-chair) Oscar Novo (WG secretary)

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Mary Barnes (WG co-chair) Gonzalo Camarillo (WG co-chair) Oscar Novo (WG secretary) DISPATCH WG IETF-76

  2. Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: the IETF plenary session, any IETF working group or portion thereof, the IESG or any member thereof on behalf of the IESG, the IAB or any member thereof on behalf of the IAB, any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 5378 and RFC 3979 for details. A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements. A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public.

  3. Agenda – Tuesday 09:00-11:30 09:00-09:15 Status and agenda bash (chairs) 09:15-09:45 Session Recording(Leon Portman/Andrew Hutton) 09:45-10:15Disaggregated media(Salvatore Loreto) 10:15-10:45Alert-Info URNs (Laura Liess) 10:45-11:15Reason in Responses (Roland Jesske)

  4. DISPATCH WG Status • Four topics to be discussed: • Session Recording • Disaggregated media • Alert-Info URNs • NGN reason • Three topics spawned adhocs for detailed discussions: • Identity (Monday) • Domain Registration (Thursday, 11:45-13:00) • SIP-XMPP (Friday, 13:00-15:00, Cattleya West) • Proposed WGs under discussion on mailing list : • Call Control for UUI Status: charter refined post-IETF-75 • Overload. WG charter under discussion.

  5. Identity Adhoc - Summary • Do we agree we have a problem? • Unanimous Agreement that we do have a problem. • If we have a problem, what should be the next step? • No point in mapping solutions until we all agree on requirements. • Next step is to work the requirements until we have better agreement. • Who is willing to be involved in ongoing work (e.g., drafting, reviewing, proposing solutions…)? • Several folks indicated interest and willingness • Is it appropriate to keep this as a DISPATCH topic and try to take more positive steps at IETF#77? • Need to actively work on the topic between now and IETF-77.

  6. Call Control for UUI (CCUS) Status New proposed charter text sent to the list for discussion Changes based on feedback at IETF-75 and mailing list discussion Discussion on DISPATCH list on charter scope and focus is ongoing More feedback welcome No revisions of requirements or mechanism drafts Need to finish charter discussion so we can get back to this interesting work

  7. SIP Overload Control • SIP Overload Control WG Charter Proposal • Objective of the proposed working group is to develop mechanisms for SIP overload control. Two complementary approaches: • Preventing overload in SIP servers by adjusting the incoming load to a level that is acceptable for this server. • Preventing overload in SIP servers by distributing load control filters to SIP servers that throttle calls based on their destination. • Status: feedback addressed • Mailing list: SIP Overload Control Three drafts on SIP Overload Control • draft-ietf-sipping-overload-design-02 • draft-hilt-sipping-overload-07 • draft-shen-sipping-load-control-event-package-03 Expert review on current drafts (reviewers welcome!) Next step: charter WG?