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
15 Jun
15 Jun
4:57 p.m.
1) AFAIK, the Record-Route/Route headers are used by TM for maintaining
transaction state, unless you are relying on the 'dialog' module's "fast
matching" cookies, which are identifiers that get placed as a URI
parameter into the Record-Route header so that it is not necessary to
match the message by more conventional means (Via/branch, Call-ID, tags,
etc.)
2) ACK is a separate transaction; every request and reply sequence is a
transaction. So, if you're trying to match it to an existing INVITE
transaction, for instance, that won't happen.
t_check_trans() has special behaviour for ACKs, depending on whether
they're end-to-end ACKs or ACKs for negative replies to existing
transactions:
http://www.kamailio.org/docs/modules/3.0.x/modules/tm.html#t_check_trans
Are you sure that you're using it, or its newer variant,
t_lookup_request(), correctly?
3) You are, nevertheless, correct that the ACK should contain the RR header:
The UAC core MUST generate an ACK request for each 2xx received from
the transaction layer. The header fields of the ACK are constructed
in the same way as for any request sent within a dialog (see Section
12) with the exception of the CSeq and the header fields related to
authentication.
-- Alex
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
4:58 p.m.
On 06/15/2010 04:57 PM, Alex Balashov wrote:
* are NOT used.
----
1) AFAIK, the Record-Route/Route headers are used by
TM for maintaining
transaction state, unless you are relying on the 'dialog' module's
"fast
matching" cookies, which are identifiers that get placed as a URI
parameter into the Record-Route header so that it is not necessary to
match the message by more conventional means (Via/branch, Call-ID, tags,
etc.)
2) ACK is a separate transaction; every request and reply sequence is a
transaction. So, if you're trying to match it to an existing INVITE
transaction, for instance, that won't happen.
t_check_trans() has special behaviour for ACKs, depending on whether
they're end-to-end ACKs or ACKs for negative replies to existing
transactions:
http://www.kamailio.org/docs/modules/3.0.x/modules/tm.html#t_check_trans
Are you sure that you're using it, or its newer variant,
t_lookup_request(), correctly?
3) You are, nevertheless, correct that the ACK should contain the RR
header:
The UAC core MUST generate an ACK request for each 2xx received from
the transaction layer. The header fields of the ACK are constructed
in the same way as for any request sent within a dialog (see Section
12) with the exception of the CSeq and the header fields related to
authentication.
-- Alex
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
5309
days inactive
5309
days old
2 comments
2 participants
participants (2)
-
Alex Balashov -
JR Richardson