error 437: Mismatched allocation: wrong transaction ID (WebRTC)

651 views

ICEWebRTCconfigure

Skip to first unread message

kostas

unread,

Apr 15, 2016, 4:00:07 AM4/15/16

to TURN Server (Open-Source project)

I have this structure :

- Web server : Apache. it's in a LAN. It is on a pc (windows 7) which has public static ip. PC is in a network.

- Signal server: In a VM (VirtualBox Centos 6) on the same pc.

- STUN/TURN server : Coturn/turnserver. In a VM (VirtualBox Centos 6) on the same pc.

- Client A : Laptop, Vista. I use a Samsung mobile and usb tethering to get (external) internet.

- Client B :Laptop, windows 10. I use a Samsung tablet and usb tethering to get (external) internet.

I run a coturn/turnserver like this:

sudo turnserver -X xxx.xx.xxx.xx (this is my static external ip)

I have created port forward:

3479 -> 3478 for TCP

3479 -> 3478 for UTP

5348 -> 5349 for TCP

5348 -> 5349 for UTP

I use the default configuration file of coturn with these changes :

verbose

fingerprint

lt-cred-mech

realm=mycompany.org

cert=server.crt

pkey=server.key

pkey-pwd=.... (it has been omitted)

log-file=/var/tmp/turnserver.log

simple-log

I have created files server.crt and server.key and i know they are right because i can use the web admin tool which need them to run with https

I have created admin user. I have created a key for user "test4" using :

sudo turnadmin -k -u test4 -r mycompany.org -p test

and i use it to create him :

sudo turnadmin -a -b "/var/db/turndb" -u test4 -r mycompamy.org -p ......

On client :

var STUN = {

urls: "stun:xxx.xx.xxx.xx:3479" //port forward

};

var TURN = {

urls: [

"turn:xxx.xx.xxx.xx:3479?transport=udp",

"turn:xxx.xx.xxx.xx:3479?transport=tcp",

"turn:xxx.xx.xxx.xx:3479"

username : "test4",

credential : "......................", (it's the key. it has been omitted)

};

The messages, I get from coturn/turnserver are like these :

242: handle_udp_packet: New UDP endpoint: local addr 10.0.2.15:3478, remote addr 10.0.2.2:60113

242: session 000000000000000002: realm <mycompany.org> user <>: incoming packet BINDING processed, success

242: handle_udp_packet: New UDP endpoint: local addr 10.0.2.15:3478, remote addr 10.0.2.2:60075

242: session 000000000000000003: realm <mycompany.org> user <>: incoming packet BINDING processed, success

242: session 000000000000000003: realm <mycompany.org> user <>: incoming packet message processed, error 401: Unauthorized

242: session 000000000000000002: realm <mycompany.org> user <>: incoming packet message processed, error 401: Unauthorized

242: session 000000000000000003: realm <mycompany.org> user <>: incoming packet message processed, error 401: Unauthorized

242: session 000000000000000002: realm <mycompany.org> user <>: incoming packet BINDING processed, success

242: session 000000000000000003: realm <mycompany.org> user <>: incoming packet BINDING processed, success

242: session 000000000000000003: realm <mycompany.org> user <>: incoming packet message processed, error 401: Unauthorized

242: session 000000000000000002: realm <mycompany.org> user <>: incoming packet message processed, error 401: Unauthorized

243: session 000000000000000003: realm <mycompany.org> user <>: incoming packet message processed, error 401: Unauthorized

243: session 000000000000000002: realm <mycompany.org> user <>: incoming packet message processed, error 401: Unauthorized

243: IPv4. Local relay addr: 10.0.2.15:55037

243: session 000000000000000003: new, realm=<mycompany.org>, username=<test4>, lifetime=600

243: session 000000000000000003: realm <mycompany.org> user <test4>: incoming packet ALLOCATE processed, success

243: IPv4. Local relay addr: 10.0.2.15:52683

243: session 000000000000000002: new, realm=<mycompany.org>, username=<test4>, lifetime=600

243: session 000000000000000002: realm <mycompany.org> user <test4>: incoming packet ALLOCATE processed, success

243: session 000000000000000003: realm <mycompany.org> user <test4>: incoming packet ALLOCATE processed, success

243: session 000000000000000002: realm <mycompany.org> user <test4>: incoming packet ALLOCATE processed, success

243: session 000000000000000003: realm <mycompany.org> user <test4>: incoming packet message processed, error 437: Mismatched allocation: wrong transaction ID

243: session 000000000000000002: realm <mycompany.org> user <test4>: incoming packet message processed, error 437: Mismatched allocation: wrong transaction ID

244: session 000000000000000002: refreshed, realm=<mycompany.org>, username=<test4>, lifetime=0

244: session 000000000000000002: realm <mycompany.org> user <test4>: incoming packet REFRESH processed, success

244: session 000000000000000003: refreshed, realm=<mycompany.org>, username=<test4>, lifetime=0

244: session 000000000000000003: realm <mycompany.org> user <test4>: incoming packet REFRESH processed, success

245: session 000000000000000002: closed (2nd stage), user <test4> realm <mycompany.org> origin <>, local 10.0.2.15:3478, remote 10.0.2.2:60113, reason: allocation timeout

245: session 000000000000000002: delete: realm=<mycompany.org>, username=<test4>

245: session 000000000000000003: closed (2nd stage), user <test4> realm <mycompany.org> origin <>, local 10.0.2.15:3478, remote 10.0.2.2:60075, reason: allocation timeout

245: session 000000000000000003: delete: realm=<mycompany.org>, username=<test4>

What am I missing here ? Why do I get "ICE failed" in console ?

I read in [https://tools.ietf.org/id/draft-ietf-behave-turn-08.html][1]

about

"error 437: Mismatched allocation: wrong transaction ID"

it says

> 437 (Allocation Mismatch): This indicates that the client has picked a

> 5-tuple which the server sees as already in use or which was recently

> in use. One way this could happen is if an intervening NAT assigned a

> mapped transport address that was recently used by another allocation.

> The client SHOULD pick another client transport address and retry the

> Allocate request (using a different transaction id). The client SHOULD

> try three different client transport addresses before giving up on

> this server. Once the client gives up on the server, it SHOULD NOT try

> to create another allocation on the server for 2 minutes.

What does this mean?

[1]: https://tools.ietf.org/id/draft-ietf-behave-turn-08.html

Reply all

Reply to author

Forward

0 new messages