Answer-Mode and Alert-Mode Extensions Dean Willis Andrew Allen

Background Requirements to support diagnostic and loopback sessions Requirements to support push-to-talk over cellular sessions from OMA

Current Proposal Answer-Mode header with 4 possible values =Auto -- Please Answer Automatically, but Manual is OK =Manual -- Please Answer Manually, but Auto is OK =AutoReq -- Must Answer Automatically or Reject =Manual Req -- Must Answer Manually or Reject Alert-Mode header with 2 possible values =Normal -- Please Alert the called User (Ring) =Null -- Please Do Not Alert Called User We also have supporting option tags and media feature tags.

Issue #1: OMA’s MAO Short for “Manual Answer Over-ride” Same semantic as AnswerMode=Auto, but more stongly emphasizes the caller’s desire for an automatic answer. May require a higher-level of caller authorization than does a regular call. Use case: The taxi dispatcher uses this to “wake up” a taxi driver who has set his phone to not answer automatically on “normal” PTT calls.

Proposal: Parameterize Answer-Mode header, Two Values: Auto: Please answer automatically Manual: Please answer manually Optional Parameters: Req: behavior indicated by header is required, and if you can’t do it, please reject this call. Emp: behavior indicated by header is emphasized, and the caller wants you to give it higher priority. Examples: for MAO: Answer-Mode=Auto;Emp for loopback: Answer-Mode=Auto;Req

Issue: Request vs Response Currently use same headers and value set in request and response directions: Request values ask for behavior. Response values report behavior. Originally used different in each direction, but was asked to change. Have been asked to change back. Proposal: Leave as is.

Issue: Use in REFER OMA wants to include in REFER requests in order to affect the resulting INVITE Proposed: Add this to draft