Just to add for a history.
I've found that Asterisk normally accepts sips schema over UDP and keeps
sending responses regardless on schema specified also in UDP.
So, in my case only thing that was needed is to change the $du, smth like
request_route{
...
if (is_method("CANCEL")) {
if (t_check_trans()) {
route(SIPS_PROCESS);
if (!t_relay()) {
send_reply("500", "Relay failed");
}
}
exit;
}
}
route[RELAY] {
route(SIPS_PROCESS);
t_relay();
}
route[SIPS_PROCESS] {
# If device is using "sips:" dialing scheme, force it with $du
pointing to "sip:" scheme
# so Kamailio will not try to send it over TLS to internal services.
# Applies to requests coming FROM external devices, like Poly OBI ATA's
if (route(FROMASTERISK)) {
return;
}
if ($du == $null && $rz != 'sips') {
return;
}
if ($du != $null) {
if ($(du{uri.scheme}) == 'sips') {
xlog("$var(debug_level)", "[SIPS_PROCESS]: Modifying <$du>
to sip scheme");
$du = 'sip:' + $dd + ':' + $dp;
}
return;
}
if ($rz != 'sips') {
return;
}
$du = 'sip:' + $rd + ':' + $rp;
xlog("$var(debug_level)", "[SIPS_PROCESS]: Setting <$du> for packet
to <$ru> to avoid sips routing");
}
Le 22/11/2023 à 01:53, David Villasmil via sr-users a écrit :
thanks all, i figured it out with help from Alfonso who found
https://github.com/fredposner/scripts/blob/master/kamailio/kamailio-tls_srtp-bridge.cfg
Regards,
David Villasmil
email: david.villasmil.w...@gmail.com
phone: +34669448337
On Tue, Nov 21, 2023 at 2:34 PM Henning Westerholt <h...@gilawa.com> wrote:
Hi David,
at least from the logs the dialog is matched:
DEBUG: dialog [dlg_hash.c:885]: internal_get_dlg(): dialog
callid='aa157c08df1109c4655ca64d0ed67' found on entry 1431, dir=2
to-tag='ZDDN09pNH37XB'
DEBUG: dialog [dlg_profile.c:541]: set_current_dialog(): setting
current dialog [1431:511]
DEBUG: dialog [dlg_handlers.c:343]: dlg_iuid_sfree(): freeing dlg
iuid [3314:1253] (0x7f6d9b2afe20)
DEBUG: dialog [dlg_hash.c:1293]: next_state_dlg(): dialog
0x7f6d9b2f8240 changed from state 5 to state 5, due event 7 (ref 2)
The dialog is already deleted at this point, not sure why.
Please note that your rewrite method can cause problems in
dialogs, as for example the From/To header will be not matching to
the expectations of the UAs. Consider using the methods I
mentioned earlier to prevent this.
Cheers,
Henning
*From:*David Villasmil <david.villasmil.w...@gmail.com>
*Sent:* Dienstag, 21. November 2023 13:58
*To:* Henning Westerholt <h...@gilawa.com>
*Cc:* Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org>
*Subject:* Re: [SR-Users] sips to sip
thanks Henning,
Already tried that with:
if (is_method("INVITE")) {
$var(fline) = $msg(fline);
$var(hdrs) = $msg(hdrs);
$var(body) = $msg(body);
$var(fline) = $(var(fline){s.replace,sips,sip});
#{s.replace,;transport=TLS,}{s.replace,;transport=tls,});
$var(hdrs) = $(var(hdrs){s.replace,sips,sip});
#{s.replace,;transport=TLS,}{s.replace,;transport=tls,});
$var(body) = $(var(body){s.replace,sips,sip});
#{s.replace,;transport=TLS,}{s.replace,;transport=tls,});
msg_set_buffer("$var(fline)\r\n$var(hdrs)\r\n\r\n$var(body)");
msg_apply_changes();
}
but then the BYE doesn't work, kamailio can't match it to a dialog
2023/11/21 12:48:41.962062 FREESWITCH-IP:5080 -> 10.0.3.141:5060
<http://10.0.3.141:5060>
BYE sip:+FROM-NUMBER@CLIENT-IP;transport=TLS SIP/2.0
Via: SIP/2.0/UDP FREESWITCH-IP:5080;rport;branch=z9hG4bK34FNtg4e31B8K
Route: <sip:KAMAILIO-IP-INTERNAL:5060;r2=on;lr;did=389.b1e>
Route: <sip:KAMAILIO-IP-EXTERNAL;transport=tls;r2=on;lr;did=389.b1e>
Max-Forwards: 70
From: <sip:+TO-NUMBER@KAMAILIO-DOMAIN>;tag=133B764ZS9QvD
To: <sip:+FROM-NUMBER@CLIENT-IP>;tag=df6b235d
Call-ID: 75fc6fcaaa32bcd7655ca72452eac
CSeq: 75731668 BYE
User-Agent: C3S-v1.1
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE,
REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Reason: Q.850;cause=16;text="NORMAL_CLEARING"
Content-Length: 0
DEBUG: <core> [core/receive.c:392]: receive_msg(): --- received
sip message - request - call-id: [aa157c08df1109c4655ca64d0ed67] -
cseq: [75731561 BYE]
DEBUG: <core> [core/receive.c:263]: ksr_evrt_pre_routing(): event
route core:pre-routing not defined
DEBUG: <core> [core/receive.c:474]: receive_msg(): preparing to
run routing scripts...
ERROR: <script>: [RTPENGINE] BYE
DEBUG: <core> [core/parser/parse_hname2.c:314]:
parse_sip_header_name(): parsed header name [User-Agent] type 28
DEBUG: <core> [core/parser/parse_hname2.c:314]:
parse_sip_header_name(): parsed header name [Allow] type 21
DEBUG: <core> [core/parser/parse_hname2.c:314]:
parse_sip_header_name(): parsed header name [Supported] type 17
DEBUG: <core> [core/parser/parse_hname2.c:314]:
parse_sip_header_name(): parsed header name [Reason] type 54
DEBUG: <core> [core/parser/parse_hname2.c:314]:
parse_sip_header_name(): parsed header name [Content-Length] type 12
DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field():
content_length=0
DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field():
found end of header
DEBUG: pv [pv_core.c:1471]: pv_get_authattr(): no
[Proxy-]Authorization header
DEBUG: pv [pv_core.c:1471]: pv_get_authattr(): no
[Proxy-]Authorization header
DEBUG: htable [ht_var.c:83]: pv_set_ht_cell(): set value for
$sht(f2b=><null>::auth_count)
ERROR: <script>: [REQUEST]: aa157c08df1109c4655ca64d0ed67: got
BYE#012BYE sip:+FROM-NUMBER@CLIENT-IP;transport=TLS
SIP/2.0#015#012Via: SIP/2.0/UDP
FREESWITCH-IP:5080;rport;branch=z9hG4bK2UpvrNKB6rNNr#015#012Route:
<sip:KAMAILIO-IP:5060;r2=on;lr;did=795.ff1>#015#012Route:
<sip:KAMAILIO-PUBLIC-DOMAIN:5061;transport=tls;r2=on;lr;did=795.ff1>#015#012Max-Forwards:
70#015#012From:
<sip:+TO-NUMBER@KAMAILIO-DOMAIN>;tag=ZDDN09pNH37XB#015#012To:
<sip:+FROM-NUMBER@CLIENT-IP>;tag=a8379a09#015#012Call-ID:
aa157c08df1109c4655ca64d0ed67#015#012CSeq: 75731561
BYE#015#012User-Agent: C3S-v1.1#015#012Allow: INVITE, ACK, BYE,
CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER,
NOTIFY#015#012Supported: timer, path, replaces#015#012Reason:
Q.850;cause=16;text="NORMAL_CLEARING"#015#012Content-Length:
0#015#012#015#012
DEBUG: <core> [core/parser/parse_addr_spec.c:185]:
parse_to_param(): add param: tag=ZDDN09pNH37XB
DEBUG: <core> [core/parser/parse_addr_spec.c:904]:
parse_addr_spec(): end of header reached, state=29
DEBUG: dialog [dlg_hash.c:881]: internal_get_dlg(): ref dlg
0x7f6d9b2f8240 with 1 -> 2
DEBUG: dialog [dlg_hash.c:885]: internal_get_dlg(): dialog
callid='aa157c08df1109c4655ca64d0ed67' found on entry 1431, dir=2
to-tag='ZDDN09pNH37XB'
DEBUG: dialog [dlg_profile.c:541]: set_current_dialog(): setting
current dialog [1431:511]
DEBUG: dialog [dlg_handlers.c:343]: dlg_iuid_sfree(): freeing dlg
iuid [3314:1253] (0x7f6d9b2afe20)
DEBUG: dialog [dlg_hash.c:1293]: next_state_dlg(): dialog
0x7f6d9b2f8240 changed from state 5 to state 5, due event 7 (ref 2)
DEBUG: dialog [dlg_hash.c:1088]: dlg_unref_helper(): unref op on
0x7f6d9b2f8240 with 1 from dlg_hash.c:1106
DEBUG: dialog [dlg_hash.c:1092]: dlg_unref_helper(): unref dlg
0x7f6d9b2f8240 with 1 -> 1
DEBUG: maxfwd [mf_funcs.c:74]: is_maxfwd_present(): value = 70
DEBUG: sanity [sanity.c:253]: check_ruri_sip_version():
check_ruri_sip_version entered
DEBUG: sanity [sanity.c:277]: check_ruri_sip_version():
check_ruri_sip_version passed
DEBUG: sanity [sanity.c:285]: check_ruri_scheme():
check_ruri_scheme entered
DEBUG: sanity [sanity.c:304]: check_ruri_scheme():
check_ruri_scheme passed
DEBUG: sanity [sanity.c:326]: check_required_headers():
check_required_headers entered
DEBUG: sanity [sanity.c:349]: check_required_headers():
check_required_headers passed
DEBUG: sanity [sanity.c:518]: check_cseq_method():
check_cseq_method entered
DEBUG: sanity [sanity.c:552]: check_cseq_method():
check_cseq_method passed
DEBUG: sanity [sanity.c:562]: check_cseq_value(): check_cseq_value
entered
DEBUG: sanity [sanity.c:590]: check_cseq_value(): check_cseq_value
passed
DEBUG: sanity [sanity.c:600]: check_cl(): check_cl entered
DEBUG: sanity [sanity.c:625]: check_cl(): check_cl passed
DEBUG: sanity [sanity.c:638]: check_expires_value():
check_expires_value entered
DEBUG: sanity [sanity.c:674]: check_expires_value(): no expires
header found
DEBUG: sanity [sanity.c:771]: check_parse_uris(): check_parse_uris
entered
DEBUG: sanity [sanity.c:775]: check_parse_uris(): parsing ruri
DEBUG: sanity [sanity.c:788]: check_parse_uris(): looking up From
header
DEBUG: sanity [sanity.c:803]: check_parse_uris(): looking up To header
DEBUG: sanity [sanity.c:853]: check_parse_uris(): check_parse_uris
passed
DEBUG: sanity [sanity_mod.c:252]: w_sanity_check(): sanity checks
result: 1
DEBUG: <core> [core/msg_translator.c:161]: check_via_address():
(FREESWITCH-IP, FREESWITCH-IP, 0)
DEBUG: <core> [core/proxy.c:268]: mk_proxy(): doing DNS lookup...
DEBUG: siptrace [siptrace_hep.c:523]: pipport2su(): the port
string is 5080
DEBUG: siptrace [siptrace_hep.c:523]: pipport2su(): the port
string is 5060
DEBUG: <core> [core/proxy.c:268]: mk_proxy(): doing DNS lookup...
DEBUG: siptrace [siptrace_hep.c:185]: trace_send_hep3_duplicate():
setting up the socket_info
DEBUG: <core> [core/forward.c:176]: get_out_socket(): socket
determined: 0x7f6d9f91a280
DEBUG: <core> [core/socket_info.c:724]: grep_sock_info(): checking
if host==us: 13==10 && [CLIENT-IP] == [10.0.3.141]
DEBUG: <core> [core/socket_info.c:728]: grep_sock_info(): checking
if port 5060 (advertise 5060) matches port 5061
DEBUG: <core> [core/socket_info.c:724]: grep_sock_info(): checking
if host==us: 13==10 && [CLIENT-IP] == [10.0.3.141]
DEBUG: <core> [core/socket_info.c:728]: grep_sock_info(): checking
if port 5066 (advertise 5060) matches port 5061
DEBUG: <core> [core/socket_info.c:724]: grep_sock_info(): checking
if host==us: 13==10 && [CLIENT-IP] == [10.0.3.141]
DEBUG: <core> [core/socket_info.c:728]: grep_sock_info(): checking
if port 5666 (advertise 0) matches port 5061
DEBUG: <core> [core/socket_info.c:724]: grep_sock_info(): checking
if host==us: 13==10 && [CLIENT-IP] == [10.0.3.141]
DEBUG: <core> [core/socket_info.c:728]: grep_sock_info(): checking
if port 5061 (advertise 5061) matches port 5061
DEBUG: <core> [core/socket_info.c:750]: grep_sock_info(): checking
advertise if host==us: 13==22 && [CLIENT-IP] ==
[KAMAILIO-PUBLIC-DOMAIN]
DEBUG: <core> [core/name_alias.h:63]: grep_aliases(): matching
(0:CLIENT-IP:5061) vs. (3:ip-10-0-3-141.ec2.internal:5061)
DEBUG: <core> [core/name_alias.h:63]: grep_aliases(): matching
(0:CLIENT-IP:5061) vs. (2:ip-10-0-3-141.ec2.internal:5666)
DEBUG: <core> [core/name_alias.h:63]: grep_aliases(): matching
(0:CLIENT-IP:5061) vs. (2:ip-10-0-3-141.ec2.internal:5066)
DEBUG: <core> [core/name_alias.h:63]: grep_aliases(): matching
(0:CLIENT-IP:5061) vs. (1:ip-10-0-3-141.ec2.internal:5060)
DEBUG: <core> [core/name_alias.h:63]: grep_aliases(): matching
(0:CLIENT-IP:5061) vs. (0:KAMAILIO-PUBLIC-DOMAIN:0)
DEBUG: <core> [core/name_alias.h:63]: grep_aliases(): matching
(0:CLIENT-IP:5061) vs. (0:KAMAILIO-IP:0)
DEBUG: <core> [core/name_alias.h:63]: grep_aliases(): matching
(0:CLIENT-IP:5061) vs. (0:10.0.2.65:0 <http://10.0.2.65:0>)
DEBUG: <core> [core/name_alias.h:63]: grep_aliases(): matching
(0:CLIENT-IP:5061) vs. (0:domain.com:0 <http://domain.com:0>)
DEBUG: corex [corex_lib.c:199]: corex_check_self(): check self
for: 0:CLIENT-IP:5061
DEBUG: corex [corex_lib.c:227]: corex_check_self(): no match found
DEBUG: <core> [core/forward.c:449]: check_self(): host
(0:CLIENT-IP:5061) != me
Regards,
David Villasmil
email: david.villasmil.w...@gmail.com
phone: +34669448337
On Tue, Nov 21, 2023 at 8:54 AM Henning Westerholt <h...@gilawa.com>
wrote:
Hello,
if you like you can rewrite the respective headers to use only
sip uri scheme of course.
* Record-Route: ignore_sips in rr
* From/To: uac_replace_from/_to
* Contacts: textops etc..
Cheers,
Henning
*From:*David Villasmil via sr-users <sr-users@lists.kamailio.org>
*Sent:* Montag, 20. November 2023 19:44
*To:* Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org>
*Cc:* David Villasmil <david.villasmil.w...@gmail.com>
*Subject:* [SR-Users] sips to sip
Hello guys,
I have this setup where one side is TLS and the other UDP.
Normally this works fine, but we have this provider sending
sips as the schema everywhere (from, to, rr, contacts),
kamailio sends the same sips to the upstream usp freeswitch.
My problem is when FS sends back a 200OK and kamailio forwards
it back to the provider, the provider sends an ACK and
kamailio can't match it with the dialog and doesn't know where
to forward it.
i think this is happening because FS when is sees SIPS is
setting the contact port as 5081 instead of the usual 5080...
Regards,
David Villasmil
email: david.villasmil.w...@gmail.com
phone: +34669448337
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email tosr-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:
__________________________________________________________
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:
