wireshark mate sip 2nd or 3rd pdu filter

Question

I have a wireshark capture that contains a lot of sip subscribe and notify. I am using mate to do the filtering. Each gop will contain normally 4 PDUS (Subscribe-200OK, Notify-200OK). I can filter the first and last pdu of all Gops, but I would like to filter only the 2nd or 3rd pdu of all gops. Does anyone have an idea on how I can achieve this. Is it a filter that I don't know about or some more work in the mate script?. Here is the mate script.

Transform start_stop_cond {
Match (method="SUBSCRIBE") (msg_type=start);
Match (resp_code,req_method="NOTIFY") (msg_type=stop);
};
Pdu sip_pdu Proto sip Transport ip {
Extract user From sip.from.user;
Extract user From sip.to.user;
Extract user From sip.ppi.user;
Extract callid From sip.Call-ID;
Extract method From sip.Method;
Extract cseq From sip.CSeq.seq;
Extract resp_code From sip.Status-Code;
Extract req_method From sip.CSeq.method;
Transform start_stop_cond;
};
Gop sip_gop On sip_pdu Match (callid) {
Start(msg_type=start);
Stop(msg_type=stop);
};
Done;

Thanks so much in advance.

Accepted Answer

Okay, so we've moved from a generic requirement, which was almost impossible to fulfil, to a specific one. Much easier, I tell ya :-)

My suggestion here is to forge a dedicated GoP AVP using a Transform in the GoP. The principle relies on the fact that the Transform is invoked each time when the GoP's AVPL is modified due to assignment of a new PDU to the GoP, and that the Match clauses within a Transform are only executed until the first success.

So you'd use a "flag" AVP which would be added to the GoP's AVPL when either the 200(SUBSCRIBE) or the NOTIFY arrive while this flag AVP hasn't been created yet, and the value of this AVP would be either "200" or "NOTIFY" depending on which message has caused it to be added to the GoP's AVPL.

There is another important thing, a Transform used in a GoP works with the AVPL of the GoP, not with the AVPLs of the newly arrived PDUs. So we have to add a single unique AVP per each PDU to the GoP's AVPL so that the GoP's Transform would do what we want. This effectively means that we need to forge a single AVP distinguishing the 200 response to SUBSCRIBE from the 200 response to NOTIFY at PDU level, and Extra it into the GoP.

So the complete code would be something like:

Transform start_stop_cond {
  Match (method="SUBSCRIBE") (msg_type=start);
  Match (resp_code,req_method="NOTIFY") (msg_type=stop);
};
Transform xtract_rsp {
Match (resp_code, req_method="SUBSCRIBE") Insert (resp_to="SUBSCRIBE");
Match (resp_code, req_method="NOTIFY") Insert (resp_to="NOTIFY");
};
Pdu sip_pdu Proto sip Transport ip {
Extract user From sip.from.user;
Extract user From sip.to.user;
Extract user From sip.ppi.user;
Extract callid From sip.Call-ID;
Extract method From sip.Method;
Extract cseq From sip.CSeq.seq;
Extract resp_code From sip.Status-Code;
Extract req_method From sip.CSeq.method;
Transform start_stop_cond, xtract_rsp;
};
Transform mark_it {
Match (first_was);
// only this rule, which doesn't change the GoP's AVPL, is executed if the first_was AVP already exists for the GoP's AVPL, ensuring that it is added only once
Match (method="NOTIFY") Insert (first_was="NOTIFY");
Match (resp_to="SUBSCRIBE") Insert (first_was="RSP2SUBSCRIBE");
};
Gop sip_gop On sip_pdu Match (callid) {
Start(msg_type=start);
Stop(msg_type=stop);
Extra (method,resp_to);
Transform mark_it;
};
Done;

EDIT: To respond the title of the question rather than the particular need, the approach actually could be generalized in terms that you could

organize a rudimentary PDU counter in a GoP (but the increment function needs to be implemented manually using a Transform, so the processing speed would be impacted and the number of PDUs per GoP would have to be reasonably low)
save information about several PDUs of interest (e.g. the 2nd and the 3rd) for use in display filter, but as the AVPs can only be assigned constant values, not values of other AVPs, and each protocol field may only be Extracted once per PDU, there is no way to e.g. store the cseq values of these messages
delete the information from each new PDU after it has been used to modify the GoP’s AVPL, using a “cleanup” Transform. This last step may also functionally replace the PDU’s own Transform creating the “resp_to” AVP.

So an example of the result would look like this:

Transform start_stop_cond {
Match (method="SUBSCRIBE") (msg_type=start);
Match (resp_code,req_method="NOTIFY") (msg_type=stop);
};
Pdu sip_pdu Proto sip Transport ip {
Extract user From sip.from.user;
Extract user From sip.to.user;
Extract user From sip.ppi.user;
Extract callid From sip.Call-ID;
Extract method From sip.Method;
Extract cseq From sip.CSeq.seq;
Extract resp_code From sip.Status-Code;
Extract req_method From sip.CSeq.method;
Transform start_stop_cond;
};
Transform pdu_counter {
Match (last_pdu=9) Replace (last_pdu="max");
Match (last_pdu=8) Replace (last_pdu=9);
Match (last_pdu=7) Replace (last_pdu=8);
Match (last_pdu=6) Replace (last_pdu=7);
Match (last_pdu=5) Replace (last_pdu=6);
Match (last_pdu=4) Replace (last_pdu=5);
Match (last_pdu=3) Replace (last_pdu=4);
Match (last_pdu=2) Replace (last_pdu=3);
Match (last_pdu=1) Replace (last_pdu=2);
Match (last_pdu="max") ();
Match () Insert (last_pdu=1);
};
Transform record_2nd {
Match (last_pdu{1|3|4|5|6|7|8|9|"max"});
//skip the rest unless we're dealing with PDU number 2
Match (method="NOTIFY") (pdu_2="NOTIFY");
Match (resp_code,req_method="SUBSCRIBE") (pdu_2="RSP2SUBSCRIBE");
Match () (pdu_2="OTHER");
};
Transform record_3rd {
Match (last_pdu{1|2|4|5|6|7|8|9|"max"});
//skip the rest unless we're dealing with PDU number 3
Match (method="NOTIFY") (pdu_3="NOTIFY");
Match (resp_code,req_method="SUBSCRIBE") (pdu_3="RSP2SUBSCRIBE");
Match () (pdu_3="OTHER");
};
Transform drop_extra {
Match Loose (method, resp_code,req_method) Replace ();
};
Gop sip_gop On sip_pdu Match (callid) {
Start(msg_type=start);
Stop(msg_type=stop);
Extra (method,resp_code,req_method);
Transform pdu_counter,record_2nd,record_3rd,drop_extra;
};
Done;