Conditions¶
On each test, it's possible to add different conditions to ensure the success or failure for such test. For example, did the callee received the right CLI or did the call meet specific SIP criteria, having a particular header or was the MOS score good enough?
Currently Sipfront supports the following types of conditions:
- 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
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.
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.
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.