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 Client FSM
INVITE from TU
Timer A fires INVITE sent
Reset
A, V Timer B fires
INVITE sent -----------
t.o. to TU
--------- ---------------
Calling

--------gt --------------gt
-----------
2xx
300-699 2xx to TU
ACK sent 1xx

--------------- 1xx to TU


1xx V Timer C fires
1xx to TU
----------- t.o. to TU
---------
--------------gt
Proceeding
--------gt
--------------gt
----------- 2xx
300-699
2xx to TU
ACK sent,
resp. to TU


NOTE 300-699
V
ACK sent
----------- transitions
---------
labeled with
Completed
the event
--------gt
over the action
----------- to take


Timer D fires
-------------- -


V

-----------


Terminatedlt--------------

-----------














8
INVITE Server FSM
INVITE

pass to TU, send 100
INVITE V
send
response-----------
--------
--------101-199 from TU
Proceeding send response
-------gt
lt-------
-----------
300-699 from TU
2xx from TU
send response send response

-------------------

INVITE V
Timer G fires
send response----------- send response
--------
--------
Completed
-------gt
lt-------
-----------


ACK
-
------------------gt
Timer H fires
V
fail to TU
-----------


Confirmed


-----------


Timer I fires
-


V

-----------


Terminatedlt---------------


-----------




9
Outline

• Dialogs
• Initiating a Session
• Modifying a Session
• Terminating a Session
• Proxy Behavior
• Transactions
• Transport
• Security
• Common Message Components
• Headers
• Response Codes
• SRV
• Examples
• BNF

• Intro
• Overview of Functionality
• Terminology
• Overview of Operation
• Structure of the Protocol
• Definitions
• SIP Messages
• General UA Behavior
• Canceling Requests
• Registrations
• Querying for Capabilities

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
Other changes

• 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 cant be sent until 1xx received
• BYE cant 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

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