La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux (usage serveur) => Discussion démarrée par: renaud07 le 30 juin 2019 à 21:34:40
-
Bonsoir,
Le plan d'adressage :
interfaces WG : 172.16.0.0/24
plages LAN : 192.168.1.0/24 - 192.168.2.0/24
serveur WG/asterisk : 172.16.0.1 - 192.168.2.6
serveur LAN client : 192.168.1.10 - 172.16.0.2
smartphones : 172.16.0.3-5
softphone PC1 : 192.168.1.11
J'ai décidé de réaménager ma mini infrastructure SIP en sécurisant tous les échanges. Comme le SRTP et le TLS marchent un coup sur 2 et vu que tous les tel/softphones ne le supportent pas, je me suis dit que j'allais retenter avec wireguard.
Après tâtonnement, je suis parvenu à faire fonctionner le tout en renseignant l'ip WG comme ip du serveur asterisk (au lieu de son ip côté LAN) sinon je n'avais pas de son (sur le LAN client), ni possibilité d’enregistrement sur les smartphones (pour que ça marche il fallait rediriger l'intégralité du trafic sur le VPN, hors ce n'est pas le fonctionnement souhaité).
Mais je rencontre tout de même un comportement étrange et aléatoire sur les smartphones : 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 ::)
Une idée du pourquoi ça merdouille ?
Merci d'avance.
Sur les captures : Dans le premier cas c'est ok, mais pas pour l'autre
-
On dirait que ça va mieux si tout les flux passent par asterisk avec directmedia=no
Du coup je pense que je vais laisser comme ça, d'autant plus que si je laisse activé, je ne peux pas faire de transfert d'appels.
EDIT : Ouch, j'avais pas vu mais y'a pas mal de BP utilisée en plus, avec du speex16 en qualité 8 (28kb/s) je passe en tout de 44kb/s à 110-120kb/s avec le tunnel activé... Je pensais WG plus économe.
EDIT2 : Je viens au moins de trouver une utilité à WG : la continuité de communication, je peux passer du wifi à la 4G et même switcher 2G/3G/4G, le flux repart tout seul, c'est magique :D Les opérateurs avec leur vowifi n'ont qu'à bien se tenir ;D
-
Je pensais WG plus économe.
80 octets par paquet UDP.
-
Merci pour les chiffres.
-
Je vais rajouter 2 tel physiques (un sur chaque LAN) et je voudrais les isoler sur un VLAN. Mais avec le VPN au milieu j'ai un doute : Les isoler du LAN est suffisant ou vaut-il mieux prolonger le VLAN dans le VPN ? Car vu que sur le VPN il n'y a que le trafic SIP, je me demande si c'est bien utile ?
-
Ca va être dur de prolonger un VLAN (L2) dans un VPN wireguard qui transporte de l'IP (L3). Enfin, à moins de rajouter encore un niveau d'encapsulation par dessus wireguard, comme Ethernet over GRE. Ca ferait donc de l'Ethernet over GRE over Wireguard, pas sur que ce soit optimal.
L'autre solution c'est d'avoir un endpoint wireguard par VLAN et de configurer les clients de façon à ce qu'ils utilisent l'endpoint correspondant au VLAN qu'ils doivent utiliser.
-
Ca va être dur de prolonger un VLAN (L2) dans un VPN wireguard qui transporte de l'IP (L3).
J'avais zappé ce MINUSCULE DÉTAIL ::)
Enfin, à moins de rajouter encore un niveau d'encapsulation par dessus wireguard, comme Ethernet over GRE. Ca ferait donc de l'Ethernet over GRE over Wireguard, pas sur que ce soit optimal.
En effet assez lourdingue... Surtout sur de l'ADSL en PPPoE bonjour le nombre de couches.
L'autre solution c'est d'avoir un endpoint wireguard par VLAN et de configurer les clients de façon à ce qu'ils utilisent l'endpoint correspondant au VLAN qu'ils doivent utiliser.
Ça me plait déjà mieux, on testera ça :)
Maintenant faut attendre la marchandise...
-
Une chose qui n'a pas grand chose à voir avec wireguard et asterisk mais ça m'inquiète un peu :
Plusieurs fois quand je me suis connecté en SSH le système m'a averti que les clés avaient changées. Ce qui est bizarre c'est que ça me l'a fait 3-4 fois puis après plus rien. Là après un reboot de routeur, je me suis reconnecté/déco sans problème. Puis quelques minutes plus tard, je me suis reconnecté et paf, les clés ne sont plus les mêmes.
Le plus inquiétant c'est que ça me l'a fait cette fois sur une autre VM qui ne m'a jamais fait ça avant...
Y'aurait un moyen simple pour vérifier que personne ne me pirate ? Surtout que j'utilise des ports non standard pour SSH et que la VM asterisk n'est pas accessible directement de l'extérieur...
Rien de grave, j'avais simplement mis la même IP à 2 VM ::)
-
Réception d'un grandstream GXP2000 (http://www.grandstream.com/support/resources/?title=GXP2000)pour 20€, qui dit mieux ? (en plus super bien emballé et aucune rayure, on dirait qu'il est neuf) Par contre faudrait appendre aux gens à remettre à zéro, y'avait encore le compte Freephonie de l'ancien proprio ainsi que son répertoire... Dommage que Free ai stoppé le service sinon j'aurais pû téléphoner gratos :P
Configuré en 2 clics, très facile d'utilisation. A priori tout fonctionne, même le MWI. Je n'ai pas encore mis en place le VLAN mais y'a pas de raison.
Ça à l'air vraiment de la bonne cam ces téléphones. (J'ai même été choqué par le poids du combiné, ça se voit que c'est pas que du plastique^^)
-
VLAN en place, tout fonctionne.
Par contre j'ai un petit bug (et encore pas sur que ce soit lié). Lorsque j’appelle depuis le GXP, on dirait que la négociation des codecs déconne. Il prend le PCMA alors que j'ai spécifié en premier le G722 et que en face il n'y a que le G722 de possible. Par contre dans le sens smartphone > GXP, là il prend bien le G722. C'est pareil avec les autres codecs comme le G729.
-
J'ai voulu ajouter mon PC au VLAN SIP pour faire des tests, mais je n'arrive plus à atteindre asterisk...
Le VLAN est bon, j'arrive à ping le GXP et le Rpi. Par contre pas moyen avec asterisk, le ping n'arrive pas au serveur, alors que j'ai explicitement rajouté une route :
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 enp2s0
0.0.0.0 192.168.3.1 0.0.0.0 UG 400 0 0 SIP
172.16.1.0 192.168.3.1 255.255.255.0 UG 0 0 0 SIP
172.16.9.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet8
172.16.234.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet1
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp2s0
192.168.3.0 0.0.0.0 255.255.255.0 U 400 0 0 SIP
(J'ai changé l'adressage, asterisk est désormais en 172.16.1.1/24 et le VLAN 192.168.3.0/24)
Chose curieuse aussi, le Rpi (qui fait l'endpoint) balance des DHCP discover sur le VLAN alors que son adressage est statique ???
-
Tout le monde est en vacances ? :P
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.
C'est le comportement normal ou ça devrait effectivement se reconnecter tout seul ?
-
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
-
Je connaissais pas, merci.
Je vais tester ça.
-
Bon, ça ne fonctionne pas...
Peut-être parce que j'utilise wg-quick ?
-
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 :)
-
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
-
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...
-
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)
-
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 :)
-
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.