Hello,
I am using the presence_dialoginfo module on a stand alone presence
server. I have this :
if(is_method("PUBLISH"))
{
handle_publish();
t_release();
} else if( is_method("SUBSCRIBE"))
{
handle_subscribe();
t_release();
};
If the server does not have any status information, it will send out a
blank notify with a 0 content length. Is there anyway to tell Kamailio
to send an xml doc with status "terminated" if the server does not know
the status that was requested by the SUBSCRIBE?
Thanks,
David
Server :
version: kamailio 3.2.3 (x86_64/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled on 14:19:23 Apr 19 2012 with gcc 4.4.3
Hi,
we are thinking about switching from siptrace to sipcapture + HEP
encapsulation. Do you know some reasons why we should switch to
sipcapture or why we should not ? ;) We have multiple SIP proxies and
Cisco gateways. In earlier versions of kamailio was siptrace blocking,
that's why we started to looking for some other capturing mechanism. I
think now siptrace is buffered, so we are hesitating ..
Mino
is it possible to make rtpproxy to include both ipv4 and ipv6 address in
sdp?
if not, i don't see how ipv4/ipv6 bridging can be made to work when $rd
is domain name.
-- juha
I have sipcapture and siptrace setup on the same server using kamailio
3.4.0-dev4 and webhomer 3.3.0 setup to capture sip traffic from a
mirriored port on the LAN. Interface ETH1 is to capture and ETH0 is for
managment.
The sipcapture database is getting data put into it. I can log into
webhomer, but see no data in the graphes nor can I search. I have double
checked my database permissions and they seem to be set up correctly.
webserver is set up with:
Apache/2.2.16 (Debian)
PHP5
MYSQL
Json
phpmyadmin
Here is a copy of my kamailio.cfg and configuration.php
rev_dns=no
auto_aliases=no
debug=1
log_stderror=no
memdbg=5
memlog=5
log_facility=LOG_LOCAL0
fork=yes
children=5
/* uncomment the next line to disable TCP (default on) */
disable_tcp=yes
/* IP and port for HEP capturing) */
listen=udp:127.0.0.1:9060
mpath="/usr/local/lib/kamailio/modules_k/:/usr/local/lib/kamailio/modules/"
loadmodule "pv.so"
loadmodule "db_mysql.so"
loadmodule "sipcapture.so"
loadmodule "textops.so"
loadmodule "siptrace.so"
# ----- mi_fifo params -----
####### Routing Logic ########
modparam("sipcapture", "db_url", "mysql://openser:******@localhost/homerdb")
modparam("sipcapture", "capture_on", 1)
/* activate HEP capturing */
modparam("sipcapture", "hep_capture_on", 1)
/* IP to listen. Port/Portrange apply only on mirroring port capturing */
modparam("sipcapture", "raw_socket_listen", "10.0.0.0:5060-5080")
/* Name of interface to bind on raw socket */
modparam("sipcapture", "raw_interface", "eth1")
/* activate IPIP capturing */
#modparam("sipcapture", "raw_ipip_capture_on", 1)
/* My table name*/
modparam("sipcapture", "table_name", "sip_capture")
/* children for raw socket */
modparam("sipcapture", "raw_sock_children", 4)
/* insert delayed */
#modparam("sipcapture", "db_insert_mode", 1)
/* activate monitoring/mirroring port capturing. Linux only */
modparam("sipcapture", "raw_moni_capture_on", 1)
/* Promiscious mode RAW socket. Mirroring port. Linux only */
modparam("sipcapture", "promiscious_on", 1)
/* activate Linux Socket Filter (LSF/BPF) on mirroring interface. Linux
only */
#modparam("sipcapture", "raw_moni_bpf_on", 1)
/* sipcapture node */
modparam("sipcapture", "capture_node", "homer01")
# check IP and port of your capture node
modparam("siptrace", "duplicate_uri","sip:127.0.0.1:9060")
modparam("siptrace", "hep_mode_on", 1)
modparam("siptrace", "trace_to_database", 0)
modparam("siptrace", "trace_flag",22)
modparam("siptrace", "trace_on", 1)
# Main SIP request routing logic
# - processing of any incoming SIP request starts with this route
route {
sip_capture();
drop;
}
onreply_route {
sip_capture();
drop;
}
##################################
configuration.php
<?php
/*********************************************************************************/
/* Access db of homer */
define('HOST', "localhost");
define('PORT', 3306);
define('USER', "webhomer");
define('PW', "******");
define('DB', "web_homer");
/* Homer connection
* this user must have the same password for all Homer nodes
* please define all your nodes in homer_nodes table
*/
define('HOMER_HOST', "localhost"); /* DEFAULT. Don't forget insert this
host to your DB nodes table */
define('HOMER_PORT', 3306);
define('HOMER_USER', "openser");
define('HOMER_PW', "******");
define('HOMER_DB', "homerdb");
define('HOMER_TABLE', "sip_capture");
/*********************************************************************************/
/* webHomer Settings
* Adjust to reflect your system preferences
*/
define('PCAPDIR',"/var/www/webhomer/tmp/");
define('WEBPCAPLOC',"/webhomer/tmp/");
define('APIURL',"http://localhost");
define('APILOC',"/webhomer/api/");
/* INCLUDE preferences */
include("preferences.php");
?>
Hi,
I am trying to route SIP messages to a gateway. I am using SIP MESSAGE over
UDP as well as the MSILO module for storing messages for users that aren't
currently logged in. I have read through the Dynamic Routing module info
but am not able to determine the best way to accomplish the routing I
require. Our scenario is outlined below.
User A sends a message addressed to "sip:12345678900@mydomain.com"
Kamailio at mydomain.com checks if 12345678900 is a registered user in the
system.
If not, the message header is translated to
"sip:12345678900@gatewaydomain..com"
and forwarded.
Incoming messages need to be accepted from their IP as well.
It would also be useful if the address came as "sip:2345678900@mydomain.com"
could be translated to "sip:*1*2345678900@gatewaydomain.com".
Is there any built in functionality I can configure for this, or will this
need to be scripted?
Thanks,
Ed
Hello,
based on the outcome of the discussion carried in the thread:
http://lists.sip-router.org/pipermail/sr-users/2012-August/074480.html
I am looking again the clarify some aspects out there in the VoIP world.
So, as mainly dealing with proxy/sip signaling deployments, it's very
often to be the first one hit by support issues claiming things don't
work. Then you investigate and end up in conclusions like in the above
thread:
"The problem was at the SBC, __where I did not expect it__."
The underlined part heats me up a bit, because I never understood from
where it comes this perception that SBC is a MUST-TO-HAVE and the
PERFECT (never mistaken or breaking things) node in a VoIP networks.
To some extent, the SBC is just a very costly SIP ALG, and a SIP ALG is
there to break the things.
I don't want to start like a flame war, but is it something that I am
obviously missing in regards to what benefits a SBC can bring? I see
only inconveniences:
- another point of failure
- it is a b2bua, therefore very unlikely to offer the same performances
of a proxy
- if transcoding is needed, a media server can be used behind the proxy,
properly protected of attacks by the proxy and eventually deployed as a
farm load balanced by the proxy
- if topology hinding is wanted in the b2bua fashion (not the proxy
fashion with encoding headers), then the b2bua can be behind the proxy,
properly protected of attacks by the proxy and eventually deployed as a
farm load balanced by the proxy
- nat traversal was solved long time ago in proxy environment, being
scalable by deploying a farm of rtp proxy
I don't want to go to other features, including the transport layer,
it's a clear win of the proxy in my experience (ok, being deep involved
in this project).
Then, what makes the SBC so desirable in many companies/voip
deployments? If any SBC user here that can share, what was the reason to
buy such a device? Any conceptual functionality that cannot be achieved
with the proxy as the first hop in front of the (wild) clients?
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Hello,
One of my colleagues at Crocodile has been doing some testing with the
msrp module. With the auth change that was made yesterday, and the
updated configuration I put in the README example it seems to mostly
work. However, there is one set of scenarios relating to failure
REPORTs that don't seem to be possible with the current module.
RFC 4976 section 6.4.1 paragraph 3 states:
If the Failure-Report header is "yes" or "partial", and if there is a
problem processing the SEND request or if an error response is
received for that SEND request, then the relay MUST respond with an
appropriate error response in a REPORT back to the original source of
the message.
This means that when a SEND request that contains a Failure-Report:
header with value of "yes" or "partial" is relayed by Kamailio we need
to maintain some state so that when the TCP send fails, or we receive a
failure response from the next hop, Kamailio can generate and send a
REPORT. At the moment I don't think the msrp module has these
capabilities.
If the module is getting some re-work before the next release it would
be good to get this in there. I am quite happy to help out in any way I
can, but I am not sure of the best way to proceed with this.
Regards,
Peter
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
The marketing arm of the Kamailio project has without further discussion opened up a Twitter account for Kamailio, to support our web site news, G+ and Facebook pages. Feel free to contribute with case stories and news we can publish on the web site and follow up in the social media flow.
The twitter account is @kamailioproject - please follow it.
And yes, Kamailio is THE best thing since the invention of sliced bread!
This week's EXTRAORDINARY offer: Download TWO licenses of Kamailio for the same licensing cost as we've been offering for ONE license! And get an unlimited number of user licenses for your Kamailio SIP accounts!
Kamailio greetings! Have a great SIP weekend!
/Marketing
Hi,
MSRP AUTH requests must be authenticated using HTTP Digest
authentication. Part of the concatenated data when doing this
authentication is the method name. Because of the way MSRP requests are
formatted, the part of the request-line that would contain the method
name in HTTP or SIP requests is always MSRP. The MSRP method name (AUTH
in this case) is at the end of the request-line. When Kamailio converts
an MSRP request to SIP it has a method name of MSRP.
This means that when Kamailio authenticates an MSRP request it uses
"MSRP" as the method name, not the actual MSRP method name (AUTH).
Is this correct?
Should MSRP requests be authenticated with a method name of
"MSRP" (which kind-of makes sense as this is the string at the start of
the MSRP request line - which is where the method names are in HTTP and
SIP) or should the MSRP method name of "AUTH" be used?
If it is the later, does anyone know of an easy way to add this to
Kamailio?
Regards,
Peter
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
