*"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>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 email
> shane.tur...@newpace.ca <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
> https://lists.sourceforge.net/lists/listinfo/sipp-users
>
>
------------------------------------------------------------------------------
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
