90 likes | 232 Vues
SIP Torture Tests. Robert Sparks dynamicsoft SIPPING – IETF58. Significant Rewrite. Removed tests based on deprecated 2543 features (such as absolute times in Expires) Added tests focusing on 3261
E N D
SIP Torture Tests Robert Sparks dynamicsoft SIPPING – IETF58
Significant Rewrite • Removed tests based on deprecated 2543 features (such as absolute times in Expires) • Added tests focusing on 3261 • Increased rigor on tests of escaping, non-ascii UTF-8, long or out-of-range values, and protocol extension points • Added detail to discussion of each message • SDP tests have been removed (to appear in an mmusic sdp-torture test draft) • Conformed to ID-Nits
Reducing Ambiguity • Introduced new markup • allOneLine • hex • repeat • Added bit-accurate archive • Base64 encoded zip file of the real messages • Filename indicated in the “Message Details” line of each example.
Created ReusableTools • I-D encoded and bit-accurate messages are built from a common source. • Content-Length is automatically calculated (when requested). • Designed to integrate easily with xml2rfc.
Teasers <allOneLine> !interesting-Method0123456789_*+`.%indeed'~ sip:1_unusual.URI~(to-be!sure)&isn't+it$/crazy?,/;;* :&it+has=1,weird!*pas$wo~d_too.(doesn't-it) @example.com SIP/2.0 </allOneLine> Expires: 1<repeat count=100>0</repeat> Contact: <sip:user@host129.example.com> ;expires=280297596632815
Teasers <allOneLine> SIP/2.0 200 = 2**3 * 5**2 <hex>D0BDD0BE20D181D182 D0BE20D0B4D0B5D0B2D18FD0BDD0BED181D182D0BE20D0B4 D0B5D0B2D18FD182D18C202D20D0BFD180D0BED181D182D0 BED0B5</hex> </allOneLine> SIP/2.0 4294967301 better not break the receiver
Open Issues • There are some production bugs • Message filenames didn’t make it into the draft as intended • <hex> expansions in the bit-accurate files aren’t accurate • All messages are new or heavily edited and need careful review
Open Issues • There are questions about specific messages in the open-issues section of the draft. These need list attention. One is reasonable to discuss here: • Are the long-value examples in 3.1.1.7 long enough?
Future Work • Should the messages be normalized to support automation? • Reusing common names for the initiator and recipient • Making some identifier (Call-ID) unique to assist with debugging