Try
<nop display="-Redirect Dest Port">
<action>
<setdest host="[remote_ip]" port="[$2]" protocol="tcp" />
</action>
</nop>
<send retrans="500">
<![CDATA[
INVITE [$1][$2] SIP/2.0
________________________________
From: John Rodriguez [mailto:[email protected]]
Sent: 24 June 2009 16:32
To: Kirwan, David (David); SIPp Mailing List
Subject: RE: [Sipp-users] Perform redirect without SetDest?
Hi David--
Thanks for your reply - I've attached the scenario I'm using. I grab
the 302 port very similarly to yours - once I grab it (as you see in the
scenario file), I'm sending another Invite with the updated 302 port;
from the trace logs, everything LOOKS good. However, in wireshark, you
can see that when the second invite gets sent, it's still sending to the
original port specified from the cmdline, although the second invite
iteslf does include the correct port.
As I mentioned, I'm using sip over TCP, so not sure if that's the issue
- if I use the setdest as seen in the attached xml, it works fine (and
unfortunately, SIPp randomly locks and dies using this function).
Thanks!
________________________________
Subject: RE: [Sipp-users] Perform redirect without SetDest?
Date: Wed, 24 Jun 2009 16:17:46 +0100
From: [email protected]
To: [email protected]; [email protected]
Post your xml scenario, that would help.
I use the following to extract the 302 redirect information,
instead of saving it to a file like I do, you could put it into an
INVITE, etc.
<!-- Contact header contains URI of the ad hoc conference to move to
-->
<recv response="302" rtd="true">
<action>
<ereg regexp="\<([a-za-z...@.=;]+)[^>]+"
search_in="hdr"
header="Contact: "
assign_to="1"/>
<log message="INFO: 302 Contact Header: [$1]" />
<exec command="echo [$1] >> ./302ContactHeader.txt" />
</action>
</recv>
________________________________
From: John Rodriguez [mailto:[email protected]]
Sent: 24 June 2009 15:18
To: SIPp Mailing List
Subject: [Sipp-users] Perform redirect without SetDest?
When I send a TCP sip call, I am getting a 302 redirect from the server
which redirects to the port I should connect to. I've had no trouble
extracting the new destination port from the CONTACT header. However,
the only way I've been able to get the call to work is if I use the
"SetDest" function to point to the new redirected port. Is there anyway
to perform a redirect of this nature WITHOUT using SetDest? Simply
sending another invite with the new port does not work.
The reason I'm asking is b/c I noticed that although the call WILL go
through, SIPp actually locks up occasionally during load at seemingly
random intervals and drops all calls. I'm 100% positive that setdest is
causing this b/c if I bypass the initial port and redirect to the new
port by specifying in the cmd line, all works fantastic, no lock ups,
etc; I am aware from the doc that the setdest may cause locking which
may be exactly what I'm experiencing. The problem with this is a) it's
not forcing the server to send the redirect and b) getting the
redirected port is a bit of pain as it tends to change every so often.
Any ideas?
Thanks!
________________________________
Lauren found her dream laptop. Find the PC that's right for you.
<http://www.microsoft.com/windows/choosepc/?ocid=ftp_val_wl_290>
________________________________
Bing(tm) brings you maps, menus, and reviews organized in one place. Try
it now.
<http://www.bing.com/search?q=restaurants&form=MLOGEN&publ=WLHMTAG&crea=
TEXT_MLOGEN_Core_tagline_local_1x1>
------------------------------------------------------------------------------
_______________________________________________
Sipp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sipp-users
