Re: [SR-Users] SIP basic flow question: R-URI in ACK

2019-04-30 Thread Yufei Tao
Hi Daniel, Thank you very much for clarifying! Cheers, Yufei On 30 Apr 2019 at 08:10, > wrote: Hello, there is an errata for that RFC, but it refers only to the BYE, where it adds back the transport=tcp, but the ACK R-URI should follow the same rules, see: * https://www.rfc-editor.org/errat

Re: [SR-Users] listening at link local IPv6 address

2019-04-30 Thread Juha Heinanen
Daniel-Constantin Mierla writes: > Speaking of that, can someone test with both: > > auto_bind_ipv6=1 > > bind_ipv6_link_local=1 > > And see if kamailio listen on all available IPv6 addresses, including > the link local ones? You mean start K without any listen directives? I tried and it fail

Re: [SR-Users] listening at link local IPv6 address

2019-04-30 Thread Juha Heinanen
Sergey Safarov writes: > listen=proto:[linklocalip%nic]:port advertise ... I like the above more than a new iface token. linklocalip%nic is already in use by other apps (apache, telnet, etc.). -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@

Re: [SR-Users] Pipelimit with clean_unused

2019-04-30 Thread Cinthia Leung
I suppose I can store the db values in htable. On Tue, Apr 30, 2019 at 5:49 PM Cinthia Leung wrote: > Hello, > > What is your recommendation on using clean_unused with db defined pipes? > >>pl_check("systemwide"); > > If I leave the system idle, they are eventually "cleaned" as expected. In > o

[SR-Users] Pipelimit with clean_unused

2019-04-30 Thread Cinthia Leung
Hello, What is your recommendation on using clean_unused with db defined pipes? >>pl_check("systemwide"); If I leave the system idle, they are eventually "cleaned" as expected. In our use case, that means failed calls unfortunately. I am trying to see if I can mix both db/static pipes with dyna

Re: [SR-Users] CSeq not incrementing - app_ruby

2019-04-30 Thread Henning Westerholt
Hello Andrew, It seems indeed that the dialog is not found, and therefore the cseq can't be incremented. just to make sure there is no obvious error - you actually set the dlg_flag 4 in the proper place in the configuration - e.g. for initial dialog forming requests? Cheers, Henning Am 29.0

Re: [SR-Users] listening at link local IPv6 address

2019-04-30 Thread Sergey Safarov
How it will correlate to listen=proto:ifname:port advertise ... is possible to parse old behavior, like listen=proto:[linklocalip%nic]:port advertise ... On Tue, Apr 30, 2019 at 6:00 PM Daniel-Constantin Mierla wrote: > OK, thanks for testing and feedback. > > I thought that maybe we should a

Re: [SR-Users] listening at link local IPv6 address

2019-04-30 Thread Henning Westerholt
Hello Daniel, Am 30.04.19 um 16:59 schrieb Daniel-Constantin Mierla: > OK, thanks for testing and feedback. > > I thought that maybe we should also add a way to specify the interface > name via config, like full specs for listen to be: > > listen=proto:ip:port iface xyz advertise ... > > 'iface' b

Re: [SR-Users] Next hop of reply, in onreply_route

2019-04-30 Thread Alex Balashov
On Tue, Apr 30, 2019 at 09:09:50PM +0500, Arsen wrote: > What about handling Via header with selects? Possible, just a bit too forensic. Wondered if there was a high-level PV I missed. The way I am currently handling this problem is by setting an AVP with the transport on which the transaction-f

Re: [SR-Users] Next hop of reply, in onreply_route

2019-04-30 Thread Arsen
Hi Alex, What about handling Via header with selects? Regards, Arsen Semionov On Tue, Apr 30, 2019 at 8:39 PM Alex Balashov wrote: > I am fairly sure it’s been asked a number of times, but is there a way to > know the destination, and more especially the transport, of the next hop of > a repl

[SR-Users] Next hop of reply, in onreply_route

2019-04-30 Thread Alex Balashov
I am fairly sure it’s been asked a number of times, but is there a way to know the destination, and more especially the transport, of the next hop of a reply message, viewable from onreply_route? For requests, we have $nh and many other PVs which in some way evidence where it’s going. And yes,

