On Mon, 13 Oct 2008 at 16:37, Verbeiren, David wrote: > Would you have a wireshark trace of the traffic at the SIPp instances?
I can make one. I will work on that today. > Maybe you System Under Test is not targeting the correct port for the > users selected to run the UAS side scenario? Well, I can show you what I see in the SIPp message log. Maybe you'll spot something in the propagated INVITE that is causing a problem. Here's the send: --------------------------------------------------------------------- UDP message sent: [IP4: 65.175.131.166:7086] INVITE sip:[EMAIL PROTECTED] SIP/2.0^M Via: SIP/2.0/UDP 65.175.131.166:7086;branch=z9hG4bK-23128-81-4^M Max-Forwards: 70^M Route: ^M From: "2999999186" <sip:[EMAIL PROTECTED]>;tag=23128SIPpTag0081^M To: "2999999133" <sip:[EMAIL PROTECTED]>^M Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE^M Contact: sip:[EMAIL PROTECTED]:7086^M Content-Type: application/sdp^M Content-Length: 139^M ^M v=0^M o=user1 53655765 2353687637 IN IP4 65.175.131.166^M s=-^M c=IN IP4 65.175.131.166^M t=0 0^M m=audio 6000 RTP/AVP 0^M a=rtpmap:0 PCMU/8000^M --------------------------------------------------------------------- And here's the receive: --------------------------------------------------------------------- UDP message received: [IP4: 65.175.131.166:7033] INVITE sip:[EMAIL PROTECTED]:7033 SIP/2.0^M Record-Route: <sip:65.175.131.174;ftag=a97c470411e1523a9387ee7fa5154ec6;lr>^M Via: SIP/2.0/UDP 65.175.131.174;branch=z9hG4bK6778.a07f13af41f25f6eb5801a8ec2bc10bd.0^M Via: SIP/2.0/UDP 65.175.131.174:5061;branch=z9hG4bK1f8f8c1b2feb099a9364476e47de98f7;rport=5061^M Max-Forwards: 16^M From: 2999999186 <sip:[EMAIL PROTECTED]>;tag=a97c470411e1523a9387ee7fa5154ec6^M To: <sip:[EMAIL PROTECTED]>^M Call-ID: [EMAIL PROTECTED] CSeq: 200 INVITE^M Contact: Anonymous <sip:65.175.131.174:5061>^M Expires: 300^M User-Agent: Sippy^M cisco-GUID: 3676143674-2529628637-2343043089-1138438784^M h323-conf-id: 3676143674-2529628637-2343043089-1138438784^M Content-disposition: session^M Content-Length: 131^M Content-Type: application/sdp^M ^M v=0^M o=Sippy 146906796 0 IN IP4 65.175.131.174^M s=-^M t=0 0^M m=audio 6000 RTP/AVP 0^M c=IN IP4 65.175.131.166^M a=rtpmap:0 PCMU/8000^M --------------------------------------------------------------------- So the response is at least coming back on a different port. > In the standard IMS Bench SIPp setup, the registrations are done so each > user has its own IP address / UDP port combination and the SUT is > expected to send traffic to the combination registered for each user. Is > this the way your SUT operates? IMS Bench SIPp can be configured to work As far as I know it is supposed to be. That is, the SUT records the IP and port number in the registration and sends traffic based on that IP/port number combination. --RDM ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Sipp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sipp-users
