reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] SipStack not sending the message to correct address

Simply changing the Request-Uri on the original request and resending is invalid. This is because both requests will have the same transaction id. It appears that there is a bug in TransactionState::processClientInvite() that will allow mMsgToRetransmit to be overridden by any request from the TU, regardless of what state the transaction is in (ie, sending a new INVITE with the same transaction-id is causing state-corruption in the stack). This is what is causing the assert, and this probably should be fixed to disallow override of mMsgToRetransmit. 

Best regards,
Byron Campen


Hey,

I am writing a SIP proxy using resiprocate library.
The proxy is running on 192.168.200.1 and
two SIP servers on 192.168.200.2 and 192.168.200.3.

Following is the scenario that I want.

  Client         Proxy      Server1      Server2
    |    INVITE    |           |            |
1.  |  ----------> |  INVITE   |            |
2.  |              |  -------> |            |
    |              |    500    |            |
3.  |              |  <------- |            |
    |              |    ACK    |            |
4.  |              |  -------> |            |
    |              |           |  INVITE    |
5.  |              |  --------------------> |
    |            ..........                 |

Step 1
Proxy receives invite from client, adds via and record-route
header and changes the request-uri (sets the Server1 ip address
in request-uri)

Step 2
Proxy sends the invite to Server 1, using method
sendTo(SipMessage, Uri, TransactionUser) in SipStack.

Step 3
Server1 responds with 500

Step 4
Proxy (SipStack) sends automatically ACK to Server1.

Step 5
During step 1 Proxy saved the received invite into memory and
now Proxy changes the request-uri (sets the Server2 ip address
in request-uri). Now if the Proxy tries to send the message to Server2
using sentTo(SipMessage, Uri, TransactionUser) method, the SIP message
is actually sent to Server1.

Why is the stack sending the message to server1??


The Server1 responds again with 500 and after that the stack gets
Assertion Failure and the ABORT signal is sent to the proxy application 
and the app shuts down.

I added code to TransactionState.cxx method
processClientInvite(resip::TransactionMessage*) to print out
the msg and mMsgToRetransmit messages. Here is a snippet from the log.
INFO | 20070302-175232.043 | | | RESIP:TRANSACTION | 0 | 3057712048 | 
TransactionState.cxx:797 |
--------------------------- msg BEG ---------------------------------
SipResp: 500 tid=4b941154408e538aae1822d1ee5fa4ed cseq=INVITE
contact=192.168.200.2:5060 / 1 from(wire)
--------------------------- msg END ---------------------------------
INFO | 20070302-175232.043 | | | RESIP:TRANSACTION | 0 | 3057712048 | 
TransactionState.cxx:798 |
--------------------------- mMsgToRetransmit BEG
---------------------------------
SipReq:  INVITE service@xxxxxxxxxxxxx:5060
tid=4b941154408e538aae1822d1ee5fa4ed cseq=INVITE
contact=sipp@xxxxxxxxxxxxxx:5061 / 1 from(tu)
--------------------------- mMsgToRetransmit END
---------------------------------
sbcd: TransactionState.cxx:799: void
resip::TransactionState::processClientInvite (resip::TransactionMessage*): 
Assertion `mMsgToRetransmit->method() == ACK' failed.
To conclusion I have a list of servers (Server1 ... ServerN) and the proxy should send the received invite to Server1 if the server returns 500 the the proxy should send the same INVITE to Server2 and so on, until the proxy gets 
a 200 from ServerX.
Am I doing something wrong? Or how can I send the same message to another 
ServerX if the Server1 responded with 500.


Janari Põld

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

Attachment: smime.p7s
Description: S/MIME cryptographic signature