Auteur Sujet: Asterisk et wireguard : cafouillage RTP  (Lu 8085 fois)

0 Membres et 1 Invité sur ce sujet

jeremyp3

  • Abonné Orange Fibre
  • *
  • Messages: 715
  • Pau (64)
Asterisk et wireguard : cafouillage RTP
« Réponse #12 le: 15 juillet 2019 à 01:04:48 »
De mon côté j'accumule les bugs : Si le serveur change d'ip, le client est déconnecté mais même après plusieurs minutes (le temps que le DNS change) il ne se reconnecte pas... Il faut que je refasse un wg-quick down/up pour que ça reparte.

sinon, tu peux essayer ce script:
https://github.com/WireGuard/WireGuard/blob/master/contrib/examples/reresolve-dns/reresolve-dns.sh

en fait, le script modifie le peer avec la nouvelle adresse résolu, donc faut l'exécuter périodiquement :)

Jerem

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Asterisk et wireguard : cafouillage RTP
« Réponse #13 le: 15 juillet 2019 à 18:01:27 »
Je connaissais pas, merci.

Je vais tester ça.

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Asterisk et wireguard : cafouillage RTP
« Réponse #14 le: 15 juillet 2019 à 22:39:24 »
Bon, ça ne fonctionne pas...

Peut-être parce que j'utilise wg-quick ?

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Asterisk et wireguard : cafouillage RTP
« Réponse #15 le: 26 juillet 2019 à 21:48:47 »
Pour contourner le problème, j'ai remis en service mon tunnel ipv6 avec des ip statiques, à voir sur la durée.

EDIT : Tout est ok, même lorsque je change d'ip, tout revient tout seul  :)
« Modifié: 17 août 2019 à 17:24:05 par renaud07 »

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Asterisk et wireguard : cafouillage RTP
« Réponse #16 le: 17 août 2019 à 17:28:13 »
Linphone avec le VLAN fonctionne aussi, j'avais comme un c*n oublié de l'ajouter dans la liste des ip du tunnel. Le détail qui change tout   :P
« Modifié: 19 août 2019 à 17:21:06 par renaud07 »

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Asterisk et wireguard : cafouillage RTP
« Réponse #17 le: 02 septembre 2019 à 17:50:30 »
Citer
il arrive qu'asterisk définisse le peer audio sur l'adresse publique de la connexion 4G au lieu de 172.16.0.x et bien évidement dans ce cas aucun son. Et moi qui pensais que le VPN allait justement m'éviter les problèmes de ce type... ça marchait limite mieux quand je me connectais via l'ip publique ::)

J'ai enfin résolu mon problème initial : C'était encore une histoire Avec les AllowedIPs. Il a suffit de rajouter la plage du VLAN sur les smartphones. Désormais j'ai bien en peer le GXP.

Encore une erreur stupide que j'ai mis plusieurs semaines à comprendre...

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Asterisk et wireguard : cafouillage RTP
« Réponse #18 le: 02 septembre 2019 à 18:47:07 »
La joie aura été de courte durée : Lorsque je tente un appel GXP> softphone (qui sont donc sur le même VLAN) ou smartphone > softphone asterisk coupe l'appel au bout de quelques secondes et j'ai un gros paquet d'erreurs en lien avec mon ip normale et pas celle du VLAN :

Pourquoi il veut absolument envoyer le flux sur 192.168.1.11 et pas 192.168.3.11 ?

Using SIP RTP TOS bits 184
  == Using SIP RTP TOS bits 184 in TCLASS field.
  == Using SIP RTP CoS mark 5
       > 0x7f0610055180 -- Strict RTP learning after remote address set to: 192.168.3.10:5056
    -- Executing [304@internal:1] Dial("SIP/310-00000023", "SIP/304,20,kK") in new stack
  == Using SIP RTP TOS bits 184
  == Using SIP RTP TOS bits 184 in TCLASS field.
  == Using SIP RTP CoS mark 5
    -- Called SIP/304
  == Extension Changed 304[BLF_Group_1] new state Ringing for Notify User GXP L1
    -- SIP/304-00000024 is ringing
  == Extension Changed 304[BLF_Group_1] new state Ringing for Notify User GXP L1
       > 0x7f05f400cd50 -- Strict RTP learning after remote address set to: 192.168.1.11:7078
