sr-users February 2016

sr-users@lists.kamailio.org

80 participants
133 discussions

rare impossibility to send requests to TLS connected peer
by Vasiliy Ganchev 09 Mar '16

09 Mar '16

Hi folk! Have a rare issue with tls connections. Have a server with 100+ active tls connections, that are connected to separate TCP proxy, that listen on port 443. TCP proxy send sip traffic to Kamailio via localhost:5061. In this way all connections in Kamailio are considered from Localhost. Issue scheme: - UA-A (sip-phone, UDP/TCP/TLS) -> call -> sip server (Kamailio+Asterisk based) -> UA-B (sip phone, transport=TLS) - The troubles happened in part of flow to UA-B: --- kamailio script make lookup(location), find AOR for UA-B (here is OK) --- after t_relay, kamailio make branch_route logic and try to send INVITE to tcp socket --- HERE IS the trouble: connection seems to be opened, but Kamailio cannot send INVITE there (say: no open tcp connection found) --- Kamailio try to open tcp connection from itself, TCP proxy refuse it --- as a result - Kamailio answer 477 to Asterisk, and finish processing debug level 3 logs (from the point where Kamailio try to send INVITE in opened connection) Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:1463]: _tcpconn_find(): tcpconn_find: 0 port 60286 Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [ip_addr.c:243]: print_ip(): tcpconn_find: ip 127.0.0.1 Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:1820]: tcp_send(): tcp_send: no open tcp connection found, opening new one Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [ip_addr.c:243]: print_ip(): tcpconn_new: new tcp connection: 127.0.0.1 Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:1073]: tcpconn_new(): tcpconn_new: on port 60286, type 3 Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:1626]: _tcpconn_add_alias_unsafe(): _tcpconn_add_alias_unsafe: alias port 60286 for hash 2646, id 404319 Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:1626]: _tcpconn_add_alias_unsafe(): _tcpconn_add_alias_unsafe: alias port 60286 for hash 2728, id 404319 Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:1624]: _tcpconn_add_alias_unsafe(): _tcpconn_add_alias_unsafe: alias already present Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:1382]: tcpconn_add(): tcpconn_add: hashes: 2646:2728:0, 863 Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tls [tls_server.c:184]: tls_complete_init(): Using TLS domain TLSc<default> Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tls [tls_domain.c:700]: sr_ssl_ctx_info_callback(): SSL handshake started Jan 25 14:32:43 /usr/sbin/kamailio[4722]: ERROR: <core> [tcp_main.c:2742]: tcpconn_1st_send(): connect 127.0.0.1:60286 failed (RST) Connection refused Jan 25 14:32:43 /usr/sbin/kamailio[4722]: ERROR: <core> [tcp_main.c:2752]: tcpconn_1st_send(): 127.0.0.1:60286: connect & send for 0xb1d3b7e8 failed: Connection refused (111) Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:2947]: tcpconn_chld_put(): tcpconn_chld_put: destroying connection 0xb1d3b7e8 (404319, -1) flags 0060 Jan 25 14:32:43 /usr/sbin/kamailio[4722]: ERROR: tm [../../forward.h:247]: msg_send(): tcp_send failed Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_fwd.c:1591]: t_send_branch(): t_send_branch: send to 127.0.0.1:60286 (3) failed Jan 25 14:32:43 /usr/sbin/kamailio[4722]: WARNING: tm [t_fwd.c:1610]: t_send_branch(): ERROR: t_send_branch: sending request on branch 0 failed Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_funcs.c:358]: t_relay_to(): ERROR:tm:t_relay_to: t_forward_nonack returned error Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_funcs.c:375]: t_relay_to(): -477 error reply generation delayed Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_lookup.c:1526]: t_unref(): t_unref: delayed error reply generation(-477) Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [parser/msg_parser.c:339]: parse_headers(): parse_headers: flags=ffffffffffffffff Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_reply.c:1670]: cleanup_uac_timers(): DEBUG: cleanup_uac_timers: RETR/FR timers reset Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_reply.c:728]: _reply_light(): DEBUG: reply sent out. buf=0xb67c000c: SIP/2.0 477 Unfortun..., shmem=0xb1b676cc: SIP/2.0 477 Unfortun Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_funcs.c:156]: put_on_wait(): DEBUG: put on WAIT Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_reply.c:738]: _reply_light(): DEBUG: _reply_light: finished Additionally want to say, that suddenly we don't have clear reproduce, it happened only on 2 production servers, what are common conditions for issue: - transport=TLS - when issued call is done, I checked with netstat, the connection is alive - the issued device is re-REGISTERed as usual, in kamctl ul show I see registration before/during/after issued call - issue appear only when connection through our custom TCP proxy :443 (to Kamailio it is from 127.0.0.1:5061) - if connection switched to Kamailio 5061 directly - issue never (till now) reproduced - in one of the issued server - I noticed big number of tcp id. Doing kamcmd core.tcp_list, I saw e.g. id: 567852 (usually id numbers are not more than 1000). - if kamailio/device reboot - problem disappear Because of not completely understanding how tcp core is working in kamailio, ask any suggestion, why such could happen. Any idea/hints would be greatly appreciated! kamailio -v version: kamailio 4.2.5 (i386/linux) flags: STATS: Off, EXTRA_DEBUG, 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 16:03:38 Jan 12 2016 with gcc 4.3.2 sorry for the long description cheers! -- View this message in context: http://sip-router.1086192.n5.nabble.com/rare-impossibility-to-send-requests… Sent from the Users mailing list archive at Nabble.com.

