Hi, I must deal with a B2BUA which keeps the original SDP unchanged
except the fact that it removes the "a=nortpproxy:yes" line added by
RtpProxy.
The B2BUA intercommunicates two Kamailio, both forcing its own RtpProxy server.
I've not tested it again but expect there will be no RTP as each
RtpProxy will wait for RTP coming from the other. Am I right?
Of course I could force RtpProxy just in NAT cases and so, but I
prefer to force it always so the clients of each Kamailio can
configure QoS for the media addresses (different in each server). Is
there some workaround for it?
In the other hand: is it possible two different Kamailio's to share
the same RtpProxy server? I've never tryied it. If it's valid, would
it solve the B2BUA issue? (I don't think so as there are still
different media sessions created by different kamailio instances).
Any thought? Thanks a lot.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
The htable size is static; it doesn't dynamically resize itself up to
the next power of 2 after a certain utilisation threshold, right?
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
Hello all!
I finally have something that I could call a working config (almost that
is), the proxy works fine with voice and fax sent over g.711 (but I
guess re-invites will cause problems in this scenario also). The
problem occurs when I try to switch to T.38. Since it works with voice
my guess is that the problem is caused by the re-invite to t.38. I
guess it has to be solved by a if (loose_route()) section, but I am
little bit clueless right now, I have tried multiple variants but with
no success.
RTP proxy is started with the -l flag to distinguish between local and
public traffic.
-l PUBLIC.IP.ETH0/LOCAL.IP.ETH1
The setup:
Sonus UAC/Trunk <-private ip-> (eth1)Kamailio/RTPProxy(eth0) <-public
ip-> Asterisk
IP.TO.TRUNK = Sonus IP, public address range, but only reachable by
private net (from the range of LOCAL.IP.ETH1).
LOCAL.IP.ETH1 = Local net, static route to IP.TO.TRUNK.
PUBLIC.IP.ETH0 = Public routable address.
IP.TO.ASTERISK = Public routable address.
The purpose of Kamailio/RTPProxy are to proxy everything between the
routable and the private net.
Does anyone here have any idea of how I'm going to solve my issue? It
would also be nice if anyone here have better solutions to my approach,
and there could also be some other errors in my config that causes this
behaviour.
####### Routing ########
route {
if (msg:len >= 2048) {
sl_send_reply("513", "Message too big");
exit;
}
if (method != "INVITE" && method != "ACK" && method != "BYE" &&
method != "CANCEL") {
sl_send_reply("503", "Service Unavailable");
exit;
}
if (!has_totag()) {
record_route();
route("1");
}
if (has_totag()) {
if (!loose_route()) {
if (t_check_trans()) {
t_relay();
exit;
}
exit;
}
}
if (has_body("application/sdp")) {
if (method == "INVITE") {
route("2");
t_on_reply("2");
} else if (method == "ACK") {
rtpproxy_answer();
}
} else if (method == "INVITE") {
t_on_reply("2");
}
if (method == "BYE" || method == "CANCEL") {
unforce_rtp_proxy();
}
t_relay();
}
#RELAY BY SOURCE ROUTE
route[1] {
if (src_ip == "IP.TO.TRUNK" || dst_ip == "LOCAL.IP.ETH1") {
force_send_socket("PUBLIC.IP.ETH0");
rewritehost("IP.TO.ASTERISK");
} else {
force_send_socket("LOCAL.IP.ETH1");
rewritehost("IP.TO.TRUNK");
}
}
# RTP OFFER ROUTE
route[2] {
if (src_ip == "IP.TO.TRUNK" || dst_ip == "LOCAL.IP.ETH1")
force_rtp_proxy("eir");
else
force_rtp_proxy("ier");
}
# RTP OFFER ONREPLY
onreply_route[1] {
if (has_body("application/sdp"))
route("2");
}
# RTP ANSWER ONREPLY
onreply_route[2] {
if (has_body("application/sdp"))
route("2");
}
## END OF CONFIG
Sorry for the long post, but I hope someone outthere are able to help
med with this issue.
--
Espen C. Berg, Driftstekniker - Monsternett AS (www.monsternett.no)
Violgata 3A, N-1776 HALDEN, NORWAY
Sentralbord: 69701800 - Direkte: 69701810 - Faks: 69701801
Hello,
several developers will be around Berlin in June 7-8 time frame and we
think to organize a face to face meeting. It is a good time frame if you
want to attend Amoocon in Rostock (June 4-6, aprox 230km north of
Berlin) or LinuxTag (June 9-12, in Berlin).
http://www.linuxtag.org/2010/http://www.amoocon.de/2010
I will have two presentations at Amoocon, about Asynchronous processing
in SIP Router / Kamailio and extending your routing logic with Lua (via
the new app_lua module). Hennig has one talk at LinuxTag about
Geographical redundant VoIP systems with Kamailio.
So far, interest in event and participation was shown by:
- Andrei Pelinescu-Onciul
- Jiri Kuthan
- Inaki Baz Castillo
- Jesus Rodriguez
- Elena-Ramona Modroiu
- Daniel-Constantin Mierla
- Henning Westerholt
- Marcus Hunger
A good number to move it into public space and see if others from
community are interested in such event. Based on that we will decide the
type of event and look for a proper place to host it.
Among topics could be: hands on hacking or docs update sessions, quick
start guide to start writing your own extensions as module, open debates
about current devel state and future directions...
Please drop an email if you want to participate to the event - there is
no participation fee - however, late registrations may be rejected if
the capacity of location is filled - priority is first come first served.
You can email me at miconda(a)gmail.com or to
registration(a)lists.sip-router.org
Cheers,
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/
* http://twitter.com/miconda
* http://www.linkedin.com/in/danielconstantinmierla
Hi, I need to add LCR support to an existing OpenSer 1.2 server (not
possible to upgrade it for now).
I've realized that 1.2 doesn't include gateways monitorize feature.
Ok, I can do the check with an external tool, but I would like some
way to dissable such gw from the LCR module, something like upgrading
the gw table and performing the MI reload function.
But I don't see how to set in the gw table that such gateway is
disabled. Is it possible?
Thanks.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Hi all,
Please forgive the slightly long post, but if you have anything to
contribute on this topic, please consider giving it a read as I could
really use your input. :-)
As I'm sure many others of you running proxy-based service delivery
platforms of some description also, I am faced with the problem of
trying to account for calls with missing BYEs in a realistic way.
There is no shortage of mailing list posts over the years on this
topic. Inevitably, in a platform with sufficient call volume, with
some NAT'd and/or endpoint diversity and other technical causes, there
will be some calls that are never officially terminated from the point
of view of a proxy.
The ability of the 'dialog' module to spoof bidirectional BYEs on
timeout[1] goes a long way toward addressing this problem
theoretically. However, there are practical obstacles to relying on
it solely as a solution, mainly because there is not an acceptable
timeout value to use as a trade-off. If the timeout period is set to
a very low value, users will obviously complain, and in any case,
depending on the destination, the worst-case scenario for maximum call
billing may still be far too high. If the timeout period is set
high--perhaps something like 5-8 hours--then all calls that fail to
end in the normal way will be billed some excessively large amount
that certainly will not sit well with users either.
If either the core delivery element of the platform or the user agent
is tightly controlled by the operator of the proxy from an
administrative point of view, it is indeed probably possible to rely
on RTP timeouts or SIP Session Timers (SSTs) on one of the endpoints.
That doesn't create a satisfying resolution for those of us dealing
with indeterminate call completion scenarios with a great deal of user
and vendor diversity, though. For instance, I route to about 15 ITSPs
and carriers; I think maybe one of them does 15-minute SSTs, and the
rest are certainly not going to turn them on just for me, even if
their SBCs/switches/things have the capability. The user endpoints
are mostly Asterisk and do RTP timeout, of course, and in most cases I
do get the resulting BYE. However, this discussion is about the
minute but nontrivial percentage of cases in which I do not get the
BYE, whether because of NAT statekeeping problems or network
reachability or whatever underlying causes--in truth, I cannot
accurately characterise these.
So, it seems to me that from a theoretical point of view, there are
basically two directions someone in this position can go from here:
1) Inline B2BUA in the signaling path of all calls;
1a) Make it do SSTs; or
1b) Make it relay media, too, and hang up the call (bidirectional BYE)
on RTP receive timeout;
2) Couple the proxy to an RTP relay and provide some mechanism by
which the proxy can be made aware, in an asynchronous fashion, that an
RTP timeout was detected by the relay.
It seems to me from a brief and informal survey of prior mailing list
literature that #1 is the usually recommended option here.
If #1 is pursued, what is the best tool to use in the
Kamailio/SIP-Router-oriented ecosystem? My default instinct would say
SEMS; I really like SEMS, and use it a lot for various related chores.
The problem is that the pre-built modules and examples for SEMS mostly
center on application-level functionality, while low-level
documentation of its powerful C++ API is a bit impoverished, so this
would take a lot of work.
Needless to say, I am interested in the option that requires the least
work but still solves the problem in an elegant way from a technical
and--dare I say--aesthetic perspective.
For instance, it seems clear from looking at the SEMS-1.1.1 sources
that SSTs are supported in principle in core/plug-in/session_timer.
But unless I am missing something, I cannot find anywhere in the
sources or examples where it is actually used.
So, I suppose one option is to figure out how to make this stuff work
in SEMS, and make it work. But for some reason who is not attune to
the universe of its C++ API, it is a rather formidable chore. I think
the same would hold true of making it observe bidirectional RTP timeout.
Turning attention to option #2, I have looked at rtpproxy (my
preferred default), iptrtpproxy, and mediaproxy modules but have not
found any evidence that the control protocols Kamailio/SR uses to
engage them support any notion of backward asynchronous feedback in
case of RTP timeout.
It would be really nice if one of these stream control protocols was
augmented to kick back a packet to Kamailio that can be caught in a
special event_route, like event_route[nathelper:rtp-stream-timeout],
but that is clearly not the case today.
To be honest, I would not use MediaProxy even if it had this feature,
because, well, let's be bluntly honest and acknowledge what the more
politically aware presumably already conjecture: in light of AG
Projects' zealous OpenSIPS partnership, it's difficult to muster
confidence in future compatibility of MediaProxy with Kamailio. The
module is there, it works, and I'm sure its maintainers are dedicated
to doing whatever it takes to reverse engineer and keep it working,
lift patches from OpenSIPS as necessary, etc., but who wants to be on
the wrong side of the project ecosystem fence? Not I.
That leaves iptrtpproxy, whose 'switchboard' concept I do not fully
comprehend due to lack of experience with it, but which holds a
potentially viable, if slightly kludgy/Rube Goldbergian answer. Of
the three RTP proxies, it is the only one that provides a ready means
of exporting a list of media streams it is currently tracking,
together with statistics on how many packets have been received, etc.
It is not inconceivable to cook up an external process that will
frequently check this 'switchboard', as it were, and incite
Kamailio/SR to do dlg_bye() via MI if it appears that the media stream
has disappeared from either side; the dialog module helpfully exports
the MI command dlg_end_dlg.
Still, this does not seem nearly as parsimonious and reliable a
solution as simply building some kind of RTP stream leg timeout
notification into the control socket. After all, the control socket
is open persistently, right, not on-demand? The various RTP proxies
all seem to have some kind of dead peer detection internally in order
to have some means of gracefully expiring resources allocated to media
streams that have gone away, so it would just be a matter of passing a
control frame up the socket to Kamailio/SR and wiring that to a custom
event_route or a more static callback in the code.
By the way, I should mention that I am aware of and historically very
sympathetic to the perspective that this kind of call control is alien
to the nature of a proxy, and an appropriate job for UAs and not
proxies at all. However, we all have to make pragmatic concessions to
the realities of real-world operation, which I assume is the
motivation for dialog timeouts, dlg_bye(), and other perversions from
the point of view of a purist. :-)
I welcome your thoughts and suggestions about the easiest and most
technically meritorious approach.
Thanks,
-- Alex
[1] Enabled via $dlg_ctx(timeout_bye) = 1
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
Hi everyone,
In the page where a module is described, there is a list of dependencies that have to be met in order to use the module, the list of exported parameters that might need to be set in the configuration file and a list of exported functions which can be used in the configuration script. I've noticed as well, that there are some "Exported MI functions" but I was wondering if any of you know what the purpose of those functions is, where and how such functions could be used?
Thanks
Héctor
Hi List,
I'm writing a little message because I encountered today a strange error
on my Kamailio 3.0 proxy/presence server ( and can't ask on IRC there's
nobody atm ;p )
I get these errors in the logs since a few hours:
Apr 23 14:31:41 proxy-b /proxy/bin/kamailio/sbin/kamailio[29008]: ERROR:
tm [t_msgbuilder.c:1371]: build_uac_req(): no shmem
Apr 23 14:31:41 proxy-b /proxy/bin/kamailio/sbin/kamailio[29008]: ERROR:
tm [uac.c:327]: t_uac: Error while building message
Apr 23 14:31:41 proxy-b /proxy/bin/kamailio/sbin/kamailio[29008]: ERROR:
presence [notify.c:1577]: in function tmb.t_request_within
Apr 23 14:31:41 proxy-b /proxy/bin/kamailio/sbin/kamailio[29008]: ERROR:
presence [notify.c:1673]: sending Notify not successful
Apr 23 14:31:41 proxy-b /proxy/bin/kamailio/sbin/kamailio[29008]: ERROR:
presence [notify.c:1348]: Could not send notify for dialog
That prevents NOTIFYs from being sent, but I can also see sometimes
NOTIFYs get sent without theses errors.
The strange thing is that the error indicate no shared memory, but on
the server, I'm far from being memless (16G total RAM, 4G free not even
used for cache ).
I have presence, presence_xml, presence_dialoginfo, pua, pua_dialoginfo
and pua_bla loaded.
Anyone got an idea on where to look ?
Regards,
Gled.
Hi All,
I would like to use CDRTool for accounting and integrate with kamailio +
mediaproxy + freeradius.
so, please let me know about configuration or installation steps for
CDRToolon centos-5.X os.
I have followed this link for CDRTool configuration http://cdrtool
.ag-projects.com/wiki/Install
but not success and confused.
I have seen above url for CDRTool that provides information for deban os.
but i want to install on centos.
I am installed and run kamailio and mediaproxy successful.
I am confused about compile or install about CDRTool and i want to help
about Freeradius integration with kamailo and CDRTool.
Thanks in advance.
--
Best Regards,
Rajnikant