Re: [SR-Users] listening at link local IPv6 address

2019-04-30 Thread Daniel-Constantin Mierla
OK, thanks for testing and feedback. I thought that maybe we should also add a way to specify the interface name via config, like full specs for listen to be: listen=proto:ip:port iface xyz advertise ... 'iface' being a reserved token, similar to 'advertise'. In this way we can avoid looping via

Re: [SR-Users] listening at link local IPv6 address

2019-04-30 Thread Juha Heinanen
Sergey Safarov writes: > That because to bind link local address need to define used NIC like > > sipp -sn uas -i fe80::b951:ef1f:76c8:e5a2%eth0 Yes, this kind of syntax worked: $ sipp fe80::6e29:95ff:fe7d:37e6%wlp1s0 -p 5050 -m 1 -sf register.sipp -t t1 -i fe80::6e29:95ff:fe7d:37e6%wlp1s0 -p

Re: [SR-Users] listening at link local IPv6 address

2019-04-30 Thread Sergey Safarov
That because to bind link local address need to define used NIC like sipp -sn uas -i fe80::b951:ef1f:76c8:e5a2%eth0 On Tue, Apr 30, 2019 at 4:49 PM Juha Heinanen wrote: > Daniel-Constantin Mierla writes: > > > can you try with latest master and set the next global parameter? > > > > bind_ipv6_

Re: [SR-Users] listening at link local IPv6 address

2019-04-30 Thread Juha Heinanen
Daniel-Constantin Mierla writes: > can you try with latest master and set the next global parameter? > > bind_ipv6_link_local=1 > > Along with the usual listen on a link local ipv6 address. > > Let me know if it works. It worked at least with UDP. I was not able to test with TCP or TLS. I tri

Re: [SR-Users] "ERROR: reply too big" and ctl binrpc size

2019-04-30 Thread Daniel-Constantin Mierla
Hello, you can set it to any value that fits within your system memory, because it doesn't use the internal pkg or shm pools, so it is not impacted by the values of -m or M parameters. Alternative is to do 'kamctl rpc dlg.list_ctx" if you have jsonrpcs module loaded, this command should not use a

Re: [SR-Users] Kamailio OPTIONS Round-Trip

2019-04-30 Thread Rhys Hanrahan
Hi Everyone, I would just like to add that I’m also very interested in several of the things Daniel mentioned in this thread. Particularly the RTT/latency information for NAT’d contacts is very useful – so that’s a +1 from me. As someone who is trying to migrate from using Asterisk as our regis

[SR-Users] "ERROR: reply too big" and ctl binrpc size

2019-04-30 Thread Karsten Horsmann
Hi all, i use kamailio 5.0.7 in production and i noticed that i cant listen the dialogs after a few days of traffic on this server. Then i got "kamcmd dlg.list_ctx " - "ERROR: reply too big". So now my question - i want to debug my "sleeping dialogs" with dlg.list - how big should it change the

Re: [SR-Users] listening at link local IPv6 address

2019-04-30 Thread Daniel-Constantin Mierla
Hello, can you try with latest master and set the next global parameter? bind_ipv6_link_local=1 Along with the usual listen on a link local ipv6 address. Let me know if it works. Cheers, Daniel On 24.04.19 16:38, Juha Heinanen wrote: > Daniel-Constantin Mierla writes: > >> OK, thanks for test

Re: [SR-Users] docker image for non x86 arch

2019-04-30 Thread Karsten Horsmann
Hi all, Maybe alpine Linux could be a option. It's used often as docker base image and for many arm architectures seems to be Kamailio available https://pkgs.alpinelinux.org/package/edge/main/aarch64/kamailio Cheers Karsten Sergey Safarov schrieb am Di., 5. März 2019, 06:37: > Is the communit

Re: [SR-Users] SIP basic flow question: R-URI in ACK

2019-04-30 Thread Daniel-Constantin Mierla
Hello, there is an errata for that RFC, but it refers only to the BYE, where it adds back the transport=tcp, but the ACK R-URI should follow the same rules, see:   * https://www.rfc-editor.org/errata/eid5294 Cheers, Daniel On 28.04.19 22:54, Yufei Tao wrote: > > Hi, > >   > > I have a question