sr-users July 2017

sr-users@lists.kamailio.org

69 participants
94 discussions

Need help to send INVITE to multiple client based on REGISTRATION status

by amit Kumar

Hi All, Following are the requirement which we want to achieve through Kamailio. Our "voip client" will not be register in advance.When Kamailio get INIVITE request for particular "voip client"(multiple client), we send push notification to make "voip client"(multiple client) alive and get it register for to Kamailio. Meanwhile INIVITE request will wait. the moment, "voip client" get register, Kamailio will send INIVITE to all the client despite their *registration time/status*.for example - if first client get register with in T+1 second,that should also get INVITE and another client get register in T+2 second that should also get INVITE. Could you please help me if this is possible in Kamailio. I have done some code walk through and have the basic idea to save the INVITE transaction(similar to suspend and continue), later point of time when i get the register request, I will use functionality like t_lookup_request and and lookup(which in turn append_branch) and call the t_realy () again. Please let me know if this is correct approach or if there is some other way to solve this. Thanks, Amit

6 years, 9 months

Database connection handles vs. processes

by Alex Balashov

Hi, By way of illustration, I have one server with children=8, a single UDP listener, and 23 processes total: -- 21117 attendant 21118 udp receiver child=0 sock=xxx.xxx.xxx.xxx:5060 21119 udp receiver child=1 sock=xxx.xxx.xxx.xxx:5060 21120 udp receiver child=2 sock=xxx.xxx.xxx.xxx:5060 21121 udp receiver child=3 sock=xxx.xxx.xxx.xxx:5060 21122 udp receiver child=4 sock=xxx.xxx.xxx.xxx:5060 21123 udp receiver child=5 sock=xxx.xxx.xxx.xxx:5060 21124 udp receiver child=6 sock=xxx.xxx.xxx.xxx:5060 21125 udp receiver child=7 sock=xxx.xxx.xxx.xxx:5060 21126 slow timer 21127 timer 21128 MI FIFO 21129 ctl handler 21130 RTIMER USEC EXEC 21131 RTIMER USEC EXEC 21132 RTIMER USEC EXEC 21133 RTIMER USEC EXEC 21134 RTIMER USEC EXEC 21135 RTIMER USEC EXEC 21136 RTIMER USEC EXEC 21137 Dialog KA Timer 21138 Dialog Clean Timer 21139 tcp main process # kamcmd -s /tmp/kamailio_ctl ps | wc -l 23 -- This appears to result in 23 total database connections to the Postgres server: -- # lsof -n | grep -i '^kam' | grep IPv4 | grep TCP | grep -i :postgres | wc -l 23 -- But I have another Kamailio server that has three listeners, two UDP and one TCP, and children=24, i.e. -- children=24 listen=udp:xxx.xxx.xxx.xxx:5060 listen=udp:yyy.yyy.yyy.yyy:5060 listen=tcp:zzz.zzz.zzz.zzz:5060 -- I am given to understand that the total number of worker processes there will be (children_setting * listeners), i.e. 72 in this case, plus some number of rtimer and supervisory processes, as in my case. And true enough: -- # kamcmd -s /tmp/kamailio_ctl ps | wc -l 86 # kamcmd -s /tmp/kamailio_ctl ps | sed 's/65.254.44.195/yyy.yyy.yyy.yyy/g' | sed 's/65.254.44.194/zzz.zzz.zzz.zzz/g' 22065 main process - attendant 22069 udp receiver child=0 sock=zzz.zzz.zzz.zzz:5060 22070 udp receiver child=1 sock=zzz.zzz.zzz.zzz:5060 22071 udp receiver child=2 sock=zzz.zzz.zzz.zzz:5060 22073 udp receiver child=3 sock=zzz.zzz.zzz.zzz:5060 22074 udp receiver child=4 sock=zzz.zzz.zzz.zzz:5060 22076 udp receiver child=5 sock=zzz.zzz.zzz.zzz:5060 22079 udp receiver child=6 sock=zzz.zzz.zzz.zzz:5060 22080 udp receiver child=7 sock=zzz.zzz.zzz.zzz:5060 22082 udp receiver child=8 sock=zzz.zzz.zzz.zzz:5060 22085 udp receiver child=9 sock=zzz.zzz.zzz.zzz:5060 22086 udp receiver child=10 sock=zzz.zzz.zzz.zzz:5060 22089 udp receiver child=11 sock=zzz.zzz.zzz.zzz:5060 22091 udp receiver child=12 sock=zzz.zzz.zzz.zzz:5060 22093 udp receiver child=13 sock=zzz.zzz.zzz.zzz:5060 22095 udp receiver child=14 sock=zzz.zzz.zzz.zzz:5060 22097 udp receiver child=15 sock=zzz.zzz.zzz.zzz:5060 22099 udp receiver child=16 sock=zzz.zzz.zzz.zzz:5060 22100 udp receiver child=17 sock=zzz.zzz.zzz.zzz:5060 22103 udp receiver child=18 sock=zzz.zzz.zzz.zzz:5060 22105 udp receiver child=19 sock=zzz.zzz.zzz.zzz:5060 22107 udp receiver child=20 sock=zzz.zzz.zzz.zzz:5060 22109 udp receiver child=21 sock=zzz.zzz.zzz.zzz:5060 22111 udp receiver child=22 sock=zzz.zzz.zzz.zzz:5060 22113 udp receiver child=23 sock=zzz.zzz.zzz.zzz:5060 22115 udp receiver child=0 sock=yyy.yyy.yyy.yyy:5060 22117 udp receiver child=1 sock=yyy.yyy.yyy.yyy:5060 22119 udp receiver child=2 sock=yyy.yyy.yyy.yyy:5060 22121 udp receiver child=3 sock=yyy.yyy.yyy.yyy:5060 22123 udp receiver child=4 sock=yyy.yyy.yyy.yyy:5060 22125 udp receiver child=5 sock=yyy.yyy.yyy.yyy:5060 22127 udp receiver child=6 sock=yyy.yyy.yyy.yyy:5060 22129 udp receiver child=7 sock=yyy.yyy.yyy.yyy:5060 22131 udp receiver child=8 sock=yyy.yyy.yyy.yyy:5060 22132 udp receiver child=9 sock=yyy.yyy.yyy.yyy:5060 22135 udp receiver child=10 sock=yyy.yyy.yyy.yyy:5060 22137 udp receiver child=11 sock=yyy.yyy.yyy.yyy:5060 22139 udp receiver child=12 sock=yyy.yyy.yyy.yyy:5060 22141 udp receiver child=13 sock=yyy.yyy.yyy.yyy:5060 22143 udp receiver child=14 sock=yyy.yyy.yyy.yyy:5060 22145 udp receiver child=15 sock=yyy.yyy.yyy.yyy:5060 22147 udp receiver child=16 sock=yyy.yyy.yyy.yyy:5060 22149 udp receiver child=17 sock=yyy.yyy.yyy.yyy:5060 22151 udp receiver child=18 sock=yyy.yyy.yyy.yyy:5060 22153 udp receiver child=19 sock=yyy.yyy.yyy.yyy:5060 22155 udp receiver child=20 sock=yyy.yyy.yyy.yyy:5060 22156 udp receiver child=21 sock=yyy.yyy.yyy.yyy:5060 22159 udp receiver child=22 sock=yyy.yyy.yyy.yyy:5060 22161 udp receiver child=23 sock=yyy.yyy.yyy.yyy:5060 22163 slow timer 22165 timer 22167 secondary timer 22168 ctl handler 22169 RTIMER USEC EXEC 22170 RTIMER USEC EXEC 22172 RTIMER USEC EXEC 22173 RTIMER USEC EXEC 22175 Dialog Clean Timer 22176 TIMER NH 22177 TIMER NH 22178 TIMER NH 22179 tcp receiver (generic) child=0 22180 tcp receiver (generic) child=1 22182 tcp receiver (generic) child=2 22184 tcp receiver (generic) child=3 22186 tcp receiver (generic) child=4 22188 tcp receiver (generic) child=5 22190 tcp receiver (generic) child=6 22192 tcp receiver (generic) child=7 22194 tcp receiver (generic) child=8 22196 tcp receiver (generic) child=9 22198 tcp receiver (generic) child=10 22200 tcp receiver (generic) child=11 22202 tcp receiver (generic) child=12 22204 tcp receiver (generic) child=13 22206 tcp receiver (generic) child=14 22208 tcp receiver (generic) child=15 22210 tcp receiver (generic) child=16 22212 tcp receiver (generic) child=17 22214 tcp receiver (generic) child=18 22216 tcp receiver (generic) child=19 22218 tcp receiver (generic) child=20 22220 tcp receiver (generic) child=21 22223 tcp receiver (generic) child=22 22225 tcp receiver (generic) child=23 22227 tcp main process -- But, for some reason, the number of database connections to Postgres seems to be considerably higher than the number of total processes: -- # lsof -n | grep '^kam' | grep TCP | grep IPv4 | grep ':postgres' | wc -l 114 -- This is not due to orphaned/unterminated Kamailio processes. There's only one process lineage: -- |-kamailio(22065)-+-kamailio(22069) | |-kamailio(22070) | |-kamailio(22071) | |-kamailio(22073) | |-kamailio(22074) | |-kamailio(22076) | |-kamailio(22079) | |-kamailio(22080) | |-kamailio(22082) | |-kamailio(22085) | |-kamailio(22086) | |-kamailio(22089) | |-kamailio(22091) | |-kamailio(22093) | |-kamailio(22095) | |-kamailio(22097) | |-kamailio(22099) | |-kamailio(22100) | |-kamailio(22103) | |-kamailio(22105) | |-kamailio(22107) | |-kamailio(22109) | |-kamailio(22111) | |-kamailio(22113) | |-kamailio(22115) | |-kamailio(22117) | |-kamailio(22119) | |-kamailio(22121) | |-kamailio(22123) | |-kamailio(22125) | |-kamailio(22127) | |-kamailio(22129) | |-kamailio(22131) | |-kamailio(22132) | |-kamailio(22135) | |-kamailio(22137) | |-kamailio(22139) | |-kamailio(22141) | |-kamailio(22143) | |-kamailio(22145) | |-kamailio(22147) | |-kamailio(22149) | |-kamailio(22151) | |-kamailio(22153) | |-kamailio(22155) | |-kamailio(22156) | |-kamailio(22159) | |-kamailio(22161) | |-kamailio(22163) | |-kamailio(22165) | |-kamailio(22167) | |-kamailio(22168) | |-kamailio(22169) | |-kamailio(22170) | |-kamailio(22172) | |-kamailio(22173) | |-kamailio(22175) | |-kamailio(22176) | |-kamailio(22177) | |-kamailio(22178) | |-kamailio(22179) | |-kamailio(22180) | |-kamailio(22182) | |-kamailio(22184) | |-kamailio(22186) | |-kamailio(22188) | |-kamailio(22190) | |-kamailio(22192) | |-kamailio(22194) | |-kamailio(22196) | |-kamailio(22198) | |-kamailio(22200) | |-kamailio(22202) | |-kamailio(22204) | |-kamailio(22206) | |-kamailio(22208) | |-kamailio(22210) | |-kamailio(22212) | |-kamailio(22214) | |-kamailio(22216) | |-kamailio(22218) | |-kamailio(22220) | |-kamailio(22223) | |-kamailio(22225) | `-kamailio(22227) -- Yet, for some reason, some of the processes have two established DB connections from different ports: -- kamailio 22220 root 3u IPv4 189895303 0t0 TCP 127.0.0.1:46550->127.0.0.1:postgres (ESTABLISHED) kamailio 22220 root 86u IPv4 189895067 0t0 TCP 127.0.0.1:46458->127.0.0.1:postgres (ESTABLISHED) kamailio 22223 root 3u IPv4 189895315 0t0 TCP 127.0.0.1:46556->127.0.0.1:postgres (ESTABLISHED) kamailio 22223 root 86u IPv4 189895067 0t0 TCP 127.0.0.1:46458->127.0.0.1:postgres (ESTABLISHED) kamailio 22225 root 3u IPv4 189895321 0t0 TCP 127.0.0.1:46560->127.0.0.1:postgres (ESTABLISHED) kamailio 22225 root 86u IPv4 189895067 0t0 TCP 127.0.0.1:46458->127.0.0.1:postgres (ESTABLISHED) kamailio 22227 root 86u IPv4 189895067 0t0 TCP 127.0.0.1:46458->127.0.0.1:postgres (ESTABLISHED) -- ... while others don't ... -- kamailio 22111 root 3u IPv4 189894820 0t0 TCP 127.0.0.1:46326->127.0.0.1:postgres (ESTABLISHED) kamailio 22113 root 3u IPv4 189894828 0t0 TCP 127.0.0.1:46332->127.0.0.1:postgres (ESTABLISHED) kamailio 22115 root 3u IPv4 189894834 0t0 TCP 127.0.0.1:46334->127.0.0.1:postgres (ESTABLISHED) kamailio 22117 root 3u IPv4 189894842 0t0 TCP 127.0.0.1:46338->127.0.0.1:postgres (ESTABLISHED) kamailio 22119 root 3u IPv4 189894848 0t0 TCP 127.0.0.1:46340->127.0.0.1:postgres (ESTABLISHED) -- So, this gives rise to two questions in my mind: 1. I don't seem to understand the relationship between the number of database connection handles and the total number of child processes. I had always assumed that only SIP workers and other processes specialised into a role with possible "database involvement" (e.g. rtimer, async workers, etc.) would hold database connections. 2. What's going on in the second scenario such that some processes have two connections? Both servers running: -- # kamcmd -s /tmp/kamailio_ctl core.version kamailio 4.4.6 (x86_64/linux) becbde -- Insights much appreciated! -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

