RE: [reSIProcate] responses over TCP get lost when in the same pa cket
The message is read entirely but not added to the fifo. The source code is
not very complicated. I will try to make some time this week to fix it.
Frederik
-----Original Message-----
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Alan
Hawrylyshen
Sent: Friday, January 21, 2005 4:21 PM
To: reSIProcate List
Subject: Re: [reSIProcate] responses over TCP get lost when in the same
packet
On Jan 21, 2005, at 04:31, Jon Ringle wrote:
> On Friday 21 January 2005 06:08 am, Bayart Frederik wrote:
>> Hallo,
>>
>> I've have noticed following probleem when I'm sending messages over
>> TCP :
>> if 2 responses are arriving in the same packet, the second response
>> is not
>> passed to the transaction user. This happens in the function
>> Connection::performRead. When 2 requests are arriving in the same
>> packet,
>> there is no problem.
>>
> <snip examples>
>
>>
>> I didn't find any explanation for this in the rfc's.
>
> I believe this is addressed in RFC 3261 section 18.3, framing.
> If your seeing this behaviour on tcp, then my take is that the problem
> is with
> resiprocate. But this is just a guess. I am not completely familiar
> with the
> resiprocate stack yet, but the stack needs to keep track of partially
> received messages so that when the rest of the message arrives a
> complete
> message can be made and passed to the transaction user. The framing of
> SIP
> messages is based on the Content-Length header.
>
> HTH,
>
> Jon
Frederik and Jon;
Yes, the Content-Length is important, presuming that it is working
correctly, (and it sounds like it is, since the extra bytes message was
seen) the problem is likely in the Connection class associated with
TCP.
DEBUG | ... | Check the Debug and Stack logs, I expect you will see:
DEBUG | ... | Extra bytes after message: NNNN
DEBUG | ... | 200 RAW DATA etc...
DEBUG | ... | Connection::process setting source ... **
Trouble is I suspect the like marked with ** is missing. This appears
to be because just before the 'goto start' (!! :-) ) the mState of the
connection is not set back to NewMessage. Check and see if applying
this patch to Connection.cxx (r3821) fixes the problem you describe.
I can take a look at this, but so can Jason, Derek or Jacob (at a
working minimum) I think others are familiar with the message header
scanner and connection FSMs too.
Best wishes and hope this helps
Alan
Index: Connection.cxx
===================================================================
--- Connection.cxx (revision 3821)
+++ Connection.cxx (working copy)
@@ -196,7 +196,8 @@
mBuffer = newBuffer;
mBufferPos = 0;
mBufferSize = size;
-
+ mState = NewMessage;
+
DebugLog (<< "Extra bytes after message: " <<
overHang);
DebugLog (<< Data(mBuffer, overHang));
--
a l a n a t j a s o m i d o t c o m
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel