sr-users June 2011

sr-users@lists.kamailio.org

75 participants
114 discussions

by †ஐû●чƃцίш† Goh

Hi List, below is my setup.. rtpproxy and kamailio in one PC with 2 nic. (ppp0 with public IP[60.49.119.XX] and eth1 with private IP[192.168.2.3])and asterisk is on another PC with private IP[192.168.2.23] i use realtime integration for kamailio and asterisk.http://kb.asipto.com/asterisk:realtime:kamailio-3.1.x-asterisk-1.6… i have two yealink hardphone ext 101(ip 192.168.1.200) and 102(ip 192.168.1.132) and a softphone ext 103 registered successful.both hardphone are behind same nat (175.136.221.XX)and softphone ext 103(ip 10.129.138.225) behind nat also (113.210.97.XX) ul show:database engine 'MYSQL' loadedControl engine 'FIFO' loadedentering fifo_cmd ul_dumpDomain:: location table=512 records=3 max_slot=1 AOR:: 102 Contact:: sip:102@175.136.221.XX:5062 Q= Expires:: 3109 Callid:: 2043273564(a)175.136.221.241 Cseq:: 4 User-agent:: T22 7.3.0.50 Received:: sip:175.136.221.241:1039 State:: CS_SYNC Flags:: 0 Cflag:: 192 Socket:: udp:60.49.119.69:5060 Methods:: 16383 AOR:: 103 Contact:: sip:103@113.210.97.XX:58776;transport=UDP;ob Q= Expires:: 294 Callid:: oa8Pqx3mR.SVnzAVEYHTwVKZE8CbpY9l Cseq:: 27626 User-agent:: v1.0.0/iPhone State:: CS_NEW Flags:: 0 Cflag:: 0 Socket:: udp:60.49.119.69:5060 Methods:: 8143 AOR:: 101 Contact:: sip:101@175.136.221.XX:5062 Q= Expires:: 1738 Callid:: 451417581(a)175.136.221.241 Cseq:: 2 User-agent:: T20 9.41.0.80 State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: udp:60.49.119.69:5060 Methods:: 16383FIFO command was::ul_dump:openser_receiver_17783 103 try to call 102 and 101 work fine. 101 and 102 try call 103 also fine.when 101 call 102 it work fine but when 102 call 101 there is no audio for both side.102 call 101 wireshark capture on 102 sidekeep send rtp but no receive.192.168.1.132 -> 60.49.119.XX RTP when capture on 101 side.keep send rtp but no receive.192.168.1.200 -> 60.49.119.XX RTP and also when 101 try to call into voicemail there is no audioit keep send rtp packet but to192.168.1.200 -> 192.168.2.23 RTP in kamailio.cfg#!WITH_NATlisten=60.49.119.XXlisten=192.168.2.3 # uncomment next line to do SIP NAT pinging setbflag(FLB_NATSIPPING); nat_uac_test("19")rtpproxy -l 60.49.119.XX -s udp:127.0.0.1 is running anyone can help me? how can i fix this?thanks in adv. Regards, minghon

12 years, 10 months

Re: [SR-Users] [sr-dev] kamailio 3.1.3 fail to start as a service when load the ldap.so module

by Daniel-Constantin Mierla

