[reSIProcate-users] Handling TCP calls

[Ruadhri Howman <ruadhri@xxxxxxxxx>]

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.