|
From: Edward R. <eru...@Ta...> - 2006-07-19 18:15:42
|
Thank you for the explanation. That confirms why it works for me when I split the two portions of the scenario and first run one instance of sipp and then another. My problem with that solution is that while I am using sipp for both client and server, my device under test is a sip proxy in the middle. That sip proxy will only forward invites to the same ip address/port that the registration came in on (physically, not just what's specified in the protocol message/scenario file). No problem if I force the port of sipp or leave it as default 5065. The problem is I want to generate thousands of registrations/answerers for different phone numbers. That means a unique port for each. =20 Rather than start up 1000 sipps each with a different port, I thought I would use the -m 1000 and -t un option so that each registration would go out from a different port. But in order for the invite to be received on the same port, I can't run another instance of sipp to receive the invite. I have to use the same instance and therefore combine the register and recv invite into one scenario file. =20 Sounds like I'm kind of stuck because the incoming INVITE call_id won't match the call_id that was used to send the register. (The "inviter" does not receive the registration - the DUT handles that. So the "inviter" does not know what call_id was used for the regisrtation). As the doc says:=20 [call_id] - A call_id identifies a call and is generated by SIPp for each new call. In client mode, it is mandatory to use the value generated by SIPp in the "Call-ID" header. Otherwise, SIPp will not recognise the answer to the message sent as being part of an existing call. Maybe I can hack the code for myself and force it to be in Server mode even though the first action is a send. Not sure that would even work, but since I am using unique ports (via -t un) maybe sipp will match the instance of the call based on the port. Doubt it. Any other ideas (I guess just start 1000 sipp processes - thank goodness its linux and not windows :-) -----Original Message----- From: Artur Silveira da Cunha [mailto:Art...@al...]=20 Sent: Wednesday, July 19, 2006 11:54 AM To: Edward Russell Cc: sip...@li... Subject: Re: [Sipp-users] REGISTER and recv INVITE in same scenario file Hi, Your problem comes certainly from the following: - sipp when it creates each scenario, takes the generated call_id and stores it to match all incoming replies to affect them to the running scenario. In your sample: - the Register is send and "sipp" stores the generated call_id - in the incoming 200, sipp must match the generated call_id, to affect it to the scenario, - in the incoming Invite, you have a different "call_id", then sipp can't knows for which scenario it belongs. That is for me the reason why sipp can't affect the incoming Invites to your Register. For the same cases I use the following solution: - one sipp working in port 5065 that issues Register and waits for the 200 OK, in the xml scenario you indicates another port like 5066. <?xml version=3D"1.0" encoding=3D"ISO-8859-1" ?> <scenario name=3D"register_answer"> <send retrans=3D"1000"> <![CDATA[ REGISTER sip:hal9004.whatever.com SIP/2.0 Via: SIP/2.0/[transport] = [local_ip]:[local_port];rport;branch=3D[branch] From: <sip:[field0]@hal9004.whatever.com:[local_port]>;tag=3D[call_number] To: <sip:[field0]@hal9004.whatever.com:[local_port]> Contact: <sip:[field0]@[local_ip]:5066> Call-ID: [call_id] CSeq: [cseq] REGISTER Expires: 1800 Max-Forwards: 70 Content-Length: 0 ]]> </send> =20 <nop><action><log message=3D"sent REGISTER."/></action></nop> =20 <recv response=3D"200" crlf=3D"true" rrs=3D"true"> <action><log message=3D"received OK."/></action> </recv> </scenario> - another sipp listening in port 5066, with its xml scenario for the Invite: <?xml version=3D"1.0" encoding=3D"ISO-8859-1" ?> <scenario name=3D"register_answer"> <recv request=3D"INVITE" crlf=3D"true" = rrs=3D"true"> <action><log message=3D"received INVITE."/></action> </recv> =20 <send> <![CDATA[ SIP/2.0 180 Ringing [last_Via:] [last_From:] [last_To:];tag=3D[call_number] [last_Call-ID:] [last_CSeq:] [last_Record-Route:] Contact: <sip:9782060836@[local_ip]:[local_port]> Content-Length: [len] ]]> </send> <nop><action><log message=3D"sent RINGING."/></action></nop> <send> <![CDATA[ SIP/2.0 200 OK [last_Via:] [last_From:] [last_To:];tag=3D[call_number] [last_Call-ID:] [last_CSeq:] [last_Record-Route:] Contact: <sip:9782060836@[local_ip]:[local_port]> Content-Type: application/sdp Content-Length: [len] =20 v=3D0 o=3D9782060836 [pid] [pid][cseq] IN IP4 [local_ip] s=3DQA Test c=3DIN IP4 [local_ip] t=3D0 0 m=3Daudio [media_port] RTP/AVP 8 a=3Drtpmap:8 pcmu/8000 a=3Drtpmap:101 telephone-event/8000 a=3Dfmtp:101 0-11,16 ]]> </send> <nop><action><log message=3D"sent OK."/></action></nop> <recv request=3D"ACK" crlf=3D"true" rrs=3D"true"> <action><log = message=3D"received ACK."/></action> </recv> <nop><action><log message=3D"CALL INPROGRESS."/></action></nop> <recv request=3D"BYE" crlf=3D"true" rrs=3D"true"> <action><log message=3D"received BYE."/></action> </recv> <send> <![CDATA[ SIP/2.0 200 OK [last_Via:] [last_From:] [last_To:];tag=3D[call_number] [last_Call-ID:] [last_CSeq:] [last_Record-Route:] Contact: <sip:9782060836@[local_ip]:[local_port]> Content-Length: [len] ]]> </send> <nop><action><log message=3D"sent OK."/></action></nop> = <nop><action><log message=3D"CALL OVER."/></action></nop> </scenario> I hope that this helps you. Artur Edward Russell wrote: > I want to start up sipp with a scenario file which first sends a=20 > register, receives the 200 acknowledgement, and then waits to receive=20 > an INVITE. > =20 > This does not appear to work. While tcpdump shows the INVITE was=20 > received on the system, sipp does not display any evidence that it=20 > received it. It just sits waiting for the current call to end > ("current call" being the register I guess). Message counts=20 > (discarded or otherwise) do not go up after the 200. I am starting=20 > sipp with -m 1 because I just want to register and wait for 1 call. > Later I'll put in a branch loop to register then wait for multiple calls. > =20 > However if I split the scenario into two files, and first run sipp=20 > with the send register/recv 200 portion and the -m 1 flag, and then=20 > run sipp with the receive INVITE/send RINGING portion with NO -m flag, > all works fine. > =20 > Looking at the code, I think it has something to do with server mode=20 > and client mode. Because I am SENDING a register first, sipp puts=20 > itself into client mode and since I have the -m 1 flag it thinks the=20 > REGISTER was the one call and won't go on to process the INVITE? If I > leave off -m or put -m 2, multiple registrations are sent which is not > what I want either. > =20 > Every example I see has Register followed by SENDING an Invite, but I=20 > want to RECEIVE an INVITE after sending the register. > =20 > Any thoughts? If I solve this, will I really be able to branch and=20 > loop on the recv INVITE portion? Would I use the -m flag then? > =20 > Scenario I am using follows: > =20 > <?xml version=3D"1.0" encoding=3D"ISO-8859-1" ?> <scenario=20 > name=3D"register_answer"> <send retrans=3D"1000"> <![CDATA[ > REGISTER sip:hal9004.whatever.com SIP/2.0 > Via: SIP/2.0/[transport] [local_ip]:[local_port];rport;branch=3D[branch] > From: <sip:[field0]@hal9004.whatever.com:[local_port]>;tag=3D[call_number] > To: <sip:[field0]@hal9004.whatever.com:[local_port]> > Contact: <sip:[field0]@[local_ip]:[local_port]> > Call-ID: [call_id] > CSeq: [cseq] REGISTER > Expires: 1800 > Max-Forwards: 70 > Content-Length: 0 > ]]> > </send> > =20 > <nop><action><log message=3D"sent REGISTER."/></action></nop> > =20 > <recv response=3D"200" crlf=3D"true" rrs=3D"true"> <action><log=20 > message=3D"received OK."/></action> </recv> > =20 > <recv request=3D"INVITE" crlf=3D"true" rrs=3D"true"> <action><log=20 > message=3D"received INVITE."/></action> </recv> > =20 > <send> > <![CDATA[ > SIP/2.0 180 Ringing > [last_Via:] > [last_From:] > [last_To:];tag=3D[call_number] > [last_Call-ID:] > [last_CSeq:] > [last_Record-Route:] > Contact: <sip:9782060836@[local_ip]:[local_port]> > Content-Length: [len] > ]]> > </send> > <nop><action><log message=3D"sent RINGING."/></action></nop> <send> =20 > <![CDATA[ > SIP/2.0 200 OK > [last_Via:] > [last_From:] > [last_To:];tag=3D[call_number] > [last_Call-ID:] > [last_CSeq:] > [last_Record-Route:] > Contact: <sip:9782060836@[local_ip]:[local_port]> > Content-Type: application/sdp > Content-Length: [len] > =20 > v=3D0 > o=3D9782060836 [pid] [pid][cseq] IN IP4 [local_ip] > s=3DQA Test > c=3DIN IP4 [local_ip] > t=3D0 0 > m=3Daudio [media_port] RTP/AVP 8 > a=3Drtpmap:8 pcmu/8000 > a=3Drtpmap:101 telephone-event/8000 > a=3Dfmtp:101 0-11,16 > ]]> > </send> > <nop><action><log message=3D"sent OK."/></action></nop> <recv=20 > request=3D"ACK" crlf=3D"true" rrs=3D"true"> <action><log = message=3D"received=20 > ACK."/></action> </recv> <nop><action><log message=3D"CALL=20 > INPROGRESS."/></action></nop> <recv request=3D"BYE" crlf=3D"true"=20 > rrs=3D"true"> <action><log message=3D"received BYE."/></action> = </recv>=20 > <send> <![CDATA[ > SIP/2.0 200 OK > [last_Via:] > [last_From:] > [last_To:];tag=3D[call_number] > [last_Call-ID:] > [last_CSeq:] > [last_Record-Route:] > Contact: <sip:9782060836@[local_ip]:[local_port]> > Content-Length: [len] > ]]> > </send> > <nop><action><log message=3D"sent OK."/></action></nop>=20 > <nop><action><log message=3D"CALL OVER."/></action></nop> > =20 > </scenario> > ---------------------------------------------------------------------- > -- > > ---------------------------------------------------------------------- > --- Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to share=20 > your opinions on IT & business topics through brief surveys -- and=20 > earn cash=20 > = http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEV > DEV > ---------------------------------------------------------------------- > -- > > _______________________________________________ > Sipp-users mailing list > Sip...@li... > https://lists.sourceforge.net/lists/listinfo/sipp-users > =20 |