Re: [reSIProcate] SipStack not sending the message to correct address
Thanks for the quick reply.
What is the correct solution?
Should I change the transaction ID every time
I resend the invite to another Server?
Is there any good solution to generate new
transaction ID?
Best Regards,
Janari Põld
Byron Campen wrote:
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