Re: [reSIProcate-users] Handling TCP calls
Hi Scott,
Thanks for getting back to me on this.
I'm still using reSIP 1.3 (I know, I know) so I think it'll have to be a core code change.
Rather than modifying the mLocalContact variable itself, I can check the mRemoteTarget for a transport after the return from Helper::makeResponse in Dialog::makeResponse and only add the transport to the actual response header. That way I'm not modifying any of the stored data, so I should have less opportunity to bugger stuff up. (I could be being overly paranoid as well).
WRT the question as to how to route the response, when I had this problem initially, I couldn't figure out why I wasn't receiving an ACK for my 200 OK response to the initial INVITE. I wiresharked my interface and saw that the ACK was coming back over UDP. I googled this, and came across a discussion from November 2003 with the subject, "SIP over TCP"
https://lists.cs.columbia.edu/pipermail/sip-implementors/2003-November/005718.htmlThe last person on this states:
"Because the ACK is an independent transaction and the contact is a pure IP
address, the transport layer for ACK must be UDP (see RFC3263).
If the user agent would like to be reached via TCP, it should put in the
contact the transport=TCP."
It was from that that I figured out that I needed to put transport=tcp into my 200 OK response.
I've no idea if this is still relevant 8 or so years later.
I really don't have any useful thoughts on your question, I'm afraid.
Regards,
Ruadhri.
On Wed, Mar 24, 2010 at 1:41 PM, Scott Godin
<sgodin@xxxxxxxxxxxxxxx> wrote:
Hi Ruadhri,
This is a great question. DUM's current position is that if you used the request uri to reach me in the first place, so it should be appropriate for use in in-dialog routing as well.
If you only have one transport and ip address / hostname you may want to change your work around to use the Profile::setOverrideHostAndPort - however you will need the code from SVN head in order to get the tranport=tcp parameter to properly copy over from the OverrideHostAndPort setting to the contact header. This should fix the problem for you without modifying the core stack code.
Besides the case you have brought up, another issue with DUMs current scheme is that an entity could have used an "outbound proxy like" setting to reach us, and the address in the request uri may not be relevant for use as a Contact address for future in-dialog routing by the far end.
I'm thinking it may make sense to let the stack fill in the contact address, as it does for UAC invite requests, by only setting mLocalContact to sip:<user> as we do for UAC requests. We can pull the user from the request line if present, or the To header.
Can anyone foresee any issues with this change?
One issue I can see is that DialogEventStateManager uses mLocalContact (Dialog::getLocalContact) to populate dialog event info bodies, and it will want the entire contact header (with host/ip and port filled out). Looking at the code this is apparently a current issue for UAC requests today anyway. I was originally thinking we could solve this by populating the Dialog::mLocalContact variable after the transport layer has filled in the contact header and store the complete populated uri using MessageDecorators. However after reviewing the code further, the DialogEventStateManager is accessing mLocalContact before the messages hit the wire. Any thoughts on solving this one are appreciated.
Scott
Hi,
I'm having a problem with reSIProcate's handling of inbound TCP calls.
For TCP calls that I'm receiving, the initial INVITE Contact header contains a "transport=tcp" parameter, but the request line does not:
INVITE
sip:someone@xxxxxxxxxxxxxx SIP/2.0
Contact: <sip:another@xxxxxxxxxxxxxx:31090;transport=TCP>
In Dialog.cxx the contact is set to the URI in the RequestLine (line numbers from release 1.6):
l. 112: mLocalContact = NameAddr(request.header(h_RequestLine).uri());
And the mRemoteTarget is set to the Contact:
l. 96: const NameAddr& contact = request.header(h_Contacts).front();
...
l. 100: mRemoteTarget = contact;
In the Dialog::makeResponse(SipMessage& response, const SipMessage& request, int code) method, Helper::makeResponse is called with mLocalContact:
l. 988: Helper::makeResponse(response, request, code, mLocalContact);
Thus, when the 200 OK response is sent, the Contact line in that is:
SIP/2.0 200 OK
Contact: <
sip:someone@xxxxxxxxxxxxxx>
In my case, the originating call reverts to UDP and I don't see any more SIP messaging from them (I'm only listening on TCP).
Is this a bug in reSIProcate, or is it a problem with my originating call?
To get around this, I've modified where Dialog.cxx sets the mLocalContact to:
mLocalContact = NameAddr(request.header(h_RequestLine).uri()); // update later when send a request
if (contact.uri().exists(p_transport)) {
mLocalContact.uri().param(p_transport) = contact.uri().param(p_transport);
}
This seems to work ok for me: my Contact header containing responses now have a "transport=tcp" parameter. Is there anything I should be worried about?
Thanks,
Ruadhri.
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/