sr-users

sr-users@lists.kamailio.org

9 participants
37568 discussions

Name of pseudo variable by which domain name is saved in Location List
by aawaise 29 Apr '14

29 Apr '14

Hello, I want to display the value from domain field of Location List in SER Monitor Menu. I extracted the value of $rd using xlog. It gave me the domain of callee but from invite packet. Not from the location list of SER Monitor Menu. If callee is logged in to same database with another kamailio server and hence another domain name. How can I pick domain name by which its logged in Thanks. Regards, Aawaise -- View this message in context: http://sip-router.1086192.n5.nabble.com/Name-of-pseudo-variable-by-which-do… Sent from the Users mailing list archive at Nabble.com.

2 5

drouting/LCR/dispatcher
by Keith 29 Apr '14

29 Apr '14

Hi all, I am having trouble deciding which one of these is best. I was going to start to use drouting but that doesn't seem to give me the probe efficiency of dispatcher. However I need to control calls based on destinations to different voice carriers. I'm looking for a combination of them to enable me to get the functionality required. Any ideas/pointers? Thanks Keith

2 1

OT: Excessive or fatal bounces for yahoo, hotmail, ...
by Daniel-Constantin Mierla 29 Apr '14

29 Apr '14

Hello, this morning were reported over 100 "excessive or fatal bounces" for delivery from mailing list to yahoo, hotmail/live (and few other that might be hosted) email addresses. This is unusual high and I spotted several addresses that were active recently and unlikely to have their email address gone. Is anyone here aware of similar issues and potential fixes? I guess yahoo/hotmail servers simply reject the emails sent by mailman of mailing lists. Any hint would be appreciated... Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

4 5

Can Kamailio connect WebSocket user with SIP user?
by Patrik Kristel 29 Apr '14

29 Apr '14

Hello, I would like to ask, whether Kamailio does connect WebSocket user with SIP user. Because, I'm trying to do it regarding this code: http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob_plain;f=ex… and when i'using X-lite i've got 1, Trying 2, 415 Unsupported Media Type and at Blink client I've got: 1, Trying 2, 488 Not Acceptable Here as WebSocket client i'm using JsSIP. Do you think I need to use media server(like Asterisk) to connect it? Thank you for help! Patrik

1 0

Re: [SR-Users] Drouting
by Keith 29 Apr '14

29 Apr '14

Hi all, So I moved away from LCR and dispatcher to use drouting but I can't see how to use probing. In OpenSIPS I can see this is built into the module but it's not in Kamailio. Any ideas how I can get round this? I want to use drouting for all my routing needs. Cheers Keith

2 1

Kamailio and Free switch - multi tenant
by Chirag Desai 29 Apr '14

29 Apr '14

Hi all, First time poster here. I had a freeswitch installation configured to allow users to register with different domains e.g. tenant1.mydomain.com tenant2.mydomain.com .. tenantN.my domain.com This worked fine. Users were able to call extensions in their own domain and access their voicemail. All tenants/domains shared the same diaplan (default). I followed the great tutorial at http://kb.asipto.com/freeswitch:kamailio-3.3.x-freeswitch-1.2.x-sbc I now have my users (using different domains as above) registering to Kamailio. It was a little tricky but I can now place calls between users on the same domain. For some reason the variable ${domain_name} (from the tutorial) seems to be empty so I had to replace it with a channel variable (I'm not in front of my dialplan now but it was something like ${sip_from_domain}. Was this the right thing to do? Why does the domain_name variable not populate with the domain of the user making the call? Another issue I have is to do with usernames. I want my users to have alphanumeric usernames e.g. user1(a)tenant1.example.com user2(a)tenant1.example.com But I'd also like them to be able to have an associated extension and mailbox. E.g. user1 may be extension 1001 and mailbox 1001 user2 may be extension 1002 and mailbox 1002. In Kamailio I've handled this by using aliasdb. So user1.tenant1.example.com has an alias of 1001.tenant1.example.com Scenario: User2 dials 1001. Kamailio evaluates this and determines we want user1. It passes the call to FS with a $rU of user1. However, even though user1 is registered and online...the call fails and diverts to voicemail - any ideas? Also I had to hack the above so that after the alias db lookup Kamailio sends an $rU of 1001@tenant1... If anyone has got FS and Kamailio running with multiple domains I would really love some feedback on routing and dialplan configuration. Thanks so much in advance, CD

1 0

kamctl not connect to dbserver
by Юрий Горличенко 28 Apr '14

