Client Freeswitch ESL: l'application ne reçoit pas les événements de bLeg

Question

Nous avons Freeswitch utilisant ESL (async full) avec une application cliente Java. Lorsqu'un appel entrant arrive, l'application filtre par filtre Channel-Call-UUID aLegUuid et cette entrée est généralement reliée à un bLeg (commande de pont avec park_after_bridge). Donc, nous recevons des événements des deux jambes dans le même Netty Channel Handler.

Pour autant que je sache, dans le même Netty canal Handler nous pourrions recevoir des événements de différentes jambes: https://freeswitch.org/confluence/display/FREESWITCH/mod_event_socket

filter plain all 
filter plain CUSTOM conference::maintenance 
filter Unique-ID $participantB 
filter Unique-ID $participantA 
filter Unique-ID $participantC 

Il y a un cas où BLEG, en appuyant sur un DTMF, transfert (transer XML par défaut) aLeg à 'fifo avec MOH', puis bLeg compose un autre numéro. bLéglez à ce stade en stationnement (park_after_bridge).

Avant unbridge Aleg et BLEG, nous appliquons un autre filtre pour écouter les événements de A et B filtre unique-ID Aleg et filtre unique-ID BLEG mais nous recevons des événements de B esporadically. Certains tests sont bons et d'autres pas.

Si vous créez une connexion entrante vers FS et que vous appliquez les mêmes filtres, nous recevons des événements de A, B, avant et après le pont. Donc, pourquoi ne recevons-nous pas les événements de B dans la principale Netty Channel Handler après la rupture du pont, même avec les filtres appliqués? Comment est le Netty Channel lié aux seuls événements de A?

Merci d'avance pour votre aide

Answer 1

Après la session FreeSwitch sur son HipChat, Mike Jerris a souligné le piece of code qui expliquent pourquoi cela ne fonctionne pas comme je le pense:

if (send && switch_test_flag(l, LFLAG_MYEVENTS)) { 
     char *uuid = switch_event_get_header(event, "unique-id"); 
     if (!uuid || (l->session && strcmp(uuid, switch_core_session_get_uuid(l->session)))) { 
      send = 0; 
     } 
    } 

vous voulez seulement voir les événements de la branche d'appel qui a appelé l'application socket sur une connexion socket sortante

Grâce à "Matthew Vale (@Mafoo) "aussi bien