Dear List.
I'm trying to change the contact header of a message. ( by calliing
add_contact_alias - that shuld add the ;alias= parameter to the contact
header)
but, when i print the contact header (with xlog), it shows no change.
I know the function works, and that it added the parameter as expected by
using debug mode. (it sais that it was added)
Can anyone explain me why i don't see that change in the xlog ? (i've
printer both $ct and $hdr(Contact))
thank's in advance...
Hi,
We have a solution which requires only outbound NAT on SIP calls.
Do you have a product which would solve the NAT Traversal problem on the outbound SIP calls?
If yes, how much would be the cost of this product?
Will it support 2000 simultaneous calls?
BR//
Ishan
Hi!
According "Transformations cookbook" exist string, uri, name
transformations. I think need ip transformations, simulary
atoi()/aton() and split for stings with divider.
By the way:
avp_subst("$avp(s:sipa)/$avp(s:abc)/g", "/(.*)\.(.*)\.(.*)\.(.*)/\1/");
avp_subst("$avp(s:sipa)/$avp(s:def)/g", "/(.*)\.(.*)\.(.*)\.(.*)/\2/");
avp_subst("$avp(s:sipa)/$avp(s:ghk)/g", "/(.*)\.(.*)\.(.*)\.(.*)/\3/");
avp_subst("$avp(s:sipa)/$avp(s:xyz)/g", "/(.*)\.(.*)\.(.*)\.(.*)/\4/");
$avp(s:numipa)=$avp(s:abc{s.int})<<24||$avp(s:defi{s.int})<<16||$avp(s:ghki{s.int})<<8||$avp(s:xyz{s.int});
where is error?
--
SY,
Victor
JID: coyote(a)bks.tv
JID: coyote(a)bryansktel.ru
I use FREE operation system: 3.8.4-calculate GNU/Linux
Hello,
first I want to thank to all participants to Kamailio World Conference,
everyone having a relevant contribution to it, turning out the two days
in a very successful event.
Special thanks to our sponsors - Sipwise, Fraunhofer Fokus, Asipto,
Sipgate, NG-Voice, IT Center, Amooma and Zoiper - without them it would
have been pretty impossible to bring a great group of speakers, have a
nice location, excellent logistics and services on site - practically
all that had matter to get such great event.
As organizers, we learned a lot, significantly helping to get even
better for next editions. Please do send feedback to us, it is very
important to improve for the next years, even if you didn't participate,
you can tell us what you would like to have at such event.
For everyone in the community I want to say that the slides should be
published in the near future. We also recorded the sessions, I haven't
checked the movies yet, if the quality is fair enough, then they will be
made available (probably will take a bit longer than the slides).
Several sessions were recorded separately also by Randy from VUC, being
already available on youtube:
- https://www.youtube.com/user/voipusers/videos?sort=dd
I will send soon more details, as new resources are made available.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Hi all.
I've got following construction:
modparam("acc_radius", "radius_extra", " \
Calling-Station-Id=$tU; \
User-Name=$rU; \
Called-Station-Id=$fU; \
Framed-IP-Address=$si; \
h323-call-origin=$var(ho); \
h323-disconnect-cause=$var(hdc); \
h323-connect-time=$var(ct); \
h323-disconnect-time=$var(dt); \
h323-setup-time=$var(st); \
Cisco-AVPair=$var(cavp); \
Cisco-Call-Type=$var(cct) \
")
Framed-IP-Address in dictionary described as "ipaddr". If i send $si
(as writen above), then radius server get incorrect ip like
46.48.44.49. If I try to assign $si any attribute has string type - all
ok. How can I typecast here?
Simulary problem for attributes "h323-disconnect-time",
"h323-setup-time" - need timestamp in format "0000-00-00 00:00:00"
--
SY,
Victor
JID: coyote(a)bks.tv
JID: coyote(a)bryansktel.ru
I use FREE operation system: 3.8.4-calculate GNU/Linux
Hello,
we use the xmlrpc module to fetch the list of users with the ul_dump MI command. When the number of users increased, this started to fail as the output size grew. Apparently this is because of too small write queue sizes (tcp_conn_wq_max). I discussed increasing the tcp_conn_wq_max setting with a coworker, who was reluctant to change it as it would affect SIP over TCP as well. We would probably also have to increase it if we hit the limit again at a later time. What we would like to know is if there's a way around this without having to fiddle with buffer sizes (or if this behavior is considered a bug).
We originally used the mi_xmlrpc module, but changed to the xmlrpc module as the former made kamailio spawn zombie processes on xmlrpc requests (which is considered a bug I guess).
FWIW, here's the log from a failed request, running kamailio 3.3.4:
Apr 1 23:38:24 server /usr/sbin/kamailio[4982]: DEBUG: <core> [ip_addr.c:247]: tcpconn_new: new tcp connection: [REMOVED]
Apr 1 23:38:24 server /usr/sbin/kamailio[4982]: DEBUG: <core> [tcp_main.c:1089]: tcpconn_new: on port 40261, type 2
Apr 1 23:38:24 server /usr/sbin/kamailio[4982]: DEBUG: <core> [tcp_main.c:1403]: tcpconn_add: hashes: 40:3802:373, 326
Apr 1 23:38:24 server /usr/sbin/kamailio[4982]: DEBUG: <core> [io_wait.h:390]: DBG: io_watch_add(0x828660, 94, 2, 0x7f2f87f31ca8), fd_no=85
Apr 1 23:38:24 server /usr/sbin/kamailio[4982]: DEBUG: <core> [io_wait.h:617]: DBG: io_watch_del (0x828660, 94, -1, 0x0) fd_no=86 called
Apr 1 23:38:24 server /usr/sbin/kamailio[4982]: DEBUG: <core> [tcp_main.c:4298]: tcp: DBG: sending to child, events 1
Apr 1 23:38:24 server /usr/sbin/kamailio[4982]: DEBUG: <core> [tcp_main.c:3969]: selected tcp worker 5 58(4960) for activity on [tcp:0.0.0.0:8080], 0x7f2f87f31ca8
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [tcp_read.c:1358]: received n=8 con=0x7f2f87f31ca8, fd=10
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [tcp_read.c:1168]: tcp_read_req: content-length= 153
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [parser/msg_parser.c:624]: SIP Request:
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [parser/msg_parser.c:626]: method: <POST>
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [parser/msg_parser.c:628]: uri: </RPC2>
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [parser/msg_parser.c:630]: version: <HTTP/1.0>
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [parser/msg_parser.c:202]: DEBUG: get_hdr_body : content_length=153
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [parser/msg_parser.c:104]: found end of header
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [receive.c:149]: After parse_msg...
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: xmlrpc [xmlrpc.c:2273]: new fake xml msg created (355 bytes):#012<POST sip:127.0.0.1:9 HTTP/1.0#015#012Via: SIP/2.0/TCP [REMOVED]:40261#015#012Host: [REMOVED]:8080#015#012User-Agent: xmlrpclib.py/1.0.1 (by www.pythonware.com)#015#012Content-Type: text/xml#015#012Content-Length: 153#015#012#015#012<?xml version='1.0'?>#012<methodCall>#012<methodName>mi</methodName>#012<params>#012<param>#012<value><string>ul_dump</string></value>#012</param>#012</params>#012</methodCall>#012>
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [parser/msg_parser.c:624]: SIP Request:
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [parser/msg_parser.c:626]: method: <POST>
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [parser/msg_parser.c:628]: uri: <sip:127.0.0.1:9>
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [parser/msg_parser.c:630]: version: <HTTP/1.0>
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [parser/parse_via.c:2561]: end of header reached, state=5
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [parser/msg_parser.c:511]: parse_headers: Via found, flags=2
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [parser/msg_parser.c:513]: parse_headers: this is the first via
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [parser/msg_parser.c:202]: DEBUG: get_hdr_body : content_length=153
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [parser/msg_parser.c:104]: found end of header
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [msg_translator.c:206]: check_via_address([REMOVED], [REMOVED], 0)
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: sl [sl_funcs.c:499]: execute callback for event type 1
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: siptrace [siptrace.c:1343]: trace off...
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [tcp_main.c:2316]: tcp_send: send from reader (4960 (58)), reusing fd
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [tcp_main.c:2552]: tcp_send: sending...
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [tcp_main.c:2586]: tcp_send: after real write: c= 0x7f2f87f31ca8 n=15928 fd=10
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [tcp_main.c:2587]: tcp_send: buf=[REMOVED]
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: ERROR: <core> [tcp_main.c:708]: ERROR: wbufq_add(64634 bytes): write queue full or timeout (0, total 0, last write 6648472 s ago)
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: ERROR: sl [../../forward.h:171]: msg_send: ERROR: tcp_send failed
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: ERROR: xmlrpc [xmlrpc.c:804]: Error while sending reply
Apr 1 23:38:24 server /usr/sbin/kamailio[4982]: DEBUG: <core> [tcp_main.c:3620]: handle_ser_child: read response= 7f2f87f31ca8, -2, fd -1 from 58 (4960)
Apr 1 23:38:24 server /usr/sbin/kamailio[4982]: ERROR: <core> [tcp_main.c:3634]: handle_ser_child: ERROR: received CON_ERROR for 0x7f2f87f31ca8 (id 7494), refcnt 3, flags 0x4018
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: xmlrpc [xmlrpc.c:2194]: xmlrpc: error while trying script
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil)
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil)
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil)
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil)
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil)
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil)
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [xavp.c:365]: destroying xavp list (nil)
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [tcp_read.c:1285]: releasing con 0x7f2f87f31ca8, state -2, fd=10, id=7494
Apr 1 23:38:24 server /usr/sbin/kamailio[4960]: DEBUG: <core> [tcp_read.c:1286]: extra_data (nil)
Apr 1 23:38:24 server /usr/sbin/kamailio[4982]: DEBUG: <core> [tcp_main.c:3381]: handle_tcp_child: reader response= 7f2f87f31ca8, -2 from 5
Thanks,
Jon
Hi,
Has anyone tested max TCP connections that a Kamailio node can handle? I
have an i7, 8GB server. I am trying to set max to 64K now. I want to set it
to 256K connections.
Would that work?
Thnx
Krish Kura
Hi Jeremy,
Thanks for the suggestion, I'm hoping I haven't overlooked something quite that obvious!
The last debug output I see on startup is:
> Listening on
> udp: 192.168.44.66:55060
> tcp: 192.168.44.66:55060
> Aliases:
> <snip>
>
> WARNING: no fork mode
> 0(20372) INFO: <core> [tcp_main.c:4833]: init_tcp: using epoll_lt as the io watch method (auto detected)
> 0(20372) INFO: usrloc [hslot.c:53]: locks array size 512
> 0(20372) INFO: <core> [udp_server.c:179]: INFO: udp_init: SO_RCVBUF is initially 229376
> 0(20372) INFO: <core> [udp_server.c:230]: INFO: udp_init: SO_RCVBUF is finally 262142
netstat shows listening for UDP on 55060, but nothing on TCP:
$ netstat -l | grep 5060
udp 0 0 192.168.44.66:55060 *:*
ps shows four kamailio processes running, all of which end when I Ctrl-C.
Cheers,
Dave.
> Date: Fri, 12 Apr 2013 14:22:45 +0800
> From: Jeremy Ardley <jeremy.ardley(a)gmail.com>
> Subject: Re: [SR-Users] Kamailio 4.0.0 not listening on TCP
>
>
> Have you checked to make sure it's still running?
>
>
> On 12/04/13 14:19, David Wilson wrote:
>> Hello All,
>>
>> New to Kamailio, I'm running 4.0 on Ubuntu 12.04 (precise).
>>
>> Running from the command line with a minimal config, it tells me that it is listening on port 5060 for both TCP and UDP. I see the same behaviour with the default cfg.
>>
>> However, netstat does not list anything listening on TCP port 5060 and an attempted connection is rejected consistent with there being no open socket.
>>
>> Any suggestions on where I need to be looking to fix this?
>>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> End of sr-users Digest, Vol 95, Issue 47
> ****************************************