- sr-users - kamailio.org

db_mongodb get columns error
by Mickael Marrache 07 May '15

07 May '15

Hi, After restarting Kamailio, I got the following errors during the startup: kamailio[12614]: ERROR: db_mongodb [mongodb_dbase.c:381]: db_mongodb_get_columns(): field [caller_sock] not found in result iterator kamailio[12614]: ERROR: db_mongodb [mongodb_dbase.c:739]: db_mongodb_store_result(): failed to set the columns kamailio[12614]: ERROR: db_mongodb [mongodb_dbase.c:918]: db_mongodb_query(): failed to store result kamailio[12614]: ERROR: db_mongodb [mongodb_dbase.c:927]: db_mongodb_query(): failed to do the query kamailio[12614]: ERROR: dialog [dlg_db_handler.c:257]: select_entire_dialog_table(): Error while querying database What may be causing the issue? I should always have a caller_sock in every dialog document. Thanks, Mickael

2 4

TCP connection reset by peer
by Mickael Marrache 07 May '15

07 May '15

Hi, I sometimes see the following in the logs: kamailio[14433]: ERROR: <core> [tcp_read.c:271]: tcp_read_data(): error reading: Connection reset by peer (104) kamailio[14433]: ERROR: <core> [tcp_read.c:1296]: tcp_read_req(): ERROR: tcp_read_req: error reading It looks like Kamailio tries to read a request from a TCP socket but the connection has been reset (not properly ended) by the remote peer. Is it an error? Does it prevent Kamailio from working properly? If yes, what is the solution? Thanks, Mickael

2 1

RFC: Config files installation
by Daniel-Constantin Mierla 06 May '15

06 May '15

Hello, cross posting to get heads up of everyone that wants to join the discussion, however, do reply to sr-dev(a)lists.sip-router.org, being more related to development and project files structure. At this moment we install three kamailio configuration files: - kamailio.cfg - the default one to be used when starting kamailio - kamailio-basic.cfg - a more simple version of configuration - kamailio-advanced.cfg - a more complex version (equivalent of kamailio-oob.cfg in etc/ source tree) Somehow it was suggested that apart of kamailio.cfg, the other files belong more to the docs (shared) folder (where we put INSTALL, README, etc), because they are not actually used as configuration files by kamailio installation (one has to change either init.d script or copy over kamailio.cfg). Also, some are confused not knowing if they are used or not at runtime. Shall we relocate where those files are deployed by installation? Another point: we deploy the radius dictionary with the core. I think it should be deployed by a radius module and be part of radius modules package. The question is which module should deploy it? Is auth_radius fine for everyone? Alternative would be acc_radius. To complete the cleanup of etc/ folder in the source code, I think the sip-router*.cfg files should me moved to examples/, at quick look they are invalid, using paths to old ser modules, no longer available at this moment (therefore I guess nobody is using them). Opinions and other suggestions are very welcome! Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com

1 0

Re: [SR-Users] issue with TLS and 2 NIC interfaces
by Slava Bendersky 06 May '15

06 May '15

Hello Vik, I don't have same problem it works fine for me, but I have same setup on public side where multiply aliases on interface is involved. Slava. From: "Vik Killa" <vipkilla(a)gmail.com> To: "sr-users" <sr-users(a)lists.sip-router.org> Sent: Monday, May 4, 2015 12:54:21 PM Subject: Re: [SR-Users] issue with TLS and 2 NIC interfaces Are you having the same problem as myself? Thanks, V On Fri, May 1, 2015 at 8:20 PM, Slava Bendersky < volga629(a)networklab.ca > wrote: Hello Vik, I have similar setup, try define you server configuration in tls.cfg [server:ip address of alias interface:port of alias interface] method = TLSv1 verify_certificate = no require_certificate = no private_key = certificate = ca_list = crl = Slava From: "Vik Killa" < vipkilla(a)gmail.com > To: "sr-users" < sr-users(a)lists.sip-router.org > Sent: Wednesday, April 29, 2015 4:32:21 PM Subject: [SR-Users] issue with TLS and 2 NIC interfaces Hello, if i have two interfaces (eth0 and eth0:0) I set kamailio to listen to the IP on eth0:0 This works great except when I try using TLS, kamailio routes traffic from eth0:0 to eth0 then to correct destination It should be just doing eth0:0 -> correct destination If I use UDP/TCP I am not seeing this behavior. If I set kamailio to listen to eth0 and remove eth0;0, TLS works fine. I'm running kamailio compiled from source git master a few days ago. Is anyone else having this problem? I'm wondering if it's a bug. Thanks, V _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

3 3

Strange behavior for TCP and UDP SIP Routing
by Grant Bagdasarian 06 May '15

06 May '15

Hello, I have a Kamailio machine configured with two interfaces. One public, one private. Public Address: 10.10.10.10 Private Address: 192.168.1.10 Kamailio forwards the SIP packet to another local endpoint: 192.168.1.20 When a client sends a SIP packet using TCP to the public address of Kamailio, Kamailio relays the packet using its private interface (private address) to the other endpoint. TCP: Client -> 10.10.10.10 -> 192.168.1.10 -> 192.18.1.20 When a client sends a SIP packet using UDP to the public address of Kamailio, Kamailio (or the OS) relays the packet using its public interface (public address) to the other endpoint. UDP: Client -> 10.10.10.10 -> 10.10.10.10 -> 192.18.1.20 In the case of TCP, the source address is 192.168.1.10. In the case of UDP, the source address is 10.10.10.10. Everything is the same in the routing script for both UDP and TCP, except in route[relay] (see below) Is this normal? What is causing this, the OS or Kamailio? Route[RELAY] { ... if($pr =~ "TCP") { if (!t_relay_to_tcp()) { sl_reply_error(); } } else { if (!t_relay_to_udp()) { sl_reply_error(); } } }

2 2

rtpengine, turn fallback
by Isuru Wijesinghe 06 May '15

06 May '15

Hi All I'm using rtpengine to in my implementation of webrtc. In my client side browser I have used following code snippet to configure stun/turn servers to identify ice candidates and turn fall back. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> var pcConfig = {"iceServers": [ {'url': 'turn:52.6.57.126:3478?transport=tcp'}]}; peerConn = new PeerConnection(pcConfig); >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Am using rfc 5766 turn server http://code.google.com/p/rfc5766-turn-server/ As long as stun is working my webrtc flow works fine. I wanted to know how rtpengine support the turn fallback, is there any configuration required in this case. Regards Isuru

2 1

Double record routes
by Mickael Marrache 06 May '15

06 May '15

Hi, We are adding TCP support to our load balancer and for some reason it adds two record route headers. The instance have two IP addresses on which it binds: one if the VIP address and the second is the non-VIP address. I explicitly set the tcp_source_ipv4 parameter with the VIP address so that it is used as source address for outbound TCP connection. So, we get the following INVITE going from the load balancer to a proxy: T 2015/05/05 12:08:49.715822 VIP:54667 -> PROXY:5060 [AP] INVITE sip:123@mycompany.com SIP/2.0. Record-Route: <sip:NONVIP;transport=tcp;r2=on;lr>. Record-Route: <sip:VIP;transport=tcp;r2=on;lr>. Via: SIP/2.0/TCP NONVIP;branch=z9hG4bK6f4.688efa90a17e02181ef7a11fecf8bb72.0;i=3. Via: SIP/2.0/TCP 1.1.1.1:4598;received=2.2.2.2;branch=z9hG4bKmqFaCxNo6m3f5LW4;rport=40020. You can see the INVITE is sent from the VIP address (as specified using the tcp_source_ipv4 parameter). However, the added Via corresponds to the non-VIP address. Also, you can see the two record route headers added for both addresses. Any idea? Thanks, Mickael

3 5

sht_rm_name_re() question
by Yufei Tao 05 May '15

05 May '15

Hi I've hit a problem with sht_rm_name_re() in htable module. I was calling it like this: sht_rm_name_re("Dlg=>$var(callid)::tenant"); But when I used sipp to generate 600 concurrent calls for example, I called this function when receiving BYE. But it removed more entries than it should. Seems when removing removing some entry with callid 1-3798(a)192.168.60.80, it also removed entries for [1-9]1-3798(a)192.168.60.80. How do I add '^' in front and '$' at the end of the regexp string when calling this function please? Here I don't really need regexp in fact, just want to do an exact match. But I didn't find any other functions for deleting entries. Thank you! Yufei

2 1

UAC not answer with new register after 401 reply from porvider
by Yuriy Gorlichenko 05 May '15

05 May '15

Hello. We have an issue with REGISTER to Provider. When Provider answers 401 Kamailio don't send any REGISTER with digest auth IP ourservice.com.5068 > provider.dev.5060: UDP, length 468 E...U...@.3' ..............AREGISTER sip:provider.dev SIP/2.0 Via: SIP/2.0/UDP ourservice.com:5068 ;branch=z9hG4bK4238.45a4a626000000000000000000000000.0 To: <sip:login@provider.dev> From: <sip:login@provider.dev>;tag=6a39af2190f8b2c99cc63bfeb3a3959c-1ff8 CSeq: 10 REGISTER Call-ID: 1b3f9f5d5822eca2-16804(a)ourservice.com Max-Forwards: 70 Content-Length: 0 User-Agent: kamailio (4.3.0-dev5 (x86_64/linux)) Contact: <sip:login@ourservice.com:5068> Expires: 360 IP provider.dev.5060 > ourservice.com.5068: UDP, length 572 E..XC...-.W..... ........DkJSIP/2.0 401 Unauthorized Via: SIP/2.0/UDP ourservice.com:5068 ;branch=z9hG4bK4238.45a4a626000000000000000000000000.0;received=23.100.24.250 From: <sip:login@provider.dev>;tag=6a39af2190f8b2c99cc63bfeb3a3959c-1ff8 To: <sip:login@provider.dev>;tag=as6ad61d4a Call-ID: 1b3f9f5d5822eca2-16804(a)ourservice.com CSeq: 10 REGISTER Server: FastTel SoftSwitch Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces WWW-Authenticate: Digest algorithm=MD5, realm="provider.dev", nonce="63fc6951" Content-Length: 0

2 3

Kamailio proxy for far-end nat traversal
by rahul.ultimate 05 May '15

05 May '15

Hello I need a small guidance on creating a light weight proxy which only forwards the msgs to my sip server and also does supports symmetrical nated clients. The way I have created the configuration is a slight modification of : https://github.com/xlab1/sipfe_kamailio/blob/master/kamailio.cfg Problem is unless the sip clients use STUN media packets are not routed. And sometimes even the signalling does not pass through. Should i not use fix_nated_register and switch to fix _ nated_contact always ? Because in all those cases where signalling does not pass through, I see RTO. My best guess is kamailio trying to communicate with private ip. Anything which I can try that you could suggest from the top of yourmind woyld be muc appreciated. Thanks Rahul Sent from Samsung Mobile

2 1

Re: [SR-Users] issue with TLS and 2 NIC interfaces
by Slava Bendersky 04 May '15

04 May '15

Hello Vik, I have similar setup, try define you server configuration in tls.cfg [server:ip address of alias interface:port of alias interface] method = TLSv1 verify_certificate = no require_certificate = no private_key = certificate = ca_list = crl = Slava From: "Vik Killa" <vipkilla(a)gmail.com> To: "sr-users" <sr-users(a)lists.sip-router.org> Sent: Wednesday, April 29, 2015 4:32:21 PM Subject: [SR-Users] issue with TLS and 2 NIC interfaces Hello, if i have two interfaces (eth0 and eth0:0) I set kamailio to listen to the IP on eth0:0 This works great except when I try using TLS, kamailio routes traffic from eth0:0 to eth0 then to correct destination It should be just doing eth0:0 -> correct destination If I use UDP/TCP I am not seeing this behavior. If I set kamailio to listen to eth0 and remove eth0;0, TLS works fine. I'm running kamailio compiled from source git master a few days ago. Is anyone else having this problem? I'm wondering if it's a bug. Thanks, V _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

2 1

kamcli - kamailio command line control tool
by Daniel-Constantin Mierla 04 May '15

04 May '15

Hello, we just published a new command line tool for Kamailio management, named now kamcli, available at: * https://github.com/asipto/kamcli It is written in Python and adapted from a tool provided originally by a subcontractor for a specific deployment. While not being Python developers here, the benefits and flexibility proved extremely good. At this stage it is more an attempt to see if the community finds it useful and worth to get it developed further as part of Kamailio project. Short about the benefits/flexibility: - python is by default installed on OSes (including Mac OS X) (as opposite to Lua, for example) - became rather fast since Google invested in it - lot more knowledge base and developers out there (as opposite to Lua or Perl), along with tons of extensions - implementation is based on a CLI framework (Click) that makes it extremely easy to add new commands in a plugin-like fashion, therefore is easy to have custom commands when having specific needs (e.g., managing a custom database table used in kamailio.cfg via sqlops => add a new cmd_xyz.py in commands subfolder, without touching other files, not even the config) - help message is embedded in the command code file, making it easier to document commands - easy to validate parameters as well as format the output - handling kamcli configuration file options is also easy (ini format) One of my reasons of pushing this out was in the perspective of deprecating MI and working with JSONRPC fifo from command line -- I couldn't find easy ways to manage json docs with shell and common tools (e.g., cat, echo, grep, awk) only. Kamcli has implemented the JSONRPC over fifo command (see also jsonrpc-s kamailio module). Still, given the old initial implementation, at this moment, kamcli is relying on MI via fifo (mi_fifo) for some of the commands (e.g., dumping usrloc records from memory) -- (Just as side note: perhaps here we need to do a mapping, because name of commands are different, if we want to make a 'ctl transport agnostic' tool.) Here are few things to decide: - does it sound useful and are people finding it worth to develop it further? - what about the name, is it ok? Another one? If worth developing and deciding on the name, then the plan is to host the project on kamailio organization on github so each kamailio developer can code on it (it won't be inside kamailio source code tree, but a separate project inside same organization). So far, couple of commands were implemented when comparing with kamctl: - subscriber management (kamctl add/rm/passwd...) - user location management (kamctl ul ...) - database querying (kamctl db ...) - statistics (kamctl stats ...) - mi commands (kamctl mi ...) - jsonrpc commands (not in kamctl) While cross posted for the sake of getting the info to everyone in the community, let's have further discussions on sr-dev. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com

2 1

TLSv1.2 and weak ciphers
by Attila Megyeri 04 May '15

04 May '15

Hi Daniel, Kamailio folks, We are trying to make our server more secure, but we have some issues. Right now, we have set the TLS method to method = TLSv1+ and cipher_list = HIGH The problem is, that there are still cipher suites offered which are not secure. E.g. If I check with the SSLLabs analizer, I see: This server supports anonymous (insecure) suites (see below for details). Grade set to F. Cipher Suites (SSL 3+ suites in server-preferred order; deprecated and SSL 2 suites always at the end) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH 256 bits (eq. 3072 bits RSA) FS 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH 256 bits (eq. 3072 bits RSA) FS 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH 256 bits (eq. 3072 bits RSA) FS 256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 3072 bits (p: 384, g: 1, Ys: 384) FS 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 3072 bits (p: 384, g: 1, Ys: 384) FS 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 3072 bits (p: 384, g: 1, Ys: 384) FS 256 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88) DH 3072 bits (p: 384, g: 1, Ys: 384) FS 256 TLS_ECDH_anon_WITH_AES_256_CBC_SHA (0xc019) INSECURE 256 TLS_DH_anon_WITH_AES_256_GCM_SHA384 (0xa7) INSECURE 256 TLS_DH_anon_WITH_AES_256_CBC_SHA256 (0x6d) INSECURE 256 TLS_DH_anon_WITH_AES_256_CBC_SHA (0x3a) INSECURE 256 TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA (0x89) INSECURE 256 TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) 256 TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) 256 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84) 256 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) ECDH 256 bits (eq. 3072 bits RSA) FS 112 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) DH 3072 bits (p: 384, g: 1, Ys: 384) FS 112 TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA (0xc017) INSECURE 112 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA (0x1b) INSECURE 112 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH 256 bits (eq. 3072 bits RSA) FS 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH 256 bits (eq. 3072 bits RSA) FS 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 256 bits (eq. 3072 bits RSA) FS 128 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 3072 bits (p: 384, g: 1, Ys: 384) FS 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67) DH 3072 bits (p: 384, g: 1, Ys: 384) FS 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 3072 bits (p: 384, g: 1, Ys: 384) FS 128 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45) DH 3072 bits (p: 384, g: 1, Ys: 384) FS 128 TLS_ECDH_anon_WITH_AES_128_CBC_SHA (0xc018) INSECURE 128 TLS_DH_anon_WITH_AES_128_GCM_SHA256 (0xa6) INSECURE 128 TLS_DH_anon_WITH_AES_128_CBC_SHA256 (0x6c) INSECURE 128 TLS_DH_anon_WITH_AES_128_CBC_SHA (0x34) INSECURE 128 TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA (0x46) INSECURE 128 TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) 128 TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) 128 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41) 128 How can we get rid of these _anon_ cipher suites? Thanks Attila

1 1

Auth User & is_subscriber
by jay binks 04 May '15

04 May '15

Hey, from the examples it looks like the typical usage of is_subscriber is with $fu ( From User ), however im not 100% sure I want this. in-fact, I want it to be the Auth User that is used. After all if a call was Authed, then we authoritatively know what user it is, and I think this should be used over and above the from user ( which could even be set to caller Id in some cases ). Im having some trouble getting is_subscriber to work with the Auth user, does anyone have an example of this working somewhere ? -- Sincerely Jay

2 1

WebSocket data in TCP connection
by mayamatakeshi 04 May '15

04 May '15

Hello, about module websocket, is it possible to associate a value with the TCP connection and have this value readable when handling SIP requests on that connection?

1 4

Regd: Message Routing
by suryakiiran vanam 04 May '15

04 May '15

Hi Team, I am using Jitsi client with Kamailio. I was able to IM between the clients. How can I control the Message routing in Kamailio script. Please help me with any link. Regards, Surya.

2 1

WebRTC video calls
by Ivan Vujisic 04 May '15

04 May '15

I made successful audio calls from browser to browser using Asterisk 13.1 and SIPML5 browser phone. Asterisk can't manage WebRTC video calls due to lack of codec negotiation module, but I also faced RTP ports NAT traversal issue. To my understanding Kamailio is capable to resolve this. Can anybody confirm that he made successful browser to browser video calls with Kamailio sip proxy / registrar in front of Asterisk PBX. Also, any link to good tutorial or doc pages will be appreciated. Best Regards, Ivan Vujisic

2 1

UAC Module
by Ali Jibran 02 May '15

02 May '15

Hi all. I have this setup. Trunk--->Kamailio---->FreeSWITCH I have a trunk from a sip provided and registered successfully with the UAC module. Incoming is working fine. I need to make out going through kamailio too. I have it in the dialplan to forward the invite to kamailio from FreeSWITCH. I can see it the logs that it reaches kamailio. Now how do I make the call via the trunk? Basically this is what I'm trying to workout FS---->kamailio---->trunk. Any help will be much appreciated. Thanks. AJ

3 7

Re: [SR-Users] [SR_USers] Authenticate asterisk-kamailio
by Mauricio Tejeda 30 Apr '15

30 Apr '15

Hi. Asterisk users are fine. Register subscribers Kamailio is my problem. #!ifdef WITH_ASTERISK if (!auth_check("$fd", "sipusers", "1")) { ##### OK Asterisk Users are no problem #!else ##### But if the user is no asterisk , simply refuse registration, without Respect the jump to validate users Kamailio if (!auth_check("$fd", "subscriber", "1")) { #!endif ##### Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: auth_db [authorize.c:498]: auth_check(): realm [192.168.65.132] table [sipusers] flags [1] Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: auth [api.c:86]: pre_auth(): auth:pre_auth: Credentials with realm '192.168.65.132' not found Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: auth_db [authorize.c:264]: digest_authenticate_hdr(): no credentials Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: auth [challenge.c:127]: get_challenge_hf(): build_challenge_hf: realm='192.168.65.132' Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: auth [challenge.c:269]: get_challenge_hf(): auth: 'WWW-Authenticate: Digest realm="192.168.65.132", nonce="VUDgjFVA32CFnv6lYnT/fxOzv3M7Mw7n"#015#012' Thanks. De: sr-users [mailto:sr-users-bounces@lists.sip-router.org] En nombre de SamyGo Enviado el: jueves, 30 de abril de 2015 4:39 Para: Kamailio (SER) - Users Mailing List Asunto: Re: [SR-Users] [SR_USers] Authenticate asterisk-kamailio Hi, The important thing to consider here is this line. #!define WITH_ASTERISK so if you've defined this on the very top of your kamailio.cfg then it will go and check username/passwords from the sipusers table from the Database defined by this: DBASTURL if (!auth_check("$fd", "sipusers", "1")) { Make sure you've the same user defined and username and passwords are defined in these columns: modparam("auth_db", "user_column", "name") modparam("auth_db", "password_column", "sippasswd") the sipasswd column is text based so dont use encrypted PASSWORD() in there. Once you follow these steps your user should get registered.

2 2

[SR_USers] Authenticate asterisk-kamailio
by Mauricio Tejeda 30 Apr '15

30 Apr '15

Hello All. My English is bad so I hope you can understand. I have been working with Kamailio some time, I following some of Guides of http://kb.asipto.com, http://saevolgo.blogspot.com and http://nil.uniza.sk. To Authenticate Asterisk sipusers I'm not have problems, but subscriber of Kamailio authenticate is my problem. Autenticate are denied to subscriber Kamailio. In spanish I can explain it better :-) best regards my Settings: ####################### # ----- auth_db params ----- #!ifdef WITH_AUTH modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "load_credentials", "") #!ifdef WITH_ASTERISK modparam("auth_db", "user_column", "name") modparam("auth_db", "password_column", "sippasswd") modparam("auth_db", "db_url", DBASTURL) modparam("auth_db", "version_table", 0) #!else modparam("auth_db", "db_url", DBURL) modparam("auth_db", "password_column", "password") modparam("auth_db", "use_domain", MULTIDOMAIN) #!endif #################### #!ifdef WITH_AUTH #!ifdef WITH_ASTERISK # do not auth traffic from Asterisk - trusted! if(route(FROMASTERISK)) return; #!endif #!ifdef WITH_IPAUTH if((!is_method("REGISTER")) && allow_source_address()) { # source IP allowed return; } #!endif if (is_method("REGISTER") || from_uri==myself) { # authenticate requests #!ifdef WITH_ASTERISK if (!auth_check("$fd", "sipusers", "1")) { #### Aquí autentifica sin problemas en caso de ser un usuario asterisk #!else #### Pero hace caso omiso al switch. if (!auth_check("$fd", "subscriber", "1")) { #### No autentifica subscriber de la base de datos de kamailio #!endif auth_challenge("$fd", "0"); exit; } # user authenticated - remove auth header if(!is_method("REGISTER|PUBLISH")) consume_credentials(); } #!endif return; } ######################### DEBUG KAMAILIO Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [parser/msg_parser.c:623]: parse_msg(): SIP Request: Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [parser/msg_parser.c:625]: parse_msg(): method: <REGISTER> Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [parser/msg_parser.c:627]: parse_msg(): uri: <sip:192.168.65.132> Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [parser/msg_parser.c:629]: parse_msg(): version: <SIP/2.0> Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of header reached, state=10 Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [parser/msg_parser.c:190]: get_hdr_field(): DEBUG: get_hdr_field: <To> [29]; uri=[sip:107@192.168.65.132] Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body [107<sip:107@192.168.65.132>#015#012] Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-d87543-733510592-1--d87543->; state=6 Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 235, <rport> = <n/a>; state=17 Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of header reached, state=5 Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via found, flags=2 Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [parser/msg_parser.c:515]: parse_headers(): parse_headers: this is the first via Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [receive.c:154]: receive_msg(): After parse_msg... Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [receive.c:197]: receive_msg(): preparing to run routing scripts... Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <1> <REGISTER> Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: maxfwd [mf_funcs.c:85]: is_maxfwd_present(): value = 70 Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [parser/msg_parser.c:204]: get_hdr_field(): DEBUG: get_hdr_body : content_length=0 Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [parser/msg_parser.c:106]: get_hdr_field(): found end of header Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG: add_param: tag=306ac106 Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of header reached, state=29 Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: sanity [mod_sanity.c:255]: w_sanity_check(): sanity checks result: 1 Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: siputils [checks.c:103]: has_totag(): no totag Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: tm [t_lookup.c:1072]: t_check_msg(): DEBUG: t_check_msg: msg id=2 global id=1 T start=0xffffffffffffffff Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: tm [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start searching: hash=16161, isACK=0 Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: tm [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction matching failed Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: tm [t_lookup.c:709]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: tm [t_lookup.c:1141]: t_check_msg(): DEBUG: t_check_msg: msg id=2 global id=2 T end=(nil) Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 14==14 && [192.168.65.132] == [192.168.65.132] Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [select.c:429]: run_select(): Calling SELECT 0x7f213171d950 Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [select.c:429]: run_select(): Calling SELECT 0x7f21317216c0 Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: auth_db [authorize.c:498]: auth_check(): realm [192.168.65.132] table [sipusers] flags [1] Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: auth [api.c:86]: pre_auth(): auth:pre_auth: Credentials with realm '192.168.65.132' not found Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: auth_db [authorize.c:264]: digest_authenticate_hdr(): no credentials Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: auth [challenge.c:127]: get_challenge_hf(): build_challenge_hf: realm='192.168.65.132' Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: auth [challenge.c:269]: get_challenge_hf(): auth: 'WWW-Authenticate: Digest realm="192.168.65.132", nonce="VUDgjFVA32CFnv6lYnT/fxOzv3M7Mw7n"#015#012' Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: sl [sl.c:296]: send_reply(): reply in stateless mode (sl) Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [xavp.c:448]: xavp_destroy_list(): destroying xavp list (nil) Apr 29 10:40:48 labkamailio kamailio[11304]: DEBUG: <core> [receive.c:298]: receive_msg(): receive_msg: cleaning up Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [parser/msg_parser.c:623]: parse_msg(): SIP Request: Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [parser/msg_parser.c:625]: parse_msg(): method: <REGISTER> Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [parser/msg_parser.c:627]: parse_msg(): uri: <sip:192.168.65.132> Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [parser/msg_parser.c:629]: parse_msg(): version: <SIP/2.0> Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of header reached, state=10 Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [parser/msg_parser.c:190]: get_hdr_field(): DEBUG: get_hdr_field: <To> [29]; uri=[sip:107@192.168.65.132] Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body [107<sip:107@192.168.65.132>#015#012] Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-d87543-600273073-1--d87543->; state=6 Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 235, <rport> = <n/a>; state=17 Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of header reached, state=5 Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via found, flags=2 Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [parser/msg_parser.c:515]: parse_headers(): parse_headers: this is the first via Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [receive.c:154]: receive_msg(): After parse_msg... Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [receive.c:197]: receive_msg(): preparing to run routing scripts... Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <2> <REGISTER> Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: maxfwd [mf_funcs.c:85]: is_maxfwd_present(): value = 70 Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [parser/msg_parser.c:204]: get_hdr_field(): DEBUG: get_hdr_body : content_length=0 Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [parser/msg_parser.c:106]: get_hdr_field(): found end of header Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG: add_param: tag=306ac106 Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of header reached, state=29 Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: sanity [mod_sanity.c:255]: w_sanity_check(): sanity checks result: 1 Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: siputils [checks.c:103]: has_totag(): no totag Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: tm [t_lookup.c:1072]: t_check_msg(): DEBUG: t_check_msg: msg id=2 global id=1 T start=0xffffffffffffffff Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: tm [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start searching: hash=16158, isACK=0 Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: tm [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction matching failed Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: tm [t_lookup.c:709]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: tm [t_lookup.c:1141]: t_check_msg(): DEBUG: t_check_msg: msg id=2 global id=2 T end=(nil) Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 14==14 && [192.168.65.132] == [192.168.65.132] Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [select.c:429]: run_select(): Calling SELECT 0x7f213171d950 Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [select.c:429]: run_select(): Calling SELECT 0x7f21317216c0 Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: auth_db [authorize.c:498]: auth_check(): realm [192.168.65.132] table [sipusers] flags [1] Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: auth [api.c:96]: pre_auth(): auth: digest-algo: MD5 parsed value: 1 Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [db_res.c:118]: db_new_result(): allocate 56 bytes for result set at 0x7f213171c1a0 Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: db_mysql [km_res.c:68]: db_mysql_get_columns(): 1 columns returned from the query Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [db_res.c:156]: db_allocate_columns(): allocate 8 bytes for result names at 0x7f21317236a8 Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [db_res.c:167]: db_allocate_columns(): allocate 4 bytes for result types at 0x7f2131739f10 Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: db_mysql [km_res.c:86]: db_mysql_get_columns(): allocate 16 bytes for RES_NAMES[0] at 0x7f21317605f8 Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: db_mysql [km_res.c:93]: db_mysql_get_columns(): RES_NAMES(0x7f21317605f8)[0]=[sippasswd] Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: db_mysql [km_res.c:137]: db_mysql_get_columns(): use DB1_STRING result type Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: db_mysql [km_res.c:170]: db_mysql_convert_rows(): no rows returned from the query Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: auth_db [authorize.c:196]: get_ha1(): no result for user '107@' Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [db_res.c:81]: db_free_columns(): freeing 1 columns Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [db_res.c:85]: db_free_columns(): freeing RES_NAMES[0] at 0x7f21317605f8 Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [db_res.c:94]: db_free_columns(): freeing result names at 0x7f21317236a8 Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [db_res.c:99]: db_free_columns(): freeing result types at 0x7f2131739f10 Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [db_res.c:136]: db_free_result(): freeing result set at 0x7f213171c1a0 Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: auth [challenge.c:127]: get_challenge_hf(): build_challenge_hf: realm='192.168.65.132' Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: auth [challenge.c:269]: get_challenge_hf(): auth: 'WWW-Authenticate: Digest realm="192.168.65.132", nonce="VUDgjFVA32CFnv6lYnT/fxOzv3M7Mw7n"#015#012' Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: sl [sl.c:296]: send_reply(): reply in stateless mode (sl) Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [xavp.c:448]: xavp_destroy_list(): destroying xavp list (nil) Apr 29 10:40:48 labkamailio kamailio[11302]: DEBUG: <core> [receive.c:298]: receive_msg(): receive_msg: cleaning up Ngrep sipusers asterisk U 192.168.65.1:6018 -> 192.168.65.132:5060 REGISTER sip:192.168.65.132 SIP/2.0. To: 101<sip:101@192.168.65.132>. From: 101<sip:101@192.168.65.132>;tag=622d132b. Via: SIP/2.0/UDP 192.168.65.1:6018;branch=z9hG4bK-d87543-11473800-1--d87543-;rport. Call-ID: 45522f4e99747d39. CSeq: 1 REGISTER. Contact: <sip:101@192.168.65.1:6018>. Expires: 3600. Max-Forwards: 70. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 3004w stamp 16863. Content-Length: 0. . # U 192.168.65.132:5060 -> 192.168.65.1:6018 SIP/2.0 401 Unauthorized. To: 101<sip:101@192.168.65.132>;tag=65b56d053bca97da69d7accef5da903f.bfcc. From: 101<sip:101@192.168.65.132>;tag=622d132b. Via: SIP/2.0/UDP 192.168.65.1:6018;branch=z9hG4bK-d87543-11473800-1--d87543-;rport=6018;recei ved=192.168.65.1. Call-ID: 45522f4e99747d39. CSeq: 1 REGISTER. WWW-Authenticate: Digest realm="192.168.65.132", nonce="VUDfOlVA3g5sSAKxFPg/zsB0qvueMh8Y". Server: kamailio (4.2.4 (x86_64/linux)). Content-Length: 0. . # U 192.168.65.1:6018 -> 192.168.65.132:5060 REGISTER sip:192.168.65.132 SIP/2.0. To: 101<sip:101@192.168.65.132>. From: 101<sip:101@192.168.65.132>;tag=622d132b. Via: SIP/2.0/UDP 192.168.65.1:6018;branch=z9hG4bK-d87543-426128389-1--d87543-;rport. Call-ID: 45522f4e99747d39. CSeq: 2 REGISTER. Contact: <sip:101@192.168.65.1:6018>. Expires: 3600. Max-Forwards: 70. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 3004w stamp 16863. Authorization: Digest username="101",realm="192.168.65.132",nonce="VUDfOlVA3g5sSAKxFPg/zsB0qvueMh8 Y",uri="sip:192.168.65.132",response="792b60f48b2da3bb93f5d808fd87c09c",algo rithm=MD5. Content-Length: 0. . # U 192.168.65.132:5060 -> 192.168.65.1:6018 SIP/2.0 200 OK. To: 101<sip:101@192.168.65.132>;tag=65b56d053bca97da69d7accef5da903f.92bc. From: 101<sip:101@192.168.65.132>;tag=622d132b. Via: SIP/2.0/UDP 192.168.65.1:6018;branch=z9hG4bK-d87543-426128389-1--d87543-;rport=6018;rece ived=192.168.65.1. Call-ID: 45522f4e99747d39. CSeq: 2 REGISTER. Contact: <sip:101@192.168.65.1:6018>;expires=3600. Server: kamailio (4.2.4 (x86_64/linux)). Content-Length: 0. Ngrep subscriber Kamailio U 192.168.65.1:6018 -> 192.168.65.132:5060 REGISTER sip:192.168.65.132 SIP/2.0. To: 107<sip:107@192.168.65.132>. From: 107<sip:107@192.168.65.132>;tag=7b070e2d. Via: SIP/2.0/UDP 192.168.65.1:6018;branch=z9hG4bK-d87543-536609279-1--d87543-;rport. Call-ID: 77019a2d9e70df3f. CSeq: 1 REGISTER. Contact: <sip:107@192.168.65.1:6018>. Expires: 3600. Max-Forwards: 70. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 3004w stamp 16863. Content-Length: 0. . # U 192.168.65.132:5060 -> 192.168.65.1:6018 SIP/2.0 401 Unauthorized. To: 107<sip:107@192.168.65.132>;tag=65b56d053bca97da69d7accef5da903f.1c0e. From: 107<sip:107@192.168.65.132>;tag=7b070e2d. Via: SIP/2.0/UDP 192.168.65.1:6018;branch=z9hG4bK-d87543-536609279-1--d87543-;rport=6018;rece ived=192.168.65.1. Call-ID: 77019a2d9e70df3f. CSeq: 1 REGISTER. WWW-Authenticate: Digest realm="192.168.65.132", nonce="VUDf21VA3q+Px29K8cRa5tWIadNTI5e6". Server: kamailio (4.2.4 (x86_64/linux)). Content-Length: 0. . # U 192.168.65.1:6018 -> 192.168.65.132:5060 REGISTER sip:192.168.65.132 SIP/2.0. To: 107<sip:107@192.168.65.132>. From: 107<sip:107@192.168.65.132>;tag=7b070e2d. Via: SIP/2.0/UDP 192.168.65.1:6018;branch=z9hG4bK-d87543-1058472151-1--d87543-;rport. Call-ID: 77019a2d9e70df3f. CSeq: 2 REGISTER. Contact: <sip:107@192.168.65.1:6018>. Expires: 3600. Max-Forwards: 70. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 3004w stamp 16863. Authorization: Digest username="107",realm="192.168.65.132",nonce="VUDf21VA3q+Px29K8cRa5tWIadNTI5e 6",uri="sip:192.168.65.132",response="c9ca6eff16e3b661337b6d99d74027de",algo rithm=MD5. Content-Length: 0. . # U 192.168.65.132:5060 -> 192.168.65.1:6018 SIP/2.0 401 Unauthorized. To: 107<sip:107@192.168.65.132>;tag=65b56d053bca97da69d7accef5da903f.8cc0. From: 107<sip:107@192.168.65.132>;tag=7b070e2d. Via: SIP/2.0/UDP 192.168.65.1:6018;branch=z9hG4bK-d87543-1058472151-1--d87543-;rport=6018;rec eived=192.168.65.1. Call-ID: 77019a2d9e70df3f. CSeq: 2 REGISTER. WWW-Authenticate: Digest realm="192.168.65.132", nonce="VUDf21VA3q+Px29K8cRa5tWIadNTI5e6". Server: kamailio (4.2.4 (x86_64/linux)). Content-Length: 0. .

