SIP Test Messages

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.

test1.txt

This message is a correctly formatting SIP message. It contains:

test2.txt

This message tests support for Proxy-Require and Require. It is a request that contains both headers, listing new features. Proxies and clients should respond with a 420 Bad Extension, and an Unsupported header listing these features.

test3.txt

This message contains unknown schemes in the Request URI, To, From and Contact headers of a request. A server should probably return a not found error; but other behaviors are acceptable.

test4.txt

This message is a registration request with an expiration year of 2040. This makes sure that a server doesn't crash on seeing a date past Y2038. The correct behavior is probably to limit the lifetime to some configured maximum.

test5.txt

This is a UAS test. It is a request that includes an Accept header without SDP. The UAS should respond with an error.

test6.txt

This is a UAS test. It is a request that includes a body of a non-SDP type. The UAS should respond with an error.

test7.txt

This request message contains a new method, NEWMETHOD. A proxy should forward this using the same retransmission rules as OPTIONS or BYE. A UAS should reject it with an error, and list the available methods in the response.

test8.txt

This message is nearly identical to test7. It is a request with a new method, but with a CSeq method tag which does not match. A proxy should either respond with an error, or correct the method tag.

test9.txt

This message is a REGISTER request with an unknown authorization scheme. The server should do something reasonable, such as rejecting the request.

test10.txt

This message contains two requests, separated by a bunch of whitespace. Since the message exceeds the length indicated in the Content-Length header, the message should be rejected. (Multiple SIP requests per UDP packet are no longer allowed.)

test11.txt

This message contains no Call-ID, From, or To header. The server should not crash, and ideally should respond with an error.

test12.txt

The message contains a request with an extra Call-ID and To field. The server should not crash, and should ideally respond with an error.

test13.txt

This message contains an Expires header which has illegal values for a number of components, but otherwise is syntactically correct.

test14.txt

This message is a response with a 2nd Via header of 255.255.255.255. The top Via header will need to be modified to represent the address of the server. On receiving this response, the top Via header is stripped and the packet forwarded. Since the next address is the broadcast address, it causes the packet to be broadcast onto the network. A smart server should ignore packets with 2nd Via headers that are 255.255.255.255 or 127.0.0.1. At the very least it should not crash.

test15.txt

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.

test16.txt

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...

test17.txt

This is a request message with a negative value for Content-Length. The server should respond with an error.

test18.txt

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.

test19.txt

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.

test20.txt

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.

test21.txt

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.

test22.txt

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.

test23.txt

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.

test24.txt

This INVITE is legal and has a Request-URI with a SIP URL containing escaped characters.

test25.txt

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.

test26.txt

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.

test27.txt

This OPTIONS request is legal despite there being no LWS between the display name and < in the From header.

test28.txt

This OPTIONS request is legal despite there being extra LWS between the display name and < in the From header.

test29.txt

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.

test30.txt

This is a legal INVITE but the message content has long since expired.

A server should respond 408 (Timeout).

test31.txt

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).

test32.txt

This is a legal REGISTER message where the Contact header contains a SIP URL with an escaped header within it.

test33.txt

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.

test34.txt

This is a legal message that contains long values in many headers.

test35.txt

This is an illegal and badly mangled message.

A server should respond 400 with an appropriate reason phrase if it can. It may just drop this message.

test36.txt

This is a legal message with a large number of SDP attributes and a long telephone subscriber Request-URI

test37.txt

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.

test38.txt

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.

test39.txt

This is a legal INVITE where the To and From header contain display names that contain multiple tokens but are unquoted,

test40.txt

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.

test41.txt

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.

test42.txt

This is an illegal INVITE as the SIP Protocol version is unknown.

The server should respond to the request with a bad version error.


Last updated  by Neil Deason
Last updated by Henning Schulzrinne