2 5

Reg: Facing issue in Registration of SIP Client
by sainath.ellendula＠wipro.com 04 Mar '16

04 Mar '16

Hi Franz, On Successful completion of Registration of IMS client. Now, I was trying to REGISTER SIP Client, But REGISTER request failing with 403 forbidden- User unknown. Please find attachment of X-lite configuration and Tcpdump from #422. Could you please suggest me any changes has to be done. Thanks in advance!! Regards, Sainath The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

3 9

Releasing Kamailio v4.3.5
by Daniel-Constantin Mierla 03 Mar '16

03 Mar '16

Hello, it's been a while since the release of v4.3.4, therefore I am considering to release a new minor version from branch 4.3 next week, most probably on Thursday, March 3, 2016. As usual, if there you are aware of issues not reported to the tracker [1], do it as soon as possible to get a chance to be fixed before the release date. Cheers, Daniel [1] https://github.com/kamailio/kamailio/issues -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Berlin, March 7-9, 2016 - http://www.asipto.com

1 2

Handling of messages with manipulated Event header.
by Christopher Vella 02 Mar '16

02 Mar '16

Hi, I apologise if this is not the correct venue for such a question... I am running kamailio v4.3.4 (x86_64/linux) on debian Jessie, sourced from; deb http://deb.kamailio.org/kamailio jessie main In my routing logic I am handling SUBSCRIBE requests and striping extra Event package parameters appended to "ua-profile" event types. i.e.; Event: ua-profile;model=somemodel;vendor=somevendor;profile-type=user becomes; Event: ua-profile This is done with this code; } else if( is_method("SUBSCRIBE")) { subst('/ua-profile.*/ua-profile/') ; handle_subscribe(); t_release(); However, in such conditions "search_event()" doesn't correctly find the event. Even though it looks like it is searching for the right event type; start event= [ua-profile/7] handle_subscribe(): unsupported presence event ua-profile --- Begin debug ---- ]3(7664) DEBUG: <core> [re.c:457]: subst_run(): matched (332, 79): [Event: ua-profile;model=somemodel;vendor=somevendor;profile-type=user] with [Event: ua-profile]extops.c:680]: subst_f(): textops: replacing at offset 376[Event: ua-profile;model=somemodel;vendor=somevendor;profile-type=user] 13(7664) debug: textops [textops.c:696]: subst_f(): lst was 0x7fb391fd0da8 13(7664) error: *** cfgtrace:request_route=[presence] c=[/etc/kamailio/kamailio.cfg] l=365 a=24 n=handle_subscribe 13(7664) debug: presence [event_list.c:348]: search_event(): start event= [ua-profile/7] 13(7664) notice: presence [subscribe.c:1092]: handle_subscribe(): unsupported presence event ua-profile 13(7664) debug: tm [t_lookup.c:1011]: t_check_msg(): debug: t_check_msg: msg id=1 global id=1 t start=0x7fb388763290 13(7664) debug: tm [t_lookup.c:1083]: t_check_msg(): debug: t_check_msg: t already found! 13(7664) debug: <core> [mem/shm_mem.c:101]: _shm_resize(): warning:vqm_resize: resize(0) called 13(7664) debug: tm [t_reply.c:1591]: cleanup_uac_timers(): debug: cleanup_uac_timers: retr/fr timers reset 13(7664) debug: <core> [tcp_main.c:2196]: tcpconn_send_put(): send from reader (7664 (13)), reusing fd 13(7664) debug: <core> [tcp_main.c:2430]: tcpconn_do_send(): sending... 13(7664) debug: <core> [tcp_main.c:2464]: tcpconn_do_send(): after real write: c= 0x7fb38875ecf8 n=368 fd=9 13(7664) debug: <core> [tcp_main.c:2465]: tcpconn_do_send(): buf= sip/2.0 489 bad event via: sip/2.0/tcp 127.0.1.1:5060;branch=z9hg4bk-2999-1-0;rport=34679;received=192.168.88.88 cseq: 1 subscribe call-id: 1-2999(a)127.0.1.1 from: <sip:c.vella@albourne.com>;tag=1 to: <sip:provisioning@albourne.com>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-811a --- End debug --- As a test, I send another message with clean "Event: ua-profile" and this works , event= [ua-profile/7] is found. --- Begin debug --- ]4(7665) DEBUG: <core> [re.c:457]: subst_run(): matched (332, 18): [Event: ua-profile ] with [Event: ua-profile]extops.c:680]: subst_f(): textops: replacing at offset 376 [Event: ua-profile 14(7665) DEBUG: textops [textops.c:696]: subst_f(): lst was 0x7fb391fd0da8 14(7665) ERROR: *** cfgtrace:request_route=[PRESENCE] c=[/etc/kamailio/kamailio.cfg] l=365 a=24 n=handle_subscribe 14(7665) DEBUG: presence [event_list.c:348]: search_event(): start event= [ua-profile/7] 14(7665) DEBUG: presence [subscribe.c:1161]: extract_sdialog_info_ex(): 'Expires' header found, value= 3600 14(7665) DEBUG: presence [subscribe.c:1195]: extract_sdialog_info_ex(): 'To' header ALREADY PARSED: <sip:provisioning@albourne.com> 14(7665) DEBUG: presence [subscribe.c:1266]: extract_sdialog_info_ex(): generating to_tag 14(7665) DEBUG: sl [sl.c:329]: get_reply_totag(): totag stateful mode (tm) 14(7665) DEBUG: presence [subscribe.c:1326]: extract_sdialog_info_ex(): subs->contact= sip:c.vella@192.168.88.179:59206;transport=tcp - len = 46 14(7665) DEBUG: presence [subscribe.c:1043]: handle_subscribe(): subscription status= active - inserted 14(7665) DEBUG: presence [subscribe.c:554]: update_subscription(): update subscription 14(7665) DEBUG: presence [notify.c:115]: printf_subs(): pres_uri: sip:c.vella@albourne.com 14(7665) DEBUG: presence [notify.c:116]: printf_subs(): watcher_user@watcher_domain: c.vella(a)albourne.com 14(7665) DEBUG: presence [notify.c:117]: printf_subs(): to_user@to_domain: provisioning(a)albourne.com 14(7665) DEBUG: presence [notify.c:118]: printf_subs(): from_user@from_domain: c.vella(a)albourne.com 14(7665) DEBUG: presence [notify.c:119]: printf_subs(): callid/from_tag/to_tag: 1-3002(a)127.0.1.1/1/a6a1c5f60faecf035a1ae5b6e96e979a-1030 14(7665) DEBUG: presence [notify.c:120]: printf_subs(): local_cseq/remote_cseq: 0/1 14(7665) DEBUG: presence [notify.c:121]: printf_subs(): local_contact/contact: sip:192.168.88.85:5060;transport=tcp/sip:c.vella@192.168.88.179:59206;transport=tcp 14(7665) DEBUG: presence [notify.c:122]: printf_subs(): record_route: 14(7665) DEBUG: presence [notify.c:123]: printf_subs(): sockinfo_str: tcp:192.168.88.85:5060 14(7665) DEBUG: presence [notify.c:125]: printf_subs(): event: ua-profile 14(7665) DEBUG: presence [notify.c:126]: printf_subs(): status: active 14(7665) DEBUG: presence [notify.c:127]: printf_subs(): reason: 14(7665) DEBUG: presence [notify.c:128]: printf_subs(): version: 1 14(7665) DEBUG: presence [notify.c:129]: printf_subs(): expires: 3600 14(7665) DEBUG: presence [notify.c:131]: printf_subs(): updated/updated_winfo: -1/-1 14(7665) DEBUG: presence [subscribe.c:629]: update_subscription(): subscription not in dialog 14(7665) DEBUG: presence [subscribe.c:634]: update_subscription(): inserting in shtable 14(7665) DEBUG: tm [t_lookup.c:1011]: t_check_msg(): DEBUG: t_check_msg: msg id=1 global id=1 T start=0x7fb388763290 14(7665) DEBUG: tm [t_lookup.c:1083]: t_check_msg(): DEBUG: t_check_msg: T already found! 14(7665) DEBUG: <core> [mem/shm_mem.c:101]: _shm_resize(): WARNING:vqm_resize: resize(0) called 14(7665) DEBUG: tm [t_reply.c:1591]: cleanup_uac_timers(): DEBUG: cleanup_uac_timers: RETR/FR timers reset 14(7665) DEBUG: <core> [tcp_main.c:2196]: tcpconn_send_put(): send from reader (7665 (14)), reusing fd 14(7665) DEBUG: <core> [tcp_main.c:2430]: tcpconn_do_send(): sending... 14(7665) DEBUG: <core> [tcp_main.c:2464]: tcpconn_do_send(): after real write: c= 0x7fb38875ecf8 n=399 fd=9 14(7665) DEBUG: <core> [tcp_main.c:2465]: tcpconn_do_send(): buf= SIP/2.0 202 OK Via: SIP/2.0/TCP 127.0.1.1:5060;branch=z9hG4bK-3002-1-0;rport=34680;received=192.168.88.88 CSeq: 1 SUBSCRIBE Call-ID: 1-3002(a)127.0.1.1 From: <sip:c.vella@albourne.com>;tag=1 To: <sip:provisioning@albourne.com>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-1030 Expires: 3600 Contact: <sip:192.168.88.85:5060;transport=tcp> --- End debug --- I suspect I am not understanding this correctly. Is there a proper way around this? I wonder if I am wrong to think that textops Module manipulates the actual request message? Thank you! Regards, -- Chris Vella Albourne Partners (Canada) Limited