2 2

Transaction good practices with t_relay t_newtran and t_release
by Dirk Teurlings - SIGNET B.V. 30 Apr '15

30 Apr '15

Hi, In our config we don't use presence, but I do have a question about transactions. We're using dialogs as well as transactions in the routing. To keep things simplyfied, let's assume we have the following stripped out route setup: request_route { if (is_method("CANCEL")) { if (t_check_trans()) { t_relay(); } exit; } # As stated in documentation, this call could stop further # routing from here on out t_check_trans(); if (is_method("INVITE")) { if (ds_is_from_list()) { setflag(DLG_FLAG); } setflag(FLT_ACC); } if (lookup("loction") == -1 ) { if(load_gws(1)) { t_newtran(); t_on_failure("TFAIL"); } } } route[TFAIL] { xlog("L_ERR", "Failed setting up transaction"); } What I'd like to know is when or even if we need to be releasing the transaction at some point. From what I understand in the presence example I should be releasing a transaction when I use t_newtran, but I haven't found any evidence of needing it when working with t_relay or t_check_trans. For example, could it be needed to do a t_release() on a dialog_terminated or dialog_end event? In the above example, would it just be enough to add t_release() to the failure route TFAIL? Further details about how and/or when the transactions are cleaned up internally would be greatly appreciated! -- Kind regards, Dirk Teurlings

4 5

SIP INVITE and To Header
by Andres 30 Apr '15

30 Apr '15

I have a general question maybe somebody can help me out with. We have a new SIP Trunk setup with a provider. The SIP Trunk has a username of 'jane' and it handles 400 DIDs. When the incoming INVITE from the provider comes in, the URI in the Invite is the username of the trunk while the To header actually has the dialed number. As long as I can remember I have always seen the Invite as having the same URI as the To Header in the initial INVITE but not so here. 18:17:34.786 SIP.STACK MSG INVITE sip:jane@10.5.5.5:5060;transport=UDP SIP/2.0 18:17:34.787 SIP.STACK MSG Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK290hka10e8j11dn7k0k0.1 18:17:34.788 SIP.STACK MSG From: "Test "<sip:9541112222@voip.xxx.net;user=phone>;tag=1574552918-1430345854933- 18:17:34.788 SIP.STACK MSG To: "Customer"<sip:2222222222@voip.xxx.net> I am inclined to believe this is perfectly normal and compliant but let me know what you think. Thanks, -- Technical Support http://www.cellroute.net

2 4

Re: [SR-Users] sr-users Digest, Vol 119, Issue 28
by Yufei Tao 30 Apr '15

30 Apr '15

Hi I've realised that I should put '^' after "Dlg=>" (rather than before), i.e. sht_rm_name_re("Dlg=>^$var(callid)::tenant"); - this works. But it doesn't seem to like '$' at the end of the regexp - Kamailio failed to start up with error: "ERROR: htable [ht_var.c:176]: pv_parse_ht_name(): wrong format". Any way to use the end-of-line symbol? Cheers, Yufei > ------------------------------ > > Message: 10 > Date: Wed, 29 Apr 2015 18:01:26 +0100 > From: Yufei Tao <yufei.tao(a)gmail.com> > To: sr-users(a)lists.sip-router.org > Subject: [SR-Users] sht_rm_name_re() question > Message-ID: > < > CAJwP0iTwhcTj6SJWABHj+eGDqQv13wV_e1wC2s1Na2+WoSuJGA(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi > > I've hit a problem with sht_rm_name_re() in htable module. I was calling it > like this: > > sht_rm_name_re("Dlg=>$var(callid)::tenant"); > > But when I used sipp to generate 600 concurrent calls for example, I called > this function when receiving BYE. But it removed more entries than it > should. Seems when removing removing some entry with callid > 1-3798(a)192.168.60.80, it also removed entries for [1-9] > 1-3798(a)192.168.60.80. > > > How do I add '^' in front and '$' at the end of the regexp string when > calling this function please? Here I don't really need regexp in fact, just > want to do an exact match. But I didn't find any other functions for > deleting entries. > > Thank you! > Yufei >

1 0

SBC and HA with Kamailio
by kai.ohnacker＠cbc.de 30 Apr '15

30 Apr '15

Hello, I'm new with Kamailio and have to do a research project with Kamailio server. My task is to realize a SIP infrastructure with NATing and a High Availability Cluster with two Kamailio server. For the NAT problem I found a solution with SEMS, but for security I need authentication on the SBC. I have no idea to synchronize the user authentication information from Kamailio to SEMS. Perhaps there is a more useful solution available? The SIP server is behind the NAT in a private network and the SBC to be placed in the DMZ. A new feature of Kamailio 4.2 is a replication for High Availability (HA), but I did not found any information about this. Is there somewhere a documentation or howto where I can look? I need only short keywords and not a complete description. Many thanks, Kai

2 1

NO VOICE AFTER MSILO
by sscc 30 Apr '15

30 Apr '15

hello i have configured msilo module successful but there isn't any voice with msilo. i debug and compare the call flow with and without msilo. with msilo in call flow it didn't follow to relay and consequently didnt activate rtpproxy befor the call is answered. due to which during call there isn't any voice. please help -- View this message in context: http://sip-router.1086192.n5.nabble.com/NO-VOICE-AFTER-MSILO-tp137429.html Sent from the Users mailing list archive at Nabble.com.

1 0

issue with TLS and 2 NIC interfaces
by Vik Killa 29 Apr '15

29 Apr '15

Hello, if i have two interfaces (eth0 and eth0:0) I set kamailio to listen to the IP on eth0:0 This works great except when I try using TLS, kamailio routes traffic from eth0:0 to eth0 then to correct destination It should be just doing eth0:0 -> correct destination If I use UDP/TCP I am not seeing this behavior. If I set kamailio to listen to eth0 and remove eth0;0, TLS works fine. I'm running kamailio compiled from source git master a few days ago. Is anyone else having this problem? I'm wondering if it's a bug. Thanks, V

1 0

Re: [SR-Users] Running Kamailio with IMS
by Abdul Hakeem 29 Apr '15

29 Apr '15

Mihail, Are you able to share your configurations for each of the elements (P-CSCF, S-CSCF and I-CSCF) ? Cheers, Abdul Hakeem -----Original Message----- From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Mihail Dakov Sent: Wednesday, April 29, 2015 1:03 PM To: miconda(a)gmail.com; Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] Running Kamailio with IMS Hi All, I solved the issue by compiling kamailio from src and running different instances for each component P-CSCF, S-CSCF, and I-CSCF with different configuration respectively. Thank you all for the support. On 04/29/2015 12:04 PM, Daniel-Constantin Mierla wrote: > Hello, > > On 29/04/15 10:06, Mihail Dakov wrote: >> Hi all, >> >> I am trying to run Kamailio server with IMS modules for which I have >> gone through the following tutorials: >> >> http://nil.uniza.sk/ngnims/kamailio-ims/preparing-debian-operating-system-k… io-4x-platform >> >> >> http://www.kamailio.org/wiki/tutorials/ims/installation-howto >> >> The problem I have is that using 'service kamailio start' I can only >> run one IMS component, say PCSCF. But I need to run all P/S/I-CSCFs. >> How do I proceed to get running P/S/I-CSCF on the same machine with >> kamailio? > you can run multiple instances of kamailio on the same system, just use > different ports for each instance. Or, if you can allocate many IP > addresses to the system, you can run one per IP. Just specify the ip and > port to listen on via global parameter: > > listen=1.2.3.4:5080 > > If you questions is about combining all those configs, perhaps is > possible, but not something I can assist with. > > Cheers, > Daniel > _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

2 1

Kamailio and rtpengine - client behind NAT
by Martin Schiøtz 29 Apr '15

29 Apr '15

