Hi Tomasz,
The issue is that, because you are not registering users, the SUT
doesn't know to which port to forward the call. And since each user
listens on a different port, the UAS user does not receive the call.
We have had this case already (testing app servers like you are) and
have a solution for it. We should have included it in the SVN snapshot
but because we had no time to clean up the implementation, we never got
to do that.
Anyway, I will describe here the solution, with its little dirty
aspect...
The solution consists in passing the UAS user port to the UAC scenario
as part of the user reservation procedure, in addition to the user name
and domain so that the UAC can target <user>@<domain/IP>:<port> instead
of relying on a registrar that's not there.
At the UAS side, you need to return the port that the user is listening
on. There is no port parameter in the res_user message but, as a
workaround, you can pass it in the "call_id" parameter:
<sendRmt type="res_user" crlf="true">
<param name="user_name" value="[field0]"/>
<param name="user_domain" value="[field1]"/>
<param name="call_id" value="[local_port]"/>
</sendRmt>
At the UAC side, when the user reservation is confirmed by UAS, you need
to store the port of the UAS side user in a variable (var 3) and use it
in subsequent INVITE and other messages ([$3]):
<recvRmt type="res_user" timeout="8000">
<!-- When we get the response from the partner SIPp, we store the
remote user URI in call -->
<!-- variables for later usage in the scenario (as 'To' user).
-->
<action>
<store_param param="user_name" assign_to="1" />
<store_param param="user_domain" assign_to="2" />
<store_param param="call_id" assign_to="3" />
<move_user pool="0"/>
</action>
</recvRmt>
...
<send retrans="500" start_rtd="1,2"> <!-- Start timer 1 and 2 -->
<![CDATA[
INVITE sip:[EMAIL PROTECTED]:[$3];transport=[transport] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:[EMAIL PROTECTED]:[local_port]>;tag=[call_number]
To: sut <sip:[EMAIL PROTECTED]:[$3]>
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:[EMAIL PROTECTED]:[local_port];transport=[transport]
Max-Forwards: 79
Content-Length: 0
]]>
</send>
Let us know if this works for you.
Regards,
-David
-----Original Message-----
From: Tomasz Radziszewski [mailto:[EMAIL PROTECTED]
Sent: jeudi 24 avril 2008 15:38
To: Verbeiren, David
Cc: [email protected]
Subject: Re: [Sipp-users] IMS bench SIPp: uas ignores message (user
matching problem?)
Hi David,
I am sending an archive, containing the logs, Wireshark capture and ims
bench
configuration.
The system is as follows
172.17.38.205 - manager and sipp
172.17.38.158 - load balancer
172.17.39.74 - SUT1
172.17.39.86 - SUT2
SIPp sends messages to load balancer, which distributes them among SUT1
and
SUT2. The SUTs send messages to SIPp directly, not through load
balancer.
In the Wireshark capture, you can for example look at packets no. 1 and
5.
Packet 1 is from SIPp (uac) to load balancer.
Packet 5 is from SUT1 to SIPp (uas) and is ignored by the SIPp.
Wireshark was running on the SIPp host. Communication from load balancer
to
SUTs is not visible, but hopefully not relevant to debugging the
problem.
Best regards
--
Tomasz Radziszewski
> Hi Tomasz,
>
> Could you turn on more debugging by modifying screen.h and rebuilding
> SIPp. You can turn on debugging for specific functional areas by
> uncommenting the "screendebuginfo" for the corresponding macros (after
> #ifdef FORCE_LOGGING in screen.h). For example:
> #define DBGINFO_SCEN(X) screendebuginfo X
> #define DBGINFO_ACT(X) screendebuginfo X
> #define DBGINFO_CALL(X) screendebuginfo X
> #define DBGINFO_CALL_MSG(X) screendebuginfo X
> #define DBGINFO_SOCK(X) screendebuginfo X
> #define DBGINFO_REM(X) screendebuginfo X
> #define DBGINFO_RMT(X) screendebuginfo X
> #define DBGINFO_SIPP(X) screendebuginfo X
>
> Or just all of them since you are currently debugging your call flow
> without putting any load on the system.
>
> You will then get a lot more output in the sipp log files. Could you
> send this log file? Also, a network capture could help.
>
> Regards,
> -David
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tomasz
> Radziszewski
> Sent: mercredi 23 avril 2008 13:16
> To: [email protected]
> Subject: [Sipp-users] IMS bench SIPp: uas ignores message (user
> matchingproblem?)
>
> Hi
>
> I am using IMS bench SIPp. My SUT is close to a usual B2BUA.
>
> I've taken the config generated by ims_bench.pl and did the following
> changes:
> - removed registration phase (my SUT doesn't support registration)
> - removed all registration and messaging scenarios, leaving only uac
and
> uas
> - removed route from UAC/UAS scenarios (it was taken from REGISTER
> response,
> so I don't have it and I don't need it for my simple system)
> - in the users_inf file, changed initial pool from 0 to 2 for all
users
> (to
> consider them "registered" without runnign the registration scenario).
>
> When the UAC sipp sends INVITE, it goes through my SUT and the SUT
sends
> it to
> the UAS. However, the UAS doesn't see the INVITE (but it sees recvRMT
-
> screen dump below).
>
> I've seen on Wireshark that the INVITEs are really sent to the UAS
sipp
> address/port. What can be the cause of ignoring them? Could it be
> related to
> the user reservation mechanism? The "From" header after going though
my
> SUT
> is the same as original "From", except the tag. Can the tag be
problem?
>
> SIPp screen dump
>
> Messages Retrans Timeout
> Unexpected-Msg
> 0 [ RECVRMT ] 46
> 1 [ SENDRMT ] 46
>
> 2 ----------> INVITE B5,2 0 0 0
> 3 <---------- 180 0 0
> 4 [Poi(5000ms)] Pause 0 0
> ..
>
> Original INVITE (SDP truncated):
>
> INVITE sip:[EMAIL PROTECTED] SIP/2.0
> Via: SIP/2.0/UDP 172.17.38.205:24272;branch=z9hG4bK-1302-371-4
> Max-Forwards: 70
> From: "subs017272" <sip:[EMAIL PROTECTED]>;tag=1302SIPpTag00371
> To: "subs011163" <sip:[EMAIL PROTECTED]>
> Call-ID: [EMAIL PROTECTED]
> CSeq: 1 INVITE
> Contact: sip:[EMAIL PROTECTED]:24272
> Content-Type: application/sdp
> Content-Length: 137
>
> v=0
> ..
>
> Invite forwarded by SUT:
>
> INVITE sip:[EMAIL PROTECTED] SIP/2.0
> Via: SIP/2.0/UDP
> 172.17.38.128:5062;branch=z9hG4bKMvorkJ10-N4QWLfYWkbuoA;rport
> Max-Forwards: 70
> From: "subs017272" <sip:[EMAIL PROTECTED]>;tag=UPRp9A
> To: "subs011163" <sip:[EMAIL PROTECTED]>
> Call-ID: L_Zba1vGrsqGV9RkZbjiEg
> CSeq: 1 INVITE
> Contact: <sip:172.17.38.128:5062;transport=udp>
> Content-Type: application/sdp
> Content-Length: 137
> X-Original-CallID: [EMAIL PROTECTED]
>
> v=0
> ..
>
> Best regards
---------------------------------------------------------------------
Intel Corporation NV/SA
Rond point Schuman 6, B-1040 Brussels
RPM (Bruxelles) 0415.497.718.
Citibank, Brussels, account 570/1031255/09
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Sipp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sipp-users
