Skip to content

Test Conditions

On each test, it's possible to add various conditions to define if and how a test will succeed or fail. For example, did the callee received the correct CLI, or did the call meet specific SIP criteria by having a particular header, or was the MOS score good enough?

The following types of conditions are supported:

  • Result conditions caller/callee
  • CLI received on called party side
  • MOS score caller/callee
  • Transcription conditions caller/callee
  • Transcription confidence caller/callee
  • RTP stats caller/callee
  • SIP Conditions caller/callee
  • AI-driven Intent checks caller
  • Web request conditions

Result conditions caller/callee

Any event in the platform will generate a state, such as REGISTER_OK, CALL_INCOMING, CALL_ESTABLISHED, etc. and with the result conditions the test will check if it has or not the conditions in order to verify the success of the test.

Additionally it's possible to check whether the states must appear in a given order (strict order) or can appear in any order. When strict order is selected, more states could still appear between your given states. Either way, you do not have to define all states here, only those you want to make sure are (or not) present.

CLI received on called party side

This condition will check whether the called party received the right CLI from the caller.

In some scenarios, you would like to verify your system under test is no introducing any change on the caller identification, or instead, you would like to check the normalization of the caller to national/international format for example.

MOS score caller/callee

MOS or mean opinion score is a measure to determine the quality of a call in a 1-5 range, where 1 is lowest perceived quality. Traditionally the MOS score was usually gathered in a subjective quality evaluation test. However, with the ViSQOL algorithm, Sipfront allows to easily and objectively measure the quality of the call audio.

Transcription conditions/confidence caller/callee

Sipfront allows to transcribe the audio content of a call. For example, if you want to check a voicemail content. So, you could determine whether the transcription contains a word or a phrase as part of the audio in a call.

Additionally, the test will provide a transcription confidence value. That means how sure the transcription algorithm is about the textual representation of the audio received.

RTP stats caller/callee

In case a threshold is required for jitter, MOS or any other value related to RTP stats, you can add conditions for the different RTP parameters displayed in the test results page, comparing to average or specific percentile for the overall test.

SIP Conditions caller/callee

If you need to be more specific about the SIP protocol, or even the SDP content, you can use the SIP conditions. These would let you specify a header and check against its value. For example, if the From header, changed the domain part throughout the network.

So, you can select primarily if you want to check against the Request URI or RURI, the SDP body, a particular HEADER (From, To, Contact, ...) or last but not least the whole MESSAGE, in case you want to make sure the message contains a string, but cannot know in advanced where it's going to be.

Multiple INVITES

SIP Condition

Once selected the part where it should appear, you can select if the message was either sent or received by the target agent. For example A sends an INVITE to B. In A we could check the INVITE sent but in B the INVITE received. Also in which order it will appear. For example, when establishing a call, most times you would have a first INVITE and then and authenticated INVITE, so the authentication will appear in the second INVITE, in case you want to check how the authentication looks like. Bear in mind that the conditions will consider all messages of the same type. If you send a call from A to B and another one from A to C, A will send 4 INVITES (including the authentications) and in order to verify the call with C you would need to check the 3rd and 4th INVITES.

To clear things up, in the following image the messages 14 and 17 are the first and second INVITE sent from A, and 30 and 34 are the third and forth INVITEs sent from A. On the other hand the message 19 is the first INVITE received by B and the message 35 is the first one as well received by C.

Multiple INVITES

Multiple INVITES and their identification in SIP conditions

If you want to check the reply of a message for example the 200 OK or any other possible response for a call, you could specify the Reply code instead of the Method. But you need specify what type of method the reply belongs to (INVITE, REGISTER, etc.).

Additionally, you can check the "Filter by Target Host or Proxy" option, which will make sure that in case you have other messages from unwanted sources, they won't be considered. Let's say you want to check the first INVITE received in an agent triggered by the test itself, but sometimes, we can't control if there is traffic coming from other sources messing with the outcome of the test.

AI-driven Intent checks caller

For some tests, an LLM-driven intent check is available, allowing you to check if the intention of the response spoken by the remote party matches the expected intention. This is useful for testing voice applications, such as IVRs or chatbots. An example would be a test where the calling party is trying to order a burger at a pizza hotline, and your intention would be "the order is rejected because no burger is served here". The test will then only pass if - one way or the other without knowing the wording upfront - the hotline rejects the order.

When configuring the intent, try to formulate your prompt as clearly as possible, and provide a few examples of what the remote party might say. The more examples you provide, the more robust the intent check will be.

Web request conditions

In case you want to check the response to a web request, you can use various conditions to check the response code and reason, specific headers and the content of the response. This is useful for testing APIs or web applications.

Web conditions

Example of testing a JSON response using JSONPath

Available fields and check types

  1. Response code: perform string matching, e.g. "is '200'" or "starts with '4'".
  2. Response reason: perform string matching, e.g. "contains 'OK'" or "ends with 'Found'".
  3. Header: perform check if a header exists has a specific value (the header name check is performed case-insensitive), e.g. "'content-type' starts with 'application/json'"
  4. Body: perform string, json, xml or html matching:
    1. String: perform string matching, e.g. "contains 'mystring'" or "is not 'invalid response'".
    2. JSON: perform JSONPath matching, e.g. "'$.elems[0].name' is 'mystring'". Check Chapter 1.5 in the JSONPath RFC9535 for examples and the full specification. You can use the JSONPath Online Evaluator to quickly experiment with various expressions.
    3. XML: perform XPath matching, e.g. "'//elem[@attr='value']' is 'mystring'". Check the XPath specification for more information. You can use the XPath Online Tester to quickly experiment with various expressions.
    4. HTML: perform XPath matching on the HTML body, e.g. "'//div[@class='myclass']' is 'mystring'". The same XPath specification as for XML applies.