1. The new bis

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
Goal: Preserve bis-04 normative content

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 prepared new outline and defines mapping of existing text to new outline (early Sep.)
Sections assigned to each writer

4. How was it done? Iterative approach utilizing bugzilla and cvs
First rewrite of each section done mid-September
Several cycles of cross section review and revision
Detailed verification of preservation of MUST/MAY/SHOULD
Brutally painful!
Deviations captured in changes section
bis-05 complete and submitted 10/26/01

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

6. New Structure Transaction Layer Transaction Users Reliability
Request/Response Matching
ACK generation for non-INVITE
Transaction Users
Manage dialog/session semantics
INVITE-200

7. Outline 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

8. Transport Layer Changes
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

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

10. INVITE Server FSM |INVITE |pass to TU, send 100 INVITE V
send response
| | from TU
| | Proceeding| |send response
>| |<
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|<
| |

11. 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

12. Other changes Collected BNF BNF now uses explicit LWS
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
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
Merged requests detected only at endpoints
Serverfeatures integrated
100rel will be integrated
SDP extracted to a separate I-D

13. Big changes to –05 (so far)
CANCEL and ACK contain the same Route header fields as their associated request.

14. What’s not stable? SRV functionality will change Route/Record-Route
Under discussion with IESG
Likely to be much simplified (no merging of transports)
Route/Record-Route
Loose routing
Additional rigor and explanatory text needed
Registration section
Security section

15. Next steps Closing open issues Major open issues:
Explicitly called out in bis-05 where possible
Currently all being tracked in Bugzilla
49 open issues, vast majority are minor
Major open issues:
Loose source routing, proxy route processing
Multicast operation
Maximum messages sizes
SRV
Target completion to send to IESG before 2002

16. Information Resource Robert Sparks +1.972.473.5467