[Sep  2 18:19:00] WARNING[872][C-0000000f]: chan_sip.c:3832 __sip_xmit: sip_xmit of 0x7f0610051770 (len 404) to 192.168.1.11:5060 returned -1: Destination address required
    -- SIP/304-00000024 answered SIP/310-00000023
    -- Channel SIP/304-00000024 joined 'simple_bridge' basic-bridge <b509bb23-f2d9-4226-8370-111217ca2892>
    -- Channel SIP/310-00000023 joined 'simple_bridge' basic-bridge <b509bb23-f2d9-4226-8370-111217ca2892>
       > Bridge b509bb23-f2d9-4226-8370-111217ca2892: switching from simple_bridge technology to native_rtp
[Sep  2 18:19:00] WARNING[1098][C-0000000f]: chan_sip.c:3832 __sip_xmit: sip_xmit of 0x7f05f4018bb0 (len 1049) to 192.168.1.11:5060 returned -1: Destination address required
       > Remotely bridged 'SIP/310-00000023' and 'SIP/304-00000024' - media will flow directly between them
  == Extension Changed 304[BLF_Group_1] new state InUse for Notify User GXP L1
       > 0x7f05f400cd50 -- Strict RTP qualifying stream type: audio
[Sep  2 18:19:00] WARNING[872]: chan_sip.c:3832 __sip_xmit: sip_xmit of 0x7f05f4018bb0 (len 1049) to 192.168.1.11:5060 returned -1: Destination address required
       > 0x7f05f400cd50 -- Strict RTP switching source address to 192.168.3.11:7078
       > 0x7f0610055180 -- Strict RTP switching to RTP target address 192.168.3.10:5056 as source
[Sep  2 18:19:00] WARNING[872]: chan_sip.c:3832 __sip_xmit: sip_xmit of 0x7f05f4018bb0 (len 1049) to 192.168.1.11:5060 returned -1: Destination address required
[Sep  2 18:19:00] WARNING[872]: chan_sip.c:3832 __sip_xmit: sip_xmit of 0x7f05f4018bb0 (len 1049) to 192.168.1.11:5060 returned -1: Destination address required
[Sep  2 18:19:01] WARNING[872][C-0000000f]: chan_sip.c:3832 __sip_xmit: sip_xmit of 0x7f061004f640 (len 404) to 192.168.1.11:5060 returned -1: Destination address required
[Sep  2 18:19:01] WARNING[872]: chan_sip.c:3832 __sip_xmit: sip_xmit of 0x7f05f4018bb0 (len 1049) to 192.168.1.11:5060 returned -1: Destination address required
[Sep  2 18:19:03] WARNING[872][C-0000000f]: chan_sip.c:3832 __sip_xmit: sip_xmit of 0x7f0610052450 (len 404) to 192.168.1.11:5060 returned -1: Destination address required
[Sep  2 18:19:04] WARNING[872]: chan_sip.c:3832 __sip_xmit: sip_xmit of 0x7f05f4018bb0 (len 1049) to 192.168.1.11:5060 returned -1: Destination address required
[Sep  2 18:19:06] WARNING[872][C-0000000f]: chan_sip.c:3832 __sip_xmit: sip_xmit of 0x7f0610052450 (len 404) to 192.168.1.11:5060 returned -1: Destination address required
[Sep  2 18:19:08] WARNING[872]: chan_sip.c:3832 __sip_xmit: sip_xmit of 0x7f05f4018bb0 (len 1049) to 192.168.1.11:5060 returned -1: Destination address required
[Sep  2 18:19:08] WARNING[872]: chan_sip.c:4119 retrans_pkt: Retransmission timeout reached on transmission 0e0dc0ec2b93a0c80752f6ed6114045b@172.16.1.1:5260 for seqno 103 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 8257ms with no response
[Sep  2 18:19:08] WARNING[872]: chan_sip.c:4143 retrans_pkt: Hanging up call 0e0dc0ec2b93a0c80752f6ed6114045b@172.16.1.1:5260 - no reply to our critical packet (see https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions).
    -- Channel SIP/304-00000024 left 'native_rtp' basic-bridge <b509bb23-f2d9-4226-8370-111217ca2892>
    -- Channel SIP/310-00000023 left 'native_rtp' basic-bridge <b509bb23-f2d9-4226-8370-111217ca2892>
  == Spawn extension (internal, 304, 1) exited non-zero on 'SIP/310-00000023'

