1 / 16

Clarification of Offer/Answer Usage in SIP: A Summary from IETF-67

This document serves as a comprehensive clarification on the usage of the offer/answer model in the Session Initiation Protocol (SIP), consolidating insights from various RFCs, folk wisdom, and informal discussions. It aims to guide the community by outlining existing issues, terminology challenges, and areas needing further review. No normative changes are proposed, but several future work recommendations are noted, including enhanced guidelines for handling offers received after offerless INVITE requests, and better terminology definitions.

thu
Download Presentation

Clarification of Offer/Answer Usage in SIP: A Summary from IETF-67

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Offer/Answer Usage draft-sawada-sipping-sip-offeranswer-01 IETF-67 7-Nov-2006 P. Kyzivat, for Takuya Sawada P.Kyzivat, IETF-67 SIPPING WG

  2. Overview / Scope • Intended as a clarification on offer/answer usage • (BCP? Informational?) • Consolidates material from many sources: • RFCs 3261, 3264, 3262, 3311, 3312 • Captures folk wisdom and informal agreements reached through list discussions • Includes no normative changes • Recommend future work that does make normative changes P.Kyzivat, IETF-67 SIPPING WG

  3. Status • Has already been valuable as resource in answering questions that come up frequently. • Some planned clarifications and additions yet to be incorporated. • A few significant open issues need to be addressed. • Has received limited review & comment • Needs a broader and more thorough review P.Kyzivat, IETF-67 SIPPING WG

  4. Planned Clarifications & Additions • New section of guidelines for constructing offer after receiving offerless INVITE • Clarify that a reliable provisional to an invite w/ offer need not carry an answer • Clarify that a PRACK may carry an answer only if it confirms a response containing an answer. • Clarify handling of unacceptable offers in responses. • Recommend future work to define how to reject offer in PRACK without rejecting the PRACK itself. • For details, see • http://www1.ietf.org/mail-archive/web/sipping/current/msg11309.html P.Kyzivat, IETF-67 SIPPING WG

  5. Issues • Terminology • SDP that isn’t an offer/answer • When to be prepared to receive media • Commit/Rollback of offer/answer P.Kyzivat, IETF-67 SIPPING WG

  6. Issue: Terminology – SDP that isn’t an offer/answer • What do you call the SDP in an unreliable provisional response? • The lack of consistent terminology makes discussion about behavior difficult. • In the draft we have chosen to call this a “preview” of the offer or answer. P.Kyzivat, IETF-67 SIPPING WG

  7. When to be prepared to receive media • Some alternatives: • When the offer or answer is sent • When a “preview” of the offer/answer is sent • Proposal: pass the buck • Consider early media a separate subject • Let it be handled independently P.Kyzivat, IETF-67 SIPPING WG

  8. Issue: Commit / Rollback of offer/answer • If an offer/answer initiated by a reINVITE • is completed prior to the completion of the reINVITE transaction, • and the reINVITE subsequently fails, • Is the offer/answer rolled back to the pre-reINVITE state? • Corollary issue: multiple offers/answers followed by failure (precondition resolution). • No concensus on this issue P.Kyzivat, IETF-67 SIPPING WG

  9. Issue: Commit / Rollback of offer/answer • Potential resolutions: • Each answer is committed when it is received reliably. • No going back if the reINVITE fails. • Nothing is committed until the reINVITE succeeds. • Candidate new state is built from all offers and answers. • Discarded on failure, • Committed on success of reINVITE. P.Kyzivat, IETF-67 SIPPING WG

  10. stable audio call reINVITE (offer high BW codec) PRACK 183 (unresolved preconditions) 200 (PRACK) 580 (INVITE) can’t get BW Example 1: Commit / Rollback of offer/answer P.Kyzivat, IETF-67 SIPPING WG

  11. stable audio call reINVITE (offer high BW codec) PRACK 183 (unresolved preconditions) 200 (PRACK) can’t get BW 580 (INVITE) UPDATE (offer) Example 2: Commit / Rollback of offer/answer P.Kyzivat, IETF-67 SIPPING WG

  12. stable audio call reINVITE (offer, add video) PRACK CANCEL 180 (answer, reliable) 200 (PRACK) 200 (CANCEL) 487 (INVITE) Example 3: Commit / Rollback of offer/answer (alert) P.Kyzivat, IETF-67 SIPPING WG

  13. stable audio call reINVITE (offer, add video) PRACK (alert) 200 (PRACK) 180 (answer, reliable) (reject) 403 (INVITE) Example 4: Commit / Rollback of offer/answer P.Kyzivat, IETF-67 SIPPING WG

  14. Issue: Commit / Rollback of offer/answer • Observation: • The use cases for this are obscure • Cases examined can be handled so as to avoid the problem. • Conjecture: this is always so. • Can someone provide counter example? • Possible Resolution: • Best practices that prevent the case from arising. P.Kyzivat, IETF-67 SIPPING WG

  15. INVITE (offer 1) PRACK 183 (answer 1, reliable) 200 (PRACK) 180 (no offer, reliable) 200 (no offer) 200 (INVITE) PRACK (offer 2) Race between PRACK & 200 OK P.Kyzivat, IETF-67 SIPPING WG

  16. Next Steps • Make planned changes • Reach consensus on issues on sipping list • Issue new version as WG draft • Hopefully, WGLC – before IETF-68 P.Kyzivat, IETF-67 SIPPING WG

More Related