error 437: Mismatched allocation: wrong transaction ID

[IvanBelyakoff]

Hello

Initially my implementation for p2p relayed communication was to create allocations from both clients to each others addresses. The process was:

1. 1st client sends allocation request, it gets its reflexive and relayed address.
2. 1st client sends its addresses to the signalling server
3. 2nd client sends allocation request, it gets its reflexive and relayed address.
4. 2nd client sends its addresses to the signalling server
5. On receiving each others' addresses from the signalling server, both clients send bind channel requests.
6. Upon success, clients exchange data.

It works OK for my environment, but for some other environments it does not work and I see errors in turnserver log, like "Error 437, Wrong transaction ID", and clients don't receive data from each other.

So i am worried, if this error can be due to having 2 channels for the same 5-tuples and my implementation is wrong and I need only 1 channel between the clients, or this is due to something else?

If I need only 1 channel, then I don't understand how does the peer learns its ip addresses if it does not send allocation request to the coturn server? And if the peer should just start sending plain data to the client's reflexive address without any TURN allocation, binding channels, etc?

I appreciate your help

[misi]

How many allocation needed depends on your NAT/Firewall environment and client privacy settings.
IMHO it is valid to have 2 allocation one for each client.

Can you explain more what is the real difference between your environments?
From error for me it seems that same socket is attached to multiple session..
Do you use any loadbalancer or proxy like thing? That may manipulates the client connections source ip:port.. Just my 2 cents..

[IvanBelyakoff]

But 2 allocations and hence 2 channel bindings makes these 2 channels have same 5-tuples. Can it cause any issues?

The different environments are basically different countries with different internet providers. For me it works, even if I use mobile carrier's internet for both clients, or if I use high speed fiber internet.
In another country it does not work reliable both ways. But clients connect to the same TURN and signalling servers on the same VDS.

I have one more weird log that may be related to the issue, session may be created for the port only once, but different sessions report the peer refreshed lifetime, even after peer is deleted:

842721: IPv4. Local relay addr: 138.138.138.138:51040
843828: session 000000000000009348: peer 138.138.138.138:51040 lifetime updated: 600
843839: session 000000000000009348: peer 138.138.138.138:51040 deleted
843859: session 000000000000009349: peer 138.138.138.138:51040 lifetime updated: 600
843870: session 000000000000009349: peer 138.138.138.138:51040 deleted
843879: session 000000000000009350: peer 138.138.138.138:51040 lifetime updated: 600
843890: session 000000000000009350: peer 138.138.138.138:51040 deleted
843900: session 000000000000009352: peer 138.138.138.138:51040 lifetime updated: 600
843911: session 000000000000009352: peer 138.138.138.138:51040 deleted
843920: session 001000000000008679: peer 138.138.138.138:51040 lifetime updated: 600
843931: session 001000000000008679: peer 138.138.138.138:51040 deleted

This is what I grepped by port number. Does it make any sense to you?

I am not using any loadbalancer I am aware of and no proxy.

[misi]

I am wondering how could be the source port from the 5 tuple is the same for two allocation?
I don't understand still your case..
AFAIU new allocation use new source port. Am I miss something?

[IvanBelyakoff]

I think I misunderstood 5-tuple concept and thought that 5-tuple is the same if it has same ip addresses and ports and protocol, no matter if ips and port are source or destination. You comment now makes sense to me.
Anyways, I solved the problem today - external ports used to send data to signalling server were closed very soon, and clients/peers did not receive updates from signalling server if ports used for allocations have been changed, hence they tried to use old allocation which was no longer valid.
For me it worked OK, because my ports were open for long enough to stay open until keep alive messages to signalling server were sent again.

Thank you for assisting