Alors que si je tente un appel smartphone > GXP tout se passe bien :
Called SIP/300
  == Extension Changed 300[BLF_Group_1] new state Ringing for Notify User GXP L1
    -- SIP/300-0000002e is ringing
  == Extension Changed 300[BLF_Group_1] new state Ringing for Notify User GXP L1
    -- SIP/300-0000002e is ringing
       > 0x7f05fc022370 -- Strict RTP learning after remote address set to: 192.168.1.20:4002
    -- SIP/300-0000002e answered SIP/310-0000002d
  == Extension Changed 300[BLF_Group_1] new state InUse for Notify User GXP L1
    -- Channel SIP/300-0000002e joined 'simple_bridge' basic-bridge <896bebd6-9ecc-4b56-be6d-e7b255142001>
    -- Channel SIP/310-0000002d joined 'simple_bridge' basic-bridge <896bebd6-9ecc-4b56-be6d-e7b255142001>
       > Bridge 896bebd6-9ecc-4b56-be6d-e7b255142001: switching from simple_bridge technology to native_rtp
       > Remotely bridged 'SIP/310-0000002d' and 'SIP/300-0000002e' - media will flow directly between them
       > 0x7f05fc022370 -- Strict RTP learning after remote address set to: 192.168.1.20:4002
       > 0x7f0610054e30 -- Strict RTP switching to RTP target address 192.168.3.10:5072 as source
    -- Channel SIP/310-0000002d left 'native_rtp' basic-bridge <896bebd6-9ecc-4b56-be6d-e7b255142001>
  == Spawn extension (internal, 300, 1) exited non-zero on 'SIP/310-0000002d'
    -- Channel SIP/300-0000002e left 'native_rtp' basic-bridge <896bebd6-9ecc-4b56-be6d-e7b255142001>

Le pire c'est que dans le sens softphone > smartphone/GXP ça marche, pas d'erreurs, par contre le flux audio passe par 192.168.1.11  ??? Je n’arrive pas à comprendre comment c'est possible...

- Called SIP/300
  == Extension Changed 304[BLF_Group_1] new state InUse for Notify User GXP L1
  == Extension Changed 300[BLF_Group_1] new state Ringing for Notify User GXP L1
    -- SIP/300-00000030 is ringing
  == Extension Changed 300[BLF_Group_1] new state Ringing for Notify User GXP L1 (queued)
    -- SIP/300-00000030 is ringing
       > 0x7f060c01afe0 -- Strict RTP learning after remote address set to: 192.168.1.20:4004
    -- SIP/300-00000030 answered SIP/304-0000002f
  == Extension Changed 300[BLF_Group_1] new state InUse for Notify User GXP L1
    -- Channel SIP/300-00000030 joined 'simple_bridge' basic-bridge <17a3705a-4893-4c37-a455-b0f95e8f8ed5>
    -- Channel SIP/304-0000002f joined 'simple_bridge' basic-bridge <17a3705a-4893-4c37-a455-b0f95e8f8ed5>
       > Bridge 17a3705a-4893-4c37-a455-b0f95e8f8ed5: switching from simple_bridge technology to native_rtp
       > Remotely bridged 'SIP/304-0000002f' and 'SIP/300-00000030' - media will flow directly between them
       > 0x7f060c01afe0 -- Strict RTP learning after remote address set to: 192.168.1.20:4004
       > 0x7f0610054e30 -- Strict RTP qualifying stream type: audio
       > 0x7f0610054e30 -- Strict RTP learning after remote address set to: 192.168.1.11:7078
    -- Channel SIP/300-00000030 left 'native_rtp' basic-bridge <17a3705a-4893-4c37-a455-b0f95e8f8ed5>
    -- Channel SIP/304-0000002f left 'native_rtp' basic-bridge <17a3705a-4893-4c37-a455-b0f95e8f8ed5>
  == Spawn extension (internal, 300, 1) exited non-zero on 'SIP/304-0000002f'

