[reSIProcate] port number in contact, howto
Hello,
I am setting up a simple test, similar to basiccall.cxx. When my
app sends out responses (180,200) to an initial invite, the contact field
doesn't contain the port that I setup in the DUM. The ACK then comes in on
port 5060. I believe it comes in on 5060 because the contact field in the
180 and 200 responses does not contain any port number, it is just "Contact:
<sip:12345@xxxxxxxxxxxxx>" How is the contact field populated and what
would I need to do to get this to work? Thanks.
DialogUsageManager* dumUas = new DialogUsageManager();
dumUas->addTransport(UDP, 12010);
NameAddr uasAor("sip:12345@xxxxxxxxxxxxx:12010");
Profile uasProfile;
dumUas->setProfile(&uasProfile);
dumUas->getProfile()->setDefaultFrom(uasAor);
riday 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