Hi Yasir,
> I removed the first line of the dial plan (exten =>
8001,1,Dial(8001,20)) and tried the SIPp call, and then Asterisk replied
with 404 Not Found immediately as a reply to the INVITE.
This seems to be the first mistake because AFAIK there must always be a
rule No. 1 in the Asterisk dialplan for each "exten => x". But the good
news is that you may remove all the other rules instead.
> I'm running my UAS on the same machine as the Asterisk and I see that
Asterisk doesn't send any INVITE or other SIP messages towards the UAS.
If you're running both on the same machine, each of them must use a
different local port or at least on a different IP address (although I
think Asterisk listens on all IPs unless you specially tell it not to do
so). But let's assume you did so. Then the Asterisk can only send the
INVITE to the "UAS" scenario if
* you put back your original rule "1" (exten =>
8001,1,Dial(SIP/8001,20)) *and*
* you either configure the UAS scenario as a peer in sip.conf or leave
the sip.conf unchanged but let the "UAS" (actually,
called-party-simulating) scenario register first. Asterisk needs the
Contact from the REGISTER to learn the destination socket to which
it should send INVITEs. If you set 8001 as a peer, the destination
socket is in the configuration so no REGISTER is necessary.
What is also important - if you want to assess Asterisk performance,
running the called-side SIPp scenario on the same hardware will heavily
affect the result, so running the calling and called side SIPp scenarios
on the same machine might be a better option if you are short of
hardware (but for a real performance test, the summary power of the
hardware running SIPp should be at least 10 times higher than that of
the one running Asterisk.
> I have altered to the branchc.xml to have the registration messages
and it did work, however, it's the same behaviour where Asterisk replies
immediately without any SIP messages sent to the UAS.
The branchc.xml does not do what you need as it *sends* an INVITE
instead of receiving it, and even worse, I think it is wrong in
principle because it uses the same Call-ID for the REGISTER and for the
INVITE which is confusing for any normal SIP peer.
What you need is that your called-side scenario would act as UAC when
sending the REGISTER but also act as an UAS to accept an incoming
INVITE. To do that, you need a pair of interworking scenarios. So I'd
recommend you to start from the 8001 as a trunk (where a plain UAS
scenario is OK) and to revert to the 8001 as registering CPE in the next
step.
The pair of called side scenarios would look the following way:
Main:
<scenario ...>
<recv request="INVITE" optional="true" next="process_INVITE"/>
<recvCmd/>
<label id="send_REGISTER"/>
<send>
<![CDATA[
REGISTER sip:...
]]>
</send>
<recv response="200"/>
<pause milliseconds="300" next="send_REGISTER"/>
<label id="process_INVITE"/>
<send>
<![CDATA[
SIP/2.0 100 Trying...
]]>
</send>
...
</scenario>
Auxiliary (timer):
<scenario ... >
<send>
<![CDATA[
BOGUS sip:...
]]>
</send>
<sendCmd>
<![CDATA[
Call-ID: [call_id]
]]>
</sendCmd>
<pause milliseconds="1800000"/> <!-- for test duration of 30 min. -->
</scenario>
Both of them must be run with a "-3pcc localhost:9001" command line
option, the master one first. The timer one must be launched with -m 1
and with some blackhole as destination socket (we don't want any
response to the BOGUS request which must be there so that SIPp would let
this scenario generate Call-IDs).
Only after both these scenarios are running, you may start the
calling-side one.
If Asterisk can accept that the socket in REGISTER's Contact differs
from the source socket of the REGISTER, you could run an UAC scenario
which would only REGISTER and an UAS scenario which would only respond
INVITEs and the two wouldn't need to talk to each other, but I am not
sure whether Asterisk handles that - most SIP services don't, so the
3pcc way is universal although slightly more complex.
Pavel
------------------------------------------------------------------------------
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
