Call flow validations with unknown number of message transactions

[Barry]

Hello,

I am writing sipr tests to verify a call flow where I might not know
how many messages of a type I will get, I just want to validate that I
got them. For example, suppose I have a long running call where I
receive OPTIONS messages as keep-alive statements. I don't know or
really care exactly how many of these I will get, I just want to
respond to them with 200 and verify that at least 1 was received.

I see that in the call flow validation language, I could say
"< OPTIONS {1,}, > 200 {1,}"
to assert that I received at least 1 OPTIONS message and sent at least
1 200 response. However, if I have several OPTIONS transactions (not
retransmissions), what I really want is to be able to group messages
together and put bounds on the entire transaction with something like
"(< OPTIONS, > 200) {1,}"

Is there any way to do something like this in sipr?

Thanks in advance,
Barry

[Nasir Khan]

Let me try to understand, so do you want an infinitely running test? Or do you still have some kind of a limit on time or count maybe when you miss OPTIONS after a certain time you will come out of a test raising a failure?

Thanks
Nasir

--

You received this message because you are subscribed to the Google Groups "Sipper" group.
To post to this group, send email to sip...@googlegroups.com.
To unsubscribe from this group, send email to sipper+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sipper?hl=en.

[Barry]

Thanks for getting back to me so soon!

For my example assume that the test is time bounded, so the script
places a call and stays up for some period of time then sends a BYE.
While the call is up, the other side sends periodic OPTIONS messages
on it's own timer schedule to see if the call is still alive. What I
want is for my test to be able to receive the OPTIONS messages and
respond to them, and validate that OPTIONS messages were received and
responded to, but not fail if it receives and responds to 11 messages
instead of 10.

The only way I know how to do this today is with "< OPTIONS, > 200, <
OPTIONS, > 200, ..." and hope the number of OPTIONS that show up is
the same as what I add to the expected_flow.

[Nasir Khan]

Barry,

Sorry for the delay a lot of things going on in parallel :-)

There are at least a couple of ways of doing it. The simplest but cumbersome way is to use what you described below with one change.
Have "< OPTIONS {,} > 200 {,} , < OPTIONS {,} > 200 {,} ..."

You just need to have a large number of these OPTIONS/200 strings in the validation string, it will not matter if you have more than what you receive on the wireas the {,} indicates at least 0 and at
most infinity.
I know that this is a quick and dirty way of doing it.

However here is a much powerful and elegant way.

Look at the script below

#---START OF SNIPPET ---

require 'driven_sip_test_case'

class TestCustomRecord < DrivenSipTestCase

def setup
super
str = <<-EOF

require 'sip_test_driver_controller'

module SipInline
class UasCrController < SIP::SipTestDriverController

transaction_usage :use_transactions=>true
emit_console true

def on_invite(session)
session.make_new_offer
session.respond_with(200)
logd("Received INVITE sent a 200 from "+name)
end

def on_ack(session)
session.request_with("options")
end

def on_success_res_for_bye(session)
session.invalidate(true)
session.flow_completed_for("TestCustomRecord")
end

def on_success_res_for_options(session)
if rand(10)%2 == 0
session.request_with("options")
else
session.request_with("bye")
end
end

def order
0
end

end

class UacCrController < SIP::SipTestDriverController

transaction_usage :use_transactions=>true

def start
u = create_udp_session(SipperConfigurator[:LocalSipperIP],
SipperConfigurator[:LocalTestPort])
r = u.create_initial_request("invite", "sip:na...@sipper.com",
:p_session_record=>"msg-info")
u.offer_answer.make_new_offer
u.send(r)
logd("Sent a new INVITE from "+name)
end


def on_success_res(session)
session.request_with('ACK')
end

def on_options(session)
session.respond_with(200)
end

def on_bye(session)
session.respond_with(200)
session.invalidate(true)
end

end
end
EOF
define_controller_from(str)
set_controller("SipInline::UacCrController")
end


def test_smoke_controllers

start_controller
recording = get_in_recording.get_info_only_recording
assert_equal("< INVITE", recording[0])
assert_equal("> OPTIONS", recording[-4])
assert_equal("< 200", recording[-3])
assert_equal("> BYE", recording[-2])
assert_equal("< 200", recording[-1])
end

end

#----END OF SNIPPET

There are a few things to note here.

1. We are sending a random number of OPTIONS before we send a BYE as you can see by turning on the emit_console option to print messages to console (your test may be different as you need a time bound thins, but this is a simulation).

2. We are not using standard validator here but accessing the recording using
recording = get_in_recording.get_info_only_recording
You may read the manual for more details but essentially this retrieves the recorded messages with their directions in the array.

3. Finally we are using Ruby negative array access to compare the recording from reverse starting from BYE and only one OPTION. It doesn't matter how many OPTIONS we get.

Hope this helps.

Thanks
Nasir

-----Original Message-----
From: sip...@googlegroups.com [mailto:sip...@googlegroups.com] On Behalf Of Barry
Sent: Thursday, December 10, 2009 1:43 PM
To: Sipper

[Barry Fleming]

Nasir,

This is an excellent idea! Thanks so much for all the detail.

Barry