Dans le status des peers, le softphone a bien 192.168.3.11 comme IP :
300/renaudmoto            172.16.1.3                               D  No         No             46421    OK (201 ms)                                                                     
304/renaudpc              192.168.3.11                             D  No         No             5060     OK (129 ms)                                                               
310/GXP L1                192.168.3.10                             D  No         No             5060     OK (142 ms)                                 
311/GXP L2                192.168.3.10                             D  No         No             5062     OK (142 ms)                                 

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Asterisk et wireguard : cafouillage RTP
« Réponse #19 le: 02 septembre 2019 à 19:40:35 »
Il y a visiblement un soucis de NAT, car si je le réactive, il prend bien en compte l'adresse du VLAN cette fois (mais il détecte toujours l'ip normale au début) :
Called SIP/304
    -- SIP/304-00000025 is ringing
    -- SIP/304-00000025 is ringing
       > 0x7f704c005ce0 -- Strict RTP learning after remote address set to: 192.168.1.11:7078
    -- SIP/304-00000025 answered SIP/300-00000024
    -- Channel SIP/304-00000025 joined 'simple_bridge' basic-bridge <e3bf994b-c61e-4fee-bc06-4e181fc28250>
    -- Channel SIP/300-00000024 joined 'simple_bridge' basic-bridge <e3bf994b-c61e-4fee-bc06-4e181fc28250>
       > Bridge e3bf994b-c61e-4fee-bc06-4e181fc28250: switching from simple_bridge technology to native_rtp
       > Locally RTP bridged 'SIP/300-00000024' and 'SIP/304-00000025' in stack
       > 0x7f704c005ce0 -- Strict RTP qualifying stream type: audio
       > 0x7f704c005ce0 -- Strict RTP switching source address to 192.168.3.11:7078
       > 0x7f701004feb0 -- Strict RTP qualifying stream type: audio
       > 0x7f701004feb0 -- Strict RTP switching source address to 172.16.1.3:4028
       > 0x7f701004feb0 -- Strict RTP learning after remote address set to: 192.168.1.20:4028
       > Locally RTP bridged 'SIP/300-00000024' and 'SIP/304-00000025' in stack
       > 0x7f704c005ce0 -- Strict RTP learning complete - Locking on source address 192.168.3.11:7078
       > 0x7f701004feb0 -- Strict RTP learning complete - Locking on source address 172.16.1.3:4028

Un peu comme avec le smartphone qui n'est pas sur un VLAN, il va détecter l'adresse LAN, avant de basculer sur celle de WG, sauf que dans ce cas ça ne pose pas de problème vu que c'est réellement l'adresse utilisée) :
- Called SIP/300
  == Extension Changed 300[BLF_Group_1] new state Ringing for Notify User GXP L1
    -- SIP/300-0000002b is ringing
  == Extension Changed 300[BLF_Group_1] new state Ringing for Notify User GXP L1 (queued)
       > 0x7f7034017520 -- Strict RTP learning after remote address set to: 192.168.1.20:4034
    -- SIP/300-0000002b answered SIP/310-0000002a
  == Extension Changed 300[BLF_Group_1] new state InUse for Notify User GXP L1
    -- Channel SIP/300-0000002b joined 'simple_bridge' basic-bridge <9fe56eaf-02fa-4111-9518-9549c452cef7>
    -- Channel SIP/310-0000002a joined 'simple_bridge' basic-bridge <9fe56eaf-02fa-4111-9518-9549c452cef7>
       > Bridge 9fe56eaf-02fa-4111-9518-9549c452cef7: switching from simple_bridge technology to native_rtp
       > Locally RTP bridged 'SIP/310-0000002a' and 'SIP/300-0000002b' in stack
       > 0x7f70100574c0 -- Strict RTP switching to RTP target address 192.168.3.10:5044 as source
       > 0x7f7034017520 -- Strict RTP qualifying stream type: audio
       > 0x7f7034017520 -- Strict RTP switching source address to 172.16.1.3:4034
       > 0x7f70100574c0 -- Strict RTP learning complete - Locking on source address 192.168.3.10:5044
       > 0x7f7034017520 -- Strict RTP learning complete - Locking on source address 172.16.1.3:4034
    -- Channel SIP/310-0000002a left 'native_rtp' basic-bridge <9fe56eaf-02fa-4111-9518-9549c452cef7>
  == Spawn extension (internal, 300, 1) exited non-zero on 'SIP/310-0000002a'
    -- Channel SIP/300-0000002b left 'native_rtp' basic-bridge <9fe56eaf-02fa-4111-9518-9549c452cef7>