6 years, 9 months

What happens to calls when Kamailio restarts?

by Samuel F.

Hi, I have a question regarding calls and Kamailio restarts. Suppose Kamailio crashes (and started again), is restarted or failed over to a different server (same IP). What then happens with calls? Let's suppose the following scenario: - 1000 calls active on the machine - Some are in call setup, some are in call, some are in teardown phases - The proxy is stateful - The proxy forwards calls from B2BUA machines to an ITSP (outbound only) - Uses record-routing - Uses loose routing What will be the likely outcome of the restart with regards to the calls in the different phases and accounting for said calls? All the best, Samuel

6 years, 9 months

Subst_body M Audio

by Nicolas Breuer

Hello, I'm trying to replace the M part in the SDP Body. Seems not working as expected ( I changed the "s" part without problems ) Code : if ( subst_body('/(^m=.*)/m=testing of rewrite.\r/') ) { $var(s)=""; }; Here's the incoming body message c=IN IP4 217.112.180.235. t=0 0. m=audio 49152 RTP/AVP 8 9 18 101. a=rtpmap:8 PCMA/8000. a=rtpmap:9 G722/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. After subst. ( note the .10840 on the m line) c=IN IP4 217.112.180.10. t=0 0. m=testing of rewrite..10840 a=rtpmap:8 PCMA/8000. a=rtpmap:9 G722/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=nortpproxy:yes.

