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

mayamatakeshi mayamatakeshi at gmail.com
Mon Aug 24 18:57:36 PDT 2009


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
>




More information about the FreeSWITCH-users mailing list