Offer/Answer Usage

1
Offer/Answer Usage

• draft-sawada-sipping-sip-offeranswer-01
• IETF-67 7-Nov-2006
• P. Kyzivat, for Takuya Sawada

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

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

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/cur
  rent/msg11309.html

5
Issues

• Terminology
• SDP that isnt an offer/answer
• When to be prepared to receive media
• Commit/Rollback of offer/answer

6
Issue Terminology SDP that isnt 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.

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

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

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.

10
Example 1 Commit / Rollback of offer/answer
11
Example 2 Commit / Rollback of offer/answer
12
Example 3 Commit / Rollback of offer/answer
(alert)
13
Example 4 Commit / Rollback of offer/answer
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.

15
Race between PRACK 200 OK
16
Next Steps

• Make planned changes
• Reach consensus on issues on sipping list
• Issue new version as WG draft
• Hopefully, WGLC before IETF-68