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>
-------------------------------------------------------------------------
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