Thanks for reporting back, taking the chance to forward this email from sr-dev to sr-users since the thread was cross-posted to some point, for the benefit of future reads of the archive to show the solution of this case. Cheers, Daniel On 6/21/11 7:19 PM, laura testi wrote: > Found the problem after some investigation based on your suggestions. > In the openldap configuration file /etc/openldap/ldap.conf, the entry > TLS_CACERT is pointed to a certificate file in a directory which is > accessible only by root user. After I move the file to a directory > which all user can access it, now it works. I can start the kamailio > as a service with "service kamailio start" with the running user and > group is kamailio. > > Thank you all for your helps and suggestions! > > Best Regards, > Laura > > On Tue, Jun 21, 2011 at 5:44 PM, laura testi <lau.testi(a)gmail.com > <mailto:lau.testi@gmail.com>> wrote: > > The SELinux is disabled. > > > > > On Tue, Jun 21, 2011 at 5:26 PM, Andrew Pogrebennyk > <andrew.pogrebennyk(a)portaone.com > <mailto:andrew.pogrebennyk@portaone.com>> wrote: > > On 21.06.2011 17 <tel:21.06.2011%2017>:30, laura testi wrote: > > Should I need to set a some special environment variable > to load ldap.so > in the /etc/init.d/kamailio? > > > The env output for root does not confirm my theory :) I'm not > sure what is preventing kamailio from communication with LDAP, > could it be that SELinux is enabled and denying it in some way? > > -- > Sincerely, > Andrew Pogrebennyk > > > > > > _______________________________________________ > sr-dev mailing list > sr-dev(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda

12 years, 10 months

kamailio 3.1.3 fail to start as a service when load the ldap.so module

by laura testi

