I beleive this is following the right rfc rules for dialog matching.
If it is not, please open up a bug on jira.freeswitch.org with
references of what exactly is not right.
Mike
On Aug 25, 2009, at 2: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
_______________________________________________
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