Donc ça veut dire que si par exemple je pouvais connecter le smartphone sur le VLAN, j'aurais le même problème ? Ça explique aussi pourquoi ça fonctionne avec le GXP : il n'a qu'une seule IP.

Je ne sais pas comment est foutu le mécanisme de détection RTP, mais dans ce genre de cas il a pas l'air de savoir se débrouiller correctement.

Je suis tout ouïe si quelqu'un a une solution de contournement  :)

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Asterisk et wireguard : cafouillage RTP
« Réponse #20 le: 10 septembre 2019 à 20:25:30 »
Je viens enfin de trouver une solution : il faut indiquer l'adresse locale (dans mon cas 192.168.3.11) dans les paramètres de linphone en cochant "behind NAT / Firewall" et cette fois la détection est correcte et j'ai du son  :) :

Using SIP RTP TOS bits 184
  == Using SIP RTP TOS bits 184 in TCLASS field.
  == Using SIP RTP CoS mark 5
       > 0x7f494806e470 -- Strict RTP learning after remote address set to: 192.168.3.11:7078
    -- Executing [310@internal:1] Dial("SIP/304-000000c2", "SIP/310,20,kK") in new stack
  == Extension Changed 304[BLF_Group_1] new state InUse for Notify User GXP L1
  == Using SIP RTP TOS bits 184
  == Using SIP RTP TOS bits 184 in TCLASS field.
  == Using SIP RTP CoS mark 5
    -- Called SIP/310
    -- SIP/310-000000c3 is ringing
    -- SIP/310-000000c3 is ringing
       > 0x7f4940013ba0 -- Strict RTP learning after remote address set to: 192.168.3.10:5032
    -- SIP/310-000000c3 answered SIP/304-000000c2
    -- Channel SIP/310-000000c3 joined 'simple_bridge' basic-bridge <fbb40b04-0231-4fa4-ab4e-9e1d786c46ec>
    -- Channel SIP/304-000000c2 joined 'simple_bridge' basic-bridge <fbb40b04-0231-4fa4-ab4e-9e1d786c46ec>
       > Bridge fbb40b04-0231-4fa4-ab4e-9e1d786c46ec: switching from simple_bridge technology to native_rtp
       > Remotely bridged 'SIP/304-000000c2' and 'SIP/310-000000c3' - media will flow directly between them
       > 0x7f4940013ba0 -- Strict RTP switching to RTP target address 192.168.3.10:5032 as source
       > 0x7f494806e470 -- Strict RTP switching to RTP target address 192.168.3.11:7078 as source
    -- Channel SIP/310-000000c3 left 'native_rtp' basic-bridge <fbb40b04-0231-4fa4-ab4e-9e1d786c46ec>
    -- Channel SIP/304-000000c2 left 'native_rtp' basic-bridge <fbb40b04-0231-4fa4-ab4e-9e1d786c46ec>
  == Spawn extension (internal, 310, 1) exited non-zero on 'SIP/304-000000c2'


Sinon il prend l'adresse courante car c'est celle qui peut sortir sur le net je suppose.