Thank you, David This has solved the problem
/Tom > 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 ------------------------------------------------------------------------- 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