2 2

LCR Commands Kamctl
by Alberto Sagredo 02 Mar '16

02 Mar '16

I have just edited kamctl in order to make lcr commands work. Hope that helps someone. Using Kamailio 4.3.0 Please find kamctl attached also ### LCR management # lcr() *{* *case* $1 *in* show_gws) # merr "command disabled" # exit 1 require_dbengine mecho "lcr gateways" QUERY="select * FROM lcr_gw ORDER BY id; " $DBROCMD "$QUERY" ;; show_routes) # merr "command disabled" # exit 1 require_dbengine mecho "lcr routes" QUERY="select * FROM lcr_rule ORDER BY id;" $DBROCMD "$QUERY" ;; reload) # merr "command disabled" # exit 1 kamcmd lcr.reload ;; dump_gws) # merr "command disabled" # exit 1 kamcmd lcr.dump_gws ;; dump_routes) # merr "command disabled" # exit 1 kamcmd lcr.dump_rules *exit* 1 ;; eval_weights) *shift* $AWK 'BEGIN { if (ARGC < 2) { printf("Usage: lcr eval_weights <list of weights (integers 1-254)>\n"); exit; } iters = 100000; for (i = 1; i < ARGC; i++) { counts[i] = 0; } for (i = 1; i <= iters; i++) { for (j = 1; j < ARGC; j++) { elem[j] = ARGV[j] * rshift(int(2147483647 * rand()), 8); } at = 1; max = elem[at]; for (j = 2; j < ARGC; j++) { if (elem[j] > max) { max = elem[j]; at = j; } } counts[at] = counts[at] + 1; } for (i = 1; i < ARGC; i++) { printf("weight %d probability %.4f\n", ARGV[i], counts[i]/iters); } }' $@ ;; *) usage_lcr *exit* 1 *esac* *}*

