| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index |
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.ScottOn Wed, Mar 24, 2010 at 7:34 AM, Ruadhri Howman <ruadhri@xxxxxxxxx> wrote:
_______________________________________________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/