[EMAIL PROTECTED] wrote:
> Hi,
>
> RFC 3261 section 18.3 Framing says
> "In the case of message-oriented transports (such as UDP), if the
> message has a Content-Length header
> field, the message body is assumed to contain that many bytes. If there
> are additional bytes in the transport
> packet beyond the end of the body, they MUST be discarded. If the
> transport packet ends before the end of
> the message body, this is considered an error. If the message is a
> response, it MUST be discarded. If the
> message is a request, the element SHOULD generate a 400 (Bad Request)
> response. If the message has no
> Content-Length header field, the message body is assumed to end at the
> end of the transport packet.
>
> In the case of stream-oriented transports such as TCP, the
> Content-Length header field indicates the size of
> the body. The Content-Length header field MUST be used with stream
> oriented transports."
>
> How should a UAS behave in case it receives a message on TCP having
> content-length value
> 1] less than message body length?
> 2] greater than message body length?
>
> My understanding is that UAS should throw an error because the
> content-lenght value is incorrect.
When using TCP, if the sender screws up and includes a body that is
larger than the Content-Length says, then the recipient will see this as
a body that has been truncated based on the content-length value. This
can't be detected by sip level parsing, but *may* be detected if/when
the body is parsed, because the body is likely to appear incomplete.
And in that case, the part of the body supplied by the sender that
extends beyond the content-length value will be parsed by the recipient
as the beginning of a new message. Most likely it won't be a valid
beginning of a SIP message, and so error recovery will take place at
that point. (It won't result in an error response because there isn't a
message to respond to.)
On the flip side, if the sender includes a body that is smaller than
specified by the Content-Length header, then one of two things will happen:
- the end of the tcp stream will be detected before all the bytes called
for by the content-length have been received. In this case an error can
be generated, but a new connection will need to be established to
deliver it.
- Reading of bytes for the message will stall until the sender sends
another sip message. Then some of that message will be interpreted as
the missing part of the body. Again, at the sip level this won't cause
any problem for *that* message, but an error may be detected in the
syntax of the body if/when the body is parsed. After processing that
message, there will be an attempt to process the remaining bytes as a
sip message. Because the header of that message has already been
consumed as part of the prior body, the remainder won't be a valid
beginning of a SIP message, and so an error recover will take place.
Paul
> Please help me in these scenarios.Help will be appreciated.
>
> Regards
> Deepak
>
> *********************** Aricent-Private ***********************
>
> *********************** Aricent-Private ***********************
>
> "DISCLAIMER: This message is proprietary to Aricent and is intended
> solely for the use of
> the individual to whom it is addressed. It may contain privileged or
> confidential information and should not be
> circulated or used for any purpose other than for what it is intended.
> If you have received this message in error,
> please notify the originator immediately. If you are not the intended
> recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents of
> this message. Aricent accepts no responsibility for
> loss or damage arising from the use of the information transmitted by
> this email including damage from virus."
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
