I made some progress.
After looking at the code it looks like the out of call scenarios are
only used if the -aa flag (auto answer) is turned on. Also, the version
of SIPp that is included with Ubuntu Lucid Lynx 10.04 is 3.1-r590 which
has a bug where using the -aa flag triggers a core dump. According to
the SIPp version control log subversion revision r593 addresses that
issue:
r593 | sajeeshs | 2010-10-26 03:49:11 -0300 (Tue, 26 Oct 2010) | 1 line
FIX: Fix for Segmentation Fault - ID: 2896585: -aa option causes
segfault from Endre Szalai
I'm now using the trunk version (r600) and I'm able to use a custom
out-of-call scenario.
Shane
On April-11-12 10:25:56 AM, Shane Turner wrote:
> Thanks for the info, Patrick.
>
> I was afraid that's what I was going to have to do. I was really hoping
> to not have to maintain my own fork of SIPp, but that doesn't seem like
> it's going to be possible.
>
> It seems that SIPp isn't being very actively maintained at the moment.
> There have only been commits in May, June, and October of 2011. I also
> see that almost all of the developers are working on Seagull.
>
> Shane Turner
>
> On April-10-12 9:56:14 PM, Patrick Wakano wrote:
>> /"I also can't find any evidence in the mailing list of anyone getting
>> out-of-call scenarios to work. I've seen a couple of messages about
>> people modifying -aa (auto answer) to work on messages other than the
>> documented INFO, UPDATE and NOTIFY."/
>> Unfortunatelly, I'm havent the used the -oocsn option either, but the
>> -aa option do work, so if you want to solve your problem just add a
>> MESSAGE case in the function checkAutomaticResponseMode() of the
>> call.cpp file.
>> I had to do the same for the OPTIONS, which could not be answered too
>> and was mandatory for me....
>> After that you only need to add the -aa option to your command line!
>>
>> Here is the function I mentioned:
>> call::T_AutoMode call::checkAutomaticResponseMode(char * P_recv) {
>> if (strcmp(P_recv, "BYE")==0) {
>> return E_AM_UNEXP_BYE;
>> } else if (strcmp(P_recv, "CANCEL") == 0) {
>> return E_AM_UNEXP_CANCEL;
>> } else if (strcmp(P_recv, "PING") == 0) { ==> The OPTIONS I've
>> added here! Honestly I got stunned when I saw a test for PING instead
>> of OPTIONS....
>> return E_AM_PING;
>> } else if (((strcmp(P_recv, "INFO") == 0) || (strcmp(P_recv,
>> "NOTIFY") == 0) || (strcmp(P_recv, "UPDATE") == 0)) ==> Add your case
>> here!
>> && (auto_answer == true)){
>> return E_AM_AA;
>> } else {
>> return E_AM_DEFAULT;
>> }
>> }
>>
>>
>>
>>
>> On Tue, Apr 10, 2012 at 5:03 PM, Shane Turner<[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Summary: Has anyone actually gotten out-of-call scenarios to work?
>>
>> Detail:
>>
>> I've been trying to get some scenarios working with SIPp and been
>> stumbling along dealing with issues such as setting up a separate
>> scenario for registration from the scenario that receives an
>> invite request.
>>
>> The latest issue is that I need to have a UAC scenario be able to
>> receive a MESSAGE request and simply respond with a 200 OK.
>>
>> Currently the request is dropped: "Discarding message which can't
>> be mapped to a known SIPp call:"
>>
>> From reading the documentation, there's a concept of out-of-call
>> scenarios, and that a SIPp UAC will reply with a 200 OK response
>> for any out-of-call request.
>>
>> http://sipp.sourceforge.net/doc/reference.html#UAC+Out-of-call+Messages
>>
>> It certainly doesn't seem to be the default behaviour in practice.
>>
>> If I specify -oocsn ooc_default, SIPp doesn't complain, but I get
>> the same behaviour as when I don't specify it.
>>
>> I also can't find any evidence in the mailing list of anyone
>> getting out-of-call scenarios to work. I've seen a couple of
>> messages about people modifying -aa (auto answer) to work on
>> messages other than the documented INFO, UPDATE and NOTIFY.
>>
>> --
>>
>>
>>
>> Shane Turner
>>
>> Senior Software Developer
>> phone +1 (902) 406–8375 x1008
>> <tel:%2B1%C2%A0%28902%29%C2%A0406%E2%80%938375%C2%A0%C2%A0x1008>
>> email [email protected]<mailto:[email protected]>
>> aim/msn [email protected]
>> skype saturnjct
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev
>> _______________________________________________
>> Sipp-users mailing list
>> [email protected]
>> <mailto:[email protected]>
>> https://lists.sourceforge.net/lists/listinfo/sipp-users
>>
>>
>
> --
> --
> Shane Turner
> Senior Software Developer
> phone +1 (902) 406–8375 x1008
> email [email protected]<mailto:[email protected]>
> aim<aim:[email protected]>/msn
> <msnim:[email protected]> [email protected]
> <aim:[email protected]>
> skype saturnjct<skype:saturnjct>
>
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Sipp-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sipp-users
--
--
Shane Turner
Senior Software Developer
phone +1 (902) 406–8375 x1008
email [email protected] <mailto:[email protected]>
aim <aim:[email protected]>/msn
<msnim:[email protected]> [email protected]
<aim:[email protected]>
skype saturnjct <skype:saturnjct>
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Sipp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sipp-users
