Asterisk un contexte entrant par trunk ?

[seb]

Bonjour,

Je suis en train de me documenter sur la configuration "un contexte par trunk pour appels entrants" pour Asterisk...

Je rappelle le contexte d'origine :

J'ai plusieurs trunk SIP vers le même provider, les registers pointeront tous vers la même IP. Sous XiVO il n'est pas possible de faire cette séparation sur les contextes entrants.

Il me semble que Jean m'avait dit que sur du "Asterisk pur" cela peut être effectué, sur mes recherches, je ne trouve pas vraiment de réponse si cela est faisable.

Est-ce que d'après vous cela est possible de faire :

Appel entrant vers N° 123 > SIP Provider: 1.1.1.1 >>>> Trunk1 => ContexteIN_1
Appel entrant vers N° 456 > SIP Provider: 1.1.1.1 >>>> Trunk2 => ContexteIN_2
Appel entrant vers N° 789; 111 > SIP Provider: 1.1.1.1 >>>> Trunk3 => ContexteIN_3

Merci

[jean]

non, sur asterisk pur, on peut tout envoyer de manière controlée dans le même contexte

je pense que ton problème de voix robotisée n'est pas liée à ça. au pire, il faut vérifier que les bons codecs sont utilisées (sip show channels pendant la comm). s ils ne varient pas d'une config à l'autre, il n'y a vraiment pas de logique à ce que la qualité soit dégradée

[seb]

Salut Jean :)

Si tu te souviens de mon souci, mes appels entrants ne passent pas par le bon trunk sur Xivo, il choisit le dernier trunk enregistré.

Je voudrais éviter cela en passant directement par un asterisk afin de contrôler plus finement le register et le choix du context inbound.

[olppp]

Bonjour,

Pour moi, ce comportement est du à Asterisk plus qu'à Xivo. Une IP source = 1 context.

[seb]

Salut olppp,

Xivo n'y est pour rien effectivement lorsque on utilise la même IP, donc il n'est pas possible de faire :

IP W.W.W.W context1 avec user1/mdp1
IP W.W.W.W context2 avec user2/mdp2

etc ?

[olppp]

Une source = un context. Par contre , tu peux dans ce context router tes appels suivant la destination.
111 => jump 111@context_111
222 => jump 222@context_234
333 => jump 333@context_234
_44[0-9] => jump ${EXTEN}@context_234

[seb]

Je ne te suis plus olppp :confused:

Tu me dit plus haut "Une IP source = 1 context." comme expliqué j'ai la même IP (1 IP pour enregistrer les 3 trunk) donc cela ne fera pas 3 context mais 1 context, nous somme d'accord ?


Par contre , tu peux dans ce context router tes appels suivant la destination.
Donc cela revient bien au fonctionnement que j'ai actuellement avec Xivo non ?
Car je fais rentrer tous mes trunk dans le context "from-extern" et ensuite je dispatch sur des contextes internes pour joindre tel ou tel poste en fonction du N° entrant.

[olppp]

Ta configuration est bonne. Comme le dit Jean, les problèmes de qualité audio viennent certainement d'ailleurs.

[olppp]

Quel est ta config. réseau ?

[seb]

Ta configuration est bonne. Comme le dit Jean, les problèmes de qualité audio viennent certainement d'ailleurs.

Oui mais cela reste un mystère quand même car comme je l'avais expliqué je me demandai si le fait d'avoir tous mes trunk sur la même IP ne pouvait pas à moment donner provoquer des problèmes sur la monopolisation du nombres de canaux par trunk, puisque asterisk utilise toujours le dernier trunk sur l'appel entrant...

Le phénomène c'est présenté lorsque j'ai rassemblé tous les trunk sur le même Xivo, le hasard peut être :confused:

La configuration est "normale" le serveur xivo est hébergé et je connecte mes téléphones dessus via connexion sdsl/fibre

[Gavroche95]

Bonjour à tous,



Je suis en train de me documenter sur la configuration "un contexte par trunk pour appels entrants" pour Asterisk...
A priori on a le même besoin :wink:



Appel entrant vers N° 123 > SIP Provider: 1.1.1.1 >>>> Trunk1 => ContexteIN_1
Appel entrant vers N° 456 > SIP Provider: 1.1.1.1 >>>> Trunk2 => ContexteIN_2
Appel entrant vers N° 789; 111 > SIP Provider: 1.1.1.1 >>>> Trunk3 => ContexteIN_3
J'ai pas mal galéré pour parvenir à ce résultat (un peu comme toi et surement plein d'autres), mais je pense avoir trouvé une solution satisfaisante :)

Le problème réside dans le fait qu'Asterisk se base sur l'adresse du provider pour déterminer sur quel trunk l'appel est présenté.
Celle que l'on voit dans les logs SIP sous cette forme :

