Hi, I had a major advance.
I was able to "solve" this issue avoiding closing and opening the socket several times (this is not a solution but allowed me to isolate the problem).
The main issue still remains:
Why is closing/opening a socket several times a problem?
How is this related to the error I am getting?
Why does this error only occurs with the sendto() operation?
Do I have to perform any test to ensure that the sockets have emptied all transmit buffers?
Regards

Can you elaborate more on what you stated earlier?
What is this application supposed to be doing, and what drives (ie causes) the reconfiguration?

It would also be helpful if you were to describe how many servers there are (ie. how many call bind()), and then how many clients are there. Are messages that are received by the server broadcasted to all clients?

Sometimes it is easier to help someone if they explain the problem they are trying to solve, not HOW they are trying to solve it.

Hi, I am performing a VoIP server that controls a SIP stack and VoIP DSP's.
There's only one server, just one calls bind and for testing purposes I have only two clients.
I am simulating a call so packets received from one channel is routed to the other channel and the other way around.
In the process of establishing a call a re-configuring the channel, the channels where closed and opened (which in turns lead to close/opening the channel again).

How does the server keep track of its two clients? Surely one client sends a packet to the server and you register that client as "Client 1". Do these packets "fall on the floor" until the server receives a packet from "Client 2"?

It would be interesting to get more details to see if I can develop an application that mimics what you are trying to accomplish.

------------

EDIT: Actually, when I think about it further, my question above is quite silly. Surely the two clients, when launched, register with the server. When Client 1 attempts to "dial" a telephone number, the server references the number to the IP address of the other client being called. The server then notifies this other client that it has an incoming call. When Client 2 answers the call, the server "connects" the two clients so that they can share data (or voice).

Does your system work something like what I have described above?

Hi, there's an structure on the server that it is updated when a packet is received, and the server has knowledge of all related data from the clients.
From the server point of view, as soon as it receives a packet from a client sends it to the other client and the opposite.
I tried to simulate this problem without success, the packets have fixed size of 172 and they have a very low latency in order to fulfill audio requirements.
Do you have any hints that may assist in finding the problem? Any relevant data to be checked for each socket, ... I am running out of ideas

PS: I have 2 other sockets: management and debugging.
The most important is the debugging socket that sends to my laptop every packet sent by the server (so each packet that the server send to each client is also sent to my laptop).
I never had any problem with this socket and since all sockets use the same functions (open/close(send/receive) the only difference I found was that the sockets for each client were closed and opened several times

I do not fully understand why a client must open/close it's socket, unless it is maintaining two sockets... one to stay in communication with the server, the other when communicating with another client.

The same socket can be re-used for communicating with one or more clients; the only thing that differs when performing a sendto() would be the destination address.

Anyhow, for a simplistic design, I would have the client register with the server, perhaps periodically(say 1-6 times every minute) just to ensure that it is still there/available. The server would maintain a table of registered clients. When a client wishes to communicate with another client, it sends the server a request; this request could contain an IP address of the other client, or some other identifying information, such as a telephone number. If the latter, then the server would need to correlate the telephone number with the remote client's IP address.

Anyhow, once the server sorts out that ClientA wants to talk to ClientB, the server can send a packet to ClientB that emulates a "ringing" action. When/if ClientB answers, then the server can send a packet to each client that contains the other client's IP address. That way, ClientA will know ClientB's IP address, and similarly ClientB will know ClientA's IP address. Then just let the packets fly between these two clients.

When the client is done communicating with the other client, then it should go back to listening for other connection requests from the server. Or perhaps you could allow for "N-way" calling, thus allowing a client to communicate with 2 (possible more) other clients.

I would suggest that you attempt your initial design using a state diagram. From there, think about what data structures your server will need to maintain data about available clients. Your clients will need to know how to reach the server, and if necessary, maintain a table of all other client IPs that it may be communicating with.

As for sending packets with a particular latency in an effort to regenerate voice data, well that is beyond the scope of my knowledge. I know nothing about telephony, other than how to use it as a "tool" to communicate with peers.