Discussion sur la conception

La séparation SipCall/Call

Un des problèmes actuels est la séparation des classes Call et SipCall. En plus d'être mélangeant pour les nouveaux programmeurs (un SipCall n'hérite pas de Call), quelques informations sont redoublées. La classe SipCall nécessite de connaître l'état du Call et donc de demander à la classe ManagerImpl (un contrôleur singleton) sur l'état de l'appel. Cette séparation entraîne aussi une synchronisation constante entre la liste d'appels (CallVector) dans la classe ManagerImpl et la liste d'appels SIP (SipCallVector) du lien SIP (SipVoIPLink). Cependant, cette méthode a pour avantage de permettre au contrôleur de gérer l'accès aux appels d'une façon exclusive à l'aide de Mutex.

Présentement, les SipCall peuvent être accéder de façon non protégée à l'intérieur de la class SipVoIPLink.

Une solution à ce problème pourrait être d'hériter les SipCall et AIXCall de la classe Call. Ainsi, les appels spécifiques au protocole (SIP et AIX), aurait accès directement à l'état de l'appel, le nom du correspondant, etc. De plus, le ManagerImpl, pourrait avoir accès à ces appels avec l'interface de la classe Call sans connaître les caractéristiques propres à chaque protocole. Un Mutex sur les fonctions de Call et SipCall permettrait de protéger les attributs même si deux fils d'exécution (threads) essaient de les modifier. Le mutex permettant la protection des attributs serait contenu à même la classe Call.

La gestion de deux listes d'appels (ManagerImpl / SipVoIPLink)

Les listes d'appels est sujète à être modifié par les appels entrants et les appels sortants. Il faut donc protéger à tout prix ces listes pour ne pas causer de corruption de liste. Présentement, le contrôleur (ManagerImpl) contient une liste d'objets Call et le lien VoIP (SipVoIPLink) contient une liste de SipCall. Le contrôleur doit maintenir une liste d'appels pour permettre d'associer un numéro d'appel unique à une instance de l'objet Call pour modifier son état. Le lien VoIP doit maintenir une liste de SipCall pour modifier leur état (parfois spécifique à SIP) et pour les gérer (ajout, suppression). Suite à la fusion des Call/SipCall, trois choix s'offrent à nous:

• Gérer les appels seulement dans les liens VoIP (VoIPLink) associés à un compte utilisateur. Le protocole de communications qui contient seulement des numéros d'appels devraient être modifié en profondeur pour ajouter l'identifiant du compte associé à l'appel.

  InterfaceQT (id) -> GuiServer (id) -> GuiFramework (CallID) -> 
     ManagerImpl (CallID) -> getCall(CallID) -> Call
  
  deviendrait:
  
  InterfaceQT (account,id) -> GuiServer(account,id) -> GuiFramework(account,CallID) -> 
    ManagerImpl (account, CallID) -> getAccount(account)->getCall(CallID) -> Call
  

• Gérer une liste d'appels protégée (liste de Call) dans le contrôleur et gérer une liste d'appels protégée (spécifique au protocole) dans les liens VoIP. L'information des listes doivent être synchonisés en tout temps puisqu'il s'agit de liste de pointeurs sur les mêmes objets. Cette solution apporte aucune modification au protocole, mais permet au contrôleur de modifier directement les appels.
• Gérer une table de correspondance protégée (lookup table) dans le contrôleur entre un numéro d'appel et un compte. La liste protégée des appels (instances de Call) seraient seulement dans les liens VoIP. La table de correspondance permettrait de manipuler un appel via le compte utilisateur / lien VOIP et ne modifierait pas le protocole de communication existant (pas nécessaire d'envoyer un numéro de comptes pour chaque manipulation d'appel). Désavantage: une synchronisation entre les deux tables est requises pour l'ajout et la suppression d'appels.

La dernière solution a été retenue pour ces raisons suivantes:

1. Apporte moins de modifications au protocole (pas besoin d'envoyer toujours un identifiant de compte.
2. Le contrôleur ne gère pas les appels directement, il demande au lien VoIP.
3. L'appel (CALL) ne demande pas au lien de modifier l'appel spécifique (SipCALL).
4. En modifiant les numéros d'ID des appels dans le coeur du projet, on peut enlever la table de correspondance (_callMap) gérée par la classe GUIServer qui associe une chaîne de caractères à un identifiant numérique.

Conception finale

Nouvelle architecture du coeur de SFLphone pour la gestion des appels