6 years, 9 months

issue sending http_async_client POST request

by Abdul Basit

Hi folks, I am using kamailio -v version: kamailio 5.0.2 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, 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 10:02:27 Jul 4 2017 with gcc 4.9.2 I was trying to send http POST request to my web server example.com following example Example 1.12. http_async_query() usage <https://www.kamailio.org/docs/modules/5.0.x/modules/http_async_client.html#…> https://www.kamailio.org/docs/modules/5.0.x/modules/http_async_client.html according to that we should send parameters in body like # POST $http_req(body) = "{'r_uri':'" + $rU + "', 'f_uri':'" + $fU + "'}"; http_async_query("http://example.com/test.php", "HTTP_REPLY"); But its not working out of the box as described with error message from server: INFO: <script>: route[HTTP_REPLY]: status 400 INFO: <script>: route[HTTP_REPLY]: body Insufficient parameters. I even tried adding additional parameters $http_req(hdr) = "Content-Type: application/x-www-form-urlencoded"; $http_req(method) = "POST"; But again it didn't work. I tried the alternative way which worked fine. # POST $http_req(body) = "r_uri=$rU&f_uri=$fU"; http_async_query("http://example.com/test.php", "HTTP_REPLY"); Is there any issue with documentation or i am missing something for POST request? -- regards, abdul basit | p: +92 32 1416 4196 | o: +92 30 0841 1445