Hi, we try to use LDAP module in kamailio, first we try only load the ldap.so only to see if it can be loaded. When we start from the command line with either "kamctl start" or directly "kamilio", the kamailio is started normally with different children. When I try to start as service with "service kamailio start" or "/etc/init.d/kamailio start". It fails with the following error in the /var/log/messages: ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Jun 21 10:28:39 kamailio3p1 kamailio: INFO: <core> [tcp_main.c:4716]: init_tcp: using epoll_lt as the io watch method (auto detected) Jun 21 10:28:39 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: usrloc [hslot.c:53]: locks array size 512 Jun 21 10:28:39 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: auth [auth_mod.c:312]: auth: qop set, but nonce-count (nc_enabled) support disabled Jun 21 10:28:39 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: permissions [parse_config.c:251]: file not found: //etc/kamailio/permissions.allow Jun 21 10:28:39 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: permissions [permissions.c:606]: default allow file (//etc/kamailio/permissions.allow) not found => empty rule set Jun 21 10:28:39 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: permissions [parse_config.c:251]: file not found: //etc/kamailio/permissions.deny Jun 21 10:28:39 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: permissions [permissions.c:615]: default deny file (//etc/kamailio/permissions.deny) not found => empty rule set Jun 21 10:28:39 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: ldap [ldap_mod.c:246]: OpenLDAP - 20343 Jun 21 10:28:39 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_init.c:511]: tls: _init_tls_h: compiled with openssl version "OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008" (0x0090802f), kerberos support: on, compression: on Jun 21 10:28:39 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_init.c:519]: tls: init_tls_h: installed openssl library version "OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008" (0x0090802f), kerberos support: on, zlib compression: on compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -I/usr/kerberos/include -DL_ENDIAN -DTERMIO -Wall -DMD32_REG_T=int -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wa,--noexecstack -DOPENSSL_USE_NEW_FUNCTIONS -fno-strict-aliasing -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM Jun 21 10:28:39 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_init.c:373]: tls: init_tls: disabling compression... Jun 21 10:28:39 kamailio3p1 /usr/sbin/kamailio[8774]: WARNING: tls [tls_init.c:564]: tls: init_tls_h: openssl kerberos malloc bug detected, kerberos support will be disabled... Jun 21 10:28:39 kamailio3p1 /usr/sbin/kamailio[8774]: WARNING: tls [tls_init.c:587]: tls: openssl bug #1491 (crash/mem leaks on low memory) workaround enabled (on low memory tls operations will fail preemptively) with free memory thresholds 9961472 and 4980736 bytes Jun 21 10:28:39 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: <core> [cfg/cfg_ctx.c:411]: INFO: cfg_set_now(): tls.low_mem_threshold1 has been changed to 9961472 Jun 21 10:28:39 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: <core> [cfg/cfg_ctx.c:411]: INFO: cfg_set_now(): tls.low_mem_threshold2 has been changed to 4980736 Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: <core> [udp_server.c:178]: INFO: udp_init: SO_RCVBUF is initially 129024 Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: <core> [udp_server.c:229]: INFO: udp_init: SO_RCVBUF is finally 262142 Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: <core> [udp_server.c:178]: INFO: udp_init: SO_RCVBUF is initially 129024 Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: <core> [udp_server.c:229]: INFO: udp_init: SO_RCVBUF is finally 262142 Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:176]: TLSs<default>: tls_method=9 Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:188]: TLSs<default>: certificate='//etc/kamailio/FBCIDS01V01.pem' Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:195]: TLSs<default>: ca_list='//etc/kamailio/tiglobalca.pem' Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:202]: TLSs<default>: crl='(null)' Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:206]: TLSs<default>: require_certificate=0 Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:213]: TLSs<default>: cipher_list='(null)' Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:220]: TLSs<default>: private_key='//etc/kamailio/FBCIDS01V01KEY.pem' Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:224]: TLSs<default>: verify_certificate=0 Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:227]: TLSs<default>: verify_depth=9 Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:544]: TLSs<default>: No client certificate required and no checks performed Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:597]: tls: set_ssl_options: detected openssl version (90802f) has the SSL_OP_TLS_BLOCK_PADDING bug, but compression is disabled so no workaround is needed Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:176]: TLSc<default>: tls_method=9 Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:188]: TLSc<default>: certificate='(null)' Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:195]: TLSc<default>: ca_list='(null)' Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:202]: TLSc<default>: crl='(null)' Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:206]: TLSc<default>: require_certificate=0 Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:213]: TLSc<default>: cipher_list='(null)' Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:220]: TLSc<default>: private_key='(null)' Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:224]: TLSc<default>: verify_certificate=0 Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:227]: TLSc<default>: verify_depth=9 Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:547]: TLSc<default>: Server MAY present invalid certificate Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:597]: tls: set_ssl_options: detected openssl version (90802f) has the SSL_OP_TLS_BLOCK_PADDING bug, but compression is disabled so no workaround is needed Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:176]: TLSs<10.10.5.214:5061>: tls_method=12 Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:188]: TLSs<10.10.5.214:5061>: certificate='//etc/kamailio/FBCIDS01V01.pem' Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:195]: TLSs<10.10.5.214:5061>: ca_list='//etc/kamailio/tiglobalca.pem' Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:202]: TLSs<10.10.5.214:5061>: crl='(null)' Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:206]: TLSs<10.10.5.214:5061>: require_certificate=0 Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:213]: TLSs<10.10.5.214:5061>: cipher_list='(null)' Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:220]: TLSs<10.10.5.214:5061>: private_key='//etc/kamailio/FBCIDS01V01KEY.pem' Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:224]: TLSs<10.10.5.214:5061>: verify_certificate=0 Jun 21 10:28:40 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:227]: TLSs<10.10.5.214:5061>: verify_depth=9 Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:544]: TLSs<10.10.5.214:5061>: No client certificate required and no checks performed Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: tls [tls_domain.c:597]: tls: set_ssl_options: detected openssl version (90802f) has the SSL_OP_TLS_BLOCK_PADDING bug, but compression is disabled so no workaround is needed Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8786]: ERROR: ldap [ldap_connect.c:166]: [sipaccounts]: ldap bind failed: Can't contact LDAP server Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8786]: ERROR: ldap [ldap_mod.c:182]: [sipaccounts]: failed to connect to LDAP host(s) Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8786]: ERROR: <core> [sr_module.c:832]: init_mod_child(): Error while initializing module ldap (/usr/lib64/kamailio/modules_k/ldap.so) Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8786]: ERROR: <core> [pt.c:337]: ERROR: fork_process(): init_child failed for process 1, pid 8786, "udp receiver child=0 sock=127.0.0.1:5060" Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8786]: : <core> [main.c:1546]: main_loop: Cannot fork Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8788]: ERROR: ldap [ldap_connect.c:166]: [sipaccounts]: ldap bind failed: Can't contact LDAP server Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8788]: ERROR: ldap [ldap_mod.c:182]: [sipaccounts]: failed to connect to LDAP host(s) Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8788]: ERROR: <core> [sr_module.c:832]: init_mod_child(): Error while initializing module ldap (/usr/lib64/kamailio/modules_k/ldap.so) Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8788]: ERROR: <core> [pt.c:337]: ERROR: fork_process(): init_child failed for process 2, pid 8788, "udp receiver child=1 sock=127.0.0.1:5060" Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8788]: : <core> [main.c:1546]: main_loop: Cannot fork Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8774]: ALERT: <core> [main.c:738]: child process 8786 exited normally, status=255 Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8774]: ALERT: <core> [main.c:738]: child process 8788 exited normally, status=255 Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8774]: INFO: <core> [main.c:756]: INFO: terminating due to SIGCHLD Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8801]: INFO: <core> [main.c:807]: INFO: signal 15 received Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8799]: INFO: <core> [main.c:807]: INFO: signal 15 received Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8797]: INFO: <core> [main.c:807]: INFO: signal 15 received Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8795]: INFO: <core> [main.c:807]: INFO: signal 15 received Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8793]: INFO: <core> [main.c:807]: INFO: signal 15 received Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8790]: INFO: <core> [main.c:807]: INFO: signal 15 received Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8812]: INFO: <core> [main.c:807]: INFO: signal 15 received Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8808]: INFO: <core> [main.c:807]: INFO: signal 15 received Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8810]: INFO: <core> [main.c:807]: INFO: signal 15 received Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8814]: INFO: <core> [main.c:807]: INFO: signal 15 received Jun 21 10:28:41 kamailio3p1 /usr/sbin/kamailio[8816]: INFO: <core> [main.c:807]: INFO: signal 15 received ... -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Without ldap.so loaded, we can start the kamailio as a service normally with "service kamailio start". The platform running kamailio is: RHEL5.6_X64 Can you help us please? Because we want to start the kamailio as a service from the boot Thanks a lot in advanced! Best Regards, Laura

