Discussions (German)

Stun /turn liefert interne IP

Hallo zusammen

Ich habe ein Problem, den TURN auf dem RP richtig zu konfigurieren.
Ich verwende den Stun von sipgate und den Turn auf einer IPVA.
Als Client habe MyPBX auf Android, v12r1 SR9.
Im ICE Log finde ich folgende Einträge:

0:2674:540:2 - ICE.0: Initialize STUN1(217.10.68.152:3478, :::0) STUN2(:::0, :::0)
0:2674:540:2 - ICE.0: Found HOST address 192.168.1.40 (registration)
0:2674:541:0 - ICE.0: STUN 192.168.1.40:16400 -> 217.10.68.152:3478 Request
0:2674:541:2 - ICE.0: STUN 192.168.1.40:16401 -> 217.10.68.152:3478 Request
0:2674:541:6 - ICE.0: TURN Allocate req
0:2674:542:1 - ICE.0: Found HOST address 192.168.1.40 (interface)
0:2674:543:4 - ICE.0: Found HOST address 192.168.1.40 (interface)
[.. ganz oft diese Zeile...]
0:2674:585:6 - ICE.0: Gathering HOST candidates finished
0:2674:586:1 - ICE.0: STUN 192.168.1.40:16400 <- 217.10.68.152:3478 Response
0:2674:586:2 - ICE.0: TURN Allocate result Unauthorized: re-authorizing
0:2674:586:2 - ICE.0: TURN Allocate req after Unauthorized
0:2674:586:3 - ICE.0: TURN Allocate result parsing error
0:2674:586:3 - ICE.0: STUN 192.168.1.40:16401 <- 217.10.68.152:3478 Response
0:2674:586:3 - ICE.0: Found SRFLX address 77.239.63.126
0:2674:586:4 - ICE.0: Gathering SRFLX candidates finished
0:2674:605:0 - ICE.0: TURN Allocate res
0:2674:605:0 - ICE.0: Found RELAY address 192.168.33.41
0:2674:605:0 - ICE.0: Gathering RELAY candidates finished
0:2674:605:1 - ICE.0: Initialized local candidates RTP(192.168.1.40:16400) RTCP(192.168.1.40:16401) T38(192.168.1.40:0)
CANDIDATES:LOCAL,count(3),fingerprint(5b1d772148e2724b199d8ffd3703b30e3335bf79e13e1709fc604c4ddce21fc6),usr(npQO),pwd(OVmw4Ks9uGBiJJgfmb+tgJ)
:HOST addr([192.168.1.40]:16400/16401) prio(2130569471/2130569726)
:SRFLX addr([77.239.63.126]:62586/60736) related([192.168.1.40]:16400/16401) prio(1693124351/1693124606)
:RELAY addr([192.168.33.41]:16402/16403) related([192.168.1.40]:16400/16401) prio(16683263/16683518)
0:2674:605:1 - ICE.0: TURN Allocate req
0:2674:605:2 - ICE.0: TURN Allocate res
0:2674:621:6 - ICE.0: TURN Allocate result Unauthorized: re-authorizing
0:2674:621:7 - ICE.0: TURN Allocate req after Unauthorized
0:2674:622:0 - ICE.0: TURN Allocate result parsing error
0:2674:634:2 - AC_CH.0[0]: PhTone off
0:2674:641:2 - ICE.0: TURN Allocate res
0:2674:641:3 - ICE.0: TURN Allocate res
0:2674:747:1 - H245_LISTEN:16434 Unlisten
0:2674:747:3 - H245_LISTEN:16434 Close IPv4 54
0:2674:747:4 - ICE.0: TURN Refresh req
0:2674:748:1 - ICE.0: TURN Refresh req

192.168.1.40 ist mein Smartphone im Wlan
77.239.63.126 ist mein WAN IP
192.168.33.41 ist die LAN IP vom RP und TURN Server, die ist beim Kunden und logischerweise über diese Adresse nicht erreichbar.

Die Signalisierung kommt an, es ist aber kein Audiostream vorhanden und nach 10 Sekunden bricht der Call dann ab, was in dieser Situation ja normal ist.

Mir ist nicht klar, wo ich noch etwas ändern muss?
Auch kenne ich die Ursache für die Meldung "Allocate result Unauthorized: re-authorizing" und "Allocate result parsing error" nicht.
Kennt jemand die Lösung für diese Fehler?

Gruss Mario

Re: Stun /turn liefert interne IP

Hi Mario,

Sorry the late reply,

The messages bellow are not relevant, this is part of the redundancy of messages that are sent to the TURN server from the client.

0: 2674: 621: 6 - ICE.0: TURN Allocate result Unauthorized: re-authorizing

0: 2674: 621: 7 - ICE.0: TURN Allocate req after Unauthorized

0: 2674: 622: 0 - ICE.0: TURN Allocate result parsing error

In this log seams that the client correctly obtained all his candidates:

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

0:2674:605:1 - ICE.0: Initialized local candidates RTP(192.168.1.40:16400) RTCP(192.168.1.40:16401) T38(192.168.1.40:0)
CANDIDATES:LOCAL,count(3),fingerprint(5b1d772148e2724b199d8ffd3703b30e3335bf79e13e1709fc604c4ddce21fc6),usr(npQO),pwd(OVmw4Ks9uGBiJJgfmb+tgJ)
:HOST addr([192.168.1.40]:16400/16401) prio(2130569471/2130569726)
:SRFLX addr([77.239.63.126]:62586/60736) related([192.168.1.40]:16400/16401) prio(1693124351/1693124606)
:RELAY addr([192.168.33.41]:16402/16403) related([192.168.1.40]:16400/16401) prio(16683263/16683518)

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

The TURN Server always provide his own IP, since it's on a private machine behind a NAT router we see the private IP on the candidates (what's correct and works).

Why the ICE fails it's not clear on this trace, to find out it's necessary to have trace from both endpoints envolved with the H.323 ICE trace flag and all TCP/UDP traffic so we could check each test that was made.

Important that the other endpoint involved also provided all his candidates.

You are here