4 dec 2012 kl. 05:26 skrev Ovidiu Sas :
> Hello all,
>
> For those who like running kamailio on routers and/or other small
> embedded systems, the latest kamailio stable is available for
> download.
> For more info, please check: http://www.nslu2-linux.org/wiki/Optware/HomePage
> For a list of s
I've added a basic working kamailio.cfg with Shared Call Appearances to the SCA
docs. It should help clarify where and when it's necessary to have the sca
module inspect traffic. Those of you simply wanting to test SCA can just copy
and paste the configuration, updating the listen address as nec
Hello all,
For those who like running kamailio on routers and/or other small
embedded systems, the latest kamailio stable is available for
download.
For more info, please check: http://www.nslu2-linux.org/wiki/Optware/HomePage
For a list of supported platforms, please check:
http://www.nslu2-linux
any idea what could be the cause for lots of these kind syslog messages:
Dec 3 23:11:36 sip2 /usr/sbin/sip-proxy[5490]: :
[pass_fd.c:293]: ERROR: receive_fd: EOF on 56
Dec 3 23:11:36 sip2 /usr/sbin/sip-proxy[5490]: ERROR:
[io_wait.h:628]: ERROR: io_watch_del: trying to delete already erased
en
On Dec 3, 2012, at 4:40 PM, Ovidiu Sas wrote:
> Hello all,
>
> By inspecting the source code, the only difference that I could see
> between kamailio and ser flavours is that kamailio has support for the
> "tm:local-request".
> Are there any constrains in having the tm:local-request present for
Hello all,
By inspecting the source code, the only difference that I could see
between kamailio and ser flavours is that kamailio has support for the
"tm:local-request".
Are there any constrains in having the tm:local-request present for ser flavour?
Does it make sense to continue to build two fla
On 12/03/2012 01:41 PM, Alex Solt wrote:
Is there a way to perform health check on kamailio application?
Depends on the attributes that you consider to be associated with
"health". :-) But in principle, yes, via the MI or sercmd RPC interfaces.
--
Alex Balashov - Principal
Evariste System
I was able to figure out why my logic didn't work. I was calling the default
route(RELAY) in LCR route, since route(RELAY) has t_on_failure already
specified, setting t_on_failure in LCR route did nothing.
I am now calling t_relay directly from LCR route and failure route is now
working. I just
Hi,
Is there a way to perform health check on kamailio application?
AS
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-b
Kamailio project is announcing its first dedicated event - Kamailio
World - to take place in Berlin, Germany, during April 16-17, 2013. The
event is organized by Asipto (http://www.asipto.com) in collaboration
with Fraunhofer Fokus Institute (http://www.fokus.fraunhofer.de).
The conference is
Dear Daniel,
Thanks cor your feedback. I will do the trace and come back to you.
Best Regards,
Roy.
On Fri, Nov 30, 2012 at 1:53 PM, Daniel-Constantin Mierla wrote:
>
> ngrep -d any -qt -W byline port 5060
___
SIP Express Router (SER) and Kamailio (Op
Hi Klaus and Ole,
On 12/03/2012 11:43 AM, Klaus Darilion wrote:
> Just use:
> @ IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.example.com.
>
> I would interpret it as:
>
>SIPS+D2T
> | \
> | \
> secure + TCP --> TLS
Ok, this seems like a valid approach. I'll
It might help if you can dump the ngrep trace of a NOTIFY and the
corresponding INVITE from a phone when it tries to pickup the call.
regards
Klaus
On 01.12.2012 22:29, Mark Boyce wrote:
Hi All,
I've hit my next stumbling block on my mission to get BLF/Call pickup working
on Linksys/Cisco ph
On 03.12.2012 10:43, Andreas Granig wrote:
Hi Klaus,
On 12/03/2012 10:15 AM, Klaus Darilion wrote:
The request URI should look like the one which the user enters. E.g. if
user enters "sip:12...@example.com" then the request URI should be
"sip:12...@example.com" - regardless of the transport p
3 dec 2012 kl. 10:43 skrev Andreas Granig :
> Hi Klaus,
>
> On 12/03/2012 10:15 AM, Klaus Darilion wrote:
>> The request URI should look like the one which the user enters. E.g. if
>> user enters "sip:12...@example.com" then the request URI should be
>> "sip:12...@example.com" - regardless of th
Andreas Granig writes:
> So how should the NAPTR record look like if you want to use TLS with a
> SIP URI? Would it still be SIPS+D2T, or could you use something like
> SIP+D2T along with a replacement part
> "_sip._tcp.example.com;transport=tls"?
i would use _sip._tls.example.com. the standard
Hi Klaus,
On 12/03/2012 10:15 AM, Klaus Darilion wrote:
> The request URI should look like the one which the user enters. E.g. if
> user enters "sip:12...@example.com" then the request URI should be
> "sip:12...@example.com" - regardless of the transport protocol chosen by
> the transport layer.
>
Hi Owen,
you don't need TLS for sip capturing, please undef WITH_TLS and try again,
Wbr,
Alexandr
2012/12/3 Owen Lynch
>
>
>
> On 3 December 2012 10:20, Alexandr Dubovikov wrote:
>
>> Hi Olwen,
>>
>> ** **
>>
>> siptrace use UDP to send HEP packets, but here is a problem in tcp stack.
>> *
On 01.12.2012 00:25, Andreas Granig wrote:
Hi,
Hope to get some guidance here over the usage of "sips" and "sip plus
transport=tls" when following RFC3263.
The RFC3263 says that a NATPR record could return something like this
for a query like "host -t NAPTR example.com":
; order
19 matches
Mail list logo
