Module: sip-router
Branch: master
Commit: e5a1c6fc0d773d0b12286cae309566685a3eb846
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=e5a1c6f…
Author: Peter Dunkley <peter.dunkley(a)crocodile-rcs.com>
Committer: Peter Dunkley <peter.dunkley(a)crocodile-rcs.com>
Date: Thu May 17 22:33:06 2012 +0100
pkg/kamailio/fedora/f16: Added BoxGrinder appliance definition for a Fedora 16 Kamailio test machine
- BoxGrinder automatically creates up-to-date CentOS/Fedora/RHEL
appliances to a specified configuration. See
http://boxgrinder.org/ for more information.
- This configuration is the minimum required to test F16 Kamailio
3.3 RPMs.
- To build the appliance:
1) Install BoxGrinder: "yum install rubygem-boxgrinder-build" on
Fedora
2) Run BoxGrinder: "boxgrinder-build kamailio.appl"
- If you run BoxGrinder on a 32-bit host you get a 32-bit appliance.
- If you run BoxGrinder on a 64-bit host you get a 64-bit appliance
by default. You can create a 32-bit appliance on a 64-bit host by
using the command: "setarch i386 boxgrinder-build kamailio.appl"
- WARNING: This is an unsecure (no firewall, default password) and
minimal appliance. It is not suitable for actual deployment but
it does have all of the Kamailio Fedora RPM dependencies installed.
---
pkg/kamailio/fedora/f16/kamailio.appl | 37 +++++++++++++++++++++++++++++++++
1 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/pkg/kamailio/fedora/f16/kamailio.appl b/pkg/kamailio/fedora/f16/kamailio.appl
new file mode 100644
index 0000000..0b88d5a
--- /dev/null
+++ b/pkg/kamailio/fedora/f16/kamailio.appl
@@ -0,0 +1,37 @@
+name: "f16-kamailio-#BASE_ARCH#"
+summary: Fedora 16 for Installing Kamailio RPMs
+os:
+ name: fedora
+ version: 16
+ password: kamailio
+hardware:
+ memory: 1024
+ partitions:
+ "/":
+ size: 2
+packages:
+ - @core
+ - db4
+ - expat
+ - GeoIP
+ - glib
+ - hiredis
+ - json-c
+ - libconfuse
+ - libcurl
+ - libevent
+ - libpurple
+ - libxml2
+ - mod_perl
+ - mono-core
+ - mysql-libs
+ - net-snmp-agent-libs
+ - openldap
+ - openssl
+ - pcre
+ - postgresql-libs
+ - python
+ - radiusclient-ng
+ - sqlite
+ - unixODBC
+ - zlib
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#229 - ACK not in transaction when t_relay or t_check_trans
User who did this - Pawel Sternal (Sternik)
----------
Yes, when I set ack_report to 1, ACK is correctly matched. My fault is not to check in documentation.
About "Record-Route", again my fault, because I run "record_route()" if(!$tt). When we migrate kamailio 1.5 to 3.x we notice that !$tt must be change to $tt==$null. And this time I forgot about it, with another migration, and dump on not matched ACK. Again - my fault.
I tried to check another scenario A-> SER -> ASTERISK | ASTERISK -> SER -> PSTN simulation. We don't use here acc. In kamailio 1.5.2 (test_1.5.cap) I have in:
1 ACK:
May 17 14:48:20 gx00 /usr/sbin/kamailio[32283]: DBG:tm:t_newtran: transaction on entrance=0xffffffff
May 17 14:48:20 gx00 /usr/sbin/kamailio[32282]: DBG:core:parse_headers: flags=80
May 17 14:48:20 gx00 /usr/sbin/kamailio[32283]: DBG:core:parse_headers: flags=ffffffffffffffff
May 17 14:48:20 gx00 /usr/sbin/kamailio[32283]: DBG:core:parse_headers: flags=78
May 17 14:48:20 gx00 /usr/sbin/kamailio[32283]: DBG:tm:t_lookup_request: start searching: hash=5186, isACK=1
May 17 14:48:20 gx00 /usr/sbin/kamailio[32282]: DBG:core:print_rr_body: current rr is <sip:10.0.6.20:5060;ftag=4c30f07ddedec1e3o3;lr>
May 17 14:48:20 gx00 /usr/sbin/kamailio[32282]: DBG:core:print_rr_body: current rr is <sip:10.0.6.40;lr>
May 17 14:48:20 gx00 /usr/sbin/kamailio[32283]: DBG:core:parse_headers: flags=38
May 17 14:48:20 gx00 /usr/sbin/kamailio[32282]: DBG:core:print_rr_body: skipping 2 route records
May 17 14:48:20 gx00 /usr/sbin/kamailio[32283]: DBG:tm:t_lookup_request: RFC3261 ACK matched
May 17 14:48:20 gx00 /usr/sbin/kamailio[32282]: DBG:core:print_rr_body: out rr []
May 17 14:48:20 gx00 /usr/sbin/kamailio[32283]: DBG:tm:t_lookup_request: REF_UNSAFE: after is 1
May 17 14:48:20 gx00 /usr/sbin/kamailio[32282]: DBG:core:print_rr_body: we have 2 records
May 17 14:48:20 gx00 /usr/sbin/kamailio[32283]: DBG:tm:t_lookup_request: e2e proxy ACK found
May 17 14:48:20 gx00 /usr/sbin/kamailio[32282]: DBG:dialog:populate_leg_info: route_set , contact sip:NodesProdIn1@10.0.6.20:5062, cseq 102 and bind_addr udp:10.0.6.20:5060
May 17 14:48:20 gx00 /usr/sbin/kamailio[32283]: DBG:tm:t_newtran: building branch for end2end ACK
May 17 14:48:20 gx00 /usr/sbin/kamailio[32283]: DBG:tm:t_relay_to: forwarding ACK
2 ACK:
May 17 14:48:20 gx00 /usr/sbin/kamailio[32283]: DBG:tm:t_lookup_request: start searching: hash=5186, isACK=1
May 17 14:48:20 gx00 /usr/sbin/kamailio[32282]: DBG:core:print_rr_body: current rr is <sip:10.0.6.20:5060;ftag=4c30f07ddedec1e3o3;lr>
May 17 14:48:20 gx00 /usr/sbin/kamailio[32282]: DBG:core:print_rr_body: current rr is <sip:10.0.6.40;lr>
May 17 14:48:20 gx00 /usr/sbin/kamailio[32283]: DBG:core:parse_headers: flags=38
May 17 14:48:20 gx00 /usr/sbin/kamailio[32282]: DBG:core:print_rr_body: skipping 2 route records
May 17 14:48:20 gx00 /usr/sbin/kamailio[32283]: DBG:tm:t_lookup_request: RFC3261 ACK matched
May 17 14:48:20 gx00 /usr/sbin/kamailio[32282]: DBG:core:print_rr_body: out rr []
May 17 14:48:20 gx00 /usr/sbin/kamailio[32283]: DBG:tm:t_lookup_request: REF_UNSAFE: after is 1
May 17 14:48:20 gx00 /usr/sbin/kamailio[32282]: DBG:core:print_rr_body: we have 2 records
May 17 14:48:20 gx00 /usr/sbin/kamailio[32283]: DBG:tm:t_lookup_request: e2e proxy ACK found
May 17 14:48:20 gx00 /usr/sbin/kamailio[32282]: DBG:dialog:populate_leg_info: route_set , contact sip:NodesProdIn1@10.0.6.20:5062, cseq 102 and bind_addr udp:10.0.6.20:5060
May 17 14:48:20 gx00 /usr/sbin/kamailio[32283]: DBG:tm:t_newtran: building branch for end2end ACK
May 17 14:48:20 gx00 /usr/sbin/kamailio[32283]: DBG:tm:t_relay_to: forwarding ACK
This same scenario in kamailio 3.2.2 (test_3.2.cap):
1 ACK:
May 17 13:54:26 gx00 /usr/sbin/kamailio[13546]: DEBUG: tm [t_lookup.c:1379]: DEBUG: t_newtran: msg id=16134 , global msg id=16133 , T on entrance=0xffffffff
May 17 13:54:26 gx00 /usr/sbin/kamailio[13546]: DEBUG: tm [t_lookup.c:527]: t_lookup_request: start searching: hash=37195, isACK=1
May 17 13:54:26 gx00 /usr/sbin/kamailio[13546]: DEBUG: tm [t_lookup.c:485]: DEBUG: RFC3261 transaction matching failed
May 17 13:54:26 gx00 /usr/sbin/kamailio[13546]: DEBUG: tm [t_lookup.c:709]: DEBUG: t_lookup_request: no transaction found
May 17 13:54:26 gx00 /usr/sbin/kamailio[13546]: DEBUG: tm [t_funcs.c:315]: SER: forwarding ACK statelessly
2 ACK:
May 17 13:54:26 gx00 /usr/sbin/kamailio[13546]: DEBUG: tm [t_lookup.c:1379]: DEBUG: t_newtran: msg id=16134 , global msg id=16133 , T on entrance=0xffffffff
May 17 13:54:26 gx00 /usr/sbin/kamailio[13546]: DEBUG: tm [t_lookup.c:527]: t_lookup_request: start searching: hash=37195, isACK=1
May 17 13:54:26 gx00 /usr/sbin/kamailio[13546]: DEBUG: tm [t_lookup.c:485]: DEBUG: RFC3261 transaction matching failed
May 17 13:54:26 gx00 /usr/sbin/kamailio[13546]: DEBUG: tm [t_lookup.c:709]: DEBUG: t_lookup_request: no transaction found
May 17 13:54:26 gx00 /usr/sbin/kamailio[13546]: DEBUG: tm [t_funcs.c:315]: SER: forwarding ACK statelessly
:-)
----------
One or more files have been attached.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=229#comment647
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#229 - ACK not in transaction when t_relay or t_check_trans
User who did this - Daniel-Constantin Mierla (miconda)
----------
The ACK seems ok, can you get any debug info from the device not accepting the ACK?
ACK comes to kamailio and it is routed to callee, based on source IP and port of 200ok, because the callee is behind nat.
The code you are referring to I guess is the one related to matching ACK to an existing INVITE transaction, used for accounting purposes. But the ACK itself for a 200OK is a separate transaction, being a request within dialog and has to be routed base on Route header.
In the initial description of this item you say that Record-Route is added to ACK, I could not spot that in the trace you attached. Even it would be, that is a matter of config, transaction management/matching has nothing to do with Record-Route headers.
If you want to get ACK matched to INVITE transaction, set acc module to record the ACK events and try again to see if there is any difference.
Can you post the trace taken when using 1.5.x? I would like to see if there is any difference.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=229#comment646
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.