Register + wait for call

[davidcsi]

Hello,

I started testing voip_patrol, and I would like to:

• Register
• Wait for call
• Answer
• Start Media
• Put the call on hold with sendonly (INVITE)
• Receive 200 OK with recvonly
• Wait for a few seconds
• Get the call out of hold withOUT SDP (INVITE without SDP)
• Will receive a 200 OK with SDP
• ACK with SDP
• restart media and check it we are receiving media.

Is this possible with voip_patrol? I've tried with SIPp but i seem to not be able to.

Many thanks!

[jchavanton]

Hi David, hope you are well :)

• All of theses are supported :

register, wait for call, answer, wait a few seconds, check if we are receiving media

• late_start (INVITE without SDP) is already exposed in a setting :

late_start | bool | if "true" no SDP will be included in the INVITE and will result in a late offer in 200 OK/ACK

• Stopping the media is not currently supported, but since switching codec is, I am guessing a very small modification would probably suffice.

<config>
    <action>
        <action type="codec" disable="all"/>
        <action type="codec" enable="pcma" priority="250"/>
        <action type="codec" enable="pcmu" priority="248"/>

        <!-- call that will last 12 seconds and re-invite every 2 seconds -->
        <action type="call"
            wait_until="CONFIRMED"
            expected_cause_code="200"
            caller="16364990640@125.22.198.115"
            callee="12349099229@sip.mydomain.com"
            max_duration="55" hangup="12"
            username="65454659288" password="adaadzWidD7T"
            realm="sip.mydomain.com"
            re_invite_interval="2"
            rtp_stats="true"
        />
        <action type="wait"/> <!-- this will wait until the call is confirmed -->
        <action type="codec" disable="pcma"/>
        <!-- re-invite will now use pcmu forcing a new session -->
        <action type="wait" ms="3000"/> <!-- this will wait 3 seconds -->
        <action type="codec" enable="pcma" priority="250"/>
        <!-- re-invite will now use pcma forcing a new session -->

        <action type="wait" complete="true"> <!-- Wait until the calls are disconnected -->
    <actions/>
<config/>

[jchavanton]

if it does what you want with re-invite (new codec) instead of receive only, I can help you with adding support for recvonly.

[davidcsi]

Hello Julien!

That was quick response, I appreciate it!
I started testing it and, on register, I'm getting a 401 so it's failing. I tried setting the expected code to 401 and then re-doing the registration, but i'm probably going it wrong:

<config>
  <actions>
	<!-- note: proxy param to send to a proxy -->
	<action type="register" label="register target.com"
            transport="udp"
            account="default"
            username="davidv48969"
            password=".."
            realm="domain.com"
            registrar="domain.com"
            expected_cause_code="401"
		/>
        <action type="register" label="register target.com"
            transport="udp"
            account="default"
            username="davidv48969"
            password="..."
            realm="domain.com"
            registrar="domain.com"
            expected_cause_code="200"
                />
	<action type="wait" ms="60000"/>
	<action type="accept"
            account="default"
            hangup="5"
            code="200" reason="OK"
    >
  </actions>
</config>

is this the right wat to go about it?

Thanks again

[jchavanton]

I realize It is not clearly specified, but voip_patrol will create a detailed log file with all the pjsip decision etc.
default one is :

results.json.pjsua

-o,--output <result.json>         json result file name

run it once more and see what it is saying when it receives the challenge.
but no, you do not need the 401 version of the register.

---

Also I would replace

type="wait" ms="60000"

with

type="wait" complete="true"

Else you have to put the accept before.
Also you have to put a wait after the accept.

[jchavanton]

If the password is wrong for example ?

[davidcsi]

I had the account wrong :)

[davidcsi]

Hello yet again!

it's getting better!

I have this now:

