On Mon, Jun 16, 2014 at 5:38 PM, Mordechay Kaganer <mkaganer(a)gmail.com>
wrote:
B.H.
Hello, all!
I'm trying to set up kamailio as a simple load balancer proxy between PSTN
gateway and a cluster of asterisk servers - rather common use case IMHO.
I'm completely new to kamailio.
I have started with the default kamailio.cfg that comes with Ubuntu
package and added the dispatcher module as described in the docs (
http://www.kamailio.org/docs/modules/4.0.x/modules/dispatcher.html).
At the end, i got this up and running, but with one exception: if incoming
call is not answered by the asterisk end (i.e. it is in ringing state), and
then the gateway sends CANCEL request, kamailio is unable to recognize the
transaction and is not forwarding the request to asterisk. The result is:
the call is left "dangling" in the PBX and is not properly hang up.
When the gateway sends CANCEL to kamailio, i get the following log
messages:
4(25442) DEBUG: tm [t_lookup.c:769]: t_lookupOriginalT(): DEBUG:
t_lookupOriginalT: searching on hash entry 31287
4(25442) DEBUG: tm [t_lookup.c:492]: matching_3261(): DEBUG: RFC3261
transaction matching failed
4(25442) DEBUG: tm [t_lookup.c:859]: t_lookupOriginalT(): DEBUG:
t_lookupOriginalT: no CANCEL matching found!
4(25442) DEBUG: tm [t_lookup.c:861]: t_lookupOriginalT(): DEBUG:
t_lookupOriginalT completed
4(25442) DEBUG: tm [tm.c:1039]: w_t_lookup_cancel(): lookup_original:
t_lookupOriginalT returned: (nil)
4(25442) ERROR: *** cfgtrace: c=[/etc/kamailio/kamailio.cfg] l=485 a=25
n=xdbg
4(25442) DEBUG: <script>: is_method(CANCEL): t_check_trans()==false
4(25442) ERROR: *** cfgtrace: c=[/etc/kamailio/kamailio.cfg] l=487 a=2
n=exit
The relevant script snippet is standard from the distro package:
# CANCEL processing
if (is_method("CANCEL"))
{
xdbg("is_method(CANCEL): entry");
if (t_check_trans()) {
xdbg("is_method(CANCEL): t_check_trans()==true");
route(RELAY);
} else {
xdbg("is_method(CANCEL): t_check_trans()==false");
}
exit;
}
How can i fix this?
Thanks!
Here is the INVITE packet header (the gateway here is actually another
asterisk box):
INVITE sip:0773176356@10.XXX.YYY.20:5080 SIP/2.0
Via: SIP/2.0/UDP 10.XXX.YYY.30:5060;branch=z9hG4bK04af8582
Max-Forwards: 70
From: "MK" <sip:548594119@10.XXX.YYY.30>;tag=as552bb907
To: <sip:0773176356@10.XXX.YYY.20:5080>
Contact: <sip:548594119@10.XXX.YYY.30:5060>
Call-ID: 56d55a7c1623a0983fb0bf3a57891d05@10.XXX.YYY.30:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX 11.7.0
Date: Mon, 16 Jun 2014 14:22:55 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 309
And here is the CANCEL request:
CANCEL sip:0773176356@10.XXX.YYY.20:5080 SIP/2.0
Via: SIP/2.0/UDP 10.XXX.YYY.30:5060;branch=z9hG4bK04af8582
Max-Forwards: 70
From: "MK" <sip:548594119@10.XXX.YYY.30>;tag=as552bb907
To: <sip:0773176356@10.XXX.YYY.20:5080>
Call-ID: 56d55a7c1623a0983fb0bf3a57891d05@10.XXX.YYY.30:5060
CSeq: 102 CANCEL
User-Agent: Asterisk PBX 11.7.0
Content-Length: 0
As far as i can see, branch, tag, call-id all match exactly. So why
t_check_trans() does not match the transaction? Also, the problem is only
with CANCEL, all other packets pass through properly.
--
משיח NOW!
Moshiach is coming very soon, prepare yourself!
יחי אדוננו מורינו ורבינו מלך המשיח לעולם ועד!