Affichage des résultats 1 à 3 sur 3

Discussion: Volumétrie - Enregistrement des téléphones

  1. #1
    Membre Junior
    Date d'inscription
    mai 2013
    Messages
    7
    Downloads
    0
    Uploads
    0

    Volumétrie - Enregistrement des téléphones

    Bonjour,

    Dans le cadre d'une étude de faisabilité sur Asterisk, je cherche à obtenir des données quantitatives sur les sujets suivants :

    - Sur une architecture en mode actif/passif, lors d'un crash du serveur nominal, dans quelle mesure le second serveur peut supporter la charge de ré-enregistrement des téléphones ? Si l'on considère un nombre important de téléphones (500 - 1000).

    - Combien d'appels simultanés est capable de gérer un serveur Asterisk ? Si j'ai 300 communications simultanées en G711, un seul serveur virtualisé suffirait-il ? Si oui, comment faudrait-il le dimensionner ?

    Dans l'attente de vous lire : )

  2. #2
    Membre Association Avatar de celya
    Date d'inscription
    septembre 2010
    Messages
    135
    Downloads
    0
    Uploads
    0
    Bonjour,

    Si le premier serveur crash, la pile sip n’aura pas le temps d'envoyer des 'unregistrar'. Les postes ne sauront pas qu'il est HS et ne renverrons pas de registrar. La volumétrie que prendra le nouveau serveur sera donc la même que l'ancien.
    C'est pas très propre, mais pour que le serveur secondaire connaisse les IP des téléphones il faut répliquer la basse interne d'asterisk, soit /var/lib/asterisk/astdb*

    Pour ma part je ne mettrais pas 300 com simultanée sur un serveur virtualisé.
    CELYA : www.celya.fr
    ASTERISK SERVICE : www.asterisk-service.fr
    MAVISIOCONF : www.mavisioconf.fr
    ATERISK : www.aterisk.fr

  3. #3
    Membre Senior
    Date d'inscription
    septembre 2010
    Localisation
    Where the sun shines
    Messages
    1 418
    Downloads
    0
    Uploads
    0
    quelques éléments...

    - virtualization - faudrait que je recherche les sources, mais à priori, asterisk sur des charges significatives, n'aime pas la virtualization car le timing n'est plus garanti, d'ou risque de dégradation de l'audio - il semblerait que openvz soit moins sujet à ca, vu son archi

    - perfs: deux éléments très importants sur l'impact cpu: a) le transcodage d'un codec à un autre et b) la génération de messages audio (playabck/background)

    Charge de réenregistrement ? mouais, je suis pas convaincu que ca soit si lourd.

    Vu comment tu formules ta question, je doute que ces réponses te satisfassent... je te conseille de monter une maquette, et d'utiliser SIPP pour faire des scénarios de tests

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •