[reSIProcate] port number in contact, howto

[Scott Godin]

The stack fills in the Contact header (all except the user portion) - based
on which transport the message gets sent on.  This is determined via DNS
server entries (I have attached another email that gives more detail).
Normally the transport with port 5060 would be chosen (if one is present).

You have a few options (besides those listed in the attachment):
1.  Ensure you only have one transport added with the port you want.
2.  Specify an override host and port in the profile.  This will override
the information that the stack would otherwise fill in.



-----Original Message-----
From: Justin Matthews [mailto:justin.matthews at ivr.com] 
Sent: Friday, January 21, 2005 2:26 PM
To: 'reSIProcate List'
Subject: [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 at 172.16.10.192>"  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 at 172.16.10.192: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 at list.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel at list.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel

-------------- next part --------------
An embedded message was scrubbed...
From: Jason Fischl <jason at purplecomm.com>
Subject: Re: [reSIProcate] Setting a different UDP port?
Date: Mon, 15 Nov 2004 14:59:46 -0500
Size: 1924
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20050121/631cbc02/attachment.eml>