[reSIProcate] SipStack not sending the message to correct address

[Byron Campen]

	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 at 192.168.200.3:5060
> tid=4b941154408e538aae1822d1ee5fa4ed cseq=INVITE
> contact=sipp at 217.159.142.96: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 at list.resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070305/a53da805/attachment.bin>