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
