Hi there,
I'm having an issue in a SBC (ACME) -> KAMAILIO -> Asterisk scenario with an
ACK that gets ignored in Kamailio because it does not match any transaction.
The INVITE coming from the SBC looks like this (only relevant headers and
hidden numbers for simplicity - SBC has IP .12 , Kamailio .30 and Asterisk .34)
INVITE sip:mynumber@10.15.1.30:5060 SIP/2.0
Via: SIP/2.0/UDP 10.15.1.12:5060;branch=z9hG4bKdd1m7b00aom47rggc700.1
To: <sip: mynumber@10.15.1.30:5060>
From: <sip:a-number@10.15.1.12;user=phone>;tag=SDkbo9901-42090
P-Asserted-Identity: <sip: a-number @10.15.1.12>
Call-ID: SDkbo9901-71a1d17456b829b4c422af61de9eee7e-ao32g50
CSeq: 1 INVITE
Contact: <sip:41754112601@10.15.1.12:5060;transport=udp>
And its forwarded to Asterisk with the Record-Route header:
INVITE sip: mynumber @10.15.1.30:5060 SIP/2.0
*Record-Route: <sip:10.15.1.30;lr=on;ftag=SDkbo9901-42090>
*Via: SIP/2.0/UDP
10.15.1.30;branch=z9hG4bK1c02.7dc1b94be22d8780df5141f9ba3c5b7b.0
Via: SIP/2.0/UDP 10.15.1.12:5060;branch=z9hG4bKdd1m7b00aom47rggc700.1
To: <sip:mynumber@10.15.1.30:5060>
From: <sip:a-number@10.15.1.12;user=phone>;tag=SDkbo9901-42090
P-Asserted-Identity: <sip:a-number@10.15.1.12>
Call-ID: SDkbo9901-71a1d17456b829b4c422af61de9eee7e-ao32g50
CSeq: 1 INVITE
Contact: <sip:a-number@10.15.1.12:5060;transport=udp>
Then, 200 OK from Asterisk:
SIP/2.0 200 OK
*Via: SIP/2.0/UDP
10.15.1.30;rport=5060;received=10.15.1.30;branch=z9hG4bK1c02.7dc1b94be22d8780df5141f9ba3c5b7b.0
Via: SIP/2.0/UDP 10.15.1.12:5060;branch=z9hG4bKdd1m7b00aom47rggc700.1
*Record-Route: <sip:10.15.1.30;lr;ftag=SDkbo9901-42090>
Call-ID: SDkbo9901-71a1d17456b829b4c422af61de9eee7e-ao32g50
From: <sip:a-number@10.15.1.12;user=phone>;tag=SDkbo9901-42090
To: <sip:mynumber@10.15.1.30>;tag=2e3c2071-c895-4069-afc2-37a19b20637a
CSeq: 1 INVITE
Server: Asterisk PBX 13.8.0
Contact: <sip:10.15.1.34:5060>
Which is sent to the SBC like this:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.15.1.12:5060;branch=z9hG4bKdd1m7b00aom47rggc700.1
*Record-Route: <sip:10.15.1.30;lr;ftag=SDkbo9901-42090>
Call-ID: SDkbo9901-71a1d17456b829b4c422af61de9eee7e-ao32g50
From: <sip:a-number@10.15.1.12;user=phone>;tag=SDkbo9901-42090
To: <sip:mynumber@10.15.1.30>;tag=2e3c2071-c895-4069-afc2-37a19b20637a
CSeq: 1 INVITE
Server: Asterisk PBX 13.8.0
Contact: <sip:10.15.1.34:5060>
And finally the SBC sends the ACK:
ACK sip:10.15.1.30:5060 SIP/2.0
Via: SIP/2.0/UDP 10.15.1.12:5060;branch=z9hG4bKdt7p9k00dounet8ic600.1
To: <sip:mynumber@10.15.1.30>;tag=2e3c2071-c895-4069-afc2-37a19b20637a
From: <sip:a-number@10.15.1.12;user=phone>;tag=SDkbo9901-42090
Call-ID: SDkbo9901-71a1d17456b829b4c422af61de9eee7e-ao32g50
CSeq: 1 ACK
Contact: <sip:a-number@10.15.1.12:5060;transport=udp>
*Route: sip:10.15.1.30;lr;ftag=SDkbo9901-42090
The problem: this ACK gets not retransmitted to Asterisk
At first, I thought it was some sanity check but after disabling that I
realized that it was in the WITHINDLG route.
For the incoming ACK I get in the logs:
Jun 8 11:56:47 tone-0866-fe-2-qa /usr/local/sbin/kamailio[53240]: ALERT:
<script>: Inside LOOSE route for ACK proto=UDP trans=4194304
from=sip:00754112601@10.15.1.12;user=phone
route=sip:10.15.1.30;lr;ftag=SDkbo9901-42090 src_ip=10.15.1.12
And once the ACK is ready to be sent to Asterisk, the Route header has been
removed and no Record-Route has been added so it fails.
Jun 8 11:56:44 tone-0866-fe-2-qa /usr/local/sbin/kamailio[53238]: INFO: rr
[rr_mod.c:402]: pv_get_route_uri_f(): No route header present.
Jun 8 11:56:44 tone-0866-fe-2-qa /usr/local/sbin/kamailio[53238]: ALERT:
<script>: ACK does not match transaction!! proto=UDP trans=4194304
from=sip:00754112601@10.15.1.12;user=phone route= src_ip=10.15.1.30
My WITHINDLG route looks like this:
# Handle requests within SIP dialogs
route[WITHINDLG] {
if (has_totag()) {
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
if (is_method("BYE")) {
xlog("L_ALERT","Inside LOOSE route\n");
setflag(FLT_ACC); # do accounting ...
setflag(FLT_ACCFAILED); # ... even if the transaction fails
}
if ( is_method("ACK") ) {
xlog("L_ALERT","Inside LOOSE route for ACK proto=$rP trans=$mf
from=$fu route=$route_uri src_ip=$si \n");
# ACK is forwarded statelessy
route(NATMANAGE);
}
route(RELAY);
} else {
if (is_method("SUBSCRIBE") && uri == myself) {
# in-dialog subscribe requests
route(PRESENCE);
exit;
}
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
# no loose-route, but stateful ACK;
# must be an ACK after a 487
# or e.g. 404 from upstream server
t_relay();
exit;
} else {
# ACK without matching transaction ... ignore and discard
xlog("L_ALERT","ACK does not match transaction!! proto=$rP
trans=$mf from=$fu route=$route_uri src_ip=$si \n");
exit;
}
}
sl_send_reply("404","Not here");
}
exit;
}
}
Thanks for reading this :) Any idea about how to validate the transaction?
t_check_trans is not being validated...
Cheers, Francisco.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
