Re: [Sipp-users] RE: The agent never process the INVITE message that it (does) received, because

[Raka <wir...@ya...>]

Hi,

Thanks for the replies. I solved this problem (I
removed the requirement for the agent UA to REGISTER
to Asterisk). Well, it's not a solution, actually,
only a workaround my situation. Here's the explanation
I wrote to my team:

-----
There are at least 2 possible modes of execution of
SIPp: server mode and client mode. In the testing
scenario for our software, specifically for the case
of inbound call, we would like the SIPp instance that
simulates the UA (user agent) of a contact center
agent to be running in server mode. On the other hand,
the SIPp instance that simulates the UA of a customer
who makes a call to the contact center should be
running in client mode.

When running in server mode, SIPp maintains map of
active calls that it is handling. Each call in the map
is identified by its CallID. Whenever SIPp receives
SIP message whose CallID doesn't have corresponding
entry in the map, it will create a new instance of
call (in the memory) and store that call in the map
(see sipp.cpp line 2060). Sidenote: the version of
SIPp that I use is 1.1 (unstable) snapshot 20060120.

When running in client mode, that message will be
considered as outofcall message, and will be treated
as such (discarded); see sipp.cpp line 2091. 

Unfortunately, we can't set the mode through somekind
of execution option(s)..., SIPp will figure it out by
itself, in an “interesting” way. It will set its mode
of execution to server mode only if the first
instruction in the scenario file is a <recv> (see
scenario.cpp line scenario.cpp line 521). Previously
we had a problem related to this, because in our old
inbound_agent.xml the first message is a <send> that
sends a SIP message for registering the location of
the UA of the agent to the Asterisk (such that
Asterisk knows where to forward the SIP message to
whenever it receives an incoming INVITE from the UA of
the customer).

We need to adapt to this situation by removing the
need for the UA of the agent to register itself, so we
can comment out all the instructions that precedes the
<recv> for INVITE in the inbound_agent.xml. This can
be achieved by modifying /etc/asterisk/sip.conf.
Previously, for each agent in that file, we set the
host property to dynamic. Now we need to switch to
static mode, by specifying an IP address to that
property. Additionaly, we need to specify the port
(the UA of the agent is expected to listen for SIP
messages on that port). In our case, we specify that
all agent UAs will be listening to the same (UDP)
port: 6001. Correspondingly, we need to set the
transport mode of the instance of SIPp for the agent's
UA to UDP Mono Socket (in inbound_agent.sh we now have
the u1 6001 switch).

Best regards,
Raka -- http://www.jroller.com/page/donraka

--- Mat Mat <pez...@ho...> wrote:

> Hi Cokorda,
> 
> I didn't look your code very closely but I have 1
> suggestions:
> Personnaly, I usually put the registering part and
> the calls in 2 different 
> scenarios (as there is no direct link between them).
> I first run the 
> registering scenario and when it's done I start
> stressing my proxy with the 
> call scenario. It might be a temporary workaround
> untill you find if the 
> problem comes from SIPp itself or from your code.
> 
> Mathieu

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com