On 05/16/2012 11:49 AM, Mark Michelson wrote: > Hi list, > > First off, here's my sipp -v output: > > SIPp v3.1-TLS-PCAP, version unknown, built Feb 5 2010, 03:01:20. > > I'm running a scenario where I use SIPp as a UAC. During the scenario, > the server sends back-to-back NOTIFY requests very quickly to SIPp. > Each of these NOTIFYs are part of separate transactions on an > established dialog. I have my scenario looking like the following: > > <recv request="NOTIFY" crlf="true"> > </recv> > > <send retrans="500"> > <![CDATA[ > > SIP/2.0 200 OK > [last_Via:] > [last_From:] > [last_To:] > [last_Call-ID:] > [last_CSeq:] > [last_Event:] > Contact: <sip:[local_ip]:[local_port];transport=[transport]> > Content-Length: 0 > ]]> > </send> > > <recv request="NOTIFY" crlf="true"> > </recv> > > <send retrans="500"> > <![CDATA[ > > SIP/2.0 200 OK > [last_Via:] > [last_From:] > [last_To:] > [last_Call-ID:] > [last_CSeq:] > [last_Event:] > Contact: <sip:[local_ip]:[local_port];transport=[transport]> > Content-Length: 0 > ]]> > </send> > > Seems pretty simple. What happens though, is that SIPp sends the 200 > OK for the initial NOTIFY, receives the second NOTIFY, and then > retransmits the 200 OK for the initial NOTIFY until eventually the > scenario fails. Looking at the display while SIPp is running, I see > that SIPp thinks that it is actually transmitting (and retransmitting) > the 200 OK for the second NOTIFY and not the first. Packet inspection > shows that the CSeq and Via branches of the retransmitted 200 OK from > SIPp match those of the initial NOTIFY. > > Since the NOTIFYs are sent by the server so quickly, I thought that > might be "confusing" SIPp. I altered my scenario to receive the > NOTIFYs back to back and then to try to send the two 200 OKs after. > This meant having to cache the Via and CSeq headers from the two > NOTIFYs so they could be echoed properly in the two 200 OKs that I > sent. This, however, resulted in the same behavior. > > I skimmed the documentation for SIPp and could not find anything that > seemed relevant to my situation. I tried the wiki link from the SIPp > home page and got a 500 error. I also looked through the SIPp 3.2 > changelog and did not see anything that sounded relevant to what I am > doing. > > If anyone can point me in the right direction for how to handle this > scenario, please let me know. > > Thank you very much, > Mark Michelson
I was able to fix my issue. I needed to remove the "retrans" attributes from my 200 OK responses. My assumption is that by placing a retrans on a response, SIPp expects an ACK. Of course, responses to in-dialog requests do not get ACKed, so this was causing the infinite retransmissions. SIPp still has an issue since it was displaying that the incorrect 200 OK was being retransmitted. Mark Michelson ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Sipp-users mailing list Sipp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sipp-users
