The files in here are test messages for SIP servers to exercise various functions. Contributed by Neil Deason, Anders Kristensen, Jonathan Rosenberg, Henning Schulzrinne.
SIP interoperabilty test event entrants are strongly encouraged to run these tests. In particular entrants to advanced scenario testing at these events will be expected to have passed all torture tests.
This is a request with the Via and Contact headers incorrect. They contain additional semicolons and commas without parameters or values. The server should respond with a Bad Request error.
This is a request message with a Content Length that is much larger than the length of the body. When sent UDP, the server should respond with an error. With TCP, there's not much you can do but wait...
This is a request message with a negative value for Content-Length. The server should respond with an error.
This is a request message with garbage after the end of the SDP included in the body. In fact, the server should treat this garbage as a second request. However, it is not even close to a valid message. The server should therefore ignore it, and forward the first message normally.
This is a request with an unterminated quote in the display name of the To field. The server can either return an error, or proxy it if it is successful parsing without the terminating quote.
This is an INVITE request with a semicolon-separated parameter in the "user" part. Outbound proxies should direct it appropriately.
The files below are additional test messages for SIP servers to exercise various functions. Comments and corrections should be sent to Neil Deason.
This INVITE is illegal because the Request-URI has been enclosed within in "<>".
An intelligent server may be able to deal with this and fix up the Request-URI if acting as a Proxy. If not it should respond 400 with an appropriate reason phrase.
This INVITE has illegal LWS within the SIP URL.
An intelligent server may be able to deal with this and fix up the Request-URI if acting as a proxy. If not it should respond 400 with an appropriate reason phrase.
This INVITE has illegal >1 SP between elements of the Request-URI.
An intelligent server may be able to deal with this and fix up the Request-URI if acting as a proxy. If not it should respond 400 with an appropriate reason phrase.
This INVITE is legal and has a Request-URI with a SIP URL containing escaped characters.
This INVITE is illegal as it the Request-URI contains a SIP URL containing escaped headers.
An intelligent server may be liberal enough to accept this. A server acting as a proxy should remove the escaped header before processing.
This INVITE contains an unknown URI scheme in the Request-URI.
A server should reject this message with a 400 response plus an appropriate reason phrase despite being able to understand the To header as a SIP URL.
This OPTIONS request is legal despite there being no LWS between the display name and < in the From header.
This OPTIONS request is legal despite there being extra LWS between the display name and < in the From header.
This INVITE is illegal as it contains a non GMT time zone in the SIP Date of the Expires header.
An intelligent server may be able to fix this up and correct the time to GMT. Alternatively this message may illicit a 400 response with an appropriate reason phrase.
This is a legal INVITE but the message content has long since expired.
A server should respond 408 (Timeout).
This is a legal SIP request with the Max-Forwards header set to zero.
A proxy or gateway should not forward the request and respond 483 (Too Many Hops).
This is a legal REGISTER message where the Contact header contains a SIP URL with an escaped header within it.
This is an illegal message as the REGISTER request contains a SIP URL with an escaped header but it is not enclosed in <>
A server should respond 400 with an appropriate reason phrase.
This is a legal message that contains long values in many headers.
A server should respond 400 with an appropriate reason phrase if it can. It may just drop this message.
This is a legal message with a large number of SDP attributes and a long telephone subscriber Request-URI
This REGISTER contains a contact where the 'user' parameter should be interpreted as being a contact-param and not a url-param. The register should succeed but a subsequent retrieval of the registration must not include "user=phone" as a url-parameter.
This register contains a contact where the 'user' parameter is a url-param. The register should succeed and a subsequent retrieval of the registration must include "user=phone" as a url-parameter.
This is a legal INVITE where the To and From header contain display names that contain multiple tokens but are unquoted,
This is an illegal invite at the display names in the To and From headers contain non-token characters but are unquoted. A server may be intelligent enough to cope with this but may also return a 400 response with an appropriate reason phrase.
This should be rejected with 400. Section 4.1 lists SIP version as a literal and doesn't say anything about ignoring leading zeros. As an example of why rejecting it is a good idea, consider version numbers like 2.1 and 2.01 - they are unlikely to refer to the same version.
The server should respond to the request with a bad version error.