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<shane.tur...@newpace.ca
>> <mailto:shane.tur...@newpace.ca>>  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   shane.tur...@newpace.ca<mailto:shane.tur...@newpace.ca>
>>      aim/msn         shane.tur...@newpace.ca
>>      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
>>      Sipp-users@lists.sourceforge.net
>>      <mailto:Sipp-users@lists.sourceforge.net>
>>      https://lists.sourceforge.net/lists/listinfo/sipp-users
>>
>>
>
> --
> --
>                               Shane Turner
>       Senior Software Developer
> phone         +1 (902) 406–8375 x1008
> email         shane.tur...@newpace.ca<mailto:shane.tur...@newpace.ca>
> aim<aim:GoIm?screenname=shane.tur...@newpace.ca>/msn
> <msnim:chat?contact=shane.tur...@newpace.ca>          shane.tur...@newpace.ca
> <aim:GoIm?screenname=shane.tur...@newpace.ca>
> 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
> Sipp-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sipp-users

--
--
                                Shane Turner
        Senior Software Developer
phone   +1 (902) 406–8375 x1008
email   shane.tur...@newpace.ca <mailto:shane.tur...@newpace.ca>
aim <aim:GoIm?screenname=shane.tur...@newpace.ca>/msn
<msnim:chat?contact=shane.tur...@newpace.ca>    shane.tur...@newpace.ca
<aim:GoIm?screenname=shane.tur...@newpace.ca>
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
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Reply via email to