3 2

catching lost websocket ua
by Juha Heinanen 01 Mar '16

01 Mar '16

I have done some more digging on websocket:closed event route. In DB_ONLY mode, easy deregistration of a websocket UA at connection close would require access in the event route to connection_id of the closed connection. The function that is run at the close has ws_connection_t argument: static void wsconn_run_route(ws_connection_t *wsc) ws_connection_t record has these two fields: int id; /* id and id_hash are identical to the values */ unsigned id_hash; /* for the corresponding TCP/TLS connection */ Is id the same thing as what is stored in connection_id field of location table? If it is, may be its value could be made available to the event route in a pseudo variable. -- Juha

2 8

(no subject)
by Loïc Boissy 01 Mar '16

01 Mar '16

Hello, We have detected a problem on the increment of CSeq in the SIP header from kamailio. In a session SIP subscribe / notify, we notice that there is a notify that has the same CSeq than the last. As an attachment capture wireshard to clarify our remarks. Is that you can check where is the problem? Best regards. Loïc -- Visit Digigram Booth N3534 <http://www.mapyourshow.com/shows/index.cfm?Show_ID=nab16&exhid=1436&booth=N…> at the NAB Show in Las Vegas April 18-21! Check out our showroom click here <http://nab16.mapyourshow.com/7_0/exhibitor_details.cfm?exhid=1436>! Use our Guest Pass code LV6965 <https://registration.experientevent.com/showNAB161/default.aspx?Tracking=WB…> for your free pass www.nabshow.com

