sr-users

sr-users@lists.kamailio.org

42 participants
37517 discussions

New voisonics.com - Kamailio related products and services
by David Cunningham 02 May '19

02 May '19

Hello, Usually it's our client's VoIP technology being updated. Fortunately we found a little spare time to completely revamp the Voisonics website as well! https://voisonics.com/ Voisonics provides products and services in the commercial VoIP and hosted PBX sector; in particular relating to Kamailio, Asterisk, and Enswitch. The business has been specialising in this area for almost 10 years. Please feel free to contact me off-list with any questions. Kind regards, -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782

1 0

Support for JWT token authentication?
by David Dean 01 May '19

01 May '19

I came across this thread from Jan 2015 discussing the addition of JWT token authentication to Kamailio: https://github.com/kamailio/kamailio/issues/29 Was JWT authentication ever added? Or has anyone else on this list got JWT working somehow?

1 0

CSeq not incrementing - app_ruby
by Andrew White 01 May '19

01 May '19

Hi all, I’m still building with app_ruby and loving it - for the most part! I’m having an issue with one of my providers responding with a 482 on auth invite. Researching, it appears that my CSeq isn’t incrementing and this is the reason for the issue. I already have the relevant flag set in my kamailio.cfg however: modparam("dialog", "track_cseq_updates", 1) During my uac_auth, I’ve tried manually setting the diff, as well as running msg_iflag_reset (as suggested by Daniel - https://github.com/kamailio/kamailio/issues/1359 <https://github.com/kamailio/kamailio/issues/1359> - unfortunately the function isn’t exported in KEMI): if KSR::UAC.uac_auth() then KSR.info("UAC authed, relaying") #KSR::COREX.msg_iflag_reset("UAC_AUTH") KSR::PV.sets("$dlg_var(cseq_diff)", "1") KSR.info("CSeq diff: #{KSR::PV.gete("$dlg_var(cseq_diff)")}") KSR::TM.t_relay() Unfortunately in both cases the actual CSeq doesn’t increment in the second INVITE: INVITE 1 (unauthenticated): > CSeq: 102 INVITE INVITE 2 (with Authorization header): > CSeq: 102 INVITE I’m unsure if I’ve missed something silly around the track_cseq_updates flag, or if app_ruby somehow isn’t interacting with the dialog module when running uac_auth to trigger the increment? Thanks! Kind regards, Andrew

3 6

listening at link local IPv6 address
by Juha Heinanen 01 May '19

01 May '19

My K host is behind a mobile WiFi hotspot and I tried to make K listen at the IPv6 address fe80::6e29:95ff:fe7d:37e6/64 that the host has received from the hotspot. Using that address on listen line gives error: Apr 21 08:55:18 salmon /usr/bin/sip-proxy[6887]: ERROR: <core> [core/udp_server.c:395]: udp_init(): bind(8, 0x7ff97dfb3fe4, 28) on FE80:0:0:0:6E29:95FF:FE7D:37E6: Invalid argument Apr 21 08:55:18 salmon /usr/bin/sip-proxy[6887]: ERROR: <core> [core/udp_server.c:401]: udp_init(): might be caused by using a link local address, try site local or global I can ping that address like this: $ ping6 fe80::6e29:95ff:fe7d:37e6%wlp1s0 PING fe80::6e29:95ff:fe7d:37e6%wlp1s0(fe80::6e29:95ff:fe7d:37e6%wlp1s0) 56 data bytes 64 bytes from fe80::6e29:95ff:fe7d:37e6%wlp1s0: icmp_seq=1 ttl=64 time=0.030 ms I then tried to add %wlp1s0 suffix to the listen address, but got error: Apr 21 09:10:35 salmon sip-proxy[7896]: 0(7948) CRITICAL: <core> [core/cfg.y:3510]: yyerror_at(): parse error in config file /etc/sip-proxy/sip-proxy.cfg, line 408, column 34: ip address, interface name or hostname expected Did I do something wrong? If not, why is it that K cannot listen at a link local address? It is something that Linux networking stack does not support? -- Juha

6 33

Pipelimit with clean_unused
by Cinthia Leung 30 Apr '19

30 Apr '19

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 dynamic/run-time pipes. Thanks Cindy

1 1

Next hop of reply, in onreply_route
by Alex Balashov 30 Apr '19

30 Apr '19

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, I’m aware that this can be previewed from the onsend_routes*, but I need to amalgamate that knowledge with some transaction-specific data. Thanks! — Sent from mobile, with due apologies for brevity and errors.

2 2

"ERROR: reply too big" and ctl binrpc size
by Karsten Horsmann 30 Apr '19

30 Apr '19

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 values of without knowing the size of the current filled up binrpc stuff? Or is there a better option to debug dialog-module? modparam("ctl", "binrpc_max_body_size", ??) modparam("ctl", "binrpc_struct_max_body_size", ?) -- Cheers and see you in Berlin *Karsten Horsmann*

2 1

Re: [SR-Users] SIP basic flow question: R-URI in ACK
by Yufei Tao 30 Apr '19

30 Apr '19

Hi Daniel, Thank you very much for clarifying! Cheers, Yufei On 30 Apr 2019 at 08:10, <Daniel-Constantin Mierla <miconda(a)gmail.com>> 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/errata/eid5294 Cheers, Daniel On 28.04.19 22:54, Yufei Tao wrote: Hi, I have a question regarding basic SIP flow for establishing a call session, and wonder if anyone can help me clarify. For normal call set up, INVITE-OK-ACK, from RFC3261, I believe the ACK’s R-URI should be a copy of the Contact header of the OK message. However in RFC3665 sections 3.1 and 3.2 for example, the ACK’s R-URI missed the parameters from the Contact header of the OK, e.g. In OK the Contact header is: Contact: <sip:bob@client.biloxi.example.com;transport=tcp> <sip:bob@client.biloxi.example.com;transport=tcp> And ACK the R-URI is: ACK sip:bob@client.biloxi.example.com SIP/2.0 Which has got the parameter ‘transport=tcp’ removed – why is this? In this case if the proxy connected to Bob handles ACK in the usual way as it would for all in-dialog requests, i.e. based on routing headers only and not extra processing, it’ll try to relay the ACK message to Bob using the default transport UDP which is not expected and will fail. Can anyone help explain why the parameters are removed in RFC3665 examples please? Have I missed anything? Thank you very much! Yufei _______________________________________________ Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com

1 0

docker image for non x86 arch
by Sergey Safarov 30 Apr '19

30 Apr '19

Is the community involved in kamailio docker image for ARM architecture and others not x86 platforms? ARM ARM 64 IBM POWER IBM Z PowerPC 64 LE

3 3

SIP basic flow question: R-URI in ACK
by Yufei Tao 30 Apr '19

30 Apr '19

Hi, I have a question regarding basic SIP flow for establishing a call session, and wonder if anyone can help me clarify. For normal call set up, INVITE-OK-ACK, from RFC3261, I believe the ACK’s R-URI should be a copy of the Contact header of the OK message. However in RFC3665 sections 3.1 and 3.2 for example, the ACK’s R-URI missed the parameters from the Contact header of the OK, e.g. In OK the Contact header is: Contact: <sip:bob@client.biloxi.example.com;transport=tcp> And ACK the R-URI is: ACK sip:bob@client.biloxi.example.com SIP/2.0 Which has got the parameter ‘transport=tcp’ removed – why is this? In this case if the proxy connected to Bob handles ACK in the usual way as it would for all in-dialog requests, i.e. based on routing headers only and not extra processing, it’ll try to relay the ACK message to Bob using the default transport UDP which is not expected and will fail. Can anyone help explain why the parameters are removed in RFC3665 examples please? Have I missed anything? Thank you very much! Yufei

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users