3.8.2. Parallel Forking (Forking parallèle)
3.8.2. Parallel Forking (Forking parallèle)
Le forking parallèle implique qu'un appel soit envoyé à plusieurs appelés distants, où chaque appelé peut accepter l'appel et plusieurs sessions de signalisation actives simultanées peuvent être établies en conséquence. Si plusieurs appelés envoient des médias en même temps, les possibilités de gestion de cette situation sont décrites dans [RFC3960], Section 3.1. La plupart des appareils SIP aujourd'hui ne prennent en charge que l'échange de médias avec un seul appareil à la fois et n'essaient pas de mélanger plusieurs sources audio de médias précoces, car cela pourrait entraîner une situation confuse. Par exemple, considérez avoir une tonalité de retour européenne mélangée avec la tonalité de retour nord-américaine -- le son résultant ne ressemblerait à aucune des deux tonalités et confondrait l'utilisateur. Si l'application de signalisation souhaite uniquement échanger des médias avec l'un des points de terminaison distants à la fois, alors du point de vue du moteur média, c'est exactement comme le cas du forking séquentiel.
Dans le cas du forking parallèle où l'application JavaScript souhaite échanger simultanément des médias avec plusieurs pairs, le flux est légèrement plus complexe, mais l'application JavaScript peut suivre la stratégie décrite par [RFC3960], en utilisant UPDATE. L'approche UPDATE permet à la signalisation de configurer un flux média séparé pour chaque pair avec lequel elle souhaite échanger des médias. Dans JSEP, cette offre utilisée dans l'UPDATE serait formée en créant simplement une nouvelle PeerConnection (voir Section 4.1) et en s'assurant que les mêmes flux de médias locaux ont été ajoutés à cette nouvelle PeerConnection. Ensuite, le nouvel objet PeerConnection produirait une offre SDP qui pourrait être utilisée par la signalisation pour effectuer la stratégie UPDATE discutée dans [RFC3960].
En conséquence du partage des flux de médias, l'application se retrouvera avec N sessions PeerConnection parallèles, chacune avec une description locale et distante et leurs propres adresses locales et distantes. Le flux de médias de ces sessions peut être géré à l'aide de setDirection (voir Section 4.2.3), ou l'application peut choisir de lire les médias de toutes les sessions mélangées ensemble. Bien sûr, si l'application ne souhaite conserver qu'une seule session, elle peut simplement mettre fin aux sessions dont elle n'a plus besoin.