60 likes | 82 Views
Explore the complexities of implementing PRACK according to RFC 3262, its limited usage, bug resolution issues, and the need for further development or deprecation. Discover key challenges faced by User Agents and protocol progress influenced by independent transactions.
E N D
Implementation of PRACK Rohan Mahyrohan@ekabal.com
PRACK Implementation • RFC 3262 has been around since June 2002 • Very few implementations outside of IMS and PacketCable • IMS “lite” will remove PRACK from spec • Complexity cited as main reason not used • Have only begun to shake out implementation bugs at SIPit • Well behind other specs of similar age
Why is it so hard/complex? • Several places where UA needs to queue/delay sending messages to allow state machine to synchronize: • can’t send subsequent 18x until first PRACK received • can’t send 200 to INVITE until answer received (could be in PRACK). • UAS needs retransmit queue of 18x responses • Initial RSeq can start from an arbitrary value • Adds 3 new offer/answer combos: • INVITE/18x • 18x/PRACK • PRACK/200 • Fundamental Problem: an independent transaction (PRACK/200) influences progress of another transaction. • Resulting state machine is “non-obvious”
What do we do? • Make minor update to PRACK spec? • Write replacement for PRACK spec? • Live without? • Deprecate UDP? ;-) • Other suggestions?