6 years, 9 months

issue sending http_async_client POST request

by Abdul Basit

Hi folks, I am using I was trying to send http POST request to my web server example.com following example Example 1.12. http_async_query() usage <https://www.kamailio.org/docs/modules/5.0.x/modules/http_async_client.html#…> https://www.kamailio.org/docs/modules/5.0.x/modules/http_async_client.html according to that we should send parameters in body like # POST $http_req(body) = "{'r_uri':'" + $rU + "', 'f_uri':'" + $fU + "'}"; http_async_query("http://example.com/test.php", "HTTP_REPLY"); But its not working out of the box as described with error message from server: INFO: <script>: route[HTTP_REPLY]: status 400 INFO: <script>: route[HTTP_REPLY]: body Insufficient parameters. I even tried adding additional parameters $http_req(hdr) = "Content-Type: application/x-www-form-urlencoded"; $http_req(method) = "POST"; But again it didn't work. I tried the alternative way which worked fine. # POST $http_req(body) = "r_uri=$rU&f_uri=$fU"; http_async_query("http://example.com/test.php", "HTTP_REPLY"); Is there any issue with documentation or i am missing something for POST request? -- regards, abdul basit | p: +92 32 1416 4196 | o: +92 30 0841 1445

6 years, 9 months

Call is not placing in kamailio

