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 < [email protected]> 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 <[email protected]>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:[servi...@[remote_ip]:[remote_port] SIP/2.0 >> Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] >> Max-Forwards: 70 >> Contact: <sip:[fiel...@[local_ip]> >> From: [field1] >> <sip:[fiel...@[local_ip]:[local_port]>;tag=[call_number] >> To: [service] <sip:[servi...@[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:[servi...@[remote_ip]:[remote_port] SIP/2.0 >> Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch-3] >> From: [field1] >> <sip:[fiel...@1[local_ip]:[local_port]>;tag=[call_number] >> To: [service] >> <sip:[servi...@[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 >> <[email protected]>wrote: >> >>> On Tue, Aug 25, 2009 at 10:52 AM, mayamatakeshi<[email protected]> >>> wrote: >>> > On Tue, Aug 25, 2009 at 7:31 AM, Tihomir Culjaga<[email protected]> >>> 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 >>> [email protected] >>> 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 >> [email protected] >> 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:[email protected] <msn%[email protected]> > GTALK/JABBER/PAYPAL:[email protected]<paypal%[email protected]> > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:[email protected] <sip%[email protected]> > iax:[email protected]/888 > googletalk:[email protected]<googletalk%3aconf%[email protected]> > pstn:213-799-1400 > > _______________________________________________ > FreeSWITCH-users mailing list > [email protected] > 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 [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
