Problem
This article explains how to set up monitor subscriber next call settings previous to the start of the call capture process. Every time monitor subscriber next-call is run, the settings for the previous run of that command are lost and need to be re-selected. This can be especially painful if a number of options need to be enabled for the particular scenario that is being troubleshot, especially if what is being troubleshot is happening right at the beginning of the call before one has the chance to select all the options like a Speedy Gonzales.
Solution
Use the monitor subscriber menu option approach and choose option F) Next-Call, start a capture and choose the options of interest, and then hit Escape key ONCE. Back at the menu choose F again and all of the previously selected options will still be in effect and the data desired will start to be collected without missing anything. If Escape key is hit twice in a row by accident that would lead back to the system prompt, go through this process again to set up for further captures.
This approach can be especially useful for capturing certain types of calls that have a low percentage chance of being captured. For example imagine a node that carries a small amount of Evolved High Rate Packet Data (eHRPD) traffic along with a larger amount of 3G Mobile IP (MIP) traffic. The percent of eHRPD calls is low compared to MIP and it might take a while to capture an eHRPD call. Also, these calls start off the same way as MIP calls, and so using the option "o) Next-EVDO-RevA Call" would result in capturing both call types. The same approach described earlier with respect to the system remembering the last options can be used as follows. Start in the context where eHRPD calls arrive, then run monitor subscriber, choose next-call and then choose option "L" for Limit context which will only capture calls in the current context, which is the context where the mon sub was just initiated. Then press Escape and when Next-call is selected again, only eHPRD calls will be captured. Repeat as many times as necessary.
The disadvantage with the limit context option is that packets for the call passing through other contexts, i.e. the egress context where the Proxy MIPv6 exchange with the PGW takes place, will not be captured. That may or may not be important for your troubleshooting scenario.
The gist of this approach is that one can work around restrictions of plain monitor subscriber next-call and next-call variants.
Feedback