The new bis

The new bis

www.dynamicsoft.com9th SiPiT

4 Dec 2001

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


4 Dec 2001

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 Dec 2001

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


4 Dec 2001

New Structure Semantically oriented

Present SIP as a layered protocol Message layer Transport layer Transaction layer Transaction users

Message layer Self explanatory – message formats

Transport layer Manages persistent connections Listens for requests and responses Via rules for sending responses, inserting received param


4 Dec 2001

New Structure Transaction Layer

Reliability Request/Response Matching ACK generation for non-INVITE

Transaction Users Manage dialog/session semantics INVITE-200


4 Dec 2001

Outline1. Intro

2. Overview of Functionality

3. Terminology

4. Overview of Operation

5. Structure of the Protocol

6. Definitions

7. SIP Messages

8. General UA Behavior

9. Canceling Requests

10. Registrations

11. Querying for Capabilities

12. Dialogs

13. Initiating a Session

14. Modifying a Session

15. Terminating a Session

16. Proxy Behavior

17. Transactions

18. Transport

19. Security

20. Common Message Components

21. Headers

22. Response Codes

23. SRV

24. Examples

25. BNF


4 Dec 2001

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


4 Dec 2001

INVITE Client FSM |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|<--------------+

| | +-----------+


4 Dec 2001

INVITE Server FSM |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|<---------------+ | | +-----------+


4 Dec 2001

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


4 Dec 2001

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


4 Dec 2001

Big changes to –05 (so far) CANCEL and ACK contain the same Route header fields as

their associated request.


4 Dec 2001

What’s not stable? SRV functionality will change

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


4 Dec 2001

Next steps Closing 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

Information Resource Robert Sparks+1.972.473.5467sip:[email protected]:[email protected]

Documents

The new bis