[Freeswitch-users] SIPp issues - seems FS doesn't understand ACK message

[Anthony Minessale]

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 at 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>
>
>   <!-- definition of the response time repartition table (unit is ms)   -->
>   <ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
>
>   <!-- definition of the call length repartition table (unit is ms)     -->
>   <CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
>
> </scenario>
>
>
>
> On Tue, Aug 25, 2009 at 3:57 AM, mayamatakeshi <mayamatakeshi at gmail.com>wrote:
>
>> On Tue, Aug 25, 2009 at 10:52 AM, mayamatakeshi<mayamatakeshi at gmail.com>
>> wrote:
>> > On Tue, Aug 25, 2009 at 7:31 AM, Tihomir Culjaga<tculjaga at 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 at 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 at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090825/ab752683/attachment-0002.html