ble at this location in the future. This response could be used by a service provider when a user cancels their service. 5.4.12 411 Length Required This response code has been removed from RFC 3261 but is defined in RFC 2543. This response can be used by a proxy to reject a request containing a mes- sage body but no Content-Length header field. A proxy that takes a UDP request and forwards it as a TCP request could generate this response, since the use of Content-Length is more critical in TCP requests. However, the response code is not very useful since a proxy can easily calculate the length of a message body in a UDP request (it is until the end of the UDP packet) but can- not with a stream-oriented transport such as TCP. In this case, a missing Content-Length header field would cause the message body to go on indefinitely, which would generate a 513 Message Too Large response instead of a 411 Length Required. SIP Response Messages 5.4.13 413 Request Entity Too Large This response can be used by a proxy to reject a request that has a message body that is too large. A proxy suffering congestion could temporarily generate this response to save processing long requests. 5.4.14 414 Request-URI Too Long This response indicates that the Request-URI in the request was too long and cannot be processed correctly. There is no maximum length defined for a Request-URI in the SIP standard document. 5.4.15 415 Unsupported Media Type This response sent by a user agent indicates that the media type contained in the INVITE request is not supported. For example, a request for a video conference to a PSTN gateway that only handles telephone calls will result in this response. The response should contain header fields to help the UAC reformulate the request. 5.4.16 416 Unsupported URI Scheme The 416 Unsupported URI Scheme response is new to RFC 3261 and is used when a UAC uses a URI scheme in a Request-URI that the UAS does not understand. For example, if a request URI contains a secure SIP (sips) scheme that a proxy does not und