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@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@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
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
On 06/15/2010 04:57 PM, Alex Balashov wrote:
* are NOT used.
----
- 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.)
- 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?
- 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 -
JR Richardson