Hi Charles,
Thank you for your answer.
I've notice that your name shows in the headers of the files of the new
(patched) memcached module.
Can you please detail a little bit on what does your patch bring new apart from
libmemcached support ?
Or what does it still miss, since you said it's under
Although it's difficult to know the exact cause of your "protocol" error,
it does appear from your tests that the graceful handling of errors and
subsequent reconnects is better in libmemcached than in libmemcache. So if
you do encounter the same conditions again, I would imagine that the
library w
Hello Daniel/Stoyan
Thanks for your reply, here is a full sip trace from the first INVITE
message to the last acknowledge which is sent to PGW.
192.168.10.189 ==> 81.21.38.34
INVITE sip:94294294@81.21.38.34 SIP/2.0
Via: SIP/2.0/UDP 192.168.10.189:5060;branch=z9hG4bK7ddbce3f;rport
Max-Forwards:
Hi Charles,
I tried first to trigger again the bug using some iptables rules (to simulate a
network problem) , so Kamailio could not communicate with the memcache anymore:
WARNING: memcached [memcached.c:189]: WARNING: memcached:
mcm_server_readable():2582: timeout: select(2) call timed out fo
Hi Dragos,
The memcached module has indeed been updated in the master to use
libmemcached, as the old libmemcache library is no longer under active
development. Have you tried using the latest version of the module from
git? Do you still get the same errors?
Cheers,
Charles
On 6 June 2013 16:1
Hello
We are having issues with the memcached module (Kamailio 4.0.0) .
All of a sudden we are getting this kind of messages in the logs, and the
values for the requested keys are not retrieved.
ALERT: memcached [memcached.c:189]: ALERT: memcached: mcm_fetch_cmd():1305:
memcache(4) protoc
I dont know what caused problem. I just found working solution. I used
fireshark to get messages, and I saw that some ACK and BYE messages
"reenter" kamailio and keep growing - as I remember (not sure). As I
remember (not sure) - VIA started to grow for next messages. For me it
looked like message
Hello, Daniel-Constantin!
>I could spot you change the URI in To header and don't restore it for
>replies. Might be that if your cisco is old and does not match on
>rfc3261.
Seems you are right. I test it tomorrow. Thank you!
--
WBR, Victor
JID: coy...@bks.tv
JID: coy...@bryansktel.ru
I
On 6/6/13 2:11 PM, Stoyan Mihaylov wrote:
> I use Kamailio for register and Asterisk servers for processing call.
> Asterisk accept all calls from Kamailio and dont know nothing about users
> and their passwords.
> I think this is simplest way for integration and using best from both
> applicatio
Welcome Camille! :-)
Torrey
On 6 June 2013 15:54, Daniel-Constantin Mierla wrote:
> Hello,
>
> I want to announce that a new person got developer GIT write access to
> repository: Camille Oudot - from Orange, France. Currently, he is
> developing mainly on Kamailio IMS modules, several patches
On 6/6/13 4:34 PM, Stoyan Mihaylov wrote:
We had some similar problems.
But what was the actual problem? At least in the two ACKs provided
below, loose routing handling with looks correct.
Is something that Asterisk doesn't like?
Cheers,
Daniel
Our configuration is:
SIP client 1 <-> Kama
I am not familiar with cisco, if it cannot provide more than these debug
messages.
I could spot you change the URI in To header and don't restore it for
replies. Might be that if your cisco is old and does not match on rfc3261.
Cheers,
Daniel
On 6/6/13 4:29 PM, Victor V. Kustov wrote:
Hello
On 6/6/13 2:11 PM, Stoyan Mihaylov wrote:
I use Kamailio for register and Asterisk servers for processing call.
Asterisk accept all calls from Kamailio and dont know nothing about
users and their passwords.
I think this is simplest way for integration and using best from both
applications.
T
Hello,
the incoming ACK has the top Route with lr parameter, meaning is loose
routing. By that, the proxy removes the top route header, preserves the
R-URI and sends to the URI in the next Route header.
From what I can see in the Route stack, it seems a spiral back to the
proxy because ip 81
Hello,
On 6/6/13 11:05 AM, Daniel Pocock wrote:
I was just looking over:
http://kb.asipto.com/asterisk:realtime:kamailio-3.3.x-asterisk-10.7.0-astdb
A couple of things I noticed:
- Kamailio is using a column sippasswd which is not hashed. Asterisk
doesn't use that column at all. Is there an
We had some similar problems. Our configuration is:
SIP client 1 <-> Kamailio <-> Asterisk <->Kamailio<->SIP client 2
My solution was to check $td and $si and if they are same as Kamailio, to
forward call to Asterisk.
Because I planed to use more then 1 Asterisk, I keep in variable which one
to use
Hello, Daniel-Constantin!
Pastebin link. Or better post here?
http://pastebin.com/QUGw3t0G
--
WBR, Victor
JID: coy...@bks.tv
JID: coy...@bryansktel.ru
I use FREE operation system: 3.9.4-calculate GNU/Linux
___
SIP Express Router (SER) and Kamai
Hello,
I am not a radius user, so it is not easy to reproduce. If you get a
core, then put the backtrace on tracker and we will look at it. The
issue might be in radius client library, kamailio uses function from the
library to parse the config -- we can see that from the core backtrace.
Che
Hello, Daniel-Constantin!
>Hello,
>
>this is related to:
>
>http://sip-router.org/tracker/index.php?do=details&task_id=310&project=1
>
>right?
exactly.
>Have you got additional details?
hmm... it easy to reproduce. just comment
"acctserver " in radius-ng.conf AND use radius accounting.
Hello,
On 6/6/13 2:57 PM, Victor V. Kustov wrote:
Hello!
Updated:
Cisco drop OK message:
*Jun 6 04:53:54.686: //-1//SIP/Info/sipSPILocateInviteDialogCCB:
Could not find matching transaction for this response, Dropping it
*Jun 6 04:53:55.206: //-1//SIP/Info/HandleUd
Hello,
this is related to:
http://sip-router.org/tracker/index.php?do=details&task_id=310&project=1
right?
Have you got additional details?
Cheers,
Daniel
On 6/5/13 11:51 AM, Victor V. Kustov wrote:
Hello.
[/usr/local/lib64/kamailio/modules/tm.so]
Jun 5 13:49:10 phoenix-c2 /usr/local/sbin
Hello,
I want to announce that a new person got developer GIT write access to
repository: Camille Oudot - from Orange, France. Currently, he is
developing mainly on Kamailio IMS modules, several patches being
submitted lately by him.
His git commit id is: coudot
My warm welcome and looking
obviously 'Edit as new' fails to automatically update the subject line
... this email will be sent again.
On 6/6/13 3:51 PM, Daniel-Constantin Mierla wrote:
Hello,
I want to announce that a new person got developer GIT write access to
repository: Camille Oudot - from Orange, France. Currentl
Hello,
I want to announce that a new person got developer GIT write access to
repository: Camille Oudot - from Orange, France. Currently, he is
developing mainly on Kamailio IMS modules, several patches being
submitted lately by him.
His git commit id is: coudot
My warm welcome and looking
Dear list further to the above problem i observed the following:
ACK message coming from PABX1:
U +0.001877 192.168.10.189:5060 -> 81.21.38.34:5060
ACK sip:94294294@81.21.38.55 SIP/2.0*
Via: SIP/2.0/UDP 192.168.10.189:5060;branch=z9hG4bK76f8f103;rport*
Route: ,<
sip:94294294@81.21.38.5
;pgw-call=
Hello!
Updated:
Cisco drop OK message:
*Jun 6 04:53:54.686: //-1//SIP/Info/sipSPILocateInviteDialogCCB:
Could not find matching transaction for this response, Dropping it
*Jun 6 04:53:55.206: //-1//SIP/Info/HandleUdpSocketReads: Msg
enqueued for SPI with IP addr: 172
Hi Eduardo,
please take into account that there might be telephony concepts
mistranslated from Spanish to English.
In case you find something else that seems confusing, please let me know.
Regards,
Carlos
On Thu, Jun 6, 2013 at 7:56 AM, Eduardo Lejarreta wrote:
> Good evening Carlos.
>
>
Hi all!
I've got a problem with Kamailio<->Cisco<->PSTN.
Called from PSTN:
16:20:14.328786 IP (tos 0x80, ttl 255, id 0, offset 0, flags [none], proto UDP
(17), length 1166)
172.16.16.3.58446 > 172.16.17.8.sip: SIP, length: 1138
INVITE sip:599674@172.16.17.8:5060 SIP/2.0
Via:
I use Kamailio for register and Asterisk servers for processing call.
Asterisk accept all calls from Kamailio and dont know nothing about users
and their passwords.
I think this is simplest way for integration and using best from both
applications.
On Thu, Jun 6, 2013 at 12:05 PM, Daniel Pocock
Good evening Carlos.
I've found an example on git repository where you have additional
information.
For a credit of 50, a discount per second of 0,5, a initial_pulse of 30 and
final_pulse of 6 ..
# if only one call is established, that call should last 1m, 36s
Now It makes sense to
Hello,
indeed it is microseconds, I fixed the docs on master branch. I will
backport soon.
Thanks,
Daniel
On 6/5/13 5:42 PM, David K wrote:
Hello,
According to this page :
http://kamailio.org/docs/modules/stable/modules/cfgutils.html#idp15252400
usleep will sleep for the number of milli-s
Good morning Carlos.
On cnxcc_set_max_credit() function I don't understand the concept "pulse"
(sure it's something easy but I'm a not aware about this matter)
Could you please explain it in an example?
Thanks and best regards.
--
Eduardo Lejarreta.
__
Dear List
I upgraded from Kamailio v 3.3 to 4.0.1 and am now facing an issue for the
below scenario:
PABX1 ==> Kamailio1 ==> Cisco PGW ==> Kamailio1 ==> PABX2
I understand that this is a hairpin scenario but was working normally on v
3.3.
Checking in the syslog i see:
ERROR: [receive.c:230]:
I was just looking over:
http://kb.asipto.com/asterisk:realtime:kamailio-3.3.x-asterisk-10.7.0-astdb
A couple of things I noticed:
- Kamailio is using a column sippasswd which is not hashed. Asterisk
doesn't use that column at all. Is there any reason this can't be done
with the H(A1) and H(A
Hello,
it may be useful to add it in the faq or mini-howtos on the wiki,
wherever you consider more appropriate:
- https://www.kamailio.org/wiki/tutorials/faq/main
- https://www.kamailio.org/wiki/tutorials/mini-howto-admin/main
Cheers,
Daniel
On 6/4/13 6:54 PM, Klaus Darilion wrote:
Finally
On 6/6/13 12:01 AM, hiro wrote:
earlier today I commented out the whole route(NATMANAGE) from
MANAGE_FAILURE route, that broke the NAT.
But with your condition it works fine. thanks!
Welcome.
Only I don't understand the $du/$ru thing yet.
$ru is R-URI, the address in the first line of a SIP r
36 matches
Mail list logo
