Hi,
I am having issues with an attended transfer scenario.
Set up -- call application and be transferred to uas running locally:
sipp ....... -sf transfer-uas.xml -p 5060
sipp .... -sf transfer-uac-b.xml -3pcc 127.0.0.1:50002 127.0.0.1:5060
sipp .... -sf transfer-uac-a.xml -3pcc 127.0.0.1:50002<transfer-attendant-host>
transfer-uac-a.xml calls an SIP application that sends a refer in an
attended transfer call flow.
transfer-uac-a.xml responds by sending a "202 Accepted" response.
The SIP application receives the 202 and processes it appropriately.
SIPP then proceeds to re transmit the 202 repeatedly until re-transmits
have been exceeded at which point the scenario fails.
Are there any known issue with sending a "202 Accepted" response in a sipp
scenario?
.................. excerpt from transfer-uac-a.xml
<recv request="REFER">
<action>
<ereg regexp=".*"
search_in="hdr"
header="Refer-To: "
assign_to="referTo"/>
</action>
</recv>
<send retrans="500">
<![CDATA[
SIP/2.0 202 Accepted
[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>
<!-- tell transfer-uac-b what the Refer-To header is -->
<sendCmd>
<![CDATA[
Refer-To: [$referTo]
]]>
</sendCmd>
...................................
Thanks,
Dan
--
Daniel Knopp
Application Development & Services
www.imsworkx.com | dkn...@imsworkx.com
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