<config>
  <actions>
	<!-- note: proxy param to send to a proxy -->
	<action type="register" label="register target.com"
            transport="udp"
            account="davidv48969"
            username="davidv48969"
            password="YrTd52gj"
            realm="sip.telnyx.com"
            registrar="sip.telnyx.com"
            expected_cause_code="401"
	/>

	<action type="accept"
            account="default"
            hangup="5"
            code="200" reason="OK"
		>

	<action type="wait" ms="20000"/>
	<action type="wait" complete="true"/>

  </actions>
</config>

Register goes ok, but then it just exits.

[22:40:20.743][INFO] [Register] code:200
[22:40:20.743][INFO] update_result
[22:40:20.743][INFO] update_result[0x562ad14707a0]  completing

[22:40:20.744][INFO] update_result[25-09-2020 22:40:20]{"1": {"label": "register target.com", "start": "25-09-2020 22:40:20", "end": "25-09-2020 22:40:20", "action": "register", "from": "davidv48969", "to": "davidv48969", "result": "FAIL", "expected_cause_code": 401, "cause_code": 200, "reason": "OK", "callid": "", "transport": "UDP", "peer_socket": "", "duration": 0, "expected_duration": 0, "max_duration": 0, "hangup_duration": 0, "call_info":{"local_uri": "", "remote_uri": "", "local_contact": "", "remote_contact": "" }}}
[22:40:20.744][INFO]  [register]

[22:40:20.831][INFO] do_wait: completed

[jchavanton]

It would wait 20 seconds an exit

else you can do, wait forever:

<action type="wait" ms="-1"/>

or wait until you receive a certain amount of calls

<action type="accept" call_count="x" ... />
<action type="wait" complete="true"/>

or wait 5 seconds or one call

<action type="accept" call_count="1" ... />
<action type="wait" ms="5000"/>

[jchavanton]

I just tested your scenario it worked as expected.

[16:20:09.828][INFO] set_param param name:ms val:20000
[16:20:09.828][INFO] do_wait duration_ms:20000 complete all tests:0
[16:20:09.828][INFO] do_wait: action[wait] active account tests or call tests in run_wait[1] <<<<

[16:20:09.867][INFO] [Register] code:200
[16:20:09.867][INFO] update_result
[16:20:09.867][INFO] update_result[0x55fed1e291c0]  completing
....

[16:20:30.258][INFO] do_wait: completed
[16:20:30.258][INFO] process ===> action/wait

you can see the wait 20 seconds and then the wait complete is just returning since there is no tests in progress
are you expecting something else ?

[jchavanton]

But you have to add the missing / in your accept action, I guess the parser should be more strict ...

[davidcsi]

Now it's doing it! good catch with that "/"!
I will continue on trying to put the call on hold.

[davidcsi]

So, once the call is accepted, how do i set how long to wait before going to the next action?
i.e.:

• action: accept
• wait 5 seconds with the call connected
• action: send invite with sendonly?

[jchavanton]

look at the wait command, it will stop and not execute the next action unless you use wait until

[davidcsi]

Sorry, I'm still not sure how to reInvite without SDP.
I know you said late_start will send a call without initial SDP, but how to reinvite on the existing call with late_start?

[jchavanton]

Currently you can not re-invite with late start, in your initial request you did not mention that the original invite would not be late start and that the re-invite would or I missed it

[jchavanton]

I see I missed it, not possible currently, both of the have to be late-start true/false

Put the call on hold with sendonly (INVITE)
...
Get the call out of hold withOUT SDP (INVITE without SDP)

[davidcsi]

Well, i just tried adding late_start on the accept, and it replies to the incoming invite with 200 OK + SDP. Would reinviting on that call send out the INVITE without SDP? If so, how do i accomplish that?

[jchavanton]

late_start on the accept action, should simply be ignored.

When doing re-invite, the original action params are used, this is why this can not be done currently.

When adding sendonly=true/false, it could be possible to also modify late-start=true/false
A new action like codec, would provide global behavioral change, per call would require more modifications.

Not sure when I will find the time / opportunity to do that but it seems it could be useful since one of the objective of voip_patrol is definitely to test complicated scenarios.