15 Jun
2010
15 Jun
'10
4:44 p.m.
Hi All,
I have been in the lab testing various load balancing scenarios with
kamailio 1.5 and 3.0 and distributing calls to asterisk servers. I am
running into an issue that I'm sure is related to sipp not kamailio or
asterisk. My testing is setup like this:
sipp><kamailio stateful (dispatcher or carrierroute)><multiple asterisk
servers
My sipp scenario:
sipp -sn uac 10.10.12.22 -i 10.10.14.97 -s 22265 -d 5000 -l 100 -r 1
-trace_err -m 1 -nr
What I'm seeing in my ngrep sip traces is the ACK coming back from
sipp does not have the RR header or a proper ftag:
Here is the Ok sent from kamailio 10.10.12.22 to sipp 10.10.14.97:
U 10.10.12.22:5060 -> 10.10.14.97:5061
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 10.10.14.97:5061;branch=z9hG4bK-10002-1-0.
Record-Route: <sip:10.10.12.22;lr=on;ftag=10002SIPpTag001>.
From: sipp <sip:sipp@10.10.14.97:5061>;tag=10002SIPpTag001.
To: sut <sip:22265@10.10.12.22:5060>;tag=as18ae7aa7.
Call-ID: 1-10002(a)10.10.14.97.
CSeq: 1 INVITE.
User-Agent: Asterisk PBX.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces.
Contact: <sip:65@10.10.14.102>.
Content-Type: application/sdp.
Content-Length: 184.
.
v=0.
o=root 23641 23641 IN IP4 10.10.14.102.
s=session.
c=IN IP4 10.10.14.102.
t=0 0.
m=audio 24270 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.
Here is the reply ACK sent from sipp 10.10.14.97 to kamailio 10.10.12.22:
U 10.10.14.97:5061 -> 10.10.12.22:5060
ACK sip:22265@10.10.12.22:5060 SIP/2.0.
Via: SIP/2.0/UDP 10.10.14.97:5061;branch=z9hG4bK-10002-1-5.
From: sipp <sip:sipp@10.10.14.97:5061>;tag=10002SIPpTag001.
To: sut <sip:22265@10.10.12.22:5060>;tag=as18ae7aa7.
Call-ID: 1-10002(a)10.10.14.97.
CSeq: 1 ACK.
Contact: sip:sipp@10.10.14.97:5061.
Max-Forwards: 70.
Subject: Performance Test.
Content-Length: 0.
And the ACK goes into the to-tag portion of the kamailio route script
but can not match the transaction so kamailio exits, the dialog drops
out of memory and when sipp sends a BYE, kamailio replys with 404 not
found.
So if I'm diagnosing this correctly, sipp is not maintaining the
Record-Route: header in the responses back to kamailio and without
that info kamailio can not maintain transaction state and the call
fails. Is there any work around or possibly another SIP performance
testing suite that will handle RR headers?
Thanks.
JR
--
JR Richardson
Engineering for the Masses