Hello Andreas,
I already answered you about this three weeks ago (see attached e-mail)......Note that this change has been just been documented (see the keyword list http://sipp.sourceforge.net/doc/reference.html#Create+your+own+XML+scenarios) Regards, Olivier Boulkroune ________________________________ De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Andreas Byström Envoyé : mercredi 11 juillet 2007 00:32 À : [email protected] Objet : [Sipp-users] Branch on final response Looks like my SIPp script sets the wrong branch when I get a 407 response and tries to send an ACK on this final response, is this a know problem? The scenario is: * send invite * rec optional 100, 500, 503 * rec 407 * send ACK * send INVITE with digest info In the send ACK I have the following Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] From: <sip:[EMAIL PROTECTED]>;tag=[call_number] To: <sip:[EMAIL PROTECTED]>[peer_tag_param] but the ACK that is sent dont have the same branch as the first INVITE sent. This causes the receveing end to retransmit the 407. I did read in the forum that some time ago someone had a similar problem and he got the tip that he should remove the receiving of a 407 since branch would work ok for a ACK on an unexpected message. When doing this, sipp complains that I cant have optional responses only between the first and the second Invite Im using SIPp v2.0.1-TLS-PCAP, version 20070516, built May 16 2007, 11:06:11 Regards, // Andreas _______________________________ Andreas Byström Software Engineer Teligent AB Konsul Jonssons väg 17 P.O. Box 213 SE 14923 Nynäshamn mail: [EMAIL PROTECTED] web: www.teligent.se <http://www.teligent.se/> phone: +46 (0)8 4101 7221 mobile: +46 (0)733 1172 21 fax: +46 (0)8 520 193 36 _______________________________
--- Begin Message ---Thanks for your response Olivier Next time I will use the mailing list even though the thread is already present. Sorry to disturb you with an direct email // Andreas -----Original Message----- From: Boulkroune, Olivier (Non-HP:Atos Origin) [mailto:[EMAIL PROTECTED] Sent: Thursday, June 21, 2007 9:28 AM To: Andreas Byström Cc: [email protected] Subject: RE: ACK problem using sipp Hello Andreas, Please no direct e-mails - use the sipp-users mailing-list. A fix (not yet documented) has been provided in the mean time. You can now append an offset to the branch, like [branch-1], in order to keep it correct even in particular cases such as ACK answering to >= 400 responses. Regards, Olivier Boulkroune _____ De : Andreas Byström [mailto:[EMAIL PROTECTED] Envoyé : jeudi 21 juin 2007 00:03 À : Boulkroune, Olivier (Non-HP:Atos Origin) Objet : ACK problem using sipp Hi Olivier, sorry to disturb you this way but I found an mail in the sipp user mail archive and I'm not really sure on if it is possible to mail a answer from the archive. And since there already where a thread started I felt that I should starta a new one (thats why I first looked in the archive) Anyway, the mail I saw that you answered on was about that there was a fix that made an automatic ACK on a 4xx response to contain the correct branch (I have copied the mail below). Your answer was that the one that had the problem did in fact not use an automatic 4xx, instead it was in the xml file. Your suggestion was to remove it from the xml file. Are you saying that the ack dont work if you specify a 4xx in the scenario? I have the same problem (but instead of getting 4xx I get 5xx and the ACK is wrong) and I would like to keep the 5xx in the scenario since I want to see what happens in runtime. So, I have to live with ACK being incorrect in case I want to have 5xx in my scenario (and therefore in the output) Regards, // Andreas Hello Pat, The fix you mentioned concerned automatic ACK sent by SIPp as an answer to unexpected responses, which is not the case here because you put the 486 response in your scenario (therefore, it is not treated as unexpected). It will work if you remove it. Regards,=20 Olivier Boulkroune =20 Message: 5 Date: Mon, 7 May 2007 08:32:02 -0600 From: Pat Callahan <[EMAIL PROTECTED]> Subject: [Sipp-users] ACK branch value for 4xx responses still broke? To: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=3D"iso-8859-1" Hi: =20 I have read in the release notes that there was a fix in 2.0 for the branch value in the Via header of an ACK to a 4xx response to make it be identical to the branch value in the via header of the original INVITE, but I'm not seeing that behavior. Here is the language in the release notes: =20 Fix: Incorrect branch in automatic ACK answering to unexpected >=3D 400 responses,as well as automatic CANCEL - in such cases, branch must be identical to thebranch of the initial INVITE request Here is the trace_msg output from version 2.0: =20 ----------------------------------------------- 2007-05-07 07:49:07UDP message sent: INVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0Via: SIP/2.0/UDP 1.20.39.34:5060;branch=3Dz9hG4bK-10660-1-0From: sipp <sip:[EMAIL PROTECTED]:5060>;tag=3D1To: sut <sip:[EMAIL PROTECTED]:5060>Call-ID: [EMAIL PROTECTED]: 1 INVITEContact: sip:[EMAIL PROTECTED]:5060Max-Forwards: 70Subject: Performance TestContent-Type: application/sdpContent-Length: 131 v=3D0o=3Duser1 53655765 2353687637 IN IP4 1.20.39.34s=3D-c=3DIN IP4 1.20.39.34t=3D0 0m=3Daudio 6000 RTP/AVP 0a=3Drtpmap:0 PCMU/8000 ----------------------------------------------- 2007-05-07 07:49:07UDP message received [259] bytes : SIP/2.0 100 TryingVia: SIP/2.0/UDP 1.20.39.34:5060;branch=3Dz9hG4bK-10660-1-0From: sipp <sip:[EMAIL PROTECTED]:5060>;tag=3D1To: sut <sip:[EMAIL PROTECTED]:5060>;tag=3DgK0281ebc9Call-ID: [EMAIL PROTECTED]: 1 INVITEContent-Length: 0 ----------------------------------------------- 2007-05-07 07:49:07UDP message received [262] bytes : SIP/2.0 486 Busy HereVia: SIP/2.0/UDP 1.20.39.34:5060;branch=3Dz9hG4bK-10660-1-0From: sipp <sip:[EMAIL PROTECTED]:5060>;tag=3D1To: sut <sip:[EMAIL PROTECTED]:5060>;tag=3DgK0281ebc9Call-ID: [EMAIL PROTECTED]: 1 INVITEContent-Length: 0 ----------------------------------------------- 2007-05-07 07:49:07UDP message sent: ACK sip:[EMAIL PROTECTED]:5060 SIP/2.0Via: SIP/2.0/UDP 1.20.39.34:5060;branch=3Dz9hG4bK-10660-1-3From: sipp <sip:[EMAIL PROTECTED]:5060>;tag=3D1To: sut <sip:[EMAIL PROTECTED]:5060>;tag=3DgK0281ebc9Call-ID: [EMAIL PROTECTED]: 1 ACKMax-Forwards: 70Content-Length: 0 =20 Here is the scenario that was used: =20 <scenario name=3D"Basic Sipstone UAC"> <!-- In client mode (sipp = placing calls), the Call-ID MUST be --> <!-- generated by sipp. To do so, use [call_id] keyword. --> <send retrans=3D"500"> <![CDATA[ INVITE sip:[EMAIL PROTECTED]:[remote_port] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=3D[branch] From: sipp <sip:[EMAIL PROTECTED]:[local_port]>;tag=3D[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: [len] v=3D0 o=3Duser1 53655765 2353687637 IN IP[local_ip_type] [local_ip] s=3D- c=3DIN IP[media_ip_type] [media_ip] = t=3D0 0 m=3Daudio [media_port] RTP/AVP 0 a=3Drtpmap:0 PCMU/8000 ]]> </send> <recv response=3D"100" optional=3D"true"> </recv> <recv response=3D"486" rrs=3D"true"> </recv> <!-- By adding rrs=3D"true" (Record Route Sets), the route sets --> <!-- are saved and used for following messages sent. Useful to test --> <!-- against stateful SIP proxies/B2BUAs. --> <!-- Packet lost can be simulated in any send/recv message by --> <!-- by adding the 'lost =3D "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];branch=3D[branch] From: sipp <sip:[EMAIL PROTECTED]:[local_port]>;tag=3D[call_number] To: sut <sip:[EMAIL PROTECTED]:[remote_port]>[peer_tag_param] Call-ID: [call_id] CSeq: 1 ACK Max-Forwards: 70 Content-Length: 0 ]]> </send> <!-- This delay can be customized by the -d command-line option --> <!-- or by adding a 'milliseconds =3D "value"' option here. --> <pause/> <!-- The 'crlf' option inserts a blank line in the statistics report. --> <!-- definition of the response time repartition table (unit is ms) --> <ResponseTimeRepartition value=3D"10, 20, 30, 40, 50, 100, 150, 200"/> <!-- definition of the call length repartition table (unit is ms) --> <CallLengthRepartition value=3D"10, 50, 100, 500, 1000, 5000, 10000"/> </scenario>
--- End Message ---
------------------------------------------------------------------------- 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
