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

[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

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


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

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

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

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.