Yes - I had forgotten about ooc.
-oocsf, -oocsn etc work fine so long as you only want one simultaneous
incoming call, but do not appear to support multiple simultaneous instances of
the ooc scenario.
e.g. the following will cause havoc if you try to handle it with -ooc, as your
script will be waiting for 'BYE' and will instead be passed the INVITE for the
new call.
-> INVITE (call1)
<- Trying
<- Ok
-> INVITE (call2)
...
-> BYE (call1)
...
-> BYE (call2)
The same problem occurs if an OPTIONS is received mid-call when using -ooc,
forcing you to put OPTIONS handling code in your ooc xml script at all stages.
I was tempted to modify this behaviour for the ooc scenarios (register a new
-ooc scenario for each new incoming call_id, rather than the current behaviour
where a single ooc scenario instance handles all unknown call_ids) but I was
afraid that might break other people's scripts if the changes were ever
integrated into SIPP - hence I added new parameters instead.
Using my patch, in the above example one instance of the rx scenario is
created when the 1st invite is received, and handles only incoming messages
with call_id's that match the 1st INVITE. When the 2nd INVITE is received, a
new instance of the rx scenario is created and starts handling the seconds call
from the beginning. Liekwsie an OPTIONS would create a new instanc eof the
scenario, meaning you only need to check for INVITE vs OPTIONS at the first
step of your rx scenario script, not throughout.
Matt
________________________________________
From: Steve Edwards [steve.m.edwa...@ntlworld.com]
Sent: Wednesday, 7 March 2012 7:58 a.m.
To: Matthew Briggs
Cc: sipp-users@lists.sourceforge.net
Subject: Re: [Sipp-users] Registration for a server
Hi Matt
Thank you for your very considered reply.
It's not in the user guide, but -oocsf and -oocsn allow you to load an Out
Of Call scenario XML file. So I am having some success in running a
registration as a client, and either -oocsn uas which loads the built-in uas
scenario, or my own similar server script -oocsn uas.xml.
This does seem to be something of a weakness in SIPp though, and threatens
to limit its usefulness. :-(
I will have a look 5645.
Thank you again for taking the time and trouble to reply, I do appreciate
it, and I must admit I hadn't thought of using two instances as you
describe.
Kind regards,
Steve
----- Original Message -----
From: "Matthew Briggs" <matthew.bri...@telecom.co.nz>
To: "Steve Edwards" <steve.m.edwa...@ntlworld.com>;
<sipp-users@lists.sourceforge.net>
Sent: Tuesday, March 06, 2012 6:27 PM
Subject: RE: [Sipp-users] Registration for a server
_______________________________________
From: Steve Edwards [steve.m.edwa...@ntlworld.com]
Sent: Tuesday, 6 March 2012 11:30 p.m.
To: sipp-users@lists.sourceforge.net
Subject: [Sipp-users] Registration for a server
Hi
Sorry if this is a dumb question, but I want to run SIPp with a scenario
that registers (including authentication), and then behaves as a server to
receive incoming calls.
REGISTER -------->
<--------- 401 auth="true"
REGISTER -------->
<---------- 200
<---------- INVITE
etc
It registers OK, but then when it receives an INVITE, it discards this an
unexpected message because the tags don't match those used in the
registration.
Any help would be much appreciated.
Kind regards,
Steve Edwards
===
Steve,
I had the same problem. Scripts are either UAC or UAS. But when there are
registrations ot handle you need a combination of the two: one that assigns
it's own call_id (UAC) to register, and one that receives the call_id from
the far end with the initiating message to terminate an incoming call.
My interim solution was to wrap the whole thing in a shell script:
#!/bin/bash
sipp 1.2.3.4:5060 -sf register.xml -inf mynumber.csv -l 1 - m 1 -p 5060
sipp 1.2.3.4:5060 -sf called_party.xml -inf mynumber.csv -l 1 -m 1 -p 5060
to run the two scripts in series.
This is fine except for 2 scenarios:
1) if you have a short registration timeout
In my case I had to reregister every minute, so this only gave me 1 minute
to run my called_party script before the registration expired
2) If you use SIP over TCP
I also had to test SIP over TCP support against a broadsoft platform.
Broadsoft deregister the endpoint as soon as they receive the FIN for the
TCP session used to register - so the above solution does not work since the
TCP session is torn down as soon as the register script finishes.
3) If you / the SBC / the proxy need to send OPTIONS pings as keepalives.
You can use -aa to answer these, but sending them is difficult in the above
scenario
There are scripting acrobatics that can fudge the 1st / 3rd scenarios
above - sticking reregisters and options through your called_party script to
keep registration alive, for example.
However, the better solution seemed to be to modify SIPP to allow two
scripts/scenarios to run concurrently - one handling registration and one
terminating calls. Which is what I did in the end. See post: 5645 for the
patches and for details. (Re: [Sipp-users] New feature / solution: Enabling
a mixture of server-mode and client mode operation simultaneously)
Matt=
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