Hi I'm using Kamailio 4.2.4 and rtpengine 4.0.0.0+0~mr4.0.0.0. Kamailio is configured with sip users that can register. I have also configured a sip trunk to PSTN. I'm using rtpengine to handle RTP when a client want's to call to PSTN. When a user behind NAT wants to make a call to PSTN and sends INVITE, then the rtpengine gets the SDP info from kamailio and rtppengine creates the new SDP info to be forwarded to PSTN. The problem is that when the call is established rtpengine sends RTP to 10.0.0.100 instead of sending RTP to the NAT'ed users public IP 80.71.X.X ? I thought that "fix_nated_sdp("2")" would do the job before "rtpengine_offer("asymmetric")" but it dosen't have any effect? I have included kamailio.cfg, rtpengine logs and ngrep between kamailio and rtpengine. Cheers, Martin kamailio.cfg --------------------------------------- #!KAMAILIO ## !define WITH_DEBUG #!define WITH_MYSQL #!define WITH_AUTH #!define WITH_USRLOCDB #!define WITH_NAT #!define WITH_TLS #!define WITH_PSTN # # Kamailio (OpenSER) SIP Server v3.1 - default configuration script # - web: http://www.kamailio.org # - git: http://sip-router.org # # Direct your questions about this file to: <sr-users(a)lists.sip-router.org> # # Refer to the Core CookBook at http://www.kamailio.org/dokuwiki/doku.php # for an explanation of possible statements, functions and parameters. # # Several features can be enabled using '#!define WITH_FEATURE' directives: # # *** To run in debug mode: # - define WITH_DEBUG # # *** To enable mysql: # - define WITH_MYSQL # # *** To enable authentication execute: # - enable mysql # - define WITH_AUTH # - add users using 'kamctl' # # *** To enable IP authentication execute: # - enable mysql # - enable authentication # - define WITH_IPAUTH # - add IP addresses with group id '1' to 'address' table # # *** To enable persistent user location execute: # - enable mysql # - define WITH_USRLOCDB # # *** To enable presence server execute: # - enable mysql # - define WITH_PRESENCE # # *** To enable nat traversal execute: # - define WITH_NAT # - install RTPProxy: http://www.rtpproxy.org # - start RTPProxy: # rtpproxy -l _your_public_ip_ -s udp:localhost:7722 # # *** To enable PSTN gateway routing execute: # - define WITH_PSTN # - set the value of pstn.gw_ip # - check route[PSTN] for regexp routing condition # # *** To enable database aliases lookup execute: # - enable mysql # - define WITH_ALIASDB # # *** To enable multi-domain support execute: # - enable mysql # - define WITH_MULTIDOMAIN # # *** To enable TLS support execute: # - adjust CFGDIR/tls.cfg as needed # - define WITH_TLS # # *** To enable XMLRPC support execute: # - define WITH_XMLRPC # - adjust route[XMLRPC] for access policy # # *** To enable anti-flood detection execute: # - adjust pike and htable=>ipban settings as needed (default is # block if more than 16 requests in 2 seconds and ban for 300 seconds) # - define WITH_ANTIFLOOD # # *** To enhance accounting execute: # - enable mysql # - define WITH_ACCDB # - add following columns to database #!ifdef ACCDB_COMMENT ALTER TABLE acc ADD COLUMN src_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE acc ADD COLUMN src_domain VARCHAR(128) NOT NULL DEFAULT ''; ALTER TABLE acc ADD COLUMN dst_ouser VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE acc ADD COLUMN dst_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE acc ADD COLUMN dst_domain VARCHAR(128) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN src_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN src_domain VARCHAR(128) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN dst_ouser VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN dst_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN dst_domain VARCHAR(128) NOT NULL DEFAULT ''; #!endif ####### Defined Values ######### # *** Value defines - IDs used later in config #!ifdef WITH_MYSQL # - database URL - used to connect to database server by modules such # as: auth_db, acc, usrloc, a.s.o. #!define DBURL "mysql://kamailio:kamailiorw@localhost/kamailio" #!endif #!ifdef WITH_MULTIDOMAIN # - the value for 'use_domain' parameters #!define MULTIDOMAIN 1 #!else #!define MULTIDOMAIN 0 #!endif # - flags # FLT_ - per transaction (message) flags # FLB_ - per branch flags #!define FLT_ACC 1 #!define FLT_ACCMISSED 2 #!define FLT_ACCFAILED 3 #!define FLT_NATS 5 #!define FLB_NATB 6 #!define FLB_NATSIPPING 7 ####### Global Parameters ######### #!ifdef WITH_DEBUG debug=4 log_stderror=yes #!else debug=2 log_stderror=no #!endif memdbg=5 memlog=5 log_facility=LOG_LOCAL0 fork=yes children=4 /* uncomment the next line to disable TCP (default on) */ #disable_tcp=yes /* uncomment the next line to disable the auto discovery of local aliases based on reverse DNS on IPs (default on) */ #auto_aliases=no /* add local domain aliases */ #alias="sip.mydomain.com" /* uncomment and configure the following line if you want Kamailio to bind on a specific interface/port/proto (default bind on all available) */ #listen=udp:10.0.0.10:5060 /* port to listen to * - can be specified more than once if needed to listen on many ports */ port=5060 #!ifdef WITH_TLS enable_tls=yes #!endif tcp_connection_lifetime=3605 ####### Custom Parameters ######### # These parameters can be modified runtime via RPC interface # - see the documentation of 'cfg_rpc' module. # # Format: group.id = value 'desc' description # Access: $sel(cfg_get.group.id) or @cfg_get.group.id # #!ifdef WITH_PSTN # PSTN GW Routing # # - pstn.gw_ip: valid IP or hostname as string value, example: # pstn.gw_ip = "10.0.0.101" desc "My PSTN GW Address" # # - by default is empty to avoid misrouting pstn.gw_ip = "trunk.testconnect.dk" desc "PSTN GW Address" #!endif ####### Modules Section ######## # set paths to location of modules #!ifdef LOCAL_TEST_RUN mpath="modules" #!else mpath="/usr/lib/x86_64-linux-gnu/kamailio/modules/" #!endif #!ifdef WITH_MYSQL loadmodule "db_mysql.so" #!endif loadmodule "mi_fifo.so" loadmodule "kex.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "mi_rpc.so" loadmodule "acc.so" # loadmodule "rtpengine.so" #!ifdef WITH_AUTH loadmodule "auth.so" loadmodule "auth_db.so" #!ifdef WITH_IPAUTH loadmodule "permissions.so" #!endif #!endif #!ifdef WITH_ALIASDB loadmodule "alias_db.so" #!endif #!ifdef WITH_MULTIDOMAIN loadmodule "domain.so" #!endif #!ifdef WITH_PRESENCE loadmodule "presence.so" loadmodule "presence_xml.so" #!endif #!ifdef WITH_NAT loadmodule "nathelper.so" # loadmodule "rtpproxy.so" loadmodule "rtpengine.so" loadmodule "path.so" #!endif #!ifdef WITH_TLS loadmodule "tls.so" #!endif #!ifdef WITH_ANTIFLOOD loadmodule "htable.so" loadmodule "pike.so" #!endif #!ifdef WITH_XMLRPC loadmodule "xmlrpc.so" #!endif # ----------------- setting module-specific parameters --------------- # ----- mi_fifo params ----- modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo") # ----- tm params ----- # auto-discard branches from previous serial forking leg modparam("tm", "failure_reply_mode", 3) # default retransmission timeout: 30sec modparam("tm", "fr_timer", 30000) # default invite retransmission timeout after 1xx: 120sec modparam("tm", "fr_inv_timer", 120000) # ----- rr params ----- # add value to ;lr param to cope with most of the UAs modparam("rr", "enable_full_lr", 1) # do not append from tag to the RR (no need for this script) modparam("rr", "append_fromtag", 0) # ----- registrar params ----- modparam("registrar", "method_filtering", 1) /* uncomment the next line to disable parallel forking via location */ # modparam("registrar", "append_branches", 0) /* uncomment the next line not to allow more than 10 contacts per AOR */ #modparam("registrar", "max_contacts", 10) # ----- acc params ----- /* what special events should be accounted ? */ modparam("acc", "early_media", 0) modparam("acc", "report_ack", 0) modparam("acc", "report_cancels", 0) /* by default ww do not adjust the direct of the sequential requests. if you enable this parameter, be sure the enable "append_fromtag" in "rr" module */ modparam("acc", "detect_direction", 0) /* account triggers (flags) */ modparam("acc", "log_flag", FLT_ACC) modparam("acc", "log_missed_flag", FLT_ACCMISSED) modparam("acc", "log_extra", "src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd") modparam("acc", "failed_transaction_flag", FLT_ACCFAILED) /* enhanced DB accounting */ #!ifdef WITH_ACCDB modparam("acc", "db_flag", FLT_ACC) modparam("acc", "db_missed_flag", FLT_ACCMISSED) modparam("acc", "db_url", DBURL) modparam("acc", "db_extra", "src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd") #!endif # ----- usrloc params ----- /* enable DB persistency for location entries */ #!ifdef WITH_USRLOCDB modparam("usrloc", "db_url", DBURL) modparam("usrloc", "db_mode", 2) modparam("usrloc", "use_domain", MULTIDOMAIN) #!endif # ----- auth_db params ----- #!ifdef WITH_AUTH modparam("auth_db", "db_url", DBURL) modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") modparam("auth_db", "load_credentials", "") modparam("auth_db", "use_domain", MULTIDOMAIN) # ----- permissions params ----- #!ifdef WITH_IPAUTH modparam("permissions", "db_url", DBURL) modparam("permissions", "db_mode", 1) #!endif #!endif # ----- alias_db params ----- #!ifdef WITH_ALIASDB modparam("alias_db", "db_url", DBURL) modparam("alias_db", "use_domain", MULTIDOMAIN) #!endif # ----- domain params ----- #!ifdef WITH_MULTIDOMAIN modparam("domain", "db_url", DBURL) # use caching modparam("domain", "db_mode", 1) # register callback to match myself condition with domains list modparam("domain", "register_myself", 1) #!endif #!ifdef WITH_PRESENCE # ----- presence params ----- modparam("presence", "db_url", DBURL) # ----- presence_xml params ----- modparam("presence_xml", "db_url", DBURL) modparam("presence_xml", "force_active", 1) #!endif #!ifdef WITH_NAT # ----- rtpproxy params ----- # modparam("rtpproxy", "rtpproxy_sock", "udp:127.0.0.1:7722") # modparam("rtpproxy", "rtpproxy_sock", "unix:/var/run/rtpproxy/rtpproxy.sock") # single rtproxy #modparam("rtpengine", "rtpengine_disable_tout", -1) #modparam("rtpengine", "rtpengine_sock", "udp:localhost:12222") modparam("rtpengine", "rtpengine_sock", "udp:localhost:22222") modparam("path", "use_received", 1); # ----- nathelper params ----- modparam("nathelper", "natping_interval", 30) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "sipping_bflag", FLB_NATSIPPING) modparam("nathelper", "sipping_from", "sip:pinger@kamailio.org") # params needed for NAT traversal in other modules modparam("nathelper|registrar", "received_avp", "$avp(RECEIVED)") modparam("usrloc", "nat_bflag", FLB_NATB) #!endif #!ifdef WITH_TLS # ----- tls params ----- modparam("tls", "config", "/etc/kamailio/tls.cfg") #!endif #!ifdef WITH_ANTIFLOOD # ----- pike params ----- modparam("pike", "sampling_time_unit", 2) modparam("pike", "reqs_density_per_unit", 16) modparam("pike", "remove_latency", 4) # ----- htable params ----- # ip ban htable with autoexpire after 5 minutes modparam("htable", "htable", "ipban=>size=8;autoexpire=300;") #!endif #!ifdef WITH_XMLRPC # ----- xmlrpc params ----- modparam("xmlrpc", "route", "XMLRPC"); modparam("xmlrpc", "url_match", "^/RPC") #!endif ####### Routing Logic ######## # Main SIP request routing logic # - processing of any incoming SIP request starts with this route route { if($rU=~"^\+[1-9][0-9]{3,20}$") { xlog("L_INFO", "MS: BEFORE STRIP $rm from $fu:$sp) to $ru\n"); strip(3); xlog("L_INFO", "MS: AFTER STRIP $rm from $fu:$sp) to $ru\n"); } else if($rU=~"^00[1-9][0-9]{3,20}$") { xlog("L_INFO", "MS: BEFORE STRIP $rm from $fu:$sp) to $ru\n"); strip(4); xlog("L_INFO", "MS: AFTER STRIP $rm from $fu:$sp) to $ru\n"); } xlog("L_INFO", "MS: BEFORE REQINIT $rm from $fu:$sp) to $ru\n"); # per request initial checks route(REQINIT); xlog("L_INFO", "MS: AFTER REQINIT $rm from $fu:$sp) to $ru\n"); # NAT detection route(NAT); xlog("L_INFO", "MS: AFTER NAT $rm from $fu:$sp) to $ru\n"); # handle requests within SIP dialogs route(WITHINDLG); xlog("L_INFO", "MS: AFTER WITHINDLG $rm from $fu:$sp) to $ru\n"); ### only initial requests (no To tag) # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) t_relay(); exit; } t_check_trans(); # authentication route(AUTH); # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) record_route(); # account only INVITEs if (is_method("INVITE")) { setflag(FLT_ACC); # do accounting } # dispatch requests to foreign domains route(SIPOUT); ### requests for my local domains # handle presence related requests route(PRESENCE); xlog("L_INFO", "MS: AFTER PRESENCE $rm from $fu:$sp) to $ru\n"); # handle registrations route(REGISTRAR); xlog("L_INFO", "MS: AFTER REGISTRAR $rm from $fu:$sp) to $ru\n"); if ($rU==$null) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; } xlog("L_INFO", "MS: BEFORE PSTN $rm from $fu:$sp) to $ru\n"); # dispatch destinations to PSTN route(PSTN); xlog("L_INFO", "MS: AFTER PSTN $rm from $fu:$sp) to $ru\n"); # user location service route(LOCATION); route(RELAY); } route[RELAY] { #!ifdef WITH_NAT if (check_route_param("nat=yes")) { setbflag(FLB_NATB); } if (isflagset(FLT_NATS) || isbflagset(FLB_NATB)) { xlog("L_INFO", "MS: RELAY NAT RTPPROXY $rm from $fu:$sp) to $ru\n"); route(RTPPROXY); } #!endif #if (!isflagset(FLT_NATS) && !isbflagset(FLB_NATB) && is_method("INVITE")) { # xlog("L_INFO", "MS: RELAY ALWAYS RTPPROXY $rm from $fu:$sp) to $ru\n"); # route(RTPPROXY); #} #rtpengine_manage(); /* example how to enable some additional event routes */ if (is_method("INVITE")) { #t_on_branch("BRANCH_ONE"); t_on_reply("REPLY_ONE"); t_on_failure("FAIL_ONE"); } if (!t_relay()) { sl_reply_error(); } exit; } # Per SIP request initial checks route[REQINIT] { #!ifdef WITH_ANTIFLOOD # flood dection from same IP and traffic ban for a while # be sure you exclude checking trusted peers, such as pstn gateways # - local host excluded (e.g., loop to self) if(src_ip!=myself) { if($sht(ipban=>$si)!=$null) { # ip is already blocked xdbg("request from blocked IP - $rm from $fu (IP:$si:$sp)\n"); exit; } if (!pike_check_req()) { xlog("L_ALERT","ALERT: pike blocking $rm from $fu (IP:$si:$sp)\n"); $sht(ipban=>$si) = 1; exit; } } #!endif if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if(!sanity_check("1511", "7")) { xlog("Malformed SIP message from $si:$sp\n"); exit; } } # Handle requests within SIP dialogs route[WITHINDLG] { if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { if (is_method("BYE")) { setflag(FLT_ACC); # do accounting ... setflag(FLT_ACCFAILED); # ... even if the transaction fails } route(RELAY); } else { if (is_method("SUBSCRIBE") && uri == myself) { # in-dialog subscribe requests route(PRESENCE); exit; } if ( is_method("ACK") ) { if ( t_check_trans() ) { # no loose-route, but stateful ACK; # must be an ACK after a 487 # or e.g. 404 from upstream server t_relay(); exit; } else { # ACK without matching transaction ... ignore and discard exit; } } xlog("L_INFO", "MS: route[WITHINDLG] 404 $rm from $fu:$sp) to $ru\n"); sl_send_reply("404","Not here"); } exit; } } # Handle SIP registrations route[REGISTRAR] { if (is_method("REGISTER")) { if(isflagset(FLT_NATS)) { setbflag(FLB_NATB); # uncomment next line to do SIP NAT pinging ## setbflag(FLB_NATSIPPING); } if (!save("location")) sl_reply_error(); exit; } } # USER location service route[LOCATION] { #!ifdef WITH_ALIASDB # search in DB-based aliases alias_db_lookup("dbaliases"); #!endif if (!lookup("location")) { switch ($rc) { case -1: case -3: t_newtran(); xlog("L_INFO", "MS: LOCATION 404 $rm from $fu:$sp) to $ru\n"); t_reply("404", "Not Found"); exit; case -2: sl_send_reply("405", "Method Not Allowed"); exit; } } # when routing via usrloc, log the missed calls also if (is_method("INVITE")) { setflag(FLT_ACCMISSED); } } # Presence server route route[PRESENCE] { if(!is_method("PUBLISH|SUBSCRIBE")) return; #!ifdef WITH_PRESENCE if (!t_newtran()) { sl_reply_error(); exit; }; if(is_method("PUBLISH")) { handle_publish(); t_release(); } else if( is_method("SUBSCRIBE")) { handle_subscribe(); t_release(); } exit; #!endif # if presence enabled, this part will not be executed if (is_method("PUBLISH") || $rU==$null) { sl_send_reply("404", "Not here"); exit; } return; } # Authentication route route[AUTH] { #!ifdef WITH_AUTH if (is_method("REGISTER")) { # authenticate the REGISTER requests (uncomment to enable auth) if (!www_authorize("$td", "subscriber")) { www_challenge("$td", "0"); exit; } if ($au!=$tU) { sl_send_reply("403","Forbidden auth ID"); exit; } } else { #!ifdef WITH_IPAUTH if(allow_source_address()) { # source IP allowed return; } #!endif # authenticate if from local subscriber if (from_uri==myself) { if (!proxy_authorize("$fd", "subscriber")) { proxy_challenge("$fd", "0"); exit; } if (is_method("PUBLISH")) { if ($au!=$tU) { sl_send_reply("403","Forbidden auth ID"); exit; } } else { if ($au!=$fU) { sl_send_reply("403","Forbidden auth ID"); exit; } } consume_credentials(); # caller authenticated } else { # caller is not local subscriber, then check if it calls # a local destination, otherwise deny, not an open relay here if (!uri==myself) { sl_send_reply("403","Not relaying"); exit; } } } #!endif return; } # Caller NAT detection route route[NAT] { #!ifdef WITH_NAT force_rport(); setflag(FLT_NATS); if (nat_uac_test("19")) { if (method=="REGISTER") { fix_nated_register(); } else { fix_nated_contact(); } if (method=="INVITE" && has_body("application/sdp")) { xlog("L_INFO", "MS: fix_nated_sdp $rm from $fu:$sp) to $ru\n"); #fix_nated_sdp("11"); #fix_nated_sdp("2"); #fix_nated_sdp("8"); } setflag(FLT_NATS); } #!endif return; } # RTPProxy control route[RTPPROXY] { #!ifdef WITH_NAT if (is_method("BYE")) { ## unforce_rtp_proxy(); rtpengine_delete(); } else if (is_method("INVITE")){ # force_rtp_proxy(); ## rtpproxy_offer(); #rtpengine_manage(); rtpengine_offer("asymmetric"); } if (!has_totag()) add_rr_param(";nat=yes"); #!endif return; } # Routing to foreign domains route[SIPOUT] { if (!uri==myself) { append_hf("P-hint: outbound\r\n"); route(RELAY); } } # PSTN GW routing route[PSTN] { #!ifdef WITH_PSTN # check if PSTN GW IP is defined if (strempty($sel(cfg_get.pstn.gw_ip))) { xlog("SCRIPT: PSTN rotuing enabled but pstn.gw_ip not defined\n"); return; } # route to PSTN dialed numbers starting with '+' or '00' # (international format) # - update the condition to match your dialing rules for PSTN routing #if(!($rU=~"^(\+|00)[1-9][0-9]{3,20}$")) { # xlog("L_INFO", "MS: PSTN not international $rm from $fu:$sp) to $ru\n"); # xlog("L_INFO", "MS: PSTN not international rU=$rU\n"); # return; #} xlog("L_INFO", "MS: PSTN check myself $rm from $fu:$sp) to $rU\n"); if($rU=~"^201111[0-9][0-9]$") { xlog("L_INFO", "MS: PSTN to myself $rm from $fu:$sp) to $ru\n"); return; } # only local users allowed to call if(from_uri!=myself) { xlog("L_INFO", "MS: PSTN 403 $rm from $fu:$sp) to $ru\n"); sl_send_reply("403", "Not Allowed"); exit; } #if (is_method("INVITE")) { # rtpproxy_offer(); #} xlog("L_INFO", "MS: PSTN before rewrite $rm from $fu:$sp) to $ru\n"); $ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip); xlog("L_INFO", "MS: PSTN before rewrite $rm from $fu:$sp) to $ru\n"); route(RELAY); exit; #!endif return; } # XMLRPC routing #!ifdef WITH_XMLRPC route[XMLRPC] { # allow XMLRPC from localhost if ((method=="POST" || method=="GET") && (src_ip==127.0.0.1)) { # close connection only for xmlrpclib user agents (there is a bug in # xmlrpclib: it waits for EOF before interpreting the response). if ($hdr(User-Agent) =~ "xmlrpclib") set_reply_close(); set_reply_no_connect(); dispatch_rpc(); exit; } send_reply("403", "Forbidden"); exit; } #!endif # Sample branch router branch_route[BRANCH_ONE] { xdbg("new branch at $ru\n"); } # Sample onreply route onreply_route[REPLY_ONE] { xdbg("incoming reply\n"); #!ifdef WITH_NAT if ((isflagset(FLT_NATS) || isbflagset(FLB_NATB)) && status=~"(183)|(2[0-9][0-9])") { # force_rtp_proxy(); ## rtpproxy_answer(); rtpengine_answer("asymmetric"); } if (isbflagset("6")) { fix_nated_contact(); } #!endif } # Sample failure route failure_route[FAIL_ONE] { #!ifdef WITH_NAT if (is_method("INVITE") && (isbflagset(FLB_NATB) || isflagset(FLT_NATS))) { #unforce_rtp_proxy(); rtpengine_delete(); } #!endif if (t_is_canceled()) { exit; } # uncomment the following lines if you want to block client # redirect based on 3xx replies. ##if (t_check_status("3[0-9][0-9]")) { ##t_reply("404","Not found"); ## exit; ##} # uncomment the following lines if you want to redirect the failed # calls to a different new destination ##if (t_check_status("486|408")) { ## sethostport("192.168.2.100:5060"); ## append_branch(); ## # do not set the missed call flag again ## t_relay(); ##} } --------------------------------------- rtpengine logs - rtpengine offer --------------------------------------- Apr 23 00:52:30 sipserver-01 rtpengine[27441]: [1040bcc4797199cf13f2820d7e0bea88@0:0:0:0:0:0:0:0] Received command 'offer' from 127.0.0.1:56696 Apr 23 00:52:30 sipserver-01 rtpengine[27441]: [1040bcc4797199cf13f2820d7e0bea88@0:0:0:0:0:0:0:0] Dump for 'offer' from 127.0.0.1:56696: { "sdp": "v=0#015#012o=20111101-jitsi.org 0 0 IN IP4 10.0.0.100#015#012s=-#015#012c=IN IP4 10.0.0.100#015#012t=0 0#015#012m=audio 5034 RTP/AVP 0 101#015#012a=rtpmap:0 PCMU/8000#015#012a=rtpmap:101 telephone-event/8000#015#012a=extmap:1 urn:ietf:params:rtp-hdrext:csrc-audio-level#015#012a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level#015#012a=rtcp-xr:voip-metrics#015#012", "flags": [ "asymmetric" ], "call-id": "1040bcc4797199cf13f2820d7e0bea88@0:0:0:0:0:0:0:0", "received-from": [ "IP4", "80.71.X.X" ], "from-tag" ... Apr 23 00:52:30 sipserver-01 rtpengine[27441]: [1040bcc4797199cf13f2820d7e0bea88@0:0:0:0:0:0:0:0] ... : "6bb9cb39", "command": "offer" } Apr 23 00:52:30 sipserver-01 rtpengine[27441]: [1040bcc4797199cf13f2820d7e0bea88@0:0:0:0:0:0:0:0] Creating new call Apr 23 00:52:30 sipserver-01 rtpengine[27441]: [1040bcc4797199cf13f2820d7e0bea88@0:0:0:0:0:0:0:0] Opened ports 10728..10729 for media relay Apr 23 00:52:30 sipserver-01 rtpengine[27441]: [1040bcc4797199cf13f2820d7e0bea88@0:0:0:0:0:0:0:0] Opened ports 10746..10747 for media relay Apr 23 00:52:30 sipserver-01 rtpengine[27441]: [1040bcc4797199cf13f2820d7e0bea88@0:0:0:0:0:0:0:0] Shutting down ICE agent (nothing to do) Apr 23 00:52:30 sipserver-01 rtpengine[27441]: [1040bcc4797199cf13f2820d7e0bea88@0:0:0:0:0:0:0:0] Replying to 'offer' from 127.0.0.1:56696 Apr 23 00:52:30 sipserver-01 rtpengine[27441]: [1040bcc4797199cf13f2820d7e0bea88@0:0:0:0:0:0:0:0] Response dump for 'offer' to 127.0.0.1:56696: { "sdp": "v=0#015#012o=20111101-jitsi.org 0 0 IN IP4 10.0.0.100#015#012s=-#015#012c=IN IP4 188.166.X.X#015#012t=0 0#015#012m=audio 10728 RTP/AVP 0 101#015#012a=rtpmap:0 PCMU/8000#015#012a=rtpmap:101 telephone-event/8000#015#012a=rtcp-xr:voip-metrics#015#012a=sendrecv#015#012a=rtcp:10729#015#012a=ice-ufrag:LA1hlEBj#015#012a=ice-pwd:S99AwTSnHtaGnaeCv0DL795QH7#015#012a=candidate:rPBAvp2vmOwOv6BS 1 UDP 2130706431 188.166.X.X 10728 typ host#015#012a=candidate:rPBAvp2vmOwOv6BS 2 UDP 2130706430 188.166.X.X 10729 typ host#015#012", "result": " ... Apr 23 00:52:30 sipserver-01 rtpengine[27441]: [1040bcc4797199cf13f2820d7e0bea88@0:0:0:0:0:0:0:0] ... ok" } rtpengine logs - rtpengine delete --------------------------------------- Apr 23 00:53:16 sipserver-01 rtpengine[27441]: [1040bcc4797199cf13f2820d7e0bea88@0:0:0:0:0:0:0:0] Call branch '6bb9cb39' deleted, no more branches remaining Apr 23 00:53:16 sipserver-01 rtpengine[27441]: [1040bcc4797199cf13f2820d7e0bea88@0:0:0:0:0:0:0:0] Final packet stats: Apr 23 00:53:16 sipserver-01 rtpengine[27441]: [1040bcc4797199cf13f2820d7e0bea88@0:0:0:0:0:0:0:0] --- Tag 'gK04ca43fa', created 0:46 ago, in dialogue with '6bb9cb39' Apr 23 00:53:16 sipserver-01 rtpengine[27441]: [1040bcc4797199cf13f2820d7e0bea88@0:0:0:0:0:0:0:0] ------ Media #1 (audio over RTP/AVP) using PCMU/8000 Apr 23 00:53:16 sipserver-01 rtpengine[27441]: [1040bcc4797199cf13f2820d7e0bea88@0:0:0:0:0:0:0:0] --------- Port 10728 <> 188.226.X.X:10146, 544 p, 93568 b, 0 e, 1429743164 last_packet Apr 23 00:53:16 sipserver-01 rtpengine[27441]: [1040bcc4797199cf13f2820d7e0bea88@0:0:0:0:0:0:0:0] --------- Port 10729 <> 188.226.X.X:10147 (RTCP), 0 p, 0 b, 0 e, 1429743150 last_packet Apr 23 00:53:16 sipserver-01 rtpengine[27441]: [1040bcc4797199cf13f2820d7e0bea88@0:0:0:0:0:0:0:0] --- Tag '6bb9cb39', created 0:46 ago, in dialogue with 'gK04ca43fa' Apr 23 00:53:16 sipserver-01 rtpengine[27441]: [1040bcc4797199cf13f2820d7e0bea88@0:0:0:0:0:0:0:0] ------ Media #1 (audio over RTP/AVP) using PCMU/8000 Apr 23 00:53:16 sipserver-01 rtpengine[27441]: [1040bcc4797199cf13f2820d7e0bea88@0:0:0:0:0:0:0:0] --------- Port 10746 <> 10.0.0.100:5034 , 595 p, 102340 b, 0 e, 1429743166 last_packet Apr 23 00:53:16 sipserver-01 rtpengine[27441]: [1040bcc4797199cf13f2820d7e0bea88@0:0:0:0:0:0:0:0] --------- Port 10747 <> 10.0.0.100:5035 (RTCP), 3 p, 228 b, 0 e, 1429743166 last_packet Apr 23 00:53:16 sipserver-01 rtpengine[27441]: ci=1040bcc4797199cf13f2820d7e0bea88@0:0:0:0:0:0:0:0, created_from= 127.0.0.1:56696, last_signal=1429743164, tos=0, ml0_start_time=1429743160.638873, ml0_end_time=1429743166.013947, ml0_duration=5.375074, ml0_termination=REGULAR, ml0_local_tag=gK04ca43fa, ml0_local_tag_type=FROM_TAG, ml0_remote_tag=6bb9cb39, ml0_midx1_rtp_endpoint_ip=188.226.X.X, ml0_midx1_rtp_endpoint_port=10146, ml0_midx1_rtp_local_relay_port=10728, ml0_midx1_rtp_relayed_packets=544, ml0_midx1_rtp_relayed_bytes=93568, ml0_midx1_rtp_relayed_errors=0, ml0_midx1_rtp_last_packet=1429743164, ml0_midx1_rtcp_endpoint_ip=188.226.X.X, ml0_midx1_rtcp_endpoint_port=10147, ml0_midx1_rtcp_local_relay_port=10729, ml0_midx1_rtcp_relayed_packets=0, ml0_midx1_rtcp_relayed_bytes=0, ml0_midx1_rtcp_relayed_errors=0, ml0_midx1_rtcp_last_packet=1429743150, ml1_start_time=1429743164.196879, ml1_end_time=1429743166.013948, ml1_duration=1.817069, ml1_termination=REGULAR, ml1_local_tag=6bb9cb39, ml1_local_tag_type=TO_TAG, ml1_remote_tag=gK04ca43fa, ml1_midx1_rtp_endpoint_ip=10.0.0.100, ml1_midx1_rtp_endpoint_port=5034, ml1_midx1_rtp_local_relay_port=10746, ml1_midx1_rtp_relayed_packets=595, ml1_midx1_rtp_relayed_bytes=102340, ml1_midx1_rtp_relayed_errors=0, ml1_midx1_rtp_last_packet=1429743166, ml1_midx1_rtcp_endpoint_ip=10.0.0.100, ml1_midx1_rtcp_endpoint_port=5035, ml1_midx1_rtcp_local_relay_port=10747, ml1_midx1_rtcp_relayed_packets=3, ml1_midx1_rtcp_relayed_bytes=228, ml1_midx1_rtcp_relayed_errors=0, ml1_midx1_rtcp_last_packet=1429743166, -------------------------------- ngrep - SDP send between kamailio and rtpengine: -------------------------------- U 127.0.0.1:56696 -> 127.0.0.1:22222 10856_6 d3:sdp303:v=0. o=20111101-jitsi.org 0 0 IN IP4 10.0.0.100. s=-. c=IN IP4 10.0.0.100. t=0 0. m=audio 5034 RTP/AVP 0 101. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=extmap:1 urn:ietf:params:rtp-hdrext:csrc-audio-level. a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level. a=rtcp-xr:voip-metrics. 5:flagsl10:asymmetrice7:call-id48:1040bcc4797199cf13f2820d7e0bea88@0 :0:0:0:0:0:0:013:received-froml3:IP413:80.71.X.Xe8:from-tag8:6bb9cb397:command5:offere # U 127.0.0.1:22222 -> 127.0.0.1:56696 10856_6 d3:sdp430:v=0. o=20111101-jitsi.org 0 0 IN IP4 10.0.0.100. s=-. c=IN IP4 188.166.X.X. t=0 0. m=audio 10728 RTP/AVP 0 101. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=rtcp-xr:voip-metrics. a=sendrecv. a=rtcp:10729. a=ice-ufrag:LA1hlEBj. a=ice-pwd:S99AwTSnHtaGnaeCv0DL795QH7. a=candidate:rPBAvp2vmOwOv6BS 1 UDP 2130706431 188.166.X.X 10728 typ host. a=candidate:rPBAvp2vmOwOv6BS 2 UDP 2130706430 188.166.X.X 10729 typ host. 6:result2:oke # --------------------------------

2 4

Measuring subscriber latency
by Jon Bonilla (Manwe) 29 Apr '15

29 Apr '15

Hi all I'm replacing an Asterisk based system with a kamailio based one. One of the features the legacy system has is showing the subscriber the latency obtained from the qualify option of sip.conf Now, I'd like to measure the latency but I'm not sure how to do it. AFAIK nathelper module sends the OPTIONS keepalive messages stateless mode and there's no information there. I was thinking on triggering a route send_options via the timer module, save the timestamp of the relay and the timestamp of the response in onreply_route but it doesn't look elegant. Creating my own daemon in an external server and reading the info from the location module seems to be another option. I guess I'm not the first one with this need so I wonder if there's an already existing solution or an elegant way of dealing with it. any ideas? thanks, Jon

4 3

LCR with gateway capabilities
by Grant Bagdasarian 29 Apr '15

29 Apr '15

Hello, >From what I understand about the LCR module is that the rules have to be prioritized by the admin, be it manually or automatically by an application. Let's say the LCR database has 10 gateways, each with their own rules etc. 4 of these gateways support caller id spoofing and the others don't. But the other 6 are cheaper and Kamailio has to route a call using a gateway which support caller id spoofing and is the cheapest of the 4. Would it be possible to tell the LCR module to select a gateway based on certain capabilities and is the cheapest of the ones which support a certain capability?

2 5

Running Kamailio with IMS
by Mihail Dakov 29 Apr '15

29 Apr '15

Hi all, I am trying to run Kamailio server with IMS modules for which I have gone through the following tutorials: http://nil.uniza.sk/ngnims/kamailio-ims/preparing-debian-operating-system-k… http://www.kamailio.org/wiki/tutorials/ims/installation-howto The problem I have is that using 'service kamailio start' I can only run one IMS component, say PCSCF. But I need to run all P/S/I-CSCFs. How do I proceed to get running P/S/I-CSCF on the same machine with kamailio? br, m.dakov

2 2

2 phones behind same NAT, Kamailio on Pub IP One Way Audio
by Todd R. 29 Apr '15

29 Apr '15

This is my first go round' with Kamailio but I have been messing with it off and on for a few weeks. Running latest version on latest CentOS 7.x. Kamailio installed on VM with public IP in one location, 2 SIP phones behind same NAT, both registered to Kamailio fine. I can call one phone to the other and it rings and I can answer it but get one way audio most of the time, sometimes no audio at all. I just did a standard install with MySQL and no other modules. What am I missing, do I need RTPPROXY? Will Kamailio allow extension to extension calls from/to phones behind NATS without any additional modules? I tried installing it with yum, it installed but it won't start. If I need it, I will remove the YUM version and install from source or GIT or some other method. I do NOT want any media passing through this server, that's one big reason I am learning something OTHER than Asterisk which I am very familiar with. I see all these RTP modules, music on hold etc but I specifically don't want to install anything that causes media to pass through the box. Finding the learning curve much steeper than Asterisk back in the day and a REALLY tough time find step by step examples to get started, especially on CentOS. I bought the draft of the book and it will be a great resource but at the moment, it's not helping me get started or get my first instance up and running. I need to add SIP trunks to originate and terminate calls but I can't even think about that since I can't even get audio on extension to extension calls yet. I also see that Kamailio fails to startup at boot because it can't connect to MySQL, when I restart Kamailio it starts fine. I think the issue is that Kamailio is trying to start before MySQL is up and running, I guess I can do a delayed start of Kamailio to fix that later. Any help would be appreciate by this NEWB. Thanks in advance for any assistance.

2 1

publish authentication problem
by Tomas Zanet 28 Apr '15

28 Apr '15

Hello everyone, I've been working on a project where I would like to implement RFC6035 https://tools.ietf.org/html/rfc6035 Basically, after the end of the call, our SIP UAC sends a SIP PUBLISH to Kamailio where there are some useful information about media quality (packet loss, mos, etc..) This information is stored by Kamailio with sql_query command... To achieve this, I implemented a custom route function inside Kamailio cfg file, which handles PUBLISH request, check vq-rtcpxr body and store that information into a database. Here is a snippet code: # AVPF report route route[AVPF] { if(!is_method("PUBLISH")) return; if (has_body("application/vq-rtcpxr")) { $var(x) = "INSERT INTO quality_reporting_raw(body) VALUES (\"" + $(rb{s.escape.common}) + "\");"; sql_query("cb", "$(var(x))"); ...... reply 200 ok and so on.... exit(0) } } Everything works fine (almost fine, because the report is stored twice...) if I do the route(AVPF) before authentication, like this... (main route): # handle AVPF reports route(AVPF); # authentication route(AUTH); Instead if I swap these two functions, doing the authentication before publish processing, I have some problems about publish authentication....not for the other requests (INVITE and REGISTER) As far as I know From, To and Request-URI must match the authentication user, in the PUBLISH REQUEST as described here http://kamailio.org/docs/modules/4.2.x/modules/auth_db.html#auth_db.f.auth_… I confirm that...I'm sending the SIP PUBLISH from user 101 to user 101, which is currently registered. My problem is that Kamailio is continuously answering with 407 to the SIP PUBLISH, even if the PUBLISH request has the right Proxy-Authorization header... Digging into the log file, I found this : Apr 24 14:30:58 bptrnddmzserver kamailio[30886]: DEBUG: auth_db [authorize.c:486]: auth_check(): realm [myhome2.xip.bpt.com] table [subscriber] flags [1] Apr 24 14:30:58 bptrnddmzserver kamailio[30886]: DEBUG: auth [api.c:86]: pre_auth(): auth:pre_auth: Credentials with realm 'myhome2.xip.bpt.com' not found Apr 24 14:30:58 bptrnddmzserver kamailio[30886]: DEBUG: auth_db [authorize.c:252]: digest_authenticate_hdr(): no credentials Just for your better understanding I'm doing authorization with db, using subscriber table where there are all the users with 'myhome2.xip.bpt.com' domain... In fact, all INVITEs and REGISTERs are correctly authenticated... Would you mind address me to find out the problem? Maybe, there's something wrong in my cfg file. Thanks in advance T, Tomas Zanet Software Design Department tzanet(a)came.com [cid:CAME.png]<http://www.came.com/> [cid:LogoExpo.png] [cid:FooterCAME.png] Il messaggio di posta elettronica contiene informazioni di carattere confidenziale specifiche per il destinatario. Nel caso non ne siate il destinatario, segnalatelo immediatamente al mittente ed eliminate dai vostri archivi quanto ricevuto (compresi i file allegati). L'uso, la diffusione, distribuzione o riproduzione del presente messaggio e dei suoi allegati da parte di ogni altra persona costituisce reato. Rif. Decreto legislativo 30 giugno 2003, n. 196 - Codice in materia di protezione dei dati personali. The email message contains confidential information specific to the recipient. If you are not the recipient, write it to the sender immediately and delete from your files as received (including file attachments). Use, dissemination, distribution or reproduction of this message and its attachments by any other person is a criminal offense. References Legislative Decree 30 June 2003, n. 196 - Code for the protection of personal data. Right to opposition: The person concerned who receives the message has the right at any time to oppose its processing for forwarding commercial messages, advertising material or direct sales proposals, by clicking on the e-mail address below (or by traditional postal services by writing to: Came S.p.A., Via Martiri della Libert? 15, 31030 Dosson di Casier (TV) - Italy, or by sending a fax to +39 0422 4941. Furthermore the person concerned may exercise all the rights of access to the personal data as provided by art. 7, Legislative Decree no. 196/2003, including the rights to amendment, updating and deletion, by sending an e-mail to privacy(a)came.com<mailto:privacy@came.com>.

2 5

instant message timeout detection
by Péter Barabás 28 Apr '15

28 Apr '15

Hi, i want to detect and do some custom handling on kamailio side when a suspended MESSAGE "transaction" has timed out (the t_continue has not been called after t_suspend). What is the simplest way to solve this? Péter B.

2 1

How to dump or log the value of $avp(ice_priority) with xlog
by Filip Malenka 28 Apr '15

28 Apr '15

Hi all, I am adding the modparam("rtpproxy", "ice_candidate_priority_avp", "$avp(ice_priority)") to my kamailio.cfg and I would like to know, what this "$avp(ice_priority)" returns, either 1, or 2 or anything else.. I tried with xlog xlog("The ICE priority is: $avp(ice_priority)"); and placed it right before the rtpproxy_manage() function call in my routing and did a grep on /var/log/syslog but I only get a "<null>" as returned value when attempting to make a call: Apr 25 17:47:03 localhost /usr/sbin/kamailio[19600]: ERROR: <script>: The ICE priority is: <null> I expected values 1 or 2 according to the rtpproxy module docu. http://kamailio.org/docs/modules/4.0.x/modules/rtpproxy.html#idp18746912 Thank you. Filip.

3 2

Expect the kamailio's sip account is unregistered state when the client app is shutdown
by xuefeng zhang 28 Apr '15

28 Apr '15

Hi Daniel, When the client's app is closed,the sip account may be registered state,because the expired time may have some rest time.I want to implement when the client's app is closed,the account also unregister. How can I implement this function?Would you give me some advices? Thanks! Xuefeng Zhang

6 17

subst_hf with capture groups
by Igor Potjevlesch 28 Apr '15

28 Apr '15