3 5

Domain Reload issue
by Errol Samuels 29 Feb '16

29 Feb '16

Hi All, I seem to have an issue when I run the command "kamctl domain reload" where kamailio stops running. Feb 27 07:40:16 il-kam01 kernel: [878538.747898] traps: kamailio[11903] general protection ip:7f19ca760a20 sp:7ffe5a1e8890 error:0 in domain.so[7f19ca754000+16000] Feb 27 07:40:16 il-kam01 /usr/sbin/kamailio[11911]: CRITICAL: <core> [pass_fd.c:293]: receive_fd(): EOF on 16 Feb 27 07:40:16 il-kam01 /usr/sbin/kamailio[11896]: ALERT: <core> [main.c:783]: handle_sigs(): child process 11903 exited by a signal 11 Feb 27 07:40:16 il-kam01 /usr/sbin/kamailio[11896]: ALERT: <core> [main.c:786]: handle_sigs(): core was not generated Feb 27 07:40:16 il-kam01 /usr/sbin/kamailio[11896]: INFO: <core> [main.c:798]: handle_sigs(): terminating due to SIGCHLD Feb 27 07:40:16 il-kam01 /usr/sbin/kamailio[11908]: INFO: <core> [main.c:849]: sig_usr(): signal 15 received Feb 27 07:40:16 il-kam01 /usr/sbin/kamailio[11909]: INFO: <core> [main.c:849]: sig_usr(): signal 15 received Feb 27 07:40:16 il-kam01 /usr/sbin/kamailio[11907]: INFO: <core> [main.c:849]: sig_usr(): signal 15 received Feb 27 07:40:16 il-kam01 /usr/sbin/kamailio[11910]: INFO: <core> [main.c:849]: sig_usr(): signal 15 received Feb 27 07:40:16 il-kam01 /usr/sbin/kamailio[11905]: INFO: <core> [main.c:849]: sig_usr(): signal 15 received Feb 27 07:40:16 il-kam01 /usr/sbin/kamailio[11902]: INFO: <core> [main.c:849]: sig_usr(): signal 15 received Feb 27 07:40:16 il-kam01 /usr/sbin/kamailio[11900]: INFO: <core> [main.c:849]: sig_usr(): signal 15 received Feb 27 07:40:16 il-kam01 /usr/sbin/kamailio[11897]: INFO: <core> [main.c:849]: sig_usr(): signal 15 received Feb 27 07:40:16 il-kam01 /usr/sbin/kamailio[11904]: INFO: <core> [main.c:849]: sig_usr(): signal 15 received Feb 27 07:40:16 il-kam01 /usr/sbin/kamailio[11901]: INFO: <core> [main.c:849]: sig_usr(): signal 15 received Feb 27 07:40:16 il-kam01 /usr/sbin/kamailio[11906]: INFO: <core> [main.c:849]: sig_usr(): signal 15 received Feb 27 07:40:16 il-kam01 /usr/sbin/kamailio[11898]: INFO: <core> [main.c:849]: sig_usr(): signal 15 received Feb 27 07:40:16 il-kam01 /usr/sbin/kamailio[11899]: INFO: <core> [main.c:849]: sig_usr(): signal 15 received Feb 27 07:40:16 il-kam01 /usr/sbin/kamailio[11911]: INFO: <core> [main.c:849]: sig_usr(): signal 15 received Feb 27 07:40:16 il-kam01 kernel: [878538.757055] traps: kamailio[11896] general protection ip:7f19ca760a20 sp:7ffe5a1e9000 error:0 in domain.so[7f19ca754000+16000] root@il-kam01:/usr/lib64/kamailio# kamailio -V version: kamailio 4.2.0 (x86_64/linux) 36e695 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: 36e695 compiled on 19:52:29 Jan 28 2015 with gcc 4.9.2 Any ideas? Thanks in advance.

