Hello Victor and all,

I'm coming up again to this problem 7 months later :)

Well, I stopped searching this problem then, but now I need to understand SIPP 
tool
in order to stress test a SER box using SIPP.
So, I faced up the same problem, which it drives me really crazy... :)


I did what you propose, using the [last_Record-Route:] keyword (instead of 
[routes] keyword),
in my uas.xml file (for 180 Ringing, 200 Ok). Also the same for ACK mesg in 
uac.xml.


But the problem remains the same :
SER doesn't recognize this ACK in the dialog sent by the UAC (Host A),
and this ACK is not loose routed to the UAS. So the UAS continues to send '200 
OK'.
And I have a 'Too Many hops' situation @ SER after some seconds...



Please note, that I have a working SER configuration for over 1 year.


I really appreciate, If someone could help me.
Attached you can find my uac and uas xml files



thanks
Kostas

Victor L wrote:
> Hello Kostas,
>  
> Here's a problem I ran into - it could be related to what you are seeing:
>  
> In my case, the proxy (media server also configured with it), is
> supposed to ACK as soon as it receives a 200 OK. However, it would not
> work until I figured that I was using the [routes] keyword while
> composing the 200 OK message. This keyword extracted the Record-Route
> header from the original header and converted it to a Route header. This
> is not supported by SIP. A 200 OK message should preserve the
> Record-Route headers. As soon as I added the Record-Route headers
> manually and stopped using the [routes] keyword, I got my scenario
> working. Verify if this is the case in your scenario.
>  
> Hope this helps.
> 
> Vic
>  
> On 9/20/06, *Kostas Marneris* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
> 
>     Hello all,
> 
>     I run the basic UAC senario in Host A (1.1.1.1 <http://1.1.1.1>) and
>     the basic UAS senario in Host B ( 2.2.2.2 <http://2.2.2.2>).
>     I have a SER SIP Proxy in the middle (3.3.3.3 <http://3.3.3.3>).
> 
> 
>     UAC :
>     ./sipp -sn uac -r 1 -m 1 -d 5000 -i 1.1.1.1 <http://1.1.1.1>  
>     3.3.3.3 <http://3.3.3.3>
> 
> 
>     UAS :
>     ./sipp -sn uas
> 
> 
>     SER.cfg  :
> 
>     I use the following hack in ser.cfg, because the default user
>     'service' is not
>     actually registered in Location DB.
> 
>     # In INVITE handler ..
>     ...
> 
>            # --- SIPP hack ---
>            if (uri =~ "^sip:[EMAIL PROTECTED]:5060") {
>                    rewritehostport("2.2.2.2:5060 <http://2.2.2.2:5060>");
>                    route(1);
>                    break;
>            };
>            # -----------------
> 
> 
>     # In MAIN Route Block
>     # ---------------------
>     Nothing changed from 'default SER behaviour' :
> 
>            if ((method != "REGISTER") && (method != "OPTIONS")) {
>                    log(1, " Add RR");
>                    record_route();
>            };
> 
> 
>            if (loose_route()) {
>                    route(1);
>                    break;
>            };
> 
> 
> 
> 
>     Where is the problem :
>     It seems that SER doesn't recognize (in the dialog) the ACK sent by
>     the UAC (Host A),
>     do does not relay it to the UAS. The UAS continues to send '200
>     OK'... so I can't make it
>     to have a 'full call setup simulation senario'.
> 
>     Call Flow :
> 
>     HOST A (UAC)            SER             HOST B (UAS)
>                ----------->                                        (1)
>     INVITE
>                <-----------                                        (2)
>     100 Trying
>                              -------------->                       (3)
>     INVITE
>                              <-------------                        (4)
>     180 Ringing
>                <-----------                                        (5)
>     180 Ringing
>                              <-------------                        (6)
>     200 OK
>                <-----------                                        (7)
>     200 OK
>                ----------->                                        (8) ACK
> 
>                              <-------------                        (9)
>     200 OK
>                ----------->                                        (10) ACK
>     ....
>     ....
> 
>     The first ACK (8) from UAC to SER doesn't relayed to UAS,
>     so UAS keeps sending '200 OK'...
> 
> 
>     This ACK doesn't go through the 'loose_route()' block because SER thinks
>     that this ACK is not in the dialog.
>     Even if I add the following code in MAIN route block,
>     SER insists to absorb this ACK request.
>            ...
>            } else if (method == "ACK") {
>                    # ACK mesgs --> route[1]
>                    log(1," * ACK -- not in the DIALOG --");
>                    route(1);
>                    break;
>            } else if ...
> 
> 
> 
>     Do you find something wrong in SER conf ?
>     or do you have any idea why this happening ?
> 
> 
>     thank you
>     Kostas
> 
>     -------------------------------------------------------------------------
> 
>     Take Surveys. Earn Cash. Influence the Future of IT
>     Join SourceForge.net's Techsay panel and you'll get the chance to
>     share your
>     opinions on IT & business topics through brief surveys -- and earn cash
>     http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>     
> <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
>     _______________________________________________
>     Sipp-users mailing list
>     [email protected]
>     <mailto:[email protected]>
>     https://lists.sourceforge.net/lists/listinfo/sipp-users
> 
> 
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">

<!-- This program is free software; you can redistribute it and/or      -->
<!-- modify it under the terms of the GNU General Public License as     -->
<!-- published by the Free Software Foundation; either version 2 of the -->
<!-- License, or (at your option) any later version.                    -->
<!--                                                                    -->
<!-- This program is distributed in the hope that it will be useful,    -->
<!-- but WITHOUT ANY WARRANTY; without even the implied warranty of     -->
<!-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the      -->
<!-- GNU General Public License for more details.                       -->
<!--                                                                    -->
<!-- You should have received a copy of the GNU General Public License  -->
<!-- along with this program; if not, write to the                      -->
<!-- Free Software Foundation, Inc.,                                    -->
<!-- 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA             -->
<!--                                                                    -->
<!--                 Sipp default 'uas' scenario.                       -->
<!--                                                                    -->

<scenario name="kmar UAS responder">
  <!-- By adding rrs="true" (Record Route Sets), the route sets         -->
  <!-- are saved and used for following messages sent. Useful to test   -->
  <!-- against stateful SIP proxies/B2BUAs.                             -->

  <!-- RECEIVE 'INVITE' -->
  <recv request="INVITE" rrs="true" crlf="true">
  </recv>

  <!-- The '[last_*]' keyword is replaced automatically by the          -->
  <!-- specified header if it was present in the last message received  -->
  <!-- (except if it was a retransmission). If the header was not       -->
  <!-- present or if no message has been received, the '[last_*]'       -->
  <!-- keyword is discarded, and all bytes until the end of the line    -->
  <!-- are also discarded.                                              -->
  <!--                                                                  -->
  <!-- If the specified header was present several times in the         -->
  <!-- message, all occurences are concatenated (CRLF seperated)        -->
  <!-- to be used in place of the '[last_*]' keyword.                   -->


  <!-- SEND '100 Trying' -->
  <send>
    <![CDATA[

      SIP/2.0 100 Trying
      [last_Via:]
      [last_From:]
      [last_To:];tag=[call_number]
      [last_Call-ID:]
      [last_CSeq:]
      Content-Length: 0

    ]]>
  </send>


  <!-- SEND '180 Ringing' -->
  <send crlf="true">
    <![CDATA[

      SIP/2.0 180 Ringing
      [last_Via:]
      [last_From:]
      [last_To:];tag=[call_number]
      [last_Call-ID:]
      [last_CSeq:]
      Contact: <sip:[local_ip]:[local_port];transport=[transport]>
      [last_Record-Route:]
      Content-Length: 0

    ]]>
  </send>


  <!-- PAUSE for 10 seconds = This is the response time duration -->
  <pause milliseconds="10000"/>


  <!-- SEND '200 OK' -->
  <send retrans="500">
    <![CDATA[

      SIP/2.0 200 OK
      [last_Via:]
      [last_From:]
      [last_To:];tag=[call_number]
      [last_Call-ID:]
      [last_CSeq:]
      Contact: <sip:[local_ip]:[local_port];transport=[transport]>
      [last_Record-Route:]
      Content-Type: application/sdp
      Content-Length: 136

      v=0
      o=user1 53655765 2353687637 IN IP4 127.0.0.1
      s=-
      c=IN IP4 [media_ip]
      t=0 0
      m=audio [media_port] RTP/AVP 0
      a=rtpmap:0 PCMU/8000

    ]]>
  </send>


  <!-- RECEIVE 'ACK' : The original INVITE transaction ends here -->
  <recv request="ACK"
        optional="true"
        rtd="true"
        crlf="true">
  </recv>


  <!-- RECEIVE 'BYE' -->
  <recv request="BYE">
  </recv>


  <!-- SEND '200 OK' -->
  <send>
    <![CDATA[

      SIP/2.0 200 OK
      [last_Via:]
      [last_From:]
      [last_To:];tag=[call_number]
      [last_Call-ID:]
      [last_CSeq:]
      Contact: <sip:[local_ip]:[local_port];transport=[transport]>
      Content-Length: 0

    ]]>
  </send>

  <!-- Keep the call open for a while in case the 200 is lost to be     -->
  <!-- able to retransmit it if we receive the BYE again.               -->
  <pause milliseconds="3000"/>


  <!-- 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>

<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">

<!-- This program is free software; you can redistribute it and/or      -->
<!-- modify it under the terms of the GNU General Public License as     -->
<!-- published by the Free Software Foundation; either version 2 of the -->
<!-- License, or (at your option) any later version.                    -->
<!--                                                                    -->
<!-- This program is distributed in the hope that it will be useful,    -->
<!-- but WITHOUT ANY WARRANTY; without even the implied warranty of     -->
<!-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the      -->
<!-- GNU General Public License for more details.                       -->
<!--                                                                    -->
<!-- You should have received a copy of the GNU General Public License  -->
<!-- along with this program; if not, write to the                      -->
<!-- Free Software Foundation, Inc.,                                    -->
<!-- 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA             -->
<!--                                                                    -->
<!--                 Sipp default 'uac' scenario.                       -->
<!--                                                                    -->

<scenario name="kmar Sipstone UAC">
  <!-- In client mode (sipp placing calls), the Call-ID MUST be         -->
  <!-- generated by sipp. To do so, use [call_id] token.                -->

  <!-- SEND 'INVITE' -->
  <send retrans="500">
    <![CDATA[

      INVITE sip:[EMAIL PROTECTED]:[remote_port] SIP/2.0
      Via: SIP/2.0/[transport] [local_ip]:[local_port]
      From: sipp <sip:[EMAIL PROTECTED]:[local_port]>;tag=[call_number]
      To: sut <sip:[EMAIL PROTECTED]:[remote_port]>
      Call-ID: [call_id]
      CSeq: 1 INVITE
      Contact: sip:[EMAIL PROTECTED]:[local_port]
      Max-Forwards: 70
      Subject: Performance Test
      Content-Type: application/sdp
      Content-Length: 136

      v=0
      o=user1 53655765 2353687637 IN IP4 127.0.0.1
      s=-
      c=IN IP4 [media_ip]
      t=0 0
      m=audio [media_port] RTP/AVP 0
      a=rtpmap:0 PCMU/8000

    ]]>
  </send>


  <!-- RECEIVE '100 Trying' -->
  <recv response="100" optional="true">
  </recv>


  <!-- RECEIVE '180 Trying' -->
  <recv response="180" optional="true" crlf="true">
  </recv>


  <!-- RECEIVE '200 OK' -->
  <!-- By adding rrs="true" (Record Route Sets), the route sets         -->
  <!-- are saved and used for following messages sent. Useful to test   -->
  <!-- against stateful SIP proxies/B2BUAs.                             -->
  <recv response="200" rrs="true" rtd="true">
  </recv>


  <!-- SEND 'ACK' -->
  <!-- Packet lost can be simulated in any send/recv message by         -->
  <!-- by adding the 'lost = "10"'. Value can be [1-100] percent.       -->
  <send>
    <![CDATA[

      ACK sip:[EMAIL PROTECTED]:[remote_port] SIP/2.0
      Via: SIP/2.0/[transport] [local_ip]:[local_port]
      [last_Record-Route:]
      From: sipp <sip:[EMAIL PROTECTED]:[local_port]>;tag=[call_number]
      To: sut <sip:[EMAIL PROTECTED]:[remote_port]>[peer_tag_param]
      Call-ID: [call_id]
      CSeq: 1 ACK
      Contact: sip:[EMAIL PROTECTED]:[local_port]
      Max-Forwards: 70
      Subject: Performance Test
      Content-Length: 0

    ]]>
  </send>

  <!-- PAUSE= -d cmd line parameter. This is the actual call duration -->
  <!-- This delay can be customized by the -d command-line option       -->
  <!-- or by adding a 'milliseconds = "value"' option here.             -->
  <pause/>


  <!-- SEND 'BYE' -->
  <!-- The 'crlf' option inserts a blank line in the statistics report. -->
  <send retrans="500">
    <![CDATA[

      BYE sip:[EMAIL PROTECTED]:[remote_port] SIP/2.0
      Via: SIP/2.0/[transport] [local_ip]:[local_port]
      [last_Record-Route:]
      From: sipp <sip:[EMAIL PROTECTED]:[local_port]>;tag=[call_number]
      To: sut <sip:[EMAIL PROTECTED]:[remote_port]>[peer_tag_param]
      Call-ID: [call_id]
      CSeq: 2 BYE
      Contact: sip:[EMAIL PROTECTED]:[local_port]
      Max-Forwards: 70
      Subject: Performance Test
      Content-Length: 0

    ]]>
  </send>


  <!-- RECEIVE '200 OK' -->
  <recv response="200" crlf="true">
  </recv>

  <!-- 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>

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Sipp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sipp-users

Reply via email to