C'est même pas trollesque tellement c'est triste :
Avant de comprendre si un softphone fonctionne à travers VPN, faut essayer s'il
fonctionne tout court.
Il y a 2 jours, j'ai essayé un softphone au travers du VPN. Cà n'a pas marché.
Aujourd'hui, j'ai essayé le même softphone directement sur le
> - Mail original -
> De: "Adrien Rivas"
> Niveau réseau, l'ASA est dgw ou pas ?
Non. Il donne assez uniquement à nos réseaux. Et les routes ajoutés sur un
client VPN Linux sont de la forme "10.10.0.0/16 dev tun0".
> Les routes de VPN sont déclarées sur l'Asterisk si ASA pas dgw ?
> - Mail original -
> De: "frnog"
> pour que ca fonctionne il faut que les ports 1-2 (par default
asterisk rtp soit permis au niveau du asterisk).
C'est OK.
> Par experience si tu te fais trop chier tu peux essayer l'ipv6 donc tu
elimines tous les problemes de nat.
J'ai ni
Bonjour,
je ne sais pas si je suis trop tard maid bon.
pour que ca fonctionne il faut que les ports 1-2 (par default
asterisk rtp soit permis au niveau du asterisk).
Par experience si tu te fais trop chier tu peux essayer l'ipv6 donc tu
elimines tous les problemes de nat.
-pjsip show
Niveau réseau, l'ASA est dgw ou pas ? Les routes de VPN sont déclarées sur
l'Asterisk si ASA pas dgw ? Au niveau des ACL on a bien la règle net_vpn/16
vers net_vpn/16 ? Parce que ça pourrait ressembler à du routage asymétrique
aussi. Le firewall de la solution internet security peut faire ce genre
Le 18/03/2020 à 21:21, Daniel via frnog a écrit :
Essaye alors Twinkle.
Je crois que ça a été fait et que ça ne fonctionnait pas.
Je parle avant nat=yes et directmedia=no, bien entendu.
Au passage, nat=yes est déprécié, mets nat=force_rport,comedia
XiVo le fait tout seul. Je dis nat=yes
Le 18/03/2020 à 20:51, Guillaume LUCAS a écrit :
Le 17/03/2020 à 22:21, Daniel via frnog a écrit :
. tester avec csipsimple qui est très stable
Mais plus maintenu, plus dispo sur f-droid, etc.
Essaye alors Twinkle. Au passage, nat=yes est déprécié, mets
nat=force_rport,comedia
--
Daniel
Le 18/03/2020 à 14:27, Guillaume LUCAS a écrit :
Je vais tester avec du Linphone 4.1.1 winwin, etc. Si pas d'amélioration, ça
validera que le VPN ASA n'est pas coupable.
Je retiens :
* OpenVPN (+ garantie d'absence de filtrage et de NAT) apporte rien
par rapport à ASA pour des conversation
Le 18/03/2020 à 14:06, Raphael Mazelier a écrit :
Sinon si tu peux centraliser la conf de tes linphones ca serait aussi
pour toi le meilleur, avec pareil l'option qui va bien.
Je n'ai pas compris ? Comment centralises-tu la conf' des linphones ?
---
Liste de diffusion
Le 17/03/2020 à 22:21, Daniel via frnog a écrit :
. tester avec csipsimple qui est très stable
Mais plus maintenu, plus dispo sur f-droid, etc.
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Le 17/03/2020 à 22:04, Michel Py a écrit :
Guillaume LUCAS a écrit :
C'est ça. Et ceux essayés (Jitsi, Linphone, Blink, Zoiper) échouent sur le
choix de
l'IP, soit tout le temps, soit par moments. D'où mon usage de STUN.
Maintenant je comprends. Je ne me doutais pas que les clients softphone
> - Mail original -
> De: "Raphael Mazelier"
> Le rtp learning c'est une invention d'asterisk j'imagine qui doit être
> une fonctionnalité qui essaie de découvrir la topologie réseau et donc
> setter les adresses ip dans le rtp.
Ouki.
> Une bonne manière de bien comprendre c'est de
Si tu savais… :D
Je bloque sur un point sur l'idée de relais RTP : que se passe-t-il quand le
RTP learning foire ? Fin des appels ?
Parce que là, je viens de tester entre du Linphone winwin et Linux. Ça ne
fonctionnait pas avant (donc le VPN OpenVPN apporte quelque chose) et, surtout,
je
> Kevin CHAILLY a écrit :
> Dans la guerre Asterisk vs FreeSWITCH pour des 픯픞픦픰픬픫픰 픥픦픰픱픬픯픦픮픲픢픰 ™ nous
> utilisons des produits basés sur Asterisk
Sympa la fonte, et pareil ici.
>>> Daniel Huhardeaux a écrit :
>>> Et rajoute directmedia = no
C'est bien çà que je voulais dire, j'avais le nom du
] Télétravail = VPN = fête du SIP (ou y'a-t-il
vraiment autant de bugs que ça dans les implémentations SIP ?!)
Bon,
Etape 1: tu vires ton *
Etape 2: tu utilises un produit FreeSWITCH-based Etape 3: tu dors peinard et
plus jamais tu te poses ce genre de questions :)
Le 18 mars 2020 à 16:10, Guillaume
d'origine-
De : frnog-requ...@frnog.org De la part de David
Ponzone
Envoyé : mercredi 18 mars 2020 16:18
À : Guillaume LUCAS
Cc : frnog
Objet : Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il
vraiment autant de bugs que ça dans les implémentations SIP ?!)
Bon,
Etape 1: tu
Bon,
Etape 1: tu vires ton *
Etape 2: tu utilises un produit FreeSWITCH-based
Etape 3: tu dors peinard et plus jamais tu te poses ce genre de questions :)
> Le 18 mars 2020 à 16:10, Guillaume LUCAS a
> écrit :
>
> - Mail original -
>> De: "David Ponzone"
>
>> Mais Guillaume veut pas
- Mail original -
> De: "David Ponzone"
> Mais Guillaume veut pas nous avouer que son * tourne sur un RaspPi 1 et que
> donc le rte-proxy….:)
Si tu savais… :D
Je bloque sur un point sur l'idée de relais RTP : que se passe-t-il quand le
RTP learning foire ? Fin des appels ?
Parce que
> Les SNOM également et avec ces deux fabricants je n'ai *jamais* eu de
> problème en utilisant leur VPN.
+1
> . tester avec csipsimple qui est très stable
+1
> . passer en IAX avec Zoiper. IAX c'est bien ;)
>
> PS: mon dialplan qui sauve mes journées:
> ...
> same =
Raphael,
Tu prêches un convaincu.
Mais Guillaume veut pas nous avouer que son * tourne sur un RaspPi 1 et que
donc le rte-proxy….:)
> Le 18 mars 2020 à 14:50, Raphael Mazelier a écrit :
>
>
> On 18/03/2020 14:34, David Ponzone wrote:
>> Je connais pas ton archi, mais si derrière t’as une
On 18/03/2020 14:34, David Ponzone wrote:
Je connais pas ton archi, mais si derrière t’as une Patton/Audiocodes/Bero qui
peut joindre les endpoint, alors oui, tu peux faire du direct.
Sinon tu es obligé d’utiliser l’* comme B2BUA/SBC.
Oui mais la encore c'est casse gueule. Ce n'est pas pour
Je connais pas ton archi, mais si derrière t’as une Patton/Audiocodes/Bero qui
peut joindre les endpoint, alors oui, tu peux faire du direct.
Sinon tu es obligé d’utiliser l’* comme B2BUA/SBC.
> Le 18 mars 2020 à 14:29, Guillaume LUCAS a
> écrit :
>
>> - Mail original -
>> De: "David
> - Mail original -
> De: "David Ponzone"
> Le plus lourd, c’est les appels vers et depuis l’extérieur, qui seront plus
> autour de 100 et qui sont obligatoirement relayés par l’*.
Quand RTP learning fonctionne. Sinon c'est p2p, entre le softphone/SNOM et la
passerelle T2, non ?
> - Mail original -
> De: "David Ponzone"
Vérifie si Linphone 3 a pas besoin que tu lui dises de mettre le paramètre
rport.
=> use_rport=1 dans la section sip de linphonerc = pas d'amélioration.
Pour la coupure après 31/32/36 secs de conversation, j'ai (re)mis
session-timers=refuse
>>
> Pourquoi ? sans transcoding c'est juste la copie de paquet, ça coûte que
> dalle en cpu. Pareil en réseau. Et ça va résoudre 90% de tes problèmes.
>
Ouais et puis les appels internes, c’est pas si fréquent de nos jours, même en
télétravail.
Sur 800 personnes, je penses pas que tu
On 18/03/2020 13:47, Guillaume LUCAS wrote:
Côté Asterisk, donc.
J'suis pas encore chaud pour qu'Asterisk soit relais RTP de tout le monde… D'un
autre côté… avec le RTP autolearn, il l'est implicitement depuis longtemps, si
je comprends bien ?
Pourquoi ? sans transcoding c'est juste la
Le 18/03/2020 à 13:47, Guillaume LUCAS a écrit :
- Mail original -
De: "frnog"
Et rajoute directmedia = no
Côté Asterisk, donc.
J'suis pas encore chaud pour qu'Asterisk soit relais RTP de tout le monde… D'un
autre côté… avec le RTP autolearn, il l'est implicitement depuis longtemps,
> - Mail original -
> De: "frnog"
> Et rajoute directmedia = no
Côté Asterisk, donc.
J'suis pas encore chaud pour qu'Asterisk soit relais RTP de tout le monde… D'un
autre côté… avec le RTP autolearn, il l'est implicitement depuis longtemps, si
je comprends bien ?
Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment
autant de bugs que ça dans les implémentations SIP ?!)
Merci pour ce diag. :)
On est tous arrivé au même.
Quand la colère va me prendre,
Ou la lassitude...
je vais monter un VPN OpenVPN tout neuf sur lequel je serai sûr que y'a pas d'A
ranti sans NAT ni filtrage à plus de
> collègues.
>
>
> ----- Mail original -----
> De: "Stéphane Rivière"
> À: "frnog"
> Envoyé: Mardi 17 Mars 2020 20:32:09
> Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il
> vraiment autant
> - Mail original -
> De: "Denis Fondras"
pfctl -d désactive PF donc... les règles de NAT.
J'ai été trop vite… J'ai mélangé présentation du bidule et état actuel.
Donc, au début, et jusqu'à la fin de mon premier test hier soir, PF était
activé (+ règle "tout autoriser"), il y avait du
On Wed, Mar 18, 2020 at 12:57:09PM +0100, Guillaume LUCAS wrote:
> Lui fait du NAT. Il a aucune règle de filtrage et j'ai pfctl -d.
>
pfctl -d désactive PF donc... les règles de NAT.
---
Liste de diffusion du FRnOG
http://www.frnog.org/
t;
À: "frnog"
Envoyé: Mardi 17 Mars 2020 20:32:09
Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment
autant de bugs que ça dans les implémentations SIP ?!)
> Merci pour ce diag. :)
On est tous arrivé au même.
> Quand la colère va me prendre,
Ou l
> - Mail original -
> De: "Michel Py"
> Je comprends que tu veux rester sur le softphone, mais çà vaudrait peut-être
> le coup de dépenser 50 balles pour essayer un téléphone de bureau qui a
> support de VPN. Je promets pas que çà marcherait mieux (j'ai jamais essayé),
> mais les
Le 17/03/2020 à 22:04, Michel Py a écrit :
[...]
C'est ça. Et ceux essayés (Jitsi, Linphone, Blink, Zoiper) échouent sur le
choix de
l'IP, soit tout le temps, soit par moments. D'où mon usage de STUN.
Maintenant je comprends. Je ne me doutais pas que les clients softphone avaient
ce genre
> Guillaume LUCAS a écrit :
> Perso, je ne veux pas qu'Asterisk soit relais RTP, car il
> faut dimensionner le serveur pour la montée en chargée
C'est ce que je fais avec 500 utilisateurs, avec une bécane pas trop pourrie
aucun problème.
Je me rappelle plus trop l'option, mais j'ai choisi de
Cela me ramène quelque année en arrière. Et cela me rappelle aussi
pourquoi on posait des box chez les clients. (coucou les ex-B3G,
Ipnotic, Paritel)
Faire de la Voip si tu ne maîtrise pas le lan client c'est possible mais
source d'emmerdements infinis.
Comme déjà mentionné il faut
un interlocuteur envoyer
son RTP à Asterisk et pas l'autre, du coup, ça ne fonctionnait pas.
- Mail original -
De: "David Ponzone"
À: "Guillaume LUCAS"
Cc: "frnog"
Envoyé: Mardi 17 Mars 2020 20:55:48
Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fêt
Faut fouiner, je connais pas assez Asterisk et encore moins les versions
récentes. Et côté doc, c’est comment dire….
> Le 17 mars 2020 à 20:53, Guillaume LUCAS a
> écrit :
>
>> - Mail original -
>> De: "David Ponzone"
>
>>> Qu'est-ce qui peut expliquer les échecs de l'autolearn ?
>
> - Mail original -
> De: "David Ponzone"
> > Qu'est-ce qui peut expliquer les échecs de l'autolearn ?
> Que l’IP que présente le softphone est une IP que Asterisk a dans son
> localnet.
Mon localnet est vide. Si tu m'avais dit « Que l’IP que présente le softphone
N'EST PAS une IP
> Le 17 mars 2020 à 20:46, Guillaume LUCAS a
> écrit :
>
> - Mail original -
> De: "David Ponzone"
>
>> Ah non, en autolearn, il est forcément dans le path RTP.
>
> Attends, attends, attends.
>
> Il se passe quoi quand l'autolearn marche que pour l'un des deux
> interlocuteurs ?
- Mail original -
De: "David Ponzone"
> Ah non, en autolearn, il est forcément dans le path RTP.
Attends, attends, attends.
Il se passe quoi quand l'autolearn marche que pour l'un des deux interlocuteurs
? Ça donnerait pas une conversation où un seule interlocuteur entend l'autre,
> Le 17 mars 2020 à 20:31, Guillaume LUCAS a
> écrit :
>
>> - Mail original -
>> De: "David Ponzone"
>
>> Ah non, en autolearn, il est forcément dans le path RTP.
>
> Moi je parle de ça dans le journal :
> « Strict RTP learning after remote address set to: 10.30.1.4:7078
> Strict RTP
Merci pour ce diag. :)
On est tous arrivé au même.
Quand la colère va me prendre,
Ou la lassitude...
je vais monter un VPN OpenVPN tout neuf sur lequel je serai sûr que y'a pas d'ACL
ni rien et hop hop >hop. Pas envie de démerder un Cisco ASA.
La VOIP en SIP/RTP, ça marche. Mais
> - Mail original -
> De: "David Ponzone"
> Ah non, en autolearn, il est forcément dans le path RTP.
Moi je parle de ça dans le journal :
« Strict RTP learning after remote address set to: 10.30.1.4:7078
Strict RTP learning complete - Locking on source address 10.30.1.4:7078 »
À ce
> - Mail original -
> De: "Michel Py"
> Installer une route vers le réseau local c'est pas une solution, car tu vas
> de retrouver avec une ribambelle de 192.168.0.0.
Et il faut ajouter ces routes chez tous les clients VPN, et donc avoir des
collisions (genre si on dit à un usager
> Le 17 mars 2020 à 20:17, Guillaume LUCAS a
> écrit :
>
>> - Mail original -
>> De: "David Ponzone"
>
>> Moi ce que je pige pas, c’est qu’en RTP autolearn, ça devrait marcher dans
>> tous les cas, Asterisk apprenant tout seul l’IP:PORT de chaque flux RTP, et
>> faisant le relais
> - Mail original -
> De: "David Ponzone"
> Moi ce que je pige pas, c’est qu’en RTP autolearn, ça devrait marcher dans
> tous les cas, Asterisk apprenant tout seul l’IP:PORT de chaque flux RTP, et
> faisant le relais RTP.
Idem. Dans le journal d'Asterisk, je vois bien qu'il autolearn
> Guillaume LUCAS a écrit :
> Ça dit que à chaque fois que j'ai vu de la VOIP ne pas fonctionner, c'était
> toujours
> parce que les softphones ne mettaient pas leur "bonne" IP dans le message
> SIP/SDP,
> forcément que le softphone d'en face ne pourra pas leur envoyer de RTP. Genre
> "viens
>
Moi ce que je pige pas, c’est qu’en RTP autolearn, ça devrait marcher dans tous
les cas, Asterisk apprenant tout seul l’IP:PORT de chaque flux RTP, et faisant
le relais RTP.
Je pense qu’il faut explorer cette piste, en prenant des traces côté Asterisk
si nécessaire, et comprendre ce qui merde.
> - Mail original -
> De: "Thierry Chich"
> Le problème vient peut-être du VPN. Peut-être que 2 IP attribuée par le VPN
> ne se voient pas entre elles, ou partiellement ? On vient d’avoir le coup
> avec du jitsi. Le p2p, c’est bien joli, mais bon.
À mon avis, une partie du problème
> - Mail original -
> De: "frnog"
> Définitivement pour moi problème de NAT ou Pare-Feu
Merci pour ce diag. :)
Quand la colère va me prendre, je vais monter un VPN OpenVPN tout neuf sur
lequel je serai sûr que y'a pas d'ACL ni rien et hop hop hop. Pas envie de
démerder un Cisco ASA.
> - Mail original -
> De: "frnog"
> J'avais bien compris que tu ne veux pas le faire, tu comprends donc que
> ton rtp se perd si le client envois une IP injoignable au PABX
Tout à fait, je comprends.
Je corrige un truc : le client envoie, en SDP, une IP injoignable au PABX, mais
aussi
> - Mail original -
> De: "frnog"
> Réussis tu à pinguer l'IP en 192.168.x.y à partir du PABX ?
Non. Et surtout, je ne veux pas ping les réseaux domestiques de mes usagers. Ce
n'est pas mon rôle d'utiliser notre VPN pour accéder à leur réseau local.
---
Liste
> - Mail original -
> De: "David Ponzone"
> Tu veux pas modifier la nat.address dans le fichier de conf de linphone (voir
> le lien que j’ai envoyé il y a quelques minutes), pour voir si ça aide
> linphone à envoyer un SDP correct ?
J'essaye de dépiler mes mails dans l'ordre.
Alors
Tu veux pas modifier la nat.address dans le fichier de conf de linphone (voir
le lien que j’ai envoyé il y a quelques minutes), pour voir si ça aide linphone
à envoyer un SDP correct ?
> Le 17 mars 2020 à 18:29, Guillaume LUCAS a
> écrit :
>
>> - Mail original -
>> De: "frnog"
>
>
Le problème vient peut-être du VPN. Peut-être que 2 IP attribuée par le VPN ne
se voient pas entre elles, ou partiellement ? On vient d’avoir le coup avec du
jitsi. Le p2p, c’est bien joli, mais bon.
Thierry Chich
> Le 17 mars 2020 à 18:19, Guillaume LUCAS a
> écrit :
>
> - Mail
> - Mail original -
> De: "frnog"
Le 17/03/2020 à 13:32, Guillaume LUCAS a écrit :
> Et cela te parait normal? Il y a déjà un problème au départ, Linphone ou
> autre.
Ben, comme j'ai vu ça en cours et en pratique, je me dis implémentation
foireuse et comme ça me semble quand même trop
Le 17/03/2020 à 18:18, Guillaume LUCAS a écrit :
- Mail original -
De: "frnog"
Donc session timeout: Essaye en mettant session-timers=refuse dans la config
d'un client qui génère cette erreur
J'ai fait. Reload Asterisk. Restart tous les softphones impliqués. Essai. Ça ne
- Mail original -
De: "frnog"
> Donc session timeout: Essaye en mettant session-timers=refuse dans la config
> d'un client qui génère cette erreur
J'ai fait. Reload Asterisk. Restart tous les softphones impliqués. Essai. Ça ne
fonctionne pas, ça coupe toujours après 32 secs.
Un autre article qui parle de ça, et qui donne le bon paramètre pour le
linphonerc, utilisable évidemment seulement si le VPN attribue une IP fixe:
https://linphone-users.nongnu.narkive.com/g4m2kB9q/how-to-tell-linphone-which-ip-address-to-use
Le 17/03/2020 à 15:05, Guillaume LUCAS a écrit :
[...]
Réussis tu à pinguer l'IP en 192.168.x.y à partir du PABX ?
Non, mais je ne veux pas faire ça. Sinon faut que je route 192.168.0.0/24 pour
NC-SFR, 192.168.1.0/24 pour un autre FAI, 192.168.42.0/24 pour le geek, 172.16
pour MacDo, etc.
> Faire marcher SIP à travers NAT çà a toujours été une galère, mais au travers
> d'un VPN je ne vois pas pourquoi çà ne marcherait pas.
+1
>> Nous n'avons pas de NAT. À mes yeux, le VPN est un réseau interne comme un
>> autre.
+1
--
Be Seeing You
Number Six
---
> - Mail original -
> De: "David Ponzone"
> Ok, un truc couillon: ça fait une différence si tu montes le VPN AVANT et
> APRÈS de lancer Linphone ?
Alors, ça ne m'était pas venu à l'idée d'ouvrir Linphone avant de monter le
VPN, pour moi c'était sûr qu'il ne faut pas faire ça. J'ai
> - Mail original -
> De: "frnog"
> À: "frnog"
> Envoyé: Mardi 17 Mars 2020 14:24:12
> Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il
> vraiment autant de bugs que ça dans les implémentations SIP ?!)
> Tu pars du pr
Le 17/03/2020 à 14:08, Guillaume LUCAS a écrit :
- Mail original -
De: "frnog"
À: "frnog"
Envoyé: Mardi 17 Mars 2020 09:23:08
Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment
autant de bugs que ça dans les implémentations SIP
d Ponzone"
> À: "Guillaume LUCAS"
> Cc: "frnog"
> Envoyé: Mardi 17 Mars 2020 13:42:12
> Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il
> vraiment autant de bugs que ça dans les implémentations SIP ?!)
>
>>
>> En mêm
> - Mail original -
> De: "frnog"
> À: "frnog"
> Envoyé: Mardi 17 Mars 2020 09:23:08
> Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il
> vraiment autant de bugs que ça dans les implémentations SIP ?!)
> Je pense que Li
Le 17/03/2020 à 13:47, Daniel via frnog a écrit :
[..] Je donne les preuves suivantes :
* Dans le journal de mon Asterisk, j'ai bien des « chan_sip.c:
Registered SIP 'bczhcigi' at 10.30.1.175:62633 ». 10.30.X.X est bien
une IP VPN. Je vois bien une IP 10.30/16 différente par
bjet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment
autant de bugs que ça dans les implémentations SIP ?!)
>
> En même temps, de mes souvenirs de cours VOIP et de ma pratique précédente de
> la VOIP, c'est la banalité de dire que ce ne sont pas les bonnes ad
>
> En même temps, de mes souvenirs de cours VOIP et de ma pratique précédente de
> la VOIP, c'est la banalité de dire que ce ne sont pas les bonnes adresses IP
> qui sont échangées dans SDP…
>
Je ne comprends pas le sens de cette phrase (put…je vieillis) :)
---
> - Mail original -
> De: "David Ponzone"
> À: "Guillaume LUCAS"
> Cc: "frnog"
> Envoyé: Mardi 17 Mars 2020 07:34:53
> Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il
> vraiment autant de bugs que ça dans les
….
Opensource n’est pas synonyme de qualité.
> Le 17 mars 2020 à 13:32, Guillaume LUCAS a
> écrit :
>
>> - Mail original -
>> De: "Michel Py"
>> À: "Daniel" , "frnog"
>> Envoyé: Mardi 17 Mars 2020 01:19:26
>> Objet: RE: [FR
> - Mail original -
> De: "Michel Py"
> À: "Daniel" , "frnog"
> Envoyé: Mardi 17 Mars 2020 01:19:26
> Objet: RE: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il
> vraiment autant de bugs que ça dans les implémentations SIP
Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment
autant de bugs que ça dans les implémentations SIP ?!)
Bonsoir,
tout d'abord la version de Xivo/Asterisk n'étant pas connu, il y a des
différences importantes entre chan_sip et pjsip.
. les problèmes de sons qui ne passe
Bonjour à tous,
On mixte du softphone (Zoiper) et du téléphone IP depuis 15 ans en IPsec/VPN
SSL,anciennement MPLS sur du Asterix/Xivo/Mitel et anciennement Ericson sur des
réseaux internes pas RFC 1918 (quelle idée mais c'est historique)
Au tout début j'ai eu des problèmes d'implémentations à
https://superuser.com/questions/1133293/linphone-sip-invite-providing-wrong-ip-on-multi-nic-system
Tu es visiblement pas le seul à avoir ce problème de binding.
Pas beaucoup de discussion sur ce sujet néanmoins.
Ca vaut quand même le coup de tester Zoiper ou Bria au moins pour avoir la
> Daniel Huhardeaux a écrit :
> les problèmes de sons qui ne passent pas d'un côté et/ou de l'autre sont dus
> à des problèmes de NAT
+1. Ou de pare-feu. Dans le genre le port 5060 est ouvert mais les ports
utilisés par RTP ne le sont pas.
Le seul softphone dont je me sers est GSWave de
À: frnog@frnog.org
Envoyé: Lundi 16 Mars 2020 22:53:47
Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment
autant de bugs que ça dans les implémentations SIP ?!)
Bonsoir,
tout d'abord la version de Xivo/Asterisk n'étant pas connu, il y a des
différences importantes entre c
Bonsoir,
tout d'abord la version de Xivo/Asterisk n'étant pas connu, il y a des
différences importantes entre chan_sip et pjsip.
. les problèmes de sons qui ne passent pas d'un côté et/ou de l'autre
sont dus à des problèmes de NAT
. les timeout peuvent être dus au session-timer et doivent
80 matches
Mail list logo