2 3

Help
by Kevin Farrell-Pelletier 29 Feb '16

29 Feb '16

Hi, I work for a VOIP service provider, and have been tasked with optimizing our infrastructure. We have been providing VOIP services to our clients via Asterisk VMs (PIAF) in an ESXi environment, hosted in a datacenter. We are looking for some kind of SIP Router, which would authenticate clients and route their SIP traffic to the appropriate server. By doing so, we are hoping to further secure our infrastructure and to possibly have only one Public IP (which would resolve to the Private IP of the SIP router). The Asterisk servers serve IVR/RINGGROUPS/OUTBOUNDTRUNKS/INBOUNDROUTES/OUTBOUNDROUTES. The Sip Router would therefore route all SIP traffic between the phones and the Asterisk servers, ad the phones would register to the SIP Router. I have tried many solutions (Kamailio, OpenSER, siproxd, Brekeke), but have not been able to configure these services to work the way we want them to. I am including a chart along with this email to outline what we would like to accomplish. Any suggestions or guides would be immensely appreciated. Thank you all for your time. Kevin Farrell Pelletier - Technicien informatique TI // Réseautique // Téléphonie IP // Programmation IT // Networking // VoIP // Application development 9060, boul Parkway, Anjou, Québec, Canada H1J1N5 Téléphone / Phone : 514.907.2000 Ext.203 F : 1.888.582.4001 - SF/TF : 1.855.907.2001 Web : <http://www.connextek.ca/> www.connextek.ca Pensez ENVIRONNEMENT, c'est important: n'imprimez que si nécessaire Consider the ENVIRONMENT before printing

4 3

What is the meaning of "shmized"
by sgy 28 Feb '16

28 Feb '16

Hi, Sorry, but I just want to know the meaning of "shmized", I can't find it in the dictionary, thank you very much. typedef struct _cfg_group { int num; /*!< number of variables within the group */ cfg_mapping_t *mapping; /*!< describes the mapping betweeen the cfg variable definition and the memory block */ char *vars; /*!< pointer to the memory block where the values are stored -- used only before the config is shmized. */ -- Best Regards, Shengy

4 5

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 February 2016