12 years, 10 months

an IDEA

by afshin afzali

Hi Guys, I need to integrate a SIP processing environment to H.248 and SS7/ ISUP links. For those communication links, OpenSS7 and Erlang/OTP MEGACO are good solutions. My idea is to write applications over OTP and SIP-Router to be able to bridge non-SIP protocols to SIP! On OTP the way is clear, but on SIP-Router I need to be able to generate / terminate SIP transactions. I'll appreciate every comment. BEST, -- afshin

12 years, 10 months

Security in proxy

by Anto

Hi After reading the modules pike, pipelimit, etc. I wanted to know what measures can be used in the proxy, because like me, there will be more people interested ;-). We see that the module pike is a good security measure, but for users with many channels, we used the configuration of users with few channels (could we discriminate and make different rules for each?). If we have the proxy settings for normal users and have trunk configuration as well, I guess we also mark the traffic of the trunk to see it too aggressive about the user. As you might know if discriminate different types of users according to their traffic, one solution I can think of is to have different proxies for each user type (trunk, normal, etc). Is there any way to implement something that detects unusual behavior on the user (referred to countries that do not ever called, excessive traffic, etc)?. I ask not to try to implement something that exists or perhaps someone can advise me how to do so because it is very likely not get it or do it wrong :-P . Continue to seek information and if I find something to contribute, send him to the list. Can you think of some way more secure proxy (mainly user accounts)? Do some basic safety tips to take into consideration? Any guidance? My advice to avoid trying to schedule something with 100 lines of code when I can do with 5 lines? Does this indicate that I intend to do not I make it :-P ?. What I said, I will try paper on the subject and if I can find information on something (though it may seem a bad code :-( ), which publishes. Thanks ;-) Regards Anto

12 years, 10 months

Keeping transactions in standby till future events

by Gustavo Garcia Bernardo

