On Tue, Aug 25, 2009 at 3:23 PM, Bradley Brashier <bjbrashier@gmail.com> wrote:

Well, you'd have another nickel from over here, then.

If I can get this working before I'm tasked with something else I'll write up something more on the wiki about "Freeswitch and SIPp", but I'm not sure I'll get that chance.

BB

On Tue, Aug 25, 2009 at 11:05 AM, Anthony Minessale <anthony.minessale@gmail.com> wrote:

I wish I had a nickel for every guy struggling with sipp load testing vs real world traffic.

On Tue, Aug 25, 2009 at 1:51 AM, Tihomir Culjaga <tculjaga@gmail.com> wrote:

Hello Takeshi,

Thanks for your hint... it worked out... so to be precise:

VIA header of both INVITE and ACK messages MUST be identical (IP:PORT + branch)... and you are right... it might not be according to SIP specification. Anyhow, i get FS understand my ACK message.

Finally, here is what i used and I'm getting some poor results .. but this is another topic :)

Thanks for your help.
Tihomir.

sipp 10.4.4.251 -sf uac_redirect.xml -s 30003016094191500 -trace_err -r 1 -rp 100 -trace_msg -inf test.txt -m 20000 -l 4000

<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">

<scenario name="Basic Sipstone UAC">
<send retrans="500" start_rtd="1" start_rtd="2">

    <![CDATA[

      INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
      Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]

      Max-Forwards: 70
      Contact: <sip:[field1]@[local_ip]>
      From: [field1] <sip:[field1]@[local_ip]:[local_port]>;tag=[call_number]
      To: [service] <sip:[service]@[remote_ip]:[remote_port]>
      Call-ID: [call_id]
      CSeq: 1 INVITE
      Content-Type: application/sdp
      Content-Length: [len]

      v=0
      o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
      s=-
      c=IN IP[media_ip_type] [media_ip]
      t=0 0
      m=audio [media_port] RTP/AVP 0
      a=rtpmap:0 PCMU/8000

    ]]>
</send>

<recv response="100"
        optional="true" rtd="1">
</recv>

<recv response="302" rtd="2">

</recv>

<send>
    <![CDATA[

      ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0
      Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch-3]

      From: [field1] <sip:[field1]@1[local_ip]:[local_port]>;tag=[call_number]
      To: [service] <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
      Call-ID: [call_id]
      CSeq: 1 ACK
      Max-Forwards: 70
      Content-Length: 0

    ]]>
</send>


<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>


<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>

</scenario>

On Tue, Aug 25, 2009 at 3:57 AM, mayamatakeshi <mayamatakeshi@gmail.com> wrote:

On Tue, Aug 25, 2009 at 10:52 AM, mayamatakeshi<mayamatakeshi@gmail.com> wrote:
> On Tue, Aug 25, 2009 at 7:31 AM, Tihomir Culjaga<tculjaga@gmail.com> wrote:
>>
>> sipp_cmd:         sipp -sn uac 10.4.4.251 -sf uac_redirect.xml -s
>> 30003016094191500 -trace_err -r 1 -rp 1000 -trace_msg -inf test.txt -m 1 -l
>> 4000
>> scenario file:      uac_redirect.xml
>> FS dialplan:       public.xml
>> SIP trace:          trace.log
>
> The Via definition in your SIPp scenario differs between the INVITE and the ACK:
>
> INVITE:
> Via: SIP/2.0/[transport] [local_ip];branch=[branch]
>
> ACK:
> Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch-3]
>
>
> In the INVITE, you are not adding the [local_port] as you do in the ACK.
> Just adding the [local_port] in the INVITE makes FreeSWITCH accept the ACK.
> So it seems FS is not checking just the ACK's branch against the
> INVITE's; it seems it is checking the whole Via header.
> I don't know if this is in accordance to SIP specs.
> Another thing, about the way you are calling SIPp: do no use "-sn uac"
> and "-sf uac_redirect.xml" at the same time. The parameter "-sn xxx"
> means "use the internal (embedded) scenario named xxx". So this
> conflicts with the other parameter "-sf" which specifies an external
> profile.

I mean, an external scenario (file).

It seems this doesn't cause any problem (probably because in
> the sipp startup, -sf overrides -sn), but it is misleading.
>
> regards,
> takeshi
>

_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

--
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale@hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
iax:guest@conference.freeswitch.org/888
googletalk:conf+888@conference.freeswitch.org
pstn:213-799-1400

_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org