The new bis

1. The new bis Jonathan Rosenberg dynamicsoft

2. Why rewrite the specification? • IESG said so • RFC2543 was never the model of clarity to begin with • Bis got worse with micro-editing • Symptoms • Repitition of material in many places • No overview of operations • Structure not obvious • Decision made at August IETF to move forward full steam with a rewrite

3. How was it done? • Recruited a bis rewrite team • Jonathan, Henning editors • Added four co-authors to help write • Gonzalo Camarillo (Ericsson) • Jon Peterson (Neustar) • Alan Johnston (Worldcom) • Robert Sparks (dynamicsoft) • Coaching from Dean Willis, Brian Rosen • Project Management from Rakesh Shah • Technical writing from Jean Mahoney • Jonathan prepares new outline and defines mapping of existing text to new outline (early Sep.) • Sections assigned to each writer

4. How was it done? • First iteration done, mid-September • Five iterations follow, with reviewers assigned to specific sections • Nearing final iterations, MUST/MAY/SHOULD trackers assigned • Brutally painful! • Final draft complete and submitted 10/26/01

5. New structure • Present SIP as a layered protocol • Message layer • Transport layer • Transaction layer • Transaction users • Semantically oriented • Message layer • Self explanatory – message formats • Transport layer • Manages persistent connections • Listens for requests and responses • Via rules for sending responses, inserting received param

6. New Structure • Transaction layer • Reliability • Request/response matching • ACK generation for non-INVITE • Some big changes here • ACK-200 is officially a different transaction • ACK non-200 is part of the transaction • Same EXACT transaction machine for proxies and UA • Handling for INVITE 2xx response *NOT* part of the transaction layer!! • UA state machinery retransmits 2xx and ACK • Allows transaction machines to die instantly when 2xx received • Transitions based on timeouts, not # of retransmits, to unify machine between UDP, TCP • More aggressive transaction timeouts defined for TCP • Proper RTT estimation defined • Actual diagrams for non-INVITE transactions included

7. |INVITE from TU Timer A fires |INVITE sent Reset A, V Timer B fires INVITE sent +-----------+ t.o. to TU +---------| |---------------+ | | Calling | | +-------->| |-------------->| +-----------+ 2xx | 300-699 | | 2xx to TU | ACK sent | |1xx | +---------------+ |1xx to TU | | | | | 1xx V Timer C fires | | 1xx to TU -----------+ t.o. to TU | | +---------| |-------------->| | | |Proceeding | | | +-------->| |-------------->| | +-----------+ 2xx | | 300-699 | 2xx to TU | | ACK sent, | | | resp. to TU| | | | | NOTE: | 300-699 V | | ACK sent +-----------+ | transitions | +---------| | | labeled with | | | Completed | | the event | +-------->| | | over the action | +-----------+ | to take | ^ | | | | | Timer D fires | +--------------+ | - | | | V | +-----------+ | | | | | Terminated|<--------------+ | | +-----------+ INVITE Client FSM

8. |INVITE |pass to TU, send 100 INVITE V send response+-----------+ +--------| |--------+101-199 from TU | | Proceeding| |send response +------->| |<-------+ +-----------+ 300-699 from TU | |2xx from TU send response | |send response | +-------------------+ | | INVITE V Timer G fires | send response+-----------+ send response | +--------| |--------+ | | | Completed | | | +------->| |<-------+ | +-----------+ | | | | ACK | | | - | +------------------>+ | Timer H fires | V fail to TU | +-----------+ | | | | | Confirmed | | | | | +-----------+ | | | |Timer I fires | |- | | | V | +-----------+ | | | | | Terminated|<---------------+ | | +-----------+ INVITE Server FSM

9. Intro Overview of Functionality Terminology Overview of Operation Structure of the Protocol Definitions SIP Messages General UA Behavior Canceling Requests Registrations Querying for Capabilities Dialogs Initiating a Session Modifying a Session Terminating a Session Proxy Behavior Transactions Transport Security Common Message Components Headers Response Codes SRV Examples BNF Outline

10. Dialogs • Equivalent to call-leg from bis-04 • Call leg has been eradicated from the spec • Generalization, presence • Dialog procedures are no longer INVITE specific • Maintenance of Cseq, Route sets • Construction of mid-dialog requests • General construction guidelines

11. Collected BNF BNF now uses explicit LWS Has been validated by Robert Responses no longer need to transmitted over TCP for server transactions! Does NOT include INV-2xx CANCEL can’t be sent until 1xx received BYE can’t be sent by UAS until ACK received CR or LF alone deprecated 3xx to re-INVITE allowed and specified Merged requests OK (good, actually) Radical surgery on multicast No special treatment at ALL except deciding where to send the messages Assumes only a single respondent If there are more than one, responses look like retransmits Still needs more refinement in spec Proxies no longer forward 6xx on receipt CANCEL first, then 6xx after all responses Serverfeatures integrated 100rel will be integrated SDP extracted to separate I-D Other changes

12. Whats not stable? • Registration section needs more rigor • Security section needs a lot more rigor, a lot more explanatory text • SRV functionality likely to change • Under discussion with IESG • Likely to be much simplified (no merging of transports) • Proxy Route/maddr/dns processing still shakey