RE: [reSIProcate] port number in contact, howto
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@xxxxxxx]
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@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
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
--- Begin Message ---
Christian_Gavin@xxxxxxxxxxxx wrote:
> Hi,
>
> I am testing the basic_register project under DUM.
>
> I am trying to change the default port from 5060 to 5065 by doing:
>
> ...
> DialogUsageManager clientDum;
> clientDum.addTransport(UDP, 5065);
> ...
>
> Unfortunately this only changes the source port but not the destination
> port (I sniffed packets with Ethereal). I want to REGISTER to an outbound
> proxy that is on port 5065. I have no problem REGISTERing on a proxy that
> is on the default port 5060.
>
> Thanks for any help on this!
You can do this several different ways:
1. Set up a DNS SRV record for your domainname.
_sip._udp.example.com -> 0 0 5065 proxy.example.com
2. set an outbound proxy in the profile
Profile profile;
Uri ob;
ob.host() = "proxy.example.com";
ob.port() = 5065;
profile.setOutboundProxy(ob);
3. use a preloaded route
SipMessage& reg = dum.makeRegister(target);
reg.header(h_Routes).push_front(NameAddr(ob));
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
--- End Message ---