<html><body bgcolor="#FFFFFF"><div>I beleive this is following the right rfc rules for dialog matching. &nbsp;If it is not, please open up a bug on <a href="http://jira.freeswitch.org">jira.freeswitch.org</a> with references of what exactly is not right.</div><div><br></div><div>Mike<br><br>On Aug 25, 2009, at 2:51 AM, Tihomir Culjaga &lt;<a href="mailto:tculjaga@gmail.com">tculjaga@gmail.com</a>&gt; wrote:<br><br></div><div></div><blockquote type="cite"><div>Hello Takeshi,<br><br>Thanks for your hint... it worked out... so to be precise:<br><br>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.<br>
<br><br>Finally, here is what i used and I'm getting some poor results .. but this is another topic :)<br><br><br>Thanks for your help.<br>Tihomir.<br><br><br>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<br>
<br><br>&lt;?xml version="1.0" encoding="ISO-8859-1" ?&gt;<br>&lt;!DOCTYPE scenario SYSTEM "sipp.dtd"&gt;<br><br><br>&lt;scenario name="Basic Sipstone UAC"&gt;<br>&nbsp; &lt;send retrans="500" start_rtd="1" start_rtd="2"&gt;<br>
<br>&nbsp;&nbsp;&nbsp; &lt;![CDATA[<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Max-Forwards: 70<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Contact: &lt;sip:[field1]@[local_ip]&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: [field1] &lt;sip:[field1]@[local_ip]:[local_port]&gt;;tag=[call_number]<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To: [service] &lt;sip:[service]@[remote_ip]:[remote_port]&gt;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID: [call_id]<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 INVITE<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Type: application/sdp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: [len]<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v=0<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; s=-<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c=IN IP[media_ip_type] [media_ip]<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; t=0 0<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; m=audio [media_port] RTP/AVP 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a=rtpmap:0 PCMU/8000<br><br>&nbsp;&nbsp;&nbsp; ]]&gt;<br>&nbsp; &lt;/send&gt;<br><br>&nbsp; &lt;recv response="100"<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; optional="true" rtd="1"&gt;<br>&nbsp; &lt;/recv&gt;<br><br><br>&nbsp; &lt;recv response="302" rtd="2"&gt;<br>
&nbsp; &lt;/recv&gt;<br><br>&nbsp; &lt;send&gt;<br>&nbsp;&nbsp;&nbsp; &lt;![CDATA[<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch-3]<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: [field1] &lt;sip:[field1]@1[local_ip]:[local_port]&gt;;tag=[call_number]<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To: [service] &lt;sip:[service]@[remote_ip]:[remote_port]&gt;[peer_tag_param]<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID: [call_id]<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 ACK<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Max-Forwards: 70<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 0<br><br>&nbsp;&nbsp;&nbsp; ]]&gt;<br>&nbsp; &lt;/send&gt;<br>
<br>&nbsp; &lt;!-- definition of the response time repartition table (unit is ms)&nbsp;&nbsp; --&gt;<br>&nbsp; &lt;ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/&gt;<br><br>&nbsp; &lt;!-- definition of the call length repartition table (unit is ms)&nbsp;&nbsp;&nbsp;&nbsp; --&gt;<br>
&nbsp; &lt;CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/&gt;<br><br>&lt;/scenario&gt;<br><br><br><br><div class="gmail_quote">On Tue, Aug 25, 2009 at 3:57 AM, mayamatakeshi <span dir="ltr">&lt;<a href="mailto:mayamatakeshi@gmail.com"><a href="mailto:mayamatakeshi@gmail.com">mayamatakeshi@gmail.com</a></a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Tue, Aug 25, 2009 at 10:52 AM, mayamatakeshi&lt;<a href="mailto:mayamatakeshi@gmail.com"><a href="mailto:mayamatakeshi@gmail.com">mayamatakeshi@gmail.com</a></a>&gt; wrote:<br>

&gt; On Tue, Aug 25, 2009 at 7:31 AM, Tihomir Culjaga&lt;<a href="mailto:tculjaga@gmail.com"><a href="mailto:tculjaga@gmail.com">tculjaga@gmail.com</a></a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; sipp_cmd:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sipp -sn uac 10.4.4.251 -sf uac_redirect.xml -s<br>
&gt;&gt; 30003016094191500 -trace_err -r 1 -rp 1000 -trace_msg -inf test.txt -m 1 -l<br>
&gt;&gt; 4000<br>
&gt;&gt; scenario file:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; uac_redirect.xml<br>
&gt;&gt; FS dialplan:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public.xml<br>
&gt;&gt; SIP trace:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; trace.log<br>
&gt;<br>
&gt; The Via definition in your SIPp scenario differs between the INVITE and the ACK:<br>
&gt;<br>
&gt; INVITE:<br>
&gt; Via: SIP/2.0/[transport] [local_ip];branch=[branch]<br>
&gt;<br>
&gt; ACK:<br>
&gt; Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch-3]<br>
&gt;<br>
&gt;<br>
&gt; In the INVITE, you are not adding the [local_port] as you do in the ACK.<br>
&gt; Just adding the [local_port] in the INVITE makes FreeSWITCH accept the ACK.<br>
&gt; So it seems FS is not checking just the ACK's branch against the<br>
&gt; INVITE's; it seems it is checking the whole Via header.<br>
&gt; I don't know if this is in accordance to SIP specs.<br>
&gt; Another thing, about the way you are calling SIPp: do no use "-sn uac"<br>
&gt; and "-sf uac_redirect.xml" at the same time. The parameter "-sn xxx"<br>
&gt; means "use the internal (embedded) scenario named xxx". So this<br>
&gt; conflicts with the other parameter "-sf" which specifies an external<br>
&gt; profile.<br>
<br>
</div>I mean, an external scenario (file).<br>
<div><div></div><div class="h5"><br>
&nbsp;It seems this doesn't cause any problem (probably because in<br>
&gt; the sipp startup, -sf overrides -sn), but it is misleading.<br>
&gt;<br>
&gt; regards,<br>
&gt; takeshi<br>
&gt;<br>
<br>
_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org"><a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a></a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank"><a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a></a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank"><a href="http://lists.freeswitch.org/mailman/options/freeswitch-users">http://lists.freeswitch.org/mailman/options/freeswitch-users</a></a><br>
<a href="http://www.freeswitch.org" target="_blank"><a href="http://www.freeswitch.org">http://www.freeswitch.org</a></a><br>
</div></div></blockquote></div><br>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>FreeSWITCH-users mailing list</span><br><span><a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a></span><br><span><a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a></span><br><span>UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users</span><br><span><a href="http://www.freeswitch.org">http://www.freeswitch.org</a></span><br></div></blockquote></body></html>