Hi Folks,
I have a problem with To and From headers in 200 OK to BYE request. Their
URI is doubled when leaving Kamailio.
Incoming 200 OK:
From : <sip:00421111@IP_ADDRESS>;tag=as017a2986
To : <sip:00421222@IP_ADDRESS0>;tag=K7ryDgH2g7gFm
Outgoing 200 OK:
From : <sip:+421111@IP_ADDRESS><sip:+421111@IP_ADDRESS>;tag=as017a2986
To : <sip:+421222@IP_ADDRESS><sip:+421222@IP_ADDRESS>;tag=K7ryDgH2g7gFm
I'm using uac module to replace these headers in auto and dialog mode:
modparam("uac", "restore_mode", "auto")
modparam("uac", "restore_dlg", 1)
append_fromtag is also set:
modparam("rr", "append_fromtag", 1)
When I run kamailio in debug mode I can see the function
restore_uri_reply() is called twice:
.
.
.
0(3133) DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found
param type 234, <received> = <IP_ADDRESS>; state=6
0(3133) DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found
param type 232, <branch> = <z9hG4bK0bb8c5b2>; state=6
0(3133) DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found
param type 235, <rport> = <5060>; state=16
0(3133) DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of
header reached, state=5
0(3133) DEBUG: <core> [parser/msg_parser.c:513]: parse_headers():
parse_headers: Via found, flags=62
0(3133) DEBUG: <core> [parser/msg_parser.c:526]: parse_headers():
parse_headers: this is the second via
0(3133) DEBUG: <core> [parser/parse_addr_spec.c:176]: parse_to_param():
DEBUG: add_param: tag=teHD72X67aQUm
0(3133) DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec():
end of header reached, state=29
0(3133) DEBUG: <core> [parser/msg_parser.c:190]: get_hdr_field(): DEBUG:
get_hdr_field: <To> [60]; uri=[sip:421222@IP_ADDRESS:5060]
0(3133) DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG:
to body [<sip:421222@IP_ADDRESS:5060>]
0(3133) DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field():
get_hdr_field: cseq <CSeq>: <103> <BYE>
0(3133) DEBUG: tm [t_lookup.c:949]: t_reply_matching(): DEBUG:
t_reply_matching: hash 10806 label 0 branch 0
0(3133) DEBUG: tm [t_lookup.c:1004]: t_reply_matching(): DEBUG:
t_reply_matching: reply matched (T=0x220071b4)!
0(3133) DEBUG: tm [t_hooks.c:288]: run_trans_callbacks_internal(): DBG:
trans=0x220071b4, callback type 2, id 0 entered
0(3133) DEBUG: <core> [parser/parse_addr_spec.c:176]: parse_to_param():
DEBUG: add_param: tag=as46bccb83
0(3133) DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec():
end of header reached, state=29
0(3133) DEBUG: uac [replace.c:705]: restore_uri_reply(): removing
<<sip:00421111@IP_ADDRESS>>
0(3133) DEBUG: uac [replace.c:714]: restore_uri_reply(): inserting
<<sip:+421111@IP_ADDRESS>>
0(3133) DEBUG: uac [replace.c:705]: restore_uri_reply(): removing
<<sip:00421222@IP_ADDRESS>>
0(3133) DEBUG: uac [replace.c:714]: restore_uri_reply(): inserting
<<sip:+421222@IP_ADDRESS>>
0(3133) DEBUG: tm [t_hooks.c:288]: run_trans_callbacks_internal(): DBG:
trans=0x220071b4, callback type 2, id 0 entered
0(3133) DEBUG: uac [replace.c:705]: restore_uri_reply(): removing
<<sip:00421111@IP_ADDRESS>>
0(3133) DEBUG: uac [replace.c:714]: restore_uri_reply(): inserting
<<sip:+421111@IP_ADDRESS>>
0(3133) DEBUG: uac [replace.c:705]: restore_uri_reply(): removing
<<sip:00421222@IP_ADDRESS>>
0(3133) DEBUG: uac [replace.c:714]: restore_uri_reply(): inserting
<<sip:+421222@IP_ADDRESS>>
.
.
.
I think the problem is in registering a function restore_uris_reply() in
callbacks in functions (both in replace.c of uac module)
* void rr_checker(struct sip_msg *msg, str *r_param, void *cb_param)
* static void replace_callback(struct dlg_cell *dlg, int type, struct
dlg_cb_params *_params)
Both of these callbacks are registered for BYE and ACK requests (INVITE
request is using different callback), therefore running restore_uri_reply()
twice.
For testing purposes after I have removed the callback in rr_checker and
recompile the uac module, To and From headers were OK.
In my configuration I'm calling uac_replace_to in RELAY route:
route[RELAY]
{
if ( !has_totag() ) {
dlg_manage();
uac_replace_to("$ru");
}
if (!t_relay())
{
sl_reply_error();
}
}
So I think there is a bug in uac module, when one function is registered
twice in callbacks for NON-INVITE requests.
Or is there a problem with my configuration script?
Can anyone point me to the direction how to solve this issue?
Thank you
Efelin
Kamailio version: kamailio 4.4.0-dev6 (i386/linux) a66e22-dirty
Hello everyone!
Subj is an ethernal theme, I know, but odds are so that I just need to do
that.
I've configured UAC auth to successfully register and my route[PSTN] looks
like that
# check if PSTN GW IP is defined
if (strempty($sel(cfg_get.pstn.gw_ip))) {
xlog("SCRIPT: PSTN routing enabled but pstn.gw_ip not
defined\n");
return;
}
if !ds_is_from_list()
return;
# route to PSTN dialed numbers starting with '+' or '00'
# (international format)
# - update the condition to match your dialing rules for PSTN
routing
if(!($rU=~"^(\+|00)[1-9][0-9]{3,20}$"))
return;
if (strempty($sel(cfg_get.pstn.gw_port))) {
$ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip);
} else {
$ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip) + ":"
+ $sel(cfg_get.pstn.gw_port);
}
remove_hf("To");
insert_hf("To: <sip:$rU@sipprovider.com>\r\n", "Call-ID");
uac_replace_from("","sip:user@sipprovider.com");
route(RELAY);
exit;
On INVITE's I get 407 PROXY-AUTH, which are transfered to backend FS.
If I try to put
if ($T_reply_code == 401 or $T_reply_code == 407) {
xlog("L_NOTICE", "Remote asked for authentication");
uac_auth();
}
to MANAGE_FAILURE or MANAGE_REPLY route Kamailio can't start.
Is that even possible?
--
Alexandru Covalschi
ABRISS-Solutions
VoIP engineer and system administrator
phone: +37367398493
web: http://abs-telecom.com/
Hi guys,
I use kamailio with mysql. Some queries are huge and when I need to debug
something it takes a time, so the debbuging would be easier.
Is there any way how could I log all sql queries into a log file ?
Thanks,
John
What is the best way to find out address family (IPV4 or IPV6) of media in SDP?
My goal is to reject INVITEs which have different address families in headers
and SDP, i.e. IPv4 INVITE with IPv6 media address in SDP and vice versa.
I've installed Kamailio on 2 different servers.
They share the same PostgreSQL database for users etc.
I've setup a single domain, sip.my-domain.com, with latency responds to the
2 servers.
So a user will always land on the server with the fastest responds in a
respective area of the world.
However, it seems as if 2 users are registered on different Kamailio
servers - even though they share the same database - they cannot call each
other?
Have I misunderstood something?
I've enabled WITH_NAT.
I am facing an issue with kamailio 4.3.3 that is very similar to
http://lists.sip-router.org/pipermail/sr-users/2015-May/088195.html
Had someone found the solution or faced similar issue ?
Sometimes kamailio is receiving the message (check with wireshark, logs in
tcp) but the message is not handled nor relayed.
After a certain amount of time everything works fine.
I will do what as has been advised : enabling pike & check with gdb when it
appears.
thibault
hello how are you?
i have a problem using sipcapture module
i'm writing in postgres database some sip messages but the msg field is
stored ina strange format,
\x5349502f322e30203438372052657175657374205465726d696e61746
5640d0a5669613a205349502f322e302f5544502037392e3137302e36342e3136383a353038303b6272616e63683d7a39684734624b30583665375a70394e446533513b72656365697665643d37392e3137302e36342e3136383b72706f72743d353038300d0a5265636f72642d526f7574653a
203c7369703a3139302e3136362e3233322e3139333a393236323b7472616e73706f72743d7564703b6c723e2c3c7369703a37392e3137302e36382e3138363b6c723b667461673d394448397648374435444653653b6469643d3639612e616437393e0d0a43616c6c2d49443a2033323666333
037632d373138642d346164392d393234362d3333336432323466613439380d0a46726f6d3a2022313931373838393437363922203c7369703a31393137383839343736394037392e3137302e36342e3136383e3b7461673d394448397648374435444653650d0a546f3a203c7369703a313830
39323935373838374037392e3137302e36382e3138363a353036303b757365723d70686f6e653e3b7461673d736263303830367974646c746f6c302d43432d33300d0a435365713a20383338353333383820494e564954450d0a5761726e696e673a203339392031302e31382e352e363420225
353313230303031463135364c3934345b30303030305d2043616e63656c207265636569766564206f6e20696e697469616c20696e76697465220d0a436f6e74656e742d4c656e6774683a20300d0a0d0a
do you know how to configure it to see it in ascii?
thanks a lot and regards
david escartin
Reminder: speaker's deadline this Friday, 27 November at 23:59 UTC
We have already received several really exciting talk proposals
but there is still time for people to propose talks or encourage
friends or colleagues to speak.
Many other dev-rooms also have a deadline in the next few days and if
your topic is applicable to more than one dev-room, you are welcome
to make more than one submission. Please contact us or put a note in
the memo field at the top of the talk proposal if you do that.
All projects are encouraged to consider making a lightning talk too,
it is an excellent opportunity to get exposure for your project:
even though you only have 15 minutes, it can be a much larger and more
diverse audience than in some dev-rooms.
For full details, please see the call for papers:
http://danielpocock.com/fosdem-2016-free-rtc-dev-room-and-lounge
We invite all potential speakers and participants to discuss the selection
process and other aspects of FOSDEM on the Free-RTC mailing list:
https://lists.fsfe.org/mailman/listinfo/free-rtc
Hello,
Kamailio SIP Server v4.3.4 stable release is out.
This is a maintenance release of the latest stable branch, 4.3, that
includes fixes since release of v4.3.3. There is no change to database
schema or configuration language structure that you have to do on
previous installations of v4.3.x. Deployments running previous v4.x.x
versions are strongly recommended to be upgraded to v4.3.4.
For more details about version 4.3.4 (including links and guidelines to
download the tarball or from GIT repository), visit:
* http://www.kamailio.org/w/2015/11/kamailio-v4-3-4-released/
RPM, Debian/Ubuntu packages will be available soon as well.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda