First login?
Lost password?
 
 
rsplib-discussion AT lists.franken.de 
RSPlib Discussions

Text archives Help


[RSPlib-Discusssion] fail-over problems


Chronological Thread 
  • From: "Marjan Bozinovski" <marjanb AT cpk.auc.dk>
  • To: <rsplib-discussion AT sctp.de>
  • Subject: [RSPlib-Discusssion] fail-over problems
  • Date: Tue Sep 10 23:17:01 2002
  • List-id: RSPlib Discussions <rsplib-discussion.sctp.de>
Hi,
 
In my SIP client application I have included a fail-over mechanism. For instance, if the application does not receive a response to a particular request after a timer expiration, the request has to be resent to another active pool element. In principle, my ultimate goal is if the ASAP level does the fail-over by using a notification either:
a) from the SCTP layer that the message could not be delivered to the peer endpoint or
b) from the ASAP user layer using timer mechanisms as it is at the moment.
 
Now, the problem is the following. Whenever a timer activated per SIP request fires, it is a signal for a failure, and therefore a fail-over is made by using the existing function connectToPoolElement() (in examplepu.c). Here is what I notice:
First, it prints on the screen that the connection to the second PE is successfully established and connectToPoolElement() is finished. But, when seeing the packets with Ethereal I realize that the SCTP association is actually not established. On the contrary, the SCTP client side sends an INIT but immediately after that it sends an ABORT in which it reports zero error causes with the T bit set to 0. Due to the abortion, the SCTP association has never been established although connectToPoolElement() notifies successful association startup.
 
I also expected that the SCTP association with the previous SCTP endpoint will be shutdown, but that does not happen.
 
After the connectToPoolElement(), I put sendToPoolElement(), but naturally it only says "writing to data socket failed".
 
I hope that I described this problem clearly.
 
Best regards,
Marjan

Archive powered by MHonArc 2.6.19+.

Top of page