ecting
> '10.0.1.30' due to a failure to pass ACL '(BASELINE)'
> [Jan 21 23:13:20] NOTICE[20785][C-0001] chan_sip.c: Failed to
> authenticate device <sip:95678@10.0.1.35
> <mailto:sip%3A95678@10.0.1.35>>;tag=as4028dabf
>
> Is the 10.0.1.30 in the IP ACL white list
eems the only
difference is that the second invite has an "i=2" in the Via header while
the first one has "i=1". Not sure what the "i=1" is for. Would appreciate
some insights on how kamailio is adding/handling the "i=#" in Via header.
Thanks.
Ding Ma
SPG, Motorola Solut
results on testing maxload, to know if
> there is anything to fix there.
>
> Cheers,
> Daniel
>
>
> On 14/09/15 21:52, Ding Ma wrote:
>
> Hi,
>
> Figured this out. Seems I had made a mistake in the names of AVPs. Changed
> the AVP names as the exact names used in
or
not, not really an issue even if it is not enforced.
Thanks,
On Thu, Aug 27, 2015 at 9:07 AM, Ding Ma <mading...@gmail.com> wrote:
> Hi, Daniel
>
> I just tested the dispatcher in 4.3.1. It showed the same behavior as
> 4.2.3. All the calls are sent to one Asterisk (the last one i
When your server contacts the public server, your server acts as a tls client.
So you may need to copy the server section settings (at least the calist) into
the client section of tls.cfg.
Sent from my iPhone
On Aug 28, 2015, at 12:01 PM, Alexandru Covalschi 568...@gmail.com wrote:
Hello!
, and the
kamailio.cfg is the same as included in the previous email in this thread.
Hope I didn't make any mistake in kamailio.cfg.
Thanks
On Fri, Jun 12, 2015 at 12:34 AM, Daniel-Constantin Mierla
mico...@gmail.com wrote:
Yes, 4.3 should have all fixes in 4.2.
Cheers,
Daniel
On 12/06/15 06:06, Ding Ma
Looking for some doc that describes how the new columns in 4.3.x location
table is supposed to be used. Can find some email discussions about this,
but seems no formal doc exists. Would appreciate if someone can provide an
explanation.
Thanks
___
SIP
at
it with the first chance.
Cheers,
Daniel
On 10/06/15 16:50, Ding Ma wrote:
We're running kamailio 4.2.3. Are there any changes to dispatcher in 4.2.x?
Thanks,
# kamailio -V
version: kamailio 4.2.3 (x86_64/linux) 5596bd
flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS
, select.
id: 5596bd
compiled on 09:32:37 May 6 2015 with gcc 4.4.7
On Wed, Jun 10, 2015 at 7:01 AM, Daniel-Constantin Mierla mico...@gmail.com
wrote:
Hello,
what version of kamailio are you using?
Cheers,
Daniel
On 09/06/15 20:51, Ding Ma wrote:
I'm trying to set up kamailio
I'm trying to set up kamailio dispatcher to distribute calls to 2 asterisk
servers. So far, the failover case seems ok, but I cannot get the
dispatcher to distribute load. All calls are going to the last destination
entry in the dispatcher table even if I have set the maxload attributes.
I'm using
for the help,
Ding
On Mar 20, 2015, at 3:00 AM, Daniel-Constantin Mierla mico...@gmail.com
wrote:
Hello,
On 19/03/15 02:54, Ding Ma wrote:
[...]
My first question is why k1 loose_route sends the BYE to itself instead of
the client. Is this a bug?
can you get the pcap
.
I have included pjsua logs in subsequent emails in this thread. Those logs have
SIP messages, but only provide client perspective.
Thanks for the help,
Ding
On Mar 20, 2015, at 3:00 AM, Daniel-Constantin Mierla mico...@gmail.com
wrote:
Hello,
On 19/03/15 02:54, Ding Ma wrote
Hi, all
I'm trying to set up 2 kamailio servers for active-active redundancy. The
two kamailio severs share the the same database with db_mode=3, and no
registration replication. Use pjsua2 as SIP client for testing. The test
setup is as follows:
kamailio server 1(k1): 10.0.1.30:5061
Hi, all
I'm trying to set up 2 kamailio servers for active-active redundancy. The two
kamailio severs share the the same database with db_mode=3, and no registration
replication. Use pjsua2 as SIP client for testing. The test setup is as follows:
kamailio server 1(k1): 10.0.1.30:5061
This is the SIP log when using location routing for BYE from peer server.
pjsua2_good.log
Description: Binary data
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
Is there a doc tool? Or just use an editor?
Thanks
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Daniel, Klaus,
Sorry to reply late to your comments, was busy doing some other things
until now.
Just provided some comments in
https://sip-router.org/tracker/index.php?do=detailstask_id=380
Please take a look and let me know if you agree with my assessment. Thanks,
Ding
Yes, give me a couple of days to get a clean patch based on 4.0.4. The
original patch was done on 4.0.3.
Thanks,
On 11/15/2013 3:59 AM, Klaus Darilion wrote:
Hi Ding Ma!
It would be great if you can provide the patch at the tracker.
https://sip-router.org/tracker/
regards
Klaus
Hi, all
We have applied the openssl 1.0.1e patch described in the email chain
between Roberto Fichera and Daniel-Constantin Mierla back in August. But
Kamailio 4.0.4 still fails to start up and the log shows memory allocation
problem. By the way, we're running kamailio on RHEL 6.5. Wonder if we
to submit changes for review?
Thanks,
Ding
On 10/24/2013 03:18 AM, Klaus Darilion wrote:
You should build Kamailio without optimizations. value optimized
out does not bring much information.
regards
Klaus
On 23.10.2013 21:48, Ding Ma wrote:
Hi, all
This is related to the previous
Hi, all
This is related to the previous tls.reload not safe email chain. Now we
have a detailed gdb output that shows the stack trace of the core dump.
Please take a look. This looks like a bug. Please let me know if you have
any insights on how to fix this. Thanks,
Ding
#0 0x7f0a6126a2b2
in main_loop ()
No symbol table info available.
#17 0x0046a912 in main ()
No symbol table info available.
On 10/21/2013 10:30 PM, Olle E. Johansson wrote:
22 okt 2013 kl. 05:20 skrev Ding Ma mading...@gmail.com:
Klaus,
With the information you provided, I did find the emails initiated by Jan
(ser,
openser). IIRC the feature and the detailed discussion way by Jan
Janak. Maybe this helps you to refine your Google search.
regards
Klaus
On 19.10.2013 21:33, Ding Ma wrote:
In the current Kamailio TLS module document, there is a statement about
tls.reload being unsafe. But the only way
In the current Kamailio TLS module document, there is a statement about
tls.reload being unsafe. But the only way to periodically update CRL
without restarting Kamailio is to use tls.reload. In our test with
tls.reload for CRL, it seems Kamailio would crash after about 100 times
of tls.reload
24 matches
Mail list logo