by Logeshwaran G

Dear Team, I have installed Kamailio-5.0, and i have included subscriber table as well. Two users have successfully registered but cant able to place the call in between the users. Kindly help me for placing the call. Thanks in Advance, Logesh

6 years, 9 months

RTPProxy - lookup request failed

by Marian Piater

Hello, I have a problem with RTPProxy. Scenario: SS7 (PSTN) ---> ASTERISK BOX --> Kamailio --> UAC In case of incoming call from PSTN, when called party answer the call after 60 seconds of ringing, then the call is without audio and in this case I see in the log this message: Creating session Jul 11 11:24:32 b2b-voice-sipproxy-v3 rtpproxy[731]: INFO:handle_command: new session 766d0e006d8969d36c628e363ea7c3e1(a)upc.cz, tag as7a7c86ae;1 requested, type strong Jul 11 11:24:32 b2b-voice-sipproxy-v3 rtpproxy[731]: INFO:handle_command: new session on a port 52902 created, tag as7a7c86ae;1 Jul 11 11:24:32 b2b-voice-sipproxy-v3 rtpproxy[731]: INFO:handle_command: pre-filling caller's address with XXX.XXX.XXX.XXX:32740 Answer after approx 60 seconds Jul 11 11:25:40 b2b-voice-sipproxy-v3 rtpproxy[731]: INFO:handle_command: lookup request failed: session 766d0e006d8969d36c628e363ea7c3e1(a)upc.cz, tags as7a7c86ae;1/l0g9iusua2;1 not found Jul 11 11:25:40 b2b-voice-sipproxy-v3 rtpproxy[731]: INFO:handle_delete: forcefully deleting session 1 on ports 35196/36656 Kamailio log (answer) Jul 11 11:25:40 b2b-voice-sipproxy-v3 kamailio[5268]: INFO: <script>: UID:766d0e006d8969d36c628e363ea7c3e1@upc.cz -- ONREPLY_ROUTE: rtpproxy_manage(co) Jul 11 11:25:40 b2b-voice-sipproxy-v3 kamailio[5268]: ERROR: rtpproxy [rtpproxy.c:2536]: force_rtp_proxy(): incorrect port 0 in reply from rtp proxy It looks like there is somewhere 60 seconds session timeout. But I don't know where. When the call is answered during first 60 seconds, then everything is OK and we have both audio. Kamailio reply route configuration: onreply_route[REPLYROUTE] { # #-- On-replay block routing -- # xlog("L_INFO","UID:$ci -- ONREPLY_ROUTE1: $rm $si avp $avp(s:131) $avp(s:132)"); if(has_body("application/sdp")) { xlog("L_INFO","UID:$ci -- ONREPLY_ROUTE: rtpproxy_manage(co)"); rtpproxy_manage("co"); } if ((isflagset(FLT_NATS) || isbflagset(FLB_NATB)) && status=~"(183)|(2[0-9][0-9])"){ xlog("L_INFO","UID:$ci -- ONREPLY_ROUTE1: force_rtp_proxy"); append_hf("P-hint: onreply_route|force_rtp_proxy \r\n"); } if (isbflagset(FLB_NATB)) { xlog("L_INFO","UID:$ci -- ONREPLY_ROUTE1: P-hint: Onreply-route - fixcontact"); append_hf("P-hint: Onreply-route - fixcontact \r\n"); fix_nated_contact(); } exit; } Some parameters settings. modparam("rtpproxy", "rtpproxy_sock", "udp:127.0.0.1:7722") modparam("rtpproxy", "extra_id_pv", "$avp(extra_id)") modparam("rtpproxy", "rtpproxy_disable_tout", 20) modparam("rtpproxy", "rtpproxy_tout", 2) modparam("tm", "disable_6xx_block", 1) modparam("tm", "fr_timer", 5000) ## 5 seconds. modparam("tm", "restart_fr_on_each_reply", 0) modparam("tm", "auto_inv_100_reason", "Trying") modparam("dialog", "dlg_flag", 4) modparam("dialog", "rr_param", "rtp") modparam("dialog", "default_timeout", 7230) modparam("dialog", "dlg_match_mode", 1) modparam("dialog", "db_mode", 1) modparam("dialog", "enable_stats", 1) modparam("dialog", "send_bye", 1) modparam("dialog", "lreq_callee_headers", "TH: dlh\r\n") modparam("rr", "enable_full_lr", 1) modparam("rr", "append_fromtag", 1) modparam("rr", "enable_double_rr", 1) RTPproxy is installed from Debian package: /usr/bin/rtpproxy -s udp:127.0.0.1 7722 -u rtpproxy rtpproxy -p /var/run/rtpproxy/rtpproxy.pid -F -l XXX.XXX.XXX.XXX -d DBUG LOG_LOCAL0 Any advice? Thanks

6 years, 9 months

Re: [SR-Users] Setup IMS core Network When Network behind nat

by Mojtaba

Hi. I found where was my problem. I had a misunderestanding. I used public domaim as outbound proxy and i could register to ims. On 11 Jul 2017 15:00, "Mojtaba" <mespio(a)gmail.com> wrote: > Hi Daniel. > Let me describe more clearly the network. Let me suppose these > configurations: > Private IMS Domain: kamailio0ims.test (192.168.100.200) > username: bob(a)kamailio-ims.test > secret: bob > outboundproxy: pcscf.kamailio-ims.test (192.168.100.101) > With these informations, all things works correctly. > Now suppose we have one public IP with predefined > domain(sbc.ims-domain.com) that is set on PCSCF.(This node has two ip > address, one private ip and on public ip), > How can the bob register to network like as before?because the domain > sbc.ims-domain.com is not validate on IMS network. > should i use the sems-sbc? becuase in this situation the private > domain is not reachables. > If it is needed, let me to describe more. > Thanks > > > > On Tue, Jul 11, 2017 at 2:24 PM, Daniel-Constantin Mierla > <miconda(a)gmail.com> wrote: > > Hello, > > > > do you want the entire platform to be behind a single public ip, or each > > node in the network to run on a private ip but have also a public ip > > associated? > > > > Cheers, > > Daniel > > > > > > On 11.07.17 11:31, Mojtaba wrote: > >> Hello, I am working on IMS core network. In this network we have these > >> node with private IP: > >> P-CSCF: 192.168.100.101(pcscf.kamailio-ims.test) > >> I-CSCF: 192.168.100.102(icscf.kamailio-ims.test) > >> S-CSCF: 192.168.100.103(scscf.kamailio-ims.test) > >> HSS: 192.168.100.200(hss.kamailio-ims.test) > >> I have two default users (bob and alice) and all things right great. > >> Now i want use this network with one public IP behind nat. Let me know > >> What should i do? > >> In one way i could use SEMS-SBC and set public IP on it, How should i > >> config sems-sbc to work correctly? > >> Thanks.With Regads. > >> M.ES.S > >> > >> _______________________________________________ > >> Kamailio (SER) - Users Mailing List > >> sr-users(a)lists.kamailio.org > >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > > -- > > Daniel-Constantin Mierla > > www.twitter.com/miconda -- www.linkedin.com/in/miconda > > Kamailio Advanced Training - www.asipto.com > > Kamailio World Conference - www.kamailioworld.com > > > > > > -- > --Mojtaba Esfandiari.S >

6 years, 9 months

New Diameter IMS Module : can we use it as SWx interface

by Igor Potjevlesch

Dear Kamailio users, Recently has been added to Kamailio two new modules : CDP and CDP_AVP There is not the TS 29.273 in it but I wanted to know if we can use it to emulate SWx interface? or add it with a non-hardcoded solution? I have seen the kamailio conference online and one session told about emulate IMS HSS with those two modules. Is someone tried to do it and want to share is experience with me ? Some DIAMETER functions in these modules are closed from the SWx. Best regards Igor Potjevlesch --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus

6 years, 9 months

← Newer
1
2
3
4
5
6
7
8
9
10
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 July 2017