Wireshark Mate Gop’s not collected in same Gog.

I’m not quite sure what you’re saying. A single complete_call GoG should have only one mport (which is the same in the megaco_dialog and the sip_dialog compontents of that GoG), right?

I’m not sure what all these other ports are.

@Andreas J, if still interesting, I’ll try to clarify what @JeffMorris wrote: the name of the attribute used as the key to aggregate matching Gops into a Gog must be literally the same for all Member Gops. The statement

Gog gog_name {
Member dlg_1 ( port_1 );
Member dlg_2 ( port_2 );
}

does not mean, in MATE syntax, that values of attribute port_1 of Gop dlg_1 would be treated the same way like the values of attribute port_2 of Gop dlg_2; it just means that values of port_1 should be looked for in Gogs named dlg_1, and values of port_2 should be looked for in Gogs named dlg_2.

So unless port_1 is literally the same string like port_2, all dlg_1 with the same port_1 values would be grouped together, and all dlg_2 with the same port_2 values would also be grouped together, but even for identical values of port_1 and port_2, these groups of Gops would remain separate from each other although they would have the same Gog name gog_name.

So all the way up from Pdu through Gop to Gog, you must use the same identifier, like media_port:

Pdu sip_msg Proto sip Transport ip {
Extract sip_callid From sip.Call-ID;
Extract sip_method From sip.Method;
Extract sip_cseq_method From sip.CSeq.method;
Extract media_port From sdp.media.port;
};

Gop sip_dialogue On sip_msg Match (sip_callid) {
Start(sip_method="INVITE");
Stop(sip_cseq_method="BYE");
Extra (media_port);
};
Pdu megaco_msg Proto megaco Transport sctp {
Extract media_port From sdp.media.port;
Extract megaco_transid From megaco.transid;
Extract megaco_transaction From megaco.transaction;
};
Gop megaco_dialogue On megaco_msg Match (megaco_transid) {
Start(megaco_transaction="Request");
Stop(megaco_transaction="Reply");
Extra (media_port);
};
Gog complete_call {
Member sip_dialogue (media_port);
Member megaco_dialogue (media_port);
};

A loose match has a different meaning and is not applicable here.

But that’s still not all. I would need a sample capture to be 100 % sure, but if you collect more values of media_port per sip_dialogue or megaco_dialogue (as you definitely do at least because you do not distinguish between local SDP and remote SDP, so you do have two media_port per dialog, leaving aside that there may be multiple media streams per SDP and multiple SDPs per party of a dialog), the Gog may still not be aggregated properly. So you would need to identify the proper one of the two SDPs available in each of the protocols and extract the media_port only from it, not from the other one.

Next, I somehow cannot imagine a scenario where the SIP and MEGACO would be captured on the same machine and would both send the same SDP; I can only imagine that you receive a remote SDP in SIP and forward it as local one in Megaco or vice versa. If this is the case, you may have several remote SDPs with the same media port but different media IP address, so you’d need to add the media IP address as an attribute in order to avoid mixing several dialogs together into a single Gog.