Hello, I can't figure out how to handle this case: subst_hf("P-Asserted-Identity", "/(.*\")0(.*)(.*\")/\133\2\3/", "a"); I'd like to substitute with \1 followed with 33 but it looks like the substitution tries to be done with \133. The capture group \133 doesn't exist. I tried with the following syntax: /${1}33 but ${1} is interpreted as a string. Someone can help me? Thank you. Regards, Igor.

2 3

Kamamilio with PjSIP on Asterisk
by Scott Pabin 28 Apr '15

28 Apr '15

Fellow Masters of the Universe, I'm familiar with using Kamailio to handle many tasks, such as SIP registration for Asterisk. However, that has all been using Asterisk's SIP protocol. I'm setting up a new project and I'd like to base it on PjSIP in Asterisk. What has been your experience and what specific tasks can I offload to Kamailio in this scenario? Are there any limitations with using PjSIP that were not an issue with SIP? What do I want it to do? For now, the typical, registrations and load balancing. Initially, two Kamailio sending traffic to two Asterisk, all sharing a common MySQL cluster. I also have a fair amount of traffic that may not require any Asterisk involvement, such as connecting calls from my carriers to my clients or client to client calls. Thanks for your thoughts guys.

1 0

add feature to dmq to allow for HA (heartbeat or pacemaker)
by Vik Killa 27 Apr '15

27 Apr '15

Hello, I was looking to implement HA with 2 Kamailio machines. I am aware of the dmq module and I thought that would be a great place to start. The problem I see is that dmq module does not have any "failure" callback mechanism. For instance, if KamA sends dmq ping to KamB, and KamB does not respond (perhaps because it's down), then nothing happens. I looked into using the dmq API and checked the dmq code to see how send_message() function works, and I dont see any indication that there is a failure callback. I would be a great improvement to add this sort of functionality to dmq and then other modules or code can be written to use the API to detect when another Kam box is up or down. This could lead to another module like dmq_ha (I'm open to writing this) Thanks, V

3 3

append_branch. How to disable original URI
by Yuriy Gorlichenko 27 Apr '15

27 Apr '15

