Inject Sipp variable substitution (field0, field1, etc.) from CSV file in send_digits

[gandikotam]

It would be wonderful if Sipp variables can be specified in the send_digits step where the variable (field0, field1, etc.) can be substituted from the CSV file. A sample YML is as follows:

source: sipp.mycomp.net destination: asterisk.mycomp.net max_concurrent: 10 calls_per_second: 5 number_of_calls: 20 steps:

• invite
• wait_for_answer
• ack_answer
• sleep 3

Thanks

• send_digits '1'
• sleep 5
• send_digits [field0]
• sleep 10
• send_digits [field1]
• sleep 60
• wait_for_bye

[bklang]

The example you gave is unfortunately impossible. The field expansion such as [field0] happens inside of SIPp at runtime. The way send_digits works is to actually create a PCAP file that contains the appropriate DTMF. SIPp is not smart enough to know how to generate DTMF on its own, which was one of the motivations for designing Sippy Cup in the first place.

I'm not sure how to make this happen for you. A couple of options, though I don't like either of them:

• Generate multiple SIPp scenarios, one for each field, and run them concurrently (requires no changes to Sippy Cup)
• Generate multiple SIPp scenarios and then manually combine them into a single scenario and run it through SIPp with probability distributions.

Both of the above aren't really workable if you have a very large number of permutations, as you'd have to create one PCAP file for each permutation.

One other possibility: if your system can support DTMF via SIP INFO, it should be possible to use that with SIPp field expansion. This would require some changes to SippyCup. If you wanted to contribute that in the form of a pull request, it would be very welcome.

[gandikotam]

Thank you Ben Klang for your kind reply. Sipp v 3.3 had a patch to play DTMF. I use that effectively in my testing. Coming to sipp v 3.4.1 there is no similar patch.

I didn't fully understand the SIP INFO possibility you had mentioned. Could you kindly send me some sample YML/XML? I tried specifying "dtmf_mode: info" in the header of the YML before the steps. The resulting XML sent one digit at a time. I thought that was way too inefficient. Is there a better way?

Thanks