Centralisation des appels externe

Discussion in 'Elastix 2.x' started by JUNIOR, Sep 25, 2009.

  1. JUNIOR

    Joined:
    Aug 10, 2009
    Messages:
    140
    Likes Received:
    0
    Bonjour a tous
    j'ai interconnecté deux IPBX un au siege et l'autre dans une agnece qui foncxtionne bien
    voici les config
    Au siege : @IP 213.XXX.XXX.XXX

    Trunk
    Peer Detail
    host=94.WWW.WWW.WWW
    qualify=yes
    type=peer

    Dial rule
    XX.

    Trunk name Interoffice

    uSER Detail
    context=from-internal
    host=94.WWW.WWW.WWW
    type=user

    Outbound route

    Dial Partners

    XXXX


    Trunk sequence: IAX2\interoffice

    A L'AGENCE : @IP 94.XXX.XXX.XXX

    Trunk
    Peer Detail
    host=213.WWW.WWW.WWW
    qualify=yes
    type=peer

    Dial rule
    XX.

    Trunk name Interoffice

    uSER Detail
    context=from-internal
    host=213.WWW.WWW.WWW
    type=user

    Outbound route

    Dial Partners

    XXXX


    Trunk sequence: IAX2\interoffice

    Cette configuration fonctionne bien
    Mon objectif est: je veux faire passé toute les communications externe par le siege. une centralisation des appels externe
    Je vous informe que j'ai deja un trunk et une route qui me permet de faire des appels extene au siege.
    si quelq'un a une idée de la config a ajoute sa serai la bien venu pour moi.
     
  2. Patrick_elx

    Joined:
    Dec 14, 2008
    Messages:
    1,120
    Likes Received:
    0
    il suffit de déclarer tes routes sortantes vers le siège...
     
  3. danardf

    Joined:
    Dec 3, 2007
    Messages:
    8,069
    Likes Received:
    12
    Hmmmm, oui autre autre.
    Pour ma part avec ce type de config si je ne mets pas de context dans les trunk inter-elastix, les comm internes passeront mais pas les comm externe (en sortie par transit).
    Par contre, il y a une transparence si tu mets context=from-internal dans tes trunk inter-Elastix.

    Exemple (en composant le 0 pour l'accès operateur):
    (Ext: 100) ----[A]<---------->--(operateur)

    Ta route sortante dans A sera :
    0.
    et ton trunk lié sera ton trunc inter-Elastix

    Si tu ne mets pas de context, tu ne pourras pas sortir vers ton opérateur.

    Pas de pétard, ça fonctionne! :p
    T'embêtes pas à mettre type user et peer et d'utiliser le user detail!

    quelques paramètres dans la première partie.

    host=Ip_distant
    qualify=yes
    type=friend
    canreinvite=yes
    context=from-internal
    disallow=all
    allow=(codecs désirés)
    nat=yes si besoin

    Pas de chichi. Simple.... efficace.
     
  4. Patrick_elx

    Joined:
    Dec 14, 2008
    Messages:
    1,120
    Likes Received:
    0
    Attention Franck, tu donnes trop d'infos et trop vite... ca risque de générer pleins de questions ;-)


    Pour ma part, je crée un custom context pour ces liaisons afin d'avoir une meilleure granularité sur les droits d'accès.

    Enfin, ne pas oublier de gérer les appels d'urgences qui doivent être transmis directement et non pas par le siège. Imagine l'agence qui appelle les pompiers et que ces derniers se pointent au siège...
     
  5. danardf

    Joined:
    Dec 3, 2007
    Messages:
    8,069
    Likes Received:
    12
    Oui, tu as raison pour les n° d'urgence.
    je parle bien sure la manière d'y arriver nativement sans pour autant faire un context perso.

    J'évoquais ce cas de figure car j'ai due batailler pendant pas la de temps pour avoir une sortie via le site distant. Et la manière la plus simple et efficace, c'est bien from-internal.
    Pour les n° d'urgence en transparence il y a certainement un custom_context à faire.

    Pi comme je n'ai pas l'habitude de garder les choses pour moi.. je partage ce que je connais. Après si ça génère d'autres questions.... Why not.
    Je part d'un bon sentiment. :laugh:
     

Share This Page