Hello. I thry to integrate redis for location module and first at all that I do - dublicate location to redis. First At all I create analog of lookup procedure that use location but from redis. I take values from location and create branches by mannualy. All works good but branch route create dublicate of first branch. We talk about it already and I cnow that branch route creates first original Request and then create branches. So my question is how to disable creation of original URI? My cfg part of creation branches is: First of all I create massive of needed endpoints and then create branches as bellow. I create it with different сucles "while" because websockets not blocked when creates dublicate INVITE, but some UDP endpoints can not take call because answer to kamailio 482 reply and CANCELs call. It works fine when I logged on with wesocket device and UNP at one time. But when I logget with 2 UDP devices only this algorithm not worked. Thanks for help. $var(k)=0; xlog("L_INFO", "request URI is $ru"); while ($var(k)<= $var(j)){ if ($(avp(device_contact)[$var(k)])=~"device"){ xlog("L_INFO", "This is a classic UDP call to endpoint"); if ($(avp(device_received)[$var(k)])==""){ xlog("L_INFO", "Received string is EMPTY"); $du="sip:"+$(avp(device_contact[$var(k)]){s.select,1,@}); } else { xlog("L_INFO", "Received string is {$avp(device_received)[$var(k)]}"); $du=$(avp(device_received)[$var(k)]); } $var(UDP_contact)="sip:"+$(avp(device_contact[$var(k)]){s.select,1,@}); append_branch("sip:$tU@$(du{s.select,1,:})","0.3"); xlog("L_INFO","Classic Destination URI is {$(avp(device_contact[$var(k)]){s.select,1,@})} for {$tU}}. Destination is {$du}\n"); } $var(k) = $var(k) + 1; } $var(k)=0; xlog("L_INFO", "request URI is $ru"); while ($var(k)<=$var(j)){ if ($(avp(device_contact)[$var(k)])=~"transport=ws"){ xlog("L_INFO", "This is a classic UDP call to endpoint"); xlog("L_INFO", "Received string is {$avp(device_received)[$var(k)]}"); $du=$(avp(device_received)[$var(k)]); append_branch("sip:$tU@$(du{s.select,1,:})","0.7"); xlog("L_INFO","Classic Destination URI is {$(avp(device_contact[$var(k)]){s.select,1,@})} for {$tU}}. Destination is {$du}\n"); } $var(k) = $var(k) + 1;

2 1

ims_qos routing
by Federico Cabiddu 26 Apr '15

26 Apr '15

Hi, I've been recently playing, with success, with kamailio IMS modules and the examples *cscsf configuration files. Now I'm trying to implement qos but I am stuck with diameter routing. Basically I can route Rx requests only if I use "rx_forced_peer". In the other cases (Realm routing or default routing if I have no realm-specific configuration) cdp module seems not to be able to find a route. What I have in the logs is "Checking if peer XXX handles application 16777236 for vendord 0" (realm routing) or "get_routing_peer(): No connected DefaultRoute peer found for app_id 16777236 and vendor id 0." (for the default route). Looking at get_routing_peer function (cdp module) it seems that the function extracts the vendor_id either from grouped Vendor-Specific-Application-Id AVP or from Vendor-Id AVP if in the request the Auth-Application-Id AVP is present. In this case, even if Vendor-Specif-Application-Id is present, it's not taken in count by the routing logic. In the AAR generated by ims_qos there is the Auth-Application-Id AVP but not the Vendor-Id, so the vendor_id for which cdp module looks for is "0" which is not found in any of the connected peer. Am I missing something (probably)? Thank you and have a nice weekend. Federico

1 0

siptrace for keep-alive OPTIONS
by Koray Vatansever 24 Apr '15

24 Apr '15

Hi, It seems that siptrace module doesn't trace requests which are sent out by dialog module (i.e. keep-alive OPTIONS and dialog timeout BYE). Is there any easy way to do that? any suggestion?

2 1

Re: [SR-Users] Multi party body with content type as application/resource-lists+xml couldnt able to decode
by Daniel-Constantin Mierla 24 Apr '15

24 Apr '15

Hello, you have to say what you tried and what was the failure to be able to help. Pasting the INVITE will be useful as well. Cheers, Daniel On 24/04/15 08:25, Surendra Pullaiah wrote: > > HI Daniel, > > > > Can you please share , why kamailio couldn’t able to > extract the body, when INVITE comes with multi party body (sdp + > resource-lists). Is there any other way to extract the same. > > > > Please share your views… > > Regards > > Surendra > > > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com

1 0

Re: [SR-Users] drouting
by Keith 24 Apr '15

24 Apr '15

Hi, I am using drouting but having issues when trying to route numbers in E164 in the prefix. Any ideas how to allow for a + in the prefix field in the DB? Thanks Keith

2 1

About IMS_Chargin and CDP_AVP improvement
by Yasin CANER 24 Apr '15

24 Apr '15

1 0

Multi party body with content type as application/resource-lists+xml couldnt able to decode
by Surendra Pullaiah 24 Apr '15

24 Apr '15

HI Daniel, Can you please share , why kamailio couldn't able to extract the body, when INVITE comes with multi party body (sdp + resource-lists). Is there any other way to extract the same. Please share your views. Regards Surendra

1 0

Header Concatenation - is this a Bad Idea?
by Nathan Angelacos 23 Apr '15

23 Apr '15

Some udp INVITEs hit our network very close to the 1500 byte limit, and we add 2 Record-Routes before we pass the INVITE to the end user. The packet gets truncated in the SDP; "usually" it still works. In our use case, I can't use gzip or TCP. We are already using textops to convert to short-form headers where possible; we're also stripping unnecessary headers. So the next thing is to use RFC 3261 7.3 and 25.1 to concatenate the multiple Record-Routes into one longer line (same for Via, Contact, etc.): Record-Route: <sip:111.111.111.111;lr=on> Record-Route: <sip:99.99.99.99;lr=on> Record-Route: <sip:88.88.88.88:5060;lr> Record-Route: <sip:77.77.77.77;lr> becomes: Record-Route: <sip:111.111.111.111;lr=on>, <sip:99.99.99.99;lr=on>, <sip:88.88.88.88:5060;lr> <sip:77.77.77.77;lr> That saves about 30 bytes - one can save more if putting all the values on 1 line without the cr\lf between. Doesn't look like there's any kamailio function in textops/x that makes this kind of thing easy; so before I start hacking away at the code... Our downstream uses freeswitch, and is willing to verify it works for him - but from a larger interop view, is this a Bad Idea(tm)? Anyone have any experience with brand-name carrier SBC/Proxies that would choke on a header like that? Thanks!

3 3

topoh ACK Call-ID mismatch
by Daniel Tryba 23 Apr '15

23 Apr '15

Trying to call a T.38 enabled endpoint B from an endpoint A that doesn't. This results in a "488 Not Acceptable" from A. The kamailio (4.0.3) in between with topoh enabled (with mask_callid set to 1. Kamailio ACKs the 488 to A, but the ACK has the wrong (masked) Call-ID, resulting in the ACK to A being ignored, A keeps sending 488 at intervals before just dropping the call. My understanding is the Call-ID in the ACK has to be the same as the Call-ID from the 488. But instead of sending the unmasked Call-ID used in all other messages between A and Kamailio, the ACK contains the masked Call-ID used in all messagea between A and Kamailio. I can't find a bug report relating to this. Is this a known feature or maybe fixed in newer versions? A->Kamailio SIP/2.0 488 Not acceptable here. Via: SIP/2.0/UDP 109.235.32.40;branch=z9hG4bKf91a.c6c88747.0;received=109.235.32.40. Via: SIP/2.0/UDP 172.19.162.1;branch=pocos- rS4MusXox1l5QHyNxRy6uAXsEOdsxidSEAktxGZKWgeKCgeS- RrKEAy057Nl9DEpWpefZD6AhGtwWDJjEqeuEAZgZs5iZA7*. From: <sip:+31880100799@sip.pocos.nl:5060>;tag=as3869fe2a. To: "+31880100705" <sip:+31880100705@sip.pocos.nl>;tag=as1b0b8097. Call-ID: 0b5946b977210450571f767a19cd6fa0(a)99sip.pocos.nl. CSeq: 102 INVITE. Kamailio<-A ACK sip:+31880100705@109.235.32.48 SIP/2.0. Via: SIP/2.0/UDP 109.235.32.40;branch=z9hG4bKf91a.c6c88747.0. Max-Forwards: 16. From: <sip:+31880100799@sip.pocos.nl:5060>;tag=as3869fe2a. To: "+31880100705" <sip:+31880100705@sip.pocos.nl>;tag=as1b0b8097. Call-ID: !!:xqXtWRMpZAngEsX3xGMtxGrgxDZgEA9JxR4AzGz8ZRIyWR4sh.yomqlACgxoC8K*. CSeq: 102 ACK. -- Telefoon: 088 0100 700 Sales: sales(a)pocos.nl | Service: servicedesk(a)pocos.nl http://www.pocos.nl/ | Croy 9c, 5653 LC Eindhoven | Kamer van Koophandel 17097024

3 11

Kamailio World for students
by Daniel-Constantin Mierla 23 Apr '15

23 Apr '15

Hello, given the roots and the tight relation of Kamailio project with the academic environment, we are offering three seats at Kamailio World Conference, May 27029, 2015, in Berlin, to students enrolled in universities or research institutes (both bachelor and PhD programs qualify). Last year we tried it locally with the universities in Berlin and this year we want to extend it, as there might be young people interested to travel a bit and attend the event. If you are a student and want to participate, email me directly (miconda(a)gmail.com) or to registration(a)kamailio.org . Participation to all the content of the event (workshops, conference and social event) is free, but you will have to take care of expenses for traveling and accommodation. Write a short description about your interest in real time communications and what is the university or the research institute you are affiliate to. Also, if you are not a student, but you are in touch with some or have access to students forums/mailing lists, it will be very appreciated if you forward these details. More information about Kamailio World is available on the web site: - http://www.kamailioworld.com Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com

1 0

Re: [SR-Users] SIP messages over UDP with sizes over MTU
by Yufei Tao 23 Apr '15

23 Apr '15

Hi Sharath Thanks for the tip! In fact just last night I've found what got things stuck was nothing to do with Kamailio - it was one of our own little module (plugged into Kamailio) that's got locked up. The first thing I suspected was like what you mentioned that Kamailio got stuck due to fragmentation. I wonder if you've seen this happening with Kamailio? At least in this problem of ours it wasn't Kamailio. Thank you and Daniel for the help on this! Yufei On 22 April 2015 at 22:19, Sharath Kumar <Sharath.Kumar(a)mezocliq.com> wrote: > It is definitely possible due to fragmentation the sip receiver was > stuck in some weird state. If I were you I would do TCP for SIP. It is also > recommended in 3261 to use TCP when sip is that big. > ------------------------------ > *From:* sr-users <sr-users-bounces(a)lists.sip-router.org> on behalf of > Yufei Tao <yufei.tao(a)gmail.com> > *Sent:* Friday, April 3, 2015 7:04 AM > *To:* sr-users(a)lists.sip-router.org > > *Subject:* Re: [SR-Users] SIP messages over UDP with sizes over MTU > > Hi Daniel > > We don't have pike module enabled. > > When the problem occurred on an VIP, we observed these: > * Kamailio stopped responding to any messages that were sent to the VIP, > not just OPTIONS > * The OPTIONS messages are not big. But the other SIP messages, e.g. some > of the INVITE/OK that came from some SBCs can be big > * netstat showed the Recv-Q on that VIP had a lot of bytes accumulated, > while Kamailio was not seeing/reading them > * Kamailio responded fine on its real IP, when I sent OPTIONS pings to it > using sipsak > * After restarting Kamailio it started working. But after 1 week or so > the same problem happened again > > Since this only happened after running for 1 week or so, we didn't have > any traces to show what exactly happened at the particular time when it > happened. It is possible some SIP messages may have come in fragmented and > some are just too big, depending on the route they came from etc. So I was > wonder if it was possible that the UDP receive buffer was filled somehow > with messed-up messages. Is there anyway to check this? Any suggestions > where I should start looking please? Or is it generally a bad idea to use > UDP when there are messages that may be too big, either fragmented or not? > > Since the it is running in the production environment, I'd like to get > some confidence that a Kamailio upgrade will fix the problem first before I > change anything there. > > Cheers, > Yufei > > > > Date: Wed, 01 Apr 2015 16:27:44 +0200 > From: Daniel-Constantin Mierla <miconda(a)gmail.com> > To: "Kamailio (SER) - Users Mailing List" > <sr-users(a)lists.sip-router.org > > > Subject: Re: [SR-Users] SIP messages over UDP with sizes over MTU > Message-ID: <551C0060.3010002(a)gmail.com> > Content-Type: text/plain; charset="windows-1252" > > Hello, > > first, not related to the topic you reported, I would recommend at least > upgrading to latest 4.0.x, there were many fixes from v4.0.0 and there > are no changes to be done to config or database -- simply deploy latest > 4.0.x and restart. > > Back to this topic. Is all the other traffic handled apart of big OPTIONS? > > Do you have pike module enabled? If yes, can you double check and be > sure that the SBC is not blacklisted (traffic from it should not be > handled via pike_check_req()). > > Cheers, > Daniel > > On 01/04/15 15:42, Yufei Tao wrote: > > Hi > > > > We've got Kamailio (v4.0.0) connected to some SBC, which sends SIP > > traffic and periodic OPTIONS pings to Kamailio's VIP. Kamailio > > responds to the OPTIONS pings with OK, i.e. in the main route block: > > if (is_method("OPTIONS")) > > { > > sl_send_reply("200","OK"); > > exit; > > } > > > > All works fine for a week or so, then Kamailio stopped responding to > > the OPTIONS pings on the VIP it listens to. But it still respond to > > OPTIONS pings that are sent to its real IP. The real IP is not used > > for receiving/sending any traffic while only the VIP is. So it seems > > that Kamailio is still working, but maybe having problems with the > > receiving buffer for the VIP? > > > > We do see that some SIP messages sent to Kamailio's VIP are too big > > (sometimes over 1500 bytes). My question is, in this case, what would > > be expected to happen? Is it possible somehow the receiving buffer for > > the VIP got messed up by the big UDP messages? Any one seen similar > > problems? What is the suggested solution? > > > > We're considering moving to TCP. But since this is production > > environment, I want to get some confidence that the problem we saw was > > likely to have been caused by the UDP message being too large. > > > > Cheers, > > Yufei >

1 0

Kamailio v4.3 - development frozen
by Daniel-Constantin Mierla 23 Apr '15

23 Apr '15

Hello, development (master) branch of Kamailio enters now in pre-release phase for version 4.3.0. Therefore, no new feature should be pushed to master until we create a dedicated branch for 4.3 (expected to be in about 4 weeks or so). If in doubt to push or not a commit to master, push it first on a personal branch (or attach to an email) and discuss it on sr-dev. The new modules can be a bit more dynamic if there is need to get them to the right shape (e.g., like decision to rename functions, parameters or adjust database structure). We hope to get many people involved in testing, to rich a stable state before releasing 4.3.0. If you want to get involved and need assistance, don't hesitate to write to mailing lists. Help with updating the wiki page for migration from 4.2 to 4.3 as well as what is new in 4.3 is very appreciated. I will post updates about the very soon. Many thanks to everyone involved in development of 4.3 and the early testers that played with master branch so far. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com

1 0

Unauthorized register with persistence PostgreSQL
by Gabrielle Eymard 23 Apr '15

23 Apr '15

Hello everyone, I’m currently running Kamailio 4.2.4 with PostrgreSQL 9.3 database, each one on CentOS 6.6 I have installed and configured Kamailio with PostgreSQL without any problem. But now, I don’t want my phones register be recorded on Kamailio (on cache) but immediately on the external database. For that, I follow your advices and configure the kamailio.cfg this way : I added these lines : #!ifdef WITH_PGSQL #!define DBURL "postgres://user:passwd@database.domain:5432/kamailio" #!endif … #!ifdef WITH_PGSQL loadmodule "db_postgres.so" #!endif … And I have all these modules laoded : loadmodule "mi_fifo.so" loadmodule "kex.so" loadmodule "corex.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "outbound.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "cfg_rpc.so" loadmodule "mi_rpc.so" loadmodule "acc.so" loadmodule "stun.so" I also set 3 to the usrloc param so my registration are directly on my database : # ----- usrloc params ----- /* enable DB persistency for location entries */ #!ifdef WITH_USRLOCDB modparam("usrloc", "db_url", DBURL) modparam("usrloc", "db_mode", 3) modparam("usrloc", "use_domain", MULTIDOMAIN) #!endif Then, when I restart my Kamailio server, I saw on my postgres database that the connection with this user and passwd is ok but my sip phones didn’t registered. Thanks to Wireshark, I saw that the first REGISTER is send by my sip-phone to Kamailio. The first UNAUTHORIZED response came, as expected, with the WWW-Authenticate information. My phone sent a new REGISTER with the good realm and nonce-value (so I can see with wireshark) but Kamailio still refuse it by another UNAUTHORIZED message (same as the first one). Can you please explain to me where am I wrong ? If it helps, this is what I got on the kamailio logs : Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[20466]: NOTICE: <core> [main.c:739]: handle_sigs(): Thank you for flying kamailio!!! Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[20475]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[20474]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[20473]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[20472]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[20471]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[20470]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[20469]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[20468]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[20467]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 21 14:27:39 fiducial-vm-centos66-sipr1 kamailio: INFO: <core> [tcp_main.c:4746]: init_tcp(): using epoll_lt as the io watch method (auto detected) Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[22331]: INFO: usrloc [hslot.c:53]: ul_init_locks(): locks array size 1024 Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[22331]: INFO: auth [auth_mod.c:350]: mod_init(): auth: qop set, but nonce-count (nc_enabled) support disabled Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[22331]: INFO: <core> [udp_server.c:175]: probe_max_receive_buffer(): SO_RCVBUF is initially 124928 Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[22331]: INFO: <core> [udp_server.c:225]: probe_max_receive_buffer(): SO_RCVBUF is finally 249856 Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[22339]: INFO: ctl [io_listener.c:225]: io_listen_loop(): io_listen_loop: using epoll_lt io watch method (config) Hope someone could help me, Thank you in advance anyway Gab

2 3

Kamailio: MI Command: 'trusted_dump' and 'trusted_reload'
by José Luis Millán 22 Apr '15

22 Apr '15

Hi, I'm using 'allow_trusted()' from Permissions module without a problem in a Kamailio 4.0 routing logic. It does just work, but the MI command 'trusted_dump' tells me that the module is not in use: ''' server:/home/jmillan# kamctl fifo trusted_dump 500 Trusted-module not in use ''' Doing a 'trusted_reload' does neither make any query to database to retrieve the data. Other MI commands of same module do work correctly. ie: 'address_reload' or 'address_dump' Note: I have tested in a Kamailio 1.5 and the result is the same. Regards. -- José Luis Millán

4 3

rtpengine and security
by GG GG 22 Apr '15

22 Apr '15

By port closed, I mean that ports are normally closed, but when rtpengine send the first rtp packets to the client, it opens a pinhole in the firewall, and the matching incoming packets from the client will make the connection established,related in iptables. I think symmetric nat permits that. But now I'm thinking that it's impossible for rtpengine to know the client's destination port at the learning phase if the client's rtp packets can't reach rtpengine. Rtpengine can learn the IP Address from kamailio through the --sip-source CLI switch, but can't guess the port, right ? So, playing with established,related is not possible. > If the attacker is fast enough, yes. You can disable learning of > endpoint addresses using the asynchronous flag, but obviously this will > break NAT'd media. You can also use the strict-source flag to make > rtpengine drop packets received from a mismatched source address. So if I don't use strict-source flag, an attacker could merge any garbage of data in an existing RTP stream ? Thanks.

3 2

Roadmap for next major release v4.3.0
by Daniel-Constantin Mierla 22 Apr '15

22 Apr '15

Hello, it is time to nail down the roadmap to the next major release. We discussed during the last IRC devel meeting, proposing to get it out by beginning of June. Given we need to have at least one month of testing, I propose the next milestones: - freezing the development: Wednesday, April 22, 2015 - if testing goes smooth, then branching 4.3 after about one month: During the week starting May 18 - test more in beta phase, prepare packaging, etc. and release after 2-3 weeks: One of the days between June 4 and 11 Other suggestions or adjustments are welcome! Send them to mailing list to discuss further. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com

1 3

Possible bug in TM module
by Mickael Marrache 22 Apr '15

22 Apr '15

Hi, I just got the following issue when stopping kamailio. kamailio[7279]: NOTICE: <core> [main.c:682]: handle_sigs(): Thank you for flying kamailio!!! kamailio[7279]: ERROR: ctl [ctl.c:369]: mod_destroy(): ERROR: ctl: could not delete unix socket /tmp/kamailio_ctl: Operation not permitted (1) kamailio[7279]: : <core> [mem/f_malloc.c:586]: fm_free(): BUG: fm_free: bad pointer 0x4f2dec6200000000 (out of memory block!), called from tm: h_table.c: free_cell(138) - aborting I always get the first ERROR when I stop kamailio, I need to look at the permissions. However, the next one is a bug. Thanks, Mickael

2 2

Iterative DNS resolution by enum module ?
by jyaim 22 Apr '15

22 Apr '15

Hello everyone, Do you know if the kamailio enum module is able to process 'recursives' dns requests in case of CNAME or NS response, until a NAPTR answer is returned ? Thanks in advance! Jy

2 1

Problems with git.kamailio.org server?
by kai.ohnacker＠cbc.de 22 Apr '15

22 Apr '15

Hello, is there actually a problem with the git.kamailio.org server? If I try the command git clone --depth 1 git://git.kamailio.org/kamailio kamailio or git clone --depth 1 git://git.sip-router.org/kamailio kamailio I got the message "fatal: read error: connection reset by peer". Perhaps it is a problem of my setup? Best regards, Kai Ohnacker

2 3

siptrace for keep alive OPTIONS
by Koray Vatansever 22 Apr '15

22 Apr '15

Hi, It seems that siptrace module doesn't trace requests which are sent out by dialog module (i.e. keep-alive OPTIONS and dialog timeout BYE). Is there any easy way to do that? any suggestion?

1 0

rtpengine and security
by GG GG 21 Apr '15

21 Apr '15

Hello, what do you think about opening all RTP ports for rtpengine on Internet, is it a bad practice ? I wonder if it's possible to use rtpengine with all ports closed. Maybe someone could explain how rtpengine learn the source address when the SDP contains a local address. If your rtpengine server is under attack, could rtpengine choose the wrong ip source for RTP ? Thanks.

2 1

UAC Module
by Ali Jibran 21 Apr '15

21 Apr '15

Hi all. I am using UAC module to establish two trunks to my provider. I can see that the trunks are registered successfully but the calls are coming only from the first one. The provider says server isn't responding on the second one. How is that possible when it says registered? Can somebody help me out here.

2 1

ACK and BYE routing - wrong interface problem and TCP/UDP conversion troubles
by Dmitry Sytchev 21 Apr '15

21 Apr '15

Hi all! I'm still working on incorrect routing of ACKs/BYEs with certain conditions and asking for guru help. My network looks like this: 192.168.4.218 -> TCP -> NAT (1.2.2.94) -> (1.2.0.160) Kamailio (1.2.0.160) -> UDP-> backend servers (1.2.2.44). IP address 1.2.0.16 is a 1.2.0.160/32 on loopback interface lo, and it is announced via BGP to neighbours. There is also 1.2.3.46/30, which is used to maintain BGP session. Backends are Asterisk 11 machines with "outboundproxy" sip peer setting set to Kamailio address. Kamailio forwards registrations to Asterisk servers with authentication and caches successful attempts to its internal DB. Natted clients are managed adding 'received' param to reg contact. When backend calls client, Kamailio takes correct URI from 'received' and forwards request. There is a possibility Kamailio will have several IP addresses for outbound clients. To specify source address of forwarded packets I set $fs. For initial requests and responses all works fine, but there are troubles when dealing with ACKs and BYEs. In case I don't specify interfaces with 'listen' , Kamailio listens on 1.2.0.160 and 1.2.3.46. I use $fs to set 1.2.0.160 as outgoing interface, and it works for requests. But when Kamailio forwards ACKs and BYEs, it uses 3.46 instead of 1.2.0.160, especially in case of TCP client and UDP backend. If I set mhomed = 0 and specify Kamailio to listen only to 1.2.0.160, everything works fine, except UDP <-> TCP signalling conversion. When natted TCP client receives call from backend, it answers with 200 OK and ACK from backend is never back to client. At the same time UDP<->UDP works fine. I've noted that TCP and UDP ACKs differ in Record-route headers, in case of TCP there are two records of Kamailio UDP/TCP. I have enable_double_rr = 1. UDP ACK: ACK sip:0097242@192.168.4.218:5063 SIP/2.0. Via: SIP/2.0/UDP 1.2.2.44:5060;branch=z9hG4bK31d1a26c;rport. Route: <sip:1.2.0.160;lr=on;ftag=as7af34000>. Max-Forwards: 70. From: <sip:8121230000@1.2.2.44>;tag=as7af34000. To: <sip:0097242@192.168.4.218:5063;received=sip:1.2.2.94:64825>;tag=3122411720. Contact: <sip:8121230000@1.2.2.44:5060>. Call-ID: 56c5362d2250df6777e6665523964729@1.2.2.44:5060. CSeq: 102 ACK. User-Agent: Zero vPBX. Content-Length: 0. This ack forwarded to destination correctly (to external IP 1.2.2.94:64825). Actually, I don't understand why, because $du is null and no functions logged that rURI was modified... TCP ACK: ACK sip:0097242@192.168.4.218:5062;transport=TCP SIP/2.0 Via: SIP/2.0/UDP 1.2.2.44:5060;branch=z9hG4bK08f7b9f2;rport Route: <sip:1.2.0.160;r2=on;lr=on;ftag=as5cc06d60>,<sip:1.2.0.160;transport=tcp;r2=on;lr=on;ftag=as5cc06d60> Max-Forwards: 70 From: <sip:8121230000@1.2.2.44>;tag=as5cc06d60 To: <sip:0097242@192.168.4.218:5062;transport=TCP;received=sip:1.2.2.94:57735;transport=TCP>;tag=4089422268 Contact: <sip:8121230000@1.2.2.44:5060> Call-ID: 3a72968b552bdb8875e3215431f1522d@1.2.2.44:5060 CSeq: 102 ACK User-Agent: Zero vPBX Content-Length: 0 This ack doesn't get forwarded anywhere, although Kamailio says: DEBUG: <core> [forward.c:592]: forward_request(): Sending:#012ACK sip:0097242@192.168.4.218:5062;transport=TCP SIP/2.0#015#012Via: SIP/2.0/TCP 1.2.0.160;branch=z9hG4bK42a6.5e57399c6a2c1dae96f28c7381b6c64e.0#015#012Via: SIP/2.0/UDP 1.2.2.44:5060;received=1.2.2.44;branch=z9hG4bK26130626;rport=5060#015#012Max-Forwards: 69#015#012From: <sip:8121230000@1.2.2.44>;tag=as74c521ed#015#012To: <sip:0097242@192.168.4.218:5062;transport=TCP;received=sip:1.2.2.94:65535;transport=TCP>;tag=547751151#015#012Contact: <sip:8121230000@1.2.2.44:5060>#015#012Call-ID: 10dfa7d00a9848c411a28bb54edf0f14@1.2.2.44:5060#015#012CSeq: 102 ACK#015#012User-Agent: Zero vPBX#015#012Content-Length: 0#015#012#015#012. So I'm trying to understand - how Kamailio get correct destination address to send to in case of UDP <-> UDP ack, and why the same doesn't work in case of TCP? If I turn on mhomed = 1, it breaks forwarding of UDP ACKs too... Maybe it is because of 1.2.0.160/32 IP address it is placed on lo iface, or there should be some entries in IP routing table on Kamailio host allowing selection of 1.2.0.160? Thanks in advance! -- Best regards, Dmitry Sytchev, IT Engineer

1 0

Re: [SR-Users] registrar: add optional check for local path during lookup()
by Charles Chance 21 Apr '15

21 Apr '15

Hi Volkan, It is in the master (development) branch, so will appear in the next major release (4.3). The code could not be backported to 4.2 because it was considered a new feature rather than a fix. Cheers, Charles P.S. please use mailing list in case the question is useful to others :-) On 21 April 2015 at 12:57, Volkan Hatem <volkan(a)hatem.net> wrote: > Hi Charles, > > I was hoping to see your change ( > http://git.kamailio.org/gitlist/index.php/kamailio/commits/635f23b12eff2431…) > in 4.2.4 > > I could not tell to which branch your code was submitted. Do you know when > it might find its way to an official release? > > Best, > -volkan > -- www.sipcentric.com Follow us on twitter @sipcentric <http://twitter.com/sipcentric> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.

1 0

MOH SIP SERVERS
by Kevin LeClair 19 Apr '15

19 Apr '15

Greetings, I'm new to the VoIP / SIP world but have successfully provisioned my new Yealink T48G and have begun to setup some of the many features. Of course one of the coolest features I found was the Music On Hold (MOH) with a SIP server. I configured the T48G to your sip:music@iptel.org which worked awesomely! My question is: Can I setup a SIP server with you to upload a default mp3 for using with my own MOH complete with SIP server URI? OR are there other services that do this? I have some of my own servers but I'm guessing that many servers do not allow the SIP MOH functionality? Thanks so much for your time. MaineWWW - A Maine Website Design Company Otter Creek, Maine 207-669-4269 <http://www.mainewww.com/> mainewww.com "One Site for All Devices" <http://www.mainewww.com/> maine_www_logo_small2

2 1

uri=myself question
by Andres 18 Apr '15

18 Apr '15

Hi, I have a question about about 'myself' usage. for example: if(uri==myself) { log("the request is for local processing\n"); }; I have always expected the above to hold true for any 'alias' definition in the config file. But I never really though about the domain module since I use the test "is_uri_host_local()" for that. So my question is, if we have an entry in the domain module will it resolve to true for the "(uri==myself)" test even if it's not an alias? Thanks, -- Technical Support http://www.cellroute.net

2 2

Kamailio relays ACK of 200 OK to itself
by Dmitry Sytchev 17 Apr '15

17 Apr '15

Hi all! I can't make my Kamailio to correctly relay stateful ACKs for 200 OK. It takes URI from Route: header and trying relay it to itself instead of sending it to host sent 200 OK. I don't understand why it can't match transaction and relay to correct host. Seems BYEs aren't relayed correctly either... 192.168.4.218 -> NAT 1.2.2.94 -> Kamailo (1.2.3.46, 1.2.2.219) -> 172.19.126.105 192.168.4.218 sends INVITE to 1.2.3.45 which relays it to 172.19.126.105. After 172.19.126.105 answers with 200 OK, it never gets ACK for it back. Instead, ACK relayed by proxy to 1.2.3.46 (one of proxy addresses). Example of original ACK: ACK sip:89211234567@172.19.126.105:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.4.218:5062;branch=z9hG4bK1161188624. Route: <sip:1.2.3.46;lr=on;ftag=259196205;nat=yes>. From: "0099977" <sip:0099977@1.2.3.46>;tag=259196205. To: <sip:89211234567@1.2.3.46>;tag=as6bfd1fa1. Call-ID: 910089142(a)192.168.4.218. CSeq: 2 ACK. Contact: <sip:0099977@192.168.4.218:5062>. Max-Forwards: 70. User-Agent: Yealink SIP-T46G 28.71.14.4. Content-Length: 0. It sees that host is not local: check_self: host != me I think the problem is somewhere in my NAT handling script code, but seems I'm stuck and can't get what am I doing wrong, so I'll greatly appreciate any help. Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <2> <ACK> Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: maxfwd [mf_funcs.c:85]: is_maxfwd_present(): value = 70 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [parser/msg_parser.c:204]: get_hdr_field(): DEBUG: get_hdr_body : content_length=0 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [parser/msg_parser.c:106]: get_hdr_field(): found end of header Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: sanity [mod_sanity.c:255]: w_sanity_check(): sanity checks result: 1 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: INFO: <script>: Nat detected Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: siputils [sipops.c:161]: w_is_first_hop(): no 2nd via found - first hop Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: INFO: <script>: Set contact alias Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [dset.c:774]: uri_add_rcv_alias(): encoded <sip:0099977@192.168.4.218:5062> => [sip:0099977@192.168.4.218:5062;alias =1.2.2.94~58542~1] Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: siputils [checks.c:106]: has_totag(): totag found Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: INFO: <script>: Request in dialog Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: rr [loose.c:90]: is_preloaded(): is_preloaded: No Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 14==9 && [172.19.126.105] == [127.0.0. 1] Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 14==12 && [172.19.126.105] == [1.2. 2.219] Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 14==11 && [172.19.126.105] == [1.2. 3.46] Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 14==9 && [172.19.126.105] == [127.0.0. 1] Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 14==12 && [172.19.126.105] == [1.2. 2.219] Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 14==11 && [172.19.126.105] == [1.2. 3.46] Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [forward.c:448]: check_self(): check_self: host != me Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: rr [loose.c:674]: after_strict(): Next hop: 'sip:1.2.3.46;lr=on;ftag=259196205;nat=yes' is loose router Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: rr [loose.c:724]: after_strict(): The last route URI: 'sip:1.2.3.46;lr=on;ftag=259196205;nat=yes' Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: outbound [ob_mod.c:496]: use_outbound(): Analysing ACK for outbound markers Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 11==9 && [1.2.3.46] == [127.0.0.1] Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 11==12 && [1.2.3.46] == [1.2.2.2 19] Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 11==11 && [1.2.3.46] == [1.2.3.4 6] Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: outbound [ob_mod.c:466]: use_outbound_non_reg(): outbound not used Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: siputils [checks.c:106]: has_totag(): totag found Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: siputils [checks.c:106]: has_totag(): totag found Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: NOTICE: <script>: REL: ACK sip:1.2.3.46;lr=on;ftag=259196205;nat=yes -> sip:1.2.3.46;lr=on;ftag=259196205;nat=yes Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: tm [t_lookup.c:1373]: t_newtran(): DEBUG: t_newtran: msg id=59 , global msg id=58 , T on entrance=0xffffffff Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: tm [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start searching: hash=37956, isACK=1 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: tm [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction matching failed Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: tm [t_lookup.c:709]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: tm [t_funcs.c:312]: t_relay_to(): SER: forwarding ACK statelessly Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [md5utils.c:67]: MD5StringArray(): DEBUG: MD5 calculated: 2132d578ec20fa9b478ada51e9f2965f Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [forward.c:211]: get_out_socket(): DEBUG: get_out_socket: socket determined: 0xf6e777ec Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [msg_translator.c:206]: check_via_address(): check_via_address(1.2.2.94, 192.168.4.218, 0) Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [forward.c:592]: forward_request(): Sending:#012ACK sip:1.2.3.46;lr=on;ftag=259196205;nat=yes SIP/2.0#015#012Record-Route: <sip:1.2.3.46;lr=on;ftag=259196205>#015#012Via: SIP/2.0/UDP 1.2.3.46;branch=z9hG4bK4449.2132d578ec20fa9b478ada51e9f2965f.0#015#012Via: SIP/2.0/UDP 192.168.4.218:5062;rport=58542;received=1.2.2.94;branch=z9hG4bK1161188624#015#012From: "0099977" <sip:0099977@1.2.3.46>;tag=259196205#015#012To: <sip:89215572714@1.2.3.46>;tag=as6bfd1fa1#015#012Call-ID: 910089142(a)192.168.4.218#015#012CSeq: 2 ACK#015#012Contact: <sip:0099977@192.168.4.218:5062;alias=1.2.2.94~58542~1>#015#012Max-Forwards: 69#015#012User-Agent: Yealink SIP-T46G 28.71.14.4#015#012Content-Length: 0#015#012#015#012. -- Best regards, Dmitry Sytchev, IT Engineer

2 4

Loadbalancing proxy using DNS SRV instead of dispatcher
by Daniel Tryba 17 Apr '15

17 Apr '15

The idea is to use SRV records instead of a dispatcher by setting $rd to a DNS SRV enabled host (with all hosts having the same prio and weight). Problem is that when authentication is required the flow is as follows (with 2 hosts): 1: UAC INVITE/REGISTER -> LB -> SIP0 SIP0 401 with nonce1 challenge -> LB -> UAC UAC ACK -> LB -> SIP0 2: UAC INVITE/REGISTER with nonce1 response -> LB -> SIP1 SIP1 401 with nonce2 challenge -> LB -> UAC UACK ACK -> LB -> SIP1 3: UAC INVITE/REGISTER with nonce2 response -> LB -> SIP0 SIP0 401 with nonce1 challenge -> LB -> UAC UACK ACK -> LB -> SIP0 4: UAC either gives up or goes to 2 Using the dispatcher module this can be solved by using a hash over either from/to/request URI. I can't find any hints for forcing the dialog to 1 backend. BTW the idea is to keep the loadbalancing proxy as simple/stupid as possible (no db), the backends have a shared db.

4 7

memcached module trimming the leading 8 char with innodb module
by Ethan Brooks 16 Apr '15

16 Apr '15

This is very simple Kamailio config and when i access Memcached directly everything seem to be fine but, when accessed via Kamailio he leading 8 char is omitted. I have included everything needed to test. kamailio mpath="/usr/lib/x86_64-linux-gnu/kamailio/modules/" debug=0 fork=yes loadmodule "tm.so" loadmodule "sl.so" loadmodule "pv.so" loadmodule "xhttp.so" loadmodule "memcached.so" modparam("memcached", "servers", "localhost:11211") port=80 tcp_accept_no_cl=yes event_route[xhttp:request] { $var(number) = $hu; $var(number) = $(var(number){s.substr,2,0}); xhttp_reply("200", "OK", "text/html", "value: $mct(@@lnp.$var(number))"); } mysql: source /usr/share/mysql/innodb_memcached_config.sql install plugin daemon_memcached soname "libmemcached.so"; CREATE SCHEMA lnp; CREATE TABLE `lnp`.`lnp` ( `number` bigint(20) NOT NULL, `ported` bigint(20) DEFAULT NULL, PRIMARY KEY (`number`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; insert into lnp.lnp (number,ported) values (8055551212,8053214321); insert into innodb_memcache.containers (name,db_schema,db_table,key_columns,value_columns,flags,cas_column, expire_time_column,unique_idx_name_on_key) values ('lnp','lnp','lnp','number','ported', 0,0,0,'PRIMARY'); url: http://localhost/?8055551212 reponse: value: 21 memcached # nc localhost 11211 get @@lnp.8055551212 VALUE @@lnp.8055551212 0 10 8053214321 END

2 1

Kamailio + Mediaproxy - How to set up
by Filip Malenka 16 Apr '15

16 Apr '15

Hi all, I have searched for instructions for setting up Kamailio with mediaproxy instead of rtpproxy, but I can't find anything. I found only OpenSips pages and some other outdated examples but the config does not apply very much on kamailio.cfg. As much as I could find out is that Kamailio natively supports rtpproxy and OpenSips works with mediaproxy. Is there any solution for Kamailio with mediaproxy? Thank you! Filip -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

3 5

SipML5-Kamailio+RtpEngine-ThirdpartySipServers- Not All SIP Servers are working
by Karthik Kondapaneni 16 Apr '15

16 Apr '15

Can someone help me please … I am using this setup . Sipml5 webrtc client(chrome) -----> Kamailio with RTP engine ------> ThridpartySip Server kamalio will act as mediator between webRTC client and NonWebRTC sip server . User will be registered on sip server and calls will be terminated to PSTN . This setup is working fine with one thirdparty sip server but not working with other SIP server . First server ( working ) is happily replying INVITE request and reponding with "TRYING " . But Second SIP server never reply to kamailio for INVITE requests and kamailio keep sending SDP and finally on SipML5 it shows "request timed out " Ports are open on Firewall . SIP Server 1: 192.168.102.237 SIP Server 2: 192.168.87.101 Kamailio IP : 172.17.185.46 Client PUblic ip : 79.207.241.94 1. Working Server Trace ---- INVITE sip:917638900890@192.168.102.237 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bK3929.368fd6fd45db4710e7acd52df40d3903.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKJHBbZaGh9noFlUgS1VVr8DCImVbITu0q;rport=54273 From: "2016"<sip:testcard@192.168.102.237>;tag=6mGSo8IPI4pGsvh6To1A To: <sip:917638900890@192.168.102.237> Contact: "2016"<sip:testcard@df7jal23ls0d.invalid ;alias=79.207.241.94~54273~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 89be25db-d9ed-616e-118e-c6b3a863d8fd CSeq: 62565 INVITE Content-Type: application/sdp Content-Length: 819 Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8650276303411124000 2 IN IP4 172.17.185.46 s=DD - chrome t=0 0 a=msid-semantic: WMS tosDjBW9pSViLfckZBR4gh6AolFzau3iBjgG m=audio 30246 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:2398380477 cname:8WcQLQ8hOhk5MhWZ a=ssrc:2398380477 msid:tosDjBW9pSViLfckZBR4gh6AolFzau3iBjgG 63b396a3-5126-405f-a389-75548cf0a634 a=ssrc:2398380477 mslabel:tosDjBW9pSViLfckZBR4gh6AolFzau3iBjgG a=ssrc:2398380477 label:63b396a3-5126-405f-a389-75548cf0a634 a=sendrecv a=rtcp:30247 SIP/2.0 407 Proxy Authentication Required Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bK3929.368fd6fd45db4710e7acd52df40d3903.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKJHBbZaGh9noFlUgS1VVr8DCImVbITu0q;rport=54273 From: "2016" <sip:testcard@192.168.102.237>;tag=6mGSo8IPI4pGsvh6To1A To: <sip:917638900890@192.168.102.237> Contact: "2016" <sip:testcard@192.168.102.237:5060> Call-Id: 89be25db-d9ed-616e-118e-c6b3a863d8fd CSeq: 62565 INVITE Proxy-Authenticate: Digest realm="sip.dingdongbell.net", nonce="c2133e5e1e40805244c5f201cfbaee4d", algorithm=MD5 Content-Length: 0 ACK sip:917638900890@192.168.102.237 SIP/2.0 Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bK3929.368fd6fd45db4710e7acd52df40d3903.0 From: "2016"<sip:testcard@192.168.102.237>;tag=6mGSo8IPI4pGsvh6To1A To: <sip:917638900890@192.168.102.237> Call-ID: 89be25db-d9ed-616e-118e-c6b3a863d8fd CSeq: 62565 ACK Content-Length: 0 Max-Forwards: 69 INVITE sip:917638900890@192.168.102.237 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bK0929.61a39db61290521db7dc657d252c4182.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKnswxFdcreaCt0SMSRCqs2HPPOSN9adR6;rport=54273 From: "2016"<sip:testcard@192.168.102.237>;tag=6mGSo8IPI4pGsvh6To1A To: <sip:917638900890@192.168.102.237> Contact: "2016"<sip:testcard@df7jal23ls0d.invalid ;alias=79.207.241.94~54273~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 89be25db-d9ed-616e-118e-c6b3a863d8fd CSeq: 62566 INVITE Content-Type: application/sdp Content-Length: 819 Max-Forwards: 69 Proxy-Authorization: Digest username="testcard",realm="sip.dingdongbell.net ",nonce="c2133e5e1e40805244c5f201cfbaee4d",uri=" sip:917638900890@192.168.102.237 ",response="fb9c97e380c4231725d1119256f7f7d9",algorithm=MD5 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8650276303411124000 2 IN IP4 172.17.185.46 s=DD- chrome t=0 0 a=msid-semantic: WMS tosDjBW9pSViLfckZBR4gh6AolFzau3iBjgG m=audio 30246 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:2398380477 cname:8WcQLQ8hOhk5MhWZ a=ssrc:2398380477 msid:tosDjBW9pSViLfckZBR4gh6AolFzau3iBjgG 63b396a3-5126-405f-a389-75548cf0a634 a=ssrc:2398380477 mslabel:tosDjBW9pSViLfckZBR4gh6AolFzau3iBjgG a=ssrc:2398380477 label:63b396a3-5126-405f-a389-75548cf0a634 a=sendrecv a=rtcp:30247 SIP/2.0 100 Trying Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bK0929.61a39db61290521db7dc657d252c4182.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKnswxFdcreaCt0SMSRCqs2HPPOSN9adR6;rport=54273 From: "2016" <sip:testcard@192.168.102.237>;tag=6mGSo8IPI4pGsvh6To1A To: <sip:917638900890@192.168.102.237> Contact: <sip:917638900890@192.168.102.237:5060> Call-Id: 89be25db-d9ed-616e-118e-c6b3a863d8fd CSeq: 62566 INVITE Content-Length: 0 2. Not working Server trace ( second server)-------------------- INVITE sip:917638900890@192.168.87.101 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bKc8b9.d6c920a694694e5d3104f492c48d2582.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKBXNMor2TC7eWrTb87WqF4qQN34s6MtQ0;rport=50933 From: "2017"<sip:testcard2@192.168.87.101>;tag=axqOflPwynQ898Qu2Tue To: <sip:917638900890@192.168.87.101> Contact: "2017"<sip:testcard2@df7jal23ls0d.invalid ;alias=79.207.241.94~50933~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 6b04e418-dbdf-21aa-39b7-1c2fb1d72f6b CSeq: 8601 INVITE Content-Type: application/sdp Content-Length: 811 Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8501880612358765000 2 IN IP4 172.17.185.46 s=DD - chrome t=0 0 a=msid-semantic: WMS 2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 m=audio 30038 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:68402186 cname:W2sB0/Nke1Gs8u89 a=ssrc:68402186 msid:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 62dff51b-f07b-4788-98cb-72c25ff2ab1b a=ssrc:68402186 mslabel:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 a=ssrc:68402186 label:62dff51b-f07b-4788-98cb-72c25ff2ab1b a=sendrecv a=rtcp:30039 INVITE sip:917638900890@192.168.87.101 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bKc8b9.d6c920a694694e5d3104f492c48d2582.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKBXNMor2TC7eWrTb87WqF4qQN34s6MtQ0;rport=50933 From: "2017"<sip:testcard2@192.168.87.101>;tag=axqOflPwynQ898Qu2Tue To: <sip:917638900890@192.168.87.101> Contact: "2017"<sip:testcard2@df7jal23ls0d.invalid ;alias=79.207.241.94~50933~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 6b04e418-dbdf-21aa-39b7-1c2fb1d72f6b CSeq: 8601 INVITE Content-Type: application/sdp Content-Length: 811 Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8501880612358765000 2 IN IP4 172.17.185.46 s=DD - chrome t=0 0 a=msid-semantic: WMS 2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 m=audio 30038 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:68402186 cname:W2sB0/Nke1Gs8u89 a=ssrc:68402186 msid:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 62dff51b-f07b-4788-98cb-72c25ff2ab1b a=ssrc:68402186 mslabel:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 a=ssrc:68402186 label:62dff51b-f07b-4788-98cb-72c25ff2ab1b a=sendrecv a=rtcp:30039 INVITE sip:917638900890@192.168.87.101 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bKc8b9.d6c920a694694e5d3104f492c48d2582.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKBXNMor2TC7eWrTb87WqF4qQN34s6MtQ0;rport=50933 From: "2017"<sip:testcard2@192.168.87.101>;tag=axqOflPwynQ898Qu2Tue To: <sip:917638900890@192.168.87.101> Contact: "2017"<sip:testcard2@df7jal23ls0d.invalid ;alias=79.207.241.94~50933~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 6b04e418-dbdf-21aa-39b7-1c2fb1d72f6b CSeq: 8601 INVITE Content-Type: application/sdp Content-Length: 811 Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8501880612358765000 2 IN IP4 172.17.185.46 s=DD - chrome t=0 0 a=msid-semantic: WMS 2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 m=audio 30038 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:68402186 cname:W2sB0/Nke1Gs8u89 a=ssrc:68402186 msid:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 62dff51b-f07b-4788-98cb-72c25ff2ab1b a=ssrc:68402186 mslabel:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 a=ssrc:68402186 label:62dff51b-f07b-4788-98cb-72c25ff2ab1b a=sendrecv a=rtcp:30039 INVITE sip:917638900890@192.168.87.101 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bKc8b9.d6c920a694694e5d3104f492c48d2582.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKBXNMor2TC7eWrTb87WqF4qQN34s6MtQ0;rport=50933 From: "2017"<sip:testcard2@192.168.87.101>;tag=axqOflPwynQ898Qu2Tue To: <sip:917638900890@192.168.87.101> Contact: "2017"<sip:testcard2@df7jal23ls0d.invalid ;alias=79.207.241.94~50933~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 6b04e418-dbdf-21aa-39b7-1c2fb1d72f6b CSeq: 8601 INVITE Content-Type: application/sdp Content-Length: 811 Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8501880612358765000 2 IN IP4 172.17.185.46 s=DD - chrome t=0 0 a=msid-semantic: WMS 2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 m=audio 30038 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:68402186 cname:W2sB0/Nke1Gs8u89 a=ssrc:68402186 msid:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 62dff51b-f07b-4788-98cb-72c25ff2ab1b a=ssrc:68402186 mslabel:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 a=ssrc:68402186 label:62dff51b-f07b-4788-98cb-72c25ff2ab1b a=sendrecv a=rtcp:30039 INVITE sip:917638900890@192.168.87.101 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bKc8b9.d6c920a694694e5d3104f492c48d2582.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKBXNMor2TC7eWrTb87WqF4qQN34s6MtQ0;rport=50933 From: "2017"<sip:testcard2@192.168.87.101>;tag=axqOflPwynQ898Qu2Tue To: <sip:917638900890@192.168.87.101> Contact: "2017"<sip:testcard2@df7jal23ls0d.invalid ;alias=79.207.241.94~50933~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 6b04e418-dbdf-21aa-39b7-1c2fb1d72f6b CSeq: 8601 INVITE Content-Type: application/sdp Content-Length: 811 Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8501880612358765000 2 IN IP4 172.17.185.46 s=DD - chrome t=0 0 a=msid-semantic: WMS 2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 m=audio 30038 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:68402186 cname:W2sB0/Nke1Gs8u89 a=ssrc:68402186 msid:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 62dff51b-f07b-4788-98cb-72c25ff2ab1b a=ssrc:68402186 mslabel:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 a=ssrc:68402186 label:62dff51b-f07b-4788-98cb-72c25ff2ab1b a=sendrecv a=rtcp:30039 INVITE sip:917638900890@192.168.87.101 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bKc8b9.d6c920a694694e5d3104f492c48d2582.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKBXNMor2TC7eWrTb87WqF4qQN34s6MtQ0;rport=50933 From: "2017"<sip:testcard2@192.168.87.101>;tag=axqOflPwynQ898Qu2Tue To: <sip:917638900890@192.168.87.101> Contact: "2017"<sip:testcard2@df7jal23ls0d.invalid ;alias=79.207.241.94~50933~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 6b04e418-dbdf-21aa-39b7-1c2fb1d72f6b CSeq: 8601 INVITE Content-Type: application/sdp Content-Length: 811 Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8501880612358765000 2 IN IP4 172.17.185.46 s=DD - chrome t=0 0 a=msid-semantic: WMS 2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 m=audio 30038 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:68402186 cname:W2sB0/Nke1Gs8u89 a=ssrc:68402186 msid:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 62dff51b-f07b-4788-98cb-72c25ff2ab1b a=ssrc:68402186 mslabel:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 a=ssrc:68402186 label:62dff51b-f07b-4788-98cb-72c25ff2ab1b a=sendrecv a=rtcp:30039 INVITE sip:917638900890@192.168.87.101 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bKc8b9.d6c920a694694e5d3104f492c48d2582.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKBXNMor2TC7eWrTb87WqF4qQN34s6MtQ0;rport=50933 From: "2017"<sip:testcard2@192.168.87.101>;tag=axqOflPwynQ898Qu2Tue To: <sip:917638900890@192.168.87.101> Contact: "2017"<sip:testcard2@df7jal23ls0d.invalid ;alias=79.207.241.94~50933~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 6b04e418-dbdf-21aa-39b7-1c2fb1d72f6b CSeq: 8601 INVITE Content-Type: application/sdp Content-Length: 811 Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8501880612358765000 2 IN IP4 172.17.185.46 s=DD - chrome t=0 0 a=msid-semantic: WMS 2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 m=audio 30038 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:68402186 cname:W2sB0/Nke1Gs8u89 a=ssrc:68402186 msid:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 62dff51b-f07b-4788-98cb-72c25ff2ab1b a=ssrc:68402186 mslabel:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 a=ssrc:68402186 label:62dff51b-f07b-4788-98cb-72c25ff2ab1b a=sendrecv a=rtcp:30039 INVITE sip:917638900890@192.168.87.101 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bKc8b9.d6c920a694694e5d3104f492c48d2582.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKBXNMor2TC7eWrTb87WqF4qQN34s6MtQ0;rport=50933 From: "2017"<sip:testcard2@192.168.87.101>;tag=axqOflPwynQ898Qu2Tue To: <sip:917638900890@192.168.87.101> Contact: "2017"<sip:testcard2@df7jal23ls0d.invalid ;alias=79.207.241.94~50933~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 6b04e418-dbdf-21aa-39b7-1c2fb1d72f6b CSeq: 8601 INVITE Content-Type: application/sdp Content-Length: 811 Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8501880612358765000 2 IN IP4 172.17.185.46 s=DD - chrome t=0 0 a=msid-semantic: WMS 2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 m=audio 30038 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:68402186 cname:W2sB0/Nke1Gs8u89 a=ssrc:68402186 msid:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 62dff51b-f07b-4788-98cb-72c25ff2ab1b a=ssrc:68402186 mslabel:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 a=ssrc:68402186 label:62dff51b-f07b-4788-98cb-72c25ff2ab1b a=sendrecv a=rtcp:30039 INVITE sip:917638900890@192.168.87.101 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bKc8b9.d6c920a694694e5d3104f492c48d2582.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKBXNMor2TC7eWrTb87WqF4qQN34s6MtQ0;rport=50933 From: "2017"<sip:testcard2@192.168.87.101>;tag=axqOflPwynQ898Qu2Tue To: <sip:917638900890@192.168.87.101> Contact: "2017"<sip:testcard2@df7jal23ls0d.invalid ;alias=79.207.241.94~50933~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 6b04e418-dbdf-21aa-39b7-1c2fb1d72f6b CSeq: 8601 INVITE Content-Type: application/sdp Content-Length: 811 Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8501880612358765000 2 IN IP4 172.17.185.46 s=DD - chrome t=0 0 a=msid-semantic: WMS 2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 m=audio 30038 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:68402186 cname:W2sB0/Nke1Gs8u89 a=ssrc:68402186 msid:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 62dff51b-f07b-4788-98cb-72c25ff2ab1b a=ssrc:68402186 mslabel:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 a=ssrc:68402186 label:62dff51b-f07b-4788-98cb-72c25ff2ab1b a=sendrecv a=rtcp:30039 INVITE sip:917638900890@192.168.87.101 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bKc8b9.d6c920a694694e5d3104f492c48d2582.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKBXNMor2TC7eWrTb87WqF4qQN34s6MtQ0;rport=50933 From: "2017"<sip:testcard2@192.168.87.101>;tag=axqOflPwynQ898Qu2Tue To: <sip:917638900890@192.168.87.101> Contact: "2017"<sip:testcard2@df7jal23ls0d.invalid ;alias=79.207.241.94~50933~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 6b04e418-dbdf-21aa-39b7-1c2fb1d72f6b CSeq: 8601 INVITE Content-Type: application/sdp Content-Length: 811 Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8501880612358765000 2 IN IP4 172.17.185.46 s=DD - chrome t=0 0 a=msid-semantic: WMS 2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 m=audio 30038 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:68402186 cname:W2sB0/Nke1Gs8u89 a=ssrc:68402186 msid:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 62dff51b-f07b-4788-98cb-72c25ff2ab1b a=ssrc:68402186 mslabel:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 a=ssrc:68402186 label:62dff51b-f07b-4788-98cb-72c25ff2ab1b a=sendrecv a=rtcp:30039 Kamailio Config :----------------------------------- request_route { if ((($Rp == MY_WS_PORT || $Rp == MY_WSS_PORT) && !(proto == WS || proto == WSS))) { xlog("L_WARN", "SIP request received on $Rp\n"); sl_send_reply("403", "Forbidden"); exit; } # per request initial checks route(REQINIT); # NAT detection route(NATDETECT); # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) { route(RELAY); } exit; } # handle requests within SIP dialogs route(WITHINDLG); ### only initial requests (no To tag) t_check_trans(); if (!is_method("REGISTER|INVITE|ACK|BYE|CANCEL|PRACK|MESSAGE|INFO|UPDATE")) { sl_send_reply("405", "Method not allowed"); exit; } # authentication route(AUTH); # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) record_route_preset("172.17.185.46:5090;nat=yes"); # handle registrations route(REGISTRAR); # if ($rU==$null) { # # request with no Username in RURI # sl_send_reply("484","Address Incomplete"); # exit; # } # if (!is_method("INVITE")) { # route(RELAY); # exit; # } route(RELAY); } route[SETUP_BY_TRANSPORT] { if ($ru =~ "transport=ws") { xlog("L_INFO", "Request going to WS"); if(sdp_with_transport("RTP/SAVPF")) { rtpengine_manage("force trust-address replace-origin replace-session-connection ICE=force"); t_on_reply("REPLY_WS_TO_WS"); return; } # rtpengine_manage("froc+SP"); rtpengine_manage("force trust-address replace-origin replace-session-connection ICE=force RTP/SAVPF"); t_on_reply("REPLY_FROM_WS"); } else if ($proto =~ "ws") { xlog("L_INFO", "Request coming from WS"); # rtpengine_manage("froc-sp"); rtpengine_manage("force rtcp-mux-demux symmetric trust-address replace-origin replace-session-connection ICE=remove RTP/AVP"); t_on_reply("REPLY_TO_WS"); } else { xlog("L_INFO", "This is a classic phone call"); # rtpengine_manage("co"); rtpengine_manage("replace-origin replace-session-connection"); t_on_reply("MANAGE_CLASSIC_REPLY"); } } event_route[xhttp:request] { set_reply_close(); set_reply_no_connect(); if ($Rp != MY_WS_PORT #!ifdef WITH_TLS && $Rp != MY_WSS_PORT #!endif ) { xlog("L_WARN", "HTTP request received on $Rp\n"); xhttp_reply("403", "Forbidden", "", ""); exit; } xlog("L_INFO", "HTTP Request Received\n"); if ($hdr(Upgrade)=~"websocket" && $hdr(Connection)=~"Upgrade" && $rm=~"GET") { # Validate Host - make sure the client is using the correct # alias for WebSockets if ($hdr(Host) == $null || !is_myself("sip:" + $hdr(Host))) { xlog("L_WARN", "Bad host $hdr(Host)\n"); xhttp_reply("403", "Forbidden", "", ""); exit; } if (ws_handle_handshake()) { # Optional... cache some information about the # successful connection exit; } } xhttp_reply("404", "Not Found", "", ""); } route[RELAY] { if (is_method("INVITE")) { route(SETUP_BY_TRANSPORT); if(!t_is_set("failure_route")) t_on_failure("MANAGE_FAILURE"); } if (!t_relay()) { sl_reply_error(); } exit; }

1 0

Kamailio load statistics
by Mickael Marrache 16 Apr '15

16 Apr '15

Hi, What are the statistics that should be used to monitor a Kamailio instance? I currently looked at shmem_real_used_size, shmem_used_size, dialogs_active_dialogs. However, I'm looking for other statistics that represent the load on the instance. Thanks, Mickael

1 0

rtpengine "SRT[C]P output wanted, but no crypto suite" messages
by Juha Heinanen 16 Apr '15

16 Apr '15

some calls that use rtpengine produce "SRT[C]P output wanted, but no crypto suite was negotiated" syslog messages. below is an example. the messages seem to appear after rtpengine has replied to offer request, but before it has got answer request that includes crypto suite negotiation in its sdp. the calls work fine and i was wondering if these syslog message are really needed? -- juha Apr 16 08:34:37 box /usr/bin/sip-proxy[18719]: INFO: ===== rtpengine_offer(ICE=force replace-session-connection replace-origin via-branch=1) Apr 16 08:34:37 box rtpengine[31871]: [dd63b7bcd45655b8] Received command 'offer' from 127.0.0.1:46713 Apr 16 08:34:37 box rtpengine[31871]: [dd63b7bcd45655b8] Dump for 'offer' from 127.0.0.1:46713: { "sdp": "v=0#015#012o=- 2909773022 619612917 IN IP4 192.168.43.192#015#012s=-#015#012c=IN IP4 192.168.43.192#015#012t=0 0#015#012a=tool:baresip 0.4.12#015#012m=audio 10022 RTP/SAVP 96 97 8 0 101#015#012b=AS:128#015#012a=rtpmap:96 speex/16000#015#012a=fmtp:96 mode="7";vbr=off;cng=on#015#012a=rtpmap:97 speex/8000#015#012a=fmtp:97 mode="7";vbr=off;cng=on#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:0 PCMU/8000#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101 0-15#015#012a=sendrecv#015#012a=label:1#015#012a=rtcp-rsize#015#012a=ssrc:227522320 cname:sip:test@tutpro ... Apr 16 08:34:37 box rtpengine[31871]: [dd63b7bcd45655b8] ... .com#015#012a=rtcp-mux#015#012a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:lRfv9v0tfQAKXiJihqbgr7rNS5Gh9txvuqPv9Tt0#015#012a=ptime:20#015#012", "ICE": "force", "replace": [ "session-connection", "origin" ], "call-id": "dd63b7bcd45655b8", "via-branch": "z9hG4bK83c7fd2c1c254f15", "received-from": [ "IP4", "94.100.20.99" ], "from-tag": "5408ab343077ba14", "command": "offer" } Apr 16 08:34:37 box rtpengine[31871]: [dd63b7bcd45655b8] Creating new call Apr 16 08:34:37 box rtpengine[31871]: [dd63b7bcd45655b8] Opened ports 8046..8047 for media relay Apr 16 08:34:37 box rtpengine[31871]: [dd63b7bcd45655b8] Opened ports 8056..8057 for media relay Apr 16 08:34:37 box rtpengine[31871]: [dd63b7bcd45655b8] Shutting down ICE agent (nothing to do) Apr 16 08:34:37 box rtpengine[31871]: [dd63b7bcd45655b8] Replying to 'offer' from 127.0.0.1:46713 Apr 16 08:34:37 box rtpengine[31871]: [dd63b7bcd45655b8] Response dump for 'offer' to 127.0.0.1:46713: { "sdp": "v=0#015#012o=- 2909773022 619612917 IN IP4 194.40.50.30#015#012s=-#015#012c=IN IP4 194.40.50.30#015#012t=0 0#015#012a=tool:baresip 0.4.12#015#012m=audio 8046 RTP/SAVP 96 97 8 0 101#015#012b=AS:128#015#012a=rtpmap:96 speex/16000#015#012a=fmtp:96 mode="7";vbr=off;cng=on#015#012a=rtpmap:97 speex/8000#015#012a=fmtp:97 mode="7";vbr=off;cng=on#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:0 PCMU/8000#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101 0-15#015#012a=label:1#015#012a=rtcp-rsize#015#012a=ssrc:227522320 cname:sip:test@tutpro.com#015#012a= ... Apr 16 08:34:37 box rtpengine[31871]: [dd63b7bcd45655b8] ... ptime:20#015#012a=sendrecv#015#012a=rtcp:8047#015#012a=rtcp-mux#015#012a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:lRfv9v0tfQAKXiJihqbgr7rNS5Gh9txvuqPv9Tt0#015#012a=setup:actpass#015#012a=fingerprint:sha-1 F3:4F:0A:B8:75:BF:B6:29:45:8A:C2:74:8E:F9:10:F2:CB:10:50:37#015#012a=ice-ufrag:eUJUwfKq#015#012a=ice-pwd:bDuCQKxJTV5voKlVAarucAiqv1#015#012a=candidate:FvaQOQwZdXFAyxXW 1 UDP 2130706431 194.40.50.30 8046 typ host#015#012a=candidate:FvaQOQwZdXFAyxXW 2 UDP 2130706430 194.40.50.30 8047 typ host#015#012", "result": "ok" } Apr 16 08:34:37 box /usr/bin/sip-proxy[18719]: INFO: Routing INVITE <sip:jh@10.13.40.239:53269;transport=TLS;ob> to contact via <sip:94.100.20.99:53269;transport=TLS> Apr 16 08:34:37 box rtpengine[31871]: [dd63b7bcd45655b8 port 8047] SRTCP output wanted, but no crypto suite was negotiated Apr 16 08:34:37 box rtpengine[31871]: [dd63b7bcd45655b8 port 8046] SRTP output wanted, but no crypto suite was negotiated Apr 16 08:34:37 box /usr/bin/sip-proxy[18718]: INFO: ===== rtpengine_answer(ICE=force via-branch=2) Apr 16 08:34:37 box rtpengine[31871]: [dd63b7bcd45655b8] Received command 'answer' from 127.0.0.1:51555 Apr 16 08:34:37 box rtpengine[31871]: [dd63b7bcd45655b8] Dump for 'answer' from 127.0.0.1:51555: { "sdp": "v=0#015#012o=- 3638151276 3638151277 IN IP4 10.13.40.239#015#012s=pjmedia#015#012c=IN IP4 10.13.40.239#015#012t=0 0#015#012m=audio 4002 RTP/SAVP 96 101#015#012c=IN IP4 10.13.40.239#015#012a=rtcp:4003 IN IP4 10.13.40.239#015#012a=sendrecv#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101 0-16#015#012a=zrtp-hash:1.10 4261405ee55bb84370419b56f37c3966505a583ff6fee02e1c1b854cfccb5d99#015#012a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:8/oEJd3pVqWg6tvAJkItNBxQ60sJS44mnwriZRrt#015#012a=rtpmap:96 speex/16000#015#012", "ICE": "forc ... Apr 16 08:34:37 box rtpengine[31871]: [dd63b7bcd45655b8] ... e", "call-id": "dd63b7bcd45655b8", "via-branch": "z9hG4bK83c7fd2c1c254f15", "received-from": [ "IP4", "94.100.20.99" ], "from-tag": "5408ab343077ba14", "to-tag": "Zi.x-8OwwXlfKNC-67q3D7M7PeMqbmGh", "command": "answer" } Apr 16 08:34:37 box rtpengine[31871]: [dd63b7bcd45655b8] Replying to 'answer' from 127.0.0.1:51555 Apr 16 08:34:37 box rtpengine[31871]: [dd63b7bcd45655b8] Response dump for 'answer' to 127.0.0.1:51555: { "sdp": "v=0#015#012o=- 3638151276 3638151277 IN IP4 10.13.40.239#015#012s=pjmedia#015#012c=IN IP4 10.13.40.239#015#012t=0 0#015#012m=audio 8056 RTP/SAVP 96 101#015#012c=IN IP4 194.40.50.30#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101 0-16#015#012a=zrtp-hash:1.10 4261405ee55bb84370419b56f37c3966505a583ff6fee02e1c1b854cfccb5d99#015#012a=rtpmap:96 speex/16000#015#012a=sendrecv#015#012a=rtcp:8057#015#012a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:8/oEJd3pVqWg6tvAJkItNBxQ60sJS44mnwriZRrt#015#012a=candidate:FvaQOQwZdXFAyxX ... Apr 16 08:34:37 box rtpengine[31871]: [dd63b7bcd45655b8] ... W 1 UDP 2130706431 194.40.50.30 8056 typ host#015#012a=candidate:FvaQOQwZdXFAyxXW 2 UDP 2130706430 194.40.50.30 8057 typ host#015#012", "result": "ok" }

1 0

Re: [SR-Users] No CDR is written when dialog timeouts
by Mickael Marrache 15 Apr '15

15 Apr '15

I'm looking at the dlg_ontimeout function [dlg_handlers.c:1369] and I understand the code, the DLGCB_EXPIRED callbacks are not called when the send_bye parameter is set to 1. I'm looking at the block 1399-1408. From: Mickael Marrache [mailto:mickaelmarrache@gmail.com] Sent: Wednesday, April 15, 2015 3:53 PM To: sr-users(a)lists.sip-router.org Subject: RE: No CDR is written when dialog timeouts I also confirm the cdr_on_create() [acc_cdr.c:718] function is called since I can see the debug statement "dialog '%p' created!". From: Mickael Marrache [mailto:mickaelmarrache@gmail.com] Sent: Wednesday, April 15, 2015 3:48 PM To: sr-users(a)lists.sip-router.org Subject: No CDR is written when dialog timeouts Hi, I'm testing the dialog timeout scenario and I see that no CDR is written. This is my configuration: modparam("acc", "cdr_enable", 1) modparam("acc", "cdr_expired_dlg_enable", 1) modparam("acc", "cdr_start_on_confirmed", 1) modparam("acc", "cdr_log_enable", 0) modparam("acc", "cdr_on_failed", 0) I can confirm the cdr_on_expired() [acc_cdr.c:684] function is not called since I don't see the debug statement "dialog '%p' expired!\n". (I precise that CDR generation works fine for regular hangup scenario.) Any idea what can cause the issue? Thanks, Mickael

3 8

Differentiating between regular hangup and dialog timeout
by Mickael Marrache 15 Apr '15

15 Apr '15

Hi, I'm looking for a way to differentiate between regular hangup and dialog timeout. In both case, the dialog:end event is called. Do you know which information can I use in the event route to differentiate between the two cases? Thanks, Mickael

2 3

Inconsistent dlg timer data warning at dialog timeout
by Mickael Marrache 15 Apr '15

15 Apr '15

Hi, I get the following warning when a dialog timeout occurs: kamailio[18889]: WARNING: dialog [dlg_req_within.c:214]: bye_reply_cb(): inconsitent dlg timer data on dlg 0x7f422986e448 [3547:6673] with clid 'mycvJWgmbmOSD5XQrcStKAKoTfW12XeR' and tags 'C5mlsaZCdTmybNSYgvWr75MBxWa5hVyA' 'L1ZzszpZ1MYO6qlQQ3FYYRWQYtF4F75r' Am I doing something wrong? Thanks, Mickael

3 6

Re: [SR-Users] No CDR is written when dialog timeouts
by Mickael Marrache 15 Apr '15

15 Apr '15

I also confirm the cdr_on_create() [acc_cdr.c:718] function is called since I can see the debug statement "dialog '%p' created!". From: Mickael Marrache [mailto:mickaelmarrache@gmail.com] Sent: Wednesday, April 15, 2015 3:48 PM To: sr-users(a)lists.sip-router.org Subject: No CDR is written when dialog timeouts Hi, I'm testing the dialog timeout scenario and I see that no CDR is written. This is my configuration: modparam("acc", "cdr_enable", 1) modparam("acc", "cdr_expired_dlg_enable", 1) modparam("acc", "cdr_start_on_confirmed", 1) modparam("acc", "cdr_log_enable", 0) modparam("acc", "cdr_on_failed", 0) I can confirm the cdr_on_expired() [acc_cdr.c:684] function is not called since I don't see the debug statement "dialog '%p' expired!\n". (I precise that CDR generation works fine for regular hangup scenario.) Any idea what can cause the issue? Thanks, Mickael

1 0

No CDR is written when dialog timeouts
by Mickael Marrache 15 Apr '15

15 Apr '15

Hi, I'm testing the dialog timeout scenario and I see that no CDR is written. This is my configuration: modparam("acc", "cdr_enable", 1) modparam("acc", "cdr_expired_dlg_enable", 1) modparam("acc", "cdr_start_on_confirmed", 1) modparam("acc", "cdr_log_enable", 0) modparam("acc", "cdr_on_failed", 0) I can confirm the cdr_on_expired() [acc_cdr.c:684] function is not called since I don't see the debug statement "dialog '%p' expired!\n". (I precise that CDR generation works fine for regular hangup scenario.) Any idea what can cause the issue? Thanks, Mickael

1 0

Shared location database used by independend kamailios
by Daniel Tryba 15 Apr '15

15 Apr '15

Is there an easy way to figure out on which server a uac is registered when using a shared database (modparam("usrloc", "db_mode", 3)). When uac1 is registered on server1 (dns srv loadbalancing) and uac2 is on server2. A call from uac1 to uac2 with a simple lookup("location") will result in server1 directly trying to connect to uac2. If this device is natted (or behind a stateful firewall) this will fail. In the location table the column socket contains the server which received the request. So if I know this value I can have server2 route the call to this value/server and have the call delivered to uac1 via an "existing connection". The idea was to use reg_fetch_contacts to fetch this/these socket values in $ulc and in case they are not local redirect/branch to those servers. But if the value of socket isn't local the $ulc for socket is null. I could use sqlops to fetch this manually, but is there an easier way I am missing?

4 9

DNS resolution and logical domain
by Mickael Marrache 15 Apr '15

15 Apr '15

Hi, I sometimes get the following errors: kamailio[16098]: ERROR: <core> [resolve.c:1693]: sip_hostport2su(): could not resolve hostname: "mycompany.com" kamailio[16098]: ERROR: tm [ut.h:319]: uri2dst2(): failed to resolve "mycompany.com" mycompany.com cannot be resolved using DNS (there is no corresponding DNS entry). I use this as a logical domain and I don't expect Kamailio to resolve it. Also, I set use_domain (usrloc module) to 0 so only the RURI username is used when searching locations. The flow is as follows: -the proxy receives the INVITE with sip: <sip:%3cuser%3e@myloadbalancerip:5060> <user>@myloadbalancerip:5060 which then forwards the INVITE to a proxy -the proxy looks for <user> internally and finds that this user has multiple subscribers (endpoints) -for each subscriber, a branch is appended using append_branch (or the RURI is replaced for the first subscriber) - the new RURI for each branch is sip: <sip:%3csubscriber%3e@mycompany.com> <subscriber>@mycompany.com -finally, lookup_branches is called to look for locations for every subscriber lookup_branches only uses the subscriber (RURI username) for searching locations since use_domain is set to 0. However, I sometimes get the errors I mentioned. Any idea why Kamailio sometimes tries to resolve the domain name? Thanks, Mickael

2 1

Error protoaddr2proxy
by Igor Potjevlesch 15 Apr '15

15 Apr '15

Hello, I got many errors like this one: ERROR: tm [tm.c:1192]: t_protoaddr2proxy(): tm: protoaddr2proxy: host name is empty It looks to be while I'm doing a sl_send_reply but I don't figure out why. Someone know what going wrong? Regards, Igor.

2 2

Carrierroute question
by Nelson Migliaro 14 Apr '15

14 Apr '15

Hello everyone, I have a SIP provider that gives me access to different routes over the same IP address but different prefixes. I have to send all calls to the same IP but I need to inlcude a prefix to allow vendor to route calls to different carriers. I will use carrierroute (cr) module and in case prefix 1 fails, I should send the call to prefix 2 and so on. The problem I have is cr module detects that this host (public vendor ip) was already used and I am getting this warning: NOTICE: carrierroute [cr_func.c:324]: cr_uri_already_used(): Candidate destination This machine use public DNS and I tried to set up 3 entries in /etc/hosts public_iP vendor_1 public_iP vendor_2 public_iP vendor_3 and instead of using the IP in rewrite_host I changed to the name: vendor_1, vendor_2. vendor_3 but I got error: ERROR: tm [ut.h:337]: uri2dst2(): failed to resolve "vendor_1" Is there a better war to resolve this Thank you in advance

2 2

Error configuring kamailio with sql.
by Satish Verma 14 Apr '15

14 Apr '15

Respected sir, I want to configure SIP voip server using tutorial ( http://kb.asipto.com/kamailio:skype-like-service-in-less-than-one-hour). i have configured everything on my ubuntu server as given in tutorial. but i am getting error while running start command ( /etc/init.d/kamailio start) the error as given below. root@wifi:/etc/kamailio# /etc/init.d/kamailio start * Not starting Kamailio SIP Server: invalid configuration file! * * 0(32729) INFO: tls [tls_init.c:401]: init_tls_compression(): tls: init_tls: disabling compression... 0(32729) ERROR: <core> [cfg.y:3288]: yyparse(): cfg. parser: failed to find command force_rtp_proxy (params 0) 0(32729) : <core> [cfg.y:3428]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 729, column 19: unknown command, missing loadmodule? 0(32729) ERROR: <core> [cfg.y:3288]: yyparse(): cfg. parser: failed to find command force_rtp_proxy (params 0) 0(32729) : <core> [cfg.y:3428]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 806, column 19: unknown command, missing loadmodule? ERROR: bad config file (2 errors) i have tried running using default kamailio.cfg then it works fine. but i want to configure using script uploaded by u. please do the needful. i will be very thankful to you. With regards, Satish verma, Programming Assistant, UIET, Panjab University, Chandigarh. Mobile no +917307737732

3 2

Re: [SR-Users] CDR fields are all strings
by Mickael Marrache 14 Apr '15

14 Apr '15

I created a pull request that I tested using MongoDB. It works fine. Let me know if I can help more. Mickael From: Mickael Marrache [mailto:mickaelmarrache@gmail.com] Sent: Monday, April 13, 2015 5:13 PM To: miconda(a)gmail.com; 'Kamailio (SER) - Users Mailing List' Subject: RE: [SR-Users] CDR fields are all strings We are using MongoDB and all the values are inserted as strings. I also tried using the time_mode and time_format parameters, but it looks like they are only relevant for transactions accounting. Regarding the duration, it is set as a string for any backend. I think this behavior strongly limits us (and probably others) performing queries on CDRs (especially queries based on start and end time). Mickael From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Daniel-Constantin Mierla Sent: Monday, April 13, 2015 3:03 PM To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] CDR fields are all strings Hello, On 13/04/15 11:48, Mickael Marrache wrote: Hi, Why are all the CDR fields inserted as strings? For extra fields, I can understand it is easier to implement. However, for the built in fields (e.g. duration), we need to perform queries based on duration and time and it is not really possible using strings. Dialog variables hold only strings and those values are stored in variables, iirc -- that was the design behind the concept done by initial developer. Perhaps they can be easily updated to hold integers. Anyhow, iirc, at least with mysql it should work to insert any value enclosed in quotes, not matter the field type. For datetime that is acutually the default -- to use quotes, afaik. So if you change the types of columns, it should just work. We can push a patch if most of the people think is better to use different column types. Cheers, Daniel I see that the time field for failed transactions is inserted as a date. -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com

2 1

Playing with presence module and offline AoR
by Roberto Fichera 14 Apr '15

14 Apr '15

Hi All, I've started to play with presence module on kamailo 4.1.6, everything seems to work quite well up to now except one thing. I would like to notify the presence status of a NOT currently registered AoR as not online instead of not present. How can I do that? Thanks in advance, Roberto Fichera.

1 0

Timeout session Kamailio w/ rtpproxy v2
by Igor Potjevlesch 13 Apr '15

13 Apr '15

Hi everyone, I've sent my request on the rtpproxy google group without answer so try here. I'm using Kamailio 4.2.3 (and few older versions) with the new release of rtpproxy. I can't get the info of a session timeout (-n or -i options) from rtpproxy to my Kamailio proxy, using -n and the timeout socket. I tried: - Kamailio side: *modparam("rtpproxy", "timeout_socket", "unix:/var/run/rtpproxy_timeout.sock")* - rtpproxy side: *-n **unix:/var/run/rtpproxy_timeout.sock* and other configuration like tcp, or udp socket, but nothing is happening on the Kamailio part. The Kamailio rtpproxy man page give the example: *modparam("rtpproxy", "timeout_socket", "xmlrpc:http://127.0.0.1:8000/RPC2 <http://127.0.0.1:8000/RPC2>")* Does it mean Kamailio only handles XMLRPC socket ? In this case, is rtpproxy able to handle XMLRPC (I remember a patch in an older rtpproxy version) In the case Kamailio could handle other socket types, which one could allow me to get a session timeout signal from rtpproxy in order to generate BYE message at the signalling side ? I could add that rtpproxy stops well RTP sessions that timed out. Regards, Igor Potjevlesc

2 1

Re: [SR-Users] Avoiding "script writer didn't release transaction" warnings
by Mickael Marrache 13 Apr '15

13 Apr '15

Any idea? From: Mickael Marrache [mailto:mickaelmarrache@gmail.com] Sent: Thursday, April 09, 2015 2:08 PM To: sr-users(a)lists.sip-router.org Subject: RE: Avoiding "script writer didn't release transaction" warnings I think understand in which case it happens. When I receive a REGISTER, I create a transaction since I need to use the t_continue feature to wake up a suspended transaction. However, the save() command of the REGISTRAR module doesn't seem to call t_reply for replying the 200 (it looks like the SL module is used instead). Therefore, I get the warning every time it happens since the transaction is not released explicitly. Should I call t_release just before exiting the block handling the REGISTER? From: Mickael Marrache [mailto:mickaelmarrache@gmail.com] Sent: Thursday, April 09, 2015 1:43 PM To: sr-users(a)lists.sip-router.org Subject: Avoiding "script writer didn't release transaction" warnings Hi, In my logs, I get a lot of the following warnings: WARNING: tm [t_lookup.c:1476]: t_unref(): WARNING: script writer didn't release transaction I force transaction creation from my script to absorb retransmissions as soon as possible. I understand that I need to explicitly call t_release in order to avoid this warning. What is the most appropriate place in the script to call t_release? Thanks, Mickael

2 6

Maximum feasible size of htable?
by Brooks Bridges 13 Apr '15

13 Apr '15

I have a small-ish project that could benefit from using an htable for storage of very basic data that doesn't change much, and I'd like to get an idea of what the group's experience is with storing larger amounts of data? Something in the 15-20GB range. Yes I could use Redis, but the idea here is to minimize the amount of dependencies and processing required. Thoughts? Brooks Bridges | Sr. Voice Services Engineer O1 Communications 5190 Golden Foothill Pkwy El Dorado Hills, CA 95762 office: 916.235.2097 | main: 888.444.1111, Option 2 email: bbridges(a)o1.com<mailto:bbridges@o1.com> | web: www.o1.com<http://www.o1.com/>

2 2

CDR fields are all strings
by Mickael Marrache 13 Apr '15

13 Apr '15

Hi, Why are all the CDR fields inserted as strings? For extra fields, I can understand it is easier to implement. However, for the built in fields (e.g. duration), we need to perform queries based on duration and time and it is not really possible using strings. I see that the time field for failed transactions is inserted as a date. Thanks, Mickael

2 2

Sipml5-Kamailio -RtpEngine -ThridpartySipServers- Not all sip servers working
by Karthik Kondapaneni 13 Apr '15

13 Apr '15

Dear experts , I am using this setup . Sipml5 webrtc client(chrome) -----> Kamailio with RTP engine ------> ThridpartySip Server kamalio will act as mediator between webRTC client and NonWebRTC sip server . User will be registered on sip server and calls will be terminated to PSTN . This setup is working fine with one thirdparty sip server but not working with other SIP server . First server ( working ) is happily replying INVITE request and reponding with "TRYING " . But Second SIP server never reply to kamailio for INVITE requests and kamailio keep sending SDP and finally on SipML5 it shows "request timed out " Ports are open on Firewall . SIP Server 1: 192.168.102.237 SIP Server 2: 192.168.87.101 Kamailio IP : 172.17.185.46 Client PUblic ip : 79.207.241.94 1. Working Server Trace ---- INVITE sip:917638900890@192.168.102.237 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bK3929.368fd6fd45db4710e7acd52df40d3903.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKJHBbZaGh9noFlUgS1VVr8DCImVbITu0q;rport=54273 From: "2016"<sip:testcard@192.168.102.237>;tag=6mGSo8IPI4pGsvh6To1A To: <sip:917638900890@192.168.102.237> Contact: "2016"<sip:testcard@df7jal23ls0d.invalid ;alias=79.207.241.94~54273~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 89be25db-d9ed-616e-118e-c6b3a863d8fd CSeq: 62565 INVITE Content-Type: application/sdp Content-Length: 819 Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8650276303411124000 2 IN IP4 172.17.185.46 s=DD - chrome t=0 0 a=msid-semantic: WMS tosDjBW9pSViLfckZBR4gh6AolFzau3iBjgG m=audio 30246 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:2398380477 cname:8WcQLQ8hOhk5MhWZ a=ssrc:2398380477 msid:tosDjBW9pSViLfckZBR4gh6AolFzau3iBjgG 63b396a3-5126-405f-a389-75548cf0a634 a=ssrc:2398380477 mslabel:tosDjBW9pSViLfckZBR4gh6AolFzau3iBjgG a=ssrc:2398380477 label:63b396a3-5126-405f-a389-75548cf0a634 a=sendrecv a=rtcp:30247 SIP/2.0 407 Proxy Authentication Required Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bK3929.368fd6fd45db4710e7acd52df40d3903.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKJHBbZaGh9noFlUgS1VVr8DCImVbITu0q;rport=54273 From: "2016" <sip:testcard@192.168.102.237>;tag=6mGSo8IPI4pGsvh6To1A To: <sip:917638900890@192.168.102.237> Contact: "2016" <sip:testcard@192.168.102.237:5060> Call-Id: 89be25db-d9ed-616e-118e-c6b3a863d8fd CSeq: 62565 INVITE Proxy-Authenticate: Digest realm="sip.dingdongbell.net", nonce="c2133e5e1e40805244c5f201cfbaee4d", algorithm=MD5 Content-Length: 0 ACK sip:917638900890@192.168.102.237 SIP/2.0 Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bK3929.368fd6fd45db4710e7acd52df40d3903.0 From: "2016"<sip:testcard@192.168.102.237>;tag=6mGSo8IPI4pGsvh6To1A To: <sip:917638900890@192.168.102.237> Call-ID: 89be25db-d9ed-616e-118e-c6b3a863d8fd CSeq: 62565 ACK Content-Length: 0 Max-Forwards: 69 INVITE sip:917638900890@192.168.102.237 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bK0929.61a39db61290521db7dc657d252c4182.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKnswxFdcreaCt0SMSRCqs2HPPOSN9adR6;rport=54273 From: "2016"<sip:testcard@192.168.102.237>;tag=6mGSo8IPI4pGsvh6To1A To: <sip:917638900890@192.168.102.237> Contact: "2016"<sip:testcard@df7jal23ls0d.invalid ;alias=79.207.241.94~54273~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 89be25db-d9ed-616e-118e-c6b3a863d8fd CSeq: 62566 INVITE Content-Type: application/sdp Content-Length: 819 Max-Forwards: 69 Proxy-Authorization: Digest username="testcard",realm="sip.dingdongbell.net ",nonce="c2133e5e1e40805244c5f201cfbaee4d",uri=" sip:917638900890@192.168.102.237 ",response="fb9c97e380c4231725d1119256f7f7d9",algorithm=MD5 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8650276303411124000 2 IN IP4 172.17.185.46 s=DD- chrome t=0 0 a=msid-semantic: WMS tosDjBW9pSViLfckZBR4gh6AolFzau3iBjgG m=audio 30246 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:2398380477 cname:8WcQLQ8hOhk5MhWZ a=ssrc:2398380477 msid:tosDjBW9pSViLfckZBR4gh6AolFzau3iBjgG 63b396a3-5126-405f-a389-75548cf0a634 a=ssrc:2398380477 mslabel:tosDjBW9pSViLfckZBR4gh6AolFzau3iBjgG a=ssrc:2398380477 label:63b396a3-5126-405f-a389-75548cf0a634 a=sendrecv a=rtcp:30247 SIP/2.0 100 Trying Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bK0929.61a39db61290521db7dc657d252c4182.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKnswxFdcreaCt0SMSRCqs2HPPOSN9adR6;rport=54273 From: "2016" <sip:testcard@192.168.102.237>;tag=6mGSo8IPI4pGsvh6To1A To: <sip:917638900890@192.168.102.237> Contact: <sip:917638900890@192.168.102.237:5060> Call-Id: 89be25db-d9ed-616e-118e-c6b3a863d8fd CSeq: 62566 INVITE Content-Length: 0 2. Not working Server trace ( second server)-------------------- INVITE sip:917638900890@192.168.87.101 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bKc8b9.d6c920a694694e5d3104f492c48d2582.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKBXNMor2TC7eWrTb87WqF4qQN34s6MtQ0;rport=50933 From: "2017"<sip:testcard2@192.168.87.101>;tag=axqOflPwynQ898Qu2Tue To: <sip:917638900890@192.168.87.101> Contact: "2017"<sip:testcard2@df7jal23ls0d.invalid ;alias=79.207.241.94~50933~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 6b04e418-dbdf-21aa-39b7-1c2fb1d72f6b CSeq: 8601 INVITE Content-Type: application/sdp Content-Length: 811 Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8501880612358765000 2 IN IP4 172.17.185.46 s=DD - chrome t=0 0 a=msid-semantic: WMS 2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 m=audio 30038 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:68402186 cname:W2sB0/Nke1Gs8u89 a=ssrc:68402186 msid:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 62dff51b-f07b-4788-98cb-72c25ff2ab1b a=ssrc:68402186 mslabel:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 a=ssrc:68402186 label:62dff51b-f07b-4788-98cb-72c25ff2ab1b a=sendrecv a=rtcp:30039 INVITE sip:917638900890@192.168.87.101 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bKc8b9.d6c920a694694e5d3104f492c48d2582.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKBXNMor2TC7eWrTb87WqF4qQN34s6MtQ0;rport=50933 From: "2017"<sip:testcard2@192.168.87.101>;tag=axqOflPwynQ898Qu2Tue To: <sip:917638900890@192.168.87.101> Contact: "2017"<sip:testcard2@df7jal23ls0d.invalid ;alias=79.207.241.94~50933~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 6b04e418-dbdf-21aa-39b7-1c2fb1d72f6b CSeq: 8601 INVITE Content-Type: application/sdp Content-Length: 811 Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8501880612358765000 2 IN IP4 172.17.185.46 s=DD - chrome t=0 0 a=msid-semantic: WMS 2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 m=audio 30038 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:68402186 cname:W2sB0/Nke1Gs8u89 a=ssrc:68402186 msid:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 62dff51b-f07b-4788-98cb-72c25ff2ab1b a=ssrc:68402186 mslabel:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 a=ssrc:68402186 label:62dff51b-f07b-4788-98cb-72c25ff2ab1b a=sendrecv a=rtcp:30039 INVITE sip:917638900890@192.168.87.101 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bKc8b9.d6c920a694694e5d3104f492c48d2582.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKBXNMor2TC7eWrTb87WqF4qQN34s6MtQ0;rport=50933 From: "2017"<sip:testcard2@192.168.87.101>;tag=axqOflPwynQ898Qu2Tue To: <sip:917638900890@192.168.87.101> Contact: "2017"<sip:testcard2@df7jal23ls0d.invalid ;alias=79.207.241.94~50933~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 6b04e418-dbdf-21aa-39b7-1c2fb1d72f6b CSeq: 8601 INVITE Content-Type: application/sdp Content-Length: 811 Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8501880612358765000 2 IN IP4 172.17.185.46 s=DD - chrome t=0 0 a=msid-semantic: WMS 2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 m=audio 30038 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:68402186 cname:W2sB0/Nke1Gs8u89 a=ssrc:68402186 msid:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 62dff51b-f07b-4788-98cb-72c25ff2ab1b a=ssrc:68402186 mslabel:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 a=ssrc:68402186 label:62dff51b-f07b-4788-98cb-72c25ff2ab1b a=sendrecv a=rtcp:30039 INVITE sip:917638900890@192.168.87.101 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bKc8b9.d6c920a694694e5d3104f492c48d2582.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKBXNMor2TC7eWrTb87WqF4qQN34s6MtQ0;rport=50933 From: "2017"<sip:testcard2@192.168.87.101>;tag=axqOflPwynQ898Qu2Tue To: <sip:917638900890@192.168.87.101> Contact: "2017"<sip:testcard2@df7jal23ls0d.invalid ;alias=79.207.241.94~50933~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 6b04e418-dbdf-21aa-39b7-1c2fb1d72f6b CSeq: 8601 INVITE Content-Type: application/sdp Content-Length: 811 Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8501880612358765000 2 IN IP4 172.17.185.46 s=DD - chrome t=0 0 a=msid-semantic: WMS 2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 m=audio 30038 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:68402186 cname:W2sB0/Nke1Gs8u89 a=ssrc:68402186 msid:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 62dff51b-f07b-4788-98cb-72c25ff2ab1b a=ssrc:68402186 mslabel:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 a=ssrc:68402186 label:62dff51b-f07b-4788-98cb-72c25ff2ab1b a=sendrecv a=rtcp:30039 INVITE sip:917638900890@192.168.87.101 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bKc8b9.d6c920a694694e5d3104f492c48d2582.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKBXNMor2TC7eWrTb87WqF4qQN34s6MtQ0;rport=50933 From: "2017"<sip:testcard2@192.168.87.101>;tag=axqOflPwynQ898Qu2Tue To: <sip:917638900890@192.168.87.101> Contact: "2017"<sip:testcard2@df7jal23ls0d.invalid ;alias=79.207.241.94~50933~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 6b04e418-dbdf-21aa-39b7-1c2fb1d72f6b CSeq: 8601 INVITE Content-Type: application/sdp Content-Length: 811 Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8501880612358765000 2 IN IP4 172.17.185.46 s=DD - chrome t=0 0 a=msid-semantic: WMS 2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 m=audio 30038 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:68402186 cname:W2sB0/Nke1Gs8u89 a=ssrc:68402186 msid:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 62dff51b-f07b-4788-98cb-72c25ff2ab1b a=ssrc:68402186 mslabel:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 a=ssrc:68402186 label:62dff51b-f07b-4788-98cb-72c25ff2ab1b a=sendrecv a=rtcp:30039 INVITE sip:917638900890@192.168.87.101 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bKc8b9.d6c920a694694e5d3104f492c48d2582.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKBXNMor2TC7eWrTb87WqF4qQN34s6MtQ0;rport=50933 From: "2017"<sip:testcard2@192.168.87.101>;tag=axqOflPwynQ898Qu2Tue To: <sip:917638900890@192.168.87.101> Contact: "2017"<sip:testcard2@df7jal23ls0d.invalid ;alias=79.207.241.94~50933~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 6b04e418-dbdf-21aa-39b7-1c2fb1d72f6b CSeq: 8601 INVITE Content-Type: application/sdp Content-Length: 811 Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8501880612358765000 2 IN IP4 172.17.185.46 s=DD - chrome t=0 0 a=msid-semantic: WMS 2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 m=audio 30038 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:68402186 cname:W2sB0/Nke1Gs8u89 a=ssrc:68402186 msid:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 62dff51b-f07b-4788-98cb-72c25ff2ab1b a=ssrc:68402186 mslabel:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 a=ssrc:68402186 label:62dff51b-f07b-4788-98cb-72c25ff2ab1b a=sendrecv a=rtcp:30039 INVITE sip:917638900890@192.168.87.101 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bKc8b9.d6c920a694694e5d3104f492c48d2582.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKBXNMor2TC7eWrTb87WqF4qQN34s6MtQ0;rport=50933 From: "2017"<sip:testcard2@192.168.87.101>;tag=axqOflPwynQ898Qu2Tue To: <sip:917638900890@192.168.87.101> Contact: "2017"<sip:testcard2@df7jal23ls0d.invalid ;alias=79.207.241.94~50933~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 6b04e418-dbdf-21aa-39b7-1c2fb1d72f6b CSeq: 8601 INVITE Content-Type: application/sdp Content-Length: 811 Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8501880612358765000 2 IN IP4 172.17.185.46 s=DD - chrome t=0 0 a=msid-semantic: WMS 2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 m=audio 30038 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:68402186 cname:W2sB0/Nke1Gs8u89 a=ssrc:68402186 msid:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 62dff51b-f07b-4788-98cb-72c25ff2ab1b a=ssrc:68402186 mslabel:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 a=ssrc:68402186 label:62dff51b-f07b-4788-98cb-72c25ff2ab1b a=sendrecv a=rtcp:30039 INVITE sip:917638900890@192.168.87.101 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bKc8b9.d6c920a694694e5d3104f492c48d2582.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKBXNMor2TC7eWrTb87WqF4qQN34s6MtQ0;rport=50933 From: "2017"<sip:testcard2@192.168.87.101>;tag=axqOflPwynQ898Qu2Tue To: <sip:917638900890@192.168.87.101> Contact: "2017"<sip:testcard2@df7jal23ls0d.invalid ;alias=79.207.241.94~50933~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 6b04e418-dbdf-21aa-39b7-1c2fb1d72f6b CSeq: 8601 INVITE Content-Type: application/sdp Content-Length: 811 Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8501880612358765000 2 IN IP4 172.17.185.46 s=DD - chrome t=0 0 a=msid-semantic: WMS 2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 m=audio 30038 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:68402186 cname:W2sB0/Nke1Gs8u89 a=ssrc:68402186 msid:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 62dff51b-f07b-4788-98cb-72c25ff2ab1b a=ssrc:68402186 mslabel:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 a=ssrc:68402186 label:62dff51b-f07b-4788-98cb-72c25ff2ab1b a=sendrecv a=rtcp:30039 INVITE sip:917638900890@192.168.87.101 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bKc8b9.d6c920a694694e5d3104f492c48d2582.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKBXNMor2TC7eWrTb87WqF4qQN34s6MtQ0;rport=50933 From: "2017"<sip:testcard2@192.168.87.101>;tag=axqOflPwynQ898Qu2Tue To: <sip:917638900890@192.168.87.101> Contact: "2017"<sip:testcard2@df7jal23ls0d.invalid ;alias=79.207.241.94~50933~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 6b04e418-dbdf-21aa-39b7-1c2fb1d72f6b CSeq: 8601 INVITE Content-Type: application/sdp Content-Length: 811 Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8501880612358765000 2 IN IP4 172.17.185.46 s=DD - chrome t=0 0 a=msid-semantic: WMS 2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 m=audio 30038 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:68402186 cname:W2sB0/Nke1Gs8u89 a=ssrc:68402186 msid:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 62dff51b-f07b-4788-98cb-72c25ff2ab1b a=ssrc:68402186 mslabel:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 a=ssrc:68402186 label:62dff51b-f07b-4788-98cb-72c25ff2ab1b a=sendrecv a=rtcp:30039 INVITE sip:917638900890@192.168.87.101 SIP/2.0 Record-Route: <sip:172.17.185.46:5090;nat=yes;lr=on> Via: SIP/2.0/UDP 172.17.185.46:5090 ;branch=z9hG4bKc8b9.d6c920a694694e5d3104f492c48d2582.0 Via: SIP/2.0/WS df7jal23ls0d.invalid;received=79.207.241.94;branch=z9hG4bKBXNMor2TC7eWrTb87WqF4qQN34s6MtQ0;rport=50933 From: "2017"<sip:testcard2@192.168.87.101>;tag=axqOflPwynQ898Qu2Tue To: <sip:917638900890@192.168.87.101> Contact: "2017"<sip:testcard2@df7jal23ls0d.invalid ;alias=79.207.241.94~50933~5;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" Call-ID: 6b04e418-dbdf-21aa-39b7-1c2fb1d72f6b CSeq: 8601 INVITE Content-Type: application/sdp Content-Length: 811 Max-Forwards: 69 User-Agent: IM-client/OMA1.0 sipML5-v1.2015.03.18 Organization: DD v=0 o=- 8501880612358765000 2 IN IP4 172.17.185.46 s=DD - chrome t=0 0 a=msid-semantic: WMS 2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 m=audio 30038 RTP/AVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 172.17.185.46 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:68402186 cname:W2sB0/Nke1Gs8u89 a=ssrc:68402186 msid:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 62dff51b-f07b-4788-98cb-72c25ff2ab1b a=ssrc:68402186 mslabel:2pj4LaFD0X7B4Sa0IkGLFLZhZAoDcQm5nhk8 a=ssrc:68402186 label:62dff51b-f07b-4788-98cb-72c25ff2ab1b a=sendrecv a=rtcp:30039 Kamailio Config :----------------------------------- request_route { if ((($Rp == MY_WS_PORT || $Rp == MY_WSS_PORT) && !(proto == WS || proto == WSS))) { xlog("L_WARN", "SIP request received on $Rp\n"); sl_send_reply("403", "Forbidden"); exit; } # per request initial checks route(REQINIT); # NAT detection route(NATDETECT); # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) { route(RELAY); } exit; } # handle requests within SIP dialogs route(WITHINDLG); ### only initial requests (no To tag) t_check_trans(); if (!is_method("REGISTER|INVITE|ACK|BYE|CANCEL|PRACK|MESSAGE|INFO|UPDATE")) { sl_send_reply("405", "Method not allowed"); exit; } # authentication route(AUTH); # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) record_route_preset("172.17.185.46:5090;nat=yes"); # handle registrations route(REGISTRAR); # if ($rU==$null) { # # request with no Username in RURI # sl_send_reply("484","Address Incomplete"); # exit; # } # if (!is_method("INVITE")) { # route(RELAY); # exit; # } route(RELAY); } route[SETUP_BY_TRANSPORT] { if ($ru =~ "transport=ws") { xlog("L_INFO", "Request going to WS"); if(sdp_with_transport("RTP/SAVPF")) { rtpengine_manage("force trust-address replace-origin replace-session-connection ICE=force"); t_on_reply("REPLY_WS_TO_WS"); return; } # rtpengine_manage("froc+SP"); rtpengine_manage("force trust-address replace-origin replace-session-connection ICE=force RTP/SAVPF"); t_on_reply("REPLY_FROM_WS"); } else if ($proto =~ "ws") { xlog("L_INFO", "Request coming from WS"); # rtpengine_manage("froc-sp"); rtpengine_manage("force rtcp-mux-demux symmetric trust-address replace-origin replace-session-connection ICE=remove RTP/AVP"); t_on_reply("REPLY_TO_WS"); } else { xlog("L_INFO", "This is a classic phone call"); # rtpengine_manage("co"); rtpengine_manage("replace-origin replace-session-connection"); t_on_reply("MANAGE_CLASSIC_REPLY"); } } event_route[xhttp:request] { set_reply_close(); set_reply_no_connect(); if ($Rp != MY_WS_PORT #!ifdef WITH_TLS && $Rp != MY_WSS_PORT #!endif ) { xlog("L_WARN", "HTTP request received on $Rp\n"); xhttp_reply("403", "Forbidden", "", ""); exit; } xlog("L_INFO", "HTTP Request Received\n"); if ($hdr(Upgrade)=~"websocket" && $hdr(Connection)=~"Upgrade" && $rm=~"GET") { # Validate Host - make sure the client is using the correct # alias for WebSockets if ($hdr(Host) == $null || !is_myself("sip:" + $hdr(Host))) { xlog("L_WARN", "Bad host $hdr(Host)\n"); xhttp_reply("403", "Forbidden", "", ""); exit; } if (ws_handle_handshake()) { # Optional... cache some information about the # successful connection exit; } } xhttp_reply("404", "Not Found", "", ""); } route[RELAY] { if (is_method("INVITE")) { route(SETUP_BY_TRANSPORT); if(!t_is_set("failure_route")) t_on_failure("MANAGE_FAILURE"); } if (!t_relay()) { sl_reply_error(); } exit; }

1 0

End time in CDR
by Mickael Marrache 13 Apr '15

13 Apr '15

Hi, Very short question. Why the time at which the dialog ended is also included in the CDRs? There already are the start time and duration. Is it there to avoid end time computation? Mickael

1 0

Dialog based CDRs and failed dialogs
by Mickael Marrache 13 Apr '15

13 Apr '15

Hi, I'm using the ACC module to generate dialog based CDRs and I see that CDRs are generated even for failed calls. For example, a CDR is generated for cancelled calls. At first, I thought that dialog based CDRs are generated only for successfully established dialogs but it doesn't seem to be the case. Thanks, Mickael

2 4

Re: [SR-Users] MULTIDOMAIN Environment
by Bruno Emer 13 Apr '15

13 Apr '15

Hello Daniel! Thanks for your help again!! I placed the instruction just after the "authentication" and now it is working as I want! Bruno Emer 2015-04-09 15:33 GMT-03:00 Bruno Emer <brunoemer(a)gmail.com>: > Hello all! > > I have a scenario here where I need to put more than two companies into > the same Kamailio server and to accomplish this I'm using a multi-domain > configuration. > > For now, I am able to create users in different domains and register all > of them. The users are able to place and receive internal calls (as I am > using this just to get internal communications working), so I am ok with > this part of my configuration. > > The problem that I'm facing now is that users from domain "A" are able to > place calls to users from domain "B". I need to deny calls between > different domains, and I don't know the best way to achieve this. > > Here are my domains create (output from "kamctl domain show"): > > domain:: enterprise.com > did:: enterprise.com > domain:: enterprise2.com > did:: enterprise2.com > > > And here are my users created: > > username: bob > domain: enterprise.com > > username: alice > domain: enterprise2.com > > > So, can you please help me to get this? > > > Here is my .cfg file: > > > #!KAMAILIO > #!define WITH_PGSQL > #!define WITH_AUTH > #!define WITH_USRLOCDB > ##!define WITH_NAT > ##!define WITH_DEBUG > #!define WITH_MULTIDOMAIN > ##!define WITH_SIPTRACE > #!define WITH_SQLOPS > #!define WITH_XMLRPC > ##!define WITH_603 > #!define WITH_TLS > # > > > #!substdef "!MY_WS_PORT!80!g" > #!substdef "!MY_WSS_PORT!81!g" > #!substdef "!MY_WS_ADDR!eth1:MY_WS_PORT!g" > #!substdef "!MY_WSS_ADDR!tls:eth1:MY_WSS_PORT!g" > > #!define WITH_WEBSOCKETS > > > #!ifdef ACCDB_COMMENT > ALTER TABLE acc ADD COLUMN src_user VARCHAR(64) NOT NULL DEFAULT ''; > ALTER TABLE acc ADD COLUMN src_domain VARCHAR(128) NOT NULL DEFAULT ''; > ALTER TABLE acc ADD COLUMN src_ip varchar(64) NOT NULL default ''; > ALTER TABLE acc ADD COLUMN dst_ouser VARCHAR(64) NOT NULL DEFAULT ''; > ALTER TABLE acc ADD COLUMN dst_user VARCHAR(64) NOT NULL DEFAULT ''; > ALTER TABLE acc ADD COLUMN dst_domain VARCHAR(128) NOT NULL DEFAULT ''; > ALTER TABLE missed_calls ADD COLUMN src_user VARCHAR(64) NOT NULL > DEFAULT ''; > ALTER TABLE missed_calls ADD COLUMN src_domain VARCHAR(128) NOT NULL > DEFAULT ''; > ALTER TABLE missed_calls ADD COLUMN src_ip varchar(64) NOT NULL default > ''; > ALTER TABLE missed_calls ADD COLUMN dst_ouser VARCHAR(64) NOT NULL > DEFAULT ''; > ALTER TABLE missed_calls ADD COLUMN dst_user VARCHAR(64) NOT NULL > DEFAULT ''; > ALTER TABLE missed_calls ADD COLUMN dst_domain VARCHAR(128) NOT NULL > DEFAULT ''; > #!endif > > ####### Include Local Config If Exists ######### > import_file "kamailio-local.cfg" > > ####### Defined Values ######### > > # *** Value defines - IDs used later in config > #!ifdef WITH_PGSQL > # - database URL - used to connect to database server by modules such > # as: auth_db, acc, usrloc, a.s.o. > #!define DBURL "postgres://kamailio:kamailiorw@localhost/kamailio" > #!endif > #!ifdef WITH_MULTIDOMAIN > # - the value for 'use_domain' parameters > #!define MULTIDOMAIN 1 > #!else > #!define MULTIDOMAIN 0 > #!endif > > # - flags > # FLT_ - per transaction (message) flags > # FLB_ - per branch flags > #!define FLT_ACC 1 > #!define FLT_ACCMISSED 2 > #!define FLT_ACCFAILED 3 > #!define FLT_NATS 5 > > #!define FLB_NATB 6 > #!define FLB_NATSIPPING 7 > > ####### Global Parameters ######### > > ### LOG Levels: 3=DBG, 2=INFO, 1=NOTICE, 0=WARN, -1=ERR > #!ifdef WITH_DEBUG > debug=4 > log_stderror=yes > #!else > debug=2 > log_stderror=no > #!endif > > > memdbg=5 > memlog=5 > > log_facility=LOG_LOCAL0 > > fork=yes > children=4 > > /* uncomment the next line to disable TCP (default on) */ > disable_tcp=no > tcp_accept_no_cl=yes > > /* uncomment the next line to disable the auto discovery of local aliases > based on reverse DNS on IPs (default on) */ > #auto_aliases=no > > /* add local domain aliases */ > #alias="sip.mydomain.com" > > /* uncomment and configure the following line if you want Kamailio to > bind on a specific interface/port/proto (default bind on all available) > */ > #listen=udp:10.0.0.10:5060 > > /* port to listen to > * - can be specified more than once if needed to listen on many ports */ > port=5060 > > #!ifdef WITH_TLS > enable_tls=yes > #!endif > > # life time of TCP connection when there is no traffic > # - a bit higher than registration expires to cope with UA behind NAT > tcp_connection_lifetime=3605 > tcp_rd_buf_size=6144 > > listen=eth1 > #!ifdef WITH_WEBSOCKETS > listen=MY_WS_ADDR > #!ifdef WITH_TLS > listen=eth1 > #!endif > #!endif > > ####### Custom Parameters ######### > > # These parameters can be modified runtime via RPC interface > # - see the documentation of 'cfg_rpc' module. > # > # Format: group.id = value 'desc' description > # Access: $sel(cfg_get.group.id) or @cfg_get.group.id > # > > #!ifdef WITH_PSTN > # PSTN GW Routing > # > # - pstn.gw_ip: valid IP or hostname as string value, example: > # pstn.gw_ip = "10.0.0.101" desc "My PSTN GW Address" > # > # - by default is empty to avoid misrouting > pstn.gw_ip = "" desc "PSTN GW Address" > pstn.gw_port = "" desc "PSTN GW Port" > #!endif > > #!ifdef WITH_VOICEMAIL > # VoiceMail Routing on offline, busy or no answer > # > # - by default Voicemail server IP is empty to avoid misrouting > voicemail.srv_ip = "" desc "VoiceMail IP Address" > voicemail.srv_port = "5060" desc "VoiceMail Port" > #!endif > > ####### Modules Section ######## > > # set paths to location of modules (to sources or installation folders) > #!ifdef WITH_SRCPATH > mpath="modules/" > #!else > mpath="/usr/lib/x86_64-linux-gnu/kamailio/modules/" > #!endif > > #!ifdef WITH_PGSQL > loadmodule "db_postgres.so" > #!endif > > loadmodule "mi_fifo.so" > loadmodule "kex.so" > loadmodule "corex.so" > loadmodule "tm.so" > loadmodule "tmx.so" > loadmodule "sl.so" > loadmodule "rr.so" > loadmodule "pv.so" > loadmodule "maxfwd.so" > loadmodule "usrloc.so" > loadmodule "registrar.so" > loadmodule "textops.so" > loadmodule "siputils.so" > loadmodule "xlog.so" > loadmodule "sanity.so" > loadmodule "ctl.so" > loadmodule "cfg_rpc.so" > loadmodule "mi_rpc.so" > loadmodule "acc.so" > > #!ifdef WITH_AUTH > loadmodule "auth.so" > loadmodule "auth_db.so" > #!ifdef WITH_IPAUTH > loadmodule "permissions.so" > #!endif > #!endif > > #!ifdef WITH_ALIASDB > loadmodule "alias_db.so" > #!endif > > #!ifdef WITH_SPEEDDIAL > loadmodule "speeddial.so" > #!endif > > #!ifdef WITH_MULTIDOMAIN > loadmodule "domain.so" > #!endif > > #!ifdef WITH_PRESENCE > loadmodule "presence.so" > loadmodule "presence_xml.so" > #!endif > > #!ifdef WITH_NAT > loadmodule "nathelper.so" > loadmodule "rtpproxy.so" > #!endif > > #!ifdef WITH_TLS > loadmodule "tls.so" > #!endif > > #!ifdef WITH_ANTIFLOOD > loadmodule "htable.so" > loadmodule "pike.so" > #!endif > > #!ifdef WITH_XMLRPC > loadmodule "xmlrpc.so" > #!endif > > #!ifdef WITH_DEBUG > loadmodule "debugger.so" > #!endif > > #!ifdef WITH_SIPTRACE > loadmodule "siptrace.so" > #!endif > > #!ifdef WITH_SQLOPS > loadmodule "sqlops.so" > #!endif > > #!ifdef WITH_WEBSOCKETS > loadmodule "xhttp.so" > loadmodule "websocket.so" > loadmodule "nathelper.so" > #!endif > > # ----------------- setting module-specific parameters --------------- > > # ---- sip_trace params ---- > #!ifdef WITH_SIPTRACE > modparam("siptrace", "db_url", "postgres://kamailio:kamailiorw@localhost > /kamailio") > modparam("siptrace", "trace_on", 1) > modparam("siptrace", "trace_flag", 22) > modparam("siptrace", "trace_sl_acks", 0) > #!endif > > # ----- mi_fifo params ----- > modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo") > > > # ----- tm params ----- > # auto-discard branches from previous serial forking leg > modparam("tm", "failure_reply_mode", 3) > # default retransmission timeout: 30sec > modparam("tm", "fr_timer", 30000) > # default invite retransmission timeout after 1xx: 120sec > modparam("tm", "fr_inv_timer", 120000) > > # add value to ;lr param to cope with most of the UAs > modparam("rr", "enable_full_lr", 1) > # do not append from tag to the RR (no need for this script) > modparam("rr", "append_fromtag", 0) > > > # ----- registrar params ----- > modparam("registrar", "method_filtering", 1) > /* uncomment the next line to disable parallel forking via location */ > # modparam("registrar", "append_branches", 0) > /* uncomment the next line not to allow more than 10 contacts per AOR */ > #modparam("registrar", "max_contacts", 10) > # max value for expires of registrations > modparam("registrar", "max_expires", 300) > modparam("registrar", "min_expires", 30) > # set it to 1 to enable GRUU > modparam("registrar", "gruu_enabled", 0) > > > # ----- acc params ----- > /* what special events should be accounted ? */ > modparam("acc", "early_media", 0) > modparam("acc", "report_ack", 0) > modparam("acc", "report_cancels", 0) > /* by default ww do not adjust the direct of the sequential requests. > if you enable this parameter, be sure the enable "append_fromtag" > in "rr" module */ > modparam("acc", "detect_direction", 0) > /* account triggers (flags) */ > modparam("acc", "log_flag", FLT_ACC) > modparam("acc", "log_missed_flag", FLT_ACCMISSED) > modparam("acc", "log_extra", > "src_user=$fU;src_domain=$fd;src_ip=$si;" > "dst_ouser=$tU;dst_user=$rU;dst_domain=$rd") > modparam("acc", "failed_transaction_flag", FLT_ACCFAILED) > /* enhanced DB accounting */ > #!ifdef WITH_ACCDB > modparam("acc", "db_flag", FLT_ACC) > modparam("acc", "db_missed_flag", FLT_ACCMISSED) > modparam("acc", "db_url", DBURL) > modparam("acc", "db_extra", > "src_user=$fU;src_domain=$fd;src_ip=$si;" > "dst_ouser=$tU;dst_user=$rU;dst_domain=$rd") > #!endif > > > # ----- usrloc params ----- > /* enable DB persistency for location entries */ > #!ifdef WITH_USRLOCDB > modparam("usrloc", "db_url", DBURL) > modparam("usrloc", "db_mode", 2) > modparam("usrloc", "use_domain", MULTIDOMAIN) > #!endif > > > # ----- auth_db params ----- > #!ifdef WITH_AUTH > modparam("auth_db", "db_url", DBURL) > modparam("auth_db", "calculate_ha1", 0) > #modparam("auth_db", "password_column", "password") > modparam("auth_db", "load_credentials", "") > modparam("auth_db", "use_domain", MULTIDOMAIN) > #modparam("auth_db", "use_domain", 1) > > # ----- permissions params ----- > #!ifdef WITH_IPAUTH > modparam("permissions", "db_url", DBURL) > modparam("permissions", "db_mode", 1) > #!endif > > #!endif > > > # ----- alias_db params ----- > #!ifdef WITH_ALIASDB > modparam("alias_db", "db_url", DBURL) > modparam("alias_db", "use_domain", MULTIDOMAIN) > #!endif > > > # ----- speeddial params ----- > #!ifdef WITH_SPEEDDIAL > modparam("speeddial", "db_url", DBURL) > modparam("speeddial", "use_domain", MULTIDOMAIN) > #!endif > > > # ----- domain params ----- > #!ifdef WITH_MULTIDOMAIN > modparam("domain", "db_url", DBURL) > # register callback to match myself condition with domains list > modparam("domain", "register_myself", 1) > #!endif > > > #!ifdef WITH_PRESENCE > # ----- presence params ----- > modparam("presence", "db_url", DBURL) > > # ----- presence_xml params ----- > modparam("presence_xml", "db_url", DBURL) > modparam("presence_xml", "force_active", 1) > #!endif > > > #!ifdef WITH_NAT > # ----- rtpproxy params ----- > modparam("rtpproxy", "rtpproxy_sock", "udp:127.0.0.1:7722") > # ----- nathelper params ----- > modparam("nathelper", "natping_interval", 30) > modparam("nathelper", "ping_nated_only", 1) > modparam("nathelper", "sipping_bflag", FLB_NATSIPPING) > modparam("nathelper", "sipping_from", "sip:pinger@kamailio.org") > > # params needed for NAT traversal in other modules > modparam("nathelper|registrar", "received_avp", "$avp(RECEIVED)") > modparam("usrloc", "nat_bflag", FLB_NATB) > #!endif > > > #!ifdef WITH_TLS > # ----- tls params ----- > modparam("tls", "connection_timeout", 60) > modparam("tls", "tls_debug", 10) > modparam("tls", "config", "/usr/local/etc/kamailio/tls.cfg") > #modparam("tls", "verify_certificate", 1) > #modparam("tls", "require_certificate", 0) > #!endif > > #!ifdef WITH_ANTIFLOOD > # ----- pike params ----- > modparam("pike", "sampling_time_unit", 2) > modparam("pike", "reqs_density_per_unit", 16) > modparam("pike", "remove_latency", 4) > > # ----- htable params ----- > # ip ban htable with autoexpire after 5 minutes > modparam("htable", "htable", "ipban=>size=8;autoexpire=300;") > #!endif > > #!ifdef WITH_XMLRPC > # ----- xmlrpc params ----- > modparam("xmlrpc", "route", "XMLRPC"); > modparam("xmlrpc", "url_match", "^/RPC") > #!endif > > #!ifdef WITH_DEBUG > # ----- debugger params ----- > modparam("debugger", "cfgtrace", 1) > #!endif > > > #!ifdef WITH_WEBSOCKETS > # ----- nathelper params ----- > modparam("nathelper|registrar", "received_avp", "$avp(RECEIVED)") > # Note: leaving NAT pings turned off here as nathelper is _only_ being > used for > # WebSocket connections. NAT pings are not needed as WebSockets have > # their own keep-alives. > #!endif > > > > ####### Routing Logic ######## > > # Main SIP request routing logic > # - processing of any incoming SIP request starts with this route > # - note: this is the same as route { ... } > request_route { > > route(REQINIT); > > > #!ifdef WITH_SIPTRACE > if($hdr(X-Omnz-SipTrace) !=$null) > { > sip_trace(); > setflag(22); > } > #!endif > > > #!ifdef WITH_WEBSOCKETS > if (nat_uac_test(64)) { > # Do NAT traversal stuff for requests from a WebSocket > # connection - even if it is not behind a NAT! > # This won't be needed in the future if Kamailio and the > # WebSocket client support Outbound and Path. > force_rport(); > if (is_method("REGISTER")) > fix_nated_register(); > else { > if (!add_contact_alias()) { > xlog("L_ERR", "Error aliasing contact > <$ct>\n"); > sl_send_reply("400", "Bad Request"); > exit; > } > } > } > #!endif > > > # NAT detection > route(NATDETECT); > > # CANCEL processing > if (is_method("CANCEL")) > { > if (t_check_trans()) { > route(RELAY); > } > exit; > } > > # handle requests within SIP dialogs > route(WITHINDLG); > > ### only initial requests (no To tag) > > t_check_trans(); > > # authentication > route(AUTH); > > # record routing for dialog forming requests (in case they are > routed) > # - remove preloaded route headers > remove_hf("Route"); > if (is_method("INVITE|SUBSCRIBE")) > record_route(); > > # account only INVITEs > if (is_method("INVITE")) > { > setflag(FLT_ACC); # do accounting > } > > # dispatch requests to foreign domains > route(SIPOUT); > > ### requests for my local domains > > # handle presence related requests > route(PRESENCE); > > > # handle registrations > route(REGISTRAR); > > if ($rU==$null) > { > # request with no Username in RURI > sl_send_reply("484","Address Incomplete"); > exit; > } > > # dispatch destinations to PSTN > route(PSTN); > > # user location service > route(LOCATION); > } > > > route[RELAY] { > > # enable additional event routes for forwarded requests > # - serial forking, RTP relaying handling, a.s.o. > > > #!ifdef WITH_603 > if (is_method("INVITE")) { > if($hdr(X-Omz-int-Id) ==$null) > { > # request with no Username in RURI > sl_send_reply("603","Declined"); > exit; > } > } > #!endif > > > > if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) { > if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH"); > } > if (is_method("INVITE|SUBSCRIBE|UPDATE")) { > if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY"); > } > if (is_method("INVITE")) { > if(!t_is_set("failure_route")) > t_on_failure("MANAGE_FAILURE"); > } > > if (!t_relay()) { > sl_reply_error(); > } > exit; > } > > > # Per SIP request initial checks > route[REQINIT] { > #!ifdef WITH_ANTIFLOOD > # flood dection from same IP and traffic ban for a while > # be sure you exclude checking trusted peers, such as pstn gateways > # - local host excluded (e.g., loop to self) > if(src_ip!=myself) > { > if($sht(ipban=>$si)!=$null) > { > # ip is already blocked > xdbg("request from blocked IP - $rm from $fu > (IP:$si:$sp)\n"); > exit; > } > if (!pike_check_req()) > { > xlog("L_ALERT","ALERT: pike blocking $rm from $fu > (IP:$si:$sp)\n"); > $sht(ipban=>$si) = 1; > exit; > } > } > #!endif > > if (!mf_process_maxfwd_header("10")) { > sl_send_reply("483","Too Many Hops"); > exit; > } > > if(!sanity_check("1511", "7")) > { > xlog("Malformed SIP message from $si:$sp\n"); > exit; > } > } > > > # Handle requests within SIP dialogs > route[WITHINDLG] { > if (has_totag()) { > # sequential request withing a dialog should > # take the path determined by record-routing > if (loose_route()) { > > > #!ifdef WITH_WEBSOCKETS > if ($du == "") { > if (!handle_ruri_alias()) { > xlog("L_ERR", "Bad alias <$ru>\n"); > sl_send_reply("400", "Bad > Request"); > exit; > } > } > #!endif > > > > route(DLGURI); > if (is_method("BYE")) { > setflag(FLT_ACC); # do accounting ... > setflag(FLT_ACCFAILED); # ... even if the > transaction fails > } > else if ( is_method("ACK") ) { > # ACK is forwarded statelessy > route(NATMANAGE); > } > else if ( is_method("NOTIFY") ) { > # Add Record-Route for in-dialog NOTIFY as > per RFC 6665. > record_route(); > } > route(RELAY); > } else { > if (is_method("SUBSCRIBE") && uri == myself) { > # in-dialog subscribe requests > route(PRESENCE); > exit; > } > if ( is_method("ACK") ) { > if ( t_check_trans() ) { > # no loose-route, but stateful ACK; > # must be an ACK after a 487 > # or e.g. 404 from upstream server > route(RELAY); > exit; > } else { > # ACK without matching transaction > ... ignore and discard > exit; > } > } > sl_send_reply("404","Not here"); > } > exit; > } > } > > # Handle SIP registrations > route[REGISTRAR] { > if (is_method("REGISTER")) > { > if(isflagset(FLT_NATS)) > { > setbflag(FLB_NATB); > # uncomment next line to do SIP NAT pinging > ## setbflag(FLB_NATSIPPING); > } > if (!save("location")) > sl_reply_error(); > > exit; > } > } > > # USER location service > route[LOCATION] { > > #!ifdef WITH_SPEEDDIAL > # search for short dialing - 2-digit extension > if($rU=~"^[0-9][0-9]$") > if(sd_lookup("speed_dial")) > route(SIPOUT); > #!endif > > #!ifdef WITH_ALIASDB > # search in DB-based aliases > if(alias_db_lookup("dbaliases")) > route(SIPOUT); > #!endif > > $avp(oexten) = $rU; > if (!lookup("location")) { > $var(rc) = $rc; > route(TOVOICEMAIL); > t_newtran(); > switch ($var(rc)) { > case -1: > case -3: > send_reply("404", "Not Found"); > exit; > case -2: > send_reply("405", "Method Not Allowed"); > exit; > } > } > > # when routing via usrloc, log the missed calls also > if (is_method("INVITE")) > { > setflag(FLT_ACCMISSED); > } > > route(RELAY); > exit; > } > > # Presence server route > route[PRESENCE] { > if(!is_method("PUBLISH|SUBSCRIBE")) > return; > > #!ifdef WITH_PRESENCE > if (!t_newtran()) > { > sl_reply_error(); > exit; > }; > > if(is_method("PUBLISH")) > { > handle_publish(); > t_release(); > } > else > if( is_method("SUBSCRIBE")) > { > handle_subscribe(); > t_release(); > } > exit; > #!endif > > # if presence enabled, this part will not be executed > if (is_method("PUBLISH") || $rU==$null) > { > sl_send_reply("404", "Not here"); > exit; > } > return; > } > > # Authentication route > route[AUTH] { > #!ifdef WITH_AUTH > > #!ifdef WITH_IPAUTH > if((!is_method("REGISTER")) && allow_source_address()) > { > # source IP allowed > return; > } > #!endif > > if (is_method("REGISTER") || from_uri==myself) > { > # authenticate requests > if (!auth_check("$fd", "subscriber", "1")) { > auth_challenge("$fd", "0"); > exit; > } > # user authenticated - remove auth header > if(!is_method("REGISTER|PUBLISH")) > consume_credentials(); > } > # if caller is not local subscriber, then check if it calls > # a local destination, otherwise deny, not an open relay here > if (from_uri!=myself && uri!=myself) > { > sl_send_reply("403","Not relaying"); > exit; > } > > #!endif > return; > } > > # Caller NAT detection route > route[NATDETECT] { > #!ifdef WITH_NAT > force_rport(); > if (nat_uac_test("19")) { > if (is_method("REGISTER")) { > fix_nated_register(); > } else { > add_contact_alias(); > } > setflag(FLT_NATS); > } > #!endif > return; > } > > # RTPProxy control > route[NATMANAGE] { > #!ifdef WITH_NAT > if (is_request()) { > if(has_totag()) { > if(check_route_param("nat=yes")) { > setbflag(FLB_NATB); > } > } > } > if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) > return; > > rtpproxy_manage("co"); > > if (is_request()) { > if (!has_totag()) { > if(t_is_branch_route()) { > add_rr_param(";nat=yes"); > } > } > } > if (is_reply()) { > if(isbflagset(FLB_NATB)) { > add_contact_alias(); > } > } > #!endif > return; > } > > # URI update for dialog requests > route[DLGURI] { > #!ifdef WITH_NAT > if(!isdsturiset()) { > handle_ruri_alias(); > } > #!endif > return; > } > > # Routing to foreign domains > route[SIPOUT] { > if (!uri==myself) > { > append_hf("P-hint: outbound\r\n"); > route(RELAY); > } > } > > # PSTN GW routing > route[PSTN] { > #!ifdef WITH_PSTN > # check if PSTN GW IP is defined > if (strempty($sel(cfg_get.pstn.gw_ip))) { > xlog("SCRIPT: PSTN rotuing enabled but pstn.gw_ip not > defined\n"); > return; > } > > # route to PSTN dialed numbers starting with '+' or '00' > # (international format) > # - update the condition to match your dialing rules for PSTN > routing > if(!($rU=~"^(\+|00)[1-9][0-9]{3,20}$")) > return; > > # only local users allowed to call > if(from_uri!=myself) { > sl_send_reply("403", "Not Allowed"); > exit; > } > > if (strempty($sel(cfg_get.pstn.gw_port))) { > $ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip); > } else { > $ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip) + ":" > + $sel(cfg_get.pstn.gw_port); > } > > route(RELAY); > exit; > #!endif > > return; > } > > # XMLRPC routing > #!ifdef WITH_XMLRPC > route[XMLRPC] { > # allow XMLRPC from localhost > if ((method=="POST" || method=="GET") > && (src_ip==127.0.0.1)) { > # close connection only for xmlrpclib user agents (there > is a bug in > # xmlrpclib: it waits for EOF before interpreting the > response). > if ($hdr(User-Agent) =~ "xmlrpclib") > set_reply_close(); > set_reply_no_connect(); > dispatch_rpc(); > exit; > } > send_reply("403", "Forbidden"); > exit; > } > #!endif > > # route to voicemail server > route[TOVOICEMAIL] { > #!ifdef WITH_VOICEMAIL > if(!is_method("INVITE")) > return; > > # check if VoiceMail server IP is defined > if (strempty($sel(cfg_get.voicemail.srv_ip))) { > xlog("SCRIPT: VoiceMail rotuing enabled but IP not > defined\n"); > return; > } > if($avp(oexten)==$null) > return; > > $ru = "sip:" + $avp(oexten) + "@" + $sel(cfg_get.voicemail.srv_ip) > + ":" + $sel(cfg_get.voicemail.srv_port); > route(RELAY); > exit; > #!endif > > return; > } > > # manage outgoing branches > branch_route[MANAGE_BRANCH] { > xdbg("new branch [$T_branch_idx] to $ru\n"); > route(NATMANAGE); > } > > # manage incoming replies > onreply_route[MANAGE_REPLY] { > xdbg("incoming reply\n"); > if(status=~"[12][0-9][0-9]") > route(NATMANAGE); > } > > # manage failure routing cases > failure_route[MANAGE_FAILURE] { > route(NATMANAGE); > > if (t_is_canceled()) { > exit; > } > > #!ifdef WITH_BLOCK3XX > # block call redirect based on 3xx replies. > if (t_check_status("3[0-9][0-9]")) { > t_reply("404","Not found"); > exit; > } > #!endif > > #!ifdef WITH_VOICEMAIL > # serial forking > # - route to voicemail on busy or no answer (timeout) > if (t_check_status("486|408")) { > $du = $null; > route(TOVOICEMAIL); > exit; > } > #!endif > } > > > #!ifdef WITH_WEBSOCKETS > onreply_route { > if (nat_uac_test(64)) { > # Do NAT traversal stuff for replies to a WebSocket > connection > # - even if it is not behind a NAT! > # This won't be needed in the future if Kamailio and the > # WebSocket client support Outbound and Path. > add_contact_alias(); > } > } > > event_route[xhttp:request] { > set_reply_close(); > set_reply_no_connect(); > > if ($Rp != MY_WS_PORT > > #!ifdef WITH_TLS > && $Rp != MY_WSS_PORT > #!endif > > ) { > xlog("L_WARN", "HTTP request received on $Rp\n"); > xhttp_reply("403", "Forbidden", "", ""); > exit; > } > > xlog("L_DBG", "HTTP Request Received\n"); > > if ($hdr(Upgrade)=~"websocket" > && $hdr(Connection)=~"Upgrade" > && $rm=~"GET") { > xlog("L_DBG", "WebSocket\n"); > xlog("L_DBG", " Host: $hdr(Host)\n"); > xlog("L_DBG", " Origin: $hdr(Origin)\n"); > > if ($hdr(Host) == $null ) { > xlog("L_WARN", "Bad host $hdr(Host)\n"); > xhttp_reply("403", "Forbidden", "", ""); > exit; > } > > # Optional... validate Origin > # Optional... perform HTTP authentication > > # ws_handle_handshake() exits (no further configuration > file > # processing of the request) when complete. > if (ws_handle_handshake()) > { > # Optional... cache some information abou the > # successful connection > exit; > } > } > > xhttp_reply("404", "Not found", "", ""); > } > > event_route[websocket:closed] { > xlog("L_INFO", "WebSocket connection from $si:$sp has closed\n"); > } > #!endif > > > >

2 1

Re: [SR-Users] Welcome to the "Users" mailing list
by John Jhj 13 Apr '15

13 Apr '15

Hello, We have setup Kamailio SIP Server v4.1.7 at latest our Rackspace server (ubuntu 14.10) Chat works fine on all cases and calls are working for Local network only( I think its when it doesn't uses rtpproxy). Over Internet( on real ips rather than local one), we are able to make calls(audio/video) and we can see that Our packets are being transmitted properly to the server, but we are unable to get those packets to client side back from the server. So, Client-to-Server : works but, Server-to-Client : it doesn't works FYI, We have confirmed that firewalll is inactive on our server and required ports are open. We have tried with and without tls (self signed certificates only). The SIP client we used to test the environment is JITSI. We are getting following error : Apr 10 10:46:39 telezang-app /usr/local/sbin/kamailio[25670]: ERROR: rtpproxy [rtpproxy.c:1756]: select_rtpp_node(): script error -no valid set selected Apr 10 10:46:39 telezang-app /usr/local/sbin/kamailio[25670]: ERROR: rtpproxy [rtpproxy.c:2636]: force_rtp_proxy(): no available proxies Apr 10 10:46:44 telezang-app /usr/local/sbin/kamailio[25641]: ERROR: rtpproxy [rtpproxy.c:1756]: select_rtpp_node(): script error -no valid set selected Apr 10 10:46:44 telezang-app /usr/local/sbin/kamailio[25641]: ERROR: rtpproxy [rtpproxy.c:2636]: force_rtp_proxy(): no available proxies Apr 10 10:46:44 telezang-app /usr/local/sbin/kamailio[25641]: NOTICE: acc [acc.c:315]: acc_log_request(): ACC: transaction answered: timestamp=1428662804;method=INVITE;from_tag=978a791a;to_tag=3458055147;call_id=6c08683633dd586d0e634f5e2bbfa99c@0 :0:0:0:0:0:0:0;code=200;reason=OK;src_user=user1;src_domain= mobileappplatform.com ;src_ip=202.157.76.21;dst_ouser=user4;dst_user=user4;dst_domain=192.168.5.115 Apr 10 10:46:44 telezang-app /usr/local/sbin/kamailio[25643]: ERROR: rtpproxy [rtpproxy.c:1756]: select_rtpp_node(): script error -no valid set selected Apr 10 10:46:44 telezang-app /usr/local/sbin/kamailio[25643]: ERROR: rtpproxy [rtpproxy.c:2636]: force_rtp_proxy(): no available proxies Apr 10 10:46:48 telezang-app /usr/local/sbin/kamailio[25670]: ERROR: rtpproxy [rtpproxy.c:1756]: select_rtpp_node(): script error -no valid set selected Apr 10 10:46:48 telezang-app /usr/local/sbin/kamailio[25670]: ERROR: rtpproxy [rtpproxy.c:1960]: unforce_rtp_proxy(): no available proxies Apr 10 10:46:49 telezang-app /usr/local/sbin/kamailio[25644]: NOTICE: acc [acc.c:315]: acc_log_request(): ACC: transaction answered: timestamp=1428662809;method=BYE;from_tag=978a791a;to_tag=3458055147;call_id=6c08683633dd586d0e634f5e2bbfa99c@0 :0:0:0:0:0:0:0;code=200;reason=OK;src_user=user1;src_domain= mobileappplatform.com ;src_ip=202.157.76.21;dst_ouser=user4;dst_user=user4;dst_domain=202.157.76.21 Thanks On Fri, Apr 10, 2015 at 4:38 PM, <users-request(a)lists.opensips.org> wrote: > Welcome to the Users(a)lists.opensips.org mailing list! > > To post to this list, send your email to: > > users(a)lists.opensips.org > > General information about the mailing list is at: > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > If you ever want to unsubscribe or change your options (eg, switch to > or from digest mode, change your password, etc.), visit your > subscription page at: > > > http://lists.opensips.org/cgi-bin/mailman/options/users/followtest111%40gma… > > > You can also make such adjustments via email by sending a message to: > > Users-request(a)lists.opensips.org > > with the word `help' in the subject or body (don't include the > quotes), and you will get back a message with instructions. > > You must know your password to change your options (including changing > the password, itself) or to unsubscribe. It is: > > 123456 > > Normally, Mailman will remind you of your lists.opensips.org mailing > list passwords once every month, although you can disable this if you > prefer. This reminder will also include instructions on how to > unsubscribe or change your account options. There is also a button on > your options page that will email your current password to you. >

2 1

TLS & log files
by Tributh 13 Apr '15

13 Apr '15

Hi, is there any way to configure the tls curve like secp384r1 in the config? I use actually version 4.2.4 On the other side i can't see any connection Information in the logs. I would like to see something like: "Connected with TLSv1.1 using cipher ECDHE-RSA-AES256-GCM-SHA384 and curve secp384r1" With this logs the variety of the offered ciphers can be shortened to the most secure and only needed by the clients. Regard T.Tributh

2 1

Kamailio LDAP authentication
by Marek Moravcik 11 Apr '15

11 Apr '15

Hello, I'd like to authenticate Kamailio users in LDAP. But it looks like Kamailio need to download password from LDAP and authenticate user on it's own. Is there any possibility to send password to LDAP and let LDAP to say, if the user can be sign in? Thanks Marek Moravčík

2 1

In acc for 5xx calls result in "Unknown column 'time_attr' in 'field list'"
by Ethan Brooks 10 Apr '15

10 Apr '15

I am seeing a very strange error saying that time_attr is an unknown column and the insert is failing. What is strange is that it is in the acc table and is being populated for all successful calls. It seem to only happen for 5xx unsuccessful calls and the INVITE is not recorded. 4xx response are recorded. *config* modparam("acc", "time_mode", 1); modparam("acc", "failed_transaction_flag", 3) *syslog* Apr 9 20:40:52 a-deploy-callprocessing3 /usr/sbin/kamailio[9732]: ERROR: db_mysql [km_dbase.c:123]: db_mysql_submit_query(): driver error on query: Unknown column 'time_attr' in 'field list' Apr 9 20:40:52 a-deploy-callprocessing3 /usr/sbin/kamailio[9732]: ERROR: <core> [db_query.c:235]: db_do_insert_cmd(): error while submitting query Apr 9 20:40:52 a-deploy-callprocessing3 /usr/sbin/kamailio[9732]: ERROR: acc [acc.c:504]: acc_db_request(): failed to insert into database *Database Fields:* `time_attr` int(11) DEFAULT NULL, `time_exten` int(11) DEFAULT NULL, *kamailio -v* version: kamailio 4.2.3 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, DBG_F_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled on 12:08:27 Feb 16 2015 with gcc 4.9.1

2 2

weight of rtpengine rtp proxy?
by Juha Heinanen 10 Apr '15

10 Apr '15

rtpengine readme tells in section 2: The balancing inside a set is done automatically by the module based on the weight of each RTP proxy from the set. i have not found in rtpengine_sock module parameter description, how is the weight of a rtp proxy is specified specified. it contains an example: modparam("rtpengine", "rtpengine_sock", "1 == udp:localhost:12221 udp:localhost:12222") how can i tell what the weight of each of two proxies is? -- juha

3 4

Re: [SR-Users] fifo error and kamailio wont start
by Bruno Emer 10 Apr '15

10 Apr '15

Ok Joli! Here is the way I do this. At the begining of your kamailio.cfg, just after "#!KAMAILIO" insert this define: #!define WITH_DEBUG In your global parameters, you must now define what happens if "WITH_DEBUG" is configurated, so add these lines: #!ifdef WITH_DEBUG debug=4 log_stderror=yes #!else debug=2 log_stderror=no #!endif On Modules Selection, load the module debbuger.so: #!ifdef WITH_DEBUG loadmodule "debugger.so" #!endif And set the module specific parameters: #!ifdef WITH_DEBUG # ----- debugger params ----- modparam("debugger", "cfgtrace", 1) #!endif Maybe some of these informations can be there, but I am not sure about the default configuration file. After these changes, restart your kamailio and you should see a lot of information in your screen. Then, just try to find the error there. I just asked something here in this forum as well, and posted my .cfg file there. If you want to check the places where I put these lines, take a look at the topic "MULTIDOMAIN Environment". After discover the error and finish your troubleshooting, you can just comment the line #!define WITH_DEBUG putting one more # at the beginning of it and you will not see the debug information anymore. *Bruno Emer*

1 0

Re: [SR-Users] fifo error and kamailio wont start
by Bruno Emer 10 Apr '15

10 Apr '15

Hello Joli! To see what is going on, is a good idea to set debug=4 so you can see exactly what is going on. If you don't know how to do this, please let me know and I can try to help you. Bruno Emer

2 1

fifo error and kamailio wont start
by Joli Martinez 10 Apr '15

10 Apr '15

Hello, I am installing the latest version of Kamailio on CentOS 7 from Git. Everything compiled correctly, but when I try to start it I am getting a fifo error and Kamailio wont start [error] kamailio: : <core> [cfg.y:3428]: yyerror_at(): parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 296, column 39: Can't initialize shared memory kamailio: ERROR: mi_fifo [mi_fifo.c:271]: mi_destroy(): FIFO stat failed: Bad address kamailio: Starting kamailio: kamailio.service: control process exited, code=exited status=1 systemd: Failed to start LSB: Kamailio (OpenSER) - the Open Source SIP Server. systemd: Unit kamailio.service entered failed state. [/error] any suggestions on how to fix this?

2 2

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