sipp

I am sending an INVITE from SIPp (-sn uac) through a proxy, implemented on
top of SailFin. The request is:

INVITE sip:200@192.168.123.130:5060 SIP/2.0
Max-Forwards: 70
Subject: Performance Test
Content-Length: 129
Contact: <sip:sipp@127.0.0.1:6060>
To: "sut"<sip:200@192.168.123.130:5060>
Cseq: 1 INVITE
Via: SIP/2.0/UDP
127.0.0.1:6060;branch=z9hG4bK-1555-1-0;received=192.168.123.130
Content-Type: application/sdp
Call-Id: 1-1555@127.0.0.1
From: "sipp"<sip:sipp@127.0.0.1:6060>;tag=1555SIPpTag001

v=0
o=user1 53655765 2353687637 IN IP4 127.0.0.1
s=-
c=IN IP4 127.0.0.1
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000


The proxy pushes a route header and sends the request on to a UAS. The UAS
returns a 200, which the proxy duly sends back to SIPp:


SIP/2.0 200 OK
Record-Route: <sip:192.168.123.130:5060;fid=server_1;lr>
Content-Length: 12
Contact: <sip:192.168.229.1:5060;fid=server_1>
To: "sut"<sip:200@192.168.123.130:5060>;tag=fwcabyk1-m
Cseq: 1 INVITE
Via: SIP/2.0/UDP
127.0.0.1:6060;branch=z9hG4bK-1555-1-0;received=192.168.123.130
Content-Type: text/plain
From: "sipp"<sip:sipp@127.0.0.1:6060>;tag=1555SIPpTag001
Server: Glassfish_SIP_1.0.0
Call-Id: 1-1555@127.0.0.1


The correct behavior according to RFC 3261, 12.2.1.1, is to set the RURI of
the subsequent ACK to the value of the Contact header
(<sip:192.168.229.1:5060;fid=server_1>) and include a Route header
constructed from the routeset (in this case, from the Record-Route header
in the response (<sip:192.168.123.130:5060;fid=server_1;lr>)). This would
allow the proxy to correctly route the ACK. Unfortunately, SIPp sends an
utterly incorrect ACK:


ACK sip:200@192.168.123.130:5060 SIP/2.0
Max-Forwards: 68
Subject: Performance Test
Content-Length: 0
Contact: sip:sipp@127.0.0.1:6060
To: "sut"<sip:200@192.168.123.130:5060>;tag=fwcabyk1-m
Cseq: 1 ACK
Via: SIP/2.0/UDP
127.0.0.1:6060;branch=z9hG4bK-1555-1-5;received=192.168.123.130
Call-Id: 1-1555@127.0.0.1
From: "sipp"<sip:sipp@127.0.0.1:6060>;tag=1555SIPpTag001


which preserves none of the routing information already established in the
dialog. Myself and a SailFin engineer believe this to be a bug in SIPp's
UAC scenario.