<sip:user@example.com:6000;
unknownparam1=very<repeat count=20>long</repeat>value;
longparam<repeat count=25>name</repeat>=shortvalue;
very<repeat count=25>long</repeat>ParameterNameWithNoValue>
</allOneLine>
<allOneLine>
F: sip:
<repeat count=5>amazinglylongcallername</repeat>@example.net
;tag=12<repeat count=50>982</repeat>424
;unknownheaderparam<repeat count=20>name</repeat>=
unknowheaderparam<repeat count=15>value</repeat>
;unknownValueless<repeat count=10>paramname</repeat>
</allOneLine>
Call-ID: longreq.one<repeat count=20>really</repeat>longcallid
CSeq: 3882340 INVITE
<allOneLine>
Unknown-<repeat count=20>Long</repeat>-Name:
unknown-<repeat count=20>long</repeat>-value;
unknown-<repeat count=20>long</repeat>-parameter-name =
unknown-<repeat count=20>long</repeat>-parameter-value
</allOneLine>
Via: SIP/2.0/TCP sip33.example.com
v: SIP/2.0/TCP sip32.example.com
V: SIP/2.0/TCP sip31.example.com
Via: SIP/2.0/TCP sip30.example.com
ViA: SIP/2.0/TCP sip29.example.com
VIa: SIP/2.0/TCP sip28.example.com
VIA: SIP/2.0/TCP sip27.example.com
via: SIP/2.0/TCP sip26.example.com
viA: SIP/2.0/TCP sip25.example.com
vIa: SIP/2.0/TCP sip24.example.com
vIA: SIP/2.0/TCP sip23.example.com
V : SIP/2.0/TCP sip22.example.com
v : SIP/2.0/TCP sip21.example.com
V : SIP/2.0/TCP sip20.example.com
v : SIP/2.0/TCP sip19.example.com
Via : SIP/2.0/TCP sip18.example.com
Via : SIP/2.0/TCP sip17.example.com
Via: SIP/2.0/TCP sip16.example.com
Via: SIP/2.0/TCP sip15.example.com
Via: SIP/2.0/TCP sip14.example.com
Via: SIP/2.0/TCP sip13.example.com
Via: SIP/2.0/TCP sip12.example.com
Via: SIP/2.0/TCP sip11.example.com
Via: SIP/2.0/TCP sip10.example.com
Via: SIP/2.0/TCP sip9.example.com
Via: SIP/2.0/TCP sip8.example.com
Via: SIP/2.0/TCP sip7.example.com
Via: SIP/2.0/TCP sip6.example.com
Via: SIP/2.0/TCP sip5.example.com
Via: SIP/2.0/TCP sip4.example.com
Via: SIP/2.0/TCP sip3.example.com
Via: SIP/2.0/TCP sip2.example.com
Via: SIP/2.0/TCP sip1.example.com
<allOneLine>
Via: SIP/2.0/TCP
host.example.com;received=192.0.2.5;
branch=very<repeat count=50>long</repeat>branchvalue
</allOneLine>
Max-Forwards: 70
<allOneLine>
Contact: <sip:
<repeat count=5>amazinglylongcallername</repeat>
@host5.example.net>
</allOneLine>
Content-Type: application/sdp
l: 150
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
3.1.1.8. Extra Trailing Octets in a UDP Datagram
This message contains a single SIP REGISTER request, which ostensibly
arrived over UDP in a single datagram. The packet contains extra
octets after the body (which in this case has zero length). The
extra octets happen to look like a SIP INVITE request, but (per
section 18.3 of [RFC3261]) they are just spurious noise that must be
ignored.
A SIP element receiving this datagram would handle the REGISTER
request normally and ignore the extra bits that look like an INVITE
request. If the element is a proxy choosing to forward the REGISTER,
the INVITE octets would not appear in the forwarded request.
Message Details : dblreq
REGISTER sip:example.com SIP/2.0
To: sip:j.user@example.com
From: sip:j.user@example.com;tag=43251j3j324
Max-Forwards: 8
I: dblreq.0ha0isndaksdj99sdfafnl3lk233412
Contact: sip:j.user@host.example.com
CSeq: 8 REGISTER
Via: SIP/2.0/UDP 192.0.2.125;branch=z9hG4bKkdjuw23492
Content-Length: 0
INVITE sip:joe@example.com SIP/2.0
t: sip:joe@example.com
From: sip:caller@example.net;tag=141334
Max-Forwards: 8
Call-ID: dblreq.0ha0isnda977644900765@192.0.2.15
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw380234
Content-Type: application/sdp
Content-Length: 150
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.15
s=-
c=IN IP4 192.0.2.15
t=0 0
m=audio 49217 RTP/AVP 0 12
m =video 3227 RTP/AVP 31
a=rtpmap:31 LPC
3.1.1.9. Semicolon-Separated Parameters in URI User Part
This request has a semicolon-separated parameter contained in the
"user" part of the Request-URI (whose value contains an escaped @
symbol). Receiving elements will accept this as a well-formed
message. The Request-URI will parse so that the user part is
"user;par=u@example.net".
Message Details : semiuri
OPTIONS sip:user;par=u%40example.net@example.com SIP/2.0
To: sip:j_user@example.com
From: sip:caller@example.org;tag=33242
Max-Forwards: 3
Call-ID: semiuri.0ha0isndaksdj
CSeq: 8 OPTIONS
Accept: application/sdp, application/pkcs7-mime,
multipart/mixed, multipart/signed,
message/sip, message/sipfrag
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKkdjuw
l: 0
3.1.1.10. Varied and Unknown Transport Types
This request contains Via header field values with all known
transport types and exercises the transport extension mechanism.
Parsers must accept this message as well formed. Elements receiving
this message would process it exactly as if the 2nd and subsequent
header field values specified UDP (or other transport).
Message Details : transports
OPTIONS sip:user@example.com SIP/2.0
To: sip:user@example.com
From: <sip:caller@example.com>;tag=323
Max-Forwards: 70
Call-ID: transports.kijh4akdnaqjkwendsasfdj
Accept: application/sdp
CSeq: 60 OPTIONS
Via: SIP/2.0/UDP t1.example.com;branch=z9hG4bKkdjuw
Via: SIP/2.0/SCTP t2.example.com;branch=z9hG4bKklasjdhf
Via: SIP/2.0/TLS t3.example.com;branch=z9hG4bK2980unddj
Via: SIP/2.0/UNKNOWN t4.example.com;branch=z9hG4bKasd0f3en
Via: SIP/2.0/TCP t5.example.com;branch=z9hG4bK0a9idfnee
l: 0
3.1.1.11. Multipart MIME Message
This MESSAGE request contains two body parts. The second part is
binary encoded and contains null (0x00) characters. Receivers must
take care to frame the received message properly.
Parsers must accept this message as well formed, even if the
application above the parser does not support multipart/signed.
Additional examples of multipart/mime messages, in particular S/MIME
messages, are available in the security call flow examples document
[SIP-SEC].
Message Details : mpart01
MESSAGE sip:kumiko@example.org SIP/2.0
<allOneLine>
Via: SIP/2.0/UDP 127.0.0.1:5070
;branch=z9hG4bK-d87543-4dade06d0bdb11ee-1--d87543-;rport
</allOneLine>
Max-Forwards: 70
Route: <sip:127.0.0.1:5080>
<allOneLine>
Identity: r5mwreLuyDRYBi/0TiPwEsY3rEVsk/G2WxhgTV1PF7hHuL
IK0YWVKZhKv9Mj8UeXqkMVbnVq37CD+813gvYjcBUaZngQmXc9WNZSDN
GCzA+fWl9MEUHWIZo1CeJebdY/XlgKeTa0Olvq0rt70Q5jiSfbqMJmQF
teeivUhkMWYUA=
</allOneLine>
Contact: <sip:fluffy@127.0.0.1:5070>
To: <sip:kumiko@example.org>
From: <sip:fluffy@example.com>;tag=2fb0dcc9
Call-ID: 3d9485ad0c49859b@Zmx1ZmZ5LW1hYy0xNi5sb2NhbA..
CSeq: 1 MESSAGE
Content-Transfer-Encoding: binary
Content-Type: multipart/mixed;boundary=7a9cbec02ceef655
Date: Sat, 15 Oct 2005 04:44:56 GMT
User-Agent: SIPimp.org/0.2.5 (curses)
Content-Length: 553
--7a9cbec02ceef655
Content-Type: text/plain
Content-Transfer-Encoding: binary
Hello
--7a9cbec02ceef655
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
<hex>
3082015206092A86
4886F70D010702A08201433082013F02
01013109300706052B0E03021A300B06
092A864886F70D010701318201203082
011C020101307C3070310B3009060355
04061302555331133011060355040813
0A43616C69666F726E69613111300F06
03550407130853616E204A6F7365310E
300C060355040A130573697069743129
3027060355040B132053697069742054
65737420436572746966696361746520
417574686F7269747902080195007102
330113300706052B0E03021A300D0609
2A864886F70D01010105000481808EF4
66F948F0522DD2E5978E9D95AAE9F2FE
15A06659716292E8DA2AA8D8350A68CE
FFAE3CBD2BFF1675DDD5648E593DD647
28F26220F7E941749E330D9A15EDABDB
93D10C42102E7B7289D29CC0C9AE2EFB
C7C0CFF9172F3B027E4FC027E1546DE4
B6AA3ABB3E66CCCB5DD6C64B8383149C
B8E6FF182D944FE57B65BC99D005
</hex>
--7a9cbec02ceef655--
3.1.1.12. Unusual Reason Phrase
This 200 response contains a reason phrase other than "OK". The
reason phrase is intended for human consumption and may contain any
string produced by
Reason-Phrase = *(reserved / unreserved / escaped
/ UTF8-NONASCII / UTF8-CONT / SP / HTAB)
This particular response contains unreserved and non-ascii UTF-8
characters. This response is well formed. A parser must accept this
message.
Message Details : unreason
<allOneLine>
SIP/2.0 200 = 2**3 * 5**2 <hex>D0BDD0BE20D181D182
D0BE20D0B4D0B5D0B2D18FD0BDD0BED181D182D0BE20D0B4
D0B5D0B2D18FD182D18C202D20D0BFD180D0BED181D182D0
BED0B5</hex>
</allOneLine>
Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923
Call-ID: unreason.1234ksdfak3j2erwedfsASdf
CSeq: 35 INVITE
From: sip:user@example.com;tag=11141343
To: sip:user@example.edu;tag=2229
Content-Length: 154
Content-Type: application/sdp
Contact: <sip:user@host198.example.com>
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.198
s=-
c=IN IP4 192.0.2.198
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
3.1.1.13. Empty Reason Phrase
This well-formed response contains no reason phrase. A parser must
accept this message. The space character after the reason code is
required. If it were not present, this message could be rejected as
invalid (a liberal receiver would accept it anyway).
Message Details : noreason
SIP/2.0 100<hex>20</hex>
Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe
Call-ID: noreason.asndj203insdf99223ndf
CSeq: 35 INVITE
From: <sip:user@example.com>;tag=39ansfi3
To: <sip:user@example.edu>;tag=902jndnke3
Content-Length: 0
Contact: <sip:user@host105.example.com>
3.1.2. Invalid Messages
This section contains several invalid messages reflecting errors seen
at interoperability events and exploring important edge conditions
that can be induced through malformed messages. This section does
not attempt to be a comprehensive list of all types of invalid
messages.
3.1.2.1. Extraneous Header Field Separators
The Via header field of this request contains additional semicolons
and commas without parameters or values. The Contact header field
contains additional semicolons without parameters. This message is
syntactically invalid.
An element receiving this request should respond with a 400 Bad
Request error.
Message Details : badinv01
INVITE sip:user@example.com SIP/2.0
To: sip:j.user@example.com
From: sip:caller@example.net;tag=134161461246
Max-Forwards: 7
Call-ID: badinv01.0ha0isndaksdjasdf3234nas
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.15;;,;,,
Contact: "Joe" <sip:joe@example.org>;;;;
Content-Length: 152
Content-Type: application/sdp
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.15
s=-
c=IN IP4 192.0.2.15
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
3.1.2.2. Content Length Larger Than Message
This is a request message with a Content Length that is larger than
the actual length of the body.
When sent over UDP (as this message ostensibly was), the receiving
element should respond with a 400 Bad Request error. If this message
arrived over a stream-based transport, such as TCP, there’s not much
the receiving party could do but wait for more data on the stream and
close the connection if none is forthcoming within a reasonable
period of time.
Message Details : clerr
INVITE sip:user@example.com SIP/2.0
Max-Forwards: 80
To: sip:j.user@example.com
From: sip:caller@example.net;tag=93942939o2
Contact: <sip:caller@hungry.example.net>
Call-ID: clerr.0ha0isndaksdjweiafasdk3
CSeq: 8 INVITE
Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bK-39234-23523
Content-Type: application/sdp
Content-Length: 9999
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.155
s=-
c=IN IP4 192.0.2.155
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
3.1.2.3. Negative Content-Length
This request has a negative value for Content-Length.
An element receiving this message should respond with an error. This
request appeared over UDP, so the remainder of the datagram can
simply be discarded. If a request like this arrives over TCP, the
framing error is not recoverable, and the connection should be
closed. The same behavior is appropriate for messages that arrive
without a numeric value in the Content-Length header field, such as
the following:
Content-Length: five
Implementors should take extra precautions if the technique they
choose for converting this ascii field into an integral form can
return a negative value. In particular, the result must not be used
as a counter or array index.
Message Details : ncl
INVITE sip:user@example.com SIP/2.0
Max-Forwards: 254
To: sip:j.user@example.com
From: sip:caller@example.net;tag=32394234
Call-ID: ncl.0ha0isndaksdj2193423r542w35
CSeq: 0 INVITE
Via: SIP/2.0/UDP 192.0.2.53;branch=z9hG4bKkdjuw
Contact: <sip:caller@example53.example.net>
Content-Type: application/sdp
Content-Length: -999
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.53
s=-
c=IN IP4 192.0.2.53
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
3.1.2.4. Request Scalar Fields with Overlarge Values
This request contains several scalar header field values outside
their legal range.
o The CSeq sequence number is >2**32-1.
o The Max-Forwards value is >255.
o The Expires value is >2**32-1.
o The Contact expires parameter value is >2**32-1.
An element receiving this request should respond with a 400 Bad
Request due to the CSeq error. If only the Max-Forwards field were
in error, the element could choose to process the request as if the
field were absent. If only the expiry values were in error, the
element could treat them as if they contained the default values for
expiration (3600 in this case).
Other scalar request fields that may contain aberrant values include,
but are not limited to, the Contact q value, the Timestamp value, and
the Via ttl parameter.
Message Details : scalar02
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP host129.example.com;branch=z9hG4bK342sdfoi3
To: <sip:user@example.com>
From: <sip:user@example.com>;tag=239232jh3
CSeq: 36893488147419103232 REGISTER
Call-ID: scalar02.23o0pd9vanlq3wnrlnewofjas9ui32
Max-Forwards: 300
Expires: 1<repeat count=100>0</repeat>
Contact: <sip:user@host129.example.com>
;expires=280297596632815
Content-Length: 0
3.1.2.5. Response Scalar Fields with Overlarge Values
This response contains several scalar header field values outside
their legal range.
o The CSeq sequence number is >2**32-1.
o The Retry-After field is unreasonably large (note that RFC 3261
does not define a legal range for this field).
o The Warning field has a warning-value with more than 3 digits.
An element receiving this response will simply discard it.
Message Details : scalarlg
SIP/2.0 503 Service Unavailable
<allOneLine>
Via: SIP/2.0/TCP host129.example.com
;branch=z9hG4bKzzxdiwo34sw
;received=192.0.2.129
</allOneLine>
To: <sip:user@example.com>
From: <sip:other@example.net>;tag=2easdjfejw
CSeq: 9292394834772304023312 OPTIONS
Call-ID: scalarlg.noase0of0234hn2qofoaf0232aewf2394r
Retry-After: 949302838503028349304023988
Warning: 1812 overture "In Progress"
Content-Length: 0
3.1.2.6. Unterminated Quoted String in Display Name
This is a request with an unterminated quote in the display name of
the To field. An element receiving this request should return a 400
Bad Request error.
An element could attempt to infer a terminating quote and accept the
message. Such an element needs to take care that it makes a
reasonable inference when it encounters
To: "Mr J. User <sip:j.user@example.com> <sip:realj@example.net>
Message Details : quotbal
INVITE sip:user@example.com SIP/2.0
To: "Mr. J. User <sip:j.user@example.com>
From: sip:caller@example.net;tag=93334
Max-Forwards: 10
Call-ID: quotbal.aksdj
Contact: <sip:caller@host59.example.net>
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.59:5050;branch=z9hG4bKkdjuw39234
Content-Type: application/sdp
Content-Length: 152
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.15
s=-
c=IN IP4 192.0.2.15
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
3.1.2.7. <> Enclosing Request-URI
This INVITE request is invalid because the Request-URI has been
enclosed within in "<>".
It is reasonable always to reject a request with this error with a
400 Bad Request. Elements attempting to be liberal with what they
accept may choose to ignore the brackets. If the element forwards
the request, it must not include the brackets in the messages it
sends.
Message Details : ltgtruri
INVITE <sip:user@example.com> SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=39291
Max-Forwards: 23
Call-ID: ltgtruri.1@192.0.2.5
CSeq: 1 INVITE
Via: SIP/2.0/UDP 192.0.2.5
Contact: <sip:caller@host5.example.net>
Content-Type: application/sdp
Content-Length: 159
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.5
s=-
c=IN IP4 192.0.2.5
t=3149328700 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
3.1.2.8. Malformed SIP Request-URI (embedded LWS)
This INVITE has illegal LWS within the Request-URI.
An element receiving this request should respond with a 400 Bad
Request.
An element could attempt to ignore the embedded LWS for those schemes
(like SIP) where doing so would not introduce ambiguity.
Message Details : lwsruri
INVITE sip:user@example.com; lr SIP/2.0
To: sip:user@example.com;tag=3xfe-9921883-z9f
From: sip:caller@example.net;tag=231413434
Max-Forwards: 5
Call-ID: lwsruri.asdfasdoeoi2323-asdfwrn23-asd834rk423
CSeq: 2130706432 INVITE
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKkdjuw2395
Contact: <sip:caller@host1.example.net>
Content-Type: application/sdp
Content-Length: 159
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=3149328700 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
3.1.2.9. Multiple SP Separating Request-Line Elements
This INVITE has illegal multiple SP characters between elements of
the start line.
It is acceptable to reject this request as malformed. An element
that is liberal in what it accepts may ignore these extra SP
characters when processing the request. If the element forwards the
request, it must not include these extra SP characters in the
messages it sends.
Message Details : lwsstart
INVITE sip:user@example.com SIP/2.0
Max-Forwards: 8
To: sip:user@example.com
From: sip:caller@example.net;tag=8814
Call-ID: lwsstart.dfknq234oi243099adsdfnawe3@example.com
CSeq: 1893884 INVITE
Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKkdjuw3923
Contact: <sip:caller@host1.example.net>
Content-Type: application/sdp
Content-Length: 150
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
3.1.2.10. SP Characters at End of Request-Line
This OPTIONS request contains SP characters between the SIP-Version
field and the CRLF terminating the Request-Line.
It is acceptable to reject this request as malformed. An element
that is liberal in what it accepts may ignore these extra SP
characters when processing the request. If the element forwards the
request, it must not include these extra SP characters in the
messages it sends.
Message Details : trws
OPTIONS sip:remote-target@example.com SIP/2.0<hex>2020</hex>
Via: SIP/2.0/TCP host1.example.com;branch=z9hG4bK299342093
To: <sip:remote-target@example.com>
From: <sip:local-resource@example.com>;tag=329429089
Call-ID: trws.oicu34958239neffasdhr2345r
Accept: application/sdp
CSeq: 238923 OPTIONS
Max-Forwards: 70
Content-Length: 0
3.1.2.11. Escaped Headers in SIP Request-URI
This INVITE is malformed, as the SIP Request-URI contains escaped
headers.
It is acceptable for an element to reject this request with a 400 Bad
Request. An element could choose to be liberal in what it accepts
and ignore the escaped headers. If the element is a proxy, the
escaped headers must not appear in the Request-URI of the forwarded
request (and most certainly must not be translated into the actual
header of the forwarded request).
Message Details : escruri
INVITE sip:user@example.com?Route=%3Csip:example.com%3E SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=341518
Max-Forwards: 7
Contact: <sip:caller@host39923.example.net>
Call-ID: escruri.23940-asdfhj-aje3br-234q098w-fawerh2q-h4n5
CSeq: 149209342 INVITE
Via: SIP/2.0/UDP host-of-the-hour.example.com;branch=z9hG4bKkdjuw
Content-Type: application/sdp
Content-Length: 150
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
3.1.2.12. Invalid Time Zone in Date Header Field
This INVITE is invalid, as it contains a non-GMT time zone in the SIP
Date header field.
It is acceptable to reject this request as malformed (though an
element shouldn’t do that unless the contents of the Date header
field were actually important to its processing). An element wishing
to be liberal in what it accepts could ignore this value altogether
if it wasn’t going to use the Date header field anyway. Otherwise,
it could attempt to interpret this date and adjust it to GMT.
RFC 3261 explicitly defines the only acceptable time zone designation
as "GMT". "UT", while synonymous with GMT per [RFC2822], is not