[SR-Users] Re: Need guidance on Teams interop with Kamailio
Your Kamailio is using the RURI for routing the BYE and not RR header.
My tip is to xlog your Kamailio config in order to see if the subsequent BYE
request will run the loose_route function inside your route[WITHINDLG].
if (loose_route()) {
if (is_method("BYE")) {
xlog("L_INFO","Running loose route for subsequent BYE request from $si : $sp
\n");
}
I also recommend not to remove any record route headers when engaging with MS
Teams - so do not remove any RR header and make sure your FreePBX include
record route header originally received from Teams.
Regarding the call disconnect: Might be that the corresponding ACK or the 200
OK (depending on Teams being UAC/UAS`) is not handled from MS Teams side.
Again, make sure not to replace to much of the headers received from Teams
apart from what is mentioned in the MS Teams Kamailio guide.
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] Kamailio closing tcp connection on downstream responses
Trying to setup Kamailio with MS Teams Direct Routing.
I am familiar with the integration steps required by Microsoft (using contact
header as FQDN, certified CA for certificate) aswell as the famous guide;
https://skalatan.de/en/blog/kamailio-sbc-teams +
https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip
Sending any SIP requests (Invite, ACK, BYE) toward MS is working fine (with
provisional response received in Kamailio) - so there is obviously a working
connection between Kamailio <-> MS Direct Routing environment.
HOWEVER, once Kamailio is forwarding SIP responses to MS (provisional
responses/200 OK received from UAS), then Kamailio is closing the TCP
connection.
Please see attached logs below.
Any idea why Kamailio is closing the connection when trying to send provisional
responses to MS?
- Using t_realy on original invite from MS
- tcp_reuse_port=yes, tcp_rd_buf_size = 16384, tcp_connection_lifetime=3605,
children=8, socket_workers=4
- No override rules in firewall
- OS; debian:11.7
- Notice that TLS connection is made on port :26627 - however, MS sends port
:5061 in VIA header (on first Invite). This seems to me to be a conflict in
ports.
https://www.kamailio.org/wiki/cookbooks/5.4.x/core#reply_route
"There is no network route that can be enforced for a SIP reply - it is sent
based on Via header, according to SIP RFC3261"
-
Handshake complete for 52.114.76.76:26627
19(43) DEBUG: tls [tls_domain.c:818]: sr_ssl_ctx_info_callback(): SSL handshake
done
19(43) DEBUG: tls [tls_server.c:473]: tls_accept(): TLS accept successful
19(43) DEBUG: tls [tls_server.c:476]: tls_accept(): tls_accept: new connection
from 52.114.76.76:26627 using TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256
19(43) DEBUG: tls [tls_server.c:480]: tls_accept(): tls_accept: local socket:
10.129.0.91:5061
19(43) DEBUG: tls [tls_server.c:420]: tls_dump_cert_info(): tls_accept: client
certificate subject:/C=US/ST=WA/L=Redmond/O=Microsoft
Corporation/CN=sip.pstnhub.microsoft.com
19(43) DEBUG: tls [tls_server.c:424]: tls_dump_cert_info(): tls_accept: client
certificate issuer:/C=US/O=Microsoft Corporation/CN=Microsoft Azure RSA TLS
Issuing CA 04
-
Kamailio trying to forward SIP response "183" to MS (response received from
UAS).
Kamailio finds active connection by ID 13 / 0x7f4ecad0be08
20(44) DEBUG: {2 1 INVITE e926eb82d1a25bdc9ba03048cdbc5c77}
[core/tcp_main.c:1722]: _tcpconn_find(): found connection by id: 13
20(44) DEBUG: {2 1 INVITE e926eb82d1a25bdc9ba03048cdbc5c77}
[core/tcp_main.c:2627]: tcpconn_send_put(): tcp connection found
(0x7f4ecad0be08), acquiring fd
20(44) DEBUG: {2 1 INVITE e926eb82d1a25bdc9ba03048cdbc5c77}
[core/tcp_main.c:2637]: tcpconn_send_put(): c=0x7f4ecad0be08, n=16
23(47) DEBUG: [core/tcp_main.c:3982]: handle_ser_child(): read response=
7f4ecad0be08, 2, fd -1 from 20 (44)
20(44) DEBUG: {2 1 INVITE e926eb82d1a25bdc9ba03048cdbc5c77}
[core/tcp_main.c:2665]: tcpconn_send_put(): after receive_fd: c= 0x7f4ecad0be08
n=8 fd=12
20(44) DEBUG: {2 1 INVITE e926eb82d1a25bdc9ba03048cdbc5c77}
[core/tcp_main.c:2842]: tcpconn_do_send(): sending...
20(44) DEBUG: {2 1 INVITE e926eb82d1a25bdc9ba03048cdbc5c77}
[core/tcp_main.c:2878]: tcpconn_do_send(): after real write: c= 0x7f4ecad0be08
n=1191 fd=12
-
Kamailio immediately closes the connection due to EOF.
19(43) DEBUG: [core/tcp_read.c:280]: tcp_read_data(): EOF on connection
0x7f4ecad0be08 (state: 0, flags: 4018) - FD 10, bytes 0, rd-flags 1
([52.114.76.76]:26627 -> [52.114.76.76]:5061)19(43) DEBUG:
[core/tcp_read.c:1544]: tcp_read_req(): EOF
19(43) DEBUG: [core/io_wait.h:597]: io_watch_del(): DBG: io_watch_del
(0x555b3cf20260, 10, -1, 0x10) fd_no=2 called
19(43) DEBUG: [core/tcp_read.c:1927]: handle_io(): removing from list
0x7f4ecad0be08 id 13 fd 10, state 2, flags 4018, main fd 57, refcnt 2
([52.114.76.76]:26627 -> [52.114.76.76]:5061)
19(43) DEBUG: [core/tcp_read.c:1702]: release_tcpconn(): releasing con
0x7f4ecad0be08, state -1, fd=10, id=13 ([52.114.76.76]:26627 ->
[52.114.76.76]:5061)
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] Release_tcpconnection when using RTJSON routing with TLS
Hello, I wish to use RTJSON for routing inbound calls from Kamailio to external
endpoint(s), based on JSON received from my API.
My rtjson setup is based on guide below, with my route(RELAY) sending Invite
via t_relay();
https://wazo-platform.org/blog/kamailio-routing-with-rtjson-and-http-async-client
I am including rtjson_init_routes("$var(rtjson)");, rtjson_push_routes(); &
rtjson_update_branch(); in my routes.
Also have defined: listen=tls:10.129.1.168:5061 advertise ${PUBLIC_IPV4}:5061
Routing from rtjson is working fine for TCP / UDP connections, however - once I
try to forward an INVITE via rtjson using TLS, then the TLS connection is
simply closed with Kamailio reporting "tcp_read_data(): EOF on connection".
Please see logs and setup below.
- tcp_reuse_port = yes, tcp_children = 8, tcp_accept_no_cl= yes &
tcp_connection_lifetime=3605
- Also no success with tcp_reuse_port = no
- I have HOMER setup and see here that SIP headers from the RTJSON is being
used (Outbound SIP Invites is being duplicated to HOMER before connection is
released)
- I see no drop in traffic from my firewall
As you can see from logs below, Kamailio is reusing the socket (0x7fc3ebc65060)
from the exsisting connection (not new socket 0x7fc3ef70aab0).
I am sending SIP Options toward the external endpoint (which is working fine),
and my theory is that Kamailio is reusing the exisitng SIP OPTIONS tcp
connection for the SIP INVITE and somehow close the connection when RTJSON is
used (since routing without RTJSON is working fine).
Any idea how to solve this?
Thank you!
(x.x.x.x:5061 is external endpoint)
14(43) DEBUG: rtjson [rtjson_routing.c:364]: rtjson_init_serial(): rewrite
dst-uri to: [sip:x.x.x.x:5061;transport=tls]
14(43) DEBUG: rtjson [rtjson_routing.c:388]: rtjson_init_serial(): trying to
set send socket to: [tls:10.129.1.168:5061]
14(43) DEBUG: [core/socket_info.c:726]: grep_sock_info(): checking if
host==us: 12==12 && [10.129.1.168] == [10.129.1.168]
14(43) DEBUG: [core/socket_info.c:730]: grep_sock_info(): checking if
port 5061 (advertise 5061) matches port 5061
.
14(43) DEBUG: tm [../../core/forward.h:276]: msg_send_buffer(): sending to:
x.x.x.x:5061, force_socket=4, send_sock=0x7fc3ef70aab0
14(43) DEBUG: [core/tcp_main.c:1741]: _tcpconn_find(): found connection
by peer address (id: 9)
14(43) DEBUG: [core/tcp_main.c:2627]: tcpconn_send_put(): tcp connection
found (0x7fc3ebc65060), acquiring fd
14(43) DEBUG: [core/tcp_main.c:2637]: tcpconn_send_put():
c=0x7fc3ebc65060, n=16
23(52) DEBUG: [core/tcp_main.c:3982]: handle_ser_child(): read response=
7fc3ebc65060, 2, fd -1 from 14 (43)
14(43) DEBUG: [core/tcp_main.c:2665]: tcpconn_send_put(): after
receive_fd: c= 0x7fc3ebc65060 n=8 fd=20
14(43) DEBUG: [core/tcp_main.c:2842]: tcpconn_do_send(): sending...
14(43) DEBUG: [core/tcp_main.c:2878]: tcpconn_do_send(): after real
write: c= 0x7fc3ebc65060 n=1372 fd=20
14(43) DEBUG: [core/tcp_main.c:2879]: tcpconn_do_send(): buf=
.
23(52) DEBUG: [core/tcp_main.c:4671]: handle_tcpconn_ev(): sending to
child, events 2001
23(52) DEBUG: [core/tcp_main.c:4299]: send2child(): checking per-socket
generic workers (48/19..-1828836960/21964) [tls:10.129.1.168:5061]
23(52) DEBUG: [core/tcp_main.c:4326]: send2child(): WARNING: no free tcp
receiver, connection passed to the least busy one (idx:0 busy:2)
23(52) DEBUG: [core/tcp_main.c:4330]: send2child(): selected tcp worker
idx:0 proc:19 pid:48 for activity on [tls:10.129.1.168:5061], 0x7fc3ebc65060
19(48) DEBUG: [core/tcp_read.c:1782]: handle_io(): received n=8
con=0x7fc3ebc65060, fd=14
19(48) DEBUG: [core/tcp_read.c:280]: tcp_read_data(): EOF on connection
0x7fc3ebc65060 (state: 0, flags: 118) - FD 14, bytes 0, rd-flags 1
([x.x.x.x]:5061 -> [x.x.x.x]:5061)19(48) DEBUG: [core/tcp_read.c:1544]:
tcp_read_req(): EOF
19(48) DEBUG: [core/tcp_read.c:1702]: release_tcpconn(): releasing con
0x7fc3ebc65060, state -1, fd=14, id=9 ([x.x.x.x]:5061 -> [x.x.x.x]:5061)
19(48) DEBUG: [core/tcp_read.c:1705]: release_tcpconn(): extra_data
0x7fc3ebc305b0
23(52) DEBUG: [core/tcp_main.c:3744]: handle_tcp_child(): reader
response= 7fc3ebc65060, -1 from 0
23(52) DEBUG: [core/tcp_main.c:3668]: tcp_emit_closed_event(): TCP
closed event creation triggered (reason: 0)
23(52) DEBUG: [core/tcp_main.c:3676]: tcp_emit_closed_event(): no
callback registering for handling TCP closed event
23(52) DEBUG: tls [tls_server.c:732]: tls_h_tcpconn_close_f(): Closing SSL
connection 0x7fc3ebc305b0
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