Is it possible to configure sip-router to keep a transaction for an incoming message (f.e. an INVITE) without sending a response and without forwarding it, and then reference and complete it in the future? Using pseudocode this is the logic I would like to implement: //When receiving an INVITE leave it pending if (request is INVITE) { store transactionID // This transactionID will be send somehow to the client return } //When receiving a PUBLISH referencing a pending transaction complete the forwarding if (request is PUBLISH) { transactionId = header("X-TransactionId") destination = header("X-Destination") transactions [transactionID]. forward(destination) } Thank you very much, G. Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx

12 years, 10 months

Help find out where to modify request uri

by Simone Felici

Hi to all, I need to edit our ser installation (OLD ser-2.0.0-rc1) implementing a check to rewrite the INVITE URI address in case a flag on a DB is set or not. I'm not proof on this and as always the solution is to find out on the production system without the possibility (for now) to upgrade to most recent version. In fact I would load the flag with the db_ops module. The scenario should be the follow: 1. a call is coming from sip or from pstn to an internal sip account 2. the ser should check if a given flag for the called account is set (db_ops) 3. if it's set it should take the destination URI (taken from location db table) and rewrite the number to another known number. i.e. from sip:123456789@IP;uniqu=... to sip:new987654321@IP;uniq=... My first issue is to identify WHERE ser execute the INVITE to the sip account and how rewrite the URI. Could someone point me to the right place and give me some suggestion? The ser.cfg used could be read from a previous post of me: http://www.mail-archive.com/sr-users@lists.sip-router.org/msg04900.html Thank's a lot! Simon

12 years, 10 months

Invite replies

by Lucas Alvarez

Hi, how may I catch the reply of an invite? I did this but it seems is not working: if (method=="INVITE") { $avp(sdp_ret) = fix_nated_sdp("11"); xlog("L_ALERT","#####********###### SDP return: $avp(sdp_ret)\n"); append_hf("P-hint: sdp rewritten\r\n"); t_on_reply("REPLY_TWO"); } onreply_route("REPLY_TWO") { xlog("L_ALERT","ALERT: ################ $rU - $rm from $fu (IP:$si:$sp--------$di)\n"); return; } Any help will be appreciate it, thanks in advance. Lucas

12 years, 10 months

100rel without direct reachability

by Alex Balashov

(Sorry for cross-posting from Sip-Implementors; however, upon some reflection this is really more of a Kamailio mechanics question.) Greetings, I have a scenario where endpoint A is calling endpoint B through proxy P. Endpoints A and B are on different networks that are not directly reachable--A is on the public Internet, to which proxy P is connected, but NAT'd, and B is on a private RFC1918 network on which the proxy P has an interface as well. The purpose of proxy P is to make calling A <-> B possible, while providing the appropriate far-end NAT traversal functionality for A and so on and so on. It does this by inserting the correct Record-Route headers into the INVITE from A, and otherwise by staying in the signaling path; both A and B can reach the proxy, so all requests and replies go through it. The problem I'm having is prior to full dialog establishment. Upon receipt of INVITE from A by way of proxy P, B replies with 183 + SDP and also: Require: 100rel In the 183 it provides a Contact on its private network that A obviously cannot reach: Contact: <sip:xxxxx@192.168.0.10:5060> As a result, A attempts to send PRACKs to sip:xxxxx@192.168.0.10, which are obviously not going to go anywhere. After not receiving a few of these expected PRACKs, B replies to the call with a final negative failure. The question is, is there anything I can twiddle on the proxy to make this work? The problem with PRACKs is that although they are sequential requests, they arise (in this case) prior to the point at which RR can be used to guide them through the proxy. The most obvious answer is, "Make B not Require: 100rel", of course. However, that is not an option here. Thanks! -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/

12 years, 10 months

HTTP POST

by Matthew Williams

Hi, I'm working on an application that needs to create an HTTP POST from within Kamailio. The utils module has the http_query function, but that is only for GET. I think I'm looking for something more like the uac module's uac_req_send -- but for http. Any suggestions? Thanks in advance!

12 years, 10 months

← Newer
1
...
4
5
6
7
8
9
10
11
12
Older →

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 June 2011