TCP packetization is entirely irrelevant to SIP. The messages are
extracted from the stream on a byte-by-byte basis and processed
independently. As long as message (a) is correctly *framed*, problems
with it should not result in (b) being ignored.
BUT, framing of SIP messages in TCP is tricky. You have to find the
Content-Length header, and parse it correctly. It must also find the
beginning of the body. Its possible that the recipient was unable to do
that in the presence of the syntax error. So perhaps it botched up
finding the next message.
Some implementations use special (simplified) parsing to find the C-L
header and the beginning of the body without actually parsing the other
headers. They can be resistant to syntax errors in the headers. But
perhaps this implementation doesn't work that way.
The bottom line of course is that the syntax error shouldn't be there.
Arguing about exactly how recovery should work in the presence of errors
is of dubious utility.
Thanks,
Paul
Prakash Mariasusai, TLS-Chennai wrote:
> Hi,
>
> We would like to know the behavior of s SIP Client in the below error
> scenario:
>
> An UAS, on receiving an INVITE, sends a TCP packet containing two SIP
> responses in ONE Packet. Here the first SIP Response has a PARSE error,
> while the SECOND SIP Response contains a valid SIP Response.
>
> Note that in the first Response, the content-length is CORRECTLY formed,
> whereas other header - Cseq is malformed (it is "Cseq: 1234 1234" ,
> instead of "Cseq: 1234 INVITE")
>
>
> UAC UAS (erroneous test UA)
> |-----INV (tcp) ------------------------------>|
> | |
> |<==100+200 in 1 TCP pkt=======================|
> |
> a) UAC to Drop 100 and accept 200? (or)
> b) UAC to Drop 100 and 200
>
> Our behavior Vs Others:
> ----------------------
> We expect the UAC to accept the SECOND response (a),
> but some implementations drop the whole TCP packet due to PARSE error in
> first SIP message. (b)
>
> The RFC does NOT clearly say about this.
>
> Please comment on which is the correct expected behavior for the UAC.
>
> Thanks,
> Prakash
>
> DISCLAIMER:
> -----------------------------------------------------------------------------------------------------------------------
>
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only.
> It shall not attach any liability on the originator or HCL or its affiliates.
> Any views or opinions presented in
> this email are solely those of the author and may not necessarily reflect the
> opinions of HCL or its affiliates.
> Any form of reproduction, dissemination, copying, disclosure, modification,
> distribution and / or publication of
> this message without the prior written consent of the author of this e-mail
> is strictly prohibited. If you have
> received this email in error please delete it and notify the sender
> immediately. Before opening any mail and
> attachments please check them for viruses and defect.
>
> -----------------------------------------------------------------------------------------------------------------------
>
> _______________________________________________
> 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
