[reSIProcate-users] Send a response to a destination other than the source of the request

["Lee, Allen" <allenl@xxxxxxxxxxxx>]

Hi,

 

I am currently using Resiprocate 1.7 as the SIP stack for my server. Is there a way to cause the SipStack to send the response for a request to a destination port other than the source port of the request?

 

The specific scenario I am interested in is where a UDP client application connecting to my server has separate client (outbound) and server (inbound) ports. The client sends requests to my server from its client port, but it expects responses to go to its server port.

 

For example, let’s say the client is running on client-host with client port 1111 and server port 2222. My server is running on server-host port 5060 (for both inbound and outbound traffic). The transport type is UDP. Here is scenario that I want to support:

 

   1) Client sends a SIP request from client-host:1111 to server-host:5060. The Via header of this request contains “client-host:2222” to indicate that server should respond to this address.

   2) Server receives the request on server-host:5060 from client-host:1111

   3) Server creates the response and sends it to client-host:2222 from server-host:5060.

 

The problem that I’m having is in (3). The server’s SipStack sends the response back to client-host:1111 instead of client-host:2222 specified in the Via header. What I observed is that the server’s TransactionState for the request has its “mResponseTarget” set to the actual socket it received from (client-host:1111) instead of the value in the Via header. Thus, the responses will not go to the client’s server port.

 

Is there a way we can hard wire the response to go to a particular destination port? So far I’ve tried the following with mixed success:

 

   1) Use response->setForceTarget(“client-host:2222”) – This causes “assert(target.transport)” to fail in TransportSelector.cxx. I believe the reason is because setForceTarget() will specify the destination host and port for the target, but it does not specify the transport that it should be set from.

   2) Modify the rport value in the Via header of the response – This seems to work, although I had some difficulty in getting the rport “mHasValue” flag to set correctly. One reason why I’m not too fond of this solution is because it seems to be using rport for something that it wasn’t necessarily intended for.

 

Any help or insight would be much appreciated.

 

Thanks,

Allen