<--- SIP read from UDP:1.1.1.1:5060 --->
Mes différents tests montrent qu'il parcours les trunks et s'arrête dès qu'il a une correspondance. Ce qui, dans le cas qui nous intéresse, le conduit inexorablement à utiliser toujours le même trunk et par conséquent toujours le même context.

Bon allez, vous avez suffisamment attendu, l'astuce consiste à affecter un port différent à chaque trunk : 5060,5061,5062,...


sip.conf :
[general]
register => USER1:PWD1@1.1.1.1:5060
register => USER2:PWD2@1.1.1.1:5061
register => USER3:PWD3@1.1.1.1:5062

[Trunk1]
...
host= 1.1.1.1
port=5060
context=from-Trunk1
...
[Trunk2]
...
host= 1.1.1.1
port=5061
context=from-Trunk2
...
[Trunk3]
...
host= 1.1.1.1
port=5062
context=from-Trunk3
...

Il ne reste alors plus qu'à NATté tous ces ports vers celui du provider 5060.


1.1.1.1:5060 --> NAT --> 1.1.1.1:5060
1.1.1.1:5061 --> NAT --> 1.1.1.1:5060
1.1.1.1:5062 --> NAT --> 1.1.1.1:5060

Pour peu que les lignes soient bien dispatchés côté provider, on obtient alors quelque chose de ce genre :


Appel entrant vers N° 123 > SIP Provider: 1.1.1.1:5060 >>>> Trunk1 => from-Trunk1
Appel entrant vers N° 456 > SIP Provider: 1.1.1.1:5061 >>>> Trunk2 => from-Trunk2
Appel entrant vers N° 789 > SIP Provider: 1.1.1.1:5062 >>>> Trunk3 => from-Trunk3

Alors oui, la solution demandée ne devait qu'être pur Asterisk, mais qui de nos jours laisse encore un Asterisk sans pare-feu :confused:


A vot' bon coeur m'ssieursdames


Cordialement,
Bruno.

[seb]

Bonjour Bruno,

Merci du retour seulement l'astuce du port n'est pas possible chez moi, car le provider SIP m'impose un numéro de port.

Le numéro de port est le même pour chaque trunk, l'IP est aussi la même pour chaque trunk :whistle:

Le serveur n'est pas derrière un NAT, il est directement avec une IP publique.


Alors oui, la solution demandée ne devait qu'être pur Asterisk, mais qui de nos jours laisse encore un Asterisk sans pare-feu
Par "Asterisk pur" j'entend uniquement Asterisk sans surcouche XiVO/FreePBX ect...

Quelque que soit la "surcouche" il est primordial d'avoir un firewall derrière :)

[Gavroche95]

Salut seb,


Je dois bien avouer que ta réponse me laisse un peu perplexe.



Merci du retour seulement l'astuce du port n'est pas possible chez moi, car le provider SIP m'impose un numéro de port.

Le mien non plus, OVH en l’occurrence, d'où le NAT de port



Le numéro de port est le même pour chaque trunk, l'IP est aussi la même pour chaque trunk :whistle:

C'est bien notre souci



Le serveur n'est pas derrière un NAT, il est directement avec une IP publique.
...
Quelque que soit la "surcouche" il est primordial d'avoir un firewall derrière :)


Il n'est pas derrière un NAT mais derrière un firewall, possèdes-tu un firewall qui ne sait pas faire de NAT :confused:

Le NAT sert, dans notre cas, uniquement à modifier le port destination 5061->5060, l'IP et le port d'asterisk ainsi que l'IP du provider ne sont pas touchées.


Cordialement,
Bruno.

[quintana]

C'est sûrement une distrib linux donc ça doit marcher avec un iptables directement sur la machine aussi ta solution.

[seb]

[QUOTE=Gavroche95;20334]
Le NAT sert, dans notre cas, uniquement à modifier le port destination 5061->5060, l'IP et le port d'asterisk ainsi que l'IP du provider ne sont pas touchées.
[QUOTE]

Si, sur l'Asterisk j'utilise un script iptables comme firewall :wink:

Tu utilises iptables aussi pour faire ton NAT ?

[Gavroche95]

Tu utilises iptables aussi pour faire ton NAT ?

J'ai un firewall hardware qui s'en charge, je t'avoue ne pas avoir chercher à le faire avec iptables

J'utilise un Asterisk en front pour centraliser les trunks de plusieurs marques qui possède chacune son propre serveur. La différenciation des ports me permet de simplifier le routage vers ces serveurs en utilisant un context par marque plutôt qu'avoir à déclarer toutes les inbound routes sur mon serveur de front.

Voici les services et les règles de NAT que j'ai définit dans mon FW.

543
CPT, NOM, VDM et TDV sont les différentes marques, chacune utilise un port différent.

544
Tous ces ports sont NATTés vers le classique UDP/5060


Cordialement,
Bruno.