28 Apr '14

Hello. I started configure Kamailio 3.3 server with mysql database, that running on the remote server. I customise settings at kamailio.cfg (for BDURL) and kamctlc file (for my db - changed user, password, dbhost and other settings, such as dbengine and etc.) Now, when I tried add new subscriber from kamctl util (kamctl add newuser@kamailioIP passwd). I see "access denied for <myuser>@<interface of kamailio server>", But as I aleady says I configured filew with other settings for db server. Where I must configure ip of dbhost to connect kamctl to my dbserver?

2 1

Dispatcher marks TLS destinations as Inactive when present in more than one set
by Giacomo Vacca 28 Apr '14

28 Apr '14

Hi all, I'm seeing a strange behaviour with dispatcher in these conditions: 1. A destination requires TLS (e.g. sips:10.0.0.1:5061) 2. The destination has flags 8 (i.e. in normal conditions we want AP, Active Probing) and dispatcher uses ds_probing_mode 1 (always probe) 3. The destination is present in more than one set The behaviour is that the destination is marked as IP (Inactive Probing) in the set with a lower set number. In other words at startup (or dispatcher reload): SET_NO:: 2 SET:: 2 URI:: sips:10.0.0.1:5061 flags=AP priority=0 attrs= SET:: 1 URI:: sips:10.0.0.1:5061 flags=AP priority=0 attrs= After some time (about 30", see below): SET_NO:: 2 SET:: 2 URI:: sips:10.0.0.1:5061 flags=AP priority=0 attrs= SET:: 1 URI:: sips:10.0.0.1:5061 flags=IP priority=0 attrs= So the same destination is marked as AP and IP at the same time. I've reproduced this with a brand new installation (4.1.3 on debian wheezy), but seen with 3.2.3 and 4.0.4 as well. debian wheezy VM (Linux debian7 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux) I can see (with either ssldump or asterisk's 'sip set debug on') the first OPTIONS/404 (related to set #2), but not the second (related to set #1). I haven't seen (with tcpdump) the attempt to create a second connection to the destination (which makes me think that it either fails or kamailio attempts to re-use the existing one). Probing for set #1 appears to time out (i.e. after 30" the response is considered a 408). It happens with either Asterisk or FreeSWITCH as servers. Extract from tls.cfg: [client:default] verify_certificate = no require_certificate = no Dispatcher configuration: loadmodule "dispatcher.so" [...] # ----- dispatcher params ----- modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.cfg") modparam("dispatcher", "ds_ping_reply_codes", "class=2;code=404") modparam("dispatcher", "ds_probing_mode", 1) modparam("dispatcher", "ds_ping_interval", 30) /etc/kamailio/dispatcher.cfg: 1 sips:10.0.0.1:5061 8 0 2 sips:10.0.0.1:5061 8 0 (I'm using 10.0.0.1 here for simplification only; the real IP address has been omitted). Server (Asterisk or FreeSWITCH) certs are self-signed. Relevant logs (level 4): Apr 24 15:54:19 debian7 /usr/sbin/kamailio[11169]: DEBUG: dispatcher [dispatch.c:2453]: ds_check_timer(): probing set #2, URI sips:10.0.0.1:5061 Apr 24 15:54:19 debian7 /usr/sbin/kamailio[11169]: DEBUG: tm [uac.c:243]: t_uac_prepare(): DEBUG:tm:t_uac: next_hop=<sips:10.0.0.1:5061> Apr 24 15:54:19 debian7 /usr/sbin/kamailio[11169]: DEBUG: tm [uac.c:182]: dlg2hash(): DEBUG: dlg2hash: 49688 Apr 24 15:54:19 debian7 /usr/sbin/kamailio[11169]: DEBUG: <core> [tcp_main.c:1849]: tcp_send(): tcp_send: no open tcp connection found, opening new one Apr 24 15:54:19 debian7 /usr/sbin/kamailio[11169]: DEBUG: <core> [ip_addr.c:243]: print_ip(): tcpconn_new: new tcp connection: 10.0.0.1 Apr 24 15:54:19 debian7 /usr/sbin/kamailio[11169]: DEBUG: <core> [tcp_main.c:1096]: tcpconn_new(): tcpconn_new: on port 5061, type 3 Apr 24 15:54:19 debian7 /usr/sbin/kamailio[11169]: DEBUG: <core> [tcp_main.c:1408]: tcpconn_add(): tcpconn_add: hashes: 1217:0:0, 1 Apr 24 15:54:19 debian7 /usr/sbin/kamailio[11169]: DEBUG: tls [tls_server.c:178]: tls_complete_init(): Using TLS domain TLSc<default> Apr 24 15:54:19 debian7 /usr/sbin/kamailio[11169]: DEBUG: tls [tls_domain.c:700]: sr_ssl_ctx_info_callback(): SSL handshake started Apr 24 15:54:19 debian7 /usr/sbin/kamailio[11169]: DEBUG: <core> [tcp_main.c:2737]: tcpconn_1st_send(): pending write on new connection 0x7fd4813cdb70 (-1/225 bytes written) Apr 24 15:54:19 debian7 /usr/sbin/kamailio[11177]: DEBUG: <core> [tcp_main.c:3624]: handle_ser_child(): handle_ser_child: read response= 7fd4813cdb70, 5, fd 32 from 9 (11169) Apr 24 15:54:19 debian7 /usr/sbin/kamailio[11177]: DEBUG: <core> [io_wait.h:390]: io_watch_add(): DBG: io_watch_add(0x89dc40, 32, 2, 0x7fd4813cdb70), fd_no=24 Apr 24 15:54:19 debian7 /usr/sbin/kamailio[11169]: DEBUG: dispatcher [dispatch.c:2453]: ds_check_timer(): probing set #1, URI sips:10.0.0.1:5061 Apr 24 15:54:19 debian7 /usr/sbin/kamailio[11169]: DEBUG: tm [uac.c:243]: t_uac_prepare(): DEBUG:tm:t_uac: next_hop=<sips:10.0.0.1:5061> Apr 24 15:54:19 debian7 /usr/sbin/kamailio[11169]: DEBUG: tm [uac.c:182]: dlg2hash(): DEBUG: dlg2hash: 49689 Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11177]: DEBUG: <core> [io_wait.h:796]: io_watch_chg(): DBG: io_watch_chg (0x89dc40, 32, 0x1, 0xffffffff) fd_no=25 called Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11177]: DEBUG: <core> [io_wait.h:617]: io_watch_del(): DBG: io_watch_del (0x89dc40, 32, -1, 0x0) fd_no=25 called Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11177]: DEBUG: <core> [tcp_main.c:4302]: handle_tcpconn_ev(): tcp: DBG: sending to child, events 1 Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11177]: DEBUG: <core> [tcp_main.c:3973]: send2child(): selected tcp worker 0 13(11173) for activity on [tls:192.168.142.170:5061], 0x7fd4813cdb70 Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [tcp_read.c:1510]: handle_io(): received n=8 con=0x7fd4813cdb70, fd=7 Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [io_wait.h:390]: io_watch_add(): DBG: io_watch_add(0x8e2040, 7, 2, 0x7fd4813cdb70), fd_no=1 Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [tcp_main.c:2556]: tcpconn_do_send(): tcp_send: sending... Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [tcp_main.c:2590]: tcpconn_do_send(): tcp_send: after real write: c= 0x7fd4813cdb70 n=198 fd=7 Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [tcp_main.c:2591]: tcpconn_do_send(): tcp_send: buf=#012#026#003#001 Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: tls [tls_domain.c:712]: sr_ssl_ctx_info_callback(): SSL handshake done Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: tls [tls_domain.c:715]: sr_ssl_ctx_info_callback(): SSL disable renegotiation Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: tls [tls_server.c:413]: tls_connect(): TLS connect successful Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: tls [tls_server.c:420]: tls_connect(): tls_connect: new connection to 10.0.0.1:5061 using TLSv1/SSLv3 AES256-SHA 256 Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: tls [tls_server.c:423]: tls_connect(): tls_connect: sending socket: 192.168.142.170:43914 Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: tls [tls_server.c:305]: tls_dump_cert_info(): tls_connect: server certificate subject:/CN=REMOVED/O=REMOVED Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: tls [tls_server.c:309]: tls_dump_cert_info(): tls_connect: server certificate issuer:/CN=REMOVED/O=REMOVED Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: tls [tls_server.c:429]: tls_connect(): WARNING: tls_connect: server certificate verification failed!!! Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: tls [tls_dump_vf.c:105]: tls_dump_verification_failure(): verification failure: self signed certificate in certificate chain Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [tcp_main.c:2556]: tcpconn_do_send(): tcp_send: sending... Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [tcp_main.c:2590]: tcpconn_do_send(): tcp_send: after real write: c= 0x7fd4813cdb70 n=805 fd=7 Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [tcp_main.c:2591]: tcpconn_do_send(): tcp_send: buf=[...REMOVED...] Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [tcp_read.c:1317]: tcp_read_req(): tcp_read_req: content-length= 0 Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [parser/msg_parser.c:633]: parse_msg(): SIP Reply (status): Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [parser/msg_parser.c:635]: parse_msg(): version: <SIP/2.0> Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [parser/msg_parser.c:637]: parse_msg(): status: <404> Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [parser/msg_parser.c:639]: parse_msg(): reason: <Not Found> Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK812c.b064d3e3000000000000000000000000.0>; state=6 Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 234, <received> = <REMOVED>; state=6 Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 235, <rport> = <59525>; state=16 Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of header reached, state=5 Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via found, flags=2 Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [parser/msg_parser.c:515]: parse_headers(): parse_headers: this is the first via Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [receive.c:152]: receive_msg(): After parse_msg... Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: tm [t_lookup.c:1072]: t_check_msg(): DEBUG: t_check_msg: msg id=1 global id=0 T start=0xffffffffffffffff Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG: add_param: tag=as232959d2 Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [parser/parse_addr_spec.c:893]: parse_addr_spec(): end of header reached, state=29 Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [parser/msg_parser.c:190]: get_hdr_field(): DEBUG: get_hdr_field: <To> [43]; uri=[sips:10.0.0.1:5061] Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body [<sips:10.0.0.1:5061>] Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <10> <OPTIONS> Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: tm [t_lookup.c:949]: t_reply_matching(): DEBUG: t_reply_matching: hash 49688 label 0 branch 0 Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: tm [t_lookup.c:1004]: t_reply_matching(): DEBUG: t_reply_matching: reply matched (T=0x7fd4813cc530)! Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: tm [t_lookup.c:1141]: t_check_msg(): DEBUG: t_check_msg: msg id=1 global id=1 T end=0x7fd4813cc530 Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: tm [t_reply.c:2206]: reply_received(): DEBUG: reply_received: org. status uas=0, uac[0]=0 local=2 is_invite=0) Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: tm [t_reply.c:1304]: t_should_relay_response(): ->>>>>>>>> T_code=0, new_code=404 Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: tm [t_reply.c:2086]: local_reply(): DEBUG: local_reply: branch=0, save=0, winner=0 Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: tm [t_reply.c:2123]: local_reply(): DEBUG: local transaction completed Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: tm [t_hooks.c:288]: run_trans_callbacks_internal(): DBG: trans=0x7fd4813cc530, callback type 1024, id 0 entered Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: dispatcher [dispatch.c:2392]: ds_options_callback(): OPTIONS-Request was finished with code 404 (to sips:10.0.0.1:5061, group 2) Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: tm [t_reply.c:1663]: cleanup_uac_timers(): DEBUG: cleanup_uac_timers: RETR/FR timers reset Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [xavp.c:448]: xavp_destroy_list(): destroying xavp list (nil) Apr 24 15:54:20 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [receive.c:296]: receive_msg(): receive_msg: cleaning up Apr 24 15:54:26 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [io_wait.h:617]: io_watch_del(): DBG: io_watch_del (0x8e2040, 7, -1, 0x10) fd_no=2 called Apr 24 15:54:26 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [tcp_read.c:1437]: release_tcpconn(): releasing con 0x7fd4813cdb70, state 1, fd=7, id=1 Apr 24 15:54:26 debian7 /usr/sbin/kamailio[11173]: DEBUG: <core> [tcp_read.c:1438]: release_tcpconn(): extra_data 0x7fd4813b51f0 Apr 24 15:54:26 debian7 /usr/sbin/kamailio[11177]: DEBUG: <core> [tcp_main.c:3385]: handle_tcp_child(): handle_tcp_child: reader response= 7fd4813cdb70, 1 from 0 Apr 24 15:54:26 debian7 /usr/sbin/kamailio[11177]: DEBUG: <core> [io_wait.h:390]: io_watch_add(): DBG: io_watch_add(0x89dc40, 32, 2, 0x7fd4813cdb70), fd_no=24 Apr 24 15:54:26 debian7 /usr/sbin/kamailio[11177]: DEBUG: <core> [tcp_main.c:3515]: handle_tcp_child(): handle_tcp_child: CONN_RELEASE 0x7fd4813cdb70 refcnt= 1 Apr 24 15:54:49 debian7 /usr/sbin/kamailio[11169]: DEBUG: tm [t_reply.c:1304]: t_should_relay_response(): ->>>>>>>>> T_code=0, new_code=408 Apr 24 15:54:49 debian7 /usr/sbin/kamailio[11169]: DEBUG: tm [t_reply.c:2086]: local_reply(): DEBUG: local_reply: branch=0, save=0, winner=0 Apr 24 15:54:49 debian7 /usr/sbin/kamailio[11169]: DEBUG: tm [t_reply.c:2123]: local_reply(): DEBUG: local transaction completed Apr 24 15:54:49 debian7 /usr/sbin/kamailio[11169]: DEBUG: tm [t_hooks.c:288]: run_trans_callbacks_internal(): DBG: trans=0x7fd4813e5890, callback type 1024, id 0 entered Apr 24 15:54:49 debian7 /usr/sbin/kamailio[11169]: DEBUG: dispatcher [dispatch.c:2392]: ds_options_callback(): OPTIONS-Request was finished with code 408 (to sips:10.0.0.1:5061, group 1) Probing set #2 goes OK. Probing set #1: starts probing at 15:54:19, and times out 30" later at 15:54:49. Is this a bug, a misconfiguration, or perhaps a wrong way to manage dispatcher sets using TLS? Additional question: Is it not expected that a persistent TLS connection is established with a 'sips' dispatcher destination? Thanks in advance for the time to read through all this! Giacomo Truphone Limited, registered in England and Wales (registered company number: 04187081). Registered office: CityPoint, One Ropemaker Street, London EC2Y 9SS. VAT No. GB 851 5278 19 This e-mail, and any attachment(s), may contain information which is confidential and/or privileged, and is intended for the addressee only. If you are not the intended recipient, you may not use, disclose, copy or distribute this information in any manner whatsoever. If you have received this e-mail in error, please contact the sender immediately and delete it.

2 2

Early dialog
by Ivan Baques Garcia 28 Apr '14

28 Apr '14

Hi, I'm using modparam("dialog", "db_mode", 1), but only confirmed dialogs are shown in the database. How I can enable to show unconfirmed dialogs in the database? Now are only in-memory. Best regards

3 2

Large Content-Length crash with instant message
by Roberto Fichera 28 Apr '14

28 Apr '14

Hi All, I'm playing with instant messaging with a PJSIP client, but as soon as I send body with payload to about 100k I'm getting the error below: Apr 28 09:16:52 ip-10-227-0-26 /usr/sbin/kamailio[2909]: ERROR: <core> [tcp_main.c:715]: _wbufq_add(): ERROR: wbufq_add(40552 bytes): write queue full or timeout (0, total 0, last write 51946505 s ago) Apr 28 09:16:52 ip-10-227-0-26 /usr/sbin/kamailio[2909]: ERROR: tm [../../forward.h:240]: msg_send(): msg_send: ERROR: tcp_send failed Apr 28 09:16:52 ip-10-227-0-26 /usr/sbin/kamailio[2910]: ERROR: <core> [tcp_main.c:3638]: handle_ser_child(): handle_ser_child: ERROR: received CON_ERROR for 0xb30ddcd8 (id 352), refcnt 2, flags 0x5092 Apr 28 09:16:52 ip-10-227-0-26 /usr/sbin/kamailio[2909]: ERROR: tm [t_fwd.c:1609]: t_send_branch(): ERROR: t_send_branch: sending request on branch 0 failed Apr 28 09:16:52 ip-10-227-0-26 /usr/sbin/kamailio[2909]: ERROR: sl [sl_funcs.c:387]: sl_reply_error(): ERROR: sl_reply_error used: Unfortunately error on sending to next hop occurred (477/SL) And the app get SIP/2.0 477 Unfortunately error on sending to next hop occurred (477/SL) Via: SIP/2.0/TLS XX.XX.XX.XX:55859;rport=55859;branch=z9hG4bKPjkkazEy.XcjJkYDCEzwbwUVAONDzcCN8t;alias From: <sip:aaaaa@test.net>;tag=9gcb.Ay3wSCZNFgs8PNCbdkRq7jfxbDx To: <sip:bbbbb@test.net>;tag=9a285338e10af1c086406d08dc7f5d79.e457 Call-ID: v9JlsK1AEH4So8AIEfqiGuUOEx5Fub1C CSeq: 28450 MESSAGE Server: kamailio (4.1.3 (i386/linux)) Content-Length: 0 --end msg-- Kamailio is already set with tcp_rd_buf_size=204800 Does anyone can suggest how to fix this? Thanks in advance, Roberto Fichera.

2 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users