One of the fundamental functions of many home and business gateways is to act as a SIP ALG (Application Layer Gateway) for setting up, routing, and terminating VoIP telephone calls. This presents some difficulty with Network Address Translation (NAT) functionality that we’ve covered before. However, there’s other functional behavior when it comes to SIP call setup and the resulting RTP streams that can be missed without some rigorous experimentation.
How CDRouter tests VoIP calls in a SIP ALG
CDRouter tests SIP ALG functionality using the sip-alg.tcl and sip-alg-tcp.tcl test modules. There’s also test cases for SIP over IPv6 with the IPv6 add-on.
In tests that pass RTP data, CDRouter performs both call establishment and the passing of RTP data to verify that the session is operational. In the test configuration, CDRouter provides several “knobs” to turn to test different scenarios: the number of calls, the time between call establishment, the delay before RTP traffic is sent over the connection, and the duration to wait for an RTP NAT port mapping to be torn down.
By default, CDRouter initiates each call in sequence and begins sending RTP traffic 5 seconds after the call has been successfully established. One RTP packet is sent in each direction per call every 5 seconds thereafter for the duration of the call (30 seconds).
Adjusting VoIP test variables
You can adjust the different settings for VoIP tests using several testvars.
Number of attempted sessions
The number of inbound and outbound calls can be adjusted separately using the sipMaxOutboundCalls and sipMaxInboundCalls testvars. On their own, these can exercising the ALG’s scaling ability for a certain number of calls. This number doesn’t have a hard limit in CDRouter, but using an unrealistic number of calls probably isn’t practical for testing.
Delay between call setup
You can adjust how fast CDRouter attempts to start new sessions using the sipCallPacing testvar. By default, this is set to 0, which means every SIP session up to the sipMaxInboundCalls or sipMaxOutboundCalls is started as soon as possible (i.e., very quickly). On its own, this is helpful for scaling, but also for fine tuning the behavior of the DUT in the event that some session setups are failing.
Delay before (and between) sending RTP packets
After a session is established, CDRouter waits rtpSendInterval milliseconds before sending RTP data. It’s important to note that CDRouter focuses on the successful routing and delivery of RTP data, rather than the performance and integrity of a real VoIP call. This means that CDRouter will also pause this time between each RTP packet that is sent. If you want to start sending the data as fast as possible, you can set this testvar as low as 40 milliseconds. The SIP ALG tests’ pass/fail criteria is tolerant of dropped RTP traffic, and simply requires that the DUT forward at least 2 packets in each direction for each established call. This variable is important because some implementations will not begin routing RTP traffic immediately after a call is set up - and this variable is a good way to try to discover that behavior.
It should be noted that this variable isn’t in the default CDRouter configuration, but can be added manually in the SECTION "SIP" { section.
Overall duration of the “call” and teardown delay
Lastly, you can use the sipScaleRunTime testvar to adjust how long the session is kept open and RTP traffic is sent. Combined with rtpSendInterval, you can calculate the total number of RTP packets that CDRouter will send during the “call”. Since it often requires some time for a NAT Port Mapping to be torn down after traffic ceases, you can use the sipCallTeardownDelay testvar to adjust how long you expect this to be. If the ALG uses the default UDP traffic timeout, this value should be configured to same timeout as the UDP timeout (testvar natUdpTimeout).
Putting these all together
Adjusting these settings can help to illustrate some hard to miss but important behavior. For example, some DUTs don’t begin forwarding RTP data if other calls are being set up. Others rely on normal NAT behavior to create the mappings, rather than using the contents of the SDP header to actively create UDP port forwarding mappings for the RTP traffic. You can illustrate this behavior by setting the rtpSendInterval to be lower than the sipCallPacing. CDRouter will begin setting up the next SIP call before the RTP stream of the previous call begins sending (which causes the DUT’s to establish the NAT port mapping).
Needless to say, sometimes faulty or abnormal behavior would be missed with just straight protocol testing, and these testvars can help you get a little more nuanced in your test scenarios. Try these out for yourself and see what you can find!
