From jayesh1017 at gmail.com Wed Oct 1 17:15:27 2014 From: jayesh1017 at gmail.com (Jayesh Nambiar) Date: Wed, 1 Oct 2014 20:45:27 +0530 Subject: [OpenSIPS-Users] Have one registration contact per device in usrloc Message-ID: Hi, I am trying to solve a problem of having one registration per AOR per device. So user 1234 can register from device A, device B and device C. But the user 1234 should not have multiple contacts from device A alone. At times when the device loses network, proxy doesn't receive de-register and the contact stays in opensips till its expiry time. So the same device is thus capable of creating multiple contacts. I could solve this by using "fc1" flag while doing a save("location") but I need multiple registrations to be allowed from different devices !! So is there a way where while doing a save("location"), I set some sort of device id along with it such that I identify and overwrite the existing contact only if the registration comes from same device-id or else add it up for parallel forking. Do let me know if I make sense here and there's a solution to this. Thanks for any suggestions and directions. Thanks, --- Jayesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From gn62 at gmx.us Wed Oct 1 19:22:24 2014 From: gn62 at gmx.us (Gary Nyquist) Date: Wed, 1 Oct 2014 19:22:24 +0200 Subject: [OpenSIPS-Users] (no subject) Message-ID: An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Oct 1 20:56:23 2014 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 01 Oct 2014 21:56:23 +0300 Subject: [OpenSIPS-Users] [IMPORTANT] Shellshock bash vulnerability and OpenSIPS Message-ID: <542C4E57.6070409@opensips.org> Hello all, The following email addresses a serious security issue (10/10 note on severity) which may/may not affect existing OpenSIPS-based platforms. [1] The issue was disclosed in September and is commonly named "Shellshock". You can read all about it on Wikipedia [2]. Long story short, it is a GNU Bash vulnerability in the code which handles environment variables. It also seems that under the "right conditions", any version of an OpenSIPS server can be vulnerable to this exploit. The following are the "right conditions": * your /bin/sh is vulnerable to Shellshock. You can test this with the following command: env x='() { :;}; echo vulnerable' bash -c 'echo this is a test' * your OpenSIPS uses the "exec" module * you have not disabled the "setvars" modparam of exec [3] If *all* of the above conditions are true, then you are vulnerable to some cleverly crafted INVITE requests. An attacker could remotely execute code with the privileges of your OpenSIPS daemon user! Ways to fix the issue (*any* of them is enough): * upgrade your bash shell to a non-vulnerable version * if you are not using the environment variables in your exec scripts, then skip them: modparam("exec", "setvars", 0) Note on broken backwards-compatibility: We have disabled the "setvars" parameter by default in all supported OpenSIPS versions. If you were using the environment variables in your exec scripts, make sure you update your OpenSIPS script and bash shell after performing an upgrade to the daily OpenSIPS builds. [1]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271 [2]: http://en.wikipedia.org/wiki/Shellshock_(software_bug) [3]: http://www.opensips.org/html/docs/modules/1.12.x/exec.html#id248413 Best regards, -- Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From SVacaroaia at medavail.com Wed Oct 1 21:44:34 2014 From: SVacaroaia at medavail.com (Steven Vacaroaia) Date: Wed, 1 Oct 2014 19:44:34 +0000 Subject: [OpenSIPS-Users] Opensips - cannot re-register expired extension Message-ID: <4e39fe6d77f34eedaf0ba567568d8394@EMAIL.corp.lan> Hello, I just started using Opensips so please indulge me if I ask questions with obvious answers After I register an extension and the default expiration time of 90 seconds is gone, the only way I can re-register is to restart opensips server It will be greatly appreciated if you could please let me know: - Where do I configure expiration time - Why I cannot re-register - Any useful commands/xlog settings that I can use to gather more details Many thanks Steven -------------- next part -------------- An HTML attachment was scrubbed... URL: From sauer.jens at yahoo.de Wed Oct 1 21:49:18 2014 From: sauer.jens at yahoo.de (Jens Sauer) Date: Wed, 1 Oct 2014 20:49:18 +0100 Subject: [OpenSIPS-Users] [IMPORTANT] Shellshock bash vulnerability and OpenSIPS In-Reply-To: <542C4E57.6070409@opensips.org> References: <542C4E57.6070409@opensips.org> Message-ID: <1412192958.26673.YahooMailNeo@web172303.mail.ir2.yahoo.com> Hello Chircu, thanks for the information. regards Jens Sauer Liviu Chircu schrieb am 20:56 Mittwoch, 1.Oktober 2014: Hello all, The following email addresses a serious security issue (10/10 note on severity) which may/may not affect existing OpenSIPS-based platforms. [1] The issue was disclosed in September and is commonly named "Shellshock". You can read all about it on Wikipedia [2]. Long story short, it is a GNU Bash vulnerability in the code which handles environment variables. It also seems that under the "right conditions", any version of an OpenSIPS server can be vulnerable to this exploit. The following are the "right conditions": * your /bin/sh is vulnerable to Shellshock. You can test this with the following command: env x='() { :;}; echo vulnerable' bash -c 'echo this is a test' * your OpenSIPS uses the "exec" module * you have not disabled the "setvars" modparam of exec [3] If all of the above conditions are true, then you are vulnerable to some cleverly crafted INVITE requests. An attacker could remotely execute code with the privileges of your OpenSIPS daemon user! Ways to fix the issue (any of them is enough): * upgrade your bash shell to a non-vulnerable version * if you are not using the environment variables in your exec scripts, then skip them: modparam("exec", "setvars", 0) Note on broken backwards-compatibility: We have disabled the "setvars" parameter by default in all supported OpenSIPS versions. If you were using the environment variables in your exec scripts, make sure you update your OpenSIPS script and bash shell after performing an upgrade to the daily OpenSIPS builds. [1]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271 [2]: http://en.wikipedia.org/wiki/Shellshock_(software_bug) [3]: http://www.opensips.org/html/docs/modules/1.12.x/exec.html#id248413 Best regards, -- Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrb3942 at gmail.com Thu Oct 2 00:25:07 2014 From: rrb3942 at gmail.com (Ryan Bullock) Date: Wed, 1 Oct 2014 15:25:07 -0700 Subject: [OpenSIPS-Users] Message compression in OpenSIPS 1.12 In-Reply-To: <542A8A40.8000306@opensips.org> References: <5405EF96.5080305@opensips.org> <5E61F049-702C-4DBB-896C-0D8CABFBF1FB@ag-projects.com> <5406E40D.7090006@opensips.org> <1412061982.23212.YahooMailNeo@web171805.mail.ir2.yahoo.com> <542A8A40.8000306@opensips.org> Message-ID: I think all the items proposed in the first section would be great additions. The items in the second look more implementation specific, but I can see the uses. I think that items 1a and 1b should also have the reverse options present as well. Normalize everything to long form and expand all headers. I think this would be great for interoperability as some older platforms struggle with short form (or mixed form) and consolidated headers. Also, the ability to specify all the options in section 1 on a dialog direction would also be great. I.E create_dialog("sL") would compact all headers to short form for the caller side and normalize everything to long form for the callee side. create_dialog("lS") would do the opposite. The idea here is that support for a format is going to be endpoint specific, so being able to set it once at dialog creation would be helpful. Regards, Ryan Bullock On Tue, Sep 30, 2014 at 3:47 AM, R?zvan Crainea wrote: > Hi, Yavari! > > Of course, this will also impact the performance, but I don't think it > will be something considerable, since we will not compress large amount of > data. > Our current tests show that for a 1024 bytes long buffer > compression/decompression time takes less than 200us for compression and > 25us for decompression on a comodity computer. Since this will only be done > on edge nodes, I don't think it has such a big impact on the platform. > > Best regards, > > R?zvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 09/30/2014 10:26 AM, H Yavari wrote: > > Hi to all, > This is an amazing idea, but I have a question about the performance, the > compression/decompression process is not any bottleneck for the system > performance? or any effect on process power? > > Regards, > H.Yavari > > ------------------------------ > > On 03.09.2014 11:59, Sa?l Ibarra Corretg? wrote: > > Hi Razvan, > > > > On 02 Sep 2014, at 18:25, R?zvan Crainea wrote: > > > >> 2)Compressing the SIP message (using gzip). The idea is to take the SDP > body and several headers that are not used in the routing logic, compress > them, apply a base64 transformation and add to the message's body. A use > case for this is a platform that has several edge servers (SBCs) and a few > core instances - when entering the platform the message compression should > be applied and then sent to the core servers. Inside the core networks, the > messages should be carried in the compressed format to reduce the > bandwidth. When leaving the network, the message has to be decompressed and > forwarded to the next gateway without any compression, since the other > equipments might not understand them. > >> There will be several functions exported in the script: > >> > >> a) compress_msg("1","Header1|Header2"); compresses the body of the > message and listed headers > >> b) decompress_msg(); decompress both headers and body > >> > >> What do you think about this approach? Is this something you find > useful? Since we don't have a final decision for this topic, we are looking > for more input from you guys.Anybody is welcome to throw any kind of useful > feedback on this matter, so don't be shy! > >> > > > > IIRC this is not standard, and Apple uses it somewhere on their FaceTime > implementation. Kamailio has it and someone was working on a patch for > PJSIP, but other than that I?m not sure how useful it is, servers could use > TCP between them. > It is not indeed, but the main idea is to first help you with better > handling traffic inside your network (which may be up to 3 or 4 OpenSIPS > boxes when you have a distributed platform) ; handling means bandwidth > and processing as parsing SIP messages - like headers (maybe 20) or body > you do not care about and you just want to carry through without a need > to parse and look. > > And maybe in the future it will be some progress into > standardization....for now I see the real need for it (at least for me:) ). > > Regards, > Bogdan > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mespio at gmail.com Thu Oct 2 09:53:51 2014 From: mespio at gmail.com (mojtaba esfandiari) Date: Thu, 2 Oct 2014 00:53:51 -0700 (PDT) Subject: [OpenSIPS-Users] Opensips - cannot re-register expired extension In-Reply-To: <4e39fe6d77f34eedaf0ba567568d8394@EMAIL.corp.lan> References: <4e39fe6d77f34eedaf0ba567568d8394@EMAIL.corp.lan> Message-ID: <1412236431352-7593711.post@n2.nabble.com> Hi, Use save("location","f") in Register. With Regards.Mojtaba -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Opensips-cannot-re-register-expired-extension-tp7593707p7593711.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From razvan at opensips.org Thu Oct 2 10:01:31 2014 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Thu, 02 Oct 2014 11:01:31 +0300 Subject: [OpenSIPS-Users] event_rabbitmq sending errors In-Reply-To: References: Message-ID: <542D065B.6030509@opensips.org> Hi, Gary! That's the only error you see in the logs related to raise_event()? What version of OpenSIPS you're using? Have you tried setting the heartbeat module parameter[1] to 1? [1] http://www.opensips.org/html/docs/modules/1.12.x/event_rabbitmq#id293418 PS: please add a relevant subject when starting a new thread. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 10/01/2014 08:22 PM, Gary Nyquist wrote: > Hi, > I am using the "event_rabbitmq Module" to "raise_event". > It works fine. > If "raise_event" is not used for a long time, perhaps the MQ socket is > getting closed. > The following message is appearing in the log: > ERROR:event_rabbitmq:rmq_process: cannot send message > What is a good way to keep the MQ connection alive? > Any ideas? > Regards > -Gary > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at hul.me.uk Thu Oct 2 10:14:13 2014 From: jon at hul.me.uk (Jonathan Hulme) Date: Thu, 2 Oct 2014 09:14:13 +0100 Subject: [OpenSIPS-Users] event_rabbitmq sending errors In-Reply-To: <542D065B.6030509@opensips.org> References: <542D065B.6030509@opensips.org> Message-ID: <000c01cfde18$da28ebd0$8e7ac370$@me.uk> I also get this same issue, I have placed a raise_event inside the timer route, this works for me, although it wish the problem was fixed in rabbitmq module directly, as rarely it still disconnects and does not reconnect. (1.11.2 with hb param) Regards Jonathan From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea Sent: 02 October 2014 09:02 To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] event_rabbitmq sending errors Hi, Gary! That's the only error you see in the logs related to raise_event()? What version of OpenSIPS you're using? Have you tried setting the heartbeat module parameter[1] to 1? [1] http://www.opensips.org/html/docs/modules/1.12.x/event_rabbitmq#id293418 PS: please add a relevant subject when starting a new thread. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 10/01/2014 08:22 PM, Gary Nyquist wrote: Hi, I am using the "event_rabbitmq Module" to "raise_event". It works fine. If "raise_event" is not used for a long time, perhaps the MQ socket is getting closed. The following message is appearing in the log: ERROR:event_rabbitmq:rmq_process: cannot send message What is a good way to keep the MQ connection alive? Any ideas? Regards -Gary _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Oct 2 18:45:50 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 02 Oct 2014 19:45:50 +0300 Subject: [OpenSIPS-Users] including auth nonce header in next hop In-Reply-To: References: <5412F809.5090009@opensips.org> <54193A11.4070502@opensips.org> Message-ID: <542D813E.1010209@opensips.org> Hello Tito, Simply use the setbflag() functions: http://www.opensips.org/Documentation/Script-CoreFunctions-1-11#toc21 http://www.opensips.org/Documentation/Script-CoreFunctions-1-11#toc50 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 24.09.2014 22:11, Tito Cumpen wrote: > Bogdan, > > > After reconsidering the requirements I find the easiest thing to do > would be to set a flag on the branch during its creation and remove > the header in the per branch route. Although I cant seem to find > examples of setting a branch flag and referencing to it. Do you have > documentation or examples you can point me to? > > Thanks, > Tito > > On Wed, Sep 17, 2014 at 3:36 AM, Bogdan-Andrei Iancu > > wrote: > > Hi Tito, > > Instead of consume_credentials() you can simply do > remove_hf("Proxy-Authorization") - it does the same. > > Regarding the second part, I do not get the problem - in branch > route, if $du or $ru does not point to you, you want to remove the > credentials - what the is the problem here ? > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 17.09.2014 08:13, Tito Cumpen wrote: >> Bogdan, >> >> the branch route seems pretty limited in functionality. How would >> you compare a $du to allow credentials to traverse when they are >> going to a neighbor proxy? Also noticed you cant use >> consume_credentials(). >> >> if(uri != myself ) { >> >> #consume_credentials(); >> >> xlog("This is branch is not for me $ru"); >> >> >> } >> >> >> the above will not work since branches are going to aor entries >> along with neighbor proxies set like this: >> >> while loop{ >> >> avp_subst("$avp(myloc[$var(i)])", "/(.+)/\sip:\0/"); >> >> >> xlog("$avp(myloc[$var(i)])\n"); >> >> avp_pushto("$du","$avp(myloc[$var(i)])"); >> >> insert_hf("Subject:traversal\r\n", "p-hint"); >> >> append_branch(); >> >> >> } >> >> >> Much Appreciated, >> >> Tito >> >> On Fri, Sep 12, 2014 at 5:45 PM, Tito Cumpen > > wrote: >> >> Thanks Bogdan, >> >> I found this shortly after I am now allowing calls from >> neighbor proxies to enter if the ret code is only 3 stale. >> Thanks for your suggestion on handling this in branch route I >> will now check if $du (neighbor) proxy is the branch hop in >> order to allow credentials to linger or be removed. >> >> >> >> On Fri, Sep 12, 2014 at 9:41 AM, Bogdan-Andrei Iancu >> > wrote: >> >> Hi Tito, >> >> If you do not to "consume credentials" after auth, the >> credentials will stay in your requests and they will be >> forwarded to the next hop (this is what you want, right ?). >> >> You can use branch_route[] to remove the credentials in a >> per branch manner . >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> On 10.09.2014 23:59, Tito Cumpen wrote: >>> Group, >>> >>> >>> What is the adequate way to include or insert nonce >>> response after a proxy challenge? >>> I am forwarding invites to local and remote locations by >>> forking. The remote proxy checks againsts the same db >>> for authentication. Therefore I would to include the >>> proxy authorization header when forwarding the invite to >>> the remote locations. Currently I am being sent a 407 by >>> the remote proxy which consequently kills ends the branch. >>> >>> >>> Thanks, >>> Tito >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gn62 at gmx.us Thu Oct 2 22:36:41 2014 From: gn62 at gmx.us (Gary Nyquist) Date: Thu, 2 Oct 2014 22:36:41 +0200 Subject: [OpenSIPS-Users] event_rabbitmq sending errors In-Reply-To: <542D065B.6030509@opensips.org> References: , <542D065B.6030509@opensips.org> Message-ID: R?zvan, Yes, that's the only error showing up (related to rabbitmq). [...]# opensips -V version: opensips 1.11.2-tls (x86_64/linux) flags: STATS: On, USE_IPV6, USE_TCP, USE_TLS, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. git revision: 5708ad4 main.c compiled on 19:10:09 Jul 16 2014 with gcc 4.4.7 Tried with setting the heartbeat module parameter to 1. No change :( Best Regards, - Gary Sent:?Thursday, October 02, 2014 at 4:01 AM From:?"R?zvan Crainea" To:?users at lists.opensips.org Subject:?Re: [OpenSIPS-Users] event_rabbitmq sending errors Hi, Gary! That's the only error you see in the logs related to raise_event()? What version of OpenSIPS you're using? Have you tried setting the heartbeat module parameter[1] to 1? [1] http://www.opensips.org/html/docs/modules/1.12.x/event_rabbitmq#id293418 PS: please add a relevant subject when starting a new thread. Best regards, R?zvan Crainea OpenSIPS Solutionswww.opensips-solutions.com[http://www.opensips-solutions.com] On 10/01/2014 08:22 PM, Gary Nyquist wrote: Hi, ? I am using the "event_rabbitmq Module" to "raise_event". It works fine. ? If "raise_event" is not used for a long time, perhaps the MQ socket is getting closed. The following message is appearing in the log: ERROR:event_rabbitmq:rmq_process: cannot send message ? What is a good way to keep the MQ connection alive? Any ideas? ? Regards -Gary? ? ? _______________________________________________ Users mailing listUsers at lists.opensips.org[Users at lists.opensips.org]http://lists.opensips.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users[http://lists.opensips.org/cgi-bin/mailman/listinfo/users] From razvan at opensips.org Fri Oct 3 11:09:28 2014 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Fri, 03 Oct 2014 12:09:28 +0300 Subject: [OpenSIPS-Users] event_rabbitmq sending errors In-Reply-To: References: , <542D065B.6030509@opensips.org> Message-ID: <542E67C8.80309@opensips.org> And what is the version of the rabbitmq library? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 10/02/2014 11:36 PM, Gary Nyquist wrote: > R?zvan, > > Yes, that's the only error showing up (related to rabbitmq). > > [...]# opensips -V > version: opensips 1.11.2-tls (x86_64/linux) > flags: STATS: On, USE_IPV6, USE_TCP, USE_TLS, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 > poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. > git revision: 5708ad4 > main.c compiled on 19:10:09 Jul 16 2014 with gcc 4.4.7 > > Tried with setting the heartbeat module parameter to 1. > No change :( > > Best Regards, > - Gary > > > > Sent: Thursday, October 02, 2014 at 4:01 AM > From: "R?zvan Crainea" > To: users at lists.opensips.org > Subject: Re: [OpenSIPS-Users] event_rabbitmq sending errors > > Hi, Gary! > > That's the only error you see in the logs related to raise_event()? > What version of OpenSIPS you're using? Have you tried setting the heartbeat module parameter[1] to 1? > > [1] http://www.opensips.org/html/docs/modules/1.12.x/event_rabbitmq#id293418 > > PS: please add a relevant subject when starting a new thread. > > Best regards, > R?zvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com[http://www.opensips-solutions.com] > On 10/01/2014 08:22 PM, Gary Nyquist wrote: > > Hi, > > I am using the "event_rabbitmq Module" to "raise_event". > It works fine. > > If "raise_event" is not used for a long time, perhaps the MQ socket is getting closed. > The following message is appearing in the log: > ERROR:event_rabbitmq:rmq_process: cannot send message > > What is a good way to keep the MQ connection alive? > Any ideas? > > Regards > -Gary > _______________________________________________ > Users mailing listUsers at lists.opensips.org[Users at lists.opensips.org]http://lists.opensips.org/cgi-bin/mailman/listinfo/users > _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users[http://lists.opensips.org/cgi-bin/mailman/listinfo/users] > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From bogdan at opensips.org Fri Oct 3 13:19:28 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 03 Oct 2014 14:19:28 +0300 Subject: [OpenSIPS-Users] Detecting retransmissions of replies In-Reply-To: <005d01cfdc96$598c5d50$0ca517f0$@gmail.com> References: <005d01cfdc96$598c5d50$0ca517f0$@gmail.com> Message-ID: <542E8640.4000804@opensips.org> HiMickael, No, there is none. Usually this is not something useful (in that route) - may I ask what you are trying to do ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 30.09.2014 13:07, Mickael Marrache wrote: > > Hi, > > Is there a way to detect retransmissions of replies in a reply route? > > Thanks, > > Mickael > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Fri Oct 3 13:20:28 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 03 Oct 2014 14:20:28 +0300 Subject: [OpenSIPS-Users] +sip.instance parameter is missing in 200 OK for REGISTER In-Reply-To: <1412080436115-7593676.post@n2.nabble.com> References: <1411578172569-7593626.post@n2.nabble.com> <1412080436115-7593676.post@n2.nabble.com> Message-ID: <542E867C.5050504@opensips.org> Hi, Please post the request and reply for that REGISTER. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 30.09.2014 15:33, simbad wrote: > can any one please help. > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/sip-instance-parameter-is-missing-in-200-OK-for-REGISTER-tp7593626p7593676.html > Sent from the OpenSIPS - Users mailing list archive at Nabble.com. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From mickaelmarrache at gmail.com Fri Oct 3 13:43:00 2014 From: mickaelmarrache at gmail.com (Mickael Marrache) Date: Fri, 3 Oct 2014 14:43:00 +0300 Subject: [OpenSIPS-Users] Detecting retransmissions of replies In-Reply-To: <542E8640.4000804@opensips.org> References: <005d01cfdc96$598c5d50$0ca517f0$@gmail.com> <542E8640.4000804@opensips.org> Message-ID: <029d01cfdeff$300b2fe0$90218fa0$@gmail.com> Hi Bogdan, We initialize multiple AVPs in the reply route when replies are received, but sometimes we received retransmissions and the reply route is executed multiple times causing the information in the AVPs to be wrong. Regards, Mickael From: Bogdan-Andrei Iancu [mailto:bogdan at opensips.org] Sent: Friday, October 03, 2014 2:19 PM To: OpenSIPS users mailling list; mickaelmarrache at gmail.com Subject: Re: [OpenSIPS-Users] Detecting retransmissions of replies Hi Mickael, No, there is none. Usually this is not something useful (in that route) - may I ask what you are trying to do ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 30.09.2014 13:07, Mickael Marrache wrote: Hi, Is there a way to detect retransmissions of replies in a reply route? Thanks, Mickael _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From gn62 at gmx.us Fri Oct 3 17:42:02 2014 From: gn62 at gmx.us (Gary Nyquist) Date: Fri, 3 Oct 2014 17:42:02 +0200 Subject: [OpenSIPS-Users] event_rabbitmq sending errors In-Reply-To: <542E67C8.80309@opensips.org> References: , <542D065B.6030509@opensips.org> , <542E67C8.80309@opensips.org> Message-ID: librabbitmq-0.5.0 Best Regards, - Gary > Sent: Friday, October 03, 2014 at 5:09 AM > From: "R?zvan Crainea" > To: users at lists.opensips.org > Subject: Re: [OpenSIPS-Users] event_rabbitmq sending errors > > And what is the version of the rabbitmq library? > > Best regards, > > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 10/02/2014 11:36 PM, Gary Nyquist wrote: > > R?zvan, > > > > Yes, that's the only error showing up (related to rabbitmq). > > > > [...]# opensips -V > > version: opensips 1.11.2-tls (x86_64/linux) > > flags: STATS: On, USE_IPV6, USE_TCP, USE_TLS, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 > > poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. > > git revision: 5708ad4 > > main.c compiled on 19:10:09 Jul 16 2014 with gcc 4.4.7 > > > > Tried with setting the heartbeat module parameter to 1. > > No change :( > > > > Best Regards, > > - Gary > > > > > > > > Sent: Thursday, October 02, 2014 at 4:01 AM > > From: "R?zvan Crainea" > > To: users at lists.opensips.org > > Subject: Re: [OpenSIPS-Users] event_rabbitmq sending errors > > > > Hi, Gary! > > > > That's the only error you see in the logs related to raise_event()? > > What version of OpenSIPS you're using? Have you tried setting the heartbeat module parameter[1] to 1? > > > > [1] http://www.opensips.org/html/docs/modules/1.12.x/event_rabbitmq#id293418 > > > > PS: please add a relevant subject when starting a new thread. > > > > Best regards, > > R?zvan Crainea > > OpenSIPS Solutionswww.opensips-solutions.com[http://www.opensips-solutions.com] > > On 10/01/2014 08:22 PM, Gary Nyquist wrote: > > > > Hi, > > > > I am using the "event_rabbitmq Module" to "raise_event". > > It works fine. > > > > If "raise_event" is not used for a long time, perhaps the MQ socket is getting closed. > > The following message is appearing in the log: > > ERROR:event_rabbitmq:rmq_process: cannot send message > > > > What is a good way to keep the MQ connection alive? > > Any ideas? > > > > Regards > > -Gary > > _______________________________________________ > > Users mailing listUsers at lists.opensips.org[Users at lists.opensips.org]http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users[http://lists.opensips.org/cgi-bin/mailman/listinfo/users] > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From bogdan at opensips.org Fri Oct 3 19:04:35 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 03 Oct 2014 20:04:35 +0300 Subject: [OpenSIPS-Users] Detecting retransmissions of replies In-Reply-To: <029d01cfdeff$300b2fe0$90218fa0$@gmail.com> References: <005d01cfdc96$598c5d50$0ca517f0$@gmail.com> <542E8640.4000804@opensips.org> <029d01cfdeff$300b2fe0$90218fa0$@gmail.com> Message-ID: <542ED723.3030601@opensips.org> I guess you have onreply_avp_mode set to 1, right ? if so the onreply routes for a transaction will be run sequentially (no overlapping), so you can simply test for the AVP and if already set, do not set again. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 03.10.2014 14:43, Mickael Marrache wrote: > > Hi Bogdan, > > We initialize multiple AVPs in the reply route when replies are > received, but sometimes we received retransmissions and the reply > route is executed multiple times causing the information in the AVPs > to be wrong. > > Regards, > > Mickael > > *From:*Bogdan-Andrei Iancu [mailto:bogdan at opensips.org] > *Sent:* Friday, October 03, 2014 2:19 PM > *To:* OpenSIPS users mailling list; mickaelmarrache at gmail.com > *Subject:* Re: [OpenSIPS-Users] Detecting retransmissions of replies > > Hi Mickael, > > No, there is none. Usually this is not something useful (in that > route) - may I ask what you are trying to do ? > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 30.09.2014 13:07, Mickael Marrache wrote: > > Hi, > > Is there a way to detect retransmissions of replies in a reply route? > > Thanks, > > Mickael > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From discodog62 at aol.com Fri Oct 3 21:56:52 2014 From: discodog62 at aol.com (discodog62 at aol.com) Date: Fri, 3 Oct 2014 15:56:52 -0400 Subject: [OpenSIPS-Users] Radiusclient-ng Message-ID: <8D1AD5B4F781A4E-16F0-14289@webmail-vm088.sysops.aol.com> Does anyone no where I can get my hands on the source code for Radiusclient-ng or libradiusclient-ng2? Or is ther anything else I can use for compiling raius support in opensips? I use Archlinux. Thanks, James -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Fri Oct 3 22:28:04 2014 From: satish.txt at gmail.com (Satish Patel) Date: Fri, 3 Oct 2014 16:28:04 -0400 Subject: [OpenSIPS-Users] dispatcher not doing fail over itself In-Reply-To: <63758B6C-486C-4568-A949-DE10EF8A64B6@gmail.com> References: <5417E3E4.3020000@opensips.org> <5418640B.2050105@opensips.org> <54193884.2060801@opensips.org> <541999F2.7090705@opensips.org> <541BE96E.9080403@opensips.org> <20D5493C-5039-464D-B3BC-CDA798336311@gmail.com> <63758B6C-486C-4568-A949-DE10EF8A64B6@gmail.com> Message-ID: <2B0BF41A-D957-4AF3-A3D3-83807846C5C8@gmail.com> Bogdan, any update? -- Sent from my iPhone > On Sep 22, 2014, at 3:43 PM, Satish Patel wrote: > > Where are you? We need you :) lol > > -- > Sent from my iPhone > >> On Sep 20, 2014, at 8:18 AM, Satish Patel wrote: >> >> Hey any clue? I'm using 1.12 version. >> >> -- >> Sent from my iPhone >> >>> On Sep 19, 2014, at 4:29 AM, Bogdan-Andrei Iancu wrote: >>> >>> dst is null as there is no pending destination for failover. cnt is 1. >>> >>> Which OpenSIPS revision are you using ? >>> >>> Regards, >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>>> On 17.09.2014 19:04, Satish Patel wrote: >>>> I just trying to print $avp(271) $avp(272) and $avp(273) >>>> >>>> I am getting following output, why dst_avp is null ? and cnt_avp should be 2 right? >>>> >>>> dst_avp = >>>> grp_avp = 1 >>>> cnt_avp = 0 >>>> >>>> Notes: I have both Freeswitch instance running on same box but different port, do you think because of that it think it is single host? >>>> >>>> PARTITION:: default >>>> SET:: 1 >>>> URI:: sip:sip.example.com:5061 state=Active >>>> URI:: sip:sip.example.com:5071 state=Active >>>> >>>> >>>>> On Wed, Sep 17, 2014 at 11:06 AM, Satish Patel wrote: >>>>> Here you go >>>>> >>>>> >>>>> >>>>> >>>>> /sbin/opensips[28000]: Sending call to ===> Freeswitch >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: p=0x7f9ed01dd420, flags=0x0000 >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: #011#011#011name=<274> >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: #011#011#011id=<10> >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: #011#011#011val_int=<0> >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: p=0x7f9ed01df208, flags=0x0000 >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: #011#011#011name=<273> >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: #011#011#011id=<9> >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: #011#011#011val_int=<1> >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: p=0x7f9ed01e6518, flags=0x0002 >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: #011#011#011name=<272> >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: #011#011#011id=<12> >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: #011#011#011val_str=< / 0> >>>>> /sbin/opensips[28000]: dispatcher: Attempting to dispatch call to sip:182.xx.xx.xxx:5071 >>>>> /sbin/opensips[28005]: Inside dispatcher failure route >>>>> /sbin/opensips[28005]: ds_dispatcher > >>>>> /sbin/opensips[28005]: R-DISPATCHER-ROLLOVER:fU4SNHMvcNmnjW19gsSj0g..-S No more gateways in route set >>>>> >>>>> >>>>> On Wed, Sep 17, 2014 at 10:25 AM, Bogdan-Andrei Iancu wrote: >>>>>> Hi, >>>>>> >>>>>> As mentioned, place the avp_print() just after you did the ds_select_dst(), before relaying to the first destination. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Bogdan-Andrei Iancu >>>>>> OpenSIPS Founder and Developer >>>>>> http://www.opensips-solutions.com >>>>>> >>>>>>> On 17.09.2014 14:09, Satish Patel wrote: >>>>>>> Confirmed probing/inactive thing is working, >>>>>>> >>>>>>> Now problem is failover not working, ds_next_dst() not able to find next gateway and it says no more gateway available. If you check my script, i am calling failure route and inside it calling ds_next_dst() but you are saying do avp_print() on ds_select_dst() it won't print anything because after failure you are in failure route block. >>>>>>> >>>>>>> Please advice if my script has any issue. >>>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>> On Sep 17, 2014, at 3:30 AM, Bogdan-Andrei Iancu wrote: >>>>>>> >>>>>>>> Hi Satish, >>>>>>>> >>>>>>>> Use the "opensipsctl fifo ds_list" to see the status of the gws in realtime . Be sure that once a gw is in non-active state (probing or inactive), it will not be used again for routing. Just take care of doing the ds_next_dst() in order to jump to the next available gw. >>>>>>>> >>>>>>>> If you do the avp_print() after ds_select_dst(), you can see how many other gw are prepared to used in case of failover. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Bogdan-Andrei Iancu >>>>>>>> OpenSIPS Founder and Developer >>>>>>>> http://www.opensips-solutions.com >>>>>>>> >>>>>>>>> On 16.09.2014 21:02, Satish Patel wrote: >>>>>>>>> After doing couple of TEST look like its marking "Probing" for failed gateway but not auto failover to next gateway, i meant call get disconnect and i need to re-initiate call then all call goes to second active gateway.. >>>>>>>>> >>>>>>>>> I believe it should first mark gateway "Probing" and then fall-back to second gateway automatically instead of call disconnect and i am getting 503 error code on my SIP Phone. >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaandandin at yahoo.com Sat Oct 4 10:18:07 2014 From: kaandandin at yahoo.com (Kaan Dandin) Date: Sat, 4 Oct 2014 01:18:07 -0700 Subject: [OpenSIPS-Users] RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE Message-ID: <1412410687.9891.YahooMailNeo@web121504.mail.ne1.yahoo.com> Hi all, I am making registration to the Open IMS nodes(192.168.2.3 and 192.168.2.5) simultaneously from IMS bench(192.168.2.11). Registration messages are going through OpenSIPS load balancer(192.168.2.141). Registration messages which are going to first Open IMS node(192.168.2.5) completed succesfully. But registration to second IMS node(192.168.2.3) is not completed successfully since t_relay() function in OpenSIPS load balancer is giving "DBG:tm:matching_3261: RFC3261 transaction matching failed" error and not passing the "Status: 401 Unauthorized - Challenging the UE (0 bindings)" messages to IMS bench. Below please find wireshark log and opensips logs in debug level=6. Do you have any idea for this problem. BR, Kaan o. Time Source Destination Protocol Info 55 1.186495 192.168.2.11 192.168.2.141 SIP Request: REGISTER sip:open-ims.test 56 1.188443 192.168.2.141 192.168.2.3 SIP Request: REGISTER sip:open-ims.test 57 1.189001 192.168.2.141 192.168.2.5 SIP Request: REGISTER sip:open-ims.test 58 1.215792 192.168.2.5 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) 59 1.216974 192.168.2.141 192.168.2.11 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) 60 1.217486 192.168.2.11 192.168.2.141 SIP Request: REGISTER sip:open-ims.test 61 1.218516 192.168.2.141 192.168.2.3 SIP Request: REGISTER sip:open-ims.test 62 1.218804 192.168.2.141 192.168.2.5 SIP Request: REGISTER sip:open-ims.test 63 1.233561 192.168.2.3 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) 64 1.241624 192.168.2.3 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) 65 1.246112 192.168.2.5 192.168.2.141 SIP Status: 200 OK - SAR succesful and registrar saved (1 bindings) 66 1.246919 192.168.2.141 192.168.2.11 SIP Status: 200 OK - SAR succesful and registrar saved (1 bindings) Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: xlog method: [REGISTER] totag: [] sipid: [192.168.2.11] messageid: [68] callid: [56-6888 at 192.168.2.11] callsequence: [2] Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:uri:has_totag: no totag Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: xlog_initialregister Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:comp_scriptvar: str 20 : 192.168.2.11 Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:t_newtran: transaction on entrance=0xffffffffffffffff Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:parse_headers: flags=ffffffffffffffff Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:get_hdr_field: content_length=0 Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:get_hdr_field: found end of header Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:parse_headers: flags=78 Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:t_lookup_request: start searching: hash=35746, isACK=0 Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:matching_3261: RFC3261 transaction matching failed Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:t_lookup_request: no transaction found Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:run_reqin_callbacks: trans=0x7fcda4739918, callback type 1, id 1 entered Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:run_reqin_callbacks: trans=0x7fcda4739918, callback type 1, id 0 entered Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:check_ip_address: params 192.168.2.11, 192.168.2.11, 0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mickaelmarrache at gmail.com Sun Oct 5 10:32:58 2014 From: mickaelmarrache at gmail.com (Mickael Marrache) Date: Sun, 5 Oct 2014 11:32:58 +0300 Subject: [OpenSIPS-Users] Multiple database backends in one script Message-ID: Hi, Does OpenSIPS support use of multiple database backends? For example, using db_mysql for loading information to be used in script and db_text for dialog persistence. A module that would like to access a database use the db_bind_mod function to bind to a db backend. This function looks for the first module that exports a command named db_bind_api. If multiple backends are used, such command would be exported by multiple module. Regards, Mickael -------------- next part -------------- An HTML attachment was scrubbed... URL: From mickaelmarrache at gmail.com Sun Oct 5 10:35:51 2014 From: mickaelmarrache at gmail.com (Mickael Marrache) Date: Sun, 5 Oct 2014 11:35:51 +0300 Subject: [OpenSIPS-Users] Multiple database backends in one script In-Reply-To: References: Message-ID: Sorry, ignore my question, I just seen the db_bind_api command is searched in the module defined by the specific URL. On Sun, Oct 5, 2014 at 11:32 AM, Mickael Marrache wrote: > Hi, > > Does OpenSIPS support use of multiple database backends? > > For example, using db_mysql for loading information to be used in script > and db_text for dialog persistence. > > A module that would like to access a database use the db_bind_mod function > to bind to a db backend. This function looks for the first module that > exports a command named db_bind_api. If multiple backends are used, such > command would be exported by multiple module. > > Regards, > Mickael > -------------- next part -------------- An HTML attachment was scrubbed... URL: From netcentrica at gmail.com Sun Oct 5 16:36:32 2014 From: netcentrica at gmail.com (Adam Raszynski) Date: Sun, 5 Oct 2014 16:36:32 +0200 Subject: [OpenSIPS-Users] [Paid support needed] Fix OpenSIPS configuration to add TCP support Message-ID: Hi All, I'm looking for paid support in fixing my opensips config file All interested OpenSIPS hackers are welcome: https://www.freelancer.pl/projects/Software-Architecture-Linux/Fix-OpenSIPS-configuration-add-TCP.html Hope that's good group, I've searched but didn't find better place to post Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From van_der_starre at compuserve.com Sun Oct 5 20:46:40 2014 From: van_der_starre at compuserve.com (Jaap van der Starre) Date: Sun, 05 Oct 2014 20:46:40 +0200 Subject: [OpenSIPS-Users] menuconfig-tool Message-ID: <54319210.1050709@compuserve.com> to Vlad Paiu I followed the video "2012-05-18.02 OpenSIPS Kick Start" At one time you go out of Menuconfig-tool using ^z into bash. Then you go back from bash to Menuconfig-tool again. How do you do that? Which key do I use to go back to Menuconfig ? --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From acmicrox at gmail.com Mon Oct 6 09:44:09 2014 From: acmicrox at gmail.com (microx) Date: Mon, 6 Oct 2014 00:44:09 -0700 (PDT) Subject: [OpenSIPS-Users] db_text for domain table Message-ID: <1412581449829-7593779.post@n2.nabble.com> Dear all, I use the db_text module for the dispatcher and domain tables. For the dispatcher table, it works successfully. However, for the domain table, the OpenSIP server always fails to read the domain table on startup. Please help to take a look what listed below. Thanks for any comment. Best wishes, Chen-Che Related part of the OpenSIPS config loadmodule "db_text.so" loadmodule "domain.so" modparam("db_text", "db_mode", 0) modparam("domain", "db_url", "text:///etc/opensips") modparam("domain", "domain_table", "domain") modparam("domain", "db_mode", 1) # Use caching (file)/etc/opensips/domain id(int) domain(str) last_modified(str,null) 1:siptest.com:: Log message DBG:db_text:dbt_load_file: loading file [/etc/opensips/domain] DBG:db_text:dbt_table_new: mtime is 1412576125 DBG:db_text:dbt_load_file: column[0] is INT! DBG:db_text:dbt_load_file: column[1] is STR! DBG:db_text:dbt_load_file: column[2] is STR! DBG:db_text:dbt_query: new res with 1 cols DBG:db_text:dbt_result_new: new res with 1 cols DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f14717152c8 DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7f14717155f8 DBG:core:db_allocate_rows: allocate 48 bytes for result rows and values at 0x7f1471715480 DBG:domain:reload_domain_table: Number of rows in domain table: 1 *ERROR:domain:reload_domain_table: Database problem* -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/db-text-for-domain-table-tp7593779.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From mickaelmarrache at gmail.com Mon Oct 6 10:59:59 2014 From: mickaelmarrache at gmail.com (Mickael Marrache) Date: Mon, 6 Oct 2014 11:59:59 +0300 Subject: [OpenSIPS-Users] Flow stops when branch is dropped Message-ID: Hi, What happens after drop() is called from a branch_route? In my case, I armed a failure route for the incoming INVITE in the request route and therefore, I would expect that the failure route would be called after drop() is called. However, I see the following error in the logs and the following reply is returned to the UAC. Oct 6 08:57:27 DBG:tm:pre_print_uac_request: dropping branch Oct 6 08:57:27 ERROR:tm:t_forward_nonack: failure to add branches SIP/2.0 500 Server error occurred (1/TM) I use the failure route to detect current transaction failure and try the next termination if there is. Thanks, Mickael -------------- next part -------------- An HTML attachment was scrubbed... URL: From laszlo at voipfreak.net Mon Oct 6 13:41:11 2014 From: laszlo at voipfreak.net (Laszlo) Date: Mon, 6 Oct 2014 13:41:11 +0200 Subject: [OpenSIPS-Users] [Paid support needed] Fix OpenSIPS configuration to add TCP support In-Reply-To: References: Message-ID: Hi Adam, Take a look at http://www.opensips.org/Community/Business On Sun, Oct 5, 2014 at 4:36 PM, Adam Raszynski wrote: > Hi All, > > I'm looking for paid support in fixing my opensips config file > > All interested OpenSIPS hackers are welcome: > > > https://www.freelancer.pl/projects/Software-Architecture-Linux/Fix-OpenSIPS-configuration-add-TCP.html > > Hope that's good group, I've searched but didn't find better place to post > > Regards > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- -- Kind regards, Laszlo Bekesi http://voipfreak.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Mon Oct 6 14:33:52 2014 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Mon, 06 Oct 2014 15:33:52 +0300 Subject: [OpenSIPS-Users] Radiusclient-ng In-Reply-To: <8D1AD5B4F781A4E-16F0-14289@webmail-vm088.sysops.aol.com> References: <8D1AD5B4F781A4E-16F0-14289@webmail-vm088.sysops.aol.com> Message-ID: <54328C30.5060501@opensips.org> Hi, James! Unfortunately the old link for radiusclient-ng no loger works and the PKGBUILD was not updated for Archlinux. You can get the libradiusclient-ng library from SourceForge[1], compile and install it manually. [1] http://sourceforge.net/projects/radiusclient-ng.berlios/ Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 10/03/2014 10:56 PM, discodog62 at aol.com wrote: > Does anyone no where I can get my hands on the source code for > Radiusclient-ng or libradiusclient-ng2? Or is ther anything else I > can use for compiling raius support in opensips? I use Archlinux. > > Thanks, > > James > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From eremina.net at gmail.com Mon Oct 6 15:01:49 2014 From: eremina.net at gmail.com (Pavel Eremin) Date: Mon, 6 Oct 2014 19:01:49 +0600 Subject: [OpenSIPS-Users] [Paid support needed] Fix OpenSIPS configuration to add TCP support In-Reply-To: References: Message-ID: Already make a bid as Erewin. 05.10.2014 20:36 ???????????? "Adam Raszynski" ???????: > Hi All, > > I'm looking for paid support in fixing my opensips config file > > All interested OpenSIPS hackers are welcome: > > > https://www.freelancer.pl/projects/Software-Architecture-Linux/Fix-OpenSIPS-configuration-add-TCP.html > > Hope that's good group, I've searched but didn't find better place to post > > Regards > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From levent.tinaz at sponsoracall.com Mon Oct 6 16:36:40 2014 From: levent.tinaz at sponsoracall.com (Levent Tinaz) Date: Mon, 6 Oct 2014 09:36:40 -0500 Subject: [OpenSIPS-Users] RabbitMQ Message-ID: Hi All, Collecting CDRs via rabbitMQ.., I am not clear about it. Do I need to raise the event E_ACC_CDR manually in the script ? or this should be done by ACC module automatically? If it is automatic how can I do that? I really appreciate if you share your ACC and RabbitMQ settings. Thanks. Levent Tinaz -------------- next part -------------- An HTML attachment was scrubbed... URL: From gn62 at gmx.us Mon Oct 6 22:07:57 2014 From: gn62 at gmx.us (Gary Nyquist) Date: Mon, 6 Oct 2014 22:07:57 +0200 Subject: [OpenSIPS-Users] How to route to voicemail on destination busy? Message-ID: Hi, OpenSIPS routes a call to a SIP device (destination). And (say) the device returns "486 BUSY" to OpenSIPS. Now the call needs to be routed to the Voice-Mail server (another SIP device). How to do it in opensips.cfg? Any ideas? Thanks. Best Regards, - Gary From a.dorantwyford at ivstel.com Tue Oct 7 02:24:31 2014 From: a.dorantwyford at ivstel.com (Alec Doran-Twyford) Date: Tue, 7 Oct 2014 11:24:31 +1100 Subject: [OpenSIPS-Users] ERROR:tm:t_check: INVITE reply cannot be parsed Message-ID: Hi all, I am getting this error "ERROR:tm:t_check: INVITE reply cannot be parsed" when someone makes a call though our system. I am not sure where it came from. I am just wondering if anyone know some common problem when this has happens? Alec Doran-Twyford | Support Engineer for IVSTel | | E-mail: a.dorantwyford at ivstel.com | Skype: AlecDoranTwyford | | Phone: +61 2 9288 8890 | Mob: +61 423 694 742 | | LinkedIn | -------------- next part -------------- An HTML attachment was scrubbed... URL: From gn62 at gmx.us Tue Oct 7 03:58:40 2014 From: gn62 at gmx.us (Gary Nyquist) Date: Tue, 7 Oct 2014 03:58:40 +0200 Subject: [OpenSIPS-Users] $T_fr_timeout and $T_fr_inv_timeout Message-ID: Hi, Is it possible to know (inside a failure_route[] block), which timeout caused to land up in the failure_route? # E.g. in the main route, I have: if(is_method("INVITE")){ ... ... $T_fr_timeout=8; $T_fr_inv_timeout=30; t_on_failure("1"); t_relay(); exit; } # And in failure_route: failure_route[1] { # How to know if $T_fr_timeout or $T_fr_inv_timeout caused this failure? } Any tips? Thanks. Best Regards, - Gary From simbad.k.m at gmail.com Tue Oct 7 07:35:23 2014 From: simbad.k.m at gmail.com (simbad) Date: Mon, 6 Oct 2014 22:35:23 -0700 (PDT) Subject: [OpenSIPS-Users] +sip.instance parameter is missing in 200 OK for REGISTER In-Reply-To: <542E867C.5050504@opensips.org> References: <1411578172569-7593626.post@n2.nabble.com> <1412080436115-7593676.post@n2.nabble.com> <542E867C.5050504@opensips.org> Message-ID: <1412660123319-7593809.post@n2.nabble.com> Hi Bogdan , Thank you for replying. Here is the the REGISTER request and its corresponding 200 OK. REGISTER sip:com.mydomain.net SIP/2.0 Call-Id: yl44SiUAAA at xxx.x.x.x CSeq: 2 REGISTER From: ;tag=rm44SiUBAA To: Via: SIP/2.0/TLS xxx.x.x.x:xxxx;branch=z9hG4bK1411213658669;keep Max-Forwards: 70 Contact: ;+sip.instance="";+g.oma.sip-im;+g.3gpp.cs-voice;+g.3gpp.iari-ref="urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.im,urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.ft,urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.ftthumb,urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.geopush,urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.geopullft,urn%3Aurn-7%3A3gpp-application.ims.iari.gsma-is";+g.gsma.rcs.ipcall;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";video;expires=3600 Supported: path,gruu P-Preferred-Identity: sip:+9197466xxxxx at com.mydomain.net User-Agent: IM-client/OMA1.0 local-build/version-not-set P-Access-Network-Info: IEEE-802.11n Allow: INVITE, ACK, BYE, CANCEL, NOTIFY, OPTIONS, MESSAGE Authorization: Digest username="+9197466xxxxx at com.mydomain.net",uri="sip:com.mydomain.net",algorithm=MD5,realm="com.mydomain.net",nonce="541d6978000000a7adc6e6abeb6386e32a37d652a9562296",response="839c0f7372fadb82250943de21ceff0b" Content-Length: 0 SIP/2.0 200 OK Call-Id: yl44SiUAAA at xxx.x.x.x CSeq: 2 REGISTER From: ;tag=rm44SiUBAA To: ;tag=da49f3d59ded0458f7cec35893ecbaba.2f5a Via: SIP/2.0/TLS xxx.x.x.x:xxxx;received=x.xx.xx.xxx;rport=54494;branch=z9hG4bK1411213658669;keep J-Via: SIP/2.0/TLS xxx.x.x.x:xxxx;branch=z9hG4bK1411213658669;keep=120 P-Associated-URI: , Contact: ;expires=3600;received="sip:x.xx.xx.xxx:xxxxx;transport=TLS" Server: My server SIP Proxy 1.10.1 Content-Length: 0 -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/sip-instance-parameter-is-missing-in-200-OK-for-REGISTER-tp7593626p7593809.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From bogdan at opensips.org Tue Oct 7 10:41:45 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 07 Oct 2014 11:41:45 +0300 Subject: [OpenSIPS-Users] OpenSIPS crashed after "out of pkg memory" In-Reply-To: <541005B3.7040404@opensips.org> References: <53B2D458.6030408@opensips.org> <53B679D2.5010000@opensips.org> <53BACD6A.30408@opensips.org> <53F398CD.3060901@opensips.org> <53F4BD2B.4070001@opensips.org> <5408AB2F.8090906@opensips.org> <540EDF49.7030508@opensips.org> <541005B3.7040404@opensips.org> Message-ID: <5433A749.2030209@opensips.org> Hello all, Just for the sake of completion, the memory leak was identified and fixed by Liviu . See: https://github.com/OpenSIPS/opensips/commit/e5ccde131eb72debd9aa400ced2e1e31bd61612d Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10.09.2014 11:02, Bogdan-Andrei Iancu wrote: > Hi Kevin, > > First just checking if: > - the "out of mem" was reported for pkg memory (and not for shm) > - you sent the SIGUSR1 signal to the process complaining about > lack of mem > > IF you look at the dump: > used= 1630504, used+overhead=4188560, free=5744 > but there are only 64 fragments with avg len < 100, so not more than > 100K or so.... it is a bit strange. I remember some fixes in that area > (where the stats for available mem were kept) - what exact version of > OpenSIPS are you using ? > > Thanks and regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 09.09.2014 15:56, Kevin Mathy wrote: >> Hi Bogdan, >> >> I've got now a memdump ! >> https://www.dropbox.com/s/5hb678r0ym9vtt1/memdump1.txt?dl=0 >> >> And if you need the list of the opensips processes running at the >> moment : >> https://www.dropbox.com/s/hqurr3ilamc0a0g/opensips_processes_list.txt?dl=0 >> >> I hope it'll be ok... If you need more things, I didn't have >> restarted the service yet, so I'm able to get other memdumps. >> >> Thanks for your help, >> >> Kevin >> >> >> * >> Bien cordialement, >> Best Regards, >> >> **Kevin MATHY* |**Ing?nieur VoIP >> * >> * >> >> 2014-09-09 13:06 GMT+02:00 Bogdan-Andrei Iancu > >: >> >> Hi Kevin, >> >> yes, that's the right way of getting a mem dump during runtime. >> Also you will automatically get one during the shutdown procedure. >> >> Best regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> >> >> > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Oct 7 11:15:24 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 07 Oct 2014 12:15:24 +0300 Subject: [OpenSIPS-Users] permission module In-Reply-To: <8D1A2751D8E6524-7D4-C315@webmail-vm077.sysops.aol.com> References: <8D1A2751D8E6524-7D4-C315@webmail-vm077.sysops.aol.com> Message-ID: <5433AF2C.4010801@opensips.org> Hi, Sorry for delay. After stopping OpenSIPS (and before starting it again), could you check what you have in the file ? are all the records there ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 20.09.2014 02:03, discodog62 at aol.com wrote: > Yes I have checked and I see the added record in the file. If I stop > and restart opensips then do a opensipsctl fifo address_dump I can > then see the 2 records. For the record I am using DBTEXT for my database. > > > -----Original Message----- > From: Bogdan-Andrei Iancu > To: OpenSIPS users mailling list ; > discodog62 > Sent: Fri, Sep 19, 2014 1:59 am > Subject: Re: [OpenSIPS-Users] permission module > > Hi, > > before doing the reload, can you check that you actually have the 2 > records in the "address" table ? It seems there is only one, according > to the reload logs: > Sep 18 16:52:45 [1738] DBG:permissions:reload_address_table: > number of rows in address table: 1 > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 19.09.2014 03:00, discodog62 at aol.com wrote: >> I am using opensips 1.11.2. When I add a new IP to the access list >> and then reload the newly added IP is not reloaded into memory. >> >> Here is what I am doing...... >> >> >> >> vma / # opensipsctl address show >> [1, 1, '192.168.2.5', 32, 5068, 'udp', '', 'James'] >> vma / # opensipsctl address fifo address_dump >> Sep 18 16:51:51 [1738] DBG:mi_fifo:mi_fifo_server: entered consume >> Sep 18 16:51:51 [1738] DBG:mi_fifo:mi_fifo_server: **** done consume >> Sep 18 16:51:51 [1738] DBG:mi_fifo:mi_fifo_server: done parsing the >> mi tree >> 97 <192.168.2.5,1, 5068, 1, NULL, James> >> vma / # opensipsctl address add 1 192.168.2.100 32 5060 udp Me >> Updated address, rows affected: 1 >> INFO: execute '/test/opensips/bin/opensipsctl address reload' to >> synchronize cache and database >> vma / # opensipsctl address show >> [1, 1, '192.168.2.5', 32, 5068, 'udp', '', 'James'] >> [2, 1, '192.168.2.100', 32, 5060, 'udp', '', 'Me'] >> vma / # opensipsctl fifo address_dump >> Sep 18 16:52:28 [1738] DBG:mi_fifo:mi_fifo_server: entered consume >> Sep 18 16:52:28 [1738] DBG:mi_fifo:mi_fifo_server: **** done consume >> Sep 18 16:52:28 [1738] DBG:mi_fifo:mi_fifo_server: done parsing the >> mi tree >> 97 <192.168.2.5,1, 5068, 1, NULL, James> >> vma / # opensipsctl address show >> [1, 1, '192.168.2.5', 32, 5068, 'udp', '', 'James'] >> [2, 1, '192.168.2.100', 32, 5060, 'udp', '', 'Me'] >> vma / # opensipsctl fifo address_reload >> Sep 18 16:52:45 [1738] DBG:mi_fifo:mi_fifo_server: entered consume >> Sep 18 16:52:45 [1738] DBG:mi_fifo:mi_fifo_server: **** done consume >> Sep 18 16:52:45 [1738] DBG:mi_fifo:mi_fifo_server: done parsing the >> mi tree >> Sep 18 16:52:45 [1738] DBG:db_text:dbt_db_get_table: cache or mtime >> succeeded for [address] >> Sep 18 16:52:45 [1738] DBG:db_text:dbt_query: new res with 8 cols >> Sep 18 16:52:45 [1738] DBG:db_text:dbt_result_new: new res with 8 cols >> Sep 18 16:52:45 [1738] DBG:core:db_new_result: allocate 48 bytes for >> result set at 0x7f39d69735d0 >> Sep 18 16:52:45 [1738] DBG:core:db_allocate_columns: allocate 224 >> bytes for result columns at 0x7f39d6974228 >> Sep 18 16:52:45 [1738] DBG:core:db_allocate_rows: allocate 272 bytes >> for result rows and values at 0x7f39d6974320 >> Sep 18 16:52:45 [1738] DBG:permissions:reload_address_table: number >> of rows in address table: 1 >> Sep 18 16:52:45 [1738] DBG:permissions:reload_address_table: Tuple >> <192.168.2.5, 1, 5068, 1, , James> inserted into address hash table >> Sep 18 16:52:45 [1738] DBG:core:db_free_columns: freeing result >> columns at 0x7f39d6974228 >> Sep 18 16:52:45 [1738] DBG:core:db_free_rows: freeing 1 rows >> Sep 18 16:52:45 [1738] DBG:core:db_free_row: freeing row values at >> 0x7f39d6974330 >> Sep 18 16:52:45 [1738] DBG:core:db_free_rows: freeing rows at >> 0x7f39d6974320 >> Sep 18 16:52:45 [1738] DBG:core:db_free_result: freeing result set at >> 0x7f39d69735d0 >> Sep 18 16:52:45 [1738] DBG:permissions:reload_address_table: address >> table reloaded successfully. >> vma / # opensipsctl fifo address_dump >> Sep 18 16:52:53 [1738] DBG:mi_fifo:mi_fifo_server: entered consume >> Sep 18 16:52:53 [1738] DBG:mi_fifo:mi_fifo_server: **** done consume >> Sep 18 16:52:53 [1738] DBG:mi_fifo:mi_fifo_server: done parsing the >> mi tree >> 97 <192.168.2.5,1, 5068, 1, NULL, James> >> vma / # opensipsctl address reloadshow >> [1, 1, '192.168.2.5', 32, 5068, 'udp', '', 'James'] >> [2, 1, '192.168.2.100', 32, 5060, 'udp', '', 'Me'] >> vma / # opensipsctl fifo debug 0 >> Sep 18 16:53:08 [1738] DBG:mi_fifo:mi_parse_tree: adding node <> ; >> val <0> >> Sep 18 16:53:08 [1738] DBG:mi_fifo:mi_parse_node: end of input tree >> Sep 18 16:53:08 [1738] DBG:mi_fifo:mi_fifo_server: done parsing the >> mi tree >> DEBUG:: 0 >> vma / # >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Oct 7 11:19:37 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 07 Oct 2014 12:19:37 +0300 Subject: [OpenSIPS-Users] Permission pattern In-Reply-To: References: Message-ID: <5433B029.7000805@opensips.org> Hi The "pattern" field is used as an extra matching key - once the matching based on src IP is done, you can enforce a regular expression (the "pattern") to match the message as text. In your scenario you do not need it. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 20.09.2014 16:09, Satish Patel wrote: > We are looking for IP auth but with accounting so I are planing to use tech prefix so customer will send call with some prefix and we will use it identify customer and bill that according > > I'm planing to use permission module and its DB table has "pattern" column I don't know what that pattern means? Do it match dialed URI pattern like 9999163638273 at example.com so if I want to filter it match 9999 to identify customer, should I use pattern field? > > Please clarify my doubt what that pattern column is and how I can full fill my requirement using it? > > -- > Sent from my iPhone > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > From bogdan at opensips.org Tue Oct 7 11:24:17 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 07 Oct 2014 12:24:17 +0300 Subject: [OpenSIPS-Users] [RFC] Deprecating mi_xmlrpc In-Reply-To: References: <1395238721.98475.YahooMailNeo@web122604.mail.ne1.yahoo.com> <5329D0A1.7020205@opensips.org> <532C59B6.3020706@opensips.org> Message-ID: <5433B141.8070201@opensips.org> Hi Ovidiu, We need to check once again if the mi_xmlrpc_ng can do a perfect replace for mi_xmlrpc - then we can obsolete in a blink of an eye. Are you aware of any pending issues in terms of backward compatibility ? PS: 1.12 is replaced by 2.1.0 - this is the version on trunk. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 25.09.2014 21:39, Ovidiu Sas wrote: > Are we ready to deprecate the mi_xmlrpc module now (for 1.12)? > > -ovidiu > > On Fri, Mar 21, 2014 at 11:24 AM, Bogdan-Andrei Iancu > wrote: >> Hello all, >> >> Bringing some light here : none of the xmlrpc implementations offer a >> structured reply >> >> From the "deprecation" point of view, we need to be sure: >> 1) the new mi_xmlrpc-ng module is a perfect substitute to the old one >> (providing the same unstructured reply) >> 2) the new mi_xmlrpc-ng module can also provide a structured reply - this >> definitely is something good for the future >> 3) OpenSIPS CP must be migrated (there are some things that need to be >> changed) to be compatible with both modules. >> >> Ovidiu (mi_xmlepc-ng) and Alex (opensips cp) are already heavily working to >> achieve the 3 goals above (many thanks to both of them). >> >> As noticed, the old mi_xmlrpc module was not deprecated in 1.11 - there are >> small but many things to be done to 100% ensure a smooth transition. Still >> this is work on progress and it will be done for next release. >> >> Many thanks, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> On 19.03.2014 21:55, Brett Nemeroff wrote: >> >> JSON+http sounds fantastic. It's like.. Starting to sound a like a RESTful >> server. >> >> I'm pretty sure others will jump on this. I know I would. >> -Brett >> >> >> >> On Wed, Mar 19, 2014 at 2:52 PM, Ovidiu Sas wrote: >>> The new module is built on top of the httpd module which has a >>> parameter to define the size of the buffer. If you need large >>> replies, then you need to adjust the buffer size accordingly. >>> http://www.opensips.org/html/docs/modules/devel/httpd >>> >>> That buffer is used by all modules that are sitting on top of the >>> httpd module, and there's one single process dedicated to all http >>> requests (no interference with SIP workers). >>> >>> Regards, >>> Ovidiu Sas >>> >>> On Wed, Mar 19, 2014 at 3:44 PM, Brett Nemeroff >>> wrote: >>>> I think there are some other issues with the size of the return data. I >>>> know >>>> for one that the mi_udp method has a buffer size limit. If you hit this >>>> limit I think it very quietly truncates the data. I can't 100% verify >>>> that >>>> since it's been a long time since I've used it. >>>> >>>> I believe you can paginate the data, but the problem is that you can't >>>> guarantee consistent results paginating data when the data is changing >>>> constantly. I'm not really sure on the background how this is handled; >>>> maybe >>>> a locked list or something.. but not sure if it'd affect performance at >>>> high >>>> velocity. Seems like something. somewhere would be affected.. either >>>> performance or accuracy. >>>> >>>> My point being, care needs to be taken that the method can produce >>>> consistent results; even for large datasets. If data is going to be >>>> truncated or we run out of SHM, there needs to not only be an error log, >>>> but >>>> I think the out put needs to say something as well. >>>> >>>> -Brett >>>> >>>> >>>> >>>> On Wed, Mar 19, 2014 at 2:37 PM, Dragomir Haralambiev >>>> >>>> wrote: >>>>> I totally share Brett's feelings! For me dlg_list_ctx over the new >>>>> module >>>>> causes lots of headaches when dialogs go over 100 or so. Structured >>>>> output >>>>> would resolve such problems. I am totally in for structured SJON format >>>>> too! >>>>> >>>>> >>>>> 2014-03-19 21:07 GMT+02:00 Brett Nemeroff : >>>>> >>>>>> I think the only reason for that is backwards compatibility with stuff >>>>>> written for the other mi interfaces. >>>>>> >>>>>> >>>>>> Honestly, my parsers for the MI output are ridiculous. It's really >>>>>> complicated and prone to failure. I'd like to know if others share my >>>>>> feeling here. >>>>>> >>>>>> For little things like "dr_reload" I don't really care. >>>>>> >>>>>> But for MI calls that return large amounts of user data, like >>>>>> dlg_list_ctx.. Parsing it is kind of ridiculous... Anyone else share >>>>>> this >>>>>> feeling? >>>>>> >>>>>> I personally would love to see it structured in JSON format. :) >>>>>> >>>>>> -Brett >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Mar 19, 2014 at 2:05 PM, Ovidiu Sas >>>>>> wrote: >>>>>>> Hello Brett, >>>>>>> >>>>>>> It is true that the structured output mode was not implemented in the >>>>>>> new module. >>>>>>> It seems that having the output in one big chunk is the preferred >>>>>>> method in the community. >>>>>>> >>>>>>> If there is a real demand for structured output, we can take a look >>>>>>> into >>>>>>> it. >>>>>>> >>>>>>> Regards, >>>>>>> Ovidiu Sas >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 19, 2014 at 1:56 PM, Brett Nemeroff >>>>>>> wrote: >>>>>>>> I'd like to see the new module to be a drop in replacement for the >>>>>>>> old >>>>>>>> one.. >>>>>>>> >>>>>>>> That being said... >>>>>>>> >>>>>>>> I was pretty surprised when I started down the path of the XMLRPC >>>>>>>> module >>>>>>>> that the reply isn't structured. It was just one big object. >>>>>>>> >>>>>>>> I'd like a selectable option on the module so that it either >>>>>>>> operates: >>>>>>>> 1. Legacy (one big output chunk) >>>>>>>> 2. Structured, parable for each output node. >>>>>>>> >>>>>>>> Really if we are talking "deprecating" we need to support the old >>>>>>>> method >>>>>>>> primarily or there will be a lot of broken code out there. >>>>>>>> >>>>>>>> -Brett >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Mar 19, 2014 at 12:15 PM, Bogdan-Andrei Iancu >>>>>>>> >>>>>>>> wrote: >>>>>>>>> The whole idea is not to :) >>>>>>>>> >>>>>>>>> But more tests need to be done. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Bogdan-Andrei Iancu >>>>>>>>> OpenSIPS Founder and Developer >>>>>>>>> http://www.opensips-solutions.com >>>>>>>>> >>>>>>>>> On 19.03.2014 17:39, Ali Pey wrote: >>>>>>>>> >>>>>>>>> Will this affect OpenSIPS-CP? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Ali Pey >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Mar 19, 2014 at 10:18 AM, Kneeoh wrote: >>>>>>>>>> I'm all for the deprecation as long as the documentation on the >>>>>>>>>> mi_xmlrpc_ng module is updated to a usable level. I find myself >>>>>>>>>> referencing >>>>>>>>>> the documentation for xmlrpc and hoping that it holds true for >>>>>>>>>> xmlrpc_ng. >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Users mailing list >>>>>>>>>> Users at lists.opensips.org >>>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Users mailing list >>>>>>>>> Users at lists.opensips.org >>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Users mailing list >>>>>>>>> Users at lists.opensips.org >>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Users mailing list >>>>>>>> Users at lists.opensips.org >>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> VoIP Embedded, Inc. >>>>>>> http://www.voipembedded.com >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Users mailing list >>>>>>> Users at lists.opensips.org >>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users at lists.opensips.org >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>> >>> >>> -- >>> VoIP Embedded, Inc. >>> http://www.voipembedded.com >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > From bogdan at opensips.org Tue Oct 7 12:11:02 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 07 Oct 2014 13:11:02 +0300 Subject: [OpenSIPS-Users] [RFC] Deprecating mi_xmlrpc In-Reply-To: References: <1395238721.98475.YahooMailNeo@web122604.mail.ne1.yahoo.com> <5329D0A1.7020205@opensips.org> <532C59B6.3020706@opensips.org> Message-ID: <5433BC36.6080403@opensips.org> The trunk (development code) was switched from 1.12.x to 2.1.x and you can get the URL from http://www.opensips.org/Downloads/Downloads#toc4. The trunk version is not for production. See the available versions here: http://www.opensips.org/About/AvailableVersions Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 26.09.2014 16:48, Satish Patel wrote: > Where is the trunk git URL to download latest 1.12.x? does it ready > for production? > > On Thu, Sep 25, 2014 at 2:39 PM, Ovidiu Sas > wrote: > > Are we ready to deprecate the mi_xmlrpc module now (for 1.12)? > > -ovidiu > > On Fri, Mar 21, 2014 at 11:24 AM, Bogdan-Andrei Iancu > > wrote: > > Hello all, > > > > Bringing some light here : none of the xmlrpc implementations > offer a > > structured reply > > > > From the "deprecation" point of view, we need to be sure: > > 1) the new mi_xmlrpc-ng module is a perfect substitute to the > old one > > (providing the same unstructured reply) > > 2) the new mi_xmlrpc-ng module can also provide a structured > reply - this > > definitely is something good for the future > > 3) OpenSIPS CP must be migrated (there are some things that need > to be > > changed) to be compatible with both modules. > > > > Ovidiu (mi_xmlepc-ng) and Alex (opensips cp) are already heavily > working to > > achieve the 3 goals above (many thanks to both of them). > > > > As noticed, the old mi_xmlrpc module was not deprecated in 1.11 > - there are > > small but many things to be done to 100% ensure a smooth > transition. Still > > this is work on progress and it will be done for next release. > > > > Many thanks, > > > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > > http://www.opensips-solutions.com > > > > On 19.03.2014 21:55, Brett Nemeroff wrote: > > > > JSON+http sounds fantastic. It's like.. Starting to sound a like > a RESTful > > server. > > > > I'm pretty sure others will jump on this. I know I would. > > -Brett > > > > > > > > On Wed, Mar 19, 2014 at 2:52 PM, Ovidiu Sas > > wrote: > >> > >> The new module is built on top of the httpd module which has a > >> parameter to define the size of the buffer. If you need large > >> replies, then you need to adjust the buffer size accordingly. > >> http://www.opensips.org/html/docs/modules/devel/httpd > >> > >> That buffer is used by all modules that are sitting on top of the > >> httpd module, and there's one single process dedicated to all http > >> requests (no interference with SIP workers). > >> > >> Regards, > >> Ovidiu Sas > >> > >> On Wed, Mar 19, 2014 at 3:44 PM, Brett Nemeroff > > > >> wrote: > >> > I think there are some other issues with the size of the > return data. I > >> > know > >> > for one that the mi_udp method has a buffer size limit. If > you hit this > >> > limit I think it very quietly truncates the data. I can't > 100% verify > >> > that > >> > since it's been a long time since I've used it. > >> > > >> > I believe you can paginate the data, but the problem is that > you can't > >> > guarantee consistent results paginating data when the data is > changing > >> > constantly. I'm not really sure on the background how this is > handled; > >> > maybe > >> > a locked list or something.. but not sure if it'd affect > performance at > >> > high > >> > velocity. Seems like something. somewhere would be affected.. > either > >> > performance or accuracy. > >> > > >> > My point being, care needs to be taken that the method can > produce > >> > consistent results; even for large datasets. If data is going > to be > >> > truncated or we run out of SHM, there needs to not only be an > error log, > >> > but > >> > I think the out put needs to say something as well. > >> > > >> > -Brett > >> > > >> > > >> > > >> > On Wed, Mar 19, 2014 at 2:37 PM, Dragomir Haralambiev > >> > > > >> > wrote: > >> >> > >> >> I totally share Brett's feelings! For me dlg_list_ctx over > the new > >> >> module > >> >> causes lots of headaches when dialogs go over 100 or so. > Structured > >> >> output > >> >> would resolve such problems. I am totally in for structured > SJON format > >> >> too! > >> >> > >> >> > >> >> 2014-03-19 21:07 GMT+02:00 Brett Nemeroff > >: > >> >> > >> >>> I think the only reason for that is backwards compatibility > with stuff > >> >>> written for the other mi interfaces. > >> >>> > >> >>> > >> >>> Honestly, my parsers for the MI output are ridiculous. It's > really > >> >>> complicated and prone to failure. I'd like to know if > others share my > >> >>> feeling here. > >> >>> > >> >>> For little things like "dr_reload" I don't really care. > >> >>> > >> >>> But for MI calls that return large amounts of user data, like > >> >>> dlg_list_ctx.. Parsing it is kind of ridiculous... Anyone > else share > >> >>> this > >> >>> feeling? > >> >>> > >> >>> I personally would love to see it structured in JSON format. :) > >> >>> > >> >>> -Brett > >> >>> > >> >>> > >> >>> > >> >>> On Wed, Mar 19, 2014 at 2:05 PM, Ovidiu Sas > > > >> >>> wrote: > >> >>>> > >> >>>> Hello Brett, > >> >>>> > >> >>>> It is true that the structured output mode was not > implemented in the > >> >>>> new module. > >> >>>> It seems that having the output in one big chunk is the > preferred > >> >>>> method in the community. > >> >>>> > >> >>>> If there is a real demand for structured output, we can > take a look > >> >>>> into > >> >>>> it. > >> >>>> > >> >>>> Regards, > >> >>>> Ovidiu Sas > >> >>>> > >> >>>> > >> >>>> On Wed, Mar 19, 2014 at 1:56 PM, Brett Nemeroff > > > >> >>>> wrote: > >> >>>> > I'd like to see the new module to be a drop in > replacement for the > >> >>>> > old > >> >>>> > one.. > >> >>>> > > >> >>>> > That being said... > >> >>>> > > >> >>>> > I was pretty surprised when I started down the path of > the XMLRPC > >> >>>> > module > >> >>>> > that the reply isn't structured. It was just one big object. > >> >>>> > > >> >>>> > I'd like a selectable option on the module so that it either > >> >>>> > operates: > >> >>>> > 1. Legacy (one big output chunk) > >> >>>> > 2. Structured, parable for each output node. > >> >>>> > > >> >>>> > Really if we are talking "deprecating" we need to > support the old > >> >>>> > method > >> >>>> > primarily or there will be a lot of broken code out there. > >> >>>> > > >> >>>> > -Brett > >> >>>> > > >> >>>> > > >> >>>> > > >> >>>> > On Wed, Mar 19, 2014 at 12:15 PM, Bogdan-Andrei Iancu > >> >>>> > > > >> >>>> > wrote: > >> >>>> >> > >> >>>> >> The whole idea is not to :) > >> >>>> >> > >> >>>> >> But more tests need to be done. > >> >>>> >> > >> >>>> >> Regards, > >> >>>> >> > >> >>>> >> Bogdan-Andrei Iancu > >> >>>> >> OpenSIPS Founder and Developer > >> >>>> >> http://www.opensips-solutions.com > >> >>>> >> > >> >>>> >> On 19.03.2014 17:39, Ali Pey wrote: > >> >>>> >> > >> >>>> >> Will this affect OpenSIPS-CP? > >> >>>> >> > >> >>>> >> Regards, > >> >>>> >> Ali Pey > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> On Wed, Mar 19, 2014 at 10:18 AM, Kneeoh > > wrote: > >> >>>> >>> > >> >>>> >>> I'm all for the deprecation as long as the > documentation on the > >> >>>> >>> mi_xmlrpc_ng module is updated to a usable level. I > find myself > >> >>>> >>> referencing > >> >>>> >>> the documentation for xmlrpc and hoping that it holds > true for > >> >>>> >>> xmlrpc_ng. > >> >>>> >>> > >> >>>> >>> _______________________________________________ > >> >>>> >>> Users mailing list > >> >>>> >>> Users at lists.opensips.org > >> >>>> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> _______________________________________________ > >> >>>> >> Users mailing list > >> >>>> >> Users at lists.opensips.org > >> >>>> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> _______________________________________________ > >> >>>> >> Users mailing list > >> >>>> >> Users at lists.opensips.org > >> >>>> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> >>>> >> > >> >>>> > > >> >>>> > > >> >>>> > _______________________________________________ > >> >>>> > Users mailing list > >> >>>> > Users at lists.opensips.org > >> >>>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> >>>> > > >> >>>> > >> >>>> > >> >>>> > >> >>>> -- > >> >>>> VoIP Embedded, Inc. > >> >>>> http://www.voipembedded.com > >> >>>> > >> >>>> _______________________________________________ > >> >>>> Users mailing list > >> >>>> Users at lists.opensips.org > >> >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> >>> > >> >>> > >> >>> > >> >>> _______________________________________________ > >> >>> Users mailing list > >> >>> Users at lists.opensips.org > >> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> >>> > >> >> > >> >> > >> >> _______________________________________________ > >> >> Users mailing list > >> >> Users at lists.opensips.org > >> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> >> > >> > > >> > > >> > _______________________________________________ > >> > Users mailing list > >> > Users at lists.opensips.org > >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> > > >> > >> > >> > >> -- > >> VoIP Embedded, Inc. > >> http://www.voipembedded.com > >> > >> _______________________________________________ > >> Users mailing list > >> Users at lists.opensips.org > >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > -- > VoIP Embedded, Inc. > http://www.voipembedded.com > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Oct 7 12:28:28 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 07 Oct 2014 13:28:28 +0300 Subject: [OpenSIPS-Users] a little question about uac module In-Reply-To: <340871411577448@web30o.yandex.ru> References: <340871411577448@web30o.yandex.ru> Message-ID: <5433C04C.3000300@opensips.org> Hello In failure route, after a successful uac_auth() call, you need to do t_relay() to send out the a new branch (for the INVITE) containing the credentials. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 24.09.2014 19:50, ?????? ????? wrote: > my schema: > > sip-server (1) <--> opensips (2) <---> internet > > I want to use opensips (2) as uac for registering on foreign sip-servers in the internet. > > my very simple config in part of uac-functionality: > > ######################################################################## > loadmodule "uac_auth.so" > ######################################################################## > modparam("uac_auth","auth_realm_avp","$avp(uac_realm)") > modparam("uac_auth","auth_username_avp","$avp(uac_username)") > modparam("uac_auth","auth_password_avp","$avp(uac_password)") > > ######################################################################## > loadmodule "uac.so" > ######################################################################## > > values for these AVPs i getting from some sources in my routing script. > > > When i receive 401 or 407, in failure_route i call uac_auth() function and in (as i see in debug) opensips generates authorization header. But after that opensips relaying 401(or 407)-response to originator of call (i.e. sip server (1)) and this call ends because originator doesn't want response to any type of authentication requests. > > Can opensips somehow generate INVITEs with authorization header (with uac and uac_auth modules functionality) by himself or it is impossible? > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From bogdan at opensips.org Tue Oct 7 12:29:26 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 07 Oct 2014 13:29:26 +0300 Subject: [OpenSIPS-Users] Needs Script Help In-Reply-To: References: Message-ID: <5433C086.3050804@opensips.org> Hello, Seehttp://www.opensips.org/Community/Business Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 26.09.2014 02:19, Levent Tinaz wrote: > Hello, > > Our company needs some help on our opensips servers. We are looking > for a contractor to assist us. Please let us know your rate and > availability at support at sponsoracall.com > > Thanks. > > Levent > > > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Oct 7 12:46:23 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 07 Oct 2014 13:46:23 +0300 Subject: [OpenSIPS-Users] +sip.instance parameter is missing in 200 OK for REGISTER In-Reply-To: <1412660123319-7593809.post@n2.nabble.com> References: <1411578172569-7593626.post@n2.nabble.com> <1412080436115-7593676.post@n2.nabble.com> <542E867C.5050504@opensips.org> <1412660123319-7593809.post@n2.nabble.com> Message-ID: <5433C47F.1060507@opensips.org> Hello , A registrar server stores the registered contact URIs (the those URIs are the one returned in the 200 OK). The "+sip.instance" is not part of the contact URI - it is actually a parameter of the Contact header, not a parameter of the Contact URI. This is way it is not saved. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 07.10.2014 08:35, simbad wrote: > Hi Bogdan , > > Thank you for replying. Here is the the REGISTER request and its > corresponding 200 OK. > > REGISTER sip:com.mydomain.net SIP/2.0 > Call-Id: yl44SiUAAA at xxx.x.x.x > CSeq: 2 REGISTER > From: ;tag=rm44SiUBAA > To: > Via: SIP/2.0/TLS xxx.x.x.x:xxxx;branch=z9hG4bK1411213658669;keep > Max-Forwards: 70 > Contact: > ;+sip.instance="";+g.oma.sip-im;+g.3gpp.cs-voice;+g.3gpp.iari-ref="urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.im,urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.ft,urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.ftthumb,urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.geopush,urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.geopullft,urn%3Aurn-7%3A3gpp-application.ims.iari.gsma-is";+g.gsma.rcs.ipcall;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";video;expires=3600 > Supported: path,gruu > P-Preferred-Identity: sip:+9197466xxxxx at com.mydomain.net > User-Agent: IM-client/OMA1.0 local-build/version-not-set > P-Access-Network-Info: IEEE-802.11n > Allow: INVITE, ACK, BYE, CANCEL, NOTIFY, OPTIONS, MESSAGE > Authorization: Digest > username="+9197466xxxxx at com.mydomain.net",uri="sip:com.mydomain.net",algorithm=MD5,realm="com.mydomain.net",nonce="541d6978000000a7adc6e6abeb6386e32a37d652a9562296",response="839c0f7372fadb82250943de21ceff0b" > Content-Length: 0 > > > > SIP/2.0 200 OK > Call-Id: yl44SiUAAA at xxx.x.x.x > CSeq: 2 REGISTER > From: ;tag=rm44SiUBAA > To: > ;tag=da49f3d59ded0458f7cec35893ecbaba.2f5a > Via: SIP/2.0/TLS > xxx.x.x.x:xxxx;received=x.xx.xx.xxx;rport=54494;branch=z9hG4bK1411213658669;keep > J-Via: SIP/2.0/TLS xxx.x.x.x:xxxx;branch=z9hG4bK1411213658669;keep=120 > P-Associated-URI: , > Contact: > ;expires=3600;received="sip:x.xx.xx.xxx:xxxxx;transport=TLS" > Server: My server SIP Proxy 1.10.1 > Content-Length: 0 > > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/sip-instance-parameter-is-missing-in-200-OK-for-REGISTER-tp7593626p7593809.html > Sent from the OpenSIPS - Users mailing list archive at Nabble.com. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From osas at voipembedded.com Tue Oct 7 14:43:06 2014 From: osas at voipembedded.com (Ovidiu Sas) Date: Tue, 7 Oct 2014 08:43:06 -0400 Subject: [OpenSIPS-Users] [RFC] Deprecating mi_xmlrpc In-Reply-To: <5433B141.8070201@opensips.org> References: <1395238721.98475.YahooMailNeo@web122604.mail.ne1.yahoo.com> <5329D0A1.7020205@opensips.org> <532C59B6.3020706@opensips.org> <5433B141.8070201@opensips.org> Message-ID: There was a lot of work done right before releasing 1.11 to fix the compatibility issue. I didn't heard back anything, so I assume that it's fixed. Anyway, if there's no push for it, the transition will never happen :) -ovidiu On Oct 7, 2014 5:24 AM, "Bogdan-Andrei Iancu" wrote: > Hi Ovidiu, > > We need to check once again if the mi_xmlrpc_ng can do a perfect replace > for mi_xmlrpc - then we can obsolete in a blink of an eye. > > Are you aware of any pending issues in terms of backward compatibility ? > > PS: 1.12 is replaced by 2.1.0 - this is the version on trunk. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 25.09.2014 21:39, Ovidiu Sas wrote: > >> Are we ready to deprecate the mi_xmlrpc module now (for 1.12)? >> >> -ovidiu >> >> On Fri, Mar 21, 2014 at 11:24 AM, Bogdan-Andrei Iancu >> wrote: >> >>> Hello all, >>> >>> Bringing some light here : none of the xmlrpc implementations offer a >>> structured reply >>> >>> From the "deprecation" point of view, we need to be sure: >>> 1) the new mi_xmlrpc-ng module is a perfect substitute to the old one >>> (providing the same unstructured reply) >>> 2) the new mi_xmlrpc-ng module can also provide a structured reply - this >>> definitely is something good for the future >>> 3) OpenSIPS CP must be migrated (there are some things that need to be >>> changed) to be compatible with both modules. >>> >>> Ovidiu (mi_xmlepc-ng) and Alex (opensips cp) are already heavily working >>> to >>> achieve the 3 goals above (many thanks to both of them). >>> >>> As noticed, the old mi_xmlrpc module was not deprecated in 1.11 - there >>> are >>> small but many things to be done to 100% ensure a smooth transition. >>> Still >>> this is work on progress and it will be done for next release. >>> >>> Many thanks, >>> >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> >>> On 19.03.2014 21:55, Brett Nemeroff wrote: >>> >>> JSON+http sounds fantastic. It's like.. Starting to sound a like a >>> RESTful >>> server. >>> >>> I'm pretty sure others will jump on this. I know I would. >>> -Brett >>> >>> >>> >>> On Wed, Mar 19, 2014 at 2:52 PM, Ovidiu Sas >>> wrote: >>> >>>> The new module is built on top of the httpd module which has a >>>> parameter to define the size of the buffer. If you need large >>>> replies, then you need to adjust the buffer size accordingly. >>>> http://www.opensips.org/html/docs/modules/devel/httpd >>>> >>>> That buffer is used by all modules that are sitting on top of the >>>> httpd module, and there's one single process dedicated to all http >>>> requests (no interference with SIP workers). >>>> >>>> Regards, >>>> Ovidiu Sas >>>> >>>> On Wed, Mar 19, 2014 at 3:44 PM, Brett Nemeroff >>>> wrote: >>>> >>>>> I think there are some other issues with the size of the return data. I >>>>> know >>>>> for one that the mi_udp method has a buffer size limit. If you hit this >>>>> limit I think it very quietly truncates the data. I can't 100% verify >>>>> that >>>>> since it's been a long time since I've used it. >>>>> >>>>> I believe you can paginate the data, but the problem is that you can't >>>>> guarantee consistent results paginating data when the data is changing >>>>> constantly. I'm not really sure on the background how this is handled; >>>>> maybe >>>>> a locked list or something.. but not sure if it'd affect performance at >>>>> high >>>>> velocity. Seems like something. somewhere would be affected.. either >>>>> performance or accuracy. >>>>> >>>>> My point being, care needs to be taken that the method can produce >>>>> consistent results; even for large datasets. If data is going to be >>>>> truncated or we run out of SHM, there needs to not only be an error >>>>> log, >>>>> but >>>>> I think the out put needs to say something as well. >>>>> >>>>> -Brett >>>>> >>>>> >>>>> >>>>> On Wed, Mar 19, 2014 at 2:37 PM, Dragomir Haralambiev >>>>> >>>>> wrote: >>>>> >>>>>> I totally share Brett's feelings! For me dlg_list_ctx over the new >>>>>> module >>>>>> causes lots of headaches when dialogs go over 100 or so. Structured >>>>>> output >>>>>> would resolve such problems. I am totally in for structured SJON >>>>>> format >>>>>> too! >>>>>> >>>>>> >>>>>> 2014-03-19 21:07 GMT+02:00 Brett Nemeroff : >>>>>> >>>>>> I think the only reason for that is backwards compatibility with >>>>>>> stuff >>>>>>> written for the other mi interfaces. >>>>>>> >>>>>>> >>>>>>> Honestly, my parsers for the MI output are ridiculous. It's really >>>>>>> complicated and prone to failure. I'd like to know if others share my >>>>>>> feeling here. >>>>>>> >>>>>>> For little things like "dr_reload" I don't really care. >>>>>>> >>>>>>> But for MI calls that return large amounts of user data, like >>>>>>> dlg_list_ctx.. Parsing it is kind of ridiculous... Anyone else share >>>>>>> this >>>>>>> feeling? >>>>>>> >>>>>>> I personally would love to see it structured in JSON format. :) >>>>>>> >>>>>>> -Brett >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 19, 2014 at 2:05 PM, Ovidiu Sas >>>>>>> wrote: >>>>>>> >>>>>>>> Hello Brett, >>>>>>>> >>>>>>>> It is true that the structured output mode was not implemented in >>>>>>>> the >>>>>>>> new module. >>>>>>>> It seems that having the output in one big chunk is the preferred >>>>>>>> method in the community. >>>>>>>> >>>>>>>> If there is a real demand for structured output, we can take a look >>>>>>>> into >>>>>>>> it. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Ovidiu Sas >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Mar 19, 2014 at 1:56 PM, Brett Nemeroff >>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I'd like to see the new module to be a drop in replacement for the >>>>>>>>> old >>>>>>>>> one.. >>>>>>>>> >>>>>>>>> That being said... >>>>>>>>> >>>>>>>>> I was pretty surprised when I started down the path of the XMLRPC >>>>>>>>> module >>>>>>>>> that the reply isn't structured. It was just one big object. >>>>>>>>> >>>>>>>>> I'd like a selectable option on the module so that it either >>>>>>>>> operates: >>>>>>>>> 1. Legacy (one big output chunk) >>>>>>>>> 2. Structured, parable for each output node. >>>>>>>>> >>>>>>>>> Really if we are talking "deprecating" we need to support the old >>>>>>>>> method >>>>>>>>> primarily or there will be a lot of broken code out there. >>>>>>>>> >>>>>>>>> -Brett >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Mar 19, 2014 at 12:15 PM, Bogdan-Andrei Iancu >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> The whole idea is not to :) >>>>>>>>>> >>>>>>>>>> But more tests need to be done. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Bogdan-Andrei Iancu >>>>>>>>>> OpenSIPS Founder and Developer >>>>>>>>>> http://www.opensips-solutions.com >>>>>>>>>> >>>>>>>>>> On 19.03.2014 17:39, Ali Pey wrote: >>>>>>>>>> >>>>>>>>>> Will this affect OpenSIPS-CP? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Ali Pey >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Mar 19, 2014 at 10:18 AM, Kneeoh >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I'm all for the deprecation as long as the documentation on the >>>>>>>>>>> mi_xmlrpc_ng module is updated to a usable level. I find myself >>>>>>>>>>> referencing >>>>>>>>>>> the documentation for xmlrpc and hoping that it holds true for >>>>>>>>>>> xmlrpc_ng. >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Users mailing list >>>>>>>>>>> Users at lists.opensips.org >>>>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Users mailing list >>>>>>>>>> Users at lists.opensips.org >>>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Users mailing list >>>>>>>>>> Users at lists.opensips.org >>>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Users mailing list >>>>>>>>> Users at lists.opensips.org >>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> VoIP Embedded, Inc. >>>>>>>> http://www.voipembedded.com >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Users mailing list >>>>>>>> Users at lists.opensips.org >>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Users mailing list >>>>>>> Users at lists.opensips.org >>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users at lists.opensips.org >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> >>>> >>>> -- >>>> VoIP Embedded, Inc. >>>> http://www.voipembedded.com >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >> >> > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Oct 7 15:10:45 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 07 Oct 2014 16:10:45 +0300 Subject: [OpenSIPS-Users] $T_fr_timeout and $T_fr_inv_timeout In-Reply-To: References: Message-ID: <5433E655.3090207@opensips.org> Hi Gary, The difference between the 2 timer is if a reply was received or not - until the first reply you have T_fr_timeout, after that, it is T_fr_inv_timeout. So, use the t_local_replied("all") (http://www.opensips.org/html/docs/modules/1.11.x/tm.html#id295158) to see if any rely was received. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 07.10.2014 04:58, Gary Nyquist wrote: > Hi, > > Is it possible to know (inside a failure_route[] block), which timeout caused to land up in the failure_route? > > # E.g. in the main route, I have: > if(is_method("INVITE")){ > ... > ... > $T_fr_timeout=8; > $T_fr_inv_timeout=30; > t_on_failure("1"); > t_relay(); > exit; > } > > # And in failure_route: > failure_route[1] { > # How to know if $T_fr_timeout or $T_fr_inv_timeout caused this failure? > } > > Any tips? > > Thanks. > Best Regards, > - Gary > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From bogdan at opensips.org Tue Oct 7 15:16:16 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 07 Oct 2014 16:16:16 +0300 Subject: [OpenSIPS-Users] ERROR:tm:t_check: INVITE reply cannot be parsed In-Reply-To: References: Message-ID: <5433E7A0.3080505@opensips.org> Hello Alec, The error means you received a reply with syntax errors (in this case you should have other error logs before) or with VIA or CSEQ hdr missing (not other errors in advance). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 07.10.2014 03:24, Alec Doran-Twyford wrote: > Hi all, > > I am getting this error "ERROR:tm:t_check: INVITE reply cannot be parsed" > when someone makes a call though our system. > > I am not sure where it came from. I am just wondering if anyone know > some common problem when this has happens? > > Alec Doran-Twyford > | Support Engineer for IVSTel | > | E-mail: a.dorantwyford at ivstel.com > | Skype: AlecDoranTwyford | > | Phone: +61 2 9288 8890 | Mob: +61 423 694 742 | > | LinkedIn | > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.dorantwyford at ivstel.com Tue Oct 7 01:14:07 2014 From: a.dorantwyford at ivstel.com (Alec Doran-Twyford) Date: Tue, 7 Oct 2014 10:14:07 +1100 Subject: [OpenSIPS-Users] ERROR:tm:t_check: INVITE reply cannot be parsed In-Reply-To: References: Message-ID: Hi all, I am getting this error "ERROR:tm:t_check: INVITE reply cannot be parsed" when some make a call though our system. I am not sure where it came from I just wondering if anyone know some common problem when this has happens? it happen sometime after someone does an Invite from one of our clients systems but not from our own. Alec Doran-Twyford | Support Engineer for IVSTel | | E-mail: a.dorantwyford at ivstel.com | Skype: AlecDoranTwyford | | Phone: +61 2 9288 8890 | Mob: +61 423 694 742 | | LinkedIn | -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Oct 7 15:14:11 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 07 Oct 2014 16:14:11 +0300 Subject: [OpenSIPS-Users] [RFC] Deprecating mi_xmlrpc In-Reply-To: References: <1395238721.98475.YahooMailNeo@web122604.mail.ne1.yahoo.com> <5329D0A1.7020205@opensips.org> <532C59B6.3020706@opensips.org> <5433B141.8070201@opensips.org> Message-ID: <5433E723.6050508@opensips.org> Ovidiu, we are still somewhere in the middle of a release cycle, so enough time to eventually fix potential problems. I agree with you, we need to take the step and face the outcome. We need to prepare a directly on the repo, like "modules_old" where to move the obsolete modules. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 07.10.2014 15:43, Ovidiu Sas wrote: > > There was a lot of work done right before releasing 1.11 to fix the > compatibility issue. I didn't heard back anything, so I assume that > it's fixed. > > Anyway, if there's no push for it, the transition will never happen :) > > -ovidiu > > On Oct 7, 2014 5:24 AM, "Bogdan-Andrei Iancu" > wrote: > > Hi Ovidiu, > > We need to check once again if the mi_xmlrpc_ng can do a perfect > replace for mi_xmlrpc - then we can obsolete in a blink of an eye. > > Are you aware of any pending issues in terms of backward > compatibility ? > > PS: 1.12 is replaced by 2.1.0 - this is the version on trunk. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 25.09.2014 21 :39, Ovidiu Sas wrote: > > Are we ready to deprecate the mi_xmlrpc module now (for 1.12)? > > -ovidiu > > On Fri, Mar 21, 2014 at 11:24 AM, Bogdan-Andrei Iancu > > wrote: > > Hello all, > > Bringing some light here : none of the xmlrpc > implementations offer a > structured reply > > From the "deprecation" point of view, we need to be sure: > 1) the new mi_xmlrpc-ng module is a perfect substitute to > the old one > (providing the same unstructured reply) > 2) the new mi_xmlrpc-ng module can also provide a > structured reply - this > definitely is something good for the future > 3) OpenSIPS CP must be migrated (there are some things > that need to be > changed) to be compatible with both modules. > > Ovidiu (mi_xmlepc-ng) and Alex (opensips cp) are already > heavily working to > achieve the 3 goals above (many thanks to both of them). > > As noticed, the old mi_xmlrpc module was not deprecated in > 1.11 - there are > small but many things to be done to 100% ensure a smooth > transition. Still > this is work on progress and it will be done for next release. > > Many thanks, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 19.03.2014 21:55, Brett Nemeroff wrote: > > JSON+http sounds fantastic. It's like.. Starting to sound > a like a RESTful > server. > > I'm pretty sure others will jump on this. I know I would. > -Brett > > > > On Wed, Mar 19, 2014 at 2:52 PM, Ovidiu Sas > > wrote: > > The new module is built on top of the httpd module > which has a > parameter to define the size of the buffer. If you > need large > replies, then you need to adjust the buffer size > accordingly. > http://www.opensips.org/html/docs/modules/devel/httpd > > That buffer is used by all modules that are sitting on > top of the > httpd module, and there's one single process dedicated > to all http > requests (no interference with SIP workers). > > Regards, > Ovidiu Sas > > On Wed, Mar 19, 2014 at 3:44 PM, Brett Nemeroff > > > wrote: > > I think there are some other issues with the size > of the return data. I > know > for one that the mi_udp method has a buffer size > limit. If you hit this > limit I think it very quietly truncates the data. > I can't 100% verify > that > since it's been a long time since I've used it. > > I believe you can paginate the data, but the > problem is that you can't > guarantee consistent results paginating data when > the data is changing > constantly. I'm not really sure on the background > how this is handled; > maybe > a locked list or something.. but not sure if it'd > affect performance at > high > velocity. Seems like something. somewhere would be > affected.. either > performance or accuracy. > > My point being, care needs to be taken that the > method can produce > consistent results; even for large datasets. If > data is going to be > truncated or we run out of SHM, there needs to not > only be an error log, > but > I think the out put needs to say something as well. > > -Brett > > > > On Wed, Mar 19, 2014 at 2:37 PM, Dragomir Haralambiev > > > wrote: > > I totally share Brett's feelings! For me > dlg_list_ctx over the new > module > causes lots of headaches when dialogs go over > 100 or so. Structured > output > would resolve such problems. I am totally in > for structured SJON format > too! > > > 2014-03-19 21:07 GMT+02:00 Brett Nemeroff > >: > > I think the only reason for that is > backwards compatibility with stuff > written for the other mi interfaces. > > > Honestly, my parsers for the MI output are > ridiculous. It's really > complicated and prone to failure. I'd like > to know if others share my > feeling here. > > For little things like "dr_reload" I don't > really care. > > But for MI calls that return large amounts > of user data, like > dlg_list_ctx.. Parsing it is kind of > ridiculous... Anyone else share > this > feeling? > > I personally would love to see it > structured in JSON format. :) > > -Brett > > > > On Wed, Mar 19, 2014 at 2:05 PM, Ovidiu > Sas > > wrote: > > Hello Brett, > > It is true that the structured output > mode was not implemented in the > new module. > It seems that having the output in one > big chunk is the preferred > method in the community. > > If there is a real demand for > structured output, we can take a look > into > it. > > Regards, > Ovidiu Sas > > > On Wed, Mar 19, 2014 at 1:56 PM, Brett > Nemeroff > > wrote: > > I'd like to see the new module to > be a drop in replacement for the > old > one.. > > That being said... > > I was pretty surprised when I > started down the path of the XMLRPC > module > that the reply isn't structured. > It was just one big object. > > I'd like a selectable option on > the module so that it either > operates: > 1. Legacy (one big output chunk) > 2. Structured, parable for each > output node. > > Really if we are talking > "deprecating" we need to support > the old > method > primarily or there will be a lot > of broken code out there. > > -Brett > > > > On Wed, Mar 19, 2014 at 12:15 PM, > Bogdan-Andrei Iancu > > > wrote: > > The whole idea is not to :) > > But more tests need to be done. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 19.03.2014 17:39, Ali Pey > wrote: > > Will this affect OpenSIPS-CP? > > Regards, > Ali Pey > > > > On Wed, Mar 19, 2014 at 10:18 > AM, Kneeoh > wrote: > > I'm all for the > deprecation as long as the > documentation on the > mi_xmlrpc_ng module is > updated to a usable level. > I find myself > referencing > the documentation for > xmlrpc and hoping that it > holds true for > xmlrpc_ng. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > -- > VoIP Embedded, Inc. > http://www.voipembedded.com > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > -- > VoIP Embedded, Inc. > http://www.voipembedded.com > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Oct 7 15:20:22 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 07 Oct 2014 16:20:22 +0300 Subject: [OpenSIPS-Users] menuconfig-tool In-Reply-To: <54319210.1050709@compuserve.com> References: <54319210.1050709@compuserve.com> Message-ID: <5433E896.4050401@opensips.org> Hi Jaap, It is standard shell stuff - Crtl z puts the current app into background. You can see background apps with "jobs" and bring one back forward with "fg [id]" Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 05.10.2014 21:46, Jaap van der Starre wrote: > to Vlad Paiu > I followed the video "2012-05-18.02 OpenSIPS Kick Start" > At one time you go out of Menuconfig-tool using ^z into bash. > Then you go back from bash to Menuconfig-tool again. > How do you do that? Which key do I use to go back to Menuconfig ? > > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From bogdan at opensips.org Tue Oct 7 15:24:01 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 07 Oct 2014 16:24:01 +0300 Subject: [OpenSIPS-Users] Flow stops when branch is dropped In-Reply-To: References: Message-ID: <5433E971.8020809@opensips.org> Hi Mickael, If you do the "drop" in branch route, that branch will be discarded (not sent out at all). IF no branch is actually sent out, you will get the error logs from "t_forward_nonack" (as you have). In this case, the t_relay() will fail (nothing sent) - to get that error in script, set flag 0x02 (http://www.opensips.org/html/docs/modules/1.11.x/tm.html#id294578), otherwise the error will be internally handled. A failure on sending does not trigger a failure route - failure route is triggered only if request sent out and the transaction completed with a negative code. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 06.10.2014 11:59, Mickael Marrache wrote: > Hi, > > What happens after drop() is called from a branch_route? > > In my case, I armed a failure route for the incoming INVITE in the > request route and therefore, I would expect that the failure route > would be called after drop() is called. However, I see the following > error in the logs and the following reply is returned to the UAC. > > Oct 6 08:57:27 DBG:tm:pre_print_uac_request: dropping branch > > Oct 6 08:57:27 ERROR:tm:t_forward_nonack: failure to add branches > > SIP/2.0 500 Server error occurred (1/TM) > > I use the failure route to detect current transaction failure and try > the next termination if there is. > > Thanks, > Mickael > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Oct 7 15:26:28 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 07 Oct 2014 16:26:28 +0300 Subject: [OpenSIPS-Users] db_text for domain table In-Reply-To: <1412581449829-7593779.post@n2.nabble.com> References: <1412581449829-7593779.post@n2.nabble.com> Message-ID: <5433EA04.4060106@opensips.org> Hi Chen-Che, Which OpenSIPS version are you using ? maybe you have an old one where the domain module is not compatible with the db_text driver. In 1.11 definitely is. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 06.10.2014 10:44, microx wrote: > Dear all, > > I use the db_text module for the dispatcher and domain tables. For the > dispatcher table, it works successfully. However, for the domain table, the > OpenSIP server always fails to read the domain table on startup. Please help > to take a look what listed below. Thanks for any comment. > > Best wishes, > Chen-Che > > Related part of the OpenSIPS config > loadmodule "db_text.so" > loadmodule "domain.so" > > modparam("db_text", "db_mode", 0) > modparam("domain", "db_url", "text:///etc/opensips") > modparam("domain", "domain_table", "domain") > modparam("domain", "db_mode", 1) # Use caching > > (file)/etc/opensips/domain > id(int) domain(str) last_modified(str,null) > 1:siptest.com:: > > Log message > DBG:db_text:dbt_load_file: loading file [/etc/opensips/domain] > DBG:db_text:dbt_table_new: mtime is 1412576125 > DBG:db_text:dbt_load_file: column[0] is INT! > DBG:db_text:dbt_load_file: column[1] is STR! > DBG:db_text:dbt_load_file: column[2] is STR! > DBG:db_text:dbt_query: new res with 1 cols > DBG:db_text:dbt_result_new: new res with 1 cols > DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f14717152c8 > DBG:core:db_allocate_columns: allocate 28 bytes for result columns at > 0x7f14717155f8 > DBG:core:db_allocate_rows: allocate 48 bytes for result rows and values at > 0x7f1471715480 > DBG:domain:reload_domain_table: Number of rows in domain table: 1 > *ERROR:domain:reload_domain_table: Database problem* > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/db-text-for-domain-table-tp7593779.html > Sent from the OpenSIPS - Users mailing list archive at Nabble.com. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From bogdan at opensips.org Tue Oct 7 15:29:41 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 07 Oct 2014 16:29:41 +0300 Subject: [OpenSIPS-Users] RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE In-Reply-To: <1412410687.9891.YahooMailNeo@web121504.mail.ne1.yahoo.com> References: <1412410687.9891.YahooMailNeo@web121504.mail.ne1.yahoo.com> Message-ID: <5433EAC5.80708@opensips.org> Hi Kaan, The log you refer to is a DBG and not an ERR (error) - when a new request is received, opensips (inside the t_relay) tries to match it against existing transactions to see if it a retransmission on not. The fact your request does not match means it is not a retransmission, but rather a new request. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 04.10.2014 11:18, Kaan Dandin wrote: > Hi all, > I am making registration to the Open IMS nodes(192.168.2.3 and > 192.168.2.5) simultaneously from IMS bench(192.168.2.11). Registration > messages are going through OpenSIPS load balancer(192.168.2.141). > Registration messages which are going to first Open IMS > node(192.168.2.5) completed succesfully. > But registration to second IMS node(192.168.2.3) is not completed > successfully since t_relay() function in OpenSIPS load balancer is > giving "DBG:tm:matching_3261: RFC3261 transaction matching failed" > error and not passing the "Status: 401 Unauthorized - Challenging the > UE (0 bindings)" messages to IMS bench. > Below please find wireshark log and opensips logs in debug level=6. > Do you have any idea for this problem. > BR, > Kaan > o. Time Source Destination Protocol Info > 55 1.186495 192.168.2.11 192.168.2.141 SIP > Request: REGISTER sip:open-ims.test > 56 1.188443 192.168.2.141 192.168.2.3 SIP > Request: REGISTER sip:open-ims.test > 57 1.189001 192.168.2.141 192.168.2.5 SIP > Request: REGISTER sip:open-ims.test > 58 1.215792 192.168.2.5 192.168.2.141 SIP Status: > 401 Unauthorized - Challenging the UE (0 bindings) > 59 1.216974 192.168.2.141 192.168.2.11 SIP > Status: 401 Unauthorized - Challenging the UE (0 bindings) > 60 1.217486 192.168.2.11 192.168.2.141 SIP > Request: REGISTER sip:open-ims.test > 61 1.218516 192.168.2.141 192.168.2.3 SIP > Request: REGISTER sip:open-ims.test > 62 1.218804 192.168.2.141 192.168.2.5 SIP > Request: REGISTER sip:open-ims.test > 63 1.233561 192.168.2.3 192.168.2.141 SIP Status: > 401 Unauthorized - Challenging the UE (0 bindings) > 64 1.241624 192.168.2.3 192.168.2.141 SIP Status: > 401 Unauthorized - Challenging the UE (0 bindings) > 65 1.246112 192.168.2.5 192.168.2.141 SIP Status: > 200 OK - SAR succesful and registrar saved (1 bindings) > 66 1.246919 192.168.2.141 192.168.2.11 SIP > Status: 200 OK - SAR succesful and registrar saved (1 bindings) > Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: xlog > method: [REGISTER] totag: [] sipid: [192.168.2.11] messageid: > [68] callid: [56-6888 at 192.168.2.11] callsequence: [2] > Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: > DBG:uri:has_totag: no totag > Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: > xlog_initialregister > Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: > DBG:core:comp_scriptvar: str 20 : 192.168.2.11 > Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: > DBG:tm:t_newtran: transaction on entrance=0xffffffffffffffff > Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: > DBG:core:parse_headers: flags=ffffffffffffffff > Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: > DBG:core:get_hdr_field: content_length=0 > Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: > DBG:core:get_hdr_field: found end of header > Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: > DBG:core:parse_headers: flags=78 > Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: > DBG:tm:t_lookup_request: start searching: hash=35746, isACK=0 > Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: > DBG:tm:matching_3261: RFC3261 transaction matching failed > Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: > DBG:tm:t_lookup_request: no transaction found > Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: > DBG:tm:run_reqin_callbacks: trans=0x7fcda4739918, callback type 1, id > 1 entered > Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: > DBG:tm:run_reqin_callbacks: trans=0x7fcda4739918, callback type 1, id > 0 entered > Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: > DBG:core:check_ip_address: params 192.168.2.11, 192.168.2.11, 0 > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From acmicrox at gmail.com Tue Oct 7 15:46:52 2014 From: acmicrox at gmail.com (microx) Date: Tue, 7 Oct 2014 06:46:52 -0700 (PDT) Subject: [OpenSIPS-Users] db_text for domain table In-Reply-To: <5433EA04.4060106@opensips.org> References: <1412581449829-7593779.post@n2.nabble.com> <5433EA04.4060106@opensips.org> Message-ID: <1412689612257-7593827.post@n2.nabble.com> Hi Bogdan-Andrei, I use OpenSIPS 1.9.2. I hope the version is not too old for the domain table. Best wishes, Chen-Che -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/db-text-for-domain-table-tp7593779p7593827.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From vandan.joshi at panamaxil.com Tue Oct 7 15:58:54 2014 From: vandan.joshi at panamaxil.com (Vandan Joshi) Date: Tue, 7 Oct 2014 09:58:54 -0400 (EDT) Subject: [OpenSIPS-Users] opensips-1.6 recv queue full In-Reply-To: <5433EAC5.80708@opensips.org> References: <1412410687.9891.YahooMailNeo@web121504.mail.ne1.yahoo.com> <5433EAC5.80708@opensips.org> Message-ID: <1981052536.9212077.1412690334516.JavaMail.zimbra@panamaxil.com> Dear Bogdan, I am using opensips-1.6 on CentOS-5.8. In certain conditions I am seeing lot of packets queued in recv queue and not getting processed. I am monitoring the same using "netstat" command. While observing the siptrace I found, opensips couldn't reply to incoming msgs, and if replied, it replies very late. What sort of params I should observe/optimize to handle this kinda situation(when getting very high traffic on switch) ?? thnx -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Oct 7 16:43:52 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 07 Oct 2014 17:43:52 +0300 Subject: [OpenSIPS-Users] db_text for domain table In-Reply-To: <1412689612257-7593827.post@n2.nabble.com> References: <1412581449829-7593779.post@n2.nabble.com> <5433EA04.4060106@opensips.org> <1412689612257-7593827.post@n2.nabble.com> Message-ID: <5433FC28.40003@opensips.org> Hello Chen-Che, 1.9 does not have that fix (to support db_text), neither 1.10 . Only 1.11 has it. That fix is combined with adding attr support for domains: https://github.com/OpenSIPS/opensips/commit/57ec0f399438b383b031535dc27a1e253ca78bec Of course, you can try and copy the whole module (+db schema) from 1.11 to 1.9. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 07.10.2014 16:46, microx wrote: > Hi Bogdan-Andrei, > > I use OpenSIPS 1.9.2. I hope the version is not too old for the domain > table. > > Best wishes, > Chen-Che > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/db-text-for-domain-table-tp7593779p7593827.html > Sent from the OpenSIPS - Users mailing list archive at Nabble.com. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > From brett at nemeroff.com Tue Oct 7 16:46:35 2014 From: brett at nemeroff.com (Brett Nemeroff) Date: Tue, 7 Oct 2014 09:46:35 -0500 Subject: [OpenSIPS-Users] opensips-1.6 recv queue full In-Reply-To: <1981052536.9212077.1412690334516.JavaMail.zimbra@panamaxil.com> References: <1412410687.9891.YahooMailNeo@web121504.mail.ne1.yahoo.com> <5433EAC5.80708@opensips.org> <1981052536.9212077.1412690334516.JavaMail.zimbra@panamaxil.com> Message-ID: Generally you can monitor for this with: netstat -nlp|grep opensips but I suspect you are already doing something similar. The statistics module also has a similar statistics. The command: opensipsctl fifo get_statistics all If you look near the bottom, you'll see the load in percent of the children for each listening interface. It looks like this: load:udp:1.2.3.4:5060-load = 18 ie: 1.2.3.4 is 18% busy. If this number reaches 100, your children are no longer capable of responding to UDP packets on that interface and the kernel will begin to queue if possible. -Brett On Tue, Oct 7, 2014 at 8:58 AM, Vandan Joshi wrote: > Dear Bogdan, > > I am using opensips-1.6 on CentOS-5.8. > In certain conditions I am seeing lot of packets queued in recv queue and > not getting processed. > I am monitoring the same using "netstat" command. > While observing the siptrace I found, opensips couldn't reply to incoming > msgs, and if replied, it replies very late. > > What sort of params I should observe/optimize to handle this kinda > situation(when getting very high traffic on switch) ?? > thnx > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vandan.joshi at panamaxil.com Tue Oct 7 16:51:36 2014 From: vandan.joshi at panamaxil.com (Vandan Joshi) Date: Tue, 7 Oct 2014 10:51:36 -0400 (EDT) Subject: [OpenSIPS-Users] opensips-1.6 recv queue full In-Reply-To: References: <1412410687.9891.YahooMailNeo@web121504.mail.ne1.yahoo.com> <5433EAC5.80708@opensips.org> <1981052536.9212077.1412690334516.JavaMail.zimbra@panamaxil.com> Message-ID: <412218672.9229924.1412693495888.JavaMail.zimbra@panamaxil.com> Dear Brett, I think this statistics option isn't avail in opensips-1.6 ver. plz tell me wt can I do in 1.6. thnx for the reply. ----- Original Message ----- From: "Brett Nemeroff" To: "OpenSIPS users mailling list" Sent: Tuesday, October 7, 2014 8:16:35 PM Subject: Re: [OpenSIPS-Users] opensips-1.6 recv queue full Generally you can monitor for this with: netstat -nlp|grep opensips but I suspect you are already doing something similar. The statistics module also has a similar statistics. The command: opensipsctl fifo get_statistics all If you look near the bottom, you'll see the load in percent of the children for each listening interface. It looks like this: load:udp:1.2.3.4:5060-load = 18 ie: 1.2.3.4 is 18% busy. If this number reaches 100, your children are no longer capable of responding to UDP packets on that interface and the kernel will begin to queue if possible. -Brett On Tue, Oct 7, 2014 at 8:58 AM, Vandan Joshi < vandan.joshi at panamaxil.com > wrote: Dear Bogdan, I am using opensips-1.6 on CentOS-5.8. In certain conditions I am seeing lot of packets queued in recv queue and not getting processed. I am monitoring the same using "netstat" command. While observing the siptrace I found, opensips couldn't reply to incoming msgs, and if replied, it replies very late. What sort of params I should observe/optimize to handle this kinda situation(when getting very high traffic on switch) ?? thnx _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at nemeroff.com Tue Oct 7 18:07:25 2014 From: brett at nemeroff.com (Brett Nemeroff) Date: Tue, 7 Oct 2014 11:07:25 -0500 Subject: [OpenSIPS-Users] opensips-1.6 recv queue full In-Reply-To: <412218672.9229924.1412693495888.JavaMail.zimbra@panamaxil.com> References: <1412410687.9891.YahooMailNeo@web121504.mail.ne1.yahoo.com> <5433EAC5.80708@opensips.org> <1981052536.9212077.1412690334516.JavaMail.zimbra@panamaxil.com> <412218672.9229924.1412693495888.JavaMail.zimbra@panamaxil.com> Message-ID: I'd be surprised if it wasn't.. Either way, netstat will give you pretty good information. I regularly monitor the output values in netstat. On Tue, Oct 7, 2014 at 9:51 AM, Vandan Joshi wrote: > Dear Brett, > > I think this statistics option isn't avail in opensips-1.6 ver. > plz tell me wt can I do in 1.6. > > thnx for the reply. > ------------------------------ > *From: *"Brett Nemeroff" > *To: *"OpenSIPS users mailling list" > *Sent: *Tuesday, October 7, 2014 8:16:35 PM > *Subject: *Re: [OpenSIPS-Users] opensips-1.6 recv queue full > > > Generally you can monitor for this with: > netstat -nlp|grep opensips > > but I suspect you are already doing something similar. The statistics > module also has a similar statistics. The command: > opensipsctl fifo get_statistics all > > If you look near the bottom, you'll see the load in percent of the > children for each listening interface. It looks like this: > load:udp:1.2.3.4:5060-load = 18 > > ie: 1.2.3.4 is 18% busy. If this number reaches 100, your children are no > longer capable of responding to UDP packets on that interface and the > kernel will begin to queue if possible. > > -Brett > > > On Tue, Oct 7, 2014 at 8:58 AM, Vandan Joshi > wrote: > >> Dear Bogdan, >> >> I am using opensips-1.6 on CentOS-5.8. >> In certain conditions I am seeing lot of packets queued in recv queue and >> not getting processed. >> I am monitoring the same using "netstat" command. >> While observing the siptrace I found, opensips couldn't reply to >> incoming msgs, and if replied, it replies very late. >> >> What sort of params I should observe/optimize to handle this kinda >> situation(when getting very high traffic on switch) ?? >> thnx >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gn62 at gmx.us Tue Oct 7 18:19:40 2014 From: gn62 at gmx.us (Gary Nyquist) Date: Tue, 7 Oct 2014 18:19:40 +0200 Subject: [OpenSIPS-Users] $T_fr_timeout and $T_fr_inv_timeout In-Reply-To: <5433E655.3090207@opensips.org> References: , <5433E655.3090207@opensips.org> Message-ID: Thank you Bogdan for the advice. That's what I was looking for :-) Best Regards, - Gary > Sent: Tuesday, October 07, 2014 at 9:10 AM > From: "Bogdan-Andrei Iancu" > To: "OpenSIPS users mailling list" , gn62 at gmx.us > Subject: Re: [OpenSIPS-Users] $T_fr_timeout and $T_fr_inv_timeout > > Hi Gary, > > The difference between the 2 timer is if a reply was received or not - > until the first reply you have T_fr_timeout, after that, it is > T_fr_inv_timeout. > > So, use the t_local_replied("all") > (http://www.opensips.org/html/docs/modules/1.11.x/tm.html#id295158) to > see if any rely was received. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 07.10.2014 04:58, Gary Nyquist wrote: > > Hi, > > > > Is it possible to know (inside a failure_route[] block), which timeout caused to land up in the failure_route? > > > > # E.g. in the main route, I have: > > if(is_method("INVITE")){ > > ... > > ... > > $T_fr_timeout=8; > > $T_fr_inv_timeout=30; > > t_on_failure("1"); > > t_relay(); > > exit; > > } > > > > # And in failure_route: > > failure_route[1] { > > # How to know if $T_fr_timeout or $T_fr_inv_timeout caused this failure? > > } > > > > Any tips? > > > > Thanks. > > Best Regards, > > - Gary > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > From bogdan at opensips.org Tue Oct 7 18:44:30 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 07 Oct 2014 19:44:30 +0300 Subject: [OpenSIPS-Users] OpenSIPS Las Vegas Summit - Speakers & Workshops - part Message-ID: <5434186E.20708@opensips.org> Ever wonder how you can: * load balance your Asterisk servers * provide fail over protection for your Asterisk servers * distribute services to your Asterisk server clusters *On October 21st, 2014, Las Vegas will be the the "OpenSIPS" city!* *Vlad Paiu - OpenSIPS core developer - */"OpenSIPS, a service enabler for Asterisk//"/ By using OpenSIPS as a front-end for the Asterisk-based system, additional/advanced SIP services can be enabled for the end-users. OpenSIPS can act as an enabler for SIP SIMPLE (presence and IM), XCAP, webRTC, TLS support, Parallel Registration, IRC-like chatting and other end-user oriented services. Aside the end-user service, OpenSIPS can address provider oriented services like LCR and Gateway failover for the outbound traffic, LNP and CNAME dipping, etc. *Razvan Crainea ***- OpenSIPS core developer *- "*/Scaling Asterisk with OpenSIPS"/ There is a huge number of successful Asterisk-based platforms which need to grow beyond the "one-instance" stage. To grow/scale as capacity or as geographical coverage. OpenSIPS provides the solution for such platform - the typical OpenSIPS sandwich consists of a pool of Asterisk servers between two OpenSIPS instances, on inbound and outbound. On the inbound side, OpenSIPS can solve the problem of doing SIP wise balancing and redundancy for the Asterisk cluster, to ensure traffic validation and shaping. Aside complex authentication mechanisms (as digest, LDAP, IP based), the fronting OpenSIPS is responsible for provide fraud detection and other various security tools. On the outbound side, OpenSIPS takes care of complex routing logics to PSTN carriers / GW, LCR, CNAME or LNP dipping. Traffic to carriers can be CPS/CC controlled and accounted. The latest OpenSIPS version is able to provide Quality based Routing towards carriers And more speakers and even more topics to follow. See http://www.opensips.org/Community/Summit-2014LasVegas-Schedule To *register for the event*, see http://www.opensips.org/Community/Summit-Registration Participating the Astricon? Use the "astricon2014" discount code ;). See you in Vegas, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ionutm22 at gmail.com Tue Oct 7 22:51:59 2014 From: ionutm22 at gmail.com (Ionut Muntean) Date: Tue, 07 Oct 2014 23:51:59 +0300 Subject: [OpenSIPS-Users] OpenSIPS Las Vegas Summit - Speakers & Workshops - part In-Reply-To: <5434186E.20708@opensips.org> References: <5434186E.20708@opensips.org> Message-ID: <5434526F.6070805@gmail.com> IMHO ... Yate is over Aterisk 1000 times. But this is my humble opinion .... On 07/10/2014 19:44, Bogdan-Andrei Iancu wrote: > Ever wonder how you can: > > * load balance your Asterisk servers > * provide fail over protection for your Asterisk servers > * distribute services to your Asterisk server clusters > > *On October 21st, 2014, Las Vegas will be the the "OpenSIPS" city!* > > > *Vlad Paiu - OpenSIPS core developer - */"OpenSIPS, a service enabler > for Asterisk//"/ > > By using OpenSIPS as a front-end for the Asterisk-based system, > additional/advanced SIP services can be enabled for the end-users. > OpenSIPS can act as an enabler for SIP SIMPLE (presence and IM), XCAP, > webRTC, TLS support, Parallel Registration, IRC-like chatting and > other end-user oriented services. > Aside the end-user service, OpenSIPS can address provider oriented > services like LCR and Gateway failover for the outbound traffic, LNP > and CNAME dipping, etc. > > > *Razvan Crainea ***- OpenSIPS core developer *- "*/Scaling Asterisk > with OpenSIPS"/ > > There is a huge number of successful Asterisk-based platforms which > need to grow beyond the "one-instance" stage. To grow/scale as > capacity or as geographical coverage. OpenSIPS provides the solution > for such platform - the typical OpenSIPS sandwich consists of a pool > of Asterisk servers between two OpenSIPS instances, on inbound and > outbound. > On the inbound side, OpenSIPS can solve the problem of doing SIP wise > balancing and redundancy for the Asterisk cluster, to ensure traffic > validation and shaping. Aside complex authentication mechanisms (as > digest, LDAP, IP based), the fronting OpenSIPS is responsible for > provide fraud detection and other various security tools. > On the outbound side, OpenSIPS takes care of complex routing logics to > PSTN carriers / GW, LCR, CNAME or LNP dipping. Traffic to carriers can > be CPS/CC controlled and accounted. The latest OpenSIPS version is > able to provide Quality based Routing towards carriers > > > And more speakers and even more topics to follow. See > http://www.opensips.org/Community/Summit-2014LasVegas-Schedule > > To *register for the event*, see > http://www.opensips.org/Community/Summit-Registration > > Participating the Astricon? Use the "astricon2014" discount code ;). > > > See you in Vegas, > -- > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simbad.k.m at gmail.com Wed Oct 8 06:49:21 2014 From: simbad.k.m at gmail.com (simbad) Date: Tue, 7 Oct 2014 21:49:21 -0700 (PDT) Subject: [OpenSIPS-Users] +sip.instance parameter is missing in 200 OK for REGISTER In-Reply-To: <5433C47F.1060507@opensips.org> References: <1411578172569-7593626.post@n2.nabble.com> <1412080436115-7593676.post@n2.nabble.com> <542E867C.5050504@opensips.org> <1412660123319-7593809.post@n2.nabble.com> <5433C47F.1060507@opensips.org> Message-ID: <1412743761353-7593839.post@n2.nabble.com> Hello Bodgan, Thanks for replying. Is there anyway to return sip.instance along with the 200OK. Thanks Simbad -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/sip-instance-parameter-is-missing-in-200-OK-for-REGISTER-tp7593626p7593839.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From bogdan at opensips.org Wed Oct 8 09:02:14 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 08 Oct 2014 10:02:14 +0300 Subject: [OpenSIPS-Users] +sip.instance parameter is missing in 200 OK for REGISTER In-Reply-To: <1412743761353-7593839.post@n2.nabble.com> References: <1411578172569-7593626.post@n2.nabble.com> <1412080436115-7593676.post@n2.nabble.com> <542E867C.5050504@opensips.org> <1412660123319-7593809.post@n2.nabble.com> <5433C47F.1060507@opensips.org> <1412743761353-7593839.post@n2.nabble.com> Message-ID: <5434E176.8080404@opensips.org> Hi Simbad, Not something straight. You can try and store that param into usrloc by hand (see attr_avp http://www.opensips.org/html/docs/modules/1.11.x/registrar.html#id293909) and get it back to lookup time. But it will be more mission impossible to add it to the 200OK reply as the Contact hdr in internally built by the registrar module (so you cannot come with your own changes from the script) :). Looks like some development should be needed to do that. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 08.10.2014 07:49, simbad wrote: > Hello Bodgan, > > Thanks for replying. Is there anyway to return sip.instance along with the > 200OK. > > Thanks > Simbad > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/sip-instance-parameter-is-missing-in-200-OK-for-REGISTER-tp7593626p7593839.html > Sent from the OpenSIPS - Users mailing list archive at Nabble.com. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From bogdan at opensips.org Wed Oct 8 10:16:50 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 08 Oct 2014 11:16:50 +0300 Subject: [OpenSIPS-Users] How to route to voicemail on destination busy? In-Reply-To: References: Message-ID: <5434F2F2.7060709@opensips.org> Hi Gary, You need to use a failure route (see http://www.opensips.org/Documentation/Script-Routes-1-11#toc3) in order to do the serial branching. See the config file generated by "make menuconfig" for the residential scenario - you will see there how to do a redirect on failure route. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 06.10.2014 23:07, Gary Nyquist wrote: > Hi, > > OpenSIPS routes a call to a SIP device (destination). > And (say) the device returns "486 BUSY" to OpenSIPS. > Now the call needs to be routed to the Voice-Mail server (another SIP device). > > How to do it in opensips.cfg? > Any ideas? > > Thanks. > Best Regards, > - Gary > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From razvan at opensips.org Wed Oct 8 10:18:18 2014 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Wed, 08 Oct 2014 11:18:18 +0300 Subject: [OpenSIPS-Users] ERROR:tm:t_check: INVITE reply cannot be parsed In-Reply-To: References: Message-ID: <5434F34A.80007@opensips.org> Hi, Alec! It is not a common problem, most likely your SIP message is not properly formed. Is that the only error you see related to that reply? Can you start a trace and check if the reply is a valid SIP message? Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 10/07/2014 02:14 AM, Alec Doran-Twyford wrote: > Hi all, > > I am getting this error "ERROR:tm:t_check: INVITE reply cannot be parsed" > when some make a call though our system. > > I am not sure where it came from I just wondering if anyone know some > common problem when this has happens? > it happen sometime after someone does an Invite from one of our > clients systems but not from our own. > > Alec Doran-Twyford > | Support Engineer for IVSTel | > | E-mail: a.dorantwyford at ivstel.com > | Skype: AlecDoranTwyford | > | Phone: +61 2 9288 8890 | Mob: +61 423 694 742 | > | LinkedIn | > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Oct 8 11:22:10 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 08 Oct 2014 12:22:10 +0300 Subject: [OpenSIPS-Users] Dialog ping fails with UDP, mhomed and virtual IP In-Reply-To: References: Message-ID: <54350242.4000307@opensips.org> Hi Patrick, Shortly, I found a flow in the logic of validating the send socket (the dialog module is forcing an send socket for the OPTIONS, taken from the dialog info). I made a fix on trunk/master - see: https://github.com/OpenSIPS/opensips/commit/c95ddd8f282c8809a0fae233bdb57b4dddb3c628.patch Could you test to see if this solves your problem ? If you need to backport the patch and have problems applying it, just let me know. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 24.09.2014 14:45, Patrick Wakano wrote: > Hello list, > > I was having a problem in which my Opensips was not sending the > Options of the dialog ping mechanism. After debuging I found out that > Opensips could not send it because it was not listening to the primary > IP of the interface. I am in a mhomed scenario and using Linux-HA so > the virtual IP managed by the heartbeat is the one Opensips listens > to. If I configured Opensips to listen to both IPs then the dialog > ping works. Also the problem only happens in UDP, if I use TCP then it > works fine too. > > I found this thread that may be related, but with the drouting module: > http://opensips.org/pipermail/users/2013-November/027203.html > So is this an Opensips error in the dialog module or should I face it > as a linux restriction? > > The following lines are printed on the log when the dialog ping fails: > /sbin/opensips[28392]: DBG:dialog:ref_dlg: ref dlg 0xb4e8e37c with 1 -> 4 > /sbin/opensips[28392]: DBG:dialog:send_leg_msg: sending [OPTIONS] to > caller (0) > /sbin/opensips[28392]: DBG:tm:t_uac: > next_hop=> > /sbin/opensips[28392]: DBG:core:mk_proxy: doing DNS lookup... > /sbin/opensips[28392]: ERROR:core:get_out_socket: no socket found > /sbin/opensips[28392]: ERROR:tm:t_uac: no corresponding socket for af 2 > /sbin/opensips[28392]: ERROR:dialog:send_leg_msg: failed to send the > in-dialog request > /sbin/opensips[28392]: ERROR:dialog:dlg_ping_routine: failed to ping > caller > /sbin/opensips[28392]: DBG:dialog:unref_dlg: unref dlg 0xb4e8e37c > with 1 -> 3 in entry 0xb4d24d74 > .... > /sbin/opensips[28392]: DBG:dialog:dlg_ping_routine: dialog > 0xb4e8e37c-1537054613 has expired > /sbin/opensips[28392]: DBG:dialog:init_dlg_term_reason: Setting DLG > term reason to [Ping Timeout] > /sbin/opensips[28392]: DBG:dialog:send_leg_bye: sending BYE to caller (0) > /sbin/opensips[28392]: DBG:dialog:ref_dlg: ref dlg 0xb4e8e37c with 1 -> 4 > /sbin/opensips[28392]: DBG:tm:t_uac: > next_hop=> > /sbin/opensips[28392]: DBG:core:mk_proxy: doing DNS lookup... > /sbin/opensips[28392]: ERROR:core:get_out_socket: no socket found > /sbin/opensips[28392]: ERROR:tm:t_uac: no corresponding socket for af 2 > /sbin/opensips[28392]: ERROR:dialog:send_leg_bye: failed to send the > BYE request > > Thanks! > > Patrick > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Oct 8 11:40:39 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 08 Oct 2014 12:40:39 +0300 Subject: [OpenSIPS-Users] Have one registration contact per device in usrloc In-Reply-To: References: Message-ID: <54350697.60100@opensips.org> Hi Jayesh, Basically you do not what to have more registrations from the same IP, right ? Exactly the opposit of the is_other_contact() function : http://www.opensips.org/html/docs/modules/1.11.x/registrar.html#id294660 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 01.10.2014 18:15, Jayesh Nambiar wrote: > Hi, > I am trying to solve a problem of having one registration per AOR per > device. So user 1234 can register from device A, device B and device > C. But the user 1234 should not have multiple contacts from device A > alone. > At times when the device loses network, proxy doesn't receive > de-register and the contact stays in opensips till its expiry time. So > the same device is thus capable of creating multiple contacts. I could > solve this by using "fc1" flag while doing a save("location") but I > need multiple registrations to be allowed from different devices !! > So is there a way where while doing a save("location"), I set some > sort of device id along with it such that I identify and overwrite the > existing contact only if the registration comes from same device-id or > else add it up for parallel forking. > Do let me know if I make sense here and there's a solution to this. > Thanks for any suggestions and directions. > > Thanks, > > --- Jayesh > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Wed Oct 8 11:56:24 2014 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Wed, 08 Oct 2014 12:56:24 +0300 Subject: [OpenSIPS-Users] RabbitMQ In-Reply-To: References: Message-ID: <54350A48.3000902@opensips.org> Hi, Levent! The E_ACC_CDR event is automatically triggered if you set the evi_flag[1] and cdr_flag[2] on your initial INVITEs. Also, the rabbitmq queue should be setup in the startup_route according to this example[3]. [1] http://www.opensips.org/html/docs/modules/1.12.x/acc#id295246 [2] http://www.opensips.org/html/docs/modules/1.12.x/acc#id295374 [3] http://www.opensips.org/html/docs/modules/devel/event_rabbitmq#id293516 Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 10/06/2014 05:36 PM, Levent Tinaz wrote: > Hi All, > > Collecting CDRs via rabbitMQ.., I am not clear about it. Do I need to > raise the event E_ACC_CDR manually in the script ? or this should be > done by ACC module automatically? > If it is automatic how can I do that? I really appreciate if you share > your ACC and RabbitMQ settings. > > Thanks. > > Levent Tinaz > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Oct 8 12:22:44 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 08 Oct 2014 13:22:44 +0300 Subject: [OpenSIPS-Users] dispatcher not doing fail over itself In-Reply-To: <20D5493C-5039-464D-B3BC-CDA798336311@gmail.com> References: <5417E3E4.3020000@opensips.org> <5418640B.2050105@opensips.org> <54193884.2060801@opensips.org> <541999F2.7090705@opensips.org> <541BE96E.9080403@opensips.org> <20D5493C-5039-464D-B3BC-CDA798336311@gmail.com> Message-ID: <54351074.5060405@opensips.org> Hi Satish, Could you add as extra flag to ds_select_xxx() the "M10" ? That will make the overall flags string "FM10". Try with that flags and let me know. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 20.09.2014 15:18, Satish Patel wrote: > Hey any clue? I'm using 1.12 version. > > -- > Sent from my iPhone > > On Sep 19, 2014, at 4:29 AM, Bogdan-Andrei Iancu > wrote: > >> dst is null as there is no pending destination for failover. cnt is 1. >> >> Which OpenSIPS revision are you using ? >> >> Regards, >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> On 17.09.2014 19:04, Satish Patel wrote: >>> I just trying to print $avp(271) $avp(272) and $avp(273) >>> >>> I am getting following output, why dst_avp is null ? and cnt_avp >>> should be 2 right? >>> >>> dst_avp = >>> grp_avp = 1 >>> cnt_avp = 0 >>> >>> Notes: I have both Freeswitch instance running on same box but >>> different port, do you think because of that it think it is single >>> host? >>> >>> PARTITION:: default >>> SET:: 1 >>> URI:: sip:sip.example.com:5061 >>> state=Active >>> URI:: sip:sip.example.com:5071 >>> state=Active >>> >>> >>> On Wed, Sep 17, 2014 at 11:06 AM, Satish Patel >> > wrote: >>> >>> Here you go >>> >>> >>> >>> >>> /sbin/opensips[28000]: Sending call to ===> Freeswitch >>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>> p=0x7f9ed01dd420, flags=0x0000 >>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>> #011#011#011name=<274> >>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>> #011#011#011id=<10> >>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>> #011#011#011val_int=<0> >>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>> p=0x7f9ed01df208, flags=0x0000 >>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>> #011#011#011name=<273> >>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: #011#011#011id=<9> >>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>> #011#011#011val_int=<1> >>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>> p=0x7f9ed01e6518, flags=0x0002 >>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>> #011#011#011name=<272> >>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>> #011#011#011id=<12> >>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>> #011#011#011val_str=< / 0> >>> /sbin/opensips[28000]: dispatcher: Attempting to dispatch call >>> to sip:182.xx.xx.xxx:5071 >>> /sbin/opensips[28005]: Inside dispatcher failure route >>> /sbin/opensips[28005]: ds_dispatcher > >>> /sbin/opensips[28005]: >>> R-DISPATCHER-ROLLOVER:fU4SNHMvcNmnjW19gsSj0g..-S No more >>> gateways in route set >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From acmicrox at gmail.com Wed Oct 8 12:49:40 2014 From: acmicrox at gmail.com (microx) Date: Wed, 8 Oct 2014 03:49:40 -0700 (PDT) Subject: [OpenSIPS-Users] db_text for domain table In-Reply-To: <5433FC28.40003@opensips.org> References: <1412581449829-7593779.post@n2.nabble.com> <5433EA04.4060106@opensips.org> <1412689612257-7593827.post@n2.nabble.com> <5433FC28.40003@opensips.org> Message-ID: <1412765380031-7593849.post@n2.nabble.com> Hi Bogdan-Andrei, I tried to copy the domain and db_text modules from 1.11 to 1.9 and ran ``make deb''. Unfortunately, it failed to create the deb with the following error message. Do I need to copy all the modules from 1.11 to 1.9 rather than only the domain/db_text modules? If so, it seems that I should install OpenSIPS 1.11 instead of 1.9 for addressing this issue. Best wishes, Chen-Che make[3]: Entering directory `/home/test/opensips-1.9.2-tls/modules/domain' Compiling api.c Compiling domain.c Compiling domain_mod.c Compiling hash.c Compiling mi.c mi.c: In function ?mi_domain_dump?: mi.c:67:26: error: ?MI_IS_ARRAY? undeclared (first use in this function) mi.c:67:26: note: each undeclared identifier is reported only once for each function it appears in make[3]: *** [mi.o] Error 1 -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/db-text-for-domain-table-tp7593779p7593849.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From satish.txt at gmail.com Wed Oct 8 15:42:41 2014 From: satish.txt at gmail.com (Satish Patel) Date: Wed, 8 Oct 2014 09:42:41 -0400 Subject: [OpenSIPS-Users] CDRTool prepaid for big installation Message-ID: Hi, Just want to know does CDRTool prepaid capable of handling couple hundreds of concurrent calls? I heard it can handle only 2/3 concurrent calls per account? what is the solution if we want to host big prepaid system with thousands of users? -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Wed Oct 8 16:07:24 2014 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Wed, 08 Oct 2014 17:07:24 +0300 Subject: [OpenSIPS-Users] OpenSIPS 1.11.3 and 1.10.3 Releases Message-ID: <5435451C.5000704@opensips.org> Hello all, Due to the lastest bug fixes we have done for OpenSIPS 1.11 and 1.10, we decided to make a new release for these versions. The new OpenSIPS 1.11.3 and 1.10.3 are scheduled for release next week. Please make sure you have reported all the bugs you faced as soon as possible! Thank you all for making this happen! Best regards, -- R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com From tito at xsvoce.com Wed Oct 8 16:23:31 2014 From: tito at xsvoce.com (Tito Cumpen) Date: Wed, 8 Oct 2014 10:23:31 -0400 Subject: [OpenSIPS-Users] OpenSIPS 1.11.3 and 1.10.3 Releases In-Reply-To: <5435451C.5000704@opensips.org> References: <5435451C.5000704@opensips.org> Message-ID: Razvan, Can you please provide a changelog so that redundant reports don't arise? Thanks, Tito On Oct 8, 2014 10:07 AM, "R?zvan Crainea" wrote: > Hello all, > > Due to the lastest bug fixes we have done for OpenSIPS 1.11 and 1.10, we > decided to make a new release for these versions. The new OpenSIPS 1.11.3 > and 1.10.3 are scheduled for release next week. > Please make sure you have reported all the bugs you faced as soon as > possible! > > Thank you all for making this happen! > > Best regards, > > -- > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayesh1017 at gmail.com Wed Oct 8 16:31:32 2014 From: jayesh1017 at gmail.com (Jayesh Nambiar) Date: Wed, 8 Oct 2014 20:01:32 +0530 Subject: [OpenSIPS-Users] Have one registration contact per device in usrloc In-Reply-To: <54350697.60100@opensips.org> References: <54350697.60100@opensips.org> Message-ID: Hi Bogdan, So I thought of doing this and I have another problem. Say if a device registered from IP 1.2.3.4, and then moved out to different network and re-registered from IP 4.3.2.1, there is a stale registration lying in opensips for the same device from 1.2.3.4. Now when I use TCP as transport, opensips waits till connect timed out on unreachable IPs before sending the call to registered contact and the following messages are logged in syslog: ERROR:core:tcp_blocking_connect: timeout 10 s elapsed from 10 s ERROR:core:tcpconn_connect: tcp_blocking_connect failed ERROR:core:tcp_send: connect failed ERROR:tm:msg_send: tcp_send failed Looks like opensips tries to do a TCP connect first with all registered contacts before actually routing the call. I do, modparam("registrar", "tcp_persistent_flag", "TCP_PERSISTENT") if(is_method("REGISTER")) { setflag(TCP_PERSISTENT); setbflag(30); if(!save("location", "fc1")) { t_reply("500", "Error while saving AOR"); } } --- Jayesh On Wed, Oct 8, 2014 at 3:10 PM, Bogdan-Andrei Iancu wrote: > Hi Jayesh, > > Basically you do not what to have more registrations from the same IP, > right ? > > Exactly the opposit of the is_other_contact() function : > > http://www.opensips.org/html/docs/modules/1.11.x/registrar.html#id294660 > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > On 01.10.2014 18:15, Jayesh Nambiar wrote: > > Hi, > I am trying to solve a problem of having one registration per AOR per > device. So user 1234 can register from device A, device B and device C. But > the user 1234 should not have multiple contacts from device A alone. > At times when the device loses network, proxy doesn't receive de-register > and the contact stays in opensips till its expiry time. So the same device > is thus capable of creating multiple contacts. I could solve this by using > "fc1" flag while doing a save("location") but I need multiple registrations > to be allowed from different devices !! > So is there a way where while doing a save("location"), I set some sort > of device id along with it such that I identify and overwrite the existing > contact only if the registration comes from same device-id or else add it > up for parallel forking. > Do let me know if I make sense here and there's a solution to this. > Thanks for any suggestions and directions. > > Thanks, > > --- Jayesh > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Wed Oct 8 17:20:07 2014 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Wed, 08 Oct 2014 18:20:07 +0300 Subject: [OpenSIPS-Users] OpenSIPS 1.11.3 and 1.10.3 Releases In-Reply-To: References: <5435451C.5000704@opensips.org> Message-ID: <54355627.10005@opensips.org> Hi, Tito! You can view the reports on GitHub[1]. I have committed some temporary ChangeLogs for 1.11.3[2] and 1.10.3[3]. [1] https://github.com/OpenSIPS/opensips/issues [2] https://github.com/OpenSIPS/opensips/blob/1.10/ChangeLog [3] https://github.com/OpenSIPS/opensips/blob/1.11/ChangeLog Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 10/08/2014 05:23 PM, Tito Cumpen wrote: > > Razvan, > > Can you please provide a changelog so that redundant reports don't arise? > > Thanks, > Tito > > On Oct 8, 2014 10:07 AM, "R?zvan Crainea" > wrote: > > Hello all, > > Due to the lastest bug fixes we have done for OpenSIPS 1.11 and > 1.10, we decided to make a new release for these versions. The new > OpenSIPS 1.11.3 and 1.10.3 are scheduled for release next week. > Please make sure you have reported all the bugs you faced as soon > as possible! > > Thank you all for making this happen! > > Best regards, > > -- > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From itsroot at gmail.com Wed Oct 8 19:39:25 2014 From: itsroot at gmail.com (neumann) Date: Wed, 8 Oct 2014 21:39:25 +0400 Subject: [OpenSIPS-Users] topology_hiding() + bye retransmissions Message-ID: <65E69419-9CC1-4BC1-BF5F-387BC1F855EB@gmail.com> http://lists.opensips.org/pipermail/users/2013-December/027518.html Hi all! I have same problem. I can?t handle BYE retransmissions with topology hiding because dialog destroying before retransmission. This will be fixed or workaround exist? ???????????? Timofeev Dmitry VoIP Engineer Linux, Asterisk, Freeswitch, Cisco solutions Skype: itsroot icq: 227227933 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwakano at gmail.com Wed Oct 8 22:12:13 2014 From: pwakano at gmail.com (Patrick Wakano) Date: Wed, 8 Oct 2014 17:12:13 -0300 Subject: [OpenSIPS-Users] Dialog ping fails with UDP, mhomed and virtual IP In-Reply-To: <54350242.4000307@opensips.org> References: <54350242.4000307@opensips.org> Message-ID: Hi Bogdan! Just tested your patch and it worked!!! Thanks a lot for your support!! Patrick On Wed, Oct 8, 2014 at 6:22 AM, Bogdan-Andrei Iancu wrote: > Hi Patrick, > > Shortly, I found a flow in the logic of validating the send socket (the > dialog module is forcing an send socket for the OPTIONS, taken from the > dialog info). > > I made a fix on trunk/master - see: > > https://github.com/OpenSIPS/opensips/commit/c95ddd8f282c8809a0fae233bdb57b4dddb3c628.patch > > Could you test to see if this solves your problem ? > > If you need to backport the patch and have problems applying it, just let > me know. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > On 24.09.2014 14:45, Patrick Wakano wrote: > > Hello list, > > I was having a problem in which my Opensips was not sending the Options > of the dialog ping mechanism. After debuging I found out that Opensips > could not send it because it was not listening to the primary IP of the > interface. I am in a mhomed scenario and using Linux-HA so the virtual IP > managed by the heartbeat is the one Opensips listens to. If I configured > Opensips to listen to both IPs then the dialog ping works. Also the problem > only happens in UDP, if I use TCP then it works fine too. > > I found this thread that may be related, but with the drouting module: > http://opensips.org/pipermail/users/2013-November/027203.html > So is this an Opensips error in the dialog module or should I face it as > a linux restriction? > > The following lines are printed on the log when the dialog ping fails: > /sbin/opensips[28392]: DBG:dialog:ref_dlg: ref dlg 0xb4e8e37c with 1 -> > 4 > /sbin/opensips[28392]: DBG:dialog:send_leg_msg: sending [OPTIONS] to > caller (0) > /sbin/opensips[28392]: DBG:tm:t_uac: next_hop= > > /sbin/opensips[28392]: DBG:core:mk_proxy: doing DNS lookup... > /sbin/opensips[28392]: ERROR:core:get_out_socket: no socket found > /sbin/opensips[28392]: ERROR:tm:t_uac: no corresponding socket for af 2 > /sbin/opensips[28392]: ERROR:dialog:send_leg_msg: failed to send the > in-dialog request > /sbin/opensips[28392]: ERROR:dialog:dlg_ping_routine: failed to ping > caller > /sbin/opensips[28392]: DBG:dialog:unref_dlg: unref dlg 0xb4e8e37c with 1 > -> 3 in entry 0xb4d24d74 > .... > /sbin/opensips[28392]: DBG:dialog:dlg_ping_routine: dialog > 0xb4e8e37c-1537054613 has expired > /sbin/opensips[28392]: DBG:dialog:init_dlg_term_reason: Setting DLG term > reason to [Ping Timeout] > /sbin/opensips[28392]: DBG:dialog:send_leg_bye: sending BYE to caller (0) > /sbin/opensips[28392]: DBG:dialog:ref_dlg: ref dlg 0xb4e8e37c with 1 -> 4 > /sbin/opensips[28392]: DBG:tm:t_uac: next_hop= > > /sbin/opensips[28392]: DBG:core:mk_proxy: doing DNS lookup... > /sbin/opensips[28392]: ERROR:core:get_out_socket: no socket found > /sbin/opensips[28392]: ERROR:tm:t_uac: no corresponding socket for af 2 > /sbin/opensips[28392]: ERROR:dialog:send_leg_bye: failed to send the BYE > request > > Thanks! > > Patrick > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alipey at gmail.com Wed Oct 8 23:06:41 2014 From: alipey at gmail.com (Ali Pey) Date: Wed, 8 Oct 2014 17:06:41 -0400 Subject: [OpenSIPS-Users] OpenSIPS/RTpProxy BridgeMode after failure route In-Reply-To: References: <52CA9503.5020100@opensips.org> Message-ID: Hello Salman, Can you please elaborate on how you got this working? I have the same problem and can't get it to work. In failure route, I do: unforce_rtp_proxy() Then when I have a new destination, I do: rtpproxy_offer("rocie"); However, I end up with messed up SDP, in my second invite. It doesn't remove the old IP addresses and only adds the IP addresses again: o=Sonus_UAC 9216 20203 IN IP4 10.160.11.16210.160.11.162a Capabilities c=IN IP4 10.160.11.16210.160.11.162udio 2311822970AVP 0 8 100 Please let me know how I can fix this. Thanks. On Mon, Jan 6, 2014 at 10:26 AM, Salman Zafar wrote: > Hi Razvan, > I got it working without branching, after banging head a lot I got > to learn unforcing drops the media ports for previous rtpproxy offer/answer > and after that directing the new flow though rtpproxy flags,IP media works. > I am able to traverse from eternal to internal play media and then on > failure do external to external with media flowing between public > interfaces. Just wondering if you know this method or certify. > > > > On Mon, Jan 6, 2014 at 4:35 PM, R?zvan Crainea > wrote: > >> Hi, Salman! >> >> The sockets used by RTPProxy are created when the session is started (the >> first offer) and cannot be updated afterwards. Therefore the only solution >> I can see is to configure a per branch scenario, as you mentioned. >> >> Best regards, >> >> Razvan Crainea >> OpenSIPS Core Developer >> http://www.opensips-solutions.com >> >> >> >> On 12/30/2013 01:11 PM, Salman Zafar wrote: >> >>> Hi, >>> I have a scenario of playing media at a private-ip media server and >>> send BUSY, next in failure route bridge call to a public IP. (SIP to >>> SIP). >>> >>> So the scenario is as follows: >>> >>> UA(Phone1) -> OpenSIPS/RTpProxy(ei) -> Media-Server (Private IP) -> BUSY >>> -> OpenSIPS(failure route) -> RTpProxy(ee) -> lookup -> (UA Phone2) >>> >>> Now the problem is RtpProxy is being offered (EI flags) in first case >>> where routing to Media sever at private IP, after failure it is again >>> used with (EE flags), also in corresponding replies. >>> >>> The second time RTpProxy does not effect SDP c= and ports in a way to >>> build media communication. SDP fix directly does not effect rtp ports. >>> >>> Is there any way of using RtpProxy differently in fail-over, or I have >>> to go for rtpproxy per branch?. >>> >>> >>> Thanks in advance. >>> >>> -- >>> Regards >>> >>> Salman >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> >>> >>> http://lists.opensips.org/cgi- >>> >>> bin/mailman/listinfo/users >>> >>> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> >> >> http://lists.opensips.org/cgi- >> >> bin/mailman/listinfo/users >> > > > > -- > Regards > > M. Salman Zafar > > VoIP Professional > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhouxiaoqiang.mstech at gmail.com Thu Oct 9 05:37:27 2014 From: zhouxiaoqiang.mstech at gmail.com (chow) Date: Wed, 8 Oct 2014 20:37:27 -0700 (PDT) Subject: [OpenSIPS-Users] branch computation failed Message-ID: <1412825847529-7593895.post@n2.nabble.com> Hi, I test performance of opensips. I use sipp do it. but, occur some error. here is the part of opensips's log : Oct 4 00:10:03 localhost /usr/sbin/opensips[18546]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 4 00:10:03 localhost /usr/sbin/opensips[18546]: ERROR:tm:t_forward_nonack: failure to add branches Oct 4 00:10:03 localhost /usr/sbin/opensips[18482]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 4 00:10:03 localhost /usr/sbin/opensips[18482]: ERROR:tm:t_forward_nonack: failure to add branches Oct 4 00:10:04 localhost /usr/sbin/opensips[18557]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 4 00:10:04 localhost /usr/sbin/opensips[18557]: ERROR:tm:t_forward_nonack: failure to add branches Oct 4 00:10:04 localhost /usr/sbin/opensips[18467]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 4 00:10:04 localhost /usr/sbin/opensips[18467]: ERROR:tm:t_forward_nonack: failure to add branches Oct 4 00:10:28 localhost /usr/sbin/opensips[18500]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 4 00:10:28 localhost /usr/sbin/opensips[18500]: ERROR:tm:t_forward_nonack: failure to add branches Oct 4 00:10:35 localhost /usr/sbin/opensips[18502]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 4 00:10:35 localhost /usr/sbin/opensips[18502]: ERROR:tm:t_forward_nonack: failure to add branches Oct 4 00:10:35 localhost /usr/sbin/opensips[18477]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 4 00:10:35 localhost /usr/sbin/opensips[18477]: ERROR:tm:t_forward_nonack: failure to add branches -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/branch-computation-failed-tp7593895.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From msalman212 at gmail.com Thu Oct 9 07:36:51 2014 From: msalman212 at gmail.com (Salman Zafar) Date: Thu, 9 Oct 2014 10:36:51 +0500 Subject: [OpenSIPS-Users] OpenSIPS/RTpProxy BridgeMode after failure route In-Reply-To: References: <52CA9503.5020100@opensips.org> Message-ID: Hi Ali, As per your logs connection and owner SDP strings are written twice, which shows rtpproxy was called twice in result it concatenated multiple IP addresses in SDP. I would look in to the following: 1) try unforce in the main route just before new rtpproxy_offer("rocie") function call (instead of failure route). Can be easily done logically. 2) Check version of RTPproxy, if it complies with the rtpproxy devel module documentation. 3) The similar scenario can also be achieved by handling rtpproxy per branch, but it is slightly off the topic. 4) Assuming you are handling Offer/Answer approach correctly for media. Best Regards Salman VoIP Professional On Thu, Oct 9, 2014 at 2:06 AM, Ali Pey wrote: > Hello Salman, > > Can you please elaborate on how you got this working? I have the same > problem and can't get it to work. > > In failure route, I do: > unforce_rtp_proxy() > Then when I have a new destination, I do: > rtpproxy_offer("rocie"); > > However, I end up with messed up SDP, in my second invite. It doesn't > remove the old IP addresses and only adds the IP addresses again: > o=Sonus_UAC 9216 20203 IN IP4 10.160.11.16210.160.11.162a Capabilities > c=IN IP4 10.160.11.16210.160.11.162udio 2311822970AVP 0 8 100 > > > Please let me know how I can fix this. > > Thanks. > > > On Mon, Jan 6, 2014 at 10:26 AM, Salman Zafar > wrote: > >> Hi Razvan, >> I got it working without branching, after banging head a lot I >> got to learn unforcing drops the media ports for previous rtpproxy >> offer/answer and after that directing the new flow though rtpproxy flags,IP >> media works. I am able to traverse from eternal to internal play media and >> then on failure do external to external with media flowing between public >> interfaces. Just wondering if you know this method or certify. >> >> >> >> On Mon, Jan 6, 2014 at 4:35 PM, R?zvan Crainea >> wrote: >> >>> Hi, Salman! >>> >>> The sockets used by RTPProxy are created when the session is started >>> (the first offer) and cannot be updated afterwards. Therefore the only >>> solution I can see is to configure a per branch scenario, as you mentioned. >>> >>> Best regards, >>> >>> Razvan Crainea >>> OpenSIPS Core Developer >>> http://www.opensips-solutions.com >>> >>> >>> >>> On 12/30/2013 01:11 PM, Salman Zafar wrote: >>> >>>> Hi, >>>> I have a scenario of playing media at a private-ip media server and >>>> send BUSY, next in failure route bridge call to a public IP. (SIP to >>>> SIP). >>>> >>>> So the scenario is as follows: >>>> >>>> UA(Phone1) -> OpenSIPS/RTpProxy(ei) -> Media-Server (Private IP) -> BUSY >>>> -> OpenSIPS(failure route) -> RTpProxy(ee) -> lookup -> (UA Phone2) >>>> >>>> Now the problem is RtpProxy is being offered (EI flags) in first case >>>> where routing to Media sever at private IP, after failure it is again >>>> used with (EE flags), also in corresponding replies. >>>> >>>> The second time RTpProxy does not effect SDP c= and ports in a way to >>>> build media communication. SDP fix directly does not effect rtp ports. >>>> >>>> Is there any way of using RtpProxy differently in fail-over, or I have >>>> to go for rtpproxy per branch?. >>>> >>>> >>>> Thanks in advance. >>>> >>>> -- >>>> Regards >>>> >>>> Salman >>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> >>>> >>>> http://lists.opensips.org/cgi- >>>> >>>> bin/mailman/listinfo/users >>>> >>>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> >>> >>> http://lists.opensips.org/cgi- >>> >>> bin/mailman/listinfo/users >>> >> >> >> >> -- >> Regards >> >> M. Salman Zafar >> >> VoIP Professional >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- Regards M. Salman Zafar VoIP Professional -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayesh1017 at gmail.com Thu Oct 9 08:19:33 2014 From: jayesh1017 at gmail.com (Jayesh Nambiar) Date: Thu, 9 Oct 2014 11:49:33 +0530 Subject: [OpenSIPS-Users] Have one registration contact per device in usrloc In-Reply-To: References: <54350697.60100@opensips.org> Message-ID: Hello, Wanted to correct the message below: I had added fc1 in the save("location") after I got this problem to avoid more than one registration. Before adding fc1, i had this problem of TCP timeout. Sorry for the wrong info. --- Jayesh On Wed, Oct 8, 2014 at 8:01 PM, Jayesh Nambiar wrote: > Hi Bogdan, > So I thought of doing this and I have another problem. Say if a device > registered from IP 1.2.3.4, and then moved out to different network and > re-registered from IP 4.3.2.1, there is a stale registration lying in > opensips for the same device from 1.2.3.4. > Now when I use TCP as transport, opensips waits till connect timed out on > unreachable IPs before sending the call to registered contact and the > following messages are logged in syslog: > ERROR:core:tcp_blocking_connect: timeout 10 s elapsed from 10 s > ERROR:core:tcpconn_connect: tcp_blocking_connect failed > ERROR:core:tcp_send: connect failed > ERROR:tm:msg_send: tcp_send failed > > Looks like opensips tries to do a TCP connect first with all registered > contacts before actually routing the call. > I do, > modparam("registrar", "tcp_persistent_flag", "TCP_PERSISTENT") > > if(is_method("REGISTER")) { > setflag(TCP_PERSISTENT); > setbflag(30); > if(!save("location", "fc1")) { > t_reply("500", "Error while saving AOR"); > } > } > > --- Jayesh > > > > > > > On Wed, Oct 8, 2014 at 3:10 PM, Bogdan-Andrei Iancu > wrote: > >> Hi Jayesh, >> >> Basically you do not what to have more registrations from the same IP, >> right ? >> >> Exactly the opposit of the is_other_contact() function : >> >> http://www.opensips.org/html/docs/modules/1.11.x/registrar.html#id294660 >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >> >> On 01.10.2014 18:15, Jayesh Nambiar wrote: >> >> Hi, >> I am trying to solve a problem of having one registration per AOR per >> device. So user 1234 can register from device A, device B and device C. But >> the user 1234 should not have multiple contacts from device A alone. >> At times when the device loses network, proxy doesn't receive >> de-register and the contact stays in opensips till its expiry time. So the >> same device is thus capable of creating multiple contacts. I could solve >> this by using "fc1" flag while doing a save("location") but I need multiple >> registrations to be allowed from different devices !! >> So is there a way where while doing a save("location"), I set some sort >> of device id along with it such that I identify and overwrite the existing >> contact only if the registration comes from same device-id or else add it >> up for parallel forking. >> Do let me know if I make sense here and there's a solution to this. >> Thanks for any suggestions and directions. >> >> Thanks, >> >> --- Jayesh >> >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaandandin at yahoo.com Thu Oct 9 09:00:40 2014 From: kaandandin at yahoo.com (Kaan Dandin) Date: Thu, 09 Oct 2014 10:00:40 +0300 Subject: [OpenSIPS-Users] YNT: Re: RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE Message-ID: Hi Bogdan,? Thanks for your response.? In this situation how can I configure opensips to pass this message to the destination. Is it a configuration change or should I use another function instead of t_relay ? Kind regards Samsung Mobile taraf?ndan g?nderildi
-------- Orjinal mesaj --------
Kimden: Bogdan-Andrei Iancu
Tarih:07 10 2014 16:29 (GMT+02:00)
Al?c?: Kaan Dandin ,OpenSIPS users mailling list
Cc:
Konu: Re: [OpenSIPS-Users] RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE
Hi Kaan, The log you refer to is a DBG and not an ERR (error) - when a new request is received, opensips (inside the t_relay) tries to match it against existing transactions to see if it a retransmission on not. The fact your request does not match means it is not a retransmission, but rather a new request. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 04.10.2014 11:18, Kaan Dandin wrote: Hi all, I am making registration to the Open IMS nodes(192.168.2.3 and 192.168.2.5) simultaneously from IMS bench(192.168.2.11). Registration messages are going through OpenSIPS load balancer(192.168.2.141). Registration messages which are going to first Open IMS node(192.168.2.5) completed succesfully. But registration to second IMS node(192.168.2.3) is not completed successfully since t_relay() function in OpenSIPS load balancer is giving "DBG:tm:matching_3261: RFC3261 transaction matching failed" error and not passing the "Status: 401 Unauthorized - Challenging the UE (0 bindings)" messages to IMS bench. Below please find wireshark log and opensips logs in debug level=6. Do you have any idea for this problem. BR, Kaan o. Time Source Destination Protocol Info 55 1.186495 192.168.2.11 192.168.2.141 SIP Request: REGISTER sip:open-ims.test 56 1.188443 192.168.2.141 192.168.2.3 SIP Request: REGISTER sip:open-ims.test 57 1.189001 192.168.2.141 192.168.2.5 SIP Request: REGISTER sip:open-ims.test 58 1.215792 192.168.2.5 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) 59 1.216974 192.168.2.141 192.168.2.11 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) 60 1.217486 192.168.2.11 192.168.2.141 SIP Request: REGISTER sip:open-ims.test 61 1.218516 192.168.2.141 192.168.2.3 SIP Request: REGISTER sip:open-ims.test 62 1.218804 192.168.2.141 192.168.2.5 SIP Request: REGISTER sip:open-ims.test 63 1.233561 192.168.2.3 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) 64 1.241624 192.168.2.3 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) 65 1.246112 192.168.2.5 192.168.2.141 SIP Status: 200 OK - SAR succesful and registrar saved (1 bindings) 66 1.246919 192.168.2.141 192.168.2.11 SIP Status: 200 OK - SAR succesful and registrar saved (1 bindings) Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: xlog method: [REGISTER] totag: [] sipid: [192.168.2.11] messageid: [68] callid: [56-6888 at 192.168.2.11] callsequence: [2] Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:uri:has_totag: no totag Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: xlog_initialregister Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:comp_scriptvar: str 20 : 192.168.2.11 Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:t_newtran: transaction on entrance=0xffffffffffffffff Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:parse_headers: flags=ffffffffffffffff Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:get_hdr_field: content_length=0 Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:get_hdr_field: found end of header Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:parse_headers: flags=78 Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:t_lookup_request: start searching: hash=35746, isACK=0 Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:matching_3261: RFC3261 transaction matching failed Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:t_lookup_request: no transaction found Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:run_reqin_callbacks: trans=0x7fcda4739918, callback type 1, id 1 entered Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:run_reqin_callbacks: trans=0x7fcda4739918, callback type 1, id 0 entered Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:check_ip_address: params 192.168.2.11, 192.168.2.11, 0 _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Thu Oct 9 09:31:17 2014 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Thu, 09 Oct 2014 10:31:17 +0300 Subject: [OpenSIPS-Users] OpenSIPS/RTpProxy BridgeMode after failure route In-Reply-To: References: <52CA9503.5020100@opensips.org> Message-ID: <543639C5.1090705@opensips.org> Hi, Ali! For the initial branch (in request route) are you using engage_rtpproxy()? If so, try to use rtpproxy_offer(). Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 10/09/2014 12:06 AM, Ali Pey wrote: > Hello Salman, > > Can you please elaborate on how you got this working? I have the same > problem and can't get it to work. > > In failure route, I do: > unforce_rtp_proxy() > Then when I have a new destination, I do: > rtpproxy_offer("rocie"); > > However, I end up with messed up SDP, in my second invite. It doesn't > remove the old IP addresses and only adds the IP addresses again: > o=Sonus_UAC 9216 20203 IN IP4 10.160.11.16210.160.11.162a Capabilities > c=IN IP4 10.160.11.16210.160.11.162udio 2311822970AVP 0 8 100 > > > Please let me know how I can fix this. > > Thanks. > > > On Mon, Jan 6, 2014 at 10:26 AM, Salman Zafar > wrote: > > Hi Razvan, > I got it working without branching, after banging head a > lot I got to learn unforcing drops the media ports for previous > rtpproxy offer/answer and after that directing the new flow though > rtpproxy flags,IP media works. I am able to traverse from eternal > to internal play media and then on failure do external to external > with media flowing between public interfaces. Just wondering if > you know this method or certify. > > > > On Mon, Jan 6, 2014 at 4:35 PM, R?zvan Crainea > > wrote: > > Hi, Salman! > > The sockets used by RTPProxy are created when the session is > started (the first offer) and cannot be updated afterwards. > Therefore the only solution I can see is to configure a per > branch scenario, as you mentioned. > > Best regards, > > Razvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > > > > On 12/30/2013 01:11 PM, Salman Zafar wrote: > > Hi, > I have a scenario of playing media at a private-ip > media server and > send BUSY, next in failure route bridge call to a public > IP. (SIP to SIP). > > So the scenario is as follows: > > UA(Phone1) -> OpenSIPS/RTpProxy(ei) -> Media-Server > (Private IP) -> BUSY > -> OpenSIPS(failure route) -> RTpProxy(ee) -> lookup -> > (UA Phone2) > > Now the problem is RtpProxy is being offered (EI flags) in > first case > where routing to Media sever at private IP, after failure > it is again > used with (EE flags), also in corresponding replies. > > The second time RTpProxy does not effect SDP c= and ports > in a way to > build media communication. SDP fix directly does not > effect rtp ports. > > Is there any way of using RtpProxy differently in > fail-over, or I have > to go for rtpproxy per branch?. > > > Thanks in advance. > > -- > Regards > > Salman > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi- > bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi- > bin/mailman/listinfo/users > > > > > -- > Regards > > M. Salman Zafar > > VoIP Professional > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Thu Oct 9 11:06:49 2014 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Thu, 09 Oct 2014 12:06:49 +0300 Subject: [OpenSIPS-Users] event_rabbitmq sending errors In-Reply-To: References: , <542D065B.6030509@opensips.org> , <542E67C8.80309@opensips.org> Message-ID: <54365029.8020302@opensips.org> Hi, Gary! Can you try to apply this patch[1] to your module? It displays the reason why the RabbitMQ module disconnects from the server. [1] https://gist.github.com/razvancrainea/e32132a502db8c34e7e5 Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 10/03/2014 06:42 PM, Gary Nyquist wrote: > librabbitmq-0.5.0 > > > Best Regards, > - Gary > > >> Sent: Friday, October 03, 2014 at 5:09 AM >> From: "R?zvan Crainea" >> To: users at lists.opensips.org >> Subject: Re: [OpenSIPS-Users] event_rabbitmq sending errors >> >> And what is the version of the rabbitmq library? >> >> Best regards, >> >> R?zvan Crainea >> OpenSIPS Solutions >> www.opensips-solutions.com >> >> On 10/02/2014 11:36 PM, Gary Nyquist wrote: >>> R?zvan, >>> >>> Yes, that's the only error showing up (related to rabbitmq). >>> >>> [...]# opensips -V >>> version: opensips 1.11.2-tls (x86_64/linux) >>> flags: STATS: On, USE_IPV6, USE_TCP, USE_TLS, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT >>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 >>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. >>> git revision: 5708ad4 >>> main.c compiled on 19:10:09 Jul 16 2014 with gcc 4.4.7 >>> >>> Tried with setting the heartbeat module parameter to 1. >>> No change :( >>> >>> Best Regards, >>> - Gary >>> >>> >>> >>> Sent: Thursday, October 02, 2014 at 4:01 AM >>> From: "R?zvan Crainea" >>> To: users at lists.opensips.org >>> Subject: Re: [OpenSIPS-Users] event_rabbitmq sending errors >>> >>> Hi, Gary! >>> >>> That's the only error you see in the logs related to raise_event()? >>> What version of OpenSIPS you're using? Have you tried setting the heartbeat module parameter[1] to 1? >>> >>> [1] http://www.opensips.org/html/docs/modules/1.12.x/event_rabbitmq#id293418 >>> >>> PS: please add a relevant subject when starting a new thread. >>> >>> Best regards, >>> R?zvan Crainea >>> OpenSIPS Solutionswww.opensips-solutions.com[http://www.opensips-solutions.com] >>> On 10/01/2014 08:22 PM, Gary Nyquist wrote: >>> >>> Hi, >>> >>> I am using the "event_rabbitmq Module" to "raise_event". >>> It works fine. >>> >>> If "raise_event" is not used for a long time, perhaps the MQ socket is getting closed. >>> The following message is appearing in the log: >>> ERROR:event_rabbitmq:rmq_process: cannot send message >>> >>> What is a good way to keep the MQ connection alive? >>> Any ideas? >>> >>> Regards >>> -Gary >>> _______________________________________________ >>> Users mailing listUsers at lists.opensips.org[Users at lists.opensips.org]http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users[http://lists.opensips.org/cgi-bin/mailman/listinfo/users] >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From zhouxiaoqiang.mstech at gmail.com Thu Oct 9 11:36:58 2014 From: zhouxiaoqiang.mstech at gmail.com (chow) Date: Thu, 9 Oct 2014 02:36:58 -0700 (PDT) Subject: [OpenSIPS-Users] branch computation failed In-Reply-To: <1412825847529-7593895.post@n2.nabble.com> References: <1412825847529-7593895.post@n2.nabble.com> Message-ID: <1412847418757-7593902.post@n2.nabble.com> Hi All : please , have someone help me? -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/branch-computation-failed-tp7593895p7593902.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From bogdan at opensips.org Thu Oct 9 12:32:36 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 09 Oct 2014 13:32:36 +0300 Subject: [OpenSIPS-Users] Have one registration contact per device in usrloc In-Reply-To: References: <54350697.60100@opensips.org> Message-ID: <54366444.70608@opensips.org> Hi Jayesh, Maybe you should look into GRUU stuff ;). On the TCP error - even if you set the TCP persistence flag, the UAC may close the TCP conn -> you end up in the same situation. What you can do is to prevent OpenSIPS to open TCP conns when routing to end-users - the idea is to have end-users connecting to OpenSIPS and not the other way around. See "tcp_no_new_conn_bflag" : http://www.opensips.org/Documentation/Script-CoreParameters-1-11#toc96 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 08.10.2014 17:31, Jayesh Nambiar wrote: > Hi Bogdan, > So I thought of doing this and I have another problem. Say if a device > registered from IP 1.2.3.4, and then moved out to different network > and re-registered from IP 4.3.2.1, there is a stale registration lying > in opensips for the same device from 1.2.3.4. > Now when I use TCP as transport, opensips waits till connect timed out > on unreachable IPs before sending the call to registered contact and > the following messages are logged in syslog: > ERROR:core:tcp_blocking_connect: timeout 10 s elapsed from 10 s > ERROR:core:tcpconn_connect: tcp_blocking_connect failed > ERROR:core:tcp_send: connect failed > ERROR:tm:msg_send: tcp_send failed > > Looks like opensips tries to do a TCP connect first with all > registered contacts before actually routing the call. > I do, > modparam("registrar", "tcp_persistent_flag", "TCP_PERSISTENT") > > if(is_method("REGISTER")) { > setflag(TCP_PERSISTENT); > setbflag(30); > if(!save("location", "fc1")) { > t_reply("500", "Error while saving AOR"); > } > } > > --- Jayesh > > > > > > > On Wed, Oct 8, 2014 at 3:10 PM, Bogdan-Andrei Iancu > > wrote: > > Hi Jayesh, > > Basically you do not what to have more registrations from the same > IP, right ? > > Exactly the opposit of the is_other_contact() function : > http://www.opensips.org/html/docs/modules/1.11.x/registrar.html#id294660 > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 01.10.2014 18:15, Jayesh Nambiar wrote: >> Hi, >> I am trying to solve a problem of having one registration per AOR >> per device. So user 1234 can register from device A, device B and >> device C. But the user 1234 should not have multiple contacts >> from device A alone. >> At times when the device loses network, proxy doesn't receive >> de-register and the contact stays in opensips till its expiry >> time. So the same device is thus capable of creating multiple >> contacts. I could solve this by using "fc1" flag while doing a >> save("location") but I need multiple registrations to be allowed >> from different devices !! >> So is there a way where while doing a save("location"), I set >> some sort of device id along with it such that I identify and >> overwrite the existing contact only if the registration comes >> from same device-id or else add it up for parallel forking. >> Do let me know if I make sense here and there's a solution to >> this. Thanks for any suggestions and directions. >> >> Thanks, >> >> --- Jayesh >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Oct 9 12:38:51 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 09 Oct 2014 13:38:51 +0300 Subject: [OpenSIPS-Users] Dialog ping fails with UDP, mhomed and virtual IP In-Reply-To: References: <54350242.4000307@opensips.org> Message-ID: <543665BB.4090603@opensips.org> Hi Patrick, Thanks for testing - I did the backport to 1.11 too. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 08.10.2014 23:12, Patrick Wakano wrote: > Hi Bogdan! > Just tested your patch and it worked!!! > > Thanks a lot for your support!! > > Patrick > > On Wed, Oct 8, 2014 at 6:22 AM, Bogdan-Andrei Iancu > > wrote: > > Hi Patrick, > > Shortly, I found a flow in the logic of validating the send socket > (the dialog module is forcing an send socket for the OPTIONS, > taken from the dialog info). > > I made a fix on trunk/master - see: > https://github.com/OpenSIPS/opensips/commit/c95ddd8f282c8809a0fae233bdb57b4dddb3c628.patch > > Could you test to see if this solves your problem ? > > If you need to backport the patch and have problems applying it, > just let me know. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 24.09.2014 14:45, Patrick Wakano wrote: >> Hello list, >> >> I was having a problem in which my Opensips was not sending the >> Options of the dialog ping mechanism. After debuging I found out >> that Opensips could not send it because it was not listening to >> the primary IP of the interface. I am in a mhomed scenario and >> using Linux-HA so the virtual IP managed by the heartbeat is the >> one Opensips listens to. If I configured Opensips to listen to >> both IPs then the dialog ping works. Also the problem only >> happens in UDP, if I use TCP then it works fine too. >> >> I found this thread that may be related, but with the drouting >> module: >> http://opensips.org/pipermail/users/2013-November/027203.html >> So is this an Opensips error in the dialog module or should I >> face it as a linux restriction? >> >> The following lines are printed on the log when the dialog ping >> fails: >> /sbin/opensips[28392]: DBG:dialog:ref_dlg: ref dlg 0xb4e8e37c >> with 1 -> 4 >> /sbin/opensips[28392]: DBG:dialog:send_leg_msg: sending >> [OPTIONS] to caller (0) >> /sbin/opensips[28392]: DBG:tm:t_uac: >> next_hop=> > >> /sbin/opensips[28392]: DBG:core:mk_proxy: doing DNS lookup... >> /sbin/opensips[28392]: ERROR:core:get_out_socket: no socket found >> /sbin/opensips[28392]: ERROR:tm:t_uac: no corresponding socket >> for af 2 >> /sbin/opensips[28392]: ERROR:dialog:send_leg_msg: failed to send >> the in-dialog request >> /sbin/opensips[28392]: ERROR:dialog:dlg_ping_routine: failed to >> ping caller >> /sbin/opensips[28392]: DBG:dialog:unref_dlg: unref dlg >> 0xb4e8e37c with 1 -> 3 in entry 0xb4d24d74 >> .... >> /sbin/opensips[28392]: DBG:dialog:dlg_ping_routine: dialog >> 0xb4e8e37c-1537054613 has expired >> /sbin/opensips[28392]: DBG:dialog:init_dlg_term_reason: Setting >> DLG term reason to [Ping Timeout] >> /sbin/opensips[28392]: DBG:dialog:send_leg_bye: sending BYE to >> caller (0) >> /sbin/opensips[28392]: DBG:dialog:ref_dlg: ref dlg 0xb4e8e37c >> with 1 -> 4 >> /sbin/opensips[28392]: DBG:tm:t_uac: >> next_hop=> > >> /sbin/opensips[28392]: DBG:core:mk_proxy: doing DNS lookup... >> /sbin/opensips[28392]: ERROR:core:get_out_socket: no socket found >> /sbin/opensips[28392]: ERROR:tm:t_uac: no corresponding socket >> for af 2 >> /sbin/opensips[28392]: ERROR:dialog:send_leg_bye: failed to send >> the BYE request >> >> Thanks! >> >> Patrick >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Oct 9 12:45:10 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 09 Oct 2014 13:45:10 +0300 Subject: [OpenSIPS-Users] YNT: Re: RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE In-Reply-To: References: Message-ID: <54366736.6090607@opensips.org> Hi, Is .141 your OpenSIPS ? I see .141 is sending the REGISTRAR to both nodes ( .3 and .5) . Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 09.10.2014 10:00, Kaan Dandin wrote: > Hi Bogdan, > > Thanks for your response. > In this situation how can I configure opensips to pass this message to > the destination. Is it a configuration change or should I use another > function instead of t_relay ? > > > Kind regards > > > Samsung Mobile taraf?ndan g?nderildi > > > -------- Orjinal mesaj -------- > Kimden: Bogdan-Andrei Iancu > Tarih:07 10 2014 16:29 (GMT+02:00) > Al?c?: Kaan Dandin ,OpenSIPS users mailling list > > Cc: > Konu: Re: [OpenSIPS-Users] RFC3261 transaction matching failed error > for the second 401 Unauthorized - Challenging the UE > > Hi Kaan, > > The log you refer to is a DBG and not an ERR (error) - when a new > request is received, opensips (inside the t_relay) tries to match it > against existing transactions to see if it a retransmission on not. > The fact your request does not match means it is not a retransmission, > but rather a new request. > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 04.10.2014 11:18, Kaan Dandin wrote: >> Hi all, >> I am making registration to the Open IMS nodes(192.168.2.3 and >> 192.168.2.5) simultaneously from IMS bench(192.168.2.11). >> Registration messages are going through OpenSIPS load >> balancer(192.168.2.141). >> Registration messages which are going to first Open IMS >> node(192.168.2.5) completed succesfully. >> But registration to second IMS node(192.168.2.3) is not completed >> successfully since t_relay() function in OpenSIPS load balancer is >> giving "DBG:tm:matching_3261: RFC3261 transaction matching failed" >> error and not passing the "Status: 401 Unauthorized - Challenging the >> UE (0 bindings)" messages to IMS bench. >> Below please find wireshark log and opensips logs in debug level=6. >> Do you have any idea for this problem. >> BR, >> Kaan >> o. Time Source Destination Protocol Info >> 55 1.186495 192.168.2.11 192.168.2.141 SIP >> Request: REGISTER sip:open-ims.test >> 56 1.188443 192.168.2.141 192.168.2.3 SIP >> Request: REGISTER sip:open-ims.test >> 57 1.189001 192.168.2.141 192.168.2.5 SIP >> Request: REGISTER sip:open-ims.test >> 58 1.215792 192.168.2.5 192.168.2.141 SIP >> Status: 401 Unauthorized - Challenging the UE (0 bindings) >> 59 1.216974 192.168.2.141 192.168.2.11 SIP >> Status: 401 Unauthorized - Challenging the UE (0 bindings) >> 60 1.217486 192.168.2.11 192.168.2.141 SIP >> Request: REGISTER sip:open-ims.test >> 61 1.218516 192.168.2.141 192.168.2.3 SIP >> Request: REGISTER sip:open-ims.test >> 62 1.218804 192.168.2.141 192.168.2.5 SIP >> Request: REGISTER sip:open-ims.test >> 63 1.233561 192.168.2.3 192.168.2.141 SIP >> Status: 401 Unauthorized - Challenging the UE (0 bindings) >> 64 1.241624 192.168.2.3 192.168.2.141 SIP >> Status: 401 Unauthorized - Challenging the UE (0 bindings) >> 65 1.246112 192.168.2.5 192.168.2.141 SIP >> Status: 200 OK - SAR succesful and registrar saved (1 bindings) >> 66 1.246919 192.168.2.141 192.168.2.11 SIP >> Status: 200 OK - SAR succesful and registrar saved (1 bindings) >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: xlog >> method: [REGISTER] totag: [] sipid: [192.168.2.11] messageid: >> [68] callid: [56-6888 at 192.168.2.11] callsequence: [2] >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:uri:has_totag: no totag >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> xlog_initialregister >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:core:comp_scriptvar: str 20 : 192.168.2.11 >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:tm:t_newtran: transaction on entrance=0xffffffffffffffff >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:core:parse_headers: flags=ffffffffffffffff >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:core:get_hdr_field: content_length=0 >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:core:get_hdr_field: found end of header >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:core:parse_headers: flags=78 >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:tm:t_lookup_request: start searching: hash=35746, isACK=0 >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:tm:matching_3261: RFC3261 transaction matching failed >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:tm:t_lookup_request: no transaction found >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:tm:run_reqin_callbacks: trans=0x7fcda4739918, callback type 1, id >> 1 entered >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:tm:run_reqin_callbacks: trans=0x7fcda4739918, callback type 1, id >> 0 entered >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:core:check_ip_address: params 192.168.2.11, 192.168.2.11, 0 >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Oct 9 12:53:17 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 09 Oct 2014 13:53:17 +0300 Subject: [OpenSIPS-Users] branch computation failed In-Reply-To: <1412825847529-7593895.post@n2.nabble.com> References: <1412825847529-7593895.post@n2.nabble.com> Message-ID: <5436691D.4010006@opensips.org> Hi, Do you use any special settings for the TM module, like changing hash table size or the syn_branch param ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 09.10.2014 06:37, chow wrote: > Hi, I test performance of opensips. I use sipp do it. but, occur some error. > here is the part of opensips's log : > > Oct 4 00:10:03 localhost /usr/sbin/opensips[18546]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 4 00:10:03 localhost /usr/sbin/opensips[18546]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 4 00:10:03 localhost /usr/sbin/opensips[18482]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 4 00:10:03 localhost /usr/sbin/opensips[18482]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 4 00:10:04 localhost /usr/sbin/opensips[18557]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 4 00:10:04 localhost /usr/sbin/opensips[18557]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 4 00:10:04 localhost /usr/sbin/opensips[18467]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 4 00:10:04 localhost /usr/sbin/opensips[18467]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 4 00:10:28 localhost /usr/sbin/opensips[18500]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 4 00:10:28 localhost /usr/sbin/opensips[18500]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 4 00:10:35 localhost /usr/sbin/opensips[18502]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 4 00:10:35 localhost /usr/sbin/opensips[18502]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 4 00:10:35 localhost /usr/sbin/opensips[18477]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 4 00:10:35 localhost /usr/sbin/opensips[18477]: > ERROR:tm:t_forward_nonack: failure to add branches > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/branch-computation-failed-tp7593895.html > Sent from the OpenSIPS - Users mailing list archive at Nabble.com. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > From bogdan at opensips.org Thu Oct 9 13:00:10 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 09 Oct 2014 14:00:10 +0300 Subject: [OpenSIPS-Users] topology_hiding() + bye retransmissions In-Reply-To: <65E69419-9CC1-4BC1-BF5F-387BC1F855EB@gmail.com> References: <65E69419-9CC1-4BC1-BF5F-387BC1F855EB@gmail.com> Message-ID: <54366ABA.2020306@opensips.org> Hi, What you have is a issue at transaction level (a retransmission) and should not be solved at dialog level. It must be solved at transaction level, by using the t_check_tran() function before the dialog module. So, in your script, before doing the loose_route() or match_dialog() for sequential requests, just to a t_check_tran() or t_newtran(). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 08.10.2014 20:39, neumann wrote: > http://lists.opensips.org/pipermail/users/2013-December/027518.html > Hi all! > I have same problem. I can?t handle BYE retransmissions with topology > hiding because dialog destroying before retransmission. > This will be fixed or workaround exist? > > ???????????? > > Timofeev Dmitry > VoIP Engineer > Linux, Asterisk, Freeswitch, Cisco solutions > Skype: itsroot > icq: 227227933 > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From whitepj at manx.biz Thu Oct 9 13:46:00 2014 From: whitepj at manx.biz (White, Phil) Date: Thu, 9 Oct 2014 12:46:00 +0100 Subject: [OpenSIPS-Users] Sip2sip config Message-ID: Hi Apologies if I am missing an obvious file somewhere... Can someone please point me to a working config file to enable me to connect a local sip proxy to the sip2sip network? Thanks Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: From nasida at live.ru Thu Oct 9 15:40:46 2014 From: nasida at live.ru (Yuriy Nasida) Date: Thu, 9 Oct 2014 17:40:46 +0400 Subject: [OpenSIPS-Users] Q. how to send outbound INVITE from opensips via TLS ? Message-ID: Hi there! I would like to implement this scenario startpoint --UDP--> opensips ---TLS---> endpoint How can I say opensips to use TLS ? The only way I see is t_relay(tls:etc) but.. opensips can not use variables in t_relay function but i really need this :( Also I tried force_send_socket but had not luck. Any ideas ? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From linuxvenkey at gmail.com Thu Oct 9 16:11:29 2014 From: linuxvenkey at gmail.com (Venkatesh Macha) Date: Thu, 9 Oct 2014 07:11:29 -0700 (PDT) Subject: [OpenSIPS-Users] Is it possible to change the "Body of Message Method" ??? Message-ID: <1412863889795-7593914.post@n2.nabble.com> Hi list, Is it possible to change the body of Message method. here is the my SIP message U 192.168.1.126:54638 -> 192.168.1.100:5060 MESSAGE sip:200 at 192.168.1.100 SIP/2.0. Via: SIP/2.0/UDP 192.168.1.126:54638;branch=z9hG4bK.HmddG7cOd;rport. From: ;tag=qurOuaMoo. To: sip:200 at 192.168.1.100. CSeq: 20 MESSAGE. Call-ID: CXke2mLoD1. Max-Forwards: 70. Supported: outbound. Content-Type: text/plain. Content-Length: 29. Date: Thu, 9 Oct 2014 13:58:42 GMT. User-Agent: LinphoneAndroid/2.3.2 (belle-sip/1.3.2). . *msg,431,original message body* I want to change the body i.e *msg,431,original message body* to* original message body* is it possible ??? I know about $rb ($rb - reference to message body) it contains the body of my message but if i try to change the Message body it is not Working... I am trying like this in opensips.cfg *$var(s)=$(rb{s.select,2,,}); $rb = $var(s); * But not working.. here is the error message. CRITICAL:core:yyerror: parse error in config file /usr//etc/opensips/opensips.cfg, line 193, column 24-25: invalid left operand in assignment. Is there any other way to change the message body.. Thank you in Advance Venkatesh Macha, Junior VOIP Engineer, @ sillycodes -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Is-it-possible-to-change-the-Body-of-Message-Method-tp7593914.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From alipey at gmail.com Thu Oct 9 17:42:58 2014 From: alipey at gmail.com (Ali Pey) Date: Thu, 9 Oct 2014 11:42:58 -0400 Subject: [OpenSIPS-Users] OpenSIPS/RTpProxy BridgeMode after failure route In-Reply-To: <543639C5.1090705@opensips.org> References: <52CA9503.5020100@opensips.org> <543639C5.1090705@opensips.org> Message-ID: Hello R?zvan & Salman, Thank you for your responses. I was able to fix it by moving rtpproxy_offer to branch route instead of having it in the main route. In failure route, I only needed to do unforce. Regards, Ali Pey On Thu, Oct 9, 2014 at 3:31 AM, R?zvan Crainea wrote: > Hi, Ali! > > For the initial branch (in request route) are you using engage_rtpproxy()? > If so, try to use rtpproxy_offer(). > > Best regards, > > R?zvan Crainea > OpenSIPS Solutions www.opensips-solutions.com > > On 10/09/2014 12:06 AM, Ali Pey wrote: > > Hello Salman, > > Can you please elaborate on how you got this working? I have the same > problem and can't get it to work. > > In failure route, I do: > unforce_rtp_proxy() > Then when I have a new destination, I do: > rtpproxy_offer("rocie"); > > However, I end up with messed up SDP, in my second invite. It doesn't > remove the old IP addresses and only adds the IP addresses again: > o=Sonus_UAC 9216 20203 IN IP4 10.160.11.16210.160.11.162a Capabilities > c=IN IP4 10.160.11.16210.160.11.162udio 2311822970AVP 0 8 100 > > > Please let me know how I can fix this. > > Thanks. > > > On Mon, Jan 6, 2014 at 10:26 AM, Salman Zafar > wrote: > >> Hi Razvan, >> I got it working without branching, after banging head a lot I >> got to learn unforcing drops the media ports for previous rtpproxy >> offer/answer and after that directing the new flow though rtpproxy flags,IP >> media works. I am able to traverse from eternal to internal play media and >> then on failure do external to external with media flowing between public >> interfaces. Just wondering if you know this method or certify. >> >> >> >> On Mon, Jan 6, 2014 at 4:35 PM, R?zvan Crainea >> wrote: >> >>> Hi, Salman! >>> >>> The sockets used by RTPProxy are created when the session is started >>> (the first offer) and cannot be updated afterwards. Therefore the only >>> solution I can see is to configure a per branch scenario, as you mentioned. >>> >>> Best regards, >>> >>> Razvan Crainea >>> OpenSIPS Core Developer >>> http://www.opensips-solutions.com >>> >>> >>> >>> On 12/30/2013 01:11 PM, Salman Zafar wrote: >>> >>>> Hi, >>>> I have a scenario of playing media at a private-ip media server and >>>> send BUSY, next in failure route bridge call to a public IP. (SIP to >>>> SIP). >>>> >>>> So the scenario is as follows: >>>> >>>> UA(Phone1) -> OpenSIPS/RTpProxy(ei) -> Media-Server (Private IP) -> BUSY >>>> -> OpenSIPS(failure route) -> RTpProxy(ee) -> lookup -> (UA Phone2) >>>> >>>> Now the problem is RtpProxy is being offered (EI flags) in first case >>>> where routing to Media sever at private IP, after failure it is again >>>> used with (EE flags), also in corresponding replies. >>>> >>>> The second time RTpProxy does not effect SDP c= and ports in a way to >>>> build media communication. SDP fix directly does not effect rtp ports. >>>> >>>> Is there any way of using RtpProxy differently in fail-over, or I have >>>> to go for rtpproxy per branch?. >>>> >>>> >>>> Thanks in advance. >>>> >>>> -- >>>> Regards >>>> >>>> Salman >>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> >>>> >>>> http://lists.opensips.org/cgi- >>>> >>>> bin/mailman/listinfo/users >>>> >>>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> >>> >>> http://lists.opensips.org/cgi- >>> >>> bin/mailman/listinfo/users >>> >> >> >> >> -- >> Regards >> >> M. Salman Zafar >> >> VoIP Professional >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Oct 9 19:03:00 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 09 Oct 2014 20:03:00 +0300 Subject: [OpenSIPS-Users] Is it possible to change the "Body of Message Method" ??? In-Reply-To: <1412863889795-7593914.post@n2.nabble.com> References: <1412863889795-7593914.post@n2.nabble.com> Message-ID: <5436BFC4.9010300@opensips.org> Hi, as the $rb variable is read-only, in order to push your new body you can do strip_body() + add_body() : http://www.opensips.org/html/docs/modules/1.11.x/sipmsgops.html#id294226 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 09.10.2014 17:11, Venkatesh Macha wrote: > Hi list, > > Is it possible to change the body of Message method. here is the > my SIP message > > U 192.168.1.126:54638 -> 192.168.1.100:5060 > MESSAGE sip:200 at 192.168.1.100 SIP/2.0. > Via: SIP/2.0/UDP 192.168.1.126:54638;branch=z9hG4bK.HmddG7cOd;rport. > From: ;tag=qurOuaMoo. > To: sip:200 at 192.168.1.100. > CSeq: 20 MESSAGE. > Call-ID: CXke2mLoD1. > Max-Forwards: 70. > Supported: outbound. > Content-Type: text/plain. > Content-Length: 29. > Date: Thu, 9 Oct 2014 13:58:42 GMT. > User-Agent: LinphoneAndroid/2.3.2 (belle-sip/1.3.2). > . > *msg,431,original message body* > > I want to change the body i.e *msg,431,original message body* to* original > message body* is it possible ??? > > I know about $rb ($rb - reference to message body) it contains the body of > my message but if i try to change the Message body it is not Working... I am > trying like this in opensips.cfg > *$var(s)=$(rb{s.select,2,,}); > $rb = $var(s); * > > But not working.. here is the error message. > CRITICAL:core:yyerror: parse error in config file > /usr//etc/opensips/opensips.cfg, line 193, column 24-25: invalid left > operand in assignment. > > Is there any other way to change the message body.. > > Thank you in Advance > > Venkatesh Macha, > Junior VOIP Engineer, > @ sillycodes > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Is-it-possible-to-change-the-Body-of-Message-Method-tp7593914.html > Sent from the OpenSIPS - Users mailing list archive at Nabble.com. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > From bogdan at opensips.org Thu Oct 9 19:07:08 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 09 Oct 2014 20:07:08 +0300 Subject: [OpenSIPS-Users] OpenSIPS Las Vegas Summit - Speakers & Workshops - part 2 Message-ID: <5436C0BC.2040406@opensips.org> *On October 21st, 2014, Las Vegas will be the the "OpenSIPS" city!* *Bogdan-Andrei Iancu - OpenSIPS core developer - */"//OpenSIPS Call Center with Asterisk"/ ? Even without having media capabilities, OpenSIPS can provide a high performance and scalable call queuing engine - hundreds of queues, thousands of agents, thousands of queued calls. ? Asterisk is required in combination with OpenSIPS in order to provide media server oriented services - front-end IVRs for selecting queue, announcement playback and queuing playback. Considering that geo-distributed call centers (with unique queue on OpenSIPS), Asterisk can be even more used as a local (to agent) class V PBX for advanced services like call barging, call transfer, call listening and other call-center specific features. *Flavio Goncalves ***- SIPPulse *- */"Using OpenSIPS to protect an Asterisk Farm//"/ ? IP-PBXs are great, but they were created with PBX features in mind. By just configuring a PBX it is not possible to prevent attacks such as SIP flooding, RTP flooding, RTP injection, Fuzzy and Toll fraud. OpenSIPS is an advanced SIP proxy capable to handle low-level parts of SIP. Positioned as an outbound proxy or b2bua, it can protect a farm of PBXs in an effective and affordable way. Learn how! And more speakers and even more topics to follow. See http://www.opensips.org/Community/Summit-2014LasVegas-Schedule To *register for the event*, see http://www.opensips.org/Community/Summit-Registration Participating the Astricon? Use the "astricon2014" discount code ;). See you in Vegas, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ag at ag-projects.com Thu Oct 9 21:46:48 2014 From: ag at ag-projects.com (ag at ag-projects.com) Date: Thu, 9 Oct 2014 21:46:48 +0200 Subject: [OpenSIPS-Users] CDRTool prepaid for big installation In-Reply-To: References: Message-ID: <9CA4630F-2CFC-46F7-81A7-2E99F6997D1A@ag-projects.com> Yes, it is capable. On 08 Oct 2014, at 15:42, Satish Patel wrote: > Hi, > > Just want to know does CDRTool prepaid capable of handling couple hundreds of concurrent calls? I heard it can handle only 2/3 concurrent calls per account? what is the solution if we want to host big prepaid system with thousands of users? > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From kfh.opensips at kfh.dk Thu Oct 9 22:33:16 2014 From: kfh.opensips at kfh.dk (Kristian =?ISO-8859-1?Q?F=2E_H=F8gh?=) Date: Thu, 09 Oct 2014 22:33:16 +0200 Subject: [OpenSIPS-Users] udp receiver processes get stuck on publish Message-ID: <3311695.8fstP0BnLr@pingo> Hi list, We've got issues, as our presence server gets locked up. The following happened on our test server, running opensips 1.11.2 As I can see from our sip-traces and logs, one PUBLISH request was "overtaken" by another. 1. PUBLISH (no etag) (pid 3012) 200 OK, etag: 1 (pid 3012) 2. PUBLISH, etag 1 (pid 3008) 200 OK, etag: 2 (pid 3008) 3. PUBLISH, etag 2 (pid 3005) 4. PUBLISH, etag 2 (pid 3011) 200 OK, etag: 3 (pid 3011) 200 OK, etag: 4 (pid 3005) 5. PUBLISH, etag 4 (pid 3012) PUBLISH, etag 4 (retrans) PUBLISH, etag 4 (retrans) PUBLISH, etag 4 (retrans) The database update on 3rd PUBLISH took 6749us according to exec_query_threshold. The database update on 4th PUBLISH took 3646us. On the 5th PUBLISH pid 3012 got stuck, while updating presentity. Half an hour later I noticed, and enabled debug. I got the following: /usr/local/sbin/opensips[3012]: DBG:presence:search_phtable_etag: pres_uri= sip:@, event=5, etag= 4 /usr/local/sbin/opensips[3012]: DBG:presence:search_phtable_etag: found etag = /usr/local/sbin/opensips[3012]: DBG:presence:search_phtable_etag: found etag = 2 /usr/local/sbin/opensips[3012]: DBG:presence:search_phtable_etag: found etag = 4 /usr/local/sbin/opensips[3012]: DBG:presence:search_phtable_etag: pres_uri= sip:@, event=5, etag= 4 /usr/local/sbin/opensips[3012]: DBG:presence:search_phtable_etag: found etag = /usr/local/sbin/opensips[3012]: DBG:presence:search_phtable_etag: found etag = 2 /usr/local/sbin/opensips[3012]: DBG:presence:search_phtable_etag: found etag = 4 /usr/local/sbin/opensips[3012]: DBG:presence:search_phtable_etag: pres_uri= sip:@, event=5, etag= 4 ... The etag , was generated at another call, 7 minutes after the process was stuck. I've got full sip-traces and log from presence server, if somebody can help. For now we added a counter to the while loop around line 560 of modules/presence/presentity.c, terminating when it reaches 1000. Regards, Kristian H?gh From levent.tinaz at sponsoracall.com Thu Oct 9 23:58:52 2014 From: levent.tinaz at sponsoracall.com (Levent Tinaz) Date: Thu, 9 Oct 2014 16:58:52 -0500 Subject: [OpenSIPS-Users] RabbitMQ In-Reply-To: <54350A48.3000902@opensips.org> References: <54350A48.3000902@opensips.org> Message-ID: Hi R?zvan, Thank you for your answer. Levent Sponsoracall.com On Wed, Oct 8, 2014 at 4:56 AM, R?zvan Crainea wrote: > Hi, Levent! > > The E_ACC_CDR event is automatically triggered if you set the evi_flag[1] > and cdr_flag[2] on your initial INVITEs. > Also, the rabbitmq queue should be setup in the startup_route according to > this example[3]. > > [1] http://www.opensips.org/html/docs/modules/1.12.x/acc#id295246 > [2] http://www.opensips.org/html/docs/modules/1.12.x/acc#id295374 > [3] > http://www.opensips.org/html/docs/modules/devel/event_rabbitmq#id293516 > > Best regards, > > R?zvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 10/06/2014 05:36 PM, Levent Tinaz wrote: > > Hi All, > > Collecting CDRs via rabbitMQ.., I am not clear about it. Do I need to > raise the event E_ACC_CDR manually in the script ? or this should be done > by ACC module automatically? > If it is automatic how can I do that? I really appreciate if you share > your ACC and RabbitMQ settings. > > Thanks. > > Levent Tinaz > > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhengyumingnanjing at gmail.com Fri Oct 10 03:46:38 2014 From: zhengyumingnanjing at gmail.com (Yuming Zheng) Date: Fri, 10 Oct 2014 09:46:38 +0800 Subject: [OpenSIPS-Users] Have one registration contact per device in usrloc In-Reply-To: <54366444.70608@opensips.org> References: <54350697.60100@opensips.org> <54366444.70608@opensips.org> Message-ID: Yes ,GRUU can solve this situation. So, is there any similar mechanism with presence info to only keep the latest presence status of the same register. BR, Frank.zheng 2014-10-09 18:32 GMT+08:00 Bogdan-Andrei Iancu : > Hi Jayesh, > > Maybe you should look into GRUU stuff ;). > > On the TCP error - even if you set the TCP persistence flag, the UAC may > close the TCP conn -> you end up in the same situation. What you can do is > to prevent OpenSIPS to open TCP conns when routing to end-users - the idea > is to have end-users connecting to OpenSIPS and not the other way around. > See "tcp_no_new_conn_bflag" : > http://www.opensips.org/Documentation/Script-CoreParameters-1-11#toc96 > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > On 08.10.2014 17:31, Jayesh Nambiar wrote: > > Hi Bogdan, > So I thought of doing this and I have another problem. Say if a device > registered from IP 1.2.3.4, and then moved out to different network and > re-registered from IP 4.3.2.1, there is a stale registration lying in > opensips for the same device from 1.2.3.4. > Now when I use TCP as transport, opensips waits till connect timed out on > unreachable IPs before sending the call to registered contact and the > following messages are logged in syslog: > ERROR:core:tcp_blocking_connect: timeout 10 s elapsed from 10 s > ERROR:core:tcpconn_connect: tcp_blocking_connect failed > ERROR:core:tcp_send: connect failed > ERROR:tm:msg_send: tcp_send failed > > Looks like opensips tries to do a TCP connect first with all registered > contacts before actually routing the call. > I do, > modparam("registrar", "tcp_persistent_flag", "TCP_PERSISTENT") > > if(is_method("REGISTER")) { > setflag(TCP_PERSISTENT); > setbflag(30); > if(!save("location", "fc1")) { > t_reply("500", "Error while saving AOR"); > } > } > > --- Jayesh > > > > > > > On Wed, Oct 8, 2014 at 3:10 PM, Bogdan-Andrei Iancu > wrote: > >> Hi Jayesh, >> >> Basically you do not what to have more registrations from the same IP, >> right ? >> >> Exactly the opposit of the is_other_contact() function : >> >> http://www.opensips.org/html/docs/modules/1.11.x/registrar.html#id294660 >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >> >> On 01.10.2014 18:15, Jayesh Nambiar wrote: >> >> Hi, >> I am trying to solve a problem of having one registration per AOR per >> device. So user 1234 can register from device A, device B and device C. But >> the user 1234 should not have multiple contacts from device A alone. >> At times when the device loses network, proxy doesn't receive >> de-register and the contact stays in opensips till its expiry time. So the >> same device is thus capable of creating multiple contacts. I could solve >> this by using "fc1" flag while doing a save("location") but I need multiple >> registrations to be allowed from different devices !! >> So is there a way where while doing a save("location"), I set some sort >> of device id along with it such that I identify and overwrite the existing >> contact only if the registration comes from same device-id or else add it >> up for parallel forking. >> Do let me know if I make sense here and there's a solution to this. >> Thanks for any suggestions and directions. >> >> Thanks, >> >> --- Jayesh >> >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhouxiaoqiang.mstech at gmail.com Fri Oct 10 04:08:25 2014 From: zhouxiaoqiang.mstech at gmail.com (chow) Date: Thu, 9 Oct 2014 19:08:25 -0700 (PDT) Subject: [OpenSIPS-Users] branch computation failed In-Reply-To: <5436691D.4010006@opensips.org> References: <1412825847529-7593895.post@n2.nabble.com> <5436691D.4010006@opensips.org> Message-ID: <1412906905090-7593931.post@n2.nabble.com> Hi Bogdan: the param of tm : loadmodule "tm.so" modparam("tm", "fr_timer", 5) modparam("tm", "fr_inv_timer", 30) modparam("tm", "restart_fr_on_each_reply", 0) modparam("tm", "onreply_avp_mode", 1) the sipp call rate is 3000 caps. the opensips version is 1.10.1 the opensips memory config : S_MEMORY=4096, P_MEMORY=128 -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/branch-computation-failed-tp7593895p7593931.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From linuxvenkey at gmail.com Fri Oct 10 07:38:54 2014 From: linuxvenkey at gmail.com (Venkatesh Macha) Date: Thu, 9 Oct 2014 22:38:54 -0700 (PDT) Subject: [OpenSIPS-Users] Is it possible to change the "Body of Message Method" ??? In-Reply-To: <5436BFC4.9010300@opensips.org> References: <1412863889795-7593914.post@n2.nabble.com> <5436BFC4.9010300@opensips.org> Message-ID: <1412919534057-7593932.post@n2.nabble.com> Hi, Thanks you Bogdan-Andrei Iancu , i will try it now.. Venkatesh Macha, Junior VOIP Engineer. -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Is-it-possible-to-change-the-Body-of-Message-Method-tp7593914p7593932.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From bogdan at opensips.org Fri Oct 10 10:07:26 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 10 Oct 2014 11:07:26 +0300 Subject: [OpenSIPS-Users] Have one registration contact per device in usrloc In-Reply-To: References: <54350697.60100@opensips.org> <54366444.70608@opensips.org> Message-ID: <543793BE.1060204@opensips.org> Hi, SIP registration has nothing to do with SIP presence. There are totally individual mechanisms in SIP. In presence, when a device starts publishing for the first time, it gets an etag (a unique id) that will identify the device+publisher. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10.10.2014 04:46, Yuming Zheng wrote: > > Yes ,GRUU can solve this situation. > So, is there any similar mechanism with presence info to only keep the > latest presence status of the same register. > > BR, > > Frank.zheng > > 2014-10-09 18:32 GMT+08:00 Bogdan-Andrei Iancu >: > > Hi Jayesh, > > Maybe you should look into GRUU stuff ;). > > On the TCP error - even if you set the TCP persistence flag, the > UAC may close the TCP conn -> you end up in the same situation. > What you can do is to prevent OpenSIPS to open TCP conns when > routing to end-users - the idea is to have end-users connecting to > OpenSIPS and not the other way around. See "tcp_no_new_conn_bflag" : > http://www.opensips.org/Documentation/Script-CoreParameters-1-11#toc96 > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 08.10.2014 17:31, Jayesh Nambiar wrote: >> Hi Bogdan, >> So I thought of doing this and I have another problem. Say if a >> device registered from IP 1.2.3.4, and then moved out to >> different network and re-registered from IP 4.3.2.1, there is a >> stale registration lying in opensips for the same device from >> 1.2.3.4. >> Now when I use TCP as transport, opensips waits till connect >> timed out on unreachable IPs before sending the call to >> registered contact and the following messages are logged in syslog: >> ERROR:core:tcp_blocking_connect: timeout 10 s elapsed from 10 s >> ERROR:core:tcpconn_connect: tcp_blocking_connect failed >> ERROR:core:tcp_send: connect failed >> ERROR:tm:msg_send: tcp_send failed >> >> Looks like opensips tries to do a TCP connect first with all >> registered contacts before actually routing the call. >> I do, >> modparam("registrar", "tcp_persistent_flag", "TCP_PERSISTENT") >> >> if(is_method("REGISTER")) { >> setflag(TCP_PERSISTENT); >> setbflag(30); >> if(!save("location", "fc1")) { >> t_reply("500", "Error while saving AOR"); >> } >> } >> >> --- Jayesh >> >> >> >> >> >> >> On Wed, Oct 8, 2014 at 3:10 PM, Bogdan-Andrei Iancu >> > wrote: >> >> Hi Jayesh, >> >> Basically you do not what to have more registrations from the >> same IP, right ? >> >> Exactly the opposit of the is_other_contact() function : >> http://www.opensips.org/html/docs/modules/1.11.x/registrar.html#id294660 >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> On 01.10.2014 18:15, Jayesh Nambiar wrote: >>> Hi, >>> I am trying to solve a problem of having one registration >>> per AOR per device. So user 1234 can register from device A, >>> device B and device C. But the user 1234 should not have >>> multiple contacts from device A alone. >>> At times when the device loses network, proxy doesn't >>> receive de-register and the contact stays in opensips till >>> its expiry time. So the same device is thus capable of >>> creating multiple contacts. I could solve this by using >>> "fc1" flag while doing a save("location") but I need >>> multiple registrations to be allowed from different devices !! >>> So is there a way where while doing a save("location"), I >>> set some sort of device id along with it such that I >>> identify and overwrite the existing contact only if the >>> registration comes from same device-id or else add it up for >>> parallel forking. >>> Do let me know if I make sense here and there's a solution >>> to this. Thanks for any suggestions and directions. >>> >>> Thanks, >>> >>> --- Jayesh >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Fri Oct 10 10:11:04 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 10 Oct 2014 11:11:04 +0300 Subject: [OpenSIPS-Users] Q. how to send outbound INVITE from opensips via TLS ? In-Reply-To: References: Message-ID: <54379498.7020903@opensips.org> Hi, You can switch the protocol for the outbound relaying in two ways: 1) force it via the RURI -> add the transport=tls param to RURI : http://www.opensips.org/html/docs/modules/1.11.x/uri.html#id294426 2) force a TLS socket to be used with force_send_socket() or $fs http://www.opensips.org/Documentation/Script-CoreVar-2-1#toc44 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 09.10.2014 16:40, Yuriy Nasida wrote: > Hi there! > > I would like to implement this scenario > > startpoint --UDP--> opensips ---TLS---> endpoint > > How can I say opensips to use TLS ? > > The only way I see is *t_relay(tls:etc)* but.. opensips can not use > variables in t_relay function but i really need this :( > Also I tried force_send_socket but had not luck. > > Any ideas ? > Thanks. > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From voransoy at gmail.com Fri Oct 10 13:33:52 2014 From: voransoy at gmail.com (Volkan Oransoy) Date: Fri, 10 Oct 2014 14:33:52 +0300 Subject: [OpenSIPS-Users] Dispacher and Drouting question Message-ID: Hi, I am working on a special load balancing setup. For specific $rU values, I want to keep choosen gateway and use cached value for next time. So that, for each destination, there will be a specific gateway. But I failed at getting the chosen gw to an avp. I am trying to get it, just before relay with $du but it returns null. How can load chosen gw to an avp with dispacher and drouting? Thanks, /Volkan -------------- next part -------------- An HTML attachment was scrubbed... URL: From aihuawu2012 at 163.com Fri Oct 10 17:36:18 2014 From: aihuawu2012 at 163.com (george wu) Date: Fri, 10 Oct 2014 23:36:18 +0800 (CST) Subject: [OpenSIPS-Users] how to check debug message for stun? Message-ID: <17bfb9a0.1fb7d.148fab41375.Coremail.aihuawu2012@163.com> Hi, all: I can't see any debug message for stun on the opensips server side. I have enabled debug and set up stun as below loadmodule "stun.so" modparam("stun", "primary_ip", "192.168.1.3") modparam("stun","alternate_ip","192.168.122.1") From the client linphone debug message, I can see ortp-message-channel [0x1fb3080]: discovered public ip and port are [192.168.1.3:5070] Just I don't see any debug message for stun, how to check it on the server side? Thanks. George -------------- next part -------------- An HTML attachment was scrubbed... URL: From aihuawu2012 at 163.com Fri Oct 10 17:48:15 2014 From: aihuawu2012 at 163.com (george wu) Date: Fri, 10 Oct 2014 23:48:15 +0800 (CST) Subject: [OpenSIPS-Users] how to check debug message for stun? In-Reply-To: <17bfb9a0.1fb7d.148fab41375.Coremail.aihuawu2012@163.com> References: <17bfb9a0.1fb7d.148fab41375.Coremail.aihuawu2012@163.com> Message-ID: <5d3a96b0.1fc52.148fabf044a.Coremail.aihuawu2012@163.com> I think my client never send stun message to the server. the client find its public ip from the OK VIA header: Via: SIP/2.0/UDP 192.168.1.3:5070;received=192.168.1.3;branch=z9hG4bK.Klryaqrls;rport=5070 Am I right? At 2014-10-10 23:36:18, "george wu" wrote: Hi, all: I can't see any debug message for stun on the opensips server side. I have enabled debug and set up stun as below loadmodule "stun.so" modparam("stun", "primary_ip", "192.168.1.3") modparam("stun","alternate_ip","192.168.122.1") From the client linphone debug message, I can see ortp-message-channel [0x1fb3080]: discovered public ip and port are [192.168.1.3:5070] Just I don't see any debug message for stun, how to check it on the server side? Thanks. George -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaandandin at yahoo.com Fri Oct 10 22:48:50 2014 From: kaandandin at yahoo.com (Kaan Dandin) Date: Fri, 10 Oct 2014 23:48:50 +0300 Subject: [OpenSIPS-Users] YNT: Re: YNT: Re: RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE Message-ID: Yes 141 is opensips I am sending both 3 and 5 register messages when I get from 11 which is ims bench Samsung Mobile taraf?ndan g?nderildi
-------- Orjinal mesaj --------
Kimden: Bogdan-Andrei Iancu
Tarih:09 10 2014 13:45 (GMT+02:00)
Al?c?: Kaan Dandin ,OpenSIPS users mailling list
Cc:
Konu: Re: YNT: Re: [OpenSIPS-Users] RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE
Hi, Is .141 your OpenSIPS ? I see .141 is sending the REGISTRAR to both nodes ( .3 and .5) . Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 09.10.2014 10:00, Kaan Dandin wrote: Hi Bogdan, Thanks for your response. In this situation how can I configure opensips to pass this message to the destination. Is it a configuration change or should I use another function instead of t_relay ? Kind regards Samsung Mobile taraf?ndan g?nderildi -------- Orjinal mesaj -------- Kimden: Bogdan-Andrei Iancu Tarih:07 10 2014 16:29 (GMT+02:00) Al?c?: Kaan Dandin ,OpenSIPS users mailling list Cc: Konu: Re: [OpenSIPS-Users] RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE Hi Kaan, The log you refer to is a DBG and not an ERR (error) - when a new request is received, opensips (inside the t_relay) tries to match it against existing transactions to see if it a retransmission on not. The fact your request does not match means it is not a retransmission, but rather a new request. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 04.10.2014 11:18, Kaan Dandin wrote: Hi all, I am making registration to the Open IMS nodes(192.168.2.3 and 192.168.2.5) simultaneously from IMS bench(192.168.2.11). Registration messages are going through OpenSIPS load balancer(192.168.2.141). Registration messages which are going to first Open IMS node(192.168.2.5) completed succesfully. But registration to second IMS node(192.168.2.3) is not completed successfully since t_relay() function in OpenSIPS load balancer is giving "DBG:tm:matching_3261: RFC3261 transaction matching failed" error and not passing the "Status: 401 Unauthorized - Challenging the UE (0 bindings)" messages to IMS bench. Below please find wireshark log and opensips logs in debug level=6. Do you have any idea for this problem. BR, Kaan o. Time Source Destination Protocol Info 55 1.186495 192.168.2.11 192.168.2.141 SIP Request: REGISTER sip:open-ims.test 56 1.188443 192.168.2.141 192.168.2.3 SIP Request: REGISTER sip:open-ims.test 57 1.189001 192.168.2.141 192.168.2.5 SIP Request: REGISTER sip:open-ims.test 58 1.215792 192.168.2.5 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) 59 1.216974 192.168.2.141 192.168.2.11 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) 60 1.217486 192.168.2.11 192.168.2.141 SIP Request: REGISTER sip:open-ims.test 61 1.218516 192.168.2.141 192.168.2.3 SIP Request: REGISTER sip:open-ims.test 62 1.218804 192.168.2.141 192.168.2.5 SIP Request: REGISTER sip:open-ims.test 63 1.233561 192.168.2.3 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) 64 1.241624 192.168.2.3 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) 65 1.246112 192.168.2.5 192.168.2.141 SIP Status: 200 OK - SAR succesful and registrar saved (1 bindings) 66 1.246919 192.168.2.141 192.168.2.11 SIP Status: 200 OK - SAR succesful and registrar saved (1 bindings) Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: xlog method: [REGISTER] totag: [] sipid: [192.168.2.11] messageid: [68] callid: [56-6888 at 192.168.2.11] callsequence: [2] Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:uri:has_totag: no totag Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: xlog_initialregister Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:comp_scriptvar: str 20 : 192.168.2.11 Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:t_newtran: transaction on entrance=0xffffffffffffffff Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:parse_headers: flags=ffffffffffffffff Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:get_hdr_field: content_length=0 Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:get_hdr_field: found end of header Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:parse_headers: flags=78 Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:t_lookup_request: start searching: hash=35746, isACK=0 Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:matching_3261: RFC3261 transaction matching failed Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:t_lookup_request: no transaction found Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:run_reqin_callbacks: trans=0x7fcda4739918, callback type 1, id 1 entered Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:run_reqin_callbacks: trans=0x7fcda4739918, callback type 1, id 0 entered Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:check_ip_address: params 192.168.2.11, 192.168.2.11, 0 _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From lav at ptcomm.ru Sat Oct 11 08:59:33 2014 From: lav at ptcomm.ru (=?UTF-8?B?0JvRi9GC0LDQtdCyINCQ0L3RgtC+0L0g0JLQuNC60YLQvtGA0L7QstC40Yc=?=) Date: Sat, 11 Oct 2014 10:59:33 +0400 Subject: [OpenSIPS-Users] ISUP and SIP-I with Opensips In-Reply-To: References: Message-ID: <5438D555.90906@ptcomm.ru> Good time! Tell me - Opensips works with ISUP? ISUP messages can generate yourself? If yes, then how to use SIP-I to transfer some parameters such as CPC (Calling Party Category) or Numbering Plan Indicator....? Thanks! From aihuawu2012 at 163.com Sat Oct 11 15:26:18 2014 From: aihuawu2012 at 163.com (george wu) Date: Sat, 11 Oct 2014 21:26:18 +0800 (CST) Subject: [OpenSIPS-Users] help: nathelper/rtpproxy/ice/ice-mismatch Message-ID: <47e0ce27.f81e.148ff6369a4.Coremail.aihuawu2012@163.com> When I use nathelper/rtpproxy, ice does not work well with it. nathelper will rewrite the sdp media part which my ice client is not happy. Then it will reply a=ice-mismatch. finally it will use rtpproxy to relay the media. the invite: m=audio 36580 RTP/AVP 124 120 111 110 0 8 101 .... a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host Detail is below: 1) I have set up the nathelper/rtpproxy as below: #### NAT modules loadmodule "nathelper.so" modparam("nathelper", "natping_interval", 10) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "received_avp", "$avp(received_nh)") loadmodule "rtpproxy.so" modparam("rtpproxy", "rtpproxy_sock", "udp:localhost:12221") # CUSTOMIZE ME loadmodule "stun.so" modparam("stun", "primary_ip", "192.168.1.3") modparam("stun","alternate_ip","192.168.122.1") 2) my client is linphone with ice set up. 3) when it make a call with ice, the sdp media get relayed: INVITE sip:test2 at 192.168.1.3:5080 SIP/2.0 Record-Route: Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bKa00d.25386e01.0 Via: SIP/2.0/UDP 192.168.1.3:5070;received=192.168.1.3;branch=z9hG4bK.bo~6nN-3E;rport=5070 From: ;tag=0tEh0Q~ly To: sip:test2 at 192.168.1.3 CSeq: 20 INVITE Call-ID: XvJ7qOUjnp Max-Forwards: 69 Supported: replaces, outbound Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp Content-Length: 547 Contact: ;+sip.instance="" User-Agent: linphone/3.7.0 (belle-sip/1.3.0) v=0 o=test1 1936 2136 IN IP4 192.168.1.3 s=Talk c=IN IP4 192.168.1.3 t=0 0 a=ice-pwd:741608ce2b68ba853500cdf3 a=ice-ufrag:0d47513b m=audio 36580 RTP/AVP 124 120 111 110 0 8 101 a=rtpmap:124 opus/48000 a=fmtp:124 useinbandfec=1; usedtx=1 a=rtpmap:120 SILK/16000 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host a=nortpproxy:yes ////////////////// SIP/2.0 200 Ok Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bKa00d.25386e01.0 Via: SIP/2.0/UDP 192.168.1.3:5070;received=192.168.1.3;branch=z9hG4bK.bo~6nN-3E;rport=5070 From: ;tag=0tEh0Q~ly To: ;tag=OsFF6CF Call-ID: XvJ7qOUjnp CSeq: 20 INVITE User-Agent: linphone/3.7.0 (belle-sip/1.3.0) Supported: replaces, outbound Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Contact: ;+sip.instance="" Content-Type: application/sdp Content-Length: 428 Record-route: v=0 o=test2 2088 1279 IN IP4 192.168.1.3 s=Talk c=IN IP4 192.168.1.3 t=0 0 a=ice-pwd:52c18fd43896c0d573decfcd a=ice-ufrag:5d79a96c m=audio 7088 RTP/AVP 124 120 111 110 0 8 101 a=rtpmap:124 opus/48000 a=fmtp:124 useinbandfec=1; usedtx=1 a=rtpmap:120 SILK/16000 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ice-mismatch -------------- next part -------------- An HTML attachment was scrubbed... URL: From ag at ag-projects.com Sun Oct 12 00:17:47 2014 From: ag at ag-projects.com (Adrian Georgescu) Date: Sat, 11 Oct 2014 19:17:47 -0300 Subject: [OpenSIPS-Users] help: nathelper/rtpproxy/ice/ice-mismatch In-Reply-To: <47e0ce27.f81e.148ff6369a4.Coremail.aihuawu2012@163.com> References: <47e0ce27.f81e.148ff6369a4.Coremail.aihuawu2012@163.com> Message-ID: Try MediaProxy, it handles ICE negotiation properly. Adrian On 11 Oct 2014, at 10:26, george wu wrote: > When I use nathelper/rtpproxy, ice does not work well with it. > nathelper will rewrite the sdp media part which my ice client is not happy. > Then it will reply a=ice-mismatch. finally it will use rtpproxy to relay the media. > > the invite: > m=audio 36580 RTP/AVP 124 120 111 110 0 8 101 > .... > a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host > a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host > > Detail is below: > > > 1) I have set up the nathelper/rtpproxy as below: > #### NAT modules > loadmodule "nathelper.so" > modparam("nathelper", "natping_interval", 10) > modparam("nathelper", "ping_nated_only", 1) > modparam("nathelper", "received_avp", "$avp(received_nh)") > > loadmodule "rtpproxy.so" > modparam("rtpproxy", "rtpproxy_sock", "udp:localhost:12221") # CUSTOMIZE ME > > loadmodule "stun.so" > modparam("stun", "primary_ip", "192.168.1.3") > modparam("stun","alternate_ip","192.168.122.1") > > 2) my client is linphone with ice set up. > 3) when it make a call with ice, the sdp media get relayed: > INVITE sip:test2 at 192.168.1.3:5080 SIP/2.0 > Record-Route: > Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bKa00d.25386e01.0 > Via: SIP/2.0/UDP 192.168.1.3:5070;received=192.168.1.3;branch=z9hG4bK.bo~6nN-3E;rport=5070 > From: ;tag=0tEh0Q~ly > To: sip:test2 at 192.168.1.3 > CSeq: 20 INVITE > Call-ID: XvJ7qOUjnp > Max-Forwards: 69 > Supported: replaces, outbound > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO > Content-Type: application/sdp > Content-Length: 547 > Contact: ;+sip.instance="" > User-Agent: linphone/3.7.0 (belle-sip/1.3.0) > > v=0 > o=test1 1936 2136 IN IP4 192.168.1.3 > s=Talk > c=IN IP4 192.168.1.3 > t=0 0 > a=ice-pwd:741608ce2b68ba853500cdf3 > a=ice-ufrag:0d47513b > m=audio 36580 RTP/AVP 124 120 111 110 0 8 101 > a=rtpmap:124 opus/48000 > a=fmtp:124 useinbandfec=1; usedtx=1 > a=rtpmap:120 SILK/16000 > a=rtpmap:111 speex/16000 > a=fmtp:111 vbr=on > a=rtpmap:110 speex/8000 > a=fmtp:110 vbr=on > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host > a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host > a=nortpproxy:yes > ////////////////// > SIP/2.0 200 Ok > Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bKa00d.25386e01.0 > Via: SIP/2.0/UDP 192.168.1.3:5070;received=192.168.1.3;branch=z9hG4bK.bo~6nN-3E;rport=5070 > From: ;tag=0tEh0Q~ly > To: ;tag=OsFF6CF > Call-ID: XvJ7qOUjnp > CSeq: 20 INVITE > User-Agent: linphone/3.7.0 (belle-sip/1.3.0) > Supported: replaces, outbound > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO > Contact: ;+sip.instance="" > Content-Type: application/sdp > Content-Length: 428 > Record-route: > > v=0 > o=test2 2088 1279 IN IP4 192.168.1.3 > s=Talk > c=IN IP4 192.168.1.3 > t=0 0 > a=ice-pwd:52c18fd43896c0d573decfcd > a=ice-ufrag:5d79a96c > m=audio 7088 RTP/AVP 124 120 111 110 0 8 101 > a=rtpmap:124 opus/48000 > a=fmtp:124 useinbandfec=1; usedtx=1 > a=rtpmap:120 SILK/16000 > a=rtpmap:111 speex/16000 > a=fmtp:111 vbr=on > a=rtpmap:110 speex/8000 > a=fmtp:110 vbr=on > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=ice-mismatch > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Adrian -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From aihuawu2012 at 163.com Sun Oct 12 12:31:07 2014 From: aihuawu2012 at 163.com (george wu) Date: Sun, 12 Oct 2014 18:31:07 +0800 (CST) Subject: [OpenSIPS-Users] help: nathelper/rtpproxy/ice/ice-mismatch In-Reply-To: References: <47e0ce27.f81e.148ff6369a4.Coremail.aihuawu2012@163.com> Message-ID: <8ff50ac.15011.14903e96204.Coremail.aihuawu2012@163.com> Thank you very much, the mediaproxy works with ice quite nicely. George Wu At 2014-10-12 06:17:47, "Adrian Georgescu" wrote: Try MediaProxy, it handles ICE negotiation properly. Adrian On 11 Oct 2014, at 10:26, george wu wrote: When I use nathelper/rtpproxy, ice does not work well with it. nathelper will rewrite the sdp media part which my ice client is not happy. Then it will reply a=ice-mismatch. finally it will use rtpproxy to relay the media. the invite: m=audio 36580 RTP/AVP 124 120 111 110 0 8 101 .... a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host Detail is below: 1) I have set up the nathelper/rtpproxy as below: #### NAT modules loadmodule "nathelper.so" modparam("nathelper", "natping_interval", 10) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "received_avp", "$avp(received_nh)") loadmodule "rtpproxy.so" modparam("rtpproxy", "rtpproxy_sock", "udp:localhost:12221") # CUSTOMIZE ME loadmodule "stun.so" modparam("stun", "primary_ip", "192.168.1.3") modparam("stun","alternate_ip","192.168.122.1") 2) my client is linphone with ice set up. 3) when it make a call with ice, the sdp media get relayed: INVITE sip:test2 at 192.168.1.3:5080 SIP/2.0 Record-Route: Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bKa00d.25386e01.0 Via: SIP/2.0/UDP 192.168.1.3:5070;received=192.168.1.3;branch=z9hG4bK.bo~6nN-3E;rport=5070 From: ;tag=0tEh0Q~ly To: sip:test2 at 192.168.1.3 CSeq: 20 INVITE Call-ID: XvJ7qOUjnp Max-Forwards: 69 Supported: replaces, outbound Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp Content-Length: 547 Contact: ;+sip.instance="" User-Agent: linphone/3.7.0 (belle-sip/1.3.0) v=0 o=test1 1936 2136 IN IP4 192.168.1.3 s=Talk c=IN IP4 192.168.1.3 t=0 0 a=ice-pwd:741608ce2b68ba853500cdf3 a=ice-ufrag:0d47513b m=audio 36580 RTP/AVP 124 120 111 110 0 8 101 a=rtpmap:124 opus/48000 a=fmtp:124 useinbandfec=1; usedtx=1 a=rtpmap:120 SILK/16000 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host a=nortpproxy:yes ////////////////// SIP/2.0 200 Ok Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bKa00d.25386e01.0 Via: SIP/2.0/UDP 192.168.1.3:5070;received=192.168.1.3;branch=z9hG4bK.bo~6nN-3E;rport=5070 From: ;tag=0tEh0Q~ly To: ;tag=OsFF6CF Call-ID: XvJ7qOUjnp CSeq: 20 INVITE User-Agent: linphone/3.7.0 (belle-sip/1.3.0) Supported: replaces, outbound Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Contact: ;+sip.instance="" Content-Type: application/sdp Content-Length: 428 Record-route: v=0 o=test2 2088 1279 IN IP4 192.168.1.3 s=Talk c=IN IP4 192.168.1.3 t=0 0 a=ice-pwd:52c18fd43896c0d573decfcd a=ice-ufrag:5d79a96c m=audio 7088 RTP/AVP 124 120 111 110 0 8 101 a=rtpmap:124 opus/48000 a=fmtp:124 useinbandfec=1; usedtx=1 a=rtpmap:120 SILK/16000 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ice-mismatch _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Adrian -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Sun Oct 12 14:48:14 2014 From: satish.txt at gmail.com (Satish Patel) Date: Sun, 12 Oct 2014 08:48:14 -0400 Subject: [OpenSIPS-Users] CDRTool prepaid for big installation In-Reply-To: <9CA4630F-2CFC-46F7-81A7-2E99F6997D1A@ag-projects.com> References: <9CA4630F-2CFC-46F7-81A7-2E99F6997D1A@ag-projects.com> Message-ID: I have run sipp test and it only able to handle 30 calls and later all call failed, I heard from other user post, CDRTool prepaid can't handle many simultaneous running calls. In our case single account will make many simultaneous calls and we need to handle them via prepaid.. Some one suggested don't use prepaid because of limitation and performance, and suggested use Postpaid or Quota system.. is that true? On Thu, Oct 9, 2014 at 3:46 PM, wrote: > Yes, it is capable. > > On 08 Oct 2014, at 15:42, Satish Patel wrote: > > > Hi, > > > > Just want to know does CDRTool prepaid capable of handling couple > hundreds of concurrent calls? I heard it can handle only 2/3 concurrent > calls per account? what is the solution if we want to host big prepaid > system with thousands of users? > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ag at ag-projects.com Sun Oct 12 15:38:32 2014 From: ag at ag-projects.com (Adrian Georgescu) Date: Sun, 12 Oct 2014 10:38:32 -0300 Subject: [OpenSIPS-Users] CDRTool prepaid for big installation In-Reply-To: References: <9CA4630F-2CFC-46F7-81A7-2E99F6997D1A@ag-projects.com> Message-ID: On 12 Oct 2014, at 09:48, Satish Patel wrote: > I have run sipp test and it only able to handle 30 calls and later all call failed, Can you explain what exactly failed? > I heard from other user post, CDRTool prepaid can't handle many simultaneous running calls. You heard wrong. It cannot handle high density call attempts like calls generated from call centers or transit peers like SIP trunks that push lot of calls. The number of simultaneous calls is irrelevant. You can have thousands of simultaneous calls with almost no performance penalty if the traffic is generated by regular SIP user devices. > In our case single account will make many simultaneous calls and we need to handle them via prepaid.. It all depends on the meaning of many. Whenever a new call is attempted, the maximum remaining time of all ongoing calls of the same user must be recalculated so that the balance cannot be exceeded for any of them. This means that the more calls for the same user you have, the longer it takes to calculated everything over and over again. If you have many users with a few calls each like in a residential scenario where a user makes one or perhaps two parallel calls, this would have little impact as there is little to re-calculate. > Some one suggested don't use prepaid because of limitation and performance, and suggested use Postpaid or Quota system.. is that true? It all depends on the traffic patterns. Concurrent or simultaneous calls is one thing, high density calls/per second attempts is another. There is no hard limitation but the number of database queries, distance to MySQL database will affect how many calls you can handle because as I explained before all concurrent calls must be rerated in real time again for each new call attempt. If one SIP account generates 10K parallel calls the load is infinite while if you have 10K users with one call each the load is almost zero. This is why a prepaid model is not practical for high density of calls and this has little to do with CDRTool, any other system would face the same problem, the load is compounded when adding more calls for same account. A quota based system is more appropriate for entities that generate large amount of calls as nothing has to be calculated on a per call basis. Adrian > On Thu, Oct 9, 2014 at 3:46 PM, wrote: > Yes, it is capable. > > On 08 Oct 2014, at 15:42, Satish Patel wrote: > > > Hi, > > > > Just want to know does CDRTool prepaid capable of handling couple hundreds of concurrent calls? I heard it can handle only 2/3 concurrent calls per account? what is the solution if we want to host big prepaid system with thousands of users? > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Adrian -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From satish.txt at gmail.com Sun Oct 12 16:14:07 2014 From: satish.txt at gmail.com (Satish Patel) Date: Sun, 12 Oct 2014 10:14:07 -0400 Subject: [OpenSIPS-Users] CDRTool prepaid for big installation In-Reply-To: References: <9CA4630F-2CFC-46F7-81A7-2E99F6997D1A@ag-projects.com> Message-ID: Thanks!! I think you got my point, we have very high density call ratio that is why prepaid not going to be a solution, I think postpaid or quota would be right one. I have following question: Postpaid: Default it treat all calls as postpaid but in case i want to give number of mins or time to my single customer then how do i achieve that Example: 5000 mins or say $500 deposit in customer account then how i can do that with postpaid? Quota: I never explore this feature so i just want to know how quota system work with CDRTool? could you give me short explanation? Most of our customer would be call center or high density call customer, how i can use quota in that scenario? On Sun, Oct 12, 2014 at 9:38 AM, Adrian Georgescu wrote: > > On 12 Oct 2014, at 09:48, Satish Patel wrote: > > I have run sipp test and it only able to handle 30 calls and later all > call failed, > > > Can you explain what exactly failed? > > I heard from other user post, CDRTool prepaid can't handle many > simultaneous running calls. > > > You heard wrong. It cannot handle high density call attempts like calls > generated from call centers or transit peers like SIP trunks that push lot > of calls. The number of simultaneous calls is irrelevant. You can have > thousands of simultaneous calls with almost no performance penalty if the > traffic is generated by regular SIP user devices. > > In our case single account will make many simultaneous calls and we need > to handle them via prepaid.. > > > It all depends on the meaning of many. Whenever a new call is attempted, > the maximum remaining time of all ongoing calls of the same user must be > recalculated so that the balance cannot be exceeded for any of them. This > means that the more calls for the same user you have, the longer it takes > to calculated everything over and over again. > > If you have many users with a few calls each like in a residential > scenario where a user makes one or perhaps two parallel calls, this would > have little impact as there is little to re-calculate. > > Some one suggested don't use prepaid because of limitation and > performance, and suggested use Postpaid or Quota system.. is that true? > > > It all depends on the traffic patterns. Concurrent or simultaneous calls > is one thing, high density calls/per second attempts is another. There is > no hard limitation but the number of database queries, distance to MySQL > database will affect how many calls you can handle because as I explained > before all concurrent calls must be rerated in real time again for each new > call attempt. If one SIP account generates 10K parallel calls the load is > infinite while if you have 10K users with one call each the load is almost > zero. > > This is why a prepaid model is not practical for high density of calls and > this has little to do with CDRTool, any other system would face the same > problem, the load is compounded when adding more calls for same account. A > quota based system is more appropriate for entities that generate large > amount of calls as nothing has to be calculated on a per call basis. > > Adrian > > On Thu, Oct 9, 2014 at 3:46 PM, wrote: > >> Yes, it is capable. >> >> On 08 Oct 2014, at 15:42, Satish Patel wrote: >> >> > Hi, >> > >> > Just want to know does CDRTool prepaid capable of handling couple >> hundreds of concurrent calls? I heard it can handle only 2/3 concurrent >> calls per account? what is the solution if we want to host big prepaid >> system with thousands of users? >> > _______________________________________________ >> > Users mailing list >> > Users at lists.opensips.org >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -- > Adrian > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ag at ag-projects.com Mon Oct 13 01:30:32 2014 From: ag at ag-projects.com (Adrian Georgescu) Date: Sun, 12 Oct 2014 20:30:32 -0300 Subject: [OpenSIPS-Users] CDRTool prepaid for big installation In-Reply-To: References: <9CA4630F-2CFC-46F7-81A7-2E99F6997D1A@ag-projects.com> Message-ID: Quota works very simple. It is a mere cronjob that compares the total amount of costs made in the current calendar month with the maximum allowed. If the costs are higher than the quota, then the SIP account is blocked. This will not cut the calls in progress but it works well statistically speaking for postpaid customers. The documentation explains the modus operandi in more detail. Adrian On 12 Oct 2014, at 11:14, Satish Patel wrote: > Thanks!! I think you got my point, we have very high density call ratio that is why prepaid not going to be a solution, I think postpaid or quota would be right one. > > I have following question: > > Postpaid: > > Default it treat all calls as postpaid but in case i want to give number of mins or time to my single customer then how do i achieve that Example: 5000 mins or say $500 deposit in customer account then how i can do that with postpaid? > > > Quota: I never explore this feature so i just want to know how quota system work with CDRTool? could you give me short explanation? Most of our customer would be call center or high density call customer, how i can use quota in that scenario? > > On Sun, Oct 12, 2014 at 9:38 AM, Adrian Georgescu wrote: > > On 12 Oct 2014, at 09:48, Satish Patel wrote: > >> I have run sipp test and it only able to handle 30 calls and later all call failed, > > Can you explain what exactly failed? > >> I heard from other user post, CDRTool prepaid can't handle many simultaneous running calls. > > You heard wrong. It cannot handle high density call attempts like calls generated from call centers or transit peers like SIP trunks that push lot of calls. The number of simultaneous calls is irrelevant. You can have thousands of simultaneous calls with almost no performance penalty if the traffic is generated by regular SIP user devices. > >> In our case single account will make many simultaneous calls and we need to handle them via prepaid.. > > It all depends on the meaning of many. Whenever a new call is attempted, the maximum remaining time of all ongoing calls of the same user must be recalculated so that the balance cannot be exceeded for any of them. This means that the more calls for the same user you have, the longer it takes to calculated everything over and over again. > > If you have many users with a few calls each like in a residential scenario where a user makes one or perhaps two parallel calls, this would have little impact as there is little to re-calculate. > >> Some one suggested don't use prepaid because of limitation and performance, and suggested use Postpaid or Quota system.. is that true? > > It all depends on the traffic patterns. Concurrent or simultaneous calls is one thing, high density calls/per second attempts is another. There is no hard limitation but the number of database queries, distance to MySQL database will affect how many calls you can handle because as I explained before all concurrent calls must be rerated in real time again for each new call attempt. If one SIP account generates 10K parallel calls the load is infinite while if you have 10K users with one call each the load is almost zero. > > This is why a prepaid model is not practical for high density of calls and this has little to do with CDRTool, any other system would face the same problem, the load is compounded when adding more calls for same account. A quota based system is more appropriate for entities that generate large amount of calls as nothing has to be calculated on a per call basis. > > Adrian > >> On Thu, Oct 9, 2014 at 3:46 PM, wrote: >> Yes, it is capable. >> >> On 08 Oct 2014, at 15:42, Satish Patel wrote: >> >> > Hi, >> > >> > Just want to know does CDRTool prepaid capable of handling couple hundreds of concurrent calls? I heard it can handle only 2/3 concurrent calls per account? what is the solution if we want to host big prepaid system with thousands of users? >> > _______________________________________________ >> > Users mailing list >> > Users at lists.opensips.org >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- > Adrian > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Adrian -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From lav at ptcomm.ru Mon Oct 13 08:53:22 2014 From: lav at ptcomm.ru (=?UTF-8?B?0JvRi9GC0LDQtdCyINCQ0L3RgtC+0L0g0JLQuNC60YLQvtGA0L7QstC40Yc=?=) Date: Mon, 13 Oct 2014 10:53:22 +0400 Subject: [OpenSIPS-Users] ISUP and SIP-I with Opensips Message-ID: <543B76E2.3050104@ptcomm.ru> Good time! Tell me please: Opensips works with ISUP? ISUP messages can generate yourself? If yes, then how to use SIP-I to transfer some parameters such as CPC (Calling Party Category) or Numbering Plan Indicator....? Thanks! From bogdan at opensips.org Mon Oct 13 09:09:25 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 13 Oct 2014 10:09:25 +0300 Subject: [OpenSIPS-Users] YNT: Re: YNT: Re: RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE In-Reply-To: References: Message-ID: <543B7AA5.6060909@opensips.org> Hi Kaan, OK, you fork to .3 and .5 and I see only .5 answering - nothing back from .3 . So OpenSIPS sends back to IMS .11 the reply from .5, the 401. Where is the problem? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10.10.2014 23:48, Kaan Dandin wrote: > Yes 141 is opensips I am sending both 3 and 5 register messages when I > get from 11 which is ims bench > > > Samsung Mobile taraf?ndan g?nderildi > > > -------- Orjinal mesaj -------- > Kimden: Bogdan-Andrei Iancu > Tarih:09 10 2014 13:45 (GMT+02:00) > Al?c?: Kaan Dandin ,OpenSIPS users mailling list > > Cc: > Konu: Re: YNT: Re: [OpenSIPS-Users] RFC3261 transaction matching > failed error for the second 401 Unauthorized - Challenging the UE > > Hi, > > Is .141 your OpenSIPS ? I see .141 is sending the REGISTRAR to both > nodes ( .3 and .5) . > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 09.10.2014 10:00, Kaan Dandin wrote: >> Hi Bogdan, >> >> Thanks for your response. >> In this situation how can I configure opensips to pass this message >> to the destination. Is it a configuration change or should I use >> another function instead of t_relay ? >> >> >> Kind regards >> >> >> Samsung Mobile taraf?ndan g?nderildi >> >> >> -------- Orjinal mesaj -------- >> Kimden: Bogdan-Andrei Iancu >> Tarih:07 10 2014 16:29 (GMT+02:00) >> Al?c?: Kaan Dandin ,OpenSIPS users mailling >> list >> Cc: >> Konu: Re: [OpenSIPS-Users] RFC3261 transaction matching failed error >> for the second 401 Unauthorized - Challenging the UE >> >> Hi Kaan, >> >> The log you refer to is a DBG and not an ERR (error) - when a new >> request is received, opensips (inside the t_relay) tries to match it >> against existing transactions to see if it a retransmission on not. >> The fact your request does not match means it is not a >> retransmission, but rather a new request. >> >> Regards, >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> On 04.10.2014 11:18, Kaan Dandin wrote: >>> Hi all, >>> I am making registration to the Open IMS nodes(192.168.2.3 and >>> 192.168.2.5) simultaneously from IMS bench(192.168.2.11). >>> Registration messages are going through OpenSIPS load >>> balancer(192.168.2.141). >>> Registration messages which are going to first Open IMS >>> node(192.168.2.5) completed succesfully. >>> But registration to second IMS node(192.168.2.3) is not completed >>> successfully since t_relay() function in OpenSIPS load balancer is >>> giving "DBG:tm:matching_3261: RFC3261 transaction matching failed" >>> error and not passing the "Status: 401 Unauthorized - Challenging >>> the UE (0 bindings)" messages to IMS bench. >>> Below please find wireshark log and opensips logs in debug level=6. >>> Do you have any idea for this problem. >>> BR, >>> Kaan >>> o. Time Source Destination Protocol Info >>> 55 1.186495 192.168.2.11 192.168.2.141 SIP >>> Request: REGISTER sip:open-ims.test >>> 56 1.188443 192.168.2.141 192.168.2.3 SIP >>> Request: REGISTER sip:open-ims.test >>> 57 1.189001 192.168.2.141 192.168.2.5 SIP >>> Request: REGISTER sip:open-ims.test >>> 58 1.215792 192.168.2.5 192.168.2.141 SIP >>> Status: 401 Unauthorized - Challenging the UE (0 bindings) >>> 59 1.216974 192.168.2.141 192.168.2.11 SIP >>> Status: 401 Unauthorized - Challenging the UE (0 bindings) >>> 60 1.217486 192.168.2.11 192.168.2.141 SIP >>> Request: REGISTER sip:open-ims.test >>> 61 1.218516 192.168.2.141 192.168.2.3 SIP >>> Request: REGISTER sip:open-ims.test >>> 62 1.218804 192.168.2.141 192.168.2.5 SIP >>> Request: REGISTER sip:open-ims.test >>> 63 1.233561 192.168.2.3 192.168.2.141 SIP >>> Status: 401 Unauthorized - Challenging the UE (0 bindings) >>> 64 1.241624 192.168.2.3 192.168.2.141 SIP >>> Status: 401 Unauthorized - Challenging the UE (0 bindings) >>> 65 1.246112 192.168.2.5 192.168.2.141 SIP >>> Status: 200 OK - SAR succesful and registrar saved (1 bindings) >>> 66 1.246919 192.168.2.141 192.168.2.11 SIP >>> Status: 200 OK - SAR succesful and registrar saved (1 bindings) >>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: xlog >>> method: [REGISTER] totag: [] sipid: [192.168.2.11] messageid: >>> [68] callid: [56-6888 at 192.168.2.11] callsequence: [2] >>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>> DBG:uri:has_totag: no totag >>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>> xlog_initialregister >>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>> DBG:core:comp_scriptvar: str 20 : 192.168.2.11 >>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>> DBG:tm:t_newtran: transaction on entrance=0xffffffffffffffff >>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>> DBG:core:parse_headers: flags=ffffffffffffffff >>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>> DBG:core:get_hdr_field: content_length=0 >>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>> DBG:core:get_hdr_field: found end of header >>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>> DBG:core:parse_headers: flags=78 >>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>> DBG:tm:t_lookup_request: start searching: hash=35746, isACK=0 >>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>> DBG:tm:matching_3261: RFC3261 transaction matching failed >>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>> DBG:tm:t_lookup_request: no transaction found >>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>> DBG:tm:run_reqin_callbacks: trans=0x7fcda4739918, callback type 1, >>> id 1 entered >>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>> DBG:tm:run_reqin_callbacks: trans=0x7fcda4739918, callback type 1, >>> id 0 entered >>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>> DBG:core:check_ip_address: params 192.168.2.11, 192.168.2.11, 0 >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Oct 13 09:12:18 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 13 Oct 2014 10:12:18 +0300 Subject: [OpenSIPS-Users] ISUP and SIP-I with Opensips In-Reply-To: <5438D555.90906@ptcomm.ru> References: <5438D555.90906@ptcomm.ru> Message-ID: <543B7B52.2050101@opensips.org> Hi, SIP-I and SIP-T are extensions of SIP - and they are transparent for a SIP proxy. So OpenSIPS can route SIP-I and SIP-T. What is important is to have end-points which do understand these extensions. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 11.10.2014 09:59, ?????? ????? ?????????? wrote: > Good time! > Tell me - Opensips works with ISUP? ISUP messages can generate yourself? > If yes, then how to use SIP-I to transfer some parameters such as CPC > (Calling Party Category) or Numbering Plan Indicator....? > Thanks! > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From bogdan at opensips.org Mon Oct 13 09:22:47 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 13 Oct 2014 10:22:47 +0300 Subject: [OpenSIPS-Users] how to check debug message for stun? In-Reply-To: <5d3a96b0.1fc52.148fabf044a.Coremail.aihuawu2012@163.com> References: <17bfb9a0.1fb7d.148fab41375.Coremail.aihuawu2012@163.com> <5d3a96b0.1fc52.148fabf044a.Coremail.aihuawu2012@163.com> Message-ID: <543B7DC7.10106@opensips.org> Hi George, If you see private IPs in the VIA or Contact hdrs of the requests coming from your UAC, it means STUN was not used. You can run an ngrep on your opensips server on the IPs and ports used by STUN, to see if you receive anything from that UAC. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10.10.2014 18:48, george wu wrote: > I think my client never send stun message to the server. > the client find its public ip from the OK VIA header: > Via: SIP/2.0/UDP > 192.168.1.3:5070;received=192.168.1.3;branch=z9hG4bK.Klryaqrls;rport=5070 > > Am I right? > > > At 2014-10-10 23:36:18, "george wu" wrote: > > Hi, all: > > I can't see any debug message for stun on the opensips server side. > > I have enabled debug and set up stun as below > loadmodule "stun.so" > modparam("stun", "primary_ip", "192.168.1.3") > modparam("stun","alternate_ip","192.168.122.1") > > From the client linphone debug message, I can see > ortp-message-channel [0x1fb3080]: discovered public ip and port > are [192.168.1.3:5070] > > Just I don't see any debug message for stun, how to check it on > the server side? > Thanks. > > George > > > > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Oct 13 09:25:16 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 13 Oct 2014 10:25:16 +0300 Subject: [OpenSIPS-Users] Dispacher and Drouting question In-Reply-To: References: Message-ID: <543B7E5C.1010407@opensips.org> Hello Volkan, The drouting module sets the GW directly into RURI, so you can get its IP from $rd. The dispatcher module, depending on the function you use ( xx_dst() or xxx_domain() ) the GW may be set either in $dd, either in $rd. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10.10.2014 14:33, Volkan Oransoy wrote: > Hi, > > I am working on a special load balancing setup. For specific $rU > values, I want to keep choosen gateway and use cached value for next > time. So that, for each destination, there will be a specific gateway. > But I failed at getting the chosen gw to an avp. I am trying to get > it, just before relay with $du but it returns null. How can load > chosen gw to an avp with dispacher and drouting? > > Thanks, > > /Volkan > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Oct 13 09:27:42 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 13 Oct 2014 10:27:42 +0300 Subject: [OpenSIPS-Users] branch computation failed In-Reply-To: <1412906905090-7593931.post@n2.nabble.com> References: <1412825847529-7593895.post@n2.nabble.com> <5436691D.4010006@opensips.org> <1412906905090-7593931.post@n2.nabble.com> Message-ID: <543B7EEE.9000505@opensips.org> Hi, That is really strange - If I prepare a small patch to print some logs to understand why the t_calc_branch() fails, it ok with you to give it a try ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10.10.2014 05:08, chow wrote: > Hi Bogdan: > the param of tm : > loadmodule "tm.so" > modparam("tm", "fr_timer", 5) > modparam("tm", "fr_inv_timer", 30) > modparam("tm", "restart_fr_on_each_reply", 0) > modparam("tm", "onreply_avp_mode", 1) > > the sipp call rate is 3000 caps. > the opensips version is 1.10.1 > the opensips memory config : S_MEMORY=4096, P_MEMORY=128 > > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/branch-computation-failed-tp7593895p7593931.html > Sent from the OpenSIPS - Users mailing list archive at Nabble.com. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From zhouxiaoqiang.mstech at gmail.com Mon Oct 13 09:35:12 2014 From: zhouxiaoqiang.mstech at gmail.com (zhouxiaoqiang.mstech at gmail.com) Date: Mon, 13 Oct 2014 15:35:12 +0800 Subject: [OpenSIPS-Users] branch computation failed References: <1412825847529-7593895.post@n2.nabble.com>, <5436691D.4010006@opensips.org>, <1412906905090-7593931.post@n2.nabble.com>, <543B7EEE.9000505@opensips.org> Message-ID: <201410131535093743451@gmail.com> Hi Bogdan: I am glad to do that. please, give me your patch. zhouxiaoqiang.mstech at gmail.com From: Bogdan-Andrei Iancu Date: 2014-10-13 15:27 To: OpenSIPS users mailling list; zhouxiaoqiang.mstech Subject: Re: [OpenSIPS-Users] branch computation failed Hi, That is really strange - If I prepare a small patch to print some logs to understand why the t_calc_branch() fails, it ok with you to give it a try ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10.10.2014 05:08, chow wrote: > Hi Bogdan: > the param of tm : > loadmodule "tm.so" > modparam("tm", "fr_timer", 5) > modparam("tm", "fr_inv_timer", 30) > modparam("tm", "restart_fr_on_each_reply", 0) > modparam("tm", "onreply_avp_mode", 1) > > the sipp call rate is 3000 caps. > the opensips version is 1.10.1 > the opensips memory config : S_MEMORY=4096, P_MEMORY=128 > > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/branch-computation-failed-tp7593895p7593931.html > Sent from the OpenSIPS - Users mailing list archive at Nabble.com. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Oct 13 09:44:34 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 13 Oct 2014 10:44:34 +0300 Subject: [OpenSIPS-Users] branch computation failed In-Reply-To: <201410131535093743451@gmail.com> References: <1412825847529-7593895.post@n2.nabble.com>, <5436691D.4010006@opensips.org>, <1412906905090-7593931.post@n2.nabble.com>, <543B7EEE.9000505@opensips.org> <201410131535093743451@gmail.com> Message-ID: <543B82E2.7010003@opensips.org> Please apply this patch: https://gist.github.com/bogdan-iancu/851b092a1f457a19a463 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 13.10.2014 10:35, zhouxiaoqiang.mstech at gmail.com wrote: > Hi Bogdan: > I am glad to do that. > please, give me your patch. > > ------------------------------------------------------------------------ > zhouxiaoqiang.mstech at gmail.com > > *From:* Bogdan-Andrei Iancu > *Date:* 2014-10-13 15:27 > *To:* OpenSIPS users mailling list > ; zhouxiaoqiang.mstech > > *Subject:* Re: [OpenSIPS-Users] branch computation failed > Hi, > That is really strange - If I prepare a small patch to print some > logs > to understand why the t_calc_branch() fails, it ok with you to > give it a > try ? > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 10.10.2014 05:08, chow wrote: > > Hi Bogdan: > > the param of tm : > > loadmodule "tm.so" > > modparam("tm", "fr_timer", 5) > > modparam("tm", "fr_inv_timer", 30) > > modparam("tm", "restart_fr_on_each_reply", 0) > > modparam("tm", "onreply_avp_mode", 1) > > > > the sipp call rate is 3000 caps. > > the opensips version is 1.10.1 > > the opensips memory config : S_MEMORY=4096, P_MEMORY=128 > > > > > > > > > > -- > > View this message in context: > http://opensips-open-sip-server.1449251.n2.nabble.com/branch-computation-failed-tp7593895p7593931.html > > Sent from the OpenSIPS - Users mailing list archive at Nabble.com. > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lav at ptcomm.ru Mon Oct 13 10:19:33 2014 From: lav at ptcomm.ru (=?UTF-8?B?0JvRi9GC0LDQtdCyINCQ0L3RgtC+0L0g0JLQuNC60YLQvtGA0L7QstC40Yc=?=) Date: Mon, 13 Oct 2014 12:19:33 +0400 Subject: [OpenSIPS-Users] ISUP and SIP-I with Opensips In-Reply-To: <543B7B52.2050101@opensips.org> References: <5438D555.90906@ptcomm.ru> <543B7B52.2050101@opensips.org> Message-ID: <543B8B15.7070800@ptcomm.ru> Well, may be he Opensips endpoint? And generate ISUP messages messages? 13.10.2014 11:12, Bogdan-Andrei Iancu ?????: > SIP-I and SIP-T are extensions of SIP - and they are transparent for a > SIP proxy. So OpenSIPS can route SIP-I and SIP-T. What is important is > to have end-points which do understand these extensions. From kaandandin at yahoo.com Mon Oct 13 12:11:56 2014 From: kaandandin at yahoo.com (Kaan Dandin) Date: Mon, 13 Oct 2014 13:11:56 +0300 Subject: [OpenSIPS-Users] YNT: Re: YNT: Re: YNT: Re: RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE Message-ID: Hi Bogdan,? Following 401 messages are coming from .3 , but not passed to .11 by opensips (.141) Kind regards,? Kaan 63 1.233561????192.168.2.3??????????192.168.2.141???????? SIP????? Status: 401 Unauthorized - Challenging the UE??? (0 bindings) ?????64 1.241624????192.168.2.3??????????192.168.2.141???????? SIP????? Status: 401 Unauthorized - Challenging the UE??? (0 bindings) Samsung Mobile taraf?ndan g?nderildi
-------- Orjinal mesaj --------
Kimden: Bogdan-Andrei Iancu
Tarih:13 10 2014 10:09 (GMT+02:00)
Al?c?: Kaan Dandin ,OpenSIPS users mailling list
Cc: Gunes Kurt ,"Ibrahim Hokelek, (B?LGEM-UEKAE)"
Konu: Re: YNT: Re: YNT: Re: [OpenSIPS-Users] RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE
Hi Kaan, OK, you fork to .3 and .5 and I see only .5 answering - nothing back from .3 . So OpenSIPS sends back to IMS .11 the reply from .5, the 401. Where is the problem? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10.10.2014 23:48, Kaan Dandin wrote: Yes 141 is opensips I am sending both 3 and 5 register messages when I get from 11 which is ims bench Samsung Mobile taraf?ndan g?nderildi -------- Orjinal mesaj -------- Kimden: Bogdan-Andrei Iancu Tarih:09 10 2014 13:45 (GMT+02:00) Al?c?: Kaan Dandin ,OpenSIPS users mailling list Cc: Konu: Re: YNT: Re: [OpenSIPS-Users] RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE Hi, Is .141 your OpenSIPS ? I see .141 is sending the REGISTRAR to both nodes ( .3 and .5) . Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 09.10.2014 10:00, Kaan Dandin wrote: Hi Bogdan, Thanks for your response. In this situation how can I configure opensips to pass this message to the destination. Is it a configuration change or should I use another function instead of t_relay ? Kind regards Samsung Mobile taraf?ndan g?nderildi -------- Orjinal mesaj -------- Kimden: Bogdan-Andrei Iancu Tarih:07 10 2014 16:29 (GMT+02:00) Al?c?: Kaan Dandin ,OpenSIPS users mailling list Cc: Konu: Re: [OpenSIPS-Users] RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE Hi Kaan, The log you refer to is a DBG and not an ERR (error) - when a new request is received, opensips (inside the t_relay) tries to match it against existing transactions to see if it a retransmission on not. The fact your request does not match means it is not a retransmission, but rather a new request. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 04.10.2014 11:18, Kaan Dandin wrote: Hi all, I am making registration to the Open IMS nodes(192.168.2.3 and 192.168.2.5) simultaneously from IMS bench(192.168.2.11). Registration messages are going through OpenSIPS load balancer(192.168.2.141). Registration messages which are going to first Open IMS node(192.168.2.5) completed succesfully. But registration to second IMS node(192.168.2.3) is not completed successfully since t_relay() function in OpenSIPS load balancer is giving "DBG:tm:matching_3261: RFC3261 transaction matching failed" error and not passing the "Status: 401 Unauthorized - Challenging the UE (0 bindings)" messages to IMS bench. Below please find wireshark log and opensips logs in debug level=6. Do you have any idea for this problem. BR, Kaan o. Time Source Destination Protocol Info 55 1.186495 192.168.2.11 192.168.2.141 SIP Request: REGISTER sip:open-ims.test 56 1.188443 192.168.2.141 192.168.2.3 SIP Request: REGISTER sip:open-ims.test 57 1.189001 192.168.2.141 192.168.2.5 SIP Request: REGISTER sip:open-ims.test 58 1.215792 192.168.2.5 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) 59 1.216974 192.168.2.141 192.168.2.11 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) 60 1.217486 192.168.2.11 192.168.2.141 SIP Request: REGISTER sip:open-ims.test 61 1.218516 192.168.2.141 192.168.2.3 SIP Request: REGISTER sip:open-ims.test 62 1.218804 192.168.2.141 192.168.2.5 SIP Request: REGISTER sip:open-ims.test 63 1.233561 192.168.2.3 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) 64 1.241624 192.168.2.3 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) 65 1.246112 192.168.2.5 192.168.2.141 SIP Status: 200 OK - SAR succesful and registrar saved (1 bindings) 66 1.246919 192.168.2.141 192.168.2.11 SIP Status: 200 OK - SAR succesful and registrar saved (1 bindings) Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: xlog method: [REGISTER] totag: [] sipid: [192.168.2.11] messageid: [68] callid: [56-6888 at 192.168.2.11] callsequence: [2] Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:uri:has_totag: no totag Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: xlog_initialregister Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:comp_scriptvar: str 20 : 192.168.2.11 Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:t_newtran: transaction on entrance=0xffffffffffffffff Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:parse_headers: flags=ffffffffffffffff Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:get_hdr_field: content_length=0 Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:get_hdr_field: found end of header Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:parse_headers: flags=78 Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:t_lookup_request: start searching: hash=35746, isACK=0 Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:matching_3261: RFC3261 transaction matching failed Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:t_lookup_request: no transaction found Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:run_reqin_callbacks: trans=0x7fcda4739918, callback type 1, id 1 entered Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:run_reqin_callbacks: trans=0x7fcda4739918, callback type 1, id 0 entered Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:check_ip_address: params 192.168.2.11, 192.168.2.11, 0 _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Mon Oct 13 12:12:17 2014 From: liviu at opensips.org (Liviu Chircu) Date: Mon, 13 Oct 2014 13:12:17 +0300 Subject: [OpenSIPS-Users] ERROR:tm:t_check: INVITE reply cannot be parsed In-Reply-To: References: Message-ID: <543BA581.9020805@opensips.org> Hello Alec, Could you paste the 200 reply that is causing the error? I suspect there is something wrong with the "To" header. Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 10/07/2014 03:24 AM, Alec Doran-Twyford wrote: > Hi all, > > I am getting this error "ERROR:tm:t_check: INVITE reply cannot be parsed" > when someone makes a call though our system. > > I am not sure where it came from. I am just wondering if anyone know > some common problem when this has happens? > > Alec Doran-Twyford > | Support Engineer for IVSTel | > | E-mail: a.dorantwyford at ivstel.com > | Skype: AlecDoranTwyford | > | Phone: +61 2 9288 8890 | Mob: +61 423 694 742 | > | LinkedIn | > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Oct 13 16:26:12 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 13 Oct 2014 17:26:12 +0300 Subject: [OpenSIPS-Users] YNT: Re: YNT: Re: YNT: Re: RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE In-Reply-To: References: Message-ID: <543BE104.6000507@opensips.org> Hi Kaan, In OpenSIPS, how do you script to have the REGISTER sent to both .3 and .5 ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 13.10.2014 13:11, Kaan Dandin wrote: > Hi Bogdan, > > Following 401 messages are coming from .3 , but not passed to .11 > by opensips (.141) > > Kind regards, > Kaan >>>> 63 1.233561 192.168.2.3 >>>> 192.168.2.141 SIP Status: 401 >>>> Unauthorized - Challenging the UE (0 bindings) >>>> 64 1.241624 192.168.2.3 >>>> 192.168.2.141 SIP Status: 401 >>>> Unauthorized - Challenging the UE (0 bindings) > > > > Samsung Mobile taraf?ndan g?nderildi > > > -------- Orjinal mesaj -------- > Kimden: Bogdan-Andrei Iancu > Tarih:13 10 2014 10:09 (GMT+02:00) > Al?c?: Kaan Dandin ,OpenSIPS users mailling list > > Cc: Gunes Kurt ,"Ibrahim Hokelek, (B?LGEM-UEKAE)" > > Konu: Re: YNT: Re: YNT: Re: [OpenSIPS-Users] RFC3261 transaction > matching failed error for the second 401 Unauthorized - Challenging > the UE > > Hi Kaan, > > OK, you fork to .3 and .5 and I see only .5 answering - nothing back > from .3 . So OpenSIPS sends back to IMS .11 the reply from .5, the 401. > Where is the problem? > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 10.10.2014 23:48, Kaan Dandin wrote: >> Yes 141 is opensips I am sending both 3 and 5 register messages when >> I get from 11 which is ims bench >> >> >> Samsung Mobile taraf?ndan g?nderildi >> >> >> -------- Orjinal mesaj -------- >> Kimden: Bogdan-Andrei Iancu >> Tarih:09 10 2014 13:45 (GMT+02:00) >> Al?c?: Kaan Dandin ,OpenSIPS users mailling >> list >> Cc: >> Konu: Re: YNT: Re: [OpenSIPS-Users] RFC3261 transaction matching >> failed error for the second 401 Unauthorized - Challenging the UE >> >> Hi, >> >> Is .141 your OpenSIPS ? I see .141 is sending the REGISTRAR to both >> nodes ( .3 and .5) . >> >> Regards, >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> On 09.10.2014 10:00, Kaan Dandin wrote: >>> Hi Bogdan, >>> >>> Thanks for your response. >>> In this situation how can I configure opensips to pass this message >>> to the destination. Is it a configuration change or should I use >>> another function instead of t_relay ? >>> >>> >>> Kind regards >>> >>> >>> Samsung Mobile taraf?ndan g?nderildi >>> >>> >>> -------- Orjinal mesaj -------- >>> Kimden: Bogdan-Andrei Iancu >>> Tarih:07 10 2014 16:29 (GMT+02:00) >>> Al?c?: Kaan Dandin ,OpenSIPS users mailling >>> list >>> Cc: >>> Konu: Re: [OpenSIPS-Users] RFC3261 transaction matching failed error >>> for the second 401 Unauthorized - Challenging the UE >>> >>> Hi Kaan, >>> >>> The log you refer to is a DBG and not an ERR (error) - when a new >>> request is received, opensips (inside the t_relay) tries to match it >>> against existing transactions to see if it a retransmission on not. >>> The fact your request does not match means it is not a >>> retransmission, but rather a new request. >>> >>> Regards, >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> On 04.10.2014 11:18, Kaan Dandin wrote: >>>> Hi all, >>>> I am making registration to the Open IMS nodes(192.168.2.3 and >>>> 192.168.2.5) simultaneously from IMS bench(192.168.2.11). >>>> Registration messages are going through OpenSIPS load >>>> balancer(192.168.2.141). >>>> Registration messages which are going to first Open IMS >>>> node(192.168.2.5) completed succesfully. >>>> But registration to second IMS node(192.168.2.3) is not completed >>>> successfully since t_relay() function in OpenSIPS load balancer is >>>> giving "DBG:tm:matching_3261: RFC3261 transaction matching failed" >>>> error and not passing the "Status: 401 Unauthorized - Challenging >>>> the UE (0 bindings)" messages to IMS bench. >>>> Below please find wireshark log and opensips logs in debug level=6. >>>> Do you have any idea for this problem. >>>> BR, >>>> Kaan >>>> o. Time Source Destination Protocol Info >>>> 55 1.186495 192.168.2.11 192.168.2.141 SIP >>>> Request: REGISTER sip:open-ims.test >>>> 56 1.188443 192.168.2.141 192.168.2.3 SIP >>>> Request: REGISTER sip:open-ims.test >>>> 57 1.189001 192.168.2.141 192.168.2.5 SIP >>>> Request: REGISTER sip:open-ims.test >>>> 58 1.215792 192.168.2.5 192.168.2.141 SIP >>>> Status: 401 Unauthorized - Challenging the UE (0 bindings) >>>> 59 1.216974 192.168.2.141 192.168.2.11 SIP >>>> Status: 401 Unauthorized - Challenging the UE (0 bindings) >>>> 60 1.217486 192.168.2.11 192.168.2.141 SIP >>>> Request: REGISTER sip:open-ims.test >>>> 61 1.218516 192.168.2.141 192.168.2.3 SIP >>>> Request: REGISTER sip:open-ims.test >>>> 62 1.218804 192.168.2.141 192.168.2.5 SIP >>>> Request: REGISTER sip:open-ims.test >>>> 63 1.233561 192.168.2.3 192.168.2.141 SIP >>>> Status: 401 Unauthorized - Challenging the UE (0 bindings) >>>> 64 1.241624 192.168.2.3 192.168.2.141 SIP >>>> Status: 401 Unauthorized - Challenging the UE (0 bindings) >>>> 65 1.246112 192.168.2.5 192.168.2.141 SIP >>>> Status: 200 OK - SAR succesful and registrar saved (1 bindings) >>>> 66 1.246919 192.168.2.141 192.168.2.11 SIP >>>> Status: 200 OK - SAR succesful and registrar saved (1 bindings) >>>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>>> xlog method: [REGISTER] totag: [] sipid: [192.168.2.11] >>>> messageid: [68] callid: [56-6888 at 192.168.2.11] callsequence: [2] >>>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>>> DBG:uri:has_totag: no totag >>>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>>> xlog_initialregister >>>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>>> DBG:core:comp_scriptvar: str 20 : 192.168.2.11 >>>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>>> DBG:tm:t_newtran: transaction on entrance=0xffffffffffffffff >>>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>>> DBG:core:parse_headers: flags=ffffffffffffffff >>>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>>> DBG:core:get_hdr_field: content_length=0 >>>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>>> DBG:core:get_hdr_field: found end of header >>>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>>> DBG:core:parse_headers: flags=78 >>>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>>> DBG:tm:t_lookup_request: start searching: hash=35746, isACK=0 >>>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>>> DBG:tm:matching_3261: RFC3261 transaction matching failed >>>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>>> DBG:tm:t_lookup_request: no transaction found >>>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>>> DBG:tm:run_reqin_callbacks: trans=0x7fcda4739918, callback type 1, >>>> id 1 entered >>>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>>> DBG:tm:run_reqin_callbacks: trans=0x7fcda4739918, callback type 1, >>>> id 0 entered >>>> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >>>> DBG:core:check_ip_address: params 192.168.2.11, 192.168.2.11, 0 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From voransoy at gmail.com Mon Oct 13 18:43:00 2014 From: voransoy at gmail.com (Volkan Oransoy) Date: Mon, 13 Oct 2014 19:43:00 +0300 Subject: [OpenSIPS-Users] Dispacher and Drouting question In-Reply-To: <543B7E5C.1010407@opensips.org> References: <543B7E5C.1010407@opensips.org> Message-ID: Thank you Bogdan, Setting $rd did the job. Regards, 2014-10-13 10:25 GMT+03:00 Bogdan-Andrei Iancu : > Hello Volkan, > > The drouting module sets the GW directly into RURI, so you can get its IP > from $rd. > The dispatcher module, depending on the function you use ( xx_dst() or > xxx_domain() ) the GW may be set either in $dd, either in $rd. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > On 10.10.2014 14:33, Volkan Oransoy wrote: > > Hi, > > I am working on a special load balancing setup. For specific $rU > values, I want to keep choosen gateway and use cached value for next time. > So that, for each destination, there will be a specific gateway. But I > failed at getting the chosen gw to an avp. I am trying to get it, just > before relay with $du but it returns null. How can load chosen gw to an avp > with dispacher and drouting? > > Thanks, > > /Volkan > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaandandin at yahoo.com Mon Oct 13 18:45:26 2014 From: kaandandin at yahoo.com (Kaan Dandin) Date: Mon, 13 Oct 2014 09:45:26 -0700 Subject: [OpenSIPS-Users] YNT: Re: YNT: Re: YNT: Re: RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE In-Reply-To: <543BE104.6000507@opensips.org> References: <543BE104.6000507@opensips.org> Message-ID: <1413218726.55580.YahooMailNeo@web121503.mail.ne1.yahoo.com> Hi Bogdan, I am using following lines (just sharing related part of the script) to check first if the method is REGISTER and sending to .3 (open ims node 1) and .5(open ims node 2) if it is coming from .11(ims bench traffic generator). Otherwise I am sending directly to the set destination. else if (is_method("REGISTER")) { xlog("xlog_initialregister"); if($si=="192.168.2.11") { t_relay("udp:192.168.2.3:4060"); t_relay("udp:192.168.2.5:4060"); exit; } if (!t_relay()) { xlog("xlog_route1error"); sl_reply_error(); }; exit; } Kind regards, Kaan ________________________________ From: Bogdan-Andrei Iancu To: Kaan Dandin ; OpenSIPS users mailling list Cc: Gunes Kurt ; "Ibrahim Hokelek, (B?LGEM-UEKAE)" Sent: Monday, October 13, 2014 5:26 PM Subject: Re: YNT: Re: YNT: Re: YNT: Re: [OpenSIPS-Users] RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE Hi Kaan, In OpenSIPS, how do you script to have the REGISTER sent to both .3 and .5 ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 13.10.2014 13:11, Kaan Dandin wrote: Hi Bogdan, Following 401 messages are coming from .3 , but not passed to .11 by opensips (.141) Kind regards, Kaan 63 1.233561 192.168.2.3 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) >>> 64 1.241624 192.168.2.3 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) Samsung Mobile taraf?ndan g?nderildi -------- Orjinal mesaj -------- Kimden: Bogdan-Andrei Iancu Tarih:13 10 2014 10:09 (GMT+02:00) Al?c?: Kaan Dandin ,OpenSIPS users mailling list Cc: Gunes Kurt ,"Ibrahim Hokelek, (B?LGEM-UEKAE)" Konu: Re: YNT: Re: YNT: Re: [OpenSIPS-Users] RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE Hi Kaan, OK, you fork to .3 and .5 and I see only .5 answering - nothing back from .3 . So OpenSIPS sends back to IMS .11 the reply from .5, the 401. Where is the problem? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10.10.2014 23:48, Kaan Dandin wrote: Yes 141 is opensips I am sending both 3 and 5 register messages when I get from 11 which is ims bench Samsung Mobile taraf?ndan g?nderildi -------- Orjinal mesaj -------- Kimden: Bogdan-Andrei Iancu Tarih:09 10 2014 13:45 (GMT+02:00) Al?c?: Kaan Dandin ,OpenSIPS users mailling list Cc: Konu: Re: YNT: Re: [OpenSIPS-Users] RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE Hi, Is .141 your OpenSIPS ? I see .141 is sending the REGISTRAR to both nodes ( .3 and .5) . Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 09.10.2014 10:00, Kaan Dandin wrote: Hi Bogdan, Thanks for your response. In this situation how can I configure opensips to pass this message to the destination. Is it a configuration change or should I use another function instead of t_relay ? Kind regards Samsung Mobile taraf?ndan g?nderildi -------- Orjinal mesaj -------- Kimden: Bogdan-Andrei Iancu Tarih:07 10 2014 16:29 (GMT+02:00) Al?c?: Kaan Dandin ,OpenSIPS users mailling list Cc: Konu: Re: [OpenSIPS-Users] RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE Hi Kaan, The log you refer to is a DBG and not an ERR (error) - when a new request is received, opensips (inside the t_relay) tries to match it against existing transactions to see if it a retransmission on not. The fact your request does not match means it is not a retransmission, but rather a new request. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 04.10.2014 11:18, Kaan Dandin wrote: Hi all, > >I am making registration to the Open IMS nodes(192.168.2.3 and 192.168.2.5) simultaneously from IMS bench(192.168.2.11). Registration messages are going through OpenSIPS load balancer(192.168.2.141). > >Registration messages which are going to first Open IMS node(192.168.2.5) completed succesfully. > > >But registration to second IMS node(192.168.2.3) is not completed successfully since t_relay() function in OpenSIPS load balancer is giving "DBG:tm:matching_3261: RFC3261 transaction matching failed" error and not passing the "Status: 401 Unauthorized - Challenging the UE (0 bindings)" messages to IMS bench. > >Below please find wireshark log and opensips logs in debug level=6. > >Do you have any idea for this problem. > >BR, >Kaan > > >o. Time Source Destination Protocol Info > 55 1.186495 192.168.2.11 192.168.2.141 SIP Request: REGISTER sip:open-ims.test > 56 1.188443 192.168.2.141 192.168.2.3 SIP Request: REGISTER sip:open-ims.test > 57 1.189001 192.168.2.141 192.168.2.5 SIP Request: REGISTER sip:open-ims.test > 58 1.215792 192.168.2.5 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) > 59 1.216974 192.168.2.141 192.168.2.11 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) > 60 1.217486 192.168.2.11 192.168.2.141 SIP Request: REGISTER sip:open-ims.test > 61 1.218516 192.168.2.141 192.168.2.3 SIP Request: REGISTER sip:open-ims.test > 62 1.218804 192.168.2.141 192.168.2.5 SIP Request: REGISTER sip:open-ims.test > 63 1.233561 192.168.2.3 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) > 64 1.241624 192.168.2.3 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) > 65 1.246112 192.168.2.5 192.168.2.141 SIP Status: 200 OK - SAR succesful and registrar saved (1 bindings) > 66 1.246919 192.168.2.141 192.168.2.11 SIP Status: 200 OK - SAR succesful and registrar saved (1 bindings) > > > >Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: xlog method: [REGISTER] totag: [] sipid: [192.168.2.11] messageid: [68] callid: [56-6888 at 192.168.2.11] callsequence: [2] >Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:uri:has_totag: no totag >Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: xlog_initialregister >Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:comp_scriptvar: str 20 : 192.168.2.11 >Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:t_newtran: transaction on entrance=0xffffffffffffffff >Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:parse_headers: flags=ffffffffffffffff >Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:get_hdr_field: content_length=0 >Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:get_hdr_field: found end of header >Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:parse_headers: flags=78 >Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:t_lookup_request: start searching: hash=35746, isACK=0 >Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:matching_3261: RFC3261 transaction matching failed >Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:t_lookup_request: no transaction found >Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:run_reqin_callbacks: trans=0x7fcda4739918, callback type 1, id 1 entered >Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:tm:run_reqin_callbacks: trans=0x7fcda4739918, callback type 1, id 0 entered >Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: DBG:core:check_ip_address: params 192.168.2.11, 192.168.2.11, 0 > > > > >_______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Oct 13 19:05:07 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 13 Oct 2014 20:05:07 +0300 Subject: [OpenSIPS-Users] YNT: Re: YNT: Re: YNT: Re: RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE In-Reply-To: <1413218726.55580.YahooMailNeo@web121503.mail.ne1.yahoo.com> References: <543BE104.6000507@opensips.org> <1413218726.55580.YahooMailNeo@web121503.mail.ne1.yahoo.com> Message-ID: <543C0643.8020906@opensips.org> Hi Kaan, That is completely wrong as you break the transaction logic. The correct way of doing parallel forking is : if($si=="192.168.2.11") { $du = "sip:192.168.2.3:4060"; append_branch(); # add first destination with the above value $du = "sip:192.168.2.5:4060"; t_relay(); } Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 13.10.2014 19:45, Kaan Dandin wrote: > Hi Bogdan, > > > I am using following lines (just sharing related part of the script) > to check first if the method is REGISTER and sending to .3 (open ims > node 1) and .5(open ims node 2) if it is coming from .11(ims bench > traffic generator). > Otherwise I am sending directly to the set destination. > > > else if (is_method("REGISTER")) { > > xlog("xlog_initialregister"); > > if($si=="192.168.2.11") { > t_relay("udp:192.168.2.3:4060"); > t_relay("udp:192.168.2.5:4060"); > exit; > } > > if (!t_relay()) { > xlog("xlog_route1error"); > sl_reply_error(); > }; > exit; > > } > > > > > Kind regards, > Kaan > ------------------------------------------------------------------------ > *From:* Bogdan-Andrei Iancu > *To:* Kaan Dandin ; OpenSIPS users mailling list > > *Cc:* Gunes Kurt ; "Ibrahim Hokelek, (B?LGEM-UEKAE)" > > *Sent:* Monday, October 13, 2014 5:26 PM > *Subject:* Re: YNT: Re: YNT: Re: YNT: Re: [OpenSIPS-Users] RFC3261 > transaction matching failed error for the second 401 Unauthorized - > Challenging the UE > > Hi Kaan, > > In OpenSIPS, how do you script to have the REGISTER sent to both .3 > and .5 ? > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 13.10.2014 13:11, Kaan Dandin wrote: > Hi Bogdan, > > Following 401 messages are coming from .3 , but not passed to .11 > by opensips (.141) > > Kind regards, > Kaan >>>> 63 1.233561 192.168.2.3 192.168.2.141 >>>> SIP Status: 401 Unauthorized - >>>> Challenging the UE (0 bindings) >>>> 64 1.241624 192.168.2.3 192.168.2.141 >>>> SIP Status: 401 Unauthorized - >>>> Challenging the UE (0 bindings) > > > > Samsung Mobile taraf?ndan g?nderildi > > > -------- Orjinal mesaj -------- > Kimden: Bogdan-Andrei Iancu > > Tarih:13 10 2014 10:09 (GMT+02:00) > Al?c?: Kaan Dandin > ,OpenSIPS users mailling list > > Cc: Gunes Kurt ,"Ibrahim > Hokelek, (B?LGEM-UEKAE)" > > Konu: Re: YNT: Re: YNT: Re: [OpenSIPS-Users] RFC3261 transaction > matching failed error for the second 401 Unauthorized - Challenging > the UE > > Hi Kaan, > > OK, you fork to .3 and .5 and I see only .5 answering - nothing back > from .3 . So OpenSIPS sends back to IMS .11 the reply from .5, the 401. > Where is the problem? > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 10.10.2014 23:48, Kaan Dandin wrote: > Yes 141 is opensips I am sending both 3 and 5 register messages when I > get from 11 which is ims bench > > > Samsung Mobile taraf?ndan g?nderildi > > > -------- Orjinal mesaj -------- > Kimden: Bogdan-Andrei Iancu > > Tarih:09 10 2014 13:45 (GMT+02:00) > Al?c?: Kaan Dandin > ,OpenSIPS users mailling list > > Cc: > Konu: Re: YNT: Re: [OpenSIPS-Users] RFC3261 transaction matching > failed error for the second 401 Unauthorized - Challenging the UE > > Hi, > > Is .141 your OpenSIPS ? I see .141 is sending the REGISTRAR to both > nodes ( .3 and .5) . > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 09.10.2014 10:00, Kaan Dandin wrote: > Hi Bogdan, > > Thanks for your response. > In this situation how can I configure opensips to pass this message to > the destination. Is it a configuration change or should I use another > function instead of t_relay ? > > > Kind regards > > > Samsung Mobile taraf?ndan g?nderildi > > > -------- Orjinal mesaj -------- > Kimden: Bogdan-Andrei Iancu > > Tarih:07 10 2014 16:29 (GMT+02:00) > Al?c?: Kaan Dandin > ,OpenSIPS users mailling list > > Cc: > Konu: Re: [OpenSIPS-Users] RFC3261 transaction matching failed error > for the second 401 Unauthorized - Challenging the UE > > Hi Kaan, > > The log you refer to is a DBG and not an ERR (error) - when a new > request is received, opensips (inside the t_relay) tries to match it > against existing transactions to see if it a retransmission on not. > The fact your request does not match means it is not a retransmission, > but rather a new request. > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > On 04.10.2014 11:18, Kaan Dandin wrote: >> Hi all, >> I am making registration to the Open IMS nodes(192.168.2.3 and >> 192.168.2.5) simultaneously from IMS bench(192.168.2.11). >> Registration messages are going through OpenSIPS load >> balancer(192.168.2.141). >> Registration messages which are going to first Open IMS >> node(192.168.2.5) completed succesfully. >> But registration to second IMS node(192.168.2.3) is not completed >> successfully since t_relay() function in OpenSIPS load balancer is >> giving "DBG:tm:matching_3261: RFC3261 transaction matching failed" >> error and not passing the "Status: 401 Unauthorized - Challenging the >> UE (0 bindings)" messages to IMS bench. >> Below please find wireshark log and opensips logs in debug level=6. >> Do you have any idea for this problem. >> BR, >> Kaan >> o. Time Source Destination Protocol Info >> 55 1.186495 192.168.2.11 192.168.2.141 SIP >> Request: REGISTER sip:open-ims.test >> 56 1.188443 192.168.2.141 192.168.2.3 SIP >> Request: REGISTER sip:open-ims.test >> 57 1.189001 192.168.2.141 192.168.2.5 SIP >> Request: REGISTER sip:open-ims.test >> 58 1.215792 192.168.2.5 192.168.2.141 SIP >> Status: 401 Unauthorized - Challenging the UE (0 bindings) >> 59 1.216974 192.168.2.141 192.168.2.11 SIP >> Status: 401 Unauthorized - Challenging the UE (0 bindings) >> 60 1.217486 192.168.2.11 192.168.2.141 SIP >> Request: REGISTER sip:open-ims.test >> 61 1.218516 192.168.2.141 192.168.2.3 SIP >> Request: REGISTER sip:open-ims.test >> 62 1.218804 192.168.2.141 192.168.2.5 SIP >> Request: REGISTER sip:open-ims.test >> 63 1.233561 192.168.2.3 192.168.2.141 SIP >> Status: 401 Unauthorized - Challenging the UE (0 bindings) >> 64 1.241624 192.168.2.3 192.168.2.141 SIP >> Status: 401 Unauthorized - Challenging the UE (0 bindings) >> 65 1.246112 192.168.2.5 192.168.2.141 SIP >> Status: 200 OK - SAR succesful and registrar saved (1 bindings) >> 66 1.246919 192.168.2.141 192.168.2.11 SIP >> Status: 200 OK - SAR succesful and registrar saved (1 bindings) >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: xlog >> method: [REGISTER] totag: [] sipid: [192.168.2.11] messageid: >> [68] callid: [56-6888 at 192.168.2.11 ] >> callsequence: [2] >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:uri:has_totag: no totag >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> xlog_initialregister >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:core:comp_scriptvar: str 20 : 192.168.2.11 >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:tm:t_newtran: transaction on entrance=0xffffffffffffffff >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:core:parse_headers: flags=ffffffffffffffff >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:core:get_hdr_field: content_length=0 >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:core:get_hdr_field: found end of header >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:core:parse_headers: flags=78 >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:tm:t_lookup_request: start searching: hash=35746, isACK=0 >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:tm:matching_3261: RFC3261 transaction matching failed >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:tm:t_lookup_request: no transaction found >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:tm:run_reqin_callbacks: trans=0x7fcda4739918, callback type 1, id >> 1 entered >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:tm:run_reqin_callbacks: trans=0x7fcda4739918, callback type 1, id >> 0 entered >> Oct 3 10:01:35 ubuntu /usr/local/opensips/sbin/opensips[8938]: >> DBG:core:check_ip_address: params 192.168.2.11, 192.168.2.11, 0 >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaandandin at yahoo.com Mon Oct 13 19:03:53 2014 From: kaandandin at yahoo.com (Kaan Dandin) Date: Mon, 13 Oct 2014 10:03:53 -0700 Subject: [OpenSIPS-Users] YNT: Re: YNT: Re: YNT: Re: RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE In-Reply-To: <543BE104.6000507@opensips.org> References: <543BE104.6000507@opensips.org> Message-ID: <1413219833.26498.YahooMailNeo@web121501.mail.ne1.yahoo.com> Hi Bogdan, I am using following lines (just sharing related part of the script) to check first if the method is REGISTER and sending to .3 (open ims node 1) and .5(open ims node 2) if it is coming from .11(ims bench traffic generator). Otherwise I am sending directly to the set destination. else if (is_method("REGISTER")) { xlog("xlog_initialregister"); if($si=="192.168.2.11") { t_relay("udp:192.168.2.3:4060"); t_relay("udp:192.168.2.5:4060"); exit; } if (!t_relay()) { xlog("xlog_route1error"); sl_reply_error(); }; exit; } Kind regards, Kaan ________________________________ From: Bogdan-Andrei Iancu To: Kaan Dandin ; OpenSIPS users mailling list Cc: Gunes Kurt ; "Ibrahim Hokelek, (B?LGEM-UEKAE)" Sent: Monday, October 13, 2014 5:26 PM Subject: Re: YNT: Re: YNT: Re: YNT: Re: [OpenSIPS-Users] RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE Hi Kaan, In OpenSIPS, how do you script to have the REGISTER sent to both .3 and .5 ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 13.10.2014 13:11, Kaan Dandin wrote: Hi Bogdan, Following 401 messages are coming from .3 , but not passed to .11 by opensips (.141) Kind regards, Kaan 63 1.233561 192.168.2.3 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) >>> 64 1.241624 192.168.2.3 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) Samsung Mobile taraf?ndan g?nderildi -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaandandin at yahoo.com Mon Oct 13 22:01:23 2014 From: kaandandin at yahoo.com (Kaan Dandin) Date: Mon, 13 Oct 2014 13:01:23 -0700 Subject: [OpenSIPS-Users] YNT: Re: YNT: Re: YNT: Re: RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE In-Reply-To: <543C0643.8020906@opensips.org> References: <543BE104.6000507@opensips.org> <1413218726.55580.YahooMailNeo@web121503.mail.ne1.yahoo.com> <543C0643.8020906@opensips.org> Message-ID: <1413230483.7897.YahooMailNeo@web121502.mail.ne1.yahoo.com> Hi Bogdan, Thanks for the response. I have edited the script as you have mentioned but I have the same problem: 401 message going to .3 is not passed by .141(opensips lb) else if (is_method("REGISTER")) { xlog("xlog_initialregister"); if($si=="192.168.2.11") { $du = "sip:192.168.2.3:4060"; append_branch(); $du = "sip:192.168.2.5:4060"; t_relay(); exit; } if (!t_relay()) { xlog("xlog_route1error"); sl_reply_error(); }; No. Time Source Destination Protocol Info 57 13.772015 192.168.2.11 192.168.2.141 SIP Request: REGISTER sip:open-ims.test 58 13.774094 192.168.2.141 192.168.2.5 SIP Request: REGISTER sip:open-ims.test 59 13.774097 192.168.2.141 192.168.2.3 SIP Request: REGISTER sip:open-ims.test 60 13.890456 192.168.2.3 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) 61 14.046746 192.168.2.5 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) 62 14.047052 192.168.2.141 192.168.2.11 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) 63 14.047538 192.168.2.11 192.168.2.141 SIP Request: REGISTER sip:open-ims.test 64 14.047887 192.168.2.141 192.168.2.5 SIP Request: REGISTER sip:open-ims.test 65 14.047947 192.168.2.141 192.168.2.3 SIP Request: REGISTER sip:open-ims.test 66 14.084120 192.168.2.3 192.168.2.141 SIP Status: 401 Unauthorized - Challenging the UE (0 bindings) 67 14.112597 192.168.2.5 192.168.2.141 SIP Status: 200 OK - SAR succesful and registrar saved (1 bindings) 68 14.112755 192.168.2.141 192.168.2.11 SIP Status: 200 OK - SAR succesful and registrar saved (1 bindings) Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: xlog method: [REGISTER] totag: [] sipid: [192.168.2.11] messageid: [1] callid: [1-3096 at 192.168.2.11] callsequence: [2] Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: DBG:uri:has_totag: no totag Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: xlog_initialregister Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: DBG:core:comp_scriptvar: str 20 : 192.168.2.11 Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: DBG:tm:t_newtran: transaction on entrance=0xffffffffffffffff Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: DBG:core:parse_headers: flags=ffffffffffffffff Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: DBG:core:get_hdr_field: content_length=0 Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: DBG:core:get_hdr_field: found end of header Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: DBG:core:parse_headers: flags=78 Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: DBG:tm:t_lookup_request: start searching: hash=23653, isACK=0 Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: DBG:tm:matching_3261: RFC3261 transaction matching failed Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: DBG:tm:t_lookup_request: no transaction found Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: DBG:tm:run_reqin_callbacks: trans=0x7fc6d2b0d9e8, callback type 1, id 1 entered Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: DBG:tm:run_reqin_callbacks: trans=0x7fc6d2b0d9e8, callback type 1, id 0 entered Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: DBG:core:_shm_resize: resize(0) called Kind regardsi Kaan ________________________________ From: Bogdan-Andrei Iancu To: Kaan Dandin ; OpenSIPS users mailling list Cc: Gunes Kurt ; "Ibrahim Hokelek, (B?LGEM-UEKAE)" Sent: Monday, October 13, 2014 8:05 PM Subject: Re: YNT: Re: YNT: Re: YNT: Re: [OpenSIPS-Users] RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE Hi Kaan, That is completely wrong as you break the transaction logic. The correct way of doing parallel forking is : if($si=="192.168.2.11") { $du = "sip:192.168.2.3:4060"; append_branch(); # add first destination with the above value $du = "sip:192.168.2.5:4060"; t_relay(); } Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhouxiaoqiang.mstech at gmail.com Tue Oct 14 03:51:17 2014 From: zhouxiaoqiang.mstech at gmail.com (zhouxiaoqiang.mstech at gmail.com) Date: Tue, 14 Oct 2014 09:51:17 +0800 Subject: [OpenSIPS-Users] branch computation failed References: <1412825847529-7593895.post@n2.nabble.com>, <5436691D.4010006@opensips.org>, <1412906905090-7593931.post@n2.nabble.com>, <543B7EEE.9000505@opensips.org>, <201410131535093743451@gmail.com>, <543B82E2.7010003@opensips.org> Message-ID: <201410140951152215038@gmail.com> Hi: I execute that patch . the sipp beging run at Oct 13 19:07:01 The following is a log fragment. Oct 13 19:07:01 localhost /usr/sbin/opensips[24352]: ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe Oct 13 19:27:01 localhost /usr/sbin/opensips[24352]: ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe Oct 13 19:29:01 localhost /usr/sbin/opensips[24352]: ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe Oct 13 19:37:01 localhost /usr/sbin/opensips[24352]: ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe Oct 13 19:55:01 localhost /usr/sbin/opensips[24352]: ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe Oct 13 20:06:01 localhost /usr/sbin/opensips[24352]: ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe Oct 13 20:25:01 localhost /usr/sbin/opensips[24352]: ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe Oct 13 20:30:01 localhost /usr/sbin/opensips[24352]: ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe Oct 13 20:49:01 localhost /usr/sbin/opensips[24352]: ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe Oct 13 20:50:01 localhost /usr/sbin/opensips[24352]: ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe Oct 13 20:57:02 localhost /usr/sbin/opensips[24352]: ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe Oct 13 21:14:12 localhost /usr/sbin/opensips[24437]: ERROR:core:branch_builder: writing the label failed, remaining size is 0 Oct 13 21:14:12 localhost /usr/sbin/opensips[24437]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 13 21:14:12 localhost /usr/sbin/opensips[24437]: ERROR:tm:t_forward_nonack: failure to add branches Oct 13 21:14:19 localhost /usr/sbin/opensips[24463]: ERROR:core:branch_builder: writing the label failed, remaining size is 0 Oct 13 21:14:19 localhost /usr/sbin/opensips[24463]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 13 21:14:19 localhost /usr/sbin/opensips[24463]: ERROR:tm:t_forward_nonack: failure to add branches ... ... ... ... Oct 13 23:32:52 localhost /usr/sbin/opensips[24475]: ERROR:core:branch_builder: writing the label failed, remaining size is 0 Oct 13 23:32:52 localhost /usr/sbin/opensips[24475]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 13 23:32:52 localhost /usr/sbin/opensips[24475]: ERROR:tm:t_forward_nonack: failure to add branches Oct 13 23:32:52 localhost /usr/sbin/opensips[24434]: ERROR:core:branch_builder: writing the label failed, remaining size is 0 Oct 13 23:32:52 localhost /usr/sbin/opensips[24434]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 13 23:32:52 localhost /usr/sbin/opensips[24434]: ERROR:tm:t_forward_nonack: failure to add branches Oct 13 23:32:54 localhost /usr/sbin/opensips[24442]: ERROR:core:branch_builder: writing the label failed, remaining size is 0 Oct 13 23:32:54 localhost /usr/sbin/opensips[24442]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 13 23:32:54 localhost /usr/sbin/opensips[24442]: ERROR:tm:t_forward_nonack: failure to add branches Oct 13 23:32:54 localhost /usr/sbin/opensips[24397]: ERROR:core:branch_builder: writing the label failed, remaining size is 0 Oct 13 23:32:54 localhost /usr/sbin/opensips[24397]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 13 23:32:54 localhost /usr/sbin/opensips[24397]: ERROR:tm:t_forward_nonack: failure to add branches Oct 13 23:32:55 localhost /usr/sbin/opensips[24447]: ERROR:core:branch_builder: writing the label failed, remaining size is 0 Oct 13 23:32:55 localhost /usr/sbin/opensips[24447]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 13 23:32:55 localhost /usr/sbin/opensips[24447]: ERROR:tm:t_forward_nonack: failure to add branches Oct 13 23:32:55 localhost /usr/sbin/opensips[24459]: ERROR:core:branch_builder: writing the label failed, remaining size is 0 Oct 13 23:32:55 localhost /usr/sbin/opensips[24459]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 13 23:32:55 localhost /usr/sbin/opensips[24459]: ERROR:tm:t_forward_nonack: failure to add branches Oct 13 23:32:57 localhost /usr/sbin/opensips[24458]: ERROR:core:branch_builder: writing the label failed, remaining size is 0 Oct 13 23:32:57 localhost /usr/sbin/opensips[24458]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 13 23:32:57 localhost /usr/sbin/opensips[24458]: ERROR:tm:t_forward_nonack: failure to add branches Oct 13 23:32:58 localhost /usr/sbin/opensips[24485]: CRITICAL:core:utimer_ticker: utimer handler lasted (180000 us) for more than timer tick (100000 us) -> potential timer shifting Oct 13 23:32:59 localhost /usr/sbin/opensips[24359]: ERROR:core:branch_builder: writing the label failed, remaining size is 0 Oct 13 23:32:59 localhost /usr/sbin/opensips[24359]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 13 23:32:59 localhost /usr/sbin/opensips[24359]: ERROR:tm:t_forward_nonack: failure to add branches Oct 13 23:32:59 localhost /usr/sbin/opensips[24452]: ERROR:core:branch_builder: writing the label failed, remaining size is 0 Oct 13 23:32:59 localhost /usr/sbin/opensips[24452]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 13 23:32:59 localhost /usr/sbin/opensips[24452]: ERROR:tm:t_forward_nonack: failure to add branches Oct 13 23:33:00 localhost /usr/sbin/opensips[24471]: ERROR:core:branch_builder: writing the label failed, remaining size is 0 Oct 13 23:33:00 localhost /usr/sbin/opensips[24471]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 13 23:33:00 localhost /usr/sbin/opensips[24471]: ERROR:tm:t_forward_nonack: failure to add branches Oct 13 23:33:00 localhost /usr/sbin/opensips[24367]: ERROR:core:branch_builder: writing the label failed, remaining size is 0 Oct 13 23:33:00 localhost /usr/sbin/opensips[24367]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 13 23:33:00 localhost /usr/sbin/opensips[24367]: ERROR:tm:t_forward_nonack: failure to add branches Oct 13 23:33:02 localhost /usr/sbin/opensips[24364]: ERROR:core:branch_builder: writing the label failed, remaining size is 0 Oct 13 23:33:02 localhost /usr/sbin/opensips[24364]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 13 23:33:02 localhost /usr/sbin/opensips[24364]: ERROR:tm:t_forward_nonack: failure to add branches Oct 13 23:33:02 localhost /usr/sbin/opensips[24413]: ERROR:core:branch_builder: writing the label failed, remaining size is 0 zhouxiaoqiang.mstech at gmail.com From: Bogdan-Andrei Iancu Date: 2014-10-13 15:44 To: zhouxiaoqiang.mstech at gmail.com; users at lists.opensips.org Subject: Re: [OpenSIPS-Users] branch computation failed Please apply this patch: https://gist.github.com/bogdan-iancu/851b092a1f457a19a463 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.comOn 13.10.2014 10:35, zhouxiaoqiang.mstech at gmail.com wrote: Hi Bogdan: I am glad to do that. please, give me your patch. zhouxiaoqiang.mstech at gmail.com From: Bogdan-Andrei Iancu Date: 2014-10-13 15:27 To: OpenSIPS users mailling list; zhouxiaoqiang.mstech Subject: Re: [OpenSIPS-Users] branch computation failed Hi, That is really strange - If I prepare a small patch to print some logs to understand why the t_calc_branch() fails, it ok with you to give it a try ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10.10.2014 05:08, chow wrote: > Hi Bogdan: > the param of tm : > loadmodule "tm.so" > modparam("tm", "fr_timer", 5) > modparam("tm", "fr_inv_timer", 30) > modparam("tm", "restart_fr_on_each_reply", 0) > modparam("tm", "onreply_avp_mode", 1) > > the sipp call rate is 3000 caps. > the opensips version is 1.10.1 > the opensips memory config : S_MEMORY=4096, P_MEMORY=128 > > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/branch-computation-failed-tp7593895p7593931.html > Sent from the OpenSIPS - Users mailing list archive at Nabble.com. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miha at softnet.si Tue Oct 14 08:20:56 2014 From: miha at softnet.si (Miha) Date: Tue, 14 Oct 2014 08:20:56 +0200 Subject: [OpenSIPS-Users] enum waiting Message-ID: <543CC0C8.1010408@softnet.si> Hi, last time radius server was not sending back requests, so opensips was waiting and waiting and voip was not working. Today our enum server broke and opensips was agin waiting and waiting for responses and our voip did not work for the time that enum server was down. Is it possible to define some time for how long opensips should wait so that all other call will work and not that the whole system drops? tnx miha From satish.txt at gmail.com Tue Oct 14 17:02:15 2014 From: satish.txt at gmail.com (Satish Patel) Date: Tue, 14 Oct 2014 11:02:15 -0400 Subject: [OpenSIPS-Users] CDRTool prepaid for big installation In-Reply-To: References: <9CA4630F-2CFC-46F7-81A7-2E99F6997D1A@ag-projects.com> Message-ID: I am reading this document to implement Quota http://cdrtool.ag-projects.com/projects/cdrtool/repository/entry/doc/QuotaSystem.txt In number 3. Configure OpenSIPS to deny sessions initiated by subscribers belonging to the quota group. what that means? How do i configure opensips to deny session, is it part of callcontrol config? also it is saying belongs to the quota group, what is quota group? this is what i have in my subscriber table. Even after quota exceed it is not blocking call. +-----+----------+-------------------+----------+-----------------------+----------------------------------+----------------------------------+------+-------+ | id | username | domain | password | email_address | ha1 | ha1b | rpid | quota | +-----+----------+-------------------+----------+-----------------------+----------------------------------+----------------------------------+------+-------+ | 1 | 3003 | sip.example.com | 3003 | | 6fc4d74adfdedf25c72134154d3a9e1a | 3251dd8a5ef5a35d79a358bccb2c8179 | NULL | 1 | On Sun, Oct 12, 2014 at 7:30 PM, Adrian Georgescu wrote: > Quota works very simple. It is a mere cronjob that compares the total > amount of costs made in the current calendar month with the maximum > allowed. If the costs are higher than the quota, then the SIP account is > blocked. This will not cut the calls in progress but it works well > statistically speaking for postpaid customers. The documentation explains > the modus operandi in more detail. > > Adrian > > On 12 Oct 2014, at 11:14, Satish Patel wrote: > > Thanks!! I think you got my point, we have very high density call ratio > that is why prepaid not going to be a solution, I think postpaid or quota > would be right one. > > I have following question: > > Postpaid: > > Default it treat all calls as postpaid but in case i want to give number > of mins or time to my single customer then how do i achieve that Example: > 5000 mins or say $500 deposit in customer account then how i can do that > with postpaid? > > > Quota: I never explore this feature so i just want to know how quota > system work with CDRTool? could you give me short explanation? Most of our > customer would be call center or high density call customer, how i can use > quota in that scenario? > > On Sun, Oct 12, 2014 at 9:38 AM, Adrian Georgescu > wrote: > >> >> On 12 Oct 2014, at 09:48, Satish Patel wrote: >> >> I have run sipp test and it only able to handle 30 calls and later all >> call failed, >> >> >> Can you explain what exactly failed? >> >> I heard from other user post, CDRTool prepaid can't handle many >> simultaneous running calls. >> >> >> You heard wrong. It cannot handle high density call attempts like calls >> generated from call centers or transit peers like SIP trunks that push lot >> of calls. The number of simultaneous calls is irrelevant. You can have >> thousands of simultaneous calls with almost no performance penalty if the >> traffic is generated by regular SIP user devices. >> >> In our case single account will make many simultaneous calls and we need >> to handle them via prepaid.. >> >> >> It all depends on the meaning of many. Whenever a new call is attempted, >> the maximum remaining time of all ongoing calls of the same user must be >> recalculated so that the balance cannot be exceeded for any of them. This >> means that the more calls for the same user you have, the longer it takes >> to calculated everything over and over again. >> >> If you have many users with a few calls each like in a residential >> scenario where a user makes one or perhaps two parallel calls, this would >> have little impact as there is little to re-calculate. >> >> Some one suggested don't use prepaid because of limitation and >> performance, and suggested use Postpaid or Quota system.. is that true? >> >> >> It all depends on the traffic patterns. Concurrent or simultaneous calls >> is one thing, high density calls/per second attempts is another. There is >> no hard limitation but the number of database queries, distance to MySQL >> database will affect how many calls you can handle because as I explained >> before all concurrent calls must be rerated in real time again for each new >> call attempt. If one SIP account generates 10K parallel calls the load is >> infinite while if you have 10K users with one call each the load is almost >> zero. >> >> This is why a prepaid model is not practical for high density of calls >> and this has little to do with CDRTool, any other system would face the >> same problem, the load is compounded when adding more calls for same >> account. A quota based system is more appropriate for entities that >> generate large amount of calls as nothing has to be calculated on a per >> call basis. >> >> Adrian >> >> On Thu, Oct 9, 2014 at 3:46 PM, wrote: >> >>> Yes, it is capable. >>> >>> On 08 Oct 2014, at 15:42, Satish Patel wrote: >>> >>> > Hi, >>> > >>> > Just want to know does CDRTool prepaid capable of handling couple >>> hundreds of concurrent calls? I heard it can handle only 2/3 concurrent >>> calls per account? what is the solution if we want to host big prepaid >>> system with thousands of users? >>> > _______________________________________________ >>> > Users mailing list >>> > Users at lists.opensips.org >>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> -- >> Adrian >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -- > Adrian > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aihuawu2012 at 163.com Tue Oct 14 17:22:08 2014 From: aihuawu2012 at 163.com (george wu) Date: Tue, 14 Oct 2014 23:22:08 +0800 (CST) Subject: [OpenSIPS-Users] do i need nathelper if my client keeps pinging all the time? Message-ID: <14fbd3cf.26418.1490f408ab3.Coremail.aihuawu2012@163.com> do i need nathelper if my client keeps pinging all the time? What's the use of those two method? I think we should always use 5060 or 5061, otherwise how can you reach the client behind nat? natping_socket (string) force_socket (string) Thanks. George Wu -------------- next part -------------- An HTML attachment was scrubbed... URL: From aihuawu2012 at 163.com Tue Oct 14 17:37:00 2014 From: aihuawu2012 at 163.com (george wu) Date: Tue, 14 Oct 2014 23:37:00 +0800 (CST) Subject: [OpenSIPS-Users] udp or tcp for nat traversal? Message-ID: <9f50cdb.2658d.1490f4e26ee.Coremail.aihuawu2012@163.com> My experience is for two uac (linphone) behind a firewall, tcp/tls will always work. udp will never work. for both tcp/udp, my uac will send keep alive every 10 seconds. I don't understand what makes those difference. Can any one share your experience? George Wu -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Oct 14 17:50:47 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 14 Oct 2014 18:50:47 +0300 Subject: [OpenSIPS-Users] YNT: Re: YNT: Re: YNT: Re: RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE In-Reply-To: <1413230483.7897.YahooMailNeo@web121502.mail.ne1.yahoo.com> References: <543BE104.6000507@opensips.org> <1413218726.55580.YahooMailNeo@web121503.mail.ne1.yahoo.com> <543C0643.8020906@opensips.org> <1413230483.7897.YahooMailNeo@web121502.mail.ne1.yahoo.com> Message-ID: <543D4657.70405@opensips.org> Hi Kaan, When you do parallel forking (sending same request to two destinations), only one negative reply (from the two branches) is sent back to caller (to .11 in your case). You get the 401 reply on both .3 and .5 branches and OpenSIPS picks one to be sent to caller .11 (in SIP only one SIP negative reply per request is allowed). So, from SIP perspective it works ok, but my impression is you want something else. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 13.10.2014 23:01, Kaan Dandin wrote: > Hi Bogdan, > > Thanks for the response. I have edited the script as you have > mentioned but I have the same problem: > 401 message going to .3 is not passed by .141(opensips lb) > > else if (is_method("REGISTER")) { > xlog("xlog_initialregister"); > if($si=="192.168.2.11") { > $du = "sip:192.168.2.3:4060"; > append_branch(); > $du = "sip:192.168.2.5:4060"; > t_relay(); > exit; > } > if (!t_relay()) { > xlog("xlog_route1error"); > sl_reply_error(); > }; > > > No. Time Source Destination Protocol Info > 57 13.772015 192.168.2.11 192.168.2.141 SIP > Request: REGISTER sip:open-ims.test > 58 13.774094 192.168.2.141 192.168.2.5 SIP > Request: REGISTER sip:open-ims.test > 59 13.774097 192.168.2.141 192.168.2.3 SIP > Request: REGISTER sip:open-ims.test > 60 13.890456 192.168.2.3 192.168.2.141 SIP > Status: 401 Unauthorized - Challenging the UE (0 bindings) > 61 14.046746 192.168.2.5 192.168.2.141 SIP > Status: 401 Unauthorized - Challenging the UE (0 bindings) > 62 14.047052 192.168.2.141 192.168.2.11 SIP > Status: 401 Unauthorized - Challenging the UE (0 bindings) > 63 14.047538 192.168.2.11 192.168.2.141 SIP > Request: REGISTER sip:open-ims.test > 64 14.047887 192.168.2.141 192.168.2.5 SIP > Request: REGISTER sip:open-ims.test > 65 14.047947 192.168.2.141 192.168.2.3 SIP > Request: REGISTER sip:open-ims.test > 66 14.084120 192.168.2.3 192.168.2.141 SIP > Status: 401 Unauthorized - Challenging the UE (0 bindings) > 67 14.112597 192.168.2.5 192.168.2.141 SIP > Status: 200 OK - SAR succesful and registrar saved (1 bindings) > 68 14.112755 192.168.2.141 192.168.2.11 SIP > Status: 200 OK - SAR succesful and registrar saved (1 bindings) > > > > Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: xlog > method: [REGISTER] totag: [] sipid: [192.168.2.11] messageid: > [1] callid: [1-3096 at 192.168.2.11] callsequence: [2] > Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: > DBG:uri:has_totag: no totag > Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: > xlog_initialregister > Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: > DBG:core:comp_scriptvar: str 20 : 192.168.2.11 > Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: > DBG:tm:t_newtran: transaction on entrance=0xffffffffffffffff > Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: > DBG:core:parse_headers: flags=ffffffffffffffff > Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: > DBG:core:get_hdr_field: content_length=0 > Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: > DBG:core:get_hdr_field: found end of header > Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: > DBG:core:parse_headers: flags=78 > Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: > DBG:tm:t_lookup_request: start searching: hash=23653, isACK=0 > Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: > DBG:tm:matching_3261: RFC3261 transaction matching failed > Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: > DBG:tm:t_lookup_request: no transaction found > Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: > DBG:tm:run_reqin_callbacks: trans=0x7fc6d2b0d9e8, callback type 1, id > 1 entered > Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: > DBG:tm:run_reqin_callbacks: trans=0x7fc6d2b0d9e8, callback type 1, id > 0 entered > Oct 13 12:42:21 ubuntu /usr/local/opensips/sbin/opensips[4626]: > DBG:core:_shm_resize: resize(0) called > > > Kind regardsi > Kaan > ------------------------------------------------------------------------ > *From:* Bogdan-Andrei Iancu > *To:* Kaan Dandin ; OpenSIPS users mailling list > > *Cc:* Gunes Kurt ; "Ibrahim Hokelek, (B?LGEM-UEKAE)" > > *Sent:* Monday, October 13, 2014 8:05 PM > *Subject:* Re: YNT: Re: YNT: Re: YNT: Re: [OpenSIPS-Users] RFC3261 > transaction matching failed error for the second 401 Unauthorized - > Challenging the UE > > Hi Kaan, > > That is completely wrong as you break the transaction logic. The > correct way of doing parallel forking is : > > if($si=="192.168.2.11") { > $du = "sip:192.168.2.3:4060"; > append_branch(); # add first destination with the above value > $du = "sip:192.168.2.5:4060"; > t_relay(); > } > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Oct 14 18:18:32 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 14 Oct 2014 19:18:32 +0300 Subject: [OpenSIPS-Users] do i need nathelper if my client keeps pinging all the time? In-Reply-To: <14fbd3cf.26418.1490f408ab3.Coremail.aihuawu2012@163.com> References: <14fbd3cf.26418.1490f408ab3.Coremail.aihuawu2012@163.com> Message-ID: <543D4CD8.9020606@opensips.org> Hi George, nathelper module is used for multiple purposes like: 1) nat pinging 2) manging SIP signaling. If you are sure your clients are doing the pinging and you do not any signaling manging (fixing contacts, etc), you can stop using the nathelper module. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 14.10.2014 18:22, george wu wrote: > do i need nathelper if my client keeps pinging all the time? > > What's the use of those two method? I think we should always use > 5060 or 5061, otherwise how can you reach the client behind nat? > > > |natping_socket| (string) > > > |force_socket| (string) > > > Thanks. > > George Wu > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Oct 14 18:22:46 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 14 Oct 2014 19:22:46 +0300 Subject: [OpenSIPS-Users] udp or tcp for nat traversal? In-Reply-To: <9f50cdb.2658d.1490f4e26ee.Coremail.aihuawu2012@163.com> References: <9f50cdb.2658d.1490f4e26ee.Coremail.aihuawu2012@163.com> Message-ID: <543D4DD6.1020405@opensips.org> Hi George, NAT traversal is not only about pinging, but also about mangling/correcting the SIP traffic (from private IPs perspective) and ensuring the RTP flow. So you need to be sure that all 3 points are addressed. TCP versus UDP - there is only a difference at IP transport level...like datagram versus connection, and their implications at NAT level (being able to reach the device behind the nat). Otherwise it;s the same. For UDP, can you see what fails ? the registration? reaching the UAC ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 14.10.2014 18:37, george wu wrote: > My experience is for two uac (linphone) behind a firewall, > tcp/tls will always work. > udp will never work. > > for both tcp/udp, my uac will send keep alive every 10 seconds. > I don't understand what makes those difference. > Can any one share your experience? > > George Wu > > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Oct 14 18:28:23 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 14 Oct 2014 19:28:23 +0300 Subject: [OpenSIPS-Users] enum waiting In-Reply-To: <543CC0C8.1010408@softnet.si> References: <543CC0C8.1010408@softnet.si> Message-ID: <543D4F27.5040303@opensips.org> Hi Miha, Indeed, these blocking I/O's are painful and the 2.x release will start addressing this problem. The 2.1 code is already making first steps in solving it. For radius, OpenSIPS cannot control (via the libradiusclient lib) the timeout on how long to wait for the responses. For enum/dns, see dns_retr_time and dns_retr_no : http://www.opensips.org/Documentation/Script-CoreParameters-1-11#toc44 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 14.10.2014 09:20, Miha wrote: > Hi, > > last time radius server was not sending back requests, so opensips was > waiting and waiting and voip was not working. > > Today our enum server broke and opensips was agin waiting and waiting > for responses and our voip did not work for the time that enum server > was down. > > Is it possible to define some time for how long opensips should wait > so that all other call will work and not that the whole system drops? > > tnx > miha > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > From bogdan at opensips.org Tue Oct 14 18:38:49 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 14 Oct 2014 19:38:49 +0300 Subject: [OpenSIPS-Users] branch computation failed In-Reply-To: <201410140951152215038@gmail.com> References: <1412825847529-7593895.post@n2.nabble.com>, <5436691D.4010006@opensips.org>, <1412906905090-7593931.post@n2.nabble.com>, <543B7EEE.9000505@opensips.org>, <201410131535093743451@gmail.com>, <543B82E2.7010003@opensips.org> <201410140951152215038@gmail.com> Message-ID: <543D5199.4000204@opensips.org> Hi, Please apply the updated patch (remove the existing one first): https://gist.github.com/bogdan-iancu/851b092a1f457a19a463 Hopefully this new one will point out the source of the problem. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 14.10.2014 04:51, zhouxiaoqiang.mstech at gmail.com wrote: > Hi: > I execute that patch . > the sipp beging run at Oct 13 19:07:01 > The following is a log fragment. > > Oct 13 19:07:01 localhost /usr/sbin/opensips[24352]: > ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe > Oct 13 19:27:01 localhost /usr/sbin/opensips[24352]: > ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe > Oct 13 19:29:01 localhost /usr/sbin/opensips[24352]: > ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe > Oct 13 19:37:01 localhost /usr/sbin/opensips[24352]: > ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe > Oct 13 19:55:01 localhost /usr/sbin/opensips[24352]: > ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe > Oct 13 20:06:01 localhost /usr/sbin/opensips[24352]: > ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe > Oct 13 20:25:01 localhost /usr/sbin/opensips[24352]: > ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe > Oct 13 20:30:01 localhost /usr/sbin/opensips[24352]: > ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe > Oct 13 20:49:01 localhost /usr/sbin/opensips[24352]: > ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe > Oct 13 20:50:01 localhost /usr/sbin/opensips[24352]: > ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe > Oct 13 20:57:02 localhost /usr/sbin/opensips[24352]: > ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe > Oct 13 21:14:12 localhost /usr/sbin/opensips[24437]: > ERROR:core:branch_builder: writing the label failed, remaining size is 0 > Oct 13 21:14:12 localhost /usr/sbin/opensips[24437]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 13 21:14:12 localhost /usr/sbin/opensips[24437]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 13 21:14:19 localhost /usr/sbin/opensips[24463]: > ERROR:core:branch_builder: writing the label failed, remaining size is 0 > Oct 13 21:14:19 localhost /usr/sbin/opensips[24463]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 13 21:14:19 localhost /usr/sbin/opensips[24463]: > ERROR:tm:t_forward_nonack: failure to add branches > ... > ... > ... > ... > Oct 13 23:32:52 localhost /usr/sbin/opensips[24475]: > ERROR:core:branch_builder: writing the label failed, remaining size is 0 > Oct 13 23:32:52 localhost /usr/sbin/opensips[24475]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 13 23:32:52 localhost /usr/sbin/opensips[24475]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 13 23:32:52 localhost /usr/sbin/opensips[24434]: > ERROR:core:branch_builder: writing the label failed, remaining size is 0 > Oct 13 23:32:52 localhost /usr/sbin/opensips[24434]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 13 23:32:52 localhost /usr/sbin/opensips[24434]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 13 23:32:54 localhost /usr/sbin/opensips[24442]: > ERROR:core:branch_builder: writing the label failed, remaining size is 0 > Oct 13 23:32:54 localhost /usr/sbin/opensips[24442]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 13 23:32:54 localhost /usr/sbin/opensips[24442]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 13 23:32:54 localhost /usr/sbin/opensips[24397]: > ERROR:core:branch_builder: writing the label failed, remaining size is 0 > Oct 13 23:32:54 localhost /usr/sbin/opensips[24397]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 13 23:32:54 localhost /usr/sbin/opensips[24397]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 13 23:32:55 localhost /usr/sbin/opensips[24447]: > ERROR:core:branch_builder: writing the label failed, remaining size is 0 > Oct 13 23:32:55 localhost /usr/sbin/opensips[24447]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 13 23:32:55 localhost /usr/sbin/opensips[24447]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 13 23:32:55 localhost /usr/sbin/opensips[24459]: > ERROR:core:branch_builder: writing the label failed, remaining size is 0 > Oct 13 23:32:55 localhost /usr/sbin/opensips[24459]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 13 23:32:55 localhost /usr/sbin/opensips[24459]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 13 23:32:57 localhost /usr/sbin/opensips[24458]: > ERROR:core:branch_builder: writing the label failed, remaining size is 0 > Oct 13 23:32:57 localhost /usr/sbin/opensips[24458]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 13 23:32:57 localhost /usr/sbin/opensips[24458]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 13 23:32:58 localhost /usr/sbin/opensips[24485]: > CRITICAL:core:utimer_ticker: utimer handler lasted (180000 > us) for more than timer tick (100000 us) -> potential timer shifting > Oct 13 23:32:59 localhost /usr/sbin/opensips[24359]: > ERROR:core:branch_builder: writing the label failed, remaining size is 0 > Oct 13 23:32:59 localhost /usr/sbin/opensips[24359]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 13 23:32:59 localhost /usr/sbin/opensips[24359]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 13 23:32:59 localhost /usr/sbin/opensips[24452]: > ERROR:core:branch_builder: writing the label failed, remaining size is 0 > Oct 13 23:32:59 localhost /usr/sbin/opensips[24452]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 13 23:32:59 localhost /usr/sbin/opensips[24452]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 13 23:33:00 localhost /usr/sbin/opensips[24471]: > ERROR:core:branch_builder: writing the label failed, remaining size is 0 > Oct 13 23:33:00 localhost /usr/sbin/opensips[24471]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 13 23:33:00 localhost /usr/sbin/opensips[24471]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 13 23:33:00 localhost /usr/sbin/opensips[24367]: > ERROR:core:branch_builder: writing the label failed, remaining size is 0 > Oct 13 23:33:00 localhost /usr/sbin/opensips[24367]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 13 23:33:00 localhost /usr/sbin/opensips[24367]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 13 23:33:02 localhost /usr/sbin/opensips[24364]: > ERROR:core:branch_builder: writing the label failed, remaining size is 0 > Oct 13 23:33:02 localhost /usr/sbin/opensips[24364]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 13 23:33:02 localhost /usr/sbin/opensips[24364]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 13 23:33:02 localhost /usr/sbin/opensips[24413]: > ERROR:core:branch_builder: writing the label failed, remaining size is 0 > > > > ------------------------------------------------------------------------ > zhouxiaoqiang.mstech at gmail.com > > *From:* Bogdan-Andrei Iancu > *Date:* 2014-10-13 15:44 > *To:* zhouxiaoqiang.mstech at gmail.com > ; users at lists.opensips.org > > *Subject:* Re: [OpenSIPS-Users] branch computation failed > Please apply this patch: > https://gist.github.com/bogdan-iancu/851b092a1f457a19a463 > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 13.10.2014 10:35, zhouxiaoqiang.mstech at gmail.com wrote: >> Hi Bogdan: >> I am glad to do that. >> please, give me your patch. >> >> ------------------------------------------------------------------------ >> zhouxiaoqiang.mstech at gmail.com >> >> *From:* Bogdan-Andrei Iancu >> *Date:* 2014-10-13 15:27 >> *To:* OpenSIPS users mailling list >> ; zhouxiaoqiang.mstech >> >> *Subject:* Re: [OpenSIPS-Users] branch computation failed >> Hi, >> That is really strange - If I prepare a small patch to print >> some logs >> to understand why the t_calc_branch() fails, it ok with you >> to give it a >> try ? >> Regards, >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> On 10.10.2014 05:08, chow wrote: >> > Hi Bogdan: >> > the param of tm : >> > loadmodule "tm.so" >> > modparam("tm", "fr_timer", 5) >> > modparam("tm", "fr_inv_timer", 30) >> > modparam("tm", "restart_fr_on_each_reply", 0) >> > modparam("tm", "onreply_avp_mode", 1) >> > >> > the sipp call rate is 3000 caps. >> > the opensips version is 1.10.1 >> > the opensips memory config : S_MEMORY=4096, P_MEMORY=128 >> > >> > >> > >> > >> > -- >> > View this message in context: >> http://opensips-open-sip-server.1449251.n2.nabble.com/branch-computation-failed-tp7593895p7593931.html >> > Sent from the OpenSIPS - Users mailing list archive at >> Nabble.com. >> > >> > _______________________________________________ >> > Users mailing list >> > Users at lists.opensips.org >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Oct 14 18:53:56 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 14 Oct 2014 19:53:56 +0300 Subject: [OpenSIPS-Users] OpenSIPS 2.1.0dev Message-ID: <543D5524.5030008@opensips.org> Hi all, The development branch moved from 1.12 to 2.1 - we are heavily working on importing into OpenSIPS improvements related to the New Design from the OpenSIPS Experimental Code. As a result, we have a first development version which is consistent as stable (as much as a devel code can be :D ) - we have OpenSIPS 2.1.0 . This tag covers: - I/O async reactor per process (for each SIP worker) - integrate the reactor with the UDP and TCP reading - timer jobs dispatched/balanced across the SIP worker procs (instead of be all executed in dedicated procs) Next steps (2.1.1dev) : - per process I/O async ops (an async I/O op starting and ending in the same process) - running I/O async ops at script level To 2.1.0 is just a milestone on the path of the next major stable release - 2.1.0 is a tag on the devel branch, pointing to consistent and working/stable development code - it is NOT a stable release. To directly use 2.1.0, see the 2.1.0 tag : git clone https://github.com/OpenSIPS/opensips.git -b 2.1.0 Please give it a try and report back ;) Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com From ag at ag-projects.com Tue Oct 14 19:17:46 2014 From: ag at ag-projects.com (Adrian Georgescu) Date: Tue, 14 Oct 2014 15:17:46 -0200 Subject: [OpenSIPS-Users] CDRTool prepaid for big installation In-Reply-To: References: <9CA4630F-2CFC-46F7-81A7-2E99F6997D1A@ag-projects.com> Message-ID: <5595A009-56A6-447E-9FAB-6DD8D4459AC5@ag-projects.com> On 14 Oct 2014, at 13:02, Satish Patel wrote: > I am reading this document to implement Quota http://cdrtool.ag-projects.com/projects/cdrtool/repository/entry/doc/QuotaSystem.txt > > In number 3. Configure OpenSIPS to deny sessions initiated by subscribers belonging to the quota group. > > what that means? How do i configure opensips to deny session, is it part of callcontrol config? Check if the user belongs to that group and if yes don't let the call go through. It has nothing to do with call control, is just a database query. Adrian > > also it is saying belongs to the quota group, what is quota group? this is what i have in my subscriber table. Even after quota exceed it is not blocking call. > > +-----+----------+-------------------+----------+-----------------------+----------------------------------+----------------------------------+------+-------+ > | id | username | domain | password | email_address | ha1 | ha1b | rpid | quota | > +-----+----------+-------------------+----------+-----------------------+----------------------------------+----------------------------------+------+-------+ > | 1 | 3003 | sip.example.com | 3003 | | 6fc4d74adfdedf25c72134154d3a9e1a | 3251dd8a5ef5a35d79a358bccb2c8179 | NULL | 1 | > > > > > > > On Sun, Oct 12, 2014 at 7:30 PM, Adrian Georgescu wrote: > Quota works very simple. It is a mere cronjob that compares the total amount of costs made in the current calendar month with the maximum allowed. If the costs are higher than the quota, then the SIP account is blocked. This will not cut the calls in progress but it works well statistically speaking for postpaid customers. The documentation explains the modus operandi in more detail. > > Adrian > > On 12 Oct 2014, at 11:14, Satish Patel wrote: > >> Thanks!! I think you got my point, we have very high density call ratio that is why prepaid not going to be a solution, I think postpaid or quota would be right one. >> >> I have following question: >> >> Postpaid: >> >> Default it treat all calls as postpaid but in case i want to give number of mins or time to my single customer then how do i achieve that Example: 5000 mins or say $500 deposit in customer account then how i can do that with postpaid? >> >> >> Quota: I never explore this feature so i just want to know how quota system work with CDRTool? could you give me short explanation? Most of our customer would be call center or high density call customer, how i can use quota in that scenario? >> >> On Sun, Oct 12, 2014 at 9:38 AM, Adrian Georgescu wrote: >> >> On 12 Oct 2014, at 09:48, Satish Patel wrote: >> >>> I have run sipp test and it only able to handle 30 calls and later all call failed, >> >> Can you explain what exactly failed? >> >>> I heard from other user post, CDRTool prepaid can't handle many simultaneous running calls. >> >> You heard wrong. It cannot handle high density call attempts like calls generated from call centers or transit peers like SIP trunks that push lot of calls. The number of simultaneous calls is irrelevant. You can have thousands of simultaneous calls with almost no performance penalty if the traffic is generated by regular SIP user devices. >> >>> In our case single account will make many simultaneous calls and we need to handle them via prepaid.. >> >> It all depends on the meaning of many. Whenever a new call is attempted, the maximum remaining time of all ongoing calls of the same user must be recalculated so that the balance cannot be exceeded for any of them. This means that the more calls for the same user you have, the longer it takes to calculated everything over and over again. >> >> If you have many users with a few calls each like in a residential scenario where a user makes one or perhaps two parallel calls, this would have little impact as there is little to re-calculate. >> >>> Some one suggested don't use prepaid because of limitation and performance, and suggested use Postpaid or Quota system.. is that true? >> >> It all depends on the traffic patterns. Concurrent or simultaneous calls is one thing, high density calls/per second attempts is another. There is no hard limitation but the number of database queries, distance to MySQL database will affect how many calls you can handle because as I explained before all concurrent calls must be rerated in real time again for each new call attempt. If one SIP account generates 10K parallel calls the load is infinite while if you have 10K users with one call each the load is almost zero. >> >> This is why a prepaid model is not practical for high density of calls and this has little to do with CDRTool, any other system would face the same problem, the load is compounded when adding more calls for same account. A quota based system is more appropriate for entities that generate large amount of calls as nothing has to be calculated on a per call basis. >> >> Adrian >> >>> On Thu, Oct 9, 2014 at 3:46 PM, wrote: >>> Yes, it is capable. >>> >>> On 08 Oct 2014, at 15:42, Satish Patel wrote: >>> >>> > Hi, >>> > >>> > Just want to know does CDRTool prepaid capable of handling couple hundreds of concurrent calls? I heard it can handle only 2/3 concurrent calls per account? what is the solution if we want to host big prepaid system with thousands of users? >>> > _______________________________________________ >>> > Users mailing list >>> > Users at lists.opensips.org >>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> -- >> Adrian >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- > Adrian > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Adrian -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From satish.txt at gmail.com Wed Oct 15 00:22:58 2014 From: satish.txt at gmail.com (Satish Patel) Date: Tue, 14 Oct 2014 18:22:58 -0400 Subject: [OpenSIPS-Users] CDRTool prepaid for big installation In-Reply-To: <5595A009-56A6-447E-9FAB-6DD8D4459AC5@ag-projects.com> References: <9CA4630F-2CFC-46F7-81A7-2E99F6997D1A@ag-projects.com> <5595A009-56A6-447E-9FAB-6DD8D4459AC5@ag-projects.com> Message-ID: <816BB641-D862-458B-A96C-35FB55463EFD@gmail.com> Great! I figured out, it was group module. -- Sent from my iPhone > On Oct 14, 2014, at 1:17 PM, Adrian Georgescu wrote: > > >> On 14 Oct 2014, at 13:02, Satish Patel wrote: >> >> I am reading this document to implement Quota http://cdrtool.ag-projects.com/projects/cdrtool/repository/entry/doc/QuotaSystem.txt >> >> In number 3. Configure OpenSIPS to deny sessions initiated by subscribers belonging to the quota group. >> >> what that means? How do i configure opensips to deny session, is it part of callcontrol config? > > > Check if the user belongs to that group and if yes don't let the call go through. It has nothing to do with call control, is just a database query. > > Adrian > > > >> >> also it is saying belongs to the quota group, what is quota group? this is what i have in my subscriber table. Even after quota exceed it is not blocking call. >> >> +-----+----------+-------------------+----------+-----------------------+----------------------------------+----------------------------------+------+-------+ >> | id | username | domain | password | email_address | ha1 | ha1b | rpid | quota | >> +-----+----------+-------------------+----------+-----------------------+----------------------------------+----------------------------------+------+-------+ >> | 1 | 3003 | sip.example.com | 3003 | | 6fc4d74adfdedf25c72134154d3a9e1a | 3251dd8a5ef5a35d79a358bccb2c8179 | NULL | 1 | >> >> >> >> >> >> >>> On Sun, Oct 12, 2014 at 7:30 PM, Adrian Georgescu wrote: >>> Quota works very simple. It is a mere cronjob that compares the total amount of costs made in the current calendar month with the maximum allowed. If the costs are higher than the quota, then the SIP account is blocked. This will not cut the calls in progress but it works well statistically speaking for postpaid customers. The documentation explains the modus operandi in more detail. >>> >>> Adrian >>> >>>> On 12 Oct 2014, at 11:14, Satish Patel wrote: >>>> >>>> Thanks!! I think you got my point, we have very high density call ratio that is why prepaid not going to be a solution, I think postpaid or quota would be right one. >>>> >>>> I have following question: >>>> >>>> Postpaid: >>>> >>>> Default it treat all calls as postpaid but in case i want to give number of mins or time to my single customer then how do i achieve that Example: 5000 mins or say $500 deposit in customer account then how i can do that with postpaid? >>>> >>>> >>>> Quota: I never explore this feature so i just want to know how quota system work with CDRTool? could you give me short explanation? Most of our customer would be call center or high density call customer, how i can use quota in that scenario? >>>> >>>>> On Sun, Oct 12, 2014 at 9:38 AM, Adrian Georgescu wrote: >>>>> >>>>>> On 12 Oct 2014, at 09:48, Satish Patel wrote: >>>>>> >>>>>> I have run sipp test and it only able to handle 30 calls and later all call failed, >>>>> >>>>> Can you explain what exactly failed? >>>>> >>>>>> I heard from other user post, CDRTool prepaid can't handle many simultaneous running calls. >>>>> >>>>> You heard wrong. It cannot handle high density call attempts like calls generated from call centers or transit peers like SIP trunks that push lot of calls. The number of simultaneous calls is irrelevant. You can have thousands of simultaneous calls with almost no performance penalty if the traffic is generated by regular SIP user devices. >>>>> >>>>>> In our case single account will make many simultaneous calls and we need to handle them via prepaid.. >>>>> >>>>> It all depends on the meaning of many. Whenever a new call is attempted, the maximum remaining time of all ongoing calls of the same user must be recalculated so that the balance cannot be exceeded for any of them. This means that the more calls for the same user you have, the longer it takes to calculated everything over and over again. >>>>> >>>>> If you have many users with a few calls each like in a residential scenario where a user makes one or perhaps two parallel calls, this would have little impact as there is little to re-calculate. >>>>> >>>>>> Some one suggested don't use prepaid because of limitation and performance, and suggested use Postpaid or Quota system.. is that true? >>>>> >>>>> It all depends on the traffic patterns. Concurrent or simultaneous calls is one thing, high density calls/per second attempts is another. There is no hard limitation but the number of database queries, distance to MySQL database will affect how many calls you can handle because as I explained before all concurrent calls must be rerated in real time again for each new call attempt. If one SIP account generates 10K parallel calls the load is infinite while if you have 10K users with one call each the load is almost zero. >>>>> >>>>> This is why a prepaid model is not practical for high density of calls and this has little to do with CDRTool, any other system would face the same problem, the load is compounded when adding more calls for same account. A quota based system is more appropriate for entities that generate large amount of calls as nothing has to be calculated on a per call basis. >>>>> >>>>> Adrian >>>>> >>>>>>> On Thu, Oct 9, 2014 at 3:46 PM, wrote: >>>>>>> Yes, it is capable. >>>>>>> >>>>>>> On 08 Oct 2014, at 15:42, Satish Patel wrote: >>>>>>> >>>>>>> > Hi, >>>>>>> > >>>>>>> > Just want to know does CDRTool prepaid capable of handling couple hundreds of concurrent calls? I heard it can handle only 2/3 concurrent calls per account? what is the solution if we want to host big prepaid system with thousands of users? >>>>>>> > _______________________________________________ >>>>>>> > Users mailing list >>>>>>> > Users at lists.opensips.org >>>>>>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Users mailing list >>>>>>> Users at lists.opensips.org >>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users at lists.opensips.org >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> -- >>>>> Adrian >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> -- >>> Adrian >>> >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- > Adrian > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaandandin at yahoo.com Wed Oct 15 06:27:20 2014 From: kaandandin at yahoo.com (Kaan Dandin) Date: Tue, 14 Oct 2014 21:27:20 -0700 Subject: [OpenSIPS-Users] YNT: Re: YNT: Re: YNT: Re: RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE In-Reply-To: <543D4657.70405@opensips.org> References: <543BE104.6000507@opensips.org> <1413218726.55580.YahooMailNeo@web121503.mail.ne1.yahoo.com> <543C0643.8020906@opensips.org> <1413230483.7897.YahooMailNeo@web121502.mail.ne1.yahoo.com> <543D4657.70405@opensips.org> Message-ID: <1413347240.77902.YahooMailNeo@web121502.mail.ne1.yahoo.com> Hi Bogdan, Thanks a lot for your response. My aim is to register to both IMS nodes(.3 and .5) in the same time ,then able to make load balancing to any of them. With your support ,now I better understand how t_relay and paralel forking is working. I have managed the problem by sending to different IMS registration scenario (.3 and .5) from IMS bench (.11) instead of parallel forking in OpenSIPS. Now the registrations are successuly completed. But I have another problem in the IMS call scenario. ACK messages are always going to .5 IMS node in t_relay instead of the related node. In the logs it seems that related transaction not found and address is found with DNS lookup and always sent to .5 node. For that reason only half of the calls are successful. Below I am sharing related part of the script , call flow and trace. Kind regards, Kaan } else { if ( is_method("ACK") ) { xlog("xlog_ack_method"); if ( t_check_trans() ) { # non loose-route, but stateful ACK; must be an ACK after # a 487 or e.g. 404 from upstream server xlog("xlog_nonlooseroutestatefulack"); t_relay(); exit; } else { # ACK without matching transaction -> # ignore and discard t_relay(); xlog("xlog_nonlooseroutenonstatefulack"); exit; } } No. Time Source Destination Protocol Info 4647 79.393261 192.168.2.11 192.168.2.141 SIP/SDP Request: INVITE sip:subs000174 at open-ims.test, with session description 4648 79.395108 192.168.2.141 192.168.2.11 SIP Status: 100 Giving a try 4649 79.395467 192.168.2.141 192.168.2.3 SIP/SDP Request: INVITE sip:subs000174 at open-ims.test, with session description 4650 79.426101 192.168.2.3 192.168.2.141 SIP Status: 100 trying -- your call is important to us 4651 79.464427 192.168.2.3 192.168.2.141 SIP/SDP Request: INVITE sip:subs000174 at 192.168.2.11:7174, with session description 4652 79.465264 192.168.2.141 192.168.2.3 SIP Status: 100 Giving a try 4654 79.465773 192.168.2.141 192.168.2.11 SIP/SDP Request: INVITE sip:subs000174 at 192.168.2.11:7174, with session description 4655 79.465773 192.168.2.11 192.168.2.141 SIP Status: 180 Ringing 4656 79.466172 192.168.2.141 192.168.2.3 SIP Status: 180 Ringing 4657 79.507893 192.168.2.3 192.168.2.141 SIP Status: 180 Ringing 4658 79.508153 192.168.2.141 192.168.2.11 SIP Status: 180 Ringing 5053 84.372654 192.168.2.11 192.168.2.141 SIP/SDP Status: 200 OK, with session description 5054 84.372931 192.168.2.141 192.168.2.3 SIP/SDP Status: 200 OK, with session description 5055 84.396628 192.168.2.3 192.168.2.141 SIP/SDP Status: 200 OK, with session description 5056 84.397036 192.168.2.141 192.168.2.11 SIP/SDP Status: 200 OK, with session description 5057 84.397552 192.168.2.11 192.168.2.141 SIP Request: ACK sip:subs000174 at 192.168.2.11:7174;transport=UDP 5058 84.398921 192.168.2.141 192.168.2.5 SIP Request: ACK sip:subs000174 at 192.168.2.11:7174;transport=UDP 5075 84.874990 192.168.2.11 192.168.2.141 SIP/SDP Status: 200 OK, with session description 5076 84.875713 192.168.2.141 192.168.2.3 SIP/SDP Status: 200 OK, with session description 5077 84.925133 192.168.2.3 192.168.2.141 SIP/SDP Status: 200 OK, with session description 5078 84.925434 192.168.2.141 192.168.2.11 SIP/SDP Status: 200 OK, with session description 5079 84.925622 192.168.2.11 192.168.2.141 SIP Request: ACK sip:subs000174 at 192.168.2.11:7174;transport=UDP 5080 84.926591 192.168.2.141 192.168.2.5 SIP Request: ACK sip:subs000174 at 192.168.2.11:7174;transport=UDP Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: xlog method: [ACK] totag: [69bab173779e29f3a0c2aaef4e939266-4eaf] sipid: [192.168.2.5] messageid: [898] callid: [54-3946 at 192.168.2.11] callsequence: [1] Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: DBG:uri:has_totag: totag found Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: xlog_has_totag Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: DBG:core:parse_headers: flags=200 Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: DBG:core:get_hdr_field: content_length=0 Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: DBG:core:get_hdr_field: found end of header Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: DBG:rr:find_first_route: No Route headers found Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: DBG:rr:loose_route: There is no Route HF Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: xlog_ack_method Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: DBG:core:parse_headers: flags=78 Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: DBG:tm:t_lookup_request: start searching: hash=36408, isACK=1 Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: DBG:tm:t_lookup_request: proceeding to pre-RFC3261 transaction matching Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: DBG:tm:t_lookup_request: no transaction found Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: DBG:tm:t_newtran: transaction on entrance=(nil) Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: DBG:core:parse_headers: flags=ffffffffffffffff Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: DBG:tm:t_relay_to: forwarding ACK Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: DBG:core:mk_proxy: doing DNS lookup... Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: DBG:core:parse_headers: flags=ffffffffffffffff Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: DBG:core:check_ip_address: params 192.168.2.5, 192.168.2.5, 0 Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: DBG:core:forward_request: sending:#012ACK sip:subs000423 at 192.168.2.11:7423 SIP/2.0#015#012Max-Forwards: 10#015#012Via: SIP/2.0/UDP 192.168.2.141:4060;branch=z9hG4bK83e8.fcacb1c3.0#015#012Via: SIP/2.0/UDP 192.168.2.5:4060;branch=0#015#012Via: SIP/2.0/UDP 192.168.2.5:6060;rport=6060;branch=z9hG4bK83e8.fcacb1c3.0#015#012From: "subs004934" ;tag=3946SIPpTag0054#015#012Call-ID: 54-3946 at 192.168.2.11#015#012To: "subs000423" ;tag=69bab173779e29f3a0c2aaef4e939266-4eaf#015#012CSeq: 1 ACK#015#012User-Agent: Sip EXpress router(2.1.0-dev1 OpenIMSCore (i386/linux))#015#012Content-Length: 0#015#012#015#012. Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: DBG:core:forward_request: orig. len=480, new_len=547, proto=1 Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: xlog_nonlooseroutenonstatefulack Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: DBG:core:destroy_avp_list: destroying list (nil) Oct 14 11:45:03 ubuntu /usr/local/opensips/sbin/opensips[6068]: DBG:core:receive_msg: cleaning up 4 INVITE ----------> B1,2,4 21 0 0 5 100 <---------- 21 0 0 6 180 <---------- 21 0 0 7 183 <---------- 0 0 0 8 200 <---------- 21 33 0 9 ACK ----------> 21 33 10 180 <---------- 0 0 0 11 Pause [Exp(2:00)] 21 0 12 BYE ----------> B3 21 99 11 13 180 <---------- 0 0 0 14 200 <---------- E3,4 10 0 110 15 [ RECVRMT ] 10 0 1- ims_uac-0- Statistics Screen - [1-9]: Change Screen - 4485 Start Time | 2014-10-14 14:59:55 Last Reset Time | 2014-10-14 15:01:50 Current Time | 2014-10-14 15:01:51 -------------------------+---------------------------+-------------------------- Counter Name | Periodic value | Cumulative value -------------------------+---------------------------+-------------------------- Elapsed Time | 00:00:00:349 | 00:01:55:109 Call Rate | 0.000 cps | 0.182 cps -------------------------+---------------------------+-------------------------- Incoming call created | 0 | 0 OutGoing call created | 0 | 21 Total Call created | | 21 Current Call | 0 | -------------------------+---------------------------+-------------------------- Successful call | 0 | 10 Failed call | 1 | 11 -------------------------+---------------------------+-------------------------- From: Bogdan-Andrei Iancu To: Kaan Dandin ; OpenSIPS users mailling list Cc: Gunes Kurt ; "Ibrahim Hokelek, (B?LGEM-UEKAE)" Sent: Tuesday, October 14, 2014 6:50 PM Subject: Re: YNT: Re: YNT: Re: YNT: Re: [OpenSIPS-Users] RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE Hi Kaan, When you do parallel forking (sending same request to two destinations), only one negative reply (from the two branches) is sent back to caller (to .11 in your case). You get the 401 reply on both .3 and .5 branches and OpenSIPS picks one to be sent to caller .11 (in SIP only one SIP negative reply per request is allowed). So, from SIP perspective it works ok, but my impression is you want something else. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From miha at softnet.si Wed Oct 15 07:06:55 2014 From: miha at softnet.si (Miha) Date: Wed, 15 Oct 2014 07:06:55 +0200 Subject: [OpenSIPS-Users] enum waiting In-Reply-To: <543D4F27.5040303@opensips.org> References: <543CC0C8.1010408@softnet.si> <543D4F27.5040303@opensips.org> Message-ID: <543E00EF.7030801@softnet.si> Hi Bogdan, tnx for this info. Will try with this dns_retr_time and dns_retr_no. And yes, this is very painful as whole voip system is not working not just in this exp portable numbers ;) Br Miha On 14/10/2014 18:28, Bogdan-Andrei Iancu wrote: > Hi Miha, > > Indeed, these blocking I/O's are painful and the 2.x release will > start addressing this problem. The 2.1 code is already making first > steps in solving it. > > For radius, OpenSIPS cannot control (via the libradiusclient lib) the > timeout on how long to wait for the responses. > For enum/dns, see dns_retr_time and dns_retr_no : > http://www.opensips.org/Documentation/Script-CoreParameters-1-11#toc44 > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 14.10.2014 09:20, Miha wrote: >> Hi, >> >> last time radius server was not sending back requests, so opensips >> was waiting and waiting and voip was not working. >> >> Today our enum server broke and opensips was agin waiting and waiting >> for responses and our voip did not work for the time that enum server >> was down. >> >> Is it possible to define some time for how long opensips should wait >> so that all other call will work and not that the whole system drops? >> >> tnx >> miha >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > > From bogdan at opensips.org Wed Oct 15 09:13:00 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 15 Oct 2014 10:13:00 +0300 Subject: [OpenSIPS-Users] udp or tcp for nat traversal? In-Reply-To: <4dd40a9b.e54.14911311a6a.Coremail.aihuawu2012@163.com> References: <9f50cdb.2658d.1490f4e26ee.Coremail.aihuawu2012@163.com> <543D4DD6.1020405@opensips.org> <4dd40a9b.e54.14911311a6a.Coremail.aihuawu2012@163.com> Message-ID: <543E1E7C.4070407@opensips.org> Hi George, If your OpenSIPS fails to reach the UAC is because of two reasons: - NAT pinhole is closed - but if pinging is done, it shouldn't be - opensips is trying to contact UAC via wrong IP:port - can you confirm that when calling the UAC, OpenSIPS sends the INVITE to same IP and port as where the pingings are coming from ? TCP works as this part is "automatically" resolved because of the connection (where the other pipe is known). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 15.10.2014 03:24, george wu wrote: > > Hi, Bogdan-Andrei: > > For udp, it fails when reaching the UAC even though the UAC keeps > pinging the server all the time. > > For tcp, although it works. I find something interesting. > Only when the client pings the server, the invite message is sent to > the UAC. > In my understanding, the server should be able to send message to the > UAC since the > tcp connection is open. Actually the sip server is unable to send > message to the UAC. > > About the firewall type, I use opensipsctl ul show/rm to check. > I find every time when it register, i get the same ip/portmost of time. > But occasionally it might get different ip/port. > I believe it is nat within a cone. > > I am using ice, the ice only work after the first invite message is > delivered to the peer. > My ice with mediaproxy works perfectly. > > > George Wu > > At 2014-10-15 00:22:46, "Bogdan-Andrei Iancu" wrote: > > Hi George, > > NAT traversal is not only about pinging, but also about > mangling/correcting the SIP traffic (from private IPs perspective) > and ensuring the RTP flow. > > So you need to be sure that all 3 points are addressed. > > TCP versus UDP - there is only a difference at IP transport > level...like datagram versus connection, and their implications at > NAT level (being able to reach the device behind the nat). > Otherwise it;s the same. > > For UDP, can you see what fails ? the registration? reaching the > UAC ? > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 14.10.2014 18:37, george wu wrote: >> My experience is for two uac (linphone) behind a firewall, >> tcp/tls will always work. >> udp will never work. >> >> for both tcp/udp, my uac will send keep alive every 10 seconds. >> I don't understand what makes those difference. >> Can any one share your experience? >> >> George Wu >> >> >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Oct 15 09:18:03 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 15 Oct 2014 10:18:03 +0300 Subject: [OpenSIPS-Users] do i need nathelper if my client keeps pinging all the time? In-Reply-To: <2054773c.12e5.149113f8fc1.Coremail.aihuawu2012@163.com> References: <14fbd3cf.26418.1490f408ab3.Coremail.aihuawu2012@163.com> <543D4CD8.9020606@opensips.org> <2054773c.12e5.149113f8fc1.Coremail.aihuawu2012@163.com> Message-ID: <543E1FAB.7060603@opensips.org> Hi George, It looks like you use the add_rcv_param() function when processing the REGISTER. That is not the correct way of fixing the private registrations, but rather via the fix_nated_register() function : http://www.opensips.org/html/docs/modules/1.11.x/nathelper.html#id294034 Use that function for the REGISTER requests (if coming from behind NAT) and before doing the save(location) Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 15.10.2014 03:40, george wu wrote: > Hi, Bogdan-Andrei: > > I find my linphone client register twice. It seems it has fix contact > functionality. the second time it fix contact. > am I right? > > REGISTER sip:103.24.228.158 SIP/2.0 > Via: SIP/2.0/UDP 192.168.1.3:5070;branch=z9hG4bK.oYu5jsYLh;rport > From: ;tag=WD1Okb6W1 > To: sip:test1 at 103.24.228.158 > CSeq: 20 REGISTER > Call-ID: hLSmV9bsjn > Max-Forwards: 70 > Supported: replaces, outbound > Contact: > ;+sip.instance="" > Expires: 3600 > User-Agent: linphone/3.7.0 (belle-sip/1.3.0) > > SIP/2.0 200 OK > Via: SIP/2.0/UDP > 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.oYu5jsYLh;rport=5111 > From: ;tag=WD1Okb6W1 > To: sip:test1 at 103.24.228.158;tag=1d417984ac5e6d68a4c07a2aeb0726ad.8908 > CSeq: 20 REGISTER > Call-ID: hLSmV9bsjn > Contact: > ;expires=3600;received="sip:124.193.138.210:5111" > Server: OpenSIPS (1.11.2-tls (x86_64/linux)) > Content-Length: 0 > > REGISTER sip:103.24.228.158 SIP/2.0 > Via: SIP/2.0/UDP 192.168.1.3:5070;branch=z9hG4bK.Ie8svp-NN;rport > From: ;tag=WD1Okb6W1 > To: sip:test1 at 103.24.228.158 > CSeq: 21 REGISTER > Call-ID: hLSmV9bsjn > Max-Forwards: 70 > Supported: replaces, outbound > Contact: > ;+sip.instance="" > Expires: 3600 > User-Agent: linphone/3.7.0 (belle-sip/1.3.0) > > SIP/2.0 200 OK > Via: SIP/2.0/UDP > 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.Ie8svp-NN;rport=5111 > From: ;tag=WD1Okb6W1 > To: sip:test1 at 103.24.228.158;tag=1d417984ac5e6d68a4c07a2aeb0726ad.6b48 > CSeq: 21 REGISTER > Call-ID: hLSmV9bsjn > Contact: > ;expires=3600;received="sip:124.193.138.210:5111", > ;expires=3600;received="sip:124.193.138.210:5111" > Server: OpenSIPS (1.11.2-tls (x86_64/linux)) > Content-Length: 0 > > > > > > > > At 2014-10-15 00:18:32, "Bogdan-Andrei Iancu" wrote: > > Hi George, > > nathelper module is used for multiple purposes like: > 1) nat pinging > 2) manging SIP signaling. > > If you are sure your clients are doing the pinging and you do not > any signaling manging (fixing contacts, etc), you can stop using > the nathelper module. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 14.10.2014 18:22, george wu wrote: >> do i need nathelper if my client keeps pinging all the time? >> >> What's the use of those two method? I think we should always use >> 5060 or 5061, otherwise how can you reach the client behind nat? >> >> >> |natping_socket| (string) >> >> >> |force_socket| (string) >> >> >> Thanks. >> >> George Wu >> >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Oct 15 09:22:38 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 15 Oct 2014 10:22:38 +0300 Subject: [OpenSIPS-Users] YNT: Re: YNT: Re: YNT: Re: RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE In-Reply-To: <1413347240.77902.YahooMailNeo@web121502.mail.ne1.yahoo.com> References: <543BE104.6000507@opensips.org> <1413218726.55580.YahooMailNeo@web121503.mail.ne1.yahoo.com> <543C0643.8020906@opensips.org> <1413230483.7897.YahooMailNeo@web121502.mail.ne1.yahoo.com> <543D4657.70405@opensips.org> <1413347240.77902.YahooMailNeo@web121502.mail.ne1.yahoo.com> Message-ID: <543E20BE.5090307@opensips.org> Hi Kaan, I'm glad the first part is properly working now. Your ACK (as it is for a 200 OK) should be routed based on Route headers (record route and loose route mechanism). TO better understand this, please take a look to this webinar: http://www.opensips.org/Documentation/Webinars#toc12 ( chapter 5.5 ) At INVITE time you should do record_route() and the ACK should carry the Route headers in order to follow the same path as the INVITE. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 15.10.2014 07:27, Kaan Dandin wrote: > Hi Bogdan, > Thanks a lot for your response. My aim is to register to both IMS > nodes(.3 and .5) in the same time ,then able to make load balancing to > any of them. > With your support ,now I better understand how t_relay and paralel > forking is working. > I have managed the problem by sending to different IMS registration > scenario (.3 and .5) from IMS bench (.11) instead of parallel forking > in OpenSIPS. > Now the registrations are successuly completed. > But I have another problem in the IMS call scenario. > ACK messages are always going to .5 IMS node in t_relay instead of the > related node. In the logs it seems that related transaction not found > and address is found with DNS lookup and always sent to .5 node. > For that reason only half of the calls are successful. > Below I am sharing related part of the script , call flow and trace. > Kind regards, > Kaan > } else { > if ( is_method("ACK") ) { > xlog("xlog_ack_method"); > if ( t_check_trans() ) { > > # non loose-route, but stateful ACK; > must be an ACK after > # a 487 or e.g. 404 from > upstream server > xlog("xlog_nonlooseroutestatefulack"); > t_relay(); > exit; > } else { > # ACK without matching > transaction -> > # ignore and discard > t_relay(); > xlog("xlog_nonlooseroutenonstatefulack"); > exit; > } > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilddragon at sina.com Wed Oct 15 13:14:02 2014 From: wilddragon at sina.com (wilddragon at sina.com) Date: Wed, 15 Oct 2014 19:14:02 +0800 Subject: [OpenSIPS-Users] About "Not enough free memory, no more shm memory and out of mem Message-ID: <201410151913533727064@sina.com> Hi, My friends, When I do a stress testing for opensips(version: 1.11.2TLS) , I received the following errors. How to tuning it to solve these problem. anyone can help me, thanks. opensips[1362]: ERROR:dialog:dialog_update_db: could not add another dialog to db opensips[1358]: WARNING:core:fm_malloc: Not enough free memory, will attempt defragmentation opensips[1358]: ERROR:usrloc:new_ucontact: no more shm memory opensips[1358]: ERROR:usrloc:mem_insert_ucontact: failed to create new contact opensips[1358]: ERROR:usrloc:insert_ucontact: failed to insert contact opensips[1358]: ERROR:registrar:insert_contacts: failed to insert contact opensips[1359]: WARNING:core:fm_malloc: Not enough free memory, will attempt defragmentation opensips[1359]: ERROR:tm:new_t: out of mem opensips[1359]: ERROR:tm:t_newtran: new_t failed opensips[1360]: WARNING:core:fm_malloc: Not enough free memory, will attempt defragmentation opensips[1360]: ERROR:tm:new_t: out of mem opensips[1360]: ERROR:tm:t_newtran: new_t failed opensips[1359]: WARNING:core:fm_malloc: Not enough free memory, will attempt defragmentation opensips[1359]: ERROR:usrloc:new_ucontact: no more shm memory opensips[1359]: ERROR:usrloc:mem_insert_ucontact: failed to create new contact opensips[1359]: ERROR:usrloc:insert_ucontact: failed to insert contact opensips[1359]: ERROR:registrar:insert_contacts: failed to insert contact opensips[1362]: CRITICAL:db_mysql:wrapper_single_mysql_stmt_execute: driver error (1048): Column 'callee_contact' cannot be null wilddragon at sina.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From aihuawu2012 at 163.com Wed Oct 15 14:06:04 2014 From: aihuawu2012 at 163.com (george wu) Date: Wed, 15 Oct 2014 20:06:04 +0800 (CST) Subject: [OpenSIPS-Users] udp or tcp for nat traversal? In-Reply-To: <543E1E7C.4070407@opensips.org> References: <9f50cdb.2658d.1490f4e26ee.Coremail.aihuawu2012@163.com> <543D4DD6.1020405@opensips.org> <4dd40a9b.e54.14911311a6a.Coremail.aihuawu2012@163.com> <543E1E7C.4070407@opensips.org> Message-ID: <46185c1e.103bc.14913b36612.Coremail.aihuawu2012@163.com> Hi, Bogdan: I think I have found the problem. I am using mediaproxy. If I kill that proxy. suddenly the uac can get the message. So it is quite obvious that my mediaproxy setting is not correct. Just I don't know how to fix it. I modify it from my old rtpproxy setting. George ///////////////////// #### NAT modules loadmodule "nathelper.so" modparam("nathelper", "natping_interval", 10) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "received_avp", "$avp(received_nh)") #loadmodule "rtpproxy.so" #modparam("rtpproxy", "rtpproxy_sock", "udp:localhost:12221") # CUSTOMIZE ME loadmodule "mediaproxy.so" modparam("mediaproxy", "mediaproxy_socket", "/var/run/mediaproxy/dispatcher.sock") modparam("mediaproxy", "ice_candidate", "low-priority") ####### Routing Logic ######## # main request routing logic route{ force_rport(); if (nat_uac_test("23")) { if (is_method("REGISTER")) { fix_nated_register(); setbflag(NAT); } else { fix_nated_contact(); setflag(NAT); } } if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { if (is_method("BYE")) { setflag(ACC_DO); # do accounting ... setflag(ACC_FAILED); # ... even if the transaction fails } else if (is_method("INVITE")) { # even if in most of the cases is useless, do RR for # re-INVITEs alos, as some buggy clients do change route set # during the dialog. record_route(); } if (check_route_param("nat=yes")) setflag(NAT); # route it out to whatever destination was set by loose_route() # in $du (destination URI). route(relay); } else { if ( is_method("ACK") ) { if ( t_check_trans() ) { # non loose-route, but stateful ACK; must be an ACK after # a 487 or e.g. 404 from upstream server t_relay(); exit; } else { # ACK without matching transaction -> # ignore and discard exit; } } sl_send_reply("404","Not here"); } exit; } # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) t_relay(); exit; } t_check_trans(); if ( !(is_method("REGISTER") ) ) { if (from_uri==myself) { } else { # if caller is not local, then called number must be local if (!uri==myself) { send_reply("403","Rely forbidden"); exit; } } } # preloaded route checking if (loose_route()) { xlog("L_ERR", "Attempt to route with preloaded Route's [$fu/$tu/$ru/$ci]"); if (!is_method("ACK")) sl_send_reply("403","Preload Route denied"); exit; } # record routing if (!is_method("REGISTER|MESSAGE")) record_route(); # account only INVITEs if (is_method("INVITE")) { setflag(ACC_DO); # do accounting } if (!uri==myself) { append_hf("P-hint: outbound\r\n"); # if you have some interdomain connections via TLS ## CUSTOMIZE IF NEEDED ##if ($rd=="tls_domain1.net" ## || $rd=="tls_domain2.net" ##) { ## force_send_socket(tls:127.0.0.1:5061); # CUSTOMIZE ##} route(relay); } # requests for my domain if (is_method("PUBLISH|SUBSCRIBE")) { sl_send_reply("503", "Service Unavailable"); exit; } if (is_method("REGISTER")) { if ( proto==TCP || proto==TLS || 0 ) setflag(TCP_PERSISTENT); if (!save("location")) sl_reply_error(); exit; } if ($rU==NULL) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; } # do lookup with method filtering if (!lookup("location","m")) { t_newtran(); t_reply("404", "Not Found"); exit; } if (isbflagset(NAT)) setflag(NAT); # when routing via usrloc, log the missed calls also setflag(ACC_MISSED); route(relay); } route[relay] { # for INVITEs enable some additional helper routes if (is_method("INVITE")) { if (isflagset(NAT)) { # rtpproxy_offer("ro"); use_media_proxy(); } t_on_branch("per_branch_ops"); t_on_reply("handle_nat"); t_on_failure("missed_call"); } if (is_method("BYE")) { if (isflagset(NAT)) { end_media_session(); } } if (isflagset(NAT)) { add_rr_param(";nat=yes"); } if (!t_relay()) { send_reply("500","Internal Error"); }; exit; } branch_route[per_branch_ops] { xlog("new branch at $ru\n"); } onreply_route[handle_nat] { if (nat_uac_test("1")) fix_nated_contact(); # if ( isflagset(NAT) ) # rtpproxy_answer("ro"); if (is_method("INVITE")) { if (isflagset(NAT)) { use_media_proxy(); } } if (is_method("BYE")) { if (isflagset(NAT)) { end_media_session(); } } xlog("incoming reply\n"); } failure_route[missed_call] { if (t_was_cancelled()) { exit; } # uncomment the following lines if you want to block client # redirect based on 3xx replies. ##if (t_check_status("3[0-9][0-9]")) { ##t_reply("404","Not found"); ## exit; ##} } ? 2014-10-15 15:13:00?"Bogdan-Andrei Iancu" ??? Hi George, If your OpenSIPS fails to reach the UAC is because of two reasons: - NAT pinhole is closed - but if pinging is done, it shouldn't be - opensips is trying to contact UAC via wrong IP:port - can you confirm that when calling the UAC, OpenSIPS sends the INVITE to same IP and port as where the pingings are coming from ? TCP works as this part is "automatically" resolved because of the connection (where the other pipe is known). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 15.10.2014 03:24, george wu wrote: Hi, Bogdan-Andrei: For udp, it fails when reaching the UAC even though the UAC keeps pinging the server all the time. For tcp, although it works. I find something interesting. Only when the client pings the server, the invite message is sent to the UAC. In my understanding, the server should be able to send message to the UAC since the tcp connection is open. Actually the sip server is unable to send message to the UAC. About the firewall type, I use opensipsctl ul show/rm to check. I find every time when it register, i get the same ip/port most of time. But occasionally it might get different ip/port. I believe it is nat within a cone. I am using ice, the ice only work after the first invite message is delivered to the peer. My ice with mediaproxy works perfectly. George Wu At 2014-10-15 00:22:46, "Bogdan-Andrei Iancu" wrote: Hi George, NAT traversal is not only about pinging, but also about mangling/correcting the SIP traffic (from private IPs perspective) and ensuring the RTP flow. So you need to be sure that all 3 points are addressed. TCP versus UDP - there is only a difference at IP transport level...like datagram versus connection, and their implications at NAT level (being able to reach the device behind the nat). Otherwise it;s the same. For UDP, can you see what fails ? the registration? reaching the UAC ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 14.10.2014 18:37, george wu wrote: My experience is for two uac (linphone) behind a firewall, tcp/tls will always work. udp will never work. for both tcp/udp, my uac will send keep alive every 10 seconds. I don't understand what makes those difference. Can any one share your experience? George Wu _______________________________________________ Users mailing list Users at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilddragon at sina.com Wed Oct 15 14:25:56 2014 From: wilddragon at sina.com (wilddragon at sina.com) Date: Wed, 15 Oct 2014 20:25:56 +0800 Subject: [OpenSIPS-Users] About "Not enough free memory, no more shm memory and out of mem" Error Message-ID: <201410152025501249796@sina.com> Hi, My friends, When I do a stress testing for opensips(version: 1.11.2TLS) , I received the following errors. How to tuning it to solve these problem. anyone can help me, thanks. opensips[1362]: ERROR:dialog:dialog_update_db: could not add another dialog to db opensips[1358]: WARNING:core:fm_malloc: Not enough free memory, will attempt defragmentation opensips[1358]: ERROR:usrloc:new_ucontact: no more shm memory opensips[1358]: ERROR:usrloc:mem_insert_ucontact: failed to create new contact opensips[1358]: ERROR:usrloc:insert_ucontact: failed to insert contact opensips[1358]: ERROR:registrar:insert_contacts: failed to insert contact opensips[1359]: WARNING:core:fm_malloc: Not enough free memory, will attempt defragmentation opensips[1359]: ERROR:tm:new_t: out of mem opensips[1359]: ERROR:tm:t_newtran: new_t failed opensips[1360]: WARNING:core:fm_malloc: Not enough free memory, will attempt defragmentation opensips[1360]: ERROR:tm:new_t: out of mem opensips[1360]: ERROR:tm:t_newtran: new_t failed opensips[1359]: WARNING:core:fm_malloc: Not enough free memory, will attempt defragmentation opensips[1359]: ERROR:usrloc:new_ucontact: no more shm memory opensips[1359]: ERROR:usrloc:mem_insert_ucontact: failed to create new contact opensips[1359]: ERROR:usrloc:insert_ucontact: failed to insert contact opensips[1359]: ERROR:registrar:insert_contacts: failed to insert contact opensips[1362]: CRITICAL:db_mysql:wrapper_single_mysql_stmt_execute: driver error (1048): Column 'callee_contact' cannot be null wilddragon at sina.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From miha at softnet.si Wed Oct 15 14:27:45 2014 From: miha at softnet.si (Miha) Date: Wed, 15 Oct 2014 14:27:45 +0200 Subject: [OpenSIPS-Users] About "Not enough free memory, no more shm memory and out of mem" Error In-Reply-To: <201410152025501249796@sina.com> References: <201410152025501249796@sina.com> Message-ID: <543E6841.3070602@softnet.si> how do you start opensips, how much private mem and shared mam do you asigne? brM On 15/10/2014 14:25, wilddragon at sina.com wrote: > Hi, My friends, > When I do a stress testing for opensips(version: 1.11.2TLS) , I > received the following errors. How to tuning it to solve these problem. > anyone can help me, thanks. > > opensips[1362]: ERROR:dialog:dialog_update_db: could not add another > dialog to db > opensips[1358]: WARNING:core:fm_malloc: Not enough free memory, will > attempt defragmentation > opensips[1358]: ERROR:usrloc:new_ucontact: no more shm memory > opensips[1358]: ERROR:usrloc:mem_insert_ucontact: failed to create new > contact > opensips[1358]: ERROR:usrloc:insert_ucontact: failed to insert contact > opensips[1358]: ERROR:registrar:insert_contacts: failed to insert contact > opensips[1359]: WARNING:core:fm_malloc: Not enough free memory, will > attempt defragmentation > opensips[1359]: ERROR:tm:new_t: out of mem > opensips[1359]: ERROR:tm:t_newtran: new_t failed > opensips[1360]: WARNING:core:fm_malloc: Not enough free memory, will > attempt defragmentation > opensips[1360]: ERROR:tm:new_t: out of mem > opensips[1360]: ERROR:tm:t_newtran: new_t failed > opensips[1359]: WARNING:core:fm_malloc: Not enough free memory, will > attempt defragmentation > opensips[1359]: ERROR:usrloc:new_ucontact: no more shm memory > opensips[1359]: ERROR:usrloc:mem_insert_ucontact: failed to create new > contact > opensips[1359]: ERROR:usrloc:insert_ucontact: failed to insert contact > opensips[1359]: ERROR:registrar:insert_contacts: failed to insert contact > opensips[1362]: CRITICAL:db_mysql:wrapper_single_mysql_stmt_execute: > driver error (1048): Column 'callee_contact' cannot be null > > ------------------------------------------------------------------------ > wilddragon at sina.com > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Oct 15 14:46:02 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 15 Oct 2014 15:46:02 +0300 Subject: [OpenSIPS-Users] udp or tcp for nat traversal? In-Reply-To: <46185c1e.103bc.14913b36612.Coremail.aihuawu2012@163.com> References: <9f50cdb.2658d.1490f4e26ee.Coremail.aihuawu2012@163.com> <543D4DD6.1020405@opensips.org> <4dd40a9b.e54.14911311a6a.Coremail.aihuawu2012@163.com> <543E1E7C.4070407@opensips.org> <46185c1e.103bc.14913b36612.Coremail.aihuawu2012@163.com> Message-ID: <543E6C8A.6000802@opensips.org> Hi George, Not sure if a media relay process has anything to do with the ability to send traffic to an UAC - do you actually see with ngrep/tcpdump the request (on the network level) sent by opensips to the UAC ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 15.10.2014 15:06, george wu wrote: > Hi, Bogdan: > > I think I have found the problem. > I am using mediaproxy. If I kill that proxy. > suddenly the uac can get the message. > So it is quite obvious that my mediaproxy setting is not correct. > Just I don't know how to fix it. I modify it from my old rtpproxy setting. > > > George > > ///////////////////// > > > #### NAT modules > loadmodule "nathelper.so" > modparam("nathelper", "natping_interval", 10) > modparam("nathelper", "ping_nated_only", 1) > modparam("nathelper", "received_avp", "$avp(received_nh)") > > #loadmodule "rtpproxy.so" > #modparam("rtpproxy", "rtpproxy_sock", "udp:localhost:12221") # > CUSTOMIZE ME > > loadmodule "mediaproxy.so" > modparam("mediaproxy", "mediaproxy_socket", > "/var/run/mediaproxy/dispatcher.sock") > modparam("mediaproxy", "ice_candidate", "low-priority") > > > > > ####### Routing Logic ######## > > # main request routing logic > > route{ > force_rport(); > if (nat_uac_test("23")) { > if (is_method("REGISTER")) { > fix_nated_register(); > setbflag(NAT); > } else { > fix_nated_contact(); > setflag(NAT); > } > } > > > if (!mf_process_maxfwd_header("10")) { > sl_send_reply("483","Too Many Hops"); > exit; > } > > if (has_totag()) { > # sequential request withing a dialog should > # take the path determined by record-routing > if (loose_route()) { > > if (is_method("BYE")) { > setflag(ACC_DO); # do accounting ... > setflag(ACC_FAILED); # ... even if the transaction fails > } else if (is_method("INVITE")) { > # even if in most of the cases is useless, do RR for > # re-INVITEs alos, as some buggy clients do change > route set > # during the dialog. > record_route(); > } > > if (check_route_param("nat=yes")) > setflag(NAT); > > # route it out to whatever destination was set by > loose_route() > # in $du (destination URI). > route(relay); > } else { > > if ( is_method("ACK") ) { > if ( t_check_trans() ) { > # non loose-route, but stateful ACK; must be an > ACK after > # a 487 or e.g. 404 from upstream server > t_relay(); > exit; > } else { > # ACK without matching transaction -> > # ignore and discard > exit; > } > } > sl_send_reply("404","Not here"); > } > exit; > } > > # CANCEL processing > if (is_method("CANCEL")) > { > if (t_check_trans()) > t_relay(); > exit; > } > > t_check_trans(); > > if ( !(is_method("REGISTER") ) ) { > > if (from_uri==myself) > > { > > } else { > # if caller is not local, then called number must be local > > if (!uri==myself) { > send_reply("403","Rely forbidden"); > exit; > } > } > > } > > # preloaded route checking > if (loose_route()) { > xlog("L_ERR", > "Attempt to route with preloaded Route's [$fu/$tu/$ru/$ci]"); > if (!is_method("ACK")) > sl_send_reply("403","Preload Route denied"); > exit; > } > > # record routing > if (!is_method("REGISTER|MESSAGE")) > record_route(); > > # account only INVITEs > if (is_method("INVITE")) { > > setflag(ACC_DO); # do accounting > } > > > if (!uri==myself) { > append_hf("P-hint: outbound\r\n"); > > # if you have some interdomain connections via TLS > ## CUSTOMIZE IF NEEDED > ##if ($rd=="tls_domain1.net" > ## || $rd=="tls_domain2.net" > ##) { > ## force_send_socket(tls:127.0.0.1:5061); # CUSTOMIZE > ##} > > route(relay); > } > > # requests for my domain > > if (is_method("PUBLISH|SUBSCRIBE")) > { > sl_send_reply("503", "Service Unavailable"); > exit; > } > > if (is_method("REGISTER")) > { > > > if ( proto==TCP || proto==TLS || 0 ) setflag(TCP_PERSISTENT); > > if (!save("location")) > sl_reply_error(); > > exit; > } > > if ($rU==NULL) { > # request with no Username in RURI > sl_send_reply("484","Address Incomplete"); > exit; > } > > > > > > > > # do lookup with method filtering > if (!lookup("location","m")) { > > > t_newtran(); > t_reply("404", "Not Found"); > exit; > } > > if (isbflagset(NAT)) setflag(NAT); > > # when routing via usrloc, log the missed calls also > setflag(ACC_MISSED); > route(relay); > } > > > route[relay] { > # for INVITEs enable some additional helper routes > if (is_method("INVITE")) { > > if (isflagset(NAT)) { > # rtpproxy_offer("ro"); > use_media_proxy(); > > } > > t_on_branch("per_branch_ops"); > t_on_reply("handle_nat"); > t_on_failure("missed_call"); > } > if (is_method("BYE")) { > if (isflagset(NAT)) { > end_media_session(); > } > } > > > if (isflagset(NAT)) { > add_rr_param(";nat=yes"); > } > > if (!t_relay()) { > send_reply("500","Internal Error"); > }; > exit; > } > > > > > branch_route[per_branch_ops] { > xlog("new branch at $ru\n"); > } > > > onreply_route[handle_nat] { > if (nat_uac_test("1")) > fix_nated_contact(); > # if ( isflagset(NAT) ) > # rtpproxy_answer("ro"); > if (is_method("INVITE")) { > if (isflagset(NAT)) { > use_media_proxy(); > } > } > if (is_method("BYE")) { > if (isflagset(NAT)) { > end_media_session(); > } > } > > xlog("incoming reply\n"); > } > > > failure_route[missed_call] { > if (t_was_cancelled()) { > exit; > } > > # uncomment the following lines if you want to block client > # redirect based on 3xx replies. > ##if (t_check_status("3[0-9][0-9]")) { > ##t_reply("404","Not found"); > ## exit; > ##} > > > } > > > > > > ? 2014-10-15 15:13:00?"Bogdan-Andrei Iancu" ??? > > Hi George, > > If your OpenSIPS fails to reach the UAC is because of two reasons: > - NAT pinhole is closed - but if pinging is done, it shouldn't be > - opensips is trying to contact UAC via wrong IP:port - can > you confirm that when calling the UAC, OpenSIPS sends the INVITE > to same IP and port as where the pingings are coming from ? > > TCP works as this part is "automatically" resolved because of the > connection (where the other pipe is known). > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 15.10.2014 03:24, george wu wrote: >> >> Hi, Bogdan-Andrei: >> >> For udp, it fails when reaching the UAC even though the UAC keeps >> pinging the server all the time. >> >> For tcp, although it works. I find something interesting. >> Only when the client pings the server, the invite message is sent >> to the UAC. >> In my understanding, the server should be able to send message to >> the UAC since the >> tcp connection is open. Actually the sip server is unable to send >> message to the UAC. >> >> About the firewall type, I use opensipsctl ul show/rm to check. >> I find every time when it register, i get the same ip/portmost of >> time. >> But occasionally it might get different ip/port. >> I believe it is nat within a cone. >> >> I am using ice, the ice only work after the first invite message >> is delivered to the peer. >> My ice with mediaproxy works perfectly. >> >> >> George Wu >> >> At 2014-10-15 00:22:46, "Bogdan-Andrei Iancu" >> wrote: >> >> Hi George, >> >> NAT traversal is not only about pinging, but also about >> mangling/correcting the SIP traffic (from private IPs >> perspective) and ensuring the RTP flow. >> >> So you need to be sure that all 3 points are addressed. >> >> TCP versus UDP - there is only a difference at IP transport >> level...like datagram versus connection, and their >> implications at NAT level (being able to reach the device >> behind the nat). Otherwise it;s the same. >> >> For UDP, can you see what fails ? the registration? reaching >> the UAC ? >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> On 14.10.2014 18:37, george wu wrote: >>> My experience is for two uac (linphone) behind a firewall, >>> tcp/tls will always work. >>> udp will never work. >>> >>> for both tcp/udp, my uac will send keep alive every 10 seconds. >>> I don't understand what makes those difference. >>> Can any one share your experience? >>> >>> George Wu >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aihuawu2012 at 163.com Wed Oct 15 14:49:38 2014 From: aihuawu2012 at 163.com (george wu) Date: Wed, 15 Oct 2014 20:49:38 +0800 (CST) Subject: [OpenSIPS-Users] mediaproxy configuration Message-ID: <5b2b7372.10af9.14913db48e1.Coremail.aihuawu2012@163.com> Can anybody share your mediaproxy configuration? I am using mediaproxy to work with ice. I modify the script from rtpproxy. Finally it turns out it breaks some invite relay logic. The route logic configuration is very hard. The original rtpproxy is generated from menuconfig. Since there is no option in the menuconfig to generate mediaproxy, I am wondering anyone has a working mediaproxy to share? Thanks very much. George -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilddragon at sina.com Wed Oct 15 14:57:52 2014 From: wilddragon at sina.com (wilddragon at sina.com) Date: Wed, 15 Oct 2014 20:57:52 +0800 Subject: [OpenSIPS-Users] About "Not enough free memory, no more shm memory and out of mem" Error References: <201410152025501249796@sina.com>, <543E6841.3070602@softnet.si> Message-ID: <201410152057421715417@sina.com> I have not set any mem param in opensips.cfg and start opensip use "opensipsctl start" only. wilddragon at sina.com From: Miha Date: 2014-10-15 20:27 To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] About "Not enough free memory, no more shm memory and out of mem" Error how do you start opensips, how much private mem and shared mam do you asigne? brM On 15/10/2014 14:25, wilddragon at sina.com wrote: Hi, My friends, When I do a stress testing for opensips(version: 1.11.2TLS) , I received the following errors. How to tuning it to solve these problem. anyone can help me, thanks. opensips[1362]: ERROR:dialog:dialog_update_db: could not add another dialog to db opensips[1358]: WARNING:core:fm_malloc: Not enough free memory, will attempt defragmentation opensips[1358]: ERROR:usrloc:new_ucontact: no more shm memory opensips[1358]: ERROR:usrloc:mem_insert_ucontact: failed to create new contact opensips[1358]: ERROR:usrloc:insert_ucontact: failed to insert contact opensips[1358]: ERROR:registrar:insert_contacts: failed to insert contact opensips[1359]: WARNING:core:fm_malloc: Not enough free memory, will attempt defragmentation opensips[1359]: ERROR:tm:new_t: out of mem opensips[1359]: ERROR:tm:t_newtran: new_t failed opensips[1360]: WARNING:core:fm_malloc: Not enough free memory, will attempt defragmentation opensips[1360]: ERROR:tm:new_t: out of mem opensips[1360]: ERROR:tm:t_newtran: new_t failed opensips[1359]: WARNING:core:fm_malloc: Not enough free memory, will attempt defragmentation opensips[1359]: ERROR:usrloc:new_ucontact: no more shm memory opensips[1359]: ERROR:usrloc:mem_insert_ucontact: failed to create new contact opensips[1359]: ERROR:usrloc:insert_ucontact: failed to insert contact opensips[1359]: ERROR:registrar:insert_contacts: failed to insert contact opensips[1362]: CRITICAL:db_mysql:wrapper_single_mysql_stmt_execute: driver error (1048): Column 'callee_contact' cannot be null wilddragon at sina.com _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From aihuawu2012 at 163.com Wed Oct 15 14:58:33 2014 From: aihuawu2012 at 163.com (george wu) Date: Wed, 15 Oct 2014 20:58:33 +0800 (CST) Subject: [OpenSIPS-Users] udp or tcp for nat traversal? In-Reply-To: <543E6C8A.6000802@opensips.org> References: <9f50cdb.2658d.1490f4e26ee.Coremail.aihuawu2012@163.com> <543D4DD6.1020405@opensips.org> <4dd40a9b.e54.14911311a6a.Coremail.aihuawu2012@163.com> <543E1E7C.4070407@opensips.org> <46185c1e.103bc.14913b36612.Coremail.aihuawu2012@163.com> <543E6C8A.6000802@opensips.org> Message-ID: <77c199c9.10c8a.14913e37367.Coremail.aihuawu2012@163.com> Hi, Bogdan: I will try ngrep and tcpdump. But I am quite sure it is mediaproxy problem, since I can print out all the debug message by linphonec. If I enable mediaproxy, the linphone doesn't print any thing since it doesn't get message from opensips. Once I kill mediaproxy, the linphone gets and prints out all the communication which is correct. George Wu At 2014-10-15 20:46:02, "Bogdan-Andrei Iancu" wrote: Hi George, Not sure if a media relay process has anything to do with the ability to send traffic to an UAC - do you actually see with ngrep/tcpdump the request (on the network level) sent by opensips to the UAC ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 15.10.2014 15:06, george wu wrote: Hi, Bogdan: I think I have found the problem. I am using mediaproxy. If I kill that proxy. suddenly the uac can get the message. So it is quite obvious that my mediaproxy setting is not correct. Just I don't know how to fix it. I modify it from my old rtpproxy setting. George ///////////////////// #### NAT modules loadmodule "nathelper.so" modparam("nathelper", "natping_interval", 10) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "received_avp", "$avp(received_nh)") #loadmodule "rtpproxy.so" #modparam("rtpproxy", "rtpproxy_sock", "udp:localhost:12221") # CUSTOMIZE ME loadmodule "mediaproxy.so" modparam("mediaproxy", "mediaproxy_socket", "/var/run/mediaproxy/dispatcher.sock") modparam("mediaproxy", "ice_candidate", "low-priority") ####### Routing Logic ######## # main request routing logic route{ force_rport(); if (nat_uac_test("23")) { if (is_method("REGISTER")) { fix_nated_register(); setbflag(NAT); } else { fix_nated_contact(); setflag(NAT); } } if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { if (is_method("BYE")) { setflag(ACC_DO); # do accounting ... setflag(ACC_FAILED); # ... even if the transaction fails } else if (is_method("INVITE")) { # even if in most of the cases is useless, do RR for # re-INVITEs alos, as some buggy clients do change route set # during the dialog. record_route(); } if (check_route_param("nat=yes")) setflag(NAT); # route it out to whatever destination was set by loose_route() # in $du (destination URI). route(relay); } else { if ( is_method("ACK") ) { if ( t_check_trans() ) { # non loose-route, but stateful ACK; must be an ACK after # a 487 or e.g. 404 from upstream server t_relay(); exit; } else { # ACK without matching transaction -> # ignore and discard exit; } } sl_send_reply("404","Not here"); } exit; } # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) t_relay(); exit; } t_check_trans(); if ( !(is_method("REGISTER") ) ) { if (from_uri==myself) { } else { # if caller is not local, then called number must be local if (!uri==myself) { send_reply("403","Rely forbidden"); exit; } } } # preloaded route checking if (loose_route()) { xlog("L_ERR", "Attempt to route with preloaded Route's [$fu/$tu/$ru/$ci]"); if (!is_method("ACK")) sl_send_reply("403","Preload Route denied"); exit; } # record routing if (!is_method("REGISTER|MESSAGE")) record_route(); # account only INVITEs if (is_method("INVITE")) { setflag(ACC_DO); # do accounting } if (!uri==myself) { append_hf("P-hint: outbound\r\n"); # if you have some interdomain connections via TLS ## CUSTOMIZE IF NEEDED ##if ($rd=="tls_domain1.net" ## || $rd=="tls_domain2.net" ##) { ## force_send_socket(tls:127.0.0.1:5061); # CUSTOMIZE ##} route(relay); } # requests for my domain if (is_method("PUBLISH|SUBSCRIBE")) { sl_send_reply("503", "Service Unavailable"); exit; } if (is_method("REGISTER")) { if ( proto==TCP || proto==TLS || 0 ) setflag(TCP_PERSISTENT); if (!save("location")) sl_reply_error(); exit; } if ($rU==NULL) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; } # do lookup with method filtering if (!lookup("location","m")) { t_newtran(); t_reply("404", "Not Found"); exit; } if (isbflagset(NAT)) setflag(NAT); # when routing via usrloc, log the missed calls also setflag(ACC_MISSED); route(relay); } route[relay] { # for INVITEs enable some additional helper routes if (is_method("INVITE")) { if (isflagset(NAT)) { # rtpproxy_offer("ro"); use_media_proxy(); } t_on_branch("per_branch_ops"); t_on_reply("handle_nat"); t_on_failure("missed_call"); } if (is_method("BYE")) { if (isflagset(NAT)) { end_media_session(); } } if (isflagset(NAT)) { add_rr_param(";nat=yes"); } if (!t_relay()) { send_reply("500","Internal Error"); }; exit; } branch_route[per_branch_ops] { xlog("new branch at $ru\n"); } onreply_route[handle_nat] { if (nat_uac_test("1")) fix_nated_contact(); # if ( isflagset(NAT) ) # rtpproxy_answer("ro"); if (is_method("INVITE")) { if (isflagset(NAT)) { use_media_proxy(); } } if (is_method("BYE")) { if (isflagset(NAT)) { end_media_session(); } } xlog("incoming reply\n"); } failure_route[missed_call] { if (t_was_cancelled()) { exit; } # uncomment the following lines if you want to block client # redirect based on 3xx replies. ##if (t_check_status("3[0-9][0-9]")) { ##t_reply("404","Not found"); ## exit; ##} } -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Oct 15 14:44:55 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 15 Oct 2014 15:44:55 +0300 Subject: [OpenSIPS-Users] udp or tcp for nat traversal? In-Reply-To: <289d70c8.fe4b.149138e294d.Coremail.aihuawu2012@163.com> References: <9f50cdb.2658d.1490f4e26ee.Coremail.aihuawu2012@163.com> <543D4DD6.1020405@opensips.org> <4dd40a9b.e54.14911311a6a.Coremail.aihuawu2012@163.com> <543E1E7C.4070407@opensips.org> <289d70c8.fe4b.149138e294d.Coremail.aihuawu2012@163.com> Message-ID: <543E6C47.2050603@opensips.org> George, you can get all that info by using ngrep or tcpdump to see the actual traffic. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 15.10.2014 14:25, george wu wrote: > > Hi, Bogdan: > 1) > I can find the ip from the pinging message, but can't get the port. > Can you tell me the script to print port? > 2) > Also how to check the relay for invite in the log message? > I can't see the ip/port for the invite relay message in the log. > It simply Cancel sent out, sending 408 (0x7f9858507f28) > see below > > /////////////////////////////// > > Oct 15 19:04:51 [15160] DBG:core:udp_rcv_loop: probing packet received > len = 4 > Oct 15 19:04:54 [15165] DBG:nathelper:nh_timer: resolving next hop: > '124.193.138.210' > ...... > Oct 15 19:04:29 [15164] DBG:tm:timer_routine: timer > routine:0,tl=0x7f9858508178 next=0x7f9858508378, timeout=873 > Oct 15 19:04:29 [15164] DBG:tm:final_response_handler: Cancel sent > out, sending 408 (0x7f9858507f28) > > > /////The following is opensips invite log messages > > > > > Oct 15 19:04:24 [15159] DBG:core:parse_msg: SIP Request: > Oct 15 19:04:24 [15159] DBG:core:parse_msg: method: > Oct 15 19:04:24 [15159] DBG:core:parse_msg: uri: > > Oct 15 19:04:24 [15159] DBG:core:parse_msg: version: > Oct 15 19:04:24 [15159] DBG:core:parse_headers: flags=2 > Oct 15 19:04:24 [15159] DBG:core:parse_via_param: found param type > 232, = ; state=6 > Oct 15 19:04:24 [15159] DBG:core:parse_via_param: found param type > 235, = ; state=17 > Oct 15 19:04:24 [15159] DBG:core:parse_via: end of header reached, state=5 > Oct 15 19:04:24 [15159] DBG:core:parse_headers: via found, flags=2 > Oct 15 19:04:24 [15159] DBG:core:parse_headers: this is the first via > Oct 15 19:04:24 [15159] DBG:core:receive_msg: After parse_msg... > Oct 15 19:04:24 [15159] DBG:core:receive_msg: preparing to run routing > scripts... > Oct 15 19:04:24 [15159] DBG:core:parse_headers: flags=ffffffffffffffff > Oct 15 19:04:24 [15159] DBG:core:parse_to: end of header reached, state=9 > Oct 15 19:04:24 [15159] DBG:core:parse_to: display={}, > ruri={sip:test2 at 103.24.228.158} > Oct 15 19:04:24 [15159] DBG:core:get_hdr_field: [26]; > uri=[sip:test2 at 103.24.228.158] > Oct 15 19:04:24 [15159] DBG:core:get_hdr_field: to body > [sip:test2 at 103.24.228.158 > ] > Oct 15 19:04:24 [15159] DBG:core:get_hdr_field: cseq : <20> > Oct 15 19:04:24 [15159] DBG:core:get_hdr_field: content_length=729 > Oct 15 19:04:24 [15159] DBG:core:get_hdr_field: found end of header > Oct 15 19:04:24 [15159] DBG:core:parse_params: Parsing params > for:[+sip.instance=""] > Oct 15 19:04:24 [15159] DBG:maxfwd:is_maxfwd_present: value = 70 > Oct 15 19:04:24 [15159] DBG:uri:has_totag: no totag > Oct 15 19:04:24 [15159] DBG:core:parse_headers: flags=78 > Oct 15 19:04:24 [15159] DBG:tm:t_lookup_request: start searching: > hash=53427, isACK=0 > Oct 15 19:04:24 [15159] DBG:tm:matching_3261: RFC3261 transaction > matching failed > Oct 15 19:04:24 [15159] DBG:tm:t_lookup_request: no transaction found > Oct 15 19:04:24 [15159] DBG:core:parse_to_param: tag=eC6yy-cLm > Oct 15 19:04:24 [15159] DBG:core:parse_to: end of header reached, state=29 > Oct 15 19:04:24 [15159] DBG:core:parse_to: display={}, > ruri={sip:test1 at 103.24.228.158} > Oct 15 19:04:24 [15159] DBG:core:grep_sock_info: checking if host==us: > 14==14 && [103.24.228.158] == [103.24.228.158] > Oct 15 19:04:24 [15159] DBG:core:grep_sock_info: checking if port 5060 > matches port 5060 > Oct 15 19:04:24 [15159] DBG:core:parse_headers: flags=200 > Oct 15 19:04:24 [15159] DBG:rr:find_first_route: No Route headers found > Oct 15 19:04:24 [15159] DBG:rr:loose_route: There is no Route HF > Oct 15 19:04:24 [15159] DBG:core:grep_sock_info: checking if host==us: > 14==14 && [103.24.228.158] == [103.24.228.158] > Oct 15 19:04:24 [15159] DBG:core:grep_sock_info: checking if port 5060 > matches port 5060 > Oct 15 19:04:24 [15159] DBG:registrar:lookup: found a complete match > Oct 15 19:04:24 [15159] DBG:registrar:lookup: setting as ruri > > Oct 15 19:04:24 [15159] DBG:registrar:lookup: looking for branches > Oct 15 19:04:24 [15159] DBG:registrar:lookup: setting branch > > Oct 15 19:04:24 [15159] DBG:core:parse_headers: flags=ffffffffffffffff > Oct 15 19:04:24 [15159] DBG:core:parse_headers: flags=8 > Oct 15 19:04:24 [15159] DBG:core:parse_headers: flags=8 > Oct 15 19:04:24 [15159] DBG:core:parse_headers: flags=8000000 > Oct 15 19:04:24 [15159] DBG:rr:add_rr_param: adding (;nat=yes) > 0x7f985bfe1250 > Oct 15 19:04:24 [15159] DBG:tm:t_newtran: transaction on entrance=(nil) > Oct 15 19:04:24 [15159] DBG:core:parse_headers: flags=ffffffffffffffff > Oct 15 19:04:24 [15159] DBG:core:parse_headers: flags=78 > Oct 15 19:04:24 [15159] DBG:tm:t_lookup_request: start searching: > hash=53427, isACK=0 > Oct 15 19:04:24 [15159] DBG:tm:matching_3261: RFC3261 transaction > matching failed > Oct 15 19:04:24 [15159] DBG:tm:t_lookup_request: no transaction found > Oct 15 19:04:24 [15159] DBG:tm:run_reqin_callbacks: > trans=0x7f9858507f28, callback type 1, id 0 entered > Oct 15 19:04:24 [15159] DBG:core:parse_headers: flags=78 > Oct 15 19:04:24 [15159] DBG:core:parse_headers: flags=ffffffffffffffff > Oct 15 19:04:24 [15159] DBG:core:_shm_resize: resize(0) called > Oct 15 19:04:24 [15159] DBG:tm:_reply_light: reply sent out. > buf=0x7f985bfe1d78: SIP/2.0 1..., shmem=0x7f985850bb48: SIP/2.0 1 > Oct 15 19:04:24 [15159] DBG:tm:_reply_light: finished > Oct 15 19:04:24 [15159] DBG:core:buf_init: initializing... > new branch at sip:test2 at 192.168.1.3:5080 > Oct 15 19:04:24 [15159] DBG:core:_shm_resize: resize(0) called > Oct 15 19:04:24 [15159] DBG:core:mk_proxy: doing DNS lookup... > Oct 15 19:04:24 [15159] DBG:core:parse_headers: flags=2000 > Oct 15 19:04:24 [15159] DBG:core:parse_headers: flags=ffffffffffffffff > Oct 15 19:04:24 [15159] DBG:core:clen_builder: content-length: 871 (871) > new branch at sip:test2 at 124.193.138.210:5299 > Oct 15 19:04:24 [15159] DBG:core:_shm_resize: resize(0) called > Oct 15 19:04:24 [15159] DBG:core:mk_proxy: doing DNS lookup... > Oct 15 19:04:24 [15159] DBG:core:parse_headers: flags=2000 > Oct 15 19:04:24 [15159] DBG:core:parse_headers: flags=ffffffffffffffff > Oct 15 19:04:24 [15159] DBG:core:clen_builder: content-length: 871 (871) > Oct 15 19:04:24 [15159] DBG:tm:set_timer: relative timeout is 500000 > Oct 15 19:04:24 [15159] DBG:tm:insert_timer_unsafe: [4]: > 0x7f9858508148 (869000000) > Oct 15 19:04:24 [15159] DBG:tm:insert_timer_unsafe: [0]: > 0x7f9858508178 (873) > Oct 15 19:04:24 [15159] DBG:tm:set_timer: relative timeout is 500000 > Oct 15 19:04:24 [15159] DBG:tm:insert_timer_unsafe: [4]: > 0x7f9858508348 (869000000) > Oct 15 19:04:24 [15159] DBG:tm:insert_timer_unsafe: [0]: > 0x7f9858508378 (873) > Oct 15 19:04:24 [15159] DBG:tm:t_relay_to: new transaction fwd'ed > Oct 15 19:04:24 [15159] DBG:tm:t_unref: UNREF_UNSAFE: [0x7f9858507f28] > after is 0 > Oct 15 19:04:24 [15159] DBG:core:destroy_avp_list: destroying list (nil) > Oct 15 19:04:24 [15159] DBG:core:receive_msg: cleaning up > Oct 15 19:04:24 [15165] DBG:nathelper:nh_timer: resolving next hop: > '124.193.138.210' > Oct 15 19:04:24 [15165] DBG:nathelper:nh_timer: resolving next hop: > '124.193.138.210' > Oct 15 19:04:24 [15164] DBG:tm:utimer_routine: timer > routine:4,tl=0x7f9858508148 next=0x7f9858508348, timeout=869000000 > Oct 15 19:04:24 [15164] DBG:tm:retransmission_handler: > retransmission_handler : request resending (t=0x7f9858507f28, INVITE > si ... ) > Oct 15 19:04:24 [15164] DBG:tm:set_timer: relative timeout is 1000000 > Oct 15 19:04:24 [15164] DBG:tm:insert_timer_unsafe: [5]: > 0x7f9858508148 (870000000) > Oct 15 19:04:24 [15164] DBG:tm:retransmission_handler: > retransmission_handler : done > Oct 15 19:04:24 [15164] DBG:tm:utimer_routine: timer > routine:4,tl=0x7f9858508348 next=(nil), timeout=869000000 > Oct 15 19:04:24 [15164] DBG:tm:retransmission_handler: > retransmission_handler : request resending (t=0x7f9858507f28, INVITE > si ... ) > Oct 15 19:04:24 [15164] DBG:tm:set_timer: relative timeout is 1000000 > Oct 15 19:04:24 [15164] DBG:tm:insert_timer_unsafe: [5]: > 0x7f9858508348 (870000000) > Oct 15 19:04:24 [15164] DBG:tm:retransmission_handler: > retransmission_handler : done > Oct 15 19:04:25 [15164] DBG:tm:utimer_routine: timer > routine:5,tl=0x7f9858508148 next=0x7f9858508348, timeout=870000000 > Oct 15 19:04:25 [15164] DBG:tm:retransmission_handler: > retransmission_handler : request resending (t=0x7f9858507f28, INVITE > si ... ) > Oct 15 19:04:25 [15164] DBG:tm:set_timer: relative timeout is 2000000 > Oct 15 19:04:25 [15164] DBG:tm:insert_timer_unsafe: [6]: > 0x7f9858508148 (872000000) > Oct 15 19:04:25 [15164] DBG:tm:retransmission_handler: > retransmission_handler : done > Oct 15 19:04:25 [15164] DBG:tm:utimer_routine: timer > routine:5,tl=0x7f9858508348 next=(nil), timeout=870000000 > Oct 15 19:04:25 [15164] DBG:tm:retransmission_handler: > retransmission_handler : request resending (t=0x7f9858507f28, INVITE > si ... ) > Oct 15 19:04:25 [15164] DBG:tm:set_timer: relative timeout is 2000000 > Oct 15 19:04:25 [15164] DBG:tm:insert_timer_unsafe: [6]: > 0x7f9858508348 (872000000) > Oct 15 19:04:25 [15164] DBG:tm:retransmission_handler: > retransmission_handler : done > Oct 15 19:04:28 [15164] DBG:tm:utimer_routine: timer > routine:6,tl=0x7f9858508148 next=0x7f9858508348, timeout=872000000 > Oct 15 19:04:28 [15164] DBG:tm:retransmission_handler: > retransmission_handler : request resending (t=0x7f9858507f28, INVITE > si ... ) > Oct 15 19:04:28 [15164] DBG:tm:set_timer: relative timeout is 4000000 > Oct 15 19:04:28 [15164] DBG:tm:insert_timer_unsafe: [7]: > 0x7f9858508148 (876000000) > Oct 15 19:04:28 [15164] DBG:tm:retransmission_handler: > retransmission_handler : done > Oct 15 19:04:28 [15164] DBG:tm:utimer_routine: timer > routine:6,tl=0x7f9858508348 next=(nil), timeout=872000000 > Oct 15 19:04:28 [15164] DBG:tm:retransmission_handler: > retransmission_handler : request resending (t=0x7f9858507f28, INVITE > si ... ) > Oct 15 19:04:28 [15164] DBG:tm:set_timer: relative timeout is 4000000 > Oct 15 19:04:28 [15164] DBG:tm:insert_timer_unsafe: [7]: > 0x7f9858508348 (876000000) > Oct 15 19:04:28 [15164] DBG:tm:retransmission_handler: > retransmission_handler : done > Oct 15 19:04:29 [15164] DBG:tm:timer_routine: timer > routine:0,tl=0x7f9858508178 next=0x7f9858508378, timeout=873 > Oct 15 19:04:29 [15164] DBG:tm:final_response_handler: Cancel sent > out, sending 408 (0x7f9858507f28) > Oct 15 19:04:29 [15164] DBG:tm:t_should_relay_response: T_code=100, > new_code=408 > Oct 15 19:04:29 [15164] DBG:tm:relay_reply: branch=0, save=1, relay=-1 > Oct 15 19:04:29 [15164] DBG:tm:final_response_handler: done > Oct 15 19:04:29 [15164] DBG:tm:timer_routine: timer > routine:0,tl=0x7f9858508378 next=(nil), timeout=873 > Oct 15 19:04:29 [15164] DBG:tm:final_response_handler: Cancel sent > out, sending 408 (0x7f9858507f28) > Oct 15 19:04:29 [15164] DBG:tm:t_should_relay_response: T_code=100, > new_code=408 > Oct 15 19:04:29 [15164] DBG:tm:t_pick_branch: picked branch 0, code > 408 (prio=800) > Oct 15 19:04:29 [15164] DBG:tm:is_3263_failure: dns-failover test: > branch=0, last_recv=408, flags=1 > Oct 15 19:04:29 [15164] DBG:tm:t_should_relay_response: trying > DNS-based failover > Oct 15 19:04:29 [15164] DBG:tm:run_trans_callbacks: > trans=0x7f9858507f28, callback type 32, id 0 entered > ACC: call missed: > timestamp=1413371069;method=INVITE;from_tag=eC6yy-cLm;to_tag=;call_id=OHtW9D~WiH;code=408;reason=Request > Timeout > Oct 15 19:04:29 [15164] DBG:tm:relay_reply: branch=1, save=0, relay=0 > Oct 15 19:04:29 [15164] DBG:core:parse_headers: flags=ffffffffffffffff > Oct 15 19:04:29 [15164] DBG:tm:set_timer: relative timeout is 500000 > Oct 15 19:04:29 [15164] DBG:tm:insert_timer_unsafe: [4]: > 0x7f9858508070 (873400000) > Oct 15 19:04:29 [15164] DBG:tm:insert_timer_unsafe: [0]: > 0x7f98585080a0 (878) > Oct 15 19:04:29 [15164] DBG:tm:relay_reply: sent buf=0x7f985bfdd030: > SIP/2.0 4..., shmem=0x7f985850bb48: SIP/2.0 4 > Oct 15 19:04:29 [15164] DBG:tm:run_trans_callbacks: > trans=0x7f9858507f28, callback type 128, id 0 entered > Oct 15 19:04:29 [15164] DBG:tm:final_response_handler: done > Oct 15 19:04:29 [15161] DBG:core:parse_msg: SIP Request: > Oct 15 19:04:29 [15161] DBG:core:parse_msg: method: > Oct 15 19:04:29 [15161] DBG:core:parse_msg: uri: > > Oct 15 19:04:29 [15161] DBG:core:parse_msg: version: > Oct 15 19:04:29 [15161] DBG:core:parse_headers: flags=2 > Oct 15 19:04:29 [15161] DBG:core:parse_via_param: found param type > 232, = ; state=6 > Oct 15 19:04:29 [15161] DBG:core:parse_via_param: found param type > 235, = ; state=17 > Oct 15 19:04:29 [15161] DBG:core:parse_via: end of header reached, state=5 > Oct 15 19:04:29 [15161] DBG:core:parse_headers: via found, flags=2 > Oct 15 19:04:29 [15161] DBG:core:parse_headers: this is the first via > Oct 15 19:04:29 [15161] DBG:core:receive_msg: After parse_msg... > Oct 15 19:04:29 [15161] DBG:core:receive_msg: preparing to run routing > scripts... > Oct 15 19:04:29 [15161] DBG:sl:sl_filter_ACK: to late to be a local ACK! > Oct 15 19:04:29 [15161] DBG:core:parse_headers: flags=ffffffffffffffff > Oct 15 19:04:29 [15161] DBG:core:parse_to_param: > tag=d8bd1b57441363f641ce73441337eed0-d2b8 > Oct 15 19:04:29 [15161] DBG:core:parse_to: end of header reached, state=29 > Oct 15 19:04:29 [15161] DBG:core:parse_to: display={}, > ruri={sip:test2 at 103.24.228.158} > Oct 15 19:04:29 [15161] DBG:core:get_hdr_field: [70]; > uri=[sip:test2 at 103.24.228.158] > Oct 15 19:04:29 [15161] DBG:core:get_hdr_field: to body > [] > Oct 15 19:04:29 [15161] DBG:core:get_hdr_field: cseq : <20> > Oct 15 19:04:29 [15161] DBG:core:get_hdr_field: found end of header > Oct 15 19:04:29 [15161] DBG:core:parse_params: Parsing params > for:[+sip.instance=""] > Oct 15 19:04:29 [15161] DBG:maxfwd:is_maxfwd_present: value = 70 > Oct 15 19:04:29 [15161] DBG:uri:has_totag: totag found > Oct 15 19:04:29 [15161] DBG:core:parse_headers: flags=200 > Oct 15 19:04:29 [15161] DBG:rr:find_first_route: No Route headers found > Oct 15 19:04:29 [15161] DBG:rr:loose_route: There is no Route HF > Oct 15 19:04:29 [15161] DBG:core:parse_headers: flags=78 > Oct 15 19:04:29 [15161] DBG:tm:t_lookup_request: start searching: > hash=53427, isACK=1 > Oct 15 19:04:29 [15161] DBG:tm:matching_3261: RFC3261 transaction > matched, tid=.1tcd1QMAc > Oct 15 19:04:29 [15161] DBG:tm:t_lookup_request: > REF_UNSAFE:[0x7f9858507f28] after is 1 > Oct 15 19:04:29 [15161] DBG:tm:t_lookup_request: transaction found > (T=0x7f9858507f28) > Oct 15 19:04:29 [15161] DBG:tm:cleanup_uac_timers: RETR/FR timers reset > Oct 15 19:04:29 [15161] DBG:tm:insert_timer_unsafe: [2]: > 0x7f9858507fa8 (878) > Oct 15 19:04:29 [15161] DBG:tm:t_unref: UNREF_UNSAFE: [0x7f9858507f28] > after is 0 > Oct 15 19:04:29 [15161] DBG:core:destroy_avp_list: destroying list (nil) > Oct 15 19:04:29 [15161] DBG:core:receive_msg: cleaning up > Oct 15 19:04:29 [15164] DBG:tm:utimer_routine: timer > routine:4,tl=0x7f9858508070 next=(nil), timeout=873400000 > Oct 15 19:04:31 [15165] DBG:nathelper:nh_timer: resolving next hop: > '124.193.138.210' > Oct 15 19:04:31 [15165] DBG:nathelper:nh_timer: resolving next hop: > '124.193.138.210' > Oct 15 19:04:31 [15160] DBG:core:udp_rcv_loop: probing packet received > len = 4 > Oct 15 19:04:32 [15164] DBG:tm:utimer_routine: timer > routine:7,tl=0x7f9858508148 next=0x7f9858508348, timeout=876000000 > Oct 15 19:04:32 [15164] DBG:tm:utimer_routine: timer > routine:7,tl=0x7f9858508348 next=(nil), timeout=876000000 > Oct 15 19:04:33 [15162] DBG:core:udp_rcv_loop: probing packet received > len = 4 > Oct 15 19:04:35 [15164] DBG:tm:timer_routine: timer > routine:0,tl=0x7f98585080a0 next=(nil), timeout=878 > Oct 15 19:04:35 [15164] DBG:tm:timer_routine: timer > routine:2,tl=0x7f9858507fa8 next=(nil), timeout=878 > Oct 15 19:04:35 [15164] DBG:tm:wait_handler: removing 0x7f9858507f28 > from table > Oct 15 19:04:35 [15164] DBG:tm:delete_cell: delete transaction > 0x7f9858507f28 > Oct 15 19:04:35 [15164] DBG:tm:wait_handler: done > Oct 15 19:04:35 [15165] DBG:nathelper:nh_timer: resolving next hop: > '124.193.138.210' > Oct 15 19:04:35 [15165] DBG:nathelper:nh_timer: resolving next hop: > '124.193.138.210' > Oct 15 19:04:41 [15159] DBG:core:udp_rcv_loop: probing packet received > len = 4 > Oct 15 19:04:43 [15165] DBG:nathelper:nh_timer: resolving next hop: > '124.193.138.210' > Oct 15 19:04:43 [15165] DBG:nathelper:nh_timer: resolving next hop: > '124.193.138.210' > Oct 15 19:04:43 [15161] DBG:core:udp_rcv_loop: probing packet received > len = 4 > Oct 15 19:04:46 [15165] DBG:nathelper:nh_timer: resolving next hop: > '124.193.138.210' > Oct 15 19:04:46 [15165] DBG:nathelper:nh_timer: resolving next hop: > '124.193.138.210' > Oct 15 19:04:51 [15160] DBG:core:udp_rcv_loop: probing packet received > len = 4 > Oct 15 19:04:54 [15165] DBG:nathelper:nh_timer: resolving next hop: > '124.193.138.210' > Oct 15 19:04:54 [15165] DBG:nathelper:nh_timer: resolving next hop: > '124.193.138.210' > Oct 15 19:04:57 [15165] DBG:nathelper:nh_timer: resolving next hop: > '124.193.138.210' > Oct 15 19:04:57 [15165] DBG:nathelper:nh_timer: resolving next hop: > '124.193.138.210' > > > > At 2014-10-15 15:13:00, "Bogdan-Andrei Iancu" wrote: > > Hi George, > > If your OpenSIPS fails to reach the UAC is because of two reasons: > - NAT pinhole is closed - but if pinging is done, it shouldn't be > - opensips is trying to contact UAC via wrong IP:port - can > you confirm that when calling the UAC, OpenSIPS sends the INVITE > to same IP and port as where the pingings are coming from ? > > TCP works as this part is "automatically" resolved because of the > connection (where the other pipe is known). > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 15.10.2014 03:24, george wu wrote: >> >> Hi, Bogdan-Andrei: >> >> For udp, it fails when reaching the UAC even though the UAC keeps >> pinging the server all the time. >> >> For tcp, although it works. I find something interesting. >> Only when the client pings the server, the invite message is sent >> to the UAC. >> In my understanding, the server should be able to send message to >> the UAC since the >> tcp connection is open. Actually the sip server is unable to send >> message to the UAC. >> >> About the firewall type, I use opensipsctl ul show/rm to check. >> I find every time when it register, i get the same ip/portmost of >> time. >> But occasionally it might get different ip/port. >> I believe it is nat within a cone. >> >> I am using ice, the ice only work after the first invite message >> is delivered to the peer. >> My ice with mediaproxy works perfectly. >> >> >> George Wu >> >> At 2014-10-15 00:22:46, "Bogdan-Andrei Iancu" >> wrote: >> >> Hi George, >> >> NAT traversal is not only about pinging, but also about >> mangling/correcting the SIP traffic (from private IPs >> perspective) and ensuring the RTP flow. >> >> So you need to be sure that all 3 points are addressed. >> >> TCP versus UDP - there is only a difference at IP transport >> level...like datagram versus connection, and their >> implications at NAT level (being able to reach the device >> behind the nat). Otherwise it;s the same. >> >> For UDP, can you see what fails ? the registration? reaching >> the UAC ? >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> On 14.10.2014 18:37, george wu wrote: >>> My experience is for two uac (linphone) behind a firewall, >>> tcp/tls will always work. >>> udp will never work. >>> >>> for both tcp/udp, my uac will send keep alive every 10 seconds. >>> I don't understand what makes those difference. >>> Can any one share your experience? >>> >>> George Wu >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aihuawu2012 at 163.com Wed Oct 15 14:56:18 2014 From: aihuawu2012 at 163.com (george wu) Date: Wed, 15 Oct 2014 20:56:18 +0800 (CST) Subject: [OpenSIPS-Users] udp or tcp for nat traversal? In-Reply-To: <543E6C8A.6000802@opensips.org> References: <9f50cdb.2658d.1490f4e26ee.Coremail.aihuawu2012@163.com> <543D4DD6.1020405@opensips.org> <4dd40a9b.e54.14911311a6a.Coremail.aihuawu2012@163.com> <543E1E7C.4070407@opensips.org> <46185c1e.103bc.14913b36612.Coremail.aihuawu2012@163.com> <543E6C8A.6000802@opensips.org> Message-ID: <28459cfe.10c28.14913e161fa.Coremail.aihuawu2012@163.com> Hi, Bogdan: I will try ngrep and tcpdump. But I am quite sure it is mediaproxy problem, since I can print out all the debug message by linphonec. If I enable mediaproxy, the linphone doesn't print any thing since it doesn't get message from opensips. Once I kill mediaproxy, the linphone gets and prints out all the communication which is correct. George Wu At 2014-10-15 20:46:02, "Bogdan-Andrei Iancu" wrote: Hi George, Not sure if a media relay process has anything to do with the ability to send traffic to an UAC - do you actually see with ngrep/tcpdump the request (on the network level) sent by opensips to the UAC ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 15.10.2014 15:06, george wu wrote: Hi, Bogdan: I think I have found the problem. I am using mediaproxy. If I kill that proxy. suddenly the uac can get the message. So it is quite obvious that my mediaproxy setting is not correct. Just I don't know how to fix it. I modify it from my old rtpproxy setting. George ///////////////////// #### NAT modules loadmodule "nathelper.so" modparam("nathelper", "natping_interval", 10) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "received_avp", "$avp(received_nh)") #loadmodule "rtpproxy.so" #modparam("rtpproxy", "rtpproxy_sock", "udp:localhost:12221") # CUSTOMIZE ME loadmodule "mediaproxy.so" modparam("mediaproxy", "mediaproxy_socket", "/var/run/mediaproxy/dispatcher.sock") modparam("mediaproxy", "ice_candidate", "low-priority") ####### Routing Logic ######## # main request routing logic route{ force_rport(); if (nat_uac_test("23")) { if (is_method("REGISTER")) { fix_nated_register(); setbflag(NAT); } else { fix_nated_contact(); setflag(NAT); } } if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { if (is_method("BYE")) { setflag(ACC_DO); # do accounting ... setflag(ACC_FAILED); # ... even if the transaction fails } else if (is_method("INVITE")) { # even if in most of the cases is useless, do RR for # re-INVITEs alos, as some buggy clients do change route set # during the dialog. record_route(); } if (check_route_param("nat=yes")) setflag(NAT); # route it out to whatever destination was set by loose_route() # in $du (destination URI). route(relay); } else { if ( is_method("ACK") ) { if ( t_check_trans() ) { # non loose-route, but stateful ACK; must be an ACK after # a 487 or e.g. 404 from upstream server t_relay(); exit; } else { # ACK without matching transaction -> # ignore and discard exit; } } sl_send_reply("404","Not here"); } exit; } # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) t_relay(); exit; } t_check_trans(); if ( !(is_method("REGISTER") ) ) { if (from_uri==myself) { } else { # if caller is not local, then called number must be local if (!uri==myself) { send_reply("403","Rely forbidden"); exit; } } } # preloaded route checking if (loose_route()) { xlog("L_ERR", "Attempt to route with preloaded Route's [$fu/$tu/$ru/$ci]"); if (!is_method("ACK")) sl_send_reply("403","Preload Route denied"); exit; } # record routing if (!is_method("REGISTER|MESSAGE")) record_route(); # account only INVITEs if (is_method("INVITE")) { setflag(ACC_DO); # do accounting } if (!uri==myself) { append_hf("P-hint: outbound\r\n"); # if you have some interdomain connections via TLS ## CUSTOMIZE IF NEEDED ##if ($rd=="tls_domain1.net" ## || $rd=="tls_domain2.net" ##) { ## force_send_socket(tls:127.0.0.1:5061); # CUSTOMIZE ##} route(relay); } # requests for my domain if (is_method("PUBLISH|SUBSCRIBE")) { sl_send_reply("503", "Service Unavailable"); exit; } if (is_method("REGISTER")) { if ( proto==TCP || proto==TLS || 0 ) setflag(TCP_PERSISTENT); if (!save("location")) sl_reply_error(); exit; } if ($rU==NULL) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; } # do lookup with method filtering if (!lookup("location","m")) { t_newtran(); t_reply("404", "Not Found"); exit; } if (isbflagset(NAT)) setflag(NAT); # when routing via usrloc, log the missed calls also setflag(ACC_MISSED); route(relay); } route[relay] { # for INVITEs enable some additional helper routes if (is_method("INVITE")) { if (isflagset(NAT)) { # rtpproxy_offer("ro"); use_media_proxy(); } t_on_branch("per_branch_ops"); t_on_reply("handle_nat"); t_on_failure("missed_call"); } if (is_method("BYE")) { if (isflagset(NAT)) { end_media_session(); } } if (isflagset(NAT)) { add_rr_param(";nat=yes"); } if (!t_relay()) { send_reply("500","Internal Error"); }; exit; } branch_route[per_branch_ops] { xlog("new branch at $ru\n"); } onreply_route[handle_nat] { if (nat_uac_test("1")) fix_nated_contact(); # if ( isflagset(NAT) ) # rtpproxy_answer("ro"); if (is_method("INVITE")) { if (isflagset(NAT)) { use_media_proxy(); } } if (is_method("BYE")) { if (isflagset(NAT)) { end_media_session(); } } xlog("incoming reply\n"); } failure_route[missed_call] { if (t_was_cancelled()) { exit; } # uncomment the following lines if you want to block client # redirect based on 3xx replies. ##if (t_check_status("3[0-9][0-9]")) { ##t_reply("404","Not found"); ## exit; ##} } ? 2014-10-15 15:13:00?"Bogdan-Andrei Iancu" ??? Hi George, If your OpenSIPS fails to reach the UAC is because of two reasons: - NAT pinhole is closed - but if pinging is done, it shouldn't be - opensips is trying to contact UAC via wrong IP:port - can you confirm that when calling the UAC, OpenSIPS sends the INVITE to same IP and port as where the pingings are coming from ? TCP works as this part is "automatically" resolved because of the connection (where the other pipe is known). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 15.10.2014 03:24, george wu wrote: Hi, Bogdan-Andrei: For udp, it fails when reaching the UAC even though the UAC keeps pinging the server all the time. For tcp, although it works. I find something interesting. Only when the client pings the server, the invite message is sent to the UAC. In my understanding, the server should be able to send message to the UAC since the tcp connection is open. Actually the sip server is unable to send message to the UAC. About the firewall type, I use opensipsctl ul show/rm to check. I find every time when it register, i get the same ip/port most of time. But occasionally it might get different ip/port. I believe it is nat within a cone. I am using ice, the ice only work after the first invite message is delivered to the peer. My ice with mediaproxy works perfectly. George Wu At 2014-10-15 00:22:46, "Bogdan-Andrei Iancu" wrote: Hi George, NAT traversal is not only about pinging, but also about mangling/correcting the SIP traffic (from private IPs perspective) and ensuring the RTP flow. So you need to be sure that all 3 points are addressed. TCP versus UDP - there is only a difference at IP transport level...like datagram versus connection, and their implications at NAT level (being able to reach the device behind the nat). Otherwise it;s the same. For UDP, can you see what fails ? the registration? reaching the UAC ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 14.10.2014 18:37, george wu wrote: My experience is for two uac (linphone) behind a firewall, tcp/tls will always work. udp will never work. for both tcp/udp, my uac will send keep alive every 10 seconds. I don't understand what makes those difference. Can any one share your experience? George Wu _______________________________________________ Users mailing list Users at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From aihuawu2012 at 163.com Wed Oct 15 15:59:45 2014 From: aihuawu2012 at 163.com (george wu) Date: Wed, 15 Oct 2014 21:59:45 +0800 (CST) Subject: [OpenSIPS-Users] udp or tcp for nat traversal? In-Reply-To: <543E6C8A.6000802@opensips.org> References: <9f50cdb.2658d.1490f4e26ee.Coremail.aihuawu2012@163.com> <543D4DD6.1020405@opensips.org> <4dd40a9b.e54.14911311a6a.Coremail.aihuawu2012@163.com> <543E1E7C.4070407@opensips.org> <46185c1e.103bc.14913b36612.Coremail.aihuawu2012@163.com> <543E6C8A.6000802@opensips.org> Message-ID: <3a897f50.1171e.149141b7c05.Coremail.aihuawu2012@163.com> Hi, Bogdan: server 103.24.228.158.5060 caller 124.193.138.210.5758 callee 124.193.138.210.6001 1) first I enable mediaproxy, 2) invite, tcpdump, callee not reply. 3) kill media-relay 4) invite, tcpdump, callee replied So it must be something with the mediaproxy. what should I dump further so that I can get more interesting result? George Wu [root at localhost ~]# tcpdump -nn -i eth2 'port 5060' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes 21:43:18.305220 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:43:18.305247 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:43:25.030750 IP 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 4 21:43:26.321502 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:43:26.321536 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:43:29.327585 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:43:29.327609 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:43:33.110680 IP 124.193.138.210.6001 > 103.24.228.158.5060: SIP, length: 4 21:43:35.031244 IP 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 4 21:43:37.344871 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:43:37.344899 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:43:40.350973 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:43:40.350998 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:43:43.119174 IP 124.193.138.210.6001 > 103.24.228.158.5060: SIP, length: 4 21:43:45.038000 IP 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 4 21:43:48.367245 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:43:48.367284 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:43:51.373390 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:43:51.373429 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:43:53.121467 IP 124.193.138.210.6001 > 103.24.228.158.5060: SIP, length: 4 21:43:55.045829 IP 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 4 21:43:59.393654 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:43:59.393690 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:44:02.399731 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:44:02.399766 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:44:03.128231 IP 124.193.138.210.6001 > 103.24.228.158.5060: SIP, length: 4 21:44:05.049049 IP 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 4 21:44:08.575857 IP 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 1291 21:44:08.594019 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 305 21:44:08.594286 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 21:44:08.594389 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 21:44:09.196392 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 21:44:09.196475 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 21:44:10.309196 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 21:44:10.309259 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 21:44:10.416003 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:44:10.416031 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:44:12.532938 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 21:44:12.533027 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 21:44:13.422094 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:44:13.422122 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:44:13.645779 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 350 21:44:13.726980 IP 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 388 21:44:15.048933 IP 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 4 21:44:21.438478 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:44:21.438548 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:44:23.140670 IP 124.193.138.210.6001 > 103.24.228.158.5060: SIP, length: 4 21:44:25.058513 IP 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 4 21:44:25.447528 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:44:25.447561 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:44:32.461748 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:44:32.461793 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:44:33.140726 IP 124.193.138.210.6001 > 103.24.228.158.5060: SIP, length: 4 21:44:35.067372 IP 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 4 21:44:36.469892 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:44:36.469930 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:44:43.484101 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:44:43.484129 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:44:45.073227 IP 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 4 21:44:47.492803 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:44:47.492839 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:44:55.074380 IP 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 4 21:44:55.508542 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:44:55.508570 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:44:58.514652 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:44:58.514677 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:45:03.150021 IP 124.193.138.210.6001 > 103.24.228.158.5060: SIP, length: 4 21:45:05.076895 IP 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 4 21:45:06.530917 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:45:06.530953 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:45:09.537020 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:45:09.537045 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 [root at localhost ~]# [root at localhost ~]# ps aux|grep media root 1675 0.0 0.7 233152 15312 ? SNL 04:02 0:05 python /develop/mediaproxy-2.6.1/media-dispatcher root 18155 0.0 0.9 334696 18292 ? SLl 21:30 0:00 python /develop/mediaproxy-2.6.1/media-relay root 18455 0.0 0.0 103240 864 pts/0 S+ 21:47 0:00 grep media [root at localhost ~]# kill -9 18155 [root at localhost ~]# tcpdump -nn -i eth2 'port 5060' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes 21:48:13.251925 IP 124.193.138.210.6001 > 103.24.228.158.5060: SIP, length: 4 21:48:14.928378 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:48:14.928416 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:48:15.189453 IP 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 4 21:48:18.936534 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:48:18.936570 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:48:23.741238 IP 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 893 21:48:23.751169 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 305 21:48:23.751294 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1040 21:48:23.751325 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1044 21:48:24.300008 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1040 21:48:24.300101 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1044 21:48:24.397301 IP 124.193.138.210.6001 > 103.24.228.158.5060: SIP, length: 432 21:48:24.397868 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 364 21:48:24.413045 IP 124.193.138.210.6001 > 103.24.228.158.5060: SIP, length: 387 21:48:24.413441 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 328 21:48:25.195982 IP 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 4 21:48:25.950777 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:48:25.950812 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:48:29.958937 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:48:29.958975 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:48:33.267771 IP 124.193.138.210.6001 > 103.24.228.158.5060: SIP, length: 4 21:48:35.198623 IP 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 4 21:48:37.976323 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:48:37.976352 IP 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 21:48:40.983285 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:48:40.983309 IP 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 21:48:45.216862 IP 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 4 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aihuawu2012 at 163.com Wed Oct 15 16:31:41 2014 From: aihuawu2012 at 163.com (george wu) Date: Wed, 15 Oct 2014 22:31:41 +0800 (CST) Subject: [OpenSIPS-Users] udp or tcp for nat traversal? In-Reply-To: <543E6C8A.6000802@opensips.org> References: <9f50cdb.2658d.1490f4e26ee.Coremail.aihuawu2012@163.com> <543D4DD6.1020405@opensips.org> <4dd40a9b.e54.14911311a6a.Coremail.aihuawu2012@163.com> <543E1E7C.4070407@opensips.org> <46185c1e.103bc.14913b36612.Coremail.aihuawu2012@163.com> <543E6C8A.6000802@opensips.org> Message-ID: <7e23bdde.11c2b.1491438b5be.Coremail.aihuawu2012@163.com> Hi, Bogdan: The following is the tcpdump with mediaproxy on. I can't see any problem. That means it is linphone problem which can't understand ice? Actually as I said before, if I use tcp/tls, ice actually works on linphone. What should I do more to test it? George Wu /// part 1 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 1291 INVITE sip:test2 at 103.24.228.158 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.3:5070;branch=z9hG4bK.FohJ-Pjji;rport From: ;tag=OGCx7gRon To: sip:test2 at 103.24.228.158 CSeq: 20 INVITE Call-ID: xHqVFVS-lk Max-Forwards: 70 Supported: outbound Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE Content-Type: application/sdp Content-Length: 730 Contact: ;+sip.instance="" User-Agent: Linphonec/3.7.0 (belle-sip/1.3.2) v=0 o=test1 1433 1939 IN IP4 192.168.1.3 s=Talk c=IN IP4 192.168.1.3 t=0 0 a=ice-pwd:84505b9d160c756b6b138ac5 a=ice-ufrag:5e5508d3 a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics m=audio 5909 RTP/AVP 111 110 0 8 101 c=IN IP4 124.193.138.210 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp:5060 a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx raddr 192.168.1.3 rport 7079 a=candidate:2 1 UDP 1694498815 124.193.138.210 5909 typ srflx raddr 192.168.1.3 rport 7078 22:20:18.692288 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 333) 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 305 SIP/2.0 100 Giving a try Via: SIP/2.0/UDP 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 From: ;tag=OGCx7gRon To: sip:test2 at 103.24.228.158 CSeq: 20 INVITE Call-ID: xHqVFVS-lk Server: OpenSIPS (1.11.2-tls (x86_64/linux)) Content-Length: 0 22:20:18.692464 IP (tos 0x10, ttl 64, id 55675, offset 0, flags [+], proto UDP (17), length 1500) 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 INVITE sip:test2 at 192.168.1.3:5080 SIP/2.0 Record-Route: Via: SIP/2.0/UDP 103.24.228.158:5060;branch=z9hG4bK57b9.3415f0e2.0 Via: SIP/2.0/UDP 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 From: ;tag=OGCx7gRon To: sip:test2 at 103.24.228.158 CSeq: 20 INVITE Call-ID: xHqVFVS-lk Max-Forwards: 69 Supported: outbound Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE Content-Type: application/sdp Content-Length: 872 Contact: ;+sip.instance="" User-Agent: Linphonec/3.7.0 (belle-sip/1.3.2) v=0 o=test1 1433 1939 IN IP4 192.168.1.3 s=Talk c=IN IP4 103.24.228.158 t=0 0 a=ice-pwd:84505b9d160c756b6b138ac5 a=ice-ufrag:5e5508d3 a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics m=audio 50002 RTP/AVP 111 110 0 8 101 c=IN IP4 103.24.228.158 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp:50003 a=candidate:R9ee41867 1 UDP 16777215 103.24.228.158 50002 typ relay a=candidate:R9ee41867 2 UDP 16777214 103.24.228.158 50003 typ relay a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx raddr 192.168[|sip] 22:20:18.692499 IP (tos 0x10, ttl 64, id 55676, offset 0, flags [+], proto UDP (17), length 1500) 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 INVITE sip:test2 at 124.193.138.210:6001 SIP/2.0 Record-Route: Via: SIP/2.0/UDP 103.24.228.158:5060;branch=z9hG4bK57b9.3415f0e2.1 Via: SIP/2.0/UDP 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 From: ;tag=OGCx7gRon To: sip:test2 at 103.24.228.158 CSeq: 20 INVITE Call-ID: xHqVFVS-lk Max-Forwards: 69 Supported: outbound Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE Content-Type: application/sdp Content-Length: 872 Contact: ;+sip.instance="" User-Agent: Linphonec/3.7.0 (belle-sip/1.3.2) v=0 o=test1 1433 1939 IN IP4 192.168.1.3 s=Talk c=IN IP4 103.24.228.158 t=0 0 a=ice-pwd:84505b9d160c756b6b138ac5 a=ice-ufrag:5e5508d3 a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics m=audio 50002 RTP/AVP 111 110 0 8 101 c=IN IP4 103.24.228.158 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp:50003 a=candidate:R9ee41867 1 UDP 16777215 103.24.228.158 50002 typ relay a=candidate:R9ee41867 2 UDP 16777214 103.24.228.158 50003 typ relay a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx raddr 192[|sip] 22:20:19.301123 IP (tos 0x10, ttl 64, id 55677, offset 0, flags [+], proto UDP (17), length 1500) 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 INVITE sip:test2 at 192.168.1.3:5080 SIP/2.0 Record-Route: Via: SIP/2.0/UDP 103.24.228.158:5060;branch=z9hG4bK57b9.3415f0e2.0 Via: SIP/2.0/UDP 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 From: ;tag=OGCx7gRon To: sip:test2 at 103.24.228.158 CSeq: 20 INVITE Call-ID: xHqVFVS-lk Max-Forwards: 69 Supported: outbound Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE Content-Type: application/sdp Content-Length: 872 Contact: ;+sip.instance="" User-Agent: Linphonec/3.7.0 (belle-sip/1.3.2) v=0 o=test1 1433 1939 IN IP4 192.168.1.3 s=Talk c=IN IP4 103.24.228.158 t=0 0 a=ice-pwd:84505b9d160c756b6b138ac5 a=ice-ufrag:5e5508d3 a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics m=audio 50002 RTP/AVP 111 110 0 8 101 c=IN IP4 103.24.228.158 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp:50003 a=candidate:R9ee41867 1 UDP 16777215 103.24.228.158 50002 typ relay a=candidate:R9ee41867 2 UDP 16777214 103.24.228.158 50003 typ relay a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx raddr 192.168[|sip] 22:20:19.301208 IP (tos 0x10, ttl 64, id 55678, offset 0, flags [+], proto UDP (17), length 1500) 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 INVITE sip:test2 at 124.193.138.210:6001 SIP/2.0 Record-Route: Via: SIP/2.0/UDP 103.24.228.158:5060;branch=z9hG4bK57b9.3415f0e2.1 Via: SIP/2.0/UDP 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 From: ;tag=OGCx7gRon To: sip:test2 at 103.24.228.158 CSeq: 20 INVITE Call-ID: xHqVFVS-lk Max-Forwards: 69 Supported: outbound Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE Content-Type: application/sdp Content-Length: 872 Contact: ;+sip.instance="" User-Agent: Linphonec/3.7.0 (belle-sip/1.3.2) v=0 o=test1 1433 1939 IN IP4 192.168.1.3 s=Talk c=IN IP4 103.24.228.158 t=0 0 a=ice-pwd:84505b9d160c756b6b138ac5 a=ice-ufrag:5e5508d3 a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics m=audio 50002 RTP/AVP 111 110 0 8 101 c=IN IP4 103.24.228.158 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp:50003 a=candidate:R9ee41867 1 UDP 16777215 103.24.228.158 50002 typ relay a=candidate:R9ee41867 2 UDP 16777214 103.24.228.158 50003 typ relay a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx raddr 192[|sip] 22:20:20.413939 IP (tos 0x10, ttl 64, id 55679, offset 0, flags [+], proto UDP (17), length 1500) -------------- next part -------------- An HTML attachment was scrubbed... URL: From aihuawu2012 at 163.com Wed Oct 15 16:32:27 2014 From: aihuawu2012 at 163.com (george wu) Date: Wed, 15 Oct 2014 22:32:27 +0800 (CST) Subject: [OpenSIPS-Users] udp or tcp for nat traversal? In-Reply-To: <543E6C8A.6000802@opensips.org> References: <9f50cdb.2658d.1490f4e26ee.Coremail.aihuawu2012@163.com> <543D4DD6.1020405@opensips.org> <4dd40a9b.e54.14911311a6a.Coremail.aihuawu2012@163.com> <543E1E7C.4070407@opensips.org> <46185c1e.103bc.14913b36612.Coremail.aihuawu2012@163.com> <543E6C8A.6000802@opensips.org> Message-ID: <19a5f1b5.11c47.14914396a05.Coremail.aihuawu2012@163.com> //part 2 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 INVITE sip:test2 at 192.168.1.3:5080 SIP/2.0 Record-Route: Via: SIP/2.0/UDP 103.24.228.158:5060;branch=z9hG4bK57b9.3415f0e2.0 Via: SIP/2.0/UDP 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 From: ;tag=OGCx7gRon To: sip:test2 at 103.24.228.158 CSeq: 20 INVITE Call-ID: xHqVFVS-lk Max-Forwards: 69 Supported: outbound Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE Content-Type: application/sdp Content-Length: 872 Contact: ;+sip.instance="" User-Agent: Linphonec/3.7.0 (belle-sip/1.3.2) v=0 o=test1 1433 1939 IN IP4 192.168.1.3 s=Talk c=IN IP4 103.24.228.158 t=0 0 a=ice-pwd:84505b9d160c756b6b138ac5 a=ice-ufrag:5e5508d3 a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics m=audio 50002 RTP/AVP 111 110 0 8 101 c=IN IP4 103.24.228.158 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp:50003 a=candidate:R9ee41867 1 UDP 16777215 103.24.228.158 50002 typ relay a=candidate:R9ee41867 2 UDP 16777214 103.24.228.158 50003 typ relay a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx raddr 192.168[|sip] 22:20:20.414018 IP (tos 0x10, ttl 64, id 55680, offset 0, flags [+], proto UDP (17), length 1500) 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 INVITE sip:test2 at 124.193.138.210:6001 SIP/2.0 Record-Route: Via: SIP/2.0/UDP 103.24.228.158:5060;branch=z9hG4bK57b9.3415f0e2.1 Via: SIP/2.0/UDP 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 From: ;tag=OGCx7gRon To: sip:test2 at 103.24.228.158 CSeq: 20 INVITE Call-ID: xHqVFVS-lk Max-Forwards: 69 Supported: outbound Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE Content-Type: application/sdp Content-Length: 872 Contact: ;+sip.instance="" User-Agent: Linphonec/3.7.0 (belle-sip/1.3.2) v=0 o=test1 1433 1939 IN IP4 192.168.1.3 s=Talk c=IN IP4 103.24.228.158 t=0 0 a=ice-pwd:84505b9d160c756b6b138ac5 a=ice-ufrag:5e5508d3 a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics m=audio 50002 RTP/AVP 111 110 0 8 101 c=IN IP4 103.24.228.158 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp:50003 a=candidate:R9ee41867 1 UDP 16777215 103.24.228.158 50002 typ relay a=candidate:R9ee41867 2 UDP 16777214 103.24.228.158 50003 typ relay a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx raddr 192[|sip] 22:20:21.023735 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 32) 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 \0x00\0x00\0x00[|sip] 22:20:21.023768 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 32) 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 \0x00\0x00\0x00[|sip] 22:20:22.641553 IP (tos 0x10, ttl 64, id 55681, offset 0, flags [+], proto UDP (17), length 1500) 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 INVITE sip:test2 at 192.168.1.3:5080 SIP/2.0 Record-Route: Via: SIP/2.0/UDP 103.24.228.158:5060;branch=z9hG4bK57b9.3415f0e2.0 Via: SIP/2.0/UDP 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 From: ;tag=OGCx7gRon To: sip:test2 at 103.24.228.158 CSeq: 20 INVITE Call-ID: xHqVFVS-lk Max-Forwards: 69 Supported: outbound Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE Content-Type: application/sdp Content-Length: 872 Contact: ;+sip.instance="" User-Agent: Linphonec/3.7.0 (belle-sip/1.3.2) v=0 o=test1 1433 1939 IN IP4 192.168.1.3 s=Talk c=IN IP4 103.24.228.158 t=0 0 a=ice-pwd:84505b9d160c756b6b138ac5 a=ice-ufrag:5e5508d3 a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics m=audio 50002 RTP/AVP 111 110 0 8 101 c=IN IP4 103.24.228.158 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp:50003 a=candidate:R9ee41867 1 UDP 16777215 103.24.228.158 50002 typ relay a=candidate:R9ee41867 2 UDP 16777214 103.24.228.158 50003 typ relay a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx raddr 192.168[|sip] 22:20:22.641606 IP (tos 0x10, ttl 64, id 55682, offset 0, flags [+], proto UDP (17), length 1500) 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 INVITE sip:test2 at 124.193.138.210:6001 SIP/2.0 Record-Route: Via: SIP/2.0/UDP 103.24.228.158:5060;branch=z9hG4bK57b9.3415f0e2.1 Via: SIP/2.0/UDP 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 From: ;tag=OGCx7gRon To: sip:test2 at 103.24.228.158 CSeq: 20 INVITE Call-ID: xHqVFVS-lk Max-Forwards: 69 Supported: outbound Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE Content-Type: application/sdp Content-Length: 872 Contact: ;+sip.instance="" User-Agent: Linphonec/3.7.0 (belle-sip/1.3.2) v=0 o=test1 1433 1939 IN IP4 192.168.1.3 s=Talk c=IN IP4 103.24.228.158 t=0 0 a=ice-pwd:84505b9d160c756b6b138ac5 a=ice-ufrag:5e5508d3 a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics m=audio 50002 RTP/AVP 111 110 0 8 101 c=IN IP4 103.24.228.158 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp:50003 a=candidate:R9ee41867 1 UDP 16777215 103.24.228.158 50002 typ relay a=candidate:R9ee41867 2 UDP 16777214 103.24.228.158 50003 typ relay a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx raddr 192[|sip] 22:20:24.969168 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 378) 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 350 SIP/2.0 408 Request Timeout Via: SIP/2.0/UDP 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 From: ;tag=OGCx7gRon To: sip:test2 at 103.24.228.158;tag=d8bd1b57441363f641ce73441337eed0-1628 CSeq: 20 INVITE Call-ID: xHqVFVS-lk Server: OpenSIPS (1.11.2-tls (x86_64/linux)) Content-Length: 0 22:20:25.033860 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 32) 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 \0x00\0x00\0x00[|sip] 22:20:25.033896 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 32) 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 \0x00\0x00\0x00[|sip] 22:20:25.045036 IP (tos 0x0, ttl 48, id 24523, offset 0, flags [DF], proto UDP (17), length 416) 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 388 ACK sip:test2 at 103.24.228.158 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.3:5070;branch=z9hG4bK.FohJ-Pjji;rport Call-ID: xHqVFVS-lk From: ;tag=OGCx7gRon To: ;tag=d8bd1b57441363f641ce73441337eed0-1628 Contact: ;+sip.instance="" Max-Forwards: 70 CSeq: 20 ACK 22:20:26.129568 IP (tos 0x0, ttl 48, id 24524, offset 0, flags [DF], proto UDP (17), length 32) 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 4 22:20:32.049089 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 32) 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 \0x00\0x00\0x00[|sip] 22:20:32.049116 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 32) 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 \0x00\0x00\0x00[|sip] 22:20:36.057255 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 32) 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 \0x00\0x00\0x00[|sip] 22:20:36.057278 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 32) 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 \0x00\0x00\0x00[|sip] 22:20:36.139991 IP (tos 0x0, ttl 48, id 24526, offset 0, flags [DF], proto UDP (17), length 32) 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 4 22:20:43.071439 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 32) 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 \0x00\0x00\0x00[|sip] 22:20:43.071472 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 32) 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 \0x00\0x00\0x00[|sip] 22:20:44.220415 IP (tos 0x0, ttl 48, id 24527, offset 0, flags [DF], proto UDP (17), length 32) 124.193.138.210.6001 > 103.24.228.158.5060: SIP, length: 4 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aihuawu2012 at 163.com Wed Oct 15 16:44:17 2014 From: aihuawu2012 at 163.com (george wu) Date: Wed, 15 Oct 2014 22:44:17 +0800 (CST) Subject: [OpenSIPS-Users] udp or tcp for nat traversal? In-Reply-To: <7e23bdde.11c2b.1491438b5be.Coremail.aihuawu2012@163.com> References: <9f50cdb.2658d.1490f4e26ee.Coremail.aihuawu2012@163.com> <543D4DD6.1020405@opensips.org> <4dd40a9b.e54.14911311a6a.Coremail.aihuawu2012@163.com> <543E1E7C.4070407@opensips.org> <46185c1e.103bc.14913b36612.Coremail.aihuawu2012@163.com> <543E6C8A.6000802@opensips.org> <7e23bdde.11c2b.1491438b5be.Coremail.aihuawu2012@163.com> Message-ID: Hi, Bogdan: Is this a bug? When the server relay invite message to the callee in the last line: a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx raddr 192.168[|sip] At 2014-10-15 22:31:41, "george wu" wrote: Hi, Bogdan: The following is the tcpdump with mediaproxy on. I can't see any problem. That means it is linphone problem which can't understand ice? Actually as I said before, if I use tcp/tls, ice actually works on linphone. What should I do more to test it? George Wu /// part 1 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 1291 INVITE sip:test2 at 103.24.228.158 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.3:5070;branch=z9hG4bK.FohJ-Pjji;rport From: ;tag=OGCx7gRon To: sip:test2 at 103.24.228.158 CSeq: 20 INVITE Call-ID: xHqVFVS-lk Max-Forwards: 70 Supported: outbound Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE Content-Type: application/sdp Content-Length: 730 Contact: ;+sip.instance="" User-Agent: Linphonec/3.7.0 (belle-sip/1.3.2) v=0 o=test1 1433 1939 IN IP4 192.168.1.3 s=Talk c=IN IP4 192.168.1.3 t=0 0 a=ice-pwd:84505b9d160c756b6b138ac5 a=ice-ufrag:5e5508d3 a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics m=audio 5909 RTP/AVP 111 110 0 8 101 c=IN IP4 124.193.138.210 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp:5060 a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx raddr 192.168.1.3 rport 7079 a=candidate:2 1 UDP 1694498815 124.193.138.210 5909 typ srflx raddr 192.168.1.3 rport 7078 22:20:18.692288 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 333) 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 305 SIP/2.0 100 Giving a try Via: SIP/2.0/UDP 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 From: ;tag=OGCx7gRon To: sip:test2 at 103.24.228.158 CSeq: 20 INVITE Call-ID: xHqVFVS-lk Server: OpenSIPS (1.11.2-tls (x86_64/linux)) Content-Length: 0 22:20:18.692464 IP (tos 0x10, ttl 64, id 55675, offset 0, flags [+], proto UDP (17), length 1500) 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 INVITE sip:test2 at 192.168.1.3:5080 SIP/2.0 Record-Route: Via: SIP/2.0/UDP 103.24.228.158:5060;branch=z9hG4bK57b9.3415f0e2.0 Via: SIP/2.0/UDP 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 From: ;tag=OGCx7gRon To: sip:test2 at 103.24.228.158 CSeq: 20 INVITE Call-ID: xHqVFVS-lk Max-Forwards: 69 Supported: outbound Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE Content-Type: application/sdp Content-Length: 872 Contact: ;+sip.instance="" User-Agent: Linphonec/3.7.0 (belle-sip/1.3.2) v=0 o=test1 1433 1939 IN IP4 192.168.1.3 s=Talk c=IN IP4 103.24.228.158 t=0 0 a=ice-pwd:84505b9d160c756b6b138ac5 a=ice-ufrag:5e5508d3 a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics m=audio 50002 RTP/AVP 111 110 0 8 101 c=IN IP4 103.24.228.158 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp:50003 a=candidate:R9ee41867 1 UDP 16777215 103.24.228.158 50002 typ relay a=candidate:R9ee41867 2 UDP 16777214 103.24.228.158 50003 typ relay a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx raddr 192.168[|sip] 22:20:18.692499 IP (tos 0x10, ttl 64, id 55676, offset 0, flags [+], proto UDP (17), length 1500) 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 INVITE sip:test2 at 124.193.138.210:6001 SIP/2.0 Record-Route: Via: SIP/2.0/UDP 103.24.228.158:5060;branch=z9hG4bK57b9.3415f0e2.1 Via: SIP/2.0/UDP 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 From: ;tag=OGCx7gRon To: sip:test2 at 103.24.228.158 CSeq: 20 INVITE Call-ID: xHqVFVS-lk Max-Forwards: 69 Supported: outbound Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE Content-Type: application/sdp Content-Length: 872 Contact: ;+sip.instance="" User-Agent: Linphonec/3.7.0 (belle-sip/1.3.2) v=0 o=test1 1433 1939 IN IP4 192.168.1.3 s=Talk c=IN IP4 103.24.228.158 t=0 0 a=ice-pwd:84505b9d160c756b6b138ac5 a=ice-ufrag:5e5508d3 a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics m=audio 50002 RTP/AVP 111 110 0 8 101 c=IN IP4 103.24.228.158 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp:50003 a=candidate:R9ee41867 1 UDP 16777215 103.24.228.158 50002 typ relay a=candidate:R9ee41867 2 UDP 16777214 103.24.228.158 50003 typ relay a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx raddr 192[|sip] 22:20:19.301123 IP (tos 0x10, ttl 64, id 55677, offset 0, flags [+], proto UDP (17), length 1500) 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 INVITE sip:test2 at 192.168.1.3:5080 SIP/2.0 Record-Route: Via: SIP/2.0/UDP 103.24.228.158:5060;branch=z9hG4bK57b9.3415f0e2.0 Via: SIP/2.0/UDP 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 From: ;tag=OGCx7gRon To: sip:test2 at 103.24.228.158 CSeq: 20 INVITE Call-ID: xHqVFVS-lk Max-Forwards: 69 Supported: outbound Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE Content-Type: application/sdp Content-Length: 872 Contact: ;+sip.instance="" User-Agent: Linphonec/3.7.0 (belle-sip/1.3.2) v=0 o=test1 1433 1939 IN IP4 192.168.1.3 s=Talk c=IN IP4 103.24.228.158 t=0 0 a=ice-pwd:84505b9d160c756b6b138ac5 a=ice-ufrag:5e5508d3 a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics m=audio 50002 RTP/AVP 111 110 0 8 101 c=IN IP4 103.24.228.158 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp:50003 a=candidate:R9ee41867 1 UDP 16777215 103.24.228.158 50002 typ relay a=candidate:R9ee41867 2 UDP 16777214 103.24.228.158 50003 typ relay a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx raddr 192.168[|sip] 22:20:19.301208 IP (tos 0x10, ttl 64, id 55678, offset 0, flags [+], proto UDP (17), length 1500) 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 INVITE sip:test2 at 124.193.138.210:6001 SIP/2.0 Record-Route: Via: SIP/2.0/UDP 103.24.228.158:5060;branch=z9hG4bK57b9.3415f0e2.1 Via: SIP/2.0/UDP 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 From: ;tag=OGCx7gRon To: sip:test2 at 103.24.228.158 CSeq: 20 INVITE Call-ID: xHqVFVS-lk Max-Forwards: 69 Supported: outbound Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE Content-Type: application/sdp Content-Length: 872 Contact: ;+sip.instance="" User-Agent: Linphonec/3.7.0 (belle-sip/1.3.2) v=0 o=test1 1433 1939 IN IP4 192.168.1.3 s=Talk c=IN IP4 103.24.228.158 t=0 0 a=ice-pwd:84505b9d160c756b6b138ac5 a=ice-ufrag:5e5508d3 a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics m=audio 50002 RTP/AVP 111 110 0 8 101 c=IN IP4 103.24.228.158 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp:50003 a=candidate:R9ee41867 1 UDP 16777215 103.24.228.158 50002 typ relay a=candidate:R9ee41867 2 UDP 16777214 103.24.228.158 50003 typ relay a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx raddr 192[|sip] 22:20:20.413939 IP (tos 0x10, ttl 64, id 55679, offset 0, flags [+], proto UDP (17), length 1500) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Oct 15 16:44:37 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 15 Oct 2014 17:44:37 +0300 Subject: [OpenSIPS-Users] OpenSIPS Las Vegas Summit - Speakers & Workshops - part 3 Message-ID: <543E8855.5040304@opensips.org> *On October 21st, 2014, Las Vegas will be the the "OpenSIPS" city!* *Pete Kelly - **Sourcevox - */"//Solving Business Problems with OpenSIPs: Least Cost Routing"/ ? In addition to standard modules, OpenSIPS comes with a powerful "Turing complete" scripting language which truly allows you to do some remarkable things when routing a simple SIP request. ? In this example Least Cost Routing is explored. Using the OpenSIPS modules and scripting language, this presentation explores how a business definition of Least Cost Routing can be easily achieved with a combination of OpenSIPS modules and the scripting language. *Ali Pey ***- ****Sr. Software Engineer Architect J2 *- */"o//pensips.cfg//"/ ? This is to review best practices for OpenSIPS deployment, configuration and scripting. No matter if you are an OpenSIPS beginner or an expert, this will be a chance to ask questions and/or share your experiences as there are some OpenSIPS experts and core developers all in the same room. ? I will walk through opensips.cfg and basic principles of using a proxy server. Will discuss best practices for Network design, redundancy, NAT and OpenSIPS configuration. And more speakers and even more topics to follow. See http://www.opensips.org/Community/Summit-2014LasVegas-Schedule To *register for the event*, see http://www.opensips.org/Community/Summit-Registration Participating the Astricon? Use the "astricon2014" discount code ;). See you in Vegas, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Oct 15 16:50:43 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 15 Oct 2014 17:50:43 +0300 Subject: [OpenSIPS-Users] udp or tcp for nat traversal? In-Reply-To: <19a5f1b5.11c47.14914396a05.Coremail.aihuawu2012@163.com> References: <9f50cdb.2658d.1490f4e26ee.Coremail.aihuawu2012@163.com> <543D4DD6.1020405@opensips.org> <4dd40a9b.e54.14911311a6a.Coremail.aihuawu2012@163.com> <543E1E7C.4070407@opensips.org> <46185c1e.103bc.14913b36612.Coremail.aihuawu2012@163.com> <543E6C8A.6000802@opensips.org> <19a5f1b5.11c47.14914396a05.Coremail.aihuawu2012@163.com> Message-ID: <543E89C3.5030401@opensips.org> The trace definitely shows linphone not answering to the INVITE handled via mediaproxy (INVITE goes to linphone but nothing back). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 15.10.2014 17:32, george wu wrote: > //part 2 > > > 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 > INVITE sip:test2 at 192.168.1.3:5080 SIP/2.0 > Record-Route: > Via: SIP/2.0/UDP 103.24.228.158:5060;branch=z9hG4bK57b9.3415f0e2.0 > Via: SIP/2.0/UDP > 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 > From: ;tag=OGCx7gRon > To: sip:test2 at 103.24.228.158 > CSeq: 20 INVITE > Call-ID: xHqVFVS-lk > Max-Forwards: 69 > Supported: outbound > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, > SUBSCRIBE, INFO, UPDATE > Content-Type: application/sdp > Content-Length: 872 > Contact: > ;+sip.instance="" > User-Agent: Linphonec/3.7.0 (belle-sip/1.3.2) > > v=0 > o=test1 1433 1939 IN IP4 192.168.1.3 > s=Talk > c=IN IP4 103.24.228.158 > t=0 0 > a=ice-pwd:84505b9d160c756b6b138ac5 > a=ice-ufrag:5e5508d3 > a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL > voip-metrics > m=audio 50002 RTP/AVP 111 110 0 8 101 > c=IN IP4 103.24.228.158 > a=rtpmap:111 speex/16000 > a=fmtp:111 vbr=on > a=rtpmap:110 speex/8000 > a=fmtp:110 vbr=on > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=rtcp:50003 > a=candidate:R9ee41867 1 UDP 16777215 103.24.228.158 50002 typ relay > a=candidate:R9ee41867 2 UDP 16777214 103.24.228.158 50003 typ relay > a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host > a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host > a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx > raddr 192.168[|sip] > 22:20:20.414018 IP (tos 0x10, ttl 64, id 55680, offset 0, flags [+], > proto UDP (17), length 1500) > 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 > INVITE sip:test2 at 124.193.138.210:6001 SIP/2.0 > Record-Route: > Via: SIP/2.0/UDP 103.24.228.158:5060;branch=z9hG4bK57b9.3415f0e2.1 > Via: SIP/2.0/UDP > 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 > From: ;tag=OGCx7gRon > To: sip:test2 at 103.24.228.158 > CSeq: 20 INVITE > Call-ID: xHqVFVS-lk > Max-Forwards: 69 > Supported: outbound > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, > SUBSCRIBE, INFO, UPDATE > Content-Type: application/sdp > Content-Length: 872 > Contact: > ;+sip.instance="" > User-Agent: Linphonec/3.7.0 (belle-sip/1.3.2) > > v=0 > o=test1 1433 1939 IN IP4 192.168.1.3 > s=Talk > c=IN IP4 103.24.228.158 > t=0 0 > a=ice-pwd:84505b9d160c756b6b138ac5 > a=ice-ufrag:5e5508d3 > a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL > voip-metrics > m=audio 50002 RTP/AVP 111 110 0 8 101 > c=IN IP4 103.24.228.158 > a=rtpmap:111 speex/16000 > a=fmtp:111 vbr=on > a=rtpmap:110 speex/8000 > a=fmtp:110 vbr=on > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=rtcp:50003 > a=candidate:R9ee41867 1 UDP 16777215 103.24.228.158 50002 typ relay > a=candidate:R9ee41867 2 UDP 16777214 103.24.228.158 50003 typ relay > a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host > a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host > a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx > raddr 192[|sip] > 22:20:21.023735 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], > proto UDP (17), length 32) > 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 > \0x00\0x00\0x00[|sip] > 22:20:21.023768 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], > proto UDP (17), length 32) > 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 > \0x00\0x00\0x00[|sip] > 22:20:22.641553 IP (tos 0x10, ttl 64, id 55681, offset 0, flags [+], > proto UDP (17), length 1500) > 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 > INVITE sip:test2 at 192.168.1.3:5080 SIP/2.0 > Record-Route: > Via: SIP/2.0/UDP 103.24.228.158:5060;branch=z9hG4bK57b9.3415f0e2.0 > Via: SIP/2.0/UDP > 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 > From: ;tag=OGCx7gRon > To: sip:test2 at 103.24.228.158 > CSeq: 20 INVITE > Call-ID: xHqVFVS-lk > Max-Forwards: 69 > Supported: outbound > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, > SUBSCRIBE, INFO, UPDATE > Content-Type: application/sdp > Content-Length: 872 > Contact: > ;+sip.instance="" > User-Agent: Linphonec/3.7.0 (belle-sip/1.3.2) > > v=0 > o=test1 1433 1939 IN IP4 192.168.1.3 > s=Talk > c=IN IP4 103.24.228.158 > t=0 0 > a=ice-pwd:84505b9d160c756b6b138ac5 > a=ice-ufrag:5e5508d3 > a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL > voip-metrics > m=audio 50002 RTP/AVP 111 110 0 8 101 > c=IN IP4 103.24.228.158 > a=rtpmap:111 speex/16000 > a=fmtp:111 vbr=on > a=rtpmap:110 speex/8000 > a=fmtp:110 vbr=on > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=rtcp:50003 > a=candidate:R9ee41867 1 UDP 16777215 103.24.228.158 50002 typ relay > a=candidate:R9ee41867 2 UDP 16777214 103.24.228.158 50003 typ relay > a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host > a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host > a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx > raddr 192.168[|sip] > 22:20:22.641606 IP (tos 0x10, ttl 64, id 55682, offset 0, flags [+], > proto UDP (17), length 1500) > 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 > INVITE sip:test2 at 124.193.138.210:6001 SIP/2.0 > Record-Route: > Via: SIP/2.0/UDP 103.24.228.158:5060;branch=z9hG4bK57b9.3415f0e2.1 > Via: SIP/2.0/UDP > 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 > From: ;tag=OGCx7gRon > To: sip:test2 at 103.24.228.158 > CSeq: 20 INVITE > Call-ID: xHqVFVS-lk > Max-Forwards: 69 > Supported: outbound > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, > SUBSCRIBE, INFO, UPDATE > Content-Type: application/sdp > Content-Length: 872 > Contact: > ;+sip.instance="" > User-Agent: Linphonec/3.7.0 (belle-sip/1.3.2) > > v=0 > o=test1 1433 1939 IN IP4 192.168.1.3 > s=Talk > c=IN IP4 103.24.228.158 > t=0 0 > a=ice-pwd:84505b9d160c756b6b138ac5 > a=ice-ufrag:5e5508d3 > a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL > voip-metrics > m=audio 50002 RTP/AVP 111 110 0 8 101 > c=IN IP4 103.24.228.158 > a=rtpmap:111 speex/16000 > a=fmtp:111 vbr=on > a=rtpmap:110 speex/8000 > a=fmtp:110 vbr=on > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=rtcp:50003 > a=candidate:R9ee41867 1 UDP 16777215 103.24.228.158 50002 typ relay > a=candidate:R9ee41867 2 UDP 16777214 103.24.228.158 50003 typ relay > a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host > a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host > a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx > raddr 192[|sip] > 22:20:24.969168 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], > proto UDP (17), length 378) > 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 350 > SIP/2.0 408 Request Timeout > Via: SIP/2.0/UDP > 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 > From: ;tag=OGCx7gRon > To: sip:test2 at 103.24.228.158;tag=d8bd1b57441363f641ce73441337eed0-1628 > CSeq: 20 INVITE > Call-ID: xHqVFVS-lk > Server: OpenSIPS (1.11.2-tls (x86_64/linux)) > Content-Length: 0 > > > 22:20:25.033860 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], > proto UDP (17), length 32) > 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 > \0x00\0x00\0x00[|sip] > 22:20:25.033896 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], > proto UDP (17), length 32) > 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 > \0x00\0x00\0x00[|sip] > 22:20:25.045036 IP (tos 0x0, ttl 48, id 24523, offset 0, flags [DF], > proto UDP (17), length 416) > 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 388 > ACK sip:test2 at 103.24.228.158 SIP/2.0 > Via: SIP/2.0/UDP 192.168.1.3:5070;branch=z9hG4bK.FohJ-Pjji;rport > Call-ID: xHqVFVS-lk > From: ;tag=OGCx7gRon > To: > ;tag=d8bd1b57441363f641ce73441337eed0-1628 > Contact: > ;+sip.instance="" > Max-Forwards: 70 > CSeq: 20 ACK > > > 22:20:26.129568 IP (tos 0x0, ttl 48, id 24524, offset 0, flags [DF], > proto UDP (17), length 32) > 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 4 > > > > 22:20:32.049089 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], > proto UDP (17), length 32) > 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 > \0x00\0x00\0x00[|sip] > 22:20:32.049116 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], > proto UDP (17), length 32) > 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 > \0x00\0x00\0x00[|sip] > 22:20:36.057255 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], > proto UDP (17), length 32) > 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 > \0x00\0x00\0x00[|sip] > 22:20:36.057278 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], > proto UDP (17), length 32) > 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 > \0x00\0x00\0x00[|sip] > 22:20:36.139991 IP (tos 0x0, ttl 48, id 24526, offset 0, flags [DF], > proto UDP (17), length 32) > 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 4 > > > > 22:20:43.071439 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], > proto UDP (17), length 32) > 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 > \0x00\0x00\0x00[|sip] > 22:20:43.071472 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], > proto UDP (17), length 32) > 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 > \0x00\0x00\0x00[|sip] > 22:20:44.220415 IP (tos 0x0, ttl 48, id 24527, offset 0, flags [DF], > proto UDP (17), length 32) > 124.193.138.210.6001 > 103.24.228.158.5060: SIP, length: 4 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Wed Oct 15 17:04:13 2014 From: satish.txt at gmail.com (Satish Patel) Date: Wed, 15 Oct 2014 11:04:13 -0400 Subject: [OpenSIPS-Users] dispatcher not doing fail over itself In-Reply-To: <54351074.5060405@opensips.org> References: <5417E3E4.3020000@opensips.org> <5418640B.2050105@opensips.org> <54193884.2060801@opensips.org> <541999F2.7090705@opensips.org> <541BE96E.9080403@opensips.org> <20D5493C-5039-464D-B3BC-CDA798336311@gmail.com> <54351074.5060405@opensips.org> Message-ID: Great!!! After putting "FM10" now it working! what the hack is FM10? On Wed, Oct 8, 2014 at 6:22 AM, Bogdan-Andrei Iancu wrote: > Hi Satish, > > Could you add as extra flag to ds_select_xxx() the "M10" ? That will make > the overall flags string "FM10". > > Try with that flags and let me know. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > On 20.09.2014 15:18, Satish Patel wrote: > > Hey any clue? I'm using 1.12 version. > > -- > Sent from my iPhone > > On Sep 19, 2014, at 4:29 AM, Bogdan-Andrei Iancu > wrote: > > dst is null as there is no pending destination for failover. cnt is 1. > > Which OpenSIPS revision are you using ? > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > On 17.09.2014 19:04, Satish Patel wrote: > > I just trying to print $avp(271) $avp(272) and $avp(273) > > I am getting following output, why dst_avp is null ? and cnt_avp should > be 2 right? > > dst_avp = > grp_avp = 1 > cnt_avp = 0 > > Notes: I have both Freeswitch instance running on same box but different > port, do you think because of that it think it is single host? > > PARTITION:: default > SET:: 1 > URI:: sip:sip.example.com:5061 state=Active > URI:: sip:sip.example.com:5071 state=Active > > > On Wed, Sep 17, 2014 at 11:06 AM, Satish Patel > wrote: > >> Here you go >> >> >> >> >> /sbin/opensips[28000]: Sending call to ===> Freeswitch >> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: p=0x7f9ed01dd420, >> flags=0x0000 >> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: #011#011#011name=<274> >> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: #011#011#011id=<10> >> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: #011#011#011val_int=<0> >> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: p=0x7f9ed01df208, >> flags=0x0000 >> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: #011#011#011name=<273> >> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: #011#011#011id=<9> >> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: #011#011#011val_int=<1> >> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: p=0x7f9ed01e6518, >> flags=0x0002 >> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: #011#011#011name=<272> >> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: #011#011#011id=<12> >> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: #011#011#011val_str=< >> / 0> >> /sbin/opensips[28000]: dispatcher: Attempting to dispatch call to >> sip:182.xx.xx.xxx:5071 >> /sbin/opensips[28005]: Inside dispatcher failure route >> /sbin/opensips[28005]: ds_dispatcher > >> /sbin/opensips[28005]: R-DISPATCHER-ROLLOVER:fU4SNHMvcNmnjW19gsSj0g..-S >> No more gateways in route set >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Oct 15 17:36:24 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 15 Oct 2014 18:36:24 +0300 Subject: [OpenSIPS-Users] dispatcher not doing fail over itself In-Reply-To: References: <5417E3E4.3020000@opensips.org> <5418640B.2050105@opensips.org> <54193884.2060801@opensips.org> <541999F2.7090705@opensips.org> <541BE96E.9080403@opensips.org> <20D5493C-5039-464D-B3BC-CDA798336311@gmail.com> <54351074.5060405@opensips.org> Message-ID: <543E9478.5010702@opensips.org> Hi Satish, In devel branch, there was an error on handling the default value for returned value. The M10 (explicitly setting the limit to 10) is a hack, it has to work without it. This error was fixed in the mean while on GIT, see : https://github.com/OpenSIPS/opensips/pull/357 So, if you update from GIT, it should work even without M10 flag. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 15.10.2014 18:04, Satish Patel wrote: > Great!!! > > After putting "FM10" now it working! what the hack is FM10? > > > > On Wed, Oct 8, 2014 at 6:22 AM, Bogdan-Andrei Iancu > > wrote: > > Hi Satish, > > Could you add as extra flag to ds_select_xxx() the "M10" ? That > will make the overall flags string "FM10". > > Try with that flags and let me know. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 20.09.2014 15:18, Satish Patel wrote: >> Hey any clue? I'm using 1.12 version. >> >> -- >> Sent from my iPhone >> >> On Sep 19, 2014, at 4:29 AM, Bogdan-Andrei Iancu >> > wrote: >> >>> dst is null as there is no pending destination for failover. cnt >>> is 1. >>> >>> Which OpenSIPS revision are you using ? >>> >>> Regards, >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> On 17.09.2014 19:04, Satish Patel wrote: >>>> I just trying to print $avp(271) $avp(272) and $avp(273) >>>> >>>> I am getting following output, why dst_avp is null ? and >>>> cnt_avp should be 2 right? >>>> >>>> dst_avp = >>>> grp_avp = 1 >>>> cnt_avp = 0 >>>> >>>> Notes: I have both Freeswitch instance running on same box but >>>> different port, do you think because of that it think it is >>>> single host? >>>> >>>> PARTITION:: default >>>> SET:: 1 >>>> URI:: sip:sip.example.com:5061 >>>> state=Active >>>> URI:: sip:sip.example.com:5071 >>>> state=Active >>>> >>>> >>>> On Wed, Sep 17, 2014 at 11:06 AM, Satish Patel >>>> > wrote: >>>> >>>> Here you go >>>> >>>> >>>> >>>> >>>> /sbin/opensips[28000]: Sending call to ===> Freeswitch >>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>> p=0x7f9ed01dd420, flags=0x0000 >>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>> #011#011#011name=<274> >>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>> #011#011#011id=<10> >>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>> #011#011#011val_int=<0> >>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>> p=0x7f9ed01df208, flags=0x0000 >>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>> #011#011#011name=<273> >>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>> #011#011#011id=<9> >>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>> #011#011#011val_int=<1> >>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>> p=0x7f9ed01e6518, flags=0x0002 >>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>> #011#011#011name=<272> >>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>> #011#011#011id=<12> >>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>> #011#011#011val_str=< / 0> >>>> /sbin/opensips[28000]: dispatcher: Attempting to dispatch >>>> call to sip:182.xx.xx.xxx:5071 >>>> /sbin/opensips[28005]: Inside dispatcher failure route >>>> /sbin/opensips[28005]: ds_dispatcher > >>>> /sbin/opensips[28005]: >>>> R-DISPATCHER-ROLLOVER:fU4SNHMvcNmnjW19gsSj0g..-S No more >>>> gateways in route set >>>> >>>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Oct 15 17:44:08 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 15 Oct 2014 18:44:08 +0300 Subject: [OpenSIPS-Users] ISUP and SIP-I with Opensips In-Reply-To: <0A23E00A41AF4B579F40594C322AD071@imidomain.com> References: <5438D555.90906@ptcomm.ru> <543B7B52.2050101@opensips.org> <543B8B15.7070800@ptcomm.ru> <0A23E00A41AF4B579F40594C322AD071@imidomain.com> Message-ID: <543E9648.6020005@opensips.org> Hi, First, please use separate email threads for separate topics . Now, going back to your question - take a look at the dispatcher module: http://www.opensips.org/html/docs/modules/1.11.x/dispatcher.html Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 13.10.2014 12:07, Sandeep Sharma wrote: > Hi Bodgan > > I want to distribute call in round robin fashion through opensips > platform & below mentioned are setup:- > > 1.outgoing call voice app --> Opensips platform --> incoming call > voice app1 > --> incoming call voice app2 > --> incoming call voice app3 > > 1st call should land on app1, 2nd call on app2, 3rd call on app3 and > 4th call onward again it should land on app1, app2 & app3 platform. > > > Thanks, > Sandeep > From bogdan at opensips.org Wed Oct 15 17:45:33 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 15 Oct 2014 18:45:33 +0300 Subject: [OpenSIPS-Users] ISUP and SIP-I with Opensips In-Reply-To: <543B8B15.7070800@ptcomm.ru> References: <5438D555.90906@ptcomm.ru> <543B7B52.2050101@opensips.org> <543B8B15.7070800@ptcomm.ru> Message-ID: <543E969D.7020004@opensips.org> Hi, OpenSIPS is not ISUP aware. But if you have the ISUP payload, you can encapsulate it and make OpenSIPS to send a generic SIP request with the ISUP payload. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 13.10.2014 11:19, ?????? ????? ?????????? wrote: > Well, may be he Opensips endpoint? And generate ISUP messages messages? > > 13.10.2014 11:12, Bogdan-Andrei Iancu ?????: >> SIP-I and SIP-T are extensions of SIP - and they are transparent for >> a SIP proxy. So OpenSIPS can route SIP-I and SIP-T. What is important >> is to have end-points which do understand these extensions. > > From aihuawu2012 at 163.com Wed Oct 15 18:33:25 2014 From: aihuawu2012 at 163.com (george wu) Date: Thu, 16 Oct 2014 00:33:25 +0800 (CST) Subject: [OpenSIPS-Users] udp or tcp for nat traversal? In-Reply-To: <543E89C3.5030401@opensips.org> References: <9f50cdb.2658d.1490f4e26ee.Coremail.aihuawu2012@163.com> <543D4DD6.1020405@opensips.org> <4dd40a9b.e54.14911311a6a.Coremail.aihuawu2012@163.com> <543E1E7C.4070407@opensips.org> <46185c1e.103bc.14913b36612.Coremail.aihuawu2012@163.com> <543E6C8A.6000802@opensips.org> <19a5f1b5.11c47.14914396a05.Coremail.aihuawu2012@163.com> <543E89C3.5030401@opensips.org> Message-ID: <1e45a505.12847.14914a82b85.Coremail.aihuawu2012@163.com> Is it because the packet MTU is too big? It can't handle size bigger than 1472 bytes? The last line looks strange to me. a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx raddr 192.168[|sip] At 2014-10-15 22:50:43, "Bogdan-Andrei Iancu" wrote: The trace definitely shows linphone not answering to the INVITE handled via mediaproxy (INVITE goes to linphone but nothing back). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 15.10.2014 17:32, george wu wrote: //part 2 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 INVITE sip:test2 at 192.168.1.3:5080 SIP/2.0 Record-Route: Via: SIP/2.0/UDP 103.24.228.158:5060;branch=z9hG4bK57b9.3415f0e2.0 Via: SIP/2.0/UDP 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 From: ;tag=OGCx7gRon To: sip:test2 at 103.24.228.158 CSeq: 20 INVITE Call-ID: xHqVFVS-lk Max-Forwards: 69 Supported: outbound Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE Content-Type: application/sdp Content-Length: 872 Contact: ;+sip.instance="" User-Agent: Linphonec/3.7.0 (belle-sip/1.3.2) v=0 o=test1 1433 1939 IN IP4 192.168.1.3 s=Talk c=IN IP4 103.24.228.158 t=0 0 a=ice-pwd:84505b9d160c756b6b138ac5 a=ice-ufrag:5e5508d3 a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics m=audio 50002 RTP/AVP 111 110 0 8 101 c=IN IP4 103.24.228.158 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp:50003 a=candidate:R9ee41867 1 UDP 16777215 103.24.228.158 50002 typ relay a=candidate:R9ee41867 2 UDP 16777214 103.24.228.158 50003 typ relay a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx raddr 192.168[|sip] 22:20:20.414018 IP (tos 0x10, ttl 64, id 55680, offset 0, flags [+], proto UDP (17), length 1500) 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 INVITE sip:test2 at 124.193.138.210:6001 SIP/2.0 Record-Route: Via: SIP/2.0/UDP 103.24.228.158:5060;branch=z9hG4bK57b9.3415f0e2.1 Via: SIP/2.0/UDP 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 From: ;tag=OGCx7gRon To: sip:test2 at 103.24.228.158 CSeq: 20 INVITE Call-ID: xHqVFVS-lk Max-Forwards: 69 Supported: outbound Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE Content-Type: application/sdp Content-Length: 872 Contact: ;+sip.instance="" User-Agent: Linphonec/3.7.0 (belle-sip/1.3.2) v=0 o=test1 1433 1939 IN IP4 192.168.1.3 s=Talk c=IN IP4 103.24.228.158 t=0 0 a=ice-pwd:84505b9d160c756b6b138ac5 a=ice-ufrag:5e5508d3 a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics m=audio 50002 RTP/AVP 111 110 0 8 101 c=IN IP4 103.24.228.158 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp:50003 a=candidate:R9ee41867 1 UDP 16777215 103.24.228.158 50002 typ relay a=candidate:R9ee41867 2 UDP 16777214 103.24.228.158 50003 typ relay a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx raddr 192[|sip] 22:20:21.023735 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 32) 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 \0x00\0x00\0x00[|sip] 22:20:21.023768 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 32) 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 4 \0x00\0x00\0x00[|sip] 22:20:22.641553 IP (tos 0x10, ttl 64, id 55681, offset 0, flags [+], proto UDP (17), length 1500) 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 INVITE sip:test2 at 192.168.1.3:5080 SIP/2.0 Record-Route: Via: SIP/2.0/UDP 103.24.228.158:5060;branch=z9hG4bK57b9.3415f0e2.0 Via: SIP/2.0/UDP 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 From: ;tag=OGCx7gRon To: sip:test2 at 103.24.228.158 CSeq: 20 INVITE Call-ID: xHqVFVS-lk Max-Forwards: 69 Supported: outbound Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE Content-Type: application/sdp Content-Length: 872 Contact: ;+sip.instance="" User-Agent: Linphonec/3.7.0 (belle-sip/1.3.2) v=0 o=test1 1433 1939 IN IP4 192.168.1.3 s=Talk c=IN IP4 103.24.228.158 t=0 0 a=ice-pwd:84505b9d160c756b6b138ac5 a=ice-ufrag:5e5508d3 a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics m=audio 50002 RTP/AVP 111 110 0 8 101 c=IN IP4 103.24.228.158 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp:50003 a=candidate:R9ee41867 1 UDP 16777215 103.24.228.158 50002 typ relay a=candidate:R9ee41867 2 UDP 16777214 103.24.228.158 50003 typ relay a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx raddr 192.168[|sip] 22:20:22.641606 IP (tos 0x10, ttl 64, id 55682, offset 0, flags [+], proto UDP (17), length 1500) 103.24.228.158.5060 > 124.193.138.210.6001: SIP, length: 1472 INVITE sip:test2 at 124.193.138.210:6001 SIP/2.0 Record-Route: Via: SIP/2.0/UDP 103.24.228.158:5060;branch=z9hG4bK57b9.3415f0e2.1 Via: SIP/2.0/UDP 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 From: ;tag=OGCx7gRon To: sip:test2 at 103.24.228.158 CSeq: 20 INVITE Call-ID: xHqVFVS-lk Max-Forwards: 69 Supported: outbound Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE Content-Type: application/sdp Content-Length: 872 Contact: ;+sip.instance="" User-Agent: Linphonec/3.7.0 (belle-sip/1.3.2) v=0 o=test1 1433 1939 IN IP4 192.168.1.3 s=Talk c=IN IP4 103.24.228.158 t=0 0 a=ice-pwd:84505b9d160c756b6b138ac5 a=ice-ufrag:5e5508d3 a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics m=audio 50002 RTP/AVP 111 110 0 8 101 c=IN IP4 103.24.228.158 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp:50003 a=candidate:R9ee41867 1 UDP 16777215 103.24.228.158 50002 typ relay a=candidate:R9ee41867 2 UDP 16777214 103.24.228.158 50003 typ relay a=candidate:1 1 UDP 2130706431 192.168.1.3 7078 typ host a=candidate:1 2 UDP 2130706430 192.168.1.3 7079 typ host a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx raddr 192[|sip] 22:20:24.969168 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 378) 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 350 SIP/2.0 408 Request Timeout Via: SIP/2.0/UDP 192.168.1.3:5070;received=124.193.138.210;branch=z9hG4bK.FohJ-Pjji;rport=5758 From: ;tag=OGCx7gRon To: sip:test2 at 103.24.228.158;tag=d8bd1b57441363f641ce73441337eed0-1628 CSeq: 20 INVITE Call-ID: xHqVFVS-lk Server: OpenSIPS (1.11.2-tls (x86_64/linux)) Content-Length: 0 22:20:25.033860 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 32) 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 \0x00\0x00\0x00[|sip] 22:20:25.033896 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 32) 103.24.228.158.5060 > 124.193.138.210.5758: SIP, length: 4 \0x00\0x00\0x00[|sip] 22:20:25.045036 IP (tos 0x0, ttl 48, id 24523, offset 0, flags [DF], proto UDP (17), length 416) 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 388 ACK sip:test2 at 103.24.228.158 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.3:5070;branch=z9hG4bK.FohJ-Pjji;rport Call-ID: xHqVFVS-lk From: ;tag=OGCx7gRon To: ;tag=d8bd1b57441363f641ce73441337eed0-1628 Contact: ;+sip.instance="" Max-Forwards: 70 CSeq: 20 ACK 22:20:26.129568 IP (tos 0x0, ttl 48, id 24524, offset 0, flags [DF], proto UDP (17), length 32) 124.193.138.210.5758 > 103.24.228.158.5060: SIP, length: 4 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Oct 15 18:48:36 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 15 Oct 2014 19:48:36 +0300 Subject: [OpenSIPS-Users] dispatcher not doing fail over itself In-Reply-To: References: <5417E3E4.3020000@opensips.org> <5418640B.2050105@opensips.org> <54193884.2060801@opensips.org> <541999F2.7090705@opensips.org> <541BE96E.9080403@opensips.org> <20D5493C-5039-464D-B3BC-CDA798336311@gmail.com> <54351074.5060405@opensips.org> <543E9478.5010702@opensips.org> Message-ID: <543EA564.9050807@opensips.org> I wouldn't recommended as the trunk GIT branch is the development one, so , by definition, not stable. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 15.10.2014 19:46, Satish Patel wrote: > can i use this GIT branch in production? > > On Wed, Oct 15, 2014 at 11:36 AM, Bogdan-Andrei Iancu > > wrote: > > Hi Satish, > > In devel branch, there was an error on handling the default value > for returned value. The M10 (explicitly setting the limit to 10) > is a hack, it has to work without it. > This error was fixed in the mean while on GIT, see : > https://github.com/OpenSIPS/opensips/pull/357 > > So, if you update from GIT, it should work even without M10 flag. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 15.10.2014 18:04, Satish Patel wrote: >> Great!!! >> >> After putting "FM10" now it working! what the hack is FM10? >> >> >> >> On Wed, Oct 8, 2014 at 6:22 AM, Bogdan-Andrei Iancu >> > wrote: >> >> Hi Satish, >> >> Could you add as extra flag to ds_select_xxx() the "M10" ? >> That will make the overall flags string "FM10". >> >> Try with that flags and let me know. >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> On 20.09.2014 15:18, Satish Patel wrote: >>> Hey any clue? I'm using 1.12 version. >>> >>> -- >>> Sent from my iPhone >>> >>> On Sep 19, 2014, at 4:29 AM, Bogdan-Andrei Iancu >>> > wrote: >>> >>>> dst is null as there is no pending destination for >>>> failover. cnt is 1. >>>> >>>> Which OpenSIPS revision are you using ? >>>> >>>> Regards, >>>> Bogdan-Andrei Iancu >>>> OpenSIPS Founder and Developer >>>> http://www.opensips-solutions.com >>>> On 17.09.2014 19:04, Satish Patel wrote: >>>>> I just trying to print $avp(271) $avp(272) and $avp(273) >>>>> >>>>> I am getting following output, why dst_avp is null ? and >>>>> cnt_avp should be 2 right? >>>>> >>>>> dst_avp = >>>>> grp_avp = 1 >>>>> cnt_avp = 0 >>>>> >>>>> Notes: I have both Freeswitch instance running on same box >>>>> but different port, do you think because of that it think >>>>> it is single host? >>>>> >>>>> PARTITION:: default >>>>> SET:: 1 >>>>> URI:: sip:sip.example.com:5061 >>>>> state=Active >>>>> URI:: sip:sip.example.com:5071 >>>>> state=Active >>>>> >>>>> >>>>> On Wed, Sep 17, 2014 at 11:06 AM, Satish Patel >>>>> > wrote: >>>>> >>>>> Here you go >>>>> >>>>> >>>>> >>>>> >>>>> /sbin/opensips[28000]: Sending call to ===> Freeswitch >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>> p=0x7f9ed01dd420, flags=0x0000 >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>> #011#011#011name=<274> >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>> #011#011#011id=<10> >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>> #011#011#011val_int=<0> >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>> p=0x7f9ed01df208, flags=0x0000 >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>> #011#011#011name=<273> >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>> #011#011#011id=<9> >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>> #011#011#011val_int=<1> >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>> p=0x7f9ed01e6518, flags=0x0002 >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>> #011#011#011name=<272> >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>> #011#011#011id=<12> >>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>> #011#011#011val_str=< / 0> >>>>> /sbin/opensips[28000]: dispatcher: Attempting to >>>>> dispatch call to sip:182.xx.xx.xxx:5071 >>>>> /sbin/opensips[28005]: Inside dispatcher failure route >>>>> /sbin/opensips[28005]: ds_dispatcher > >>>>> >>>>> /sbin/opensips[28005]: >>>>> R-DISPATCHER-ROLLOVER:fU4SNHMvcNmnjW19gsSj0g..-S No >>>>> more gateways in route set >>>>> >>>>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Oct 15 19:00:36 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 15 Oct 2014 20:00:36 +0300 Subject: [OpenSIPS-Users] dispatcher not doing fail over itself In-Reply-To: References: <5417E3E4.3020000@opensips.org> <5418640B.2050105@opensips.org> <54193884.2060801@opensips.org> <541999F2.7090705@opensips.org> <541BE96E.9080403@opensips.org> <20D5493C-5039-464D-B3BC-CDA798336311@gmail.com> <54351074.5060405@opensips.org> <543E9478.5010702@opensips.org> <543EA564.9050807@opensips.org> Message-ID: <543EA834.8000205@opensips.org> former 1.12, current 2.1.1 is devel version and never released as stable. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 15.10.2014 19:51, Satish Patel wrote: > You mean say 1.12.x isn't stable yet? > > > > On Wed, Oct 15, 2014 at 12:48 PM, Bogdan-Andrei Iancu > > wrote: > > I wouldn't recommended as the trunk GIT branch is the development > one, so , by definition, not stable. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 15.10.2014 19:46, Satish Patel wrote: >> can i use this GIT branch in production? >> >> On Wed, Oct 15, 2014 at 11:36 AM, Bogdan-Andrei Iancu >> > wrote: >> >> Hi Satish, >> >> In devel branch, there was an error on handling the default >> value for returned value. The M10 (explicitly setting the >> limit to 10) is a hack, it has to work without it. >> This error was fixed in the mean while on GIT, see : >> https://github.com/OpenSIPS/opensips/pull/357 >> >> So, if you update from GIT, it should work even without M10 flag. >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> On 15.10.2014 18:04, Satish Patel wrote: >>> Great!!! >>> >>> After putting "FM10" now it working! what the hack is FM10? >>> >>> >>> >>> On Wed, Oct 8, 2014 at 6:22 AM, Bogdan-Andrei Iancu >>> > wrote: >>> >>> Hi Satish, >>> >>> Could you add as extra flag to ds_select_xxx() the "M10" >>> ? That will make the overall flags string "FM10". >>> >>> Try with that flags and let me know. >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> >>> On 20.09.2014 15:18, Satish Patel wrote: >>>> Hey any clue? I'm using 1.12 version. >>>> >>>> -- >>>> Sent from my iPhone >>>> >>>> On Sep 19, 2014, at 4:29 AM, Bogdan-Andrei Iancu >>>> > wrote: >>>> >>>>> dst is null as there is no pending destination for >>>>> failover. cnt is 1. >>>>> >>>>> Which OpenSIPS revision are you using ? >>>>> >>>>> Regards, >>>>> Bogdan-Andrei Iancu >>>>> OpenSIPS Founder and Developer >>>>> http://www.opensips-solutions.com >>>>> On 17.09.2014 19:04, Satish Patel wrote: >>>>>> I just trying to print $avp(271) $avp(272) and $avp(273) >>>>>> >>>>>> I am getting following output, why dst_avp is null ? >>>>>> and cnt_avp should be 2 right? >>>>>> >>>>>> dst_avp = >>>>>> grp_avp = 1 >>>>>> cnt_avp = 0 >>>>>> >>>>>> Notes: I have both Freeswitch instance running on >>>>>> same box but different port, do you think because of >>>>>> that it think it is single host? >>>>>> >>>>>> PARTITION:: default >>>>>> SET:: 1 >>>>>> URI:: sip:sip.example.com:5061 >>>>>> state=Active >>>>>> URI:: sip:sip.example.com:5071 >>>>>> state=Active >>>>>> >>>>>> >>>>>> On Wed, Sep 17, 2014 at 11:06 AM, Satish Patel >>>>>> > >>>>>> wrote: >>>>>> >>>>>> Here you go >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> /sbin/opensips[28000]: Sending call to ===> >>>>>> Freeswitch >>>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>>> p=0x7f9ed01dd420, flags=0x0000 >>>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>>> #011#011#011name=<274> >>>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>>> #011#011#011id=<10> >>>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>>> #011#011#011val_int=<0> >>>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>>> p=0x7f9ed01df208, flags=0x0000 >>>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>>> #011#011#011name=<273> >>>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>>> #011#011#011id=<9> >>>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>>> #011#011#011val_int=<1> >>>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>>> p=0x7f9ed01e6518, flags=0x0002 >>>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>>> #011#011#011name=<272> >>>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>>> #011#011#011id=<12> >>>>>> /sbin/opensips[28000]: INFO:avpops:ops_print_avp: >>>>>> #011#011#011val_str=< / 0> >>>>>> /sbin/opensips[28000]: dispatcher: Attempting to >>>>>> dispatch call to sip:182.xx.xx.xxx:5071 >>>>>> /sbin/opensips[28005]: Inside dispatcher failure >>>>>> route >>>>>> /sbin/opensips[28005]: ds_dispatcher >>>>>> > >>>>>> /sbin/opensips[28005]: >>>>>> R-DISPATCHER-ROLLOVER:fU4SNHMvcNmnjW19gsSj0g..-S >>>>>> No more gateways in route set >>>>>> >>>>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Wed Oct 15 19:02:19 2014 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Wed, 15 Oct 2014 20:02:19 +0300 Subject: [OpenSIPS-Users] OpenSIPS 1.11.3 and 1.10.3 and 1.8.6 Releases In-Reply-To: <54355627.10005@opensips.org> References: <5435451C.5000704@opensips.org> <54355627.10005@opensips.org> Message-ID: <543EA89B.5000208@opensips.org> Hi, all! OpenSIPS 1.11.3[1], 1.10.3[2] as well as 1.8.6[3] (missed it in the initial announce :)) have just been released! All versions are stable and contain the latest bug fixes. You can download them from the links below. Enjoy the new releases and thank you all for your valuable contributions! [1] http://opensips.org/pub/opensips/1.11.3/src/ [2] http://opensips.org/pub/opensips/1.10.3/src/ [3] http://opensips.org/pub/opensips/1.8.6/src/ [4] https://sourceforge.net/projects/opensips/files/OpenSIPS/ Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com From wilddragon at sina.com Thu Oct 16 00:00:44 2014 From: wilddragon at sina.com (wilddragon at sina.com) Date: Thu, 16 Oct 2014 06:00:44 +0800 Subject: [OpenSIPS-Users] =?gbk?b?u9i4tKO6UmU6ICBBYm91dCAiTm90IGVub3VnaCBm?= =?gbk?q?ree_memory=2C_no_more_shm_memory_and_out_of_mem=22_Error?= Message-ID: <20141015220044.615E245EE81@webmail.sinamail.sina.com.cn> opensipsctl start i have not set any param related to mem. ----- ???? ----- ????Miha ????OpenSIPS users mailling list ???Re: [OpenSIPS-Users] About "Not enough free memory, no more shm memory and out of mem" Error ???2014?10?15? 20?27? ??????????? From liviu at opensips.org Thu Oct 16 00:12:40 2014 From: liviu at opensips.org (Liviu Chircu) Date: Thu, 16 Oct 2014 01:12:40 +0300 Subject: [OpenSIPS-Users] =?gbk?b?u9i4tKO6UmU6ICBBYm91dCAiTm90IGVub3VnaCBm?= =?gbk?q?ree_memory=2C_no_more_shm_memory_and_out_of_mem=22_Error?= In-Reply-To: <20141015220044.615E245EE81@webmail.sinamail.sina.com.cn> References: <20141015220044.615E245EE81@webmail.sinamail.sina.com.cn> Message-ID: <543EF158.7040405@opensips.org> Find your "opensipsctlrc" file (common dirs: /etc/opensips or /usr/local/opensips/etc), go to the bottom and change: # STARTOPTIONS= into STARTOPTIONS="-m64 -M8" Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 16.10.2014 01:00, wilddragon at sina.com wrote: > opensipsctl start > i have not set any param related to mem. > ----- ???? ----- > ????Miha > ????OpenSIPS users mailling list > ???Re: [OpenSIPS-Users] About "Not enough free memory, no more shm memory and out of mem" Error > ???2014?10?15? 20?27? > > > ??????????? > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilddragon at sina.com Thu Oct 16 08:09:28 2014 From: wilddragon at sina.com (wilddragon at sina.com) Date: Thu, 16 Oct 2014 14:09:28 +0800 Subject: [OpenSIPS-Users] =?gb2312?b?u9i4tDogUmU6ILvYuLSjulJlOiAgQWJvdXQg?= =?gb2312?b?Ik5vdCBlbm91Z2ggZnJlZSBtZW1vcnksIG5vIG1vcmUgc2htIG1l?= =?gb2312?b?bW9yeSBhbmQgb3V0IG9mIG1lbSIgRXJyb3I=?= References: <20141015220044.615E245EE81@webmail.sinamail.sina.com.cn>, <543EF158.7040405@opensips.org> Message-ID: <201410161409169939080@sina.com> thanks. Let me try to test. wilddragon at sina.com ???? Liviu Chircu ????? 2014-10-16 06:12 ???? users ??? Re: [OpenSIPS-Users]???Re: About "Not enough free memory, no more shm memory and out of mem" Error Find your "opensipsctlrc" file (common dirs: /etc/opensips or /usr/local/opensips/etc), go to the bottom and change: # STARTOPTIONS= into STARTOPTIONS="-m64 -M8" Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.comOn 16.10.2014 01:00, wilddragon at sina.com wrote: opensipsctl start i have not set any param related to mem. ----- ???? ----- ????Miha ????OpenSIPS users mailling list ???Re: [OpenSIPS-Users] About "Not enough free memory, no more shm memory and out of mem" Error ???2014?10?15? 20?27? ??????????? _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Oct 16 09:01:36 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 16 Oct 2014 10:01:36 +0300 Subject: [OpenSIPS-Users] YNT: Re: YNT: Re: YNT: Re: RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE In-Reply-To: <1413408334.56227.YahooMailNeo@web121506.mail.ne1.yahoo.com> References: <543BE104.6000507@opensips.org> <1413218726.55580.YahooMailNeo@web121503.mail.ne1.yahoo.com> <543C0643.8020906@opensips.org> <1413230483.7897.YahooMailNeo@web121502.mail.ne1.yahoo.com> <543D4657.70405@opensips.org> <1413347240.77902.YahooMailNeo@web121502.mail.ne1.yahoo.com> <543E20BE.5090307@opensips.org> <1413408334.56227.YahooMailNeo@web121506.mail.ne1.yahoo.com> Message-ID: <543F6D50.9000100@opensips.org> Hi Kaan, What you need to check is : do the ACK and BYE you receive in OpenSIPS have a Route hdr ? So, : check if the outbound INVITE (leaving OpenSIPS) has a Record-Route hdr check if the incoming 200 OK to INVITE (from UAS) has a Record-Route hdr check in inbound ACK (from UAC to OpenSIPS) has a Route hdr. Let me know. REgards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 16.10.2014 00:25, Kaan Dandin wrote: > Hi Bogdan, > > Thanks for your response. I have check the related documentation once > more. > But it in fact, I was already using record_route and loose_route. > > When I receive initial INVITE I use record_route. > > When the following messages has to_tag , I am checking with > loose_route and making the routing with t_relay. > > This is working properly for the messages before ACK and BYE. > > But for ACK and BYE messages it is not able to find route and making > a DNS lookup and since > pcscf.open-ims.test is configured as 192.168.2.5 , it is always going > to .5 openims node. > > The difference between 180 Ringing , 200 OK which is passed properly > and ACK and BYE messages seems Via headers. 180 Ringing has all the > via headers. > > related part of script for record_route() > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilddragon at sina.com Thu Oct 16 09:15:32 2014 From: wilddragon at sina.com (wilddragon at sina.com) Date: Thu, 16 Oct 2014 15:15:32 +0800 Subject: [OpenSIPS-Users] YNT: Re: YNT: Re: YNT: Re: RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE References: , <543BE104.6000507@opensips.org>, <1413218726.55580.YahooMailNeo@web121503.mail.ne1.yahoo.com>, <543C0643.8020906@opensips.org>, <1413230483.7897.YahooMailNeo@web121502.mail.ne1.yahoo.com>, <543D4657.70405@opensips.org>, <1413347240.77902.YahooMailNeo@web121502.mail.ne1.yahoo.com>, <543E20BE.5090307@opensips.org>, <1413408334.56227.YahooMailNeo@web121506.mail.ne1.yahoo.com>, <543F6D50.9000100@opensips.org> Message-ID: <201410161514508543953@sina.com> Is your opensips server located behind a SBC? in this sceniro, you have to use record_route_preset to record route, or use textops modules to modify the record-route header when you'd like to. wilddragon at sina.com From: Bogdan-Andrei Iancu Date: 2014-10-16 15:01 To: Kaan Dandin; OpenSIPS users mailling list CC: "Ibrahim Hokelek, (B?; Gunes Kurt; LGEM-UEKAE)" Subject: Re: [OpenSIPS-Users] YNT: Re: YNT: Re: YNT: Re: RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE Hi Kaan, What you need to check is : do the ACK and BYE you receive in OpenSIPS have a Route hdr ? So, : check if the outbound INVITE (leaving OpenSIPS) has a Record-Route hdr check if the incoming 200 OK to INVITE (from UAS) has a Record-Route hdr check in inbound ACK (from UAC to OpenSIPS) has a Route hdr. Let me know. REgards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.comOn 16.10.2014 00:25, Kaan Dandin wrote: Hi Bogdan, Thanks for your response. I have check the related documentation once more. But it in fact, I was already using record_route and loose_route. When I receive initial INVITE I use record_route. When the following messages has to_tag , I am checking with loose_route and making the routing with t_relay. This is working properly for the messages before ACK and BYE. But for ACK and BYE messages it is not able to find route and making a DNS lookup and since pcscf.open-ims.test is configured as 192.168.2.5 , it is always going to .5 openims node. The difference between 180 Ringing , 200 OK which is passed properly and ACK and BYE messages seems Via headers. 180 Ringing has all the via headers. related part of script for record_route() -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Oct 16 09:20:26 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 16 Oct 2014 10:20:26 +0300 Subject: [OpenSIPS-Users] udp or tcp for nat traversal? In-Reply-To: <1e45a505.12847.14914a82b85.Coremail.aihuawu2012@163.com> References: <9f50cdb.2658d.1490f4e26ee.Coremail.aihuawu2012@163.com> <543D4DD6.1020405@opensips.org> <4dd40a9b.e54.14911311a6a.Coremail.aihuawu2012@163.com> <543E1E7C.4070407@opensips.org> <46185c1e.103bc.14913b36612.Coremail.aihuawu2012@163.com> <543E6C8A.6000802@opensips.org> <19a5f1b5.11c47.14914396a05.Coremail.aihuawu2012@163.com> <543E89C3.5030401@opensips.org> <1e45a505.12847.14914a82b85.Coremail.aihuawu2012@163.com> Message-ID: <543F71BA.9070404@opensips.org> Hi George, If it is truncated, it is on the client side maybe...not server (because of MTU or others) - is there any way to check linphone logs ?? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 15.10.2014 19:33, george wu wrote: > > > Is it because the packet MTU is too big? It can't handle size bigger > than 1472 bytes? > The last line looks strange to me. > a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx raddr > 192.168[|sip] > > > > At 2014-10-15 22:50:43, "Bogdan-Andrei Iancu" wrote: > > The trace definitely shows linphone not answering to the INVITE > handled via mediaproxy (INVITE goes to linphone but nothing back). > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 15.10.2014 17:32, george wu wrote: >> //part 2 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaandandin at yahoo.com Wed Oct 15 23:25:34 2014 From: kaandandin at yahoo.com (Kaan Dandin) Date: Wed, 15 Oct 2014 14:25:34 -0700 Subject: [OpenSIPS-Users] YNT: Re: YNT: Re: YNT: Re: RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE In-Reply-To: <543E20BE.5090307@opensips.org> References: <543BE104.6000507@opensips.org> <1413218726.55580.YahooMailNeo@web121503.mail.ne1.yahoo.com> <543C0643.8020906@opensips.org> <1413230483.7897.YahooMailNeo@web121502.mail.ne1.yahoo.com> <543D4657.70405@opensips.org> <1413347240.77902.YahooMailNeo@web121502.mail.ne1.yahoo.com> <543E20BE.5090307@opensips.org> Message-ID: <1413408334.56227.YahooMailNeo@web121506.mail.ne1.yahoo.com> Hi Bogdan, Thanks for your response. I have check the related documentation once more. But it in fact, I was already using record_route and loose_route. When I receive initial INVITE I use record_route. When the following messages has to_tag , I am checking with loose_route and making the routing with t_relay. This is working properly for the messages before ACK and BYE. But for ACK and BYE messages it is not able to find route and making a DNS lookup and since pcscf.open-ims.test is configured as 192.168.2.5 , it is always going to .5 openims node. The difference between 180 Ringing , 200 OK which is passed properly and ACK and BYE messages seems Via headers. 180 Ringing has all the via headers. related part of script for record_route() else if (is_method("INVITE")) { #load_balance("1","pstn"); xlog("xlog_initialinvite"); if($si=="192.168.2.11") { ds_select_dst("1","1"); } record_route(); if(!t_relay()) { sl_reply_error(); xlog("xlog_invitereplyerror"); } exit; } wireshark log No. Time Source Destination Protocol Info 4647 79.393261 192.168.2.11 192.168.2.141 SIP/SDP Request: INVITE sip:subs000174 at open-ims.test, with session description 4648 79.395108 192.168.2.141 192.168.2.11 SIP Status: 100 Giving a try 4649 79.395467 192.168.2.141 192.168.2.3 SIP/SDP Request: INVITE sip:subs000174 at open-ims.test, with session description 4650 79.426101 192.168.2.3 192.168.2.141 SIP Status: 100 trying -- your call is important to us 4651 79.464427 192.168.2.3 192.168.2.141 SIP/SDP Request: INVITE sip:subs000174 at 192.168.2.11:7174, with session description 4652 79.465264 192.168.2.141 192.168.2.3 SIP Status: 100 Giving a try 4654 79.465773 192.168.2.141 192.168.2.11 SIP/SDP Request: INVITE sip:subs000174 at 192.168.2.11:7174, with session description 4655 79.465773 192.168.2.11 192.168.2.141 SIP Status: 180 Ringing 4656 79.466172 192.168.2.141 192.168.2.3 SIP Status: 180 Ringing 4657 79.507893 192.168.2.3 192.168.2.141 SIP Status: 180 Ringing 4658 79.508153 192.168.2.141 192.168.2.11 SIP Status: 180 Ringing 5053 84.372654 192.168.2.11 192.168.2.141 SIP/SDP Status: 200 OK, with session description 5054 84.372931 192.168.2.141 192.168.2.3 SIP/SDP Status: 200 OK, with session description 5055 84.396628 192.168.2.3 192.168.2.141 SIP/SDP Status: 200 OK, with session description 5056 84.397036 192.168.2.141 192.168.2.11 SIP/SDP Status: 200 OK, with session description 5057 84.397552 192.168.2.11 192.168.2.141 SIP Request: ACK sip:subs000174 at 192.168.2.11:7174;transport=UDP 5058 84.398921 192.168.2.141 192.168.2.5 SIP Request: ACK sip:subs000174 at 192.168.2.11:7174;transport=UDP 5075 84.874990 192.168.2.11 192.168.2.141 SIP/SDP Status: 200 OK, with session description 5076 84.875713 192.168.2.141 192.168.2.3 SIP/SDP Status: 200 OK, with session description 5077 84.925133 192.168.2.3 192.168.2.141 SIP/SDP Status: 200 OK, with session description 5078 84.925434 192.168.2.141 192.168.2.11 SIP/SDP Status: 200 OK, with session description 5079 84.925622 192.168.2.11 192.168.2.141 SIP Request: ACK sip:subs000174 at 192.168.2.11:7174;transport=UDP 5080 84.926591 192.168.2.141 192.168.2.5 SIP Request: ACK sip:subs000174 at 192.168.2.11:7174;transport=UDP 5418 85.876690 192.168.2.11 192.168.2.141 SIP/SDP Status: 200 OK, with session description 5419 85.876692 192.168.2.141 192.168.2.3 SIP/SDP Status: 200 OK, with session description 5420 85.936150 192.168.2.3 192.168.2.141 SIP/SDP Status: 200 OK, with session description 5421 85.936625 192.168.2.141 192.168.2.11 SIP/SDP Status: 200 OK, with session description 5422 85.936815 192.168.2.11 192.168.2.141 SIP Request: ACK sip:subs000174 at 192.168.2.11:7174;transport=UDP 5423 85.937798 192.168.2.141 192.168.2.5 SIP Request: ACK sip:subs000174 at 192.168.2.11:7174;transport=UDP 5440 87.883590 192.168.2.11 192.168.2.141 SIP/SDP Status: 200 OK, with session description 5441 87.884024 192.168.2.141 192.168.2.3 SIP/SDP Status: 200 OK, with session description 5445 87.960207 192.168.2.3 192.168.2.141 SIP/SDP Status: 200 OK, with session description 5447 87.960454 192.168.2.141 192.168.2.11 SIP/SDP Status: 200 OK, with session description 5448 87.961156 192.168.2.11 192.168.2.141 SIP Request: ACK sip:subs000174 at 192.168.2.11:7174;transport=UDP 5449 87.961157 192.168.2.141 192.168.2.5 SIP Request: ACK sip:subs000174 at 192.168.2.11:7174;transport=UDP 5522 91.888474 192.168.2.11 192.168.2.141 SIP/SDP Status: 200 OK, with session description 6137 95.893241 192.168.2.11 192.168.2.141 SIP/SDP Status: 200 OK, with session description 6228 99.902322 192.168.2.11 192.168.2.141 SIP/SDP Status: 200 OK, with session description 6327 103.908286 192.168.2.11 192.168.2.141 SIP/SDP Status: 200 OK, with session description 7097 107.919189 192.168.2.11 192.168.2.141 SIP/SDP Status: 200 OK, with session description 7241 111.925927 192.168.2.11 192.168.2.141 SIP/SDP Status: 200 OK, with session description 8781 133.854566 192.168.2.11 192.168.2.141 SIP Request: BYE sip:subs000174 at 192.168.2.11:7174;transport=UDP 8782 133.855367 192.168.2.141 192.168.2.5 SIP Request: BYE sip:subs000174 at 192.168.2.11:7174;transport=UDP 8783 133.856357 192.168.2.5 192.168.2.141 SIP Status: 403 Forbidden - Originating subsequent requests outside dialog not allowed Opensips related log ct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: xlog method: [ACK] totag: [3283SIPpTag01173] sipid: [192.168.2.11] messageid: [883] callid: [173-3283 at 192.168.2.11] callsequence: [1] Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:uri:has_totag: totag found Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: xlog_has_totag Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:core:parse_headers: flags=200 Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:core:get_hdr_field: content_length=0 Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:core:get_hdr_field: found end of header Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:rr:find_first_route: No Route headers found Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:rr:loose_route: There is no Route HF Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: xlog_ack_method Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:core:parse_headers: flags=78 Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:tm:t_lookup_request: start searching: hash=58738, isACK=1 Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:core:parse_headers: flags=38 Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:core:parse_to_param: tag=3283SIPpTag00173 Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:core:parse_to: end of header reached, state=29 Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:core:parse_to: display={"subs004916"}, ruri={sip:subs004916 at open-ims.test} Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:tm:t_lookup_request: REF_UNSAFE:[0x7f81f6570408] after is 1 Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:tm:t_lookup_request: e2e proxy ACK found Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: xlog_nonlooseroutestatefulack Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:tm:t_newtran: transaction on entrance=(nil) Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:core:parse_headers: flags=ffffffffffffffff Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:tm:t_newtran: building branch for end2end ACK - flags=1 Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:tm:t_relay_to: forwarding ACK Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:core:mk_proxy: doing DNS lookup... Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:core:check_ip_address: params 192.168.2.11, 192.168.2.11, 0 Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:core:forward_request: sending:#012ACK sip:subs000129 at 192.168.2.11:7129;transport=UDP SIP/2.0#015#012Record-Route: #015#012Via: SIP/2.0/UDP 192.168.2.141:4060;branch=z9hG4bK275e.11b33e95.2#015#012Via: SIP/2.0/UDP 192.168.2.11:11916;branch=z9hG4bK-3283-173-4#015#012Max-Forwards: 70#015#012Record-Route: #015#012Record-Route: #015#012Record-Route: #015#012Record-Route: #015#012Record-Route: #015#012Record-Route: #015#012From: "subs004916" ;tag=3283SIPpTag00173#015#012To: "subs000129" ;tag=3283SIPpTag01174;tag=3283SIPpTag01173#015#012Call-ID: 173-3283 at 192.168.2.11#015#012CSeq: 1 INVITE#015#012Content-Length: 0#015#012#015#012. Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:core:forward_request: orig. len=701, new_len=828, proto=1 Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:tm:t_unref_cell: UNREF_UNSAFE: [0x7f81f6570408] after is 0 Oct 15 13:01:27 ubuntu /usr/local/opensips/sbin/opensips[4329]: DBG:core:destroy_avp_list: destroying list (nil) Details of 180 Ringing which is passed properly No. Time Source Destination Protocol Info 3263 49.371030 192.168.2.11 192.168.2.141 SIP Status: 180 Ringing Frame 3263 (1177 bytes on wire, 1177 bytes captured) Arrival Time: Oct 15, 2014 22:54:17.241278000 [Time delta from previous captured frame: 0.002010000 seconds] [Time delta from previous displayed frame: 0.002010000 seconds] [Time since reference or first frame: 49.371030000 seconds] Frame Number: 3263 Frame Length: 1177 bytes Capture Length: 1177 bytes [Frame is marked: False] [Protocols in frame: eth:ip:udp:sip] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: Vmware_d2:6a:2a (00:0c:29:d2:6a:2a), Dst: Vmware_22:e0:4c (00:0c:29:22:e0:4c) Destination: Vmware_22:e0:4c (00:0c:29:22:e0:4c) Address: Vmware_22:e0:4c (00:0c:29:22:e0:4c) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: Vmware_d2:6a:2a (00:0c:29:d2:6a:2a) Address: Vmware_d2:6a:2a (00:0c:29:d2:6a:2a) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 192.168.2.11 (192.168.2.11), Dst: 192.168.2.141 (192.168.2.141) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 1163 Identification: 0x504b (20555) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0x602e [correct] [Good: True] [Bad : False] Source: 192.168.2.11 (192.168.2.11) Destination: 192.168.2.141 (192.168.2.141) User Datagram Protocol, Src Port: 11630 (11630), Dst Port: dsmeter_iatc (4060) Source port: 11630 (11630) Destination port: dsmeter_iatc (4060) Length: 1143 Checksum: 0xb322 [correct] [Good Checksum: True] [Bad Checksum: False] Session Initiation Protocol Status-Line: SIP/2.0 180 Ringing Status-Code: 180 [Resent Packet: False] Message Header Via: SIP/2.0/UDP 192.168.2.141:4060;branch=z9hG4bKd619.6d0c1795.0 Transport: UDP Sent-by Address: 192.168.2.141 Sent-by port: 4060 Branch: z9hG4bKd619.6d0c1795.0 Via: SIP/2.0/UDP 192.168.2.3:4060;branch=z9hG4bKd619.d62fc68.0 Transport: UDP Sent-by Address: 192.168.2.3 Sent-by port: 4060 Branch: z9hG4bKd619.d62fc68.0 Via: SIP/2.0/UDP 192.168.2.3:6060;received=192.168.2.3;rport=6060;branch=z9hG4bKd619.b137ec01.0 Transport: UDP Sent-by Address: 192.168.2.3 Sent-by port: 6060 Received: 192.168.2.3 RPort: 6060 Branch: z9hG4bKd619.b137ec01.0 Via: SIP/2.0/UDP 192.168.2.3:6060;branch=z9hG4bKd619.a137ec01.0 Transport: UDP Sent-by Address: 192.168.2.3 Sent-by port: 6060 Branch: z9hG4bKd619.a137ec01.0 Via: SIP/2.0/UDP 192.168.2.3:4060;branch=z9hG4bKd619.c62fc68.0 Transport: UDP Sent-by Address: 192.168.2.3 Sent-by port: 4060 Branch: z9hG4bKd619.c62fc68.0 Via: SIP/2.0/UDP 192.168.2.141:4060;received=192.168.2.141;rport=4060;branch=z9hG4bKd619.5d0c1795.0 Transport: UDP Sent-by Address: 192.168.2.141 Sent-by port: 4060 Received: 192.168.2.141 RPort: 4060 Branch: z9hG4bKd619.5d0c1795.0 Via: SIP/2.0/UDP 192.168.2.11:10800;branch=z9hG4bK-3501-57-4 Transport: UDP Sent-by Address: 192.168.2.11 Sent-by port: 10800 Branch: z9hG4bK-3501-57-4 Record-Route: Record-Route: Record-Route: Record-Route: Record-Route: Record-Route: From: "subs003800" ;tag=3501SIPpTag0057 SIP Display info: "subs003800" SIP from address: sip:subs003800 at open-ims.test SIP tag: 3501SIPpTag0057 To: "subs004630" ;tag=3501SIPpTag0158 SIP Display info: "subs004630" SIP to address: sip:subs004630 at open-ims.test SIP tag: 3501SIPpTag0158 Call-ID: 57-3501 at 192.168.2.11 CSeq: 1 INVITE Sequence Number: 1 Method: INVITE Contact: Contact Binding: URI: SIP contact address: sip:subs004630 at 192.168.2.11:11630 Content-Length: sample ack message No. Time Source Destination Protocol Info 3271 49.468199 192.168.2.11 192.168.2.141 SIP Request: ACK sip:subs000663 at 192.168.2.11:7663;transport=UDP Frame 3271 (636 bytes on wire, 636 bytes captured) Arrival Time: Oct 15, 2014 22:54:17.338447000 [Time delta from previous captured frame: 0.000420000 seconds] [Time delta from previous displayed frame: 0.000420000 seconds] [Time since reference or first frame: 49.468199000 seconds] Frame Number: 3271 Frame Length: 636 bytes Capture Length: 636 bytes [Frame is marked: False] [Protocols in frame: eth:ip:udp:sip] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: Vmware_d2:6a:2a (00:0c:29:d2:6a:2a), Dst: Vmware_22:e0:4c (00:0c:29:22:e0:4c) Destination: Vmware_22:e0:4c (00:0c:29:22:e0:4c) Address: Vmware_22:e0:4c (00:0c:29:22:e0:4c) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: Vmware_d2:6a:2a (00:0c:29:d2:6a:2a) Address: Vmware_d2:6a:2a (00:0c:29:d2:6a:2a) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 192.168.2.11 (192.168.2.11), Dst: 192.168.2.141 (192.168.2.141) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 622 Identification: 0x504d (20557) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0x6249 [correct] [Good: True] [Bad : False] Source: 192.168.2.11 (192.168.2.11) Destination: 192.168.2.141 (192.168.2.141) User Datagram Protocol, Src Port: 10538 (10538), Dst Port: dsmeter_iatc (4060) Source port: 10538 (10538) Destination port: dsmeter_iatc (4060) Length: 602 Checksum: 0xf199 [correct] [Good Checksum: True] [Bad Checksum: False] Session Initiation Protocol Request-Line: ACK sip:subs000663 at 192.168.2.11:7663;transport=UDP SIP/2.0 Method: ACK [Resent Packet: False] Message Header Via: SIP/2.0/UDP 192.168.2.11:10538;branch=z9hG4bK-3501-49-4 Transport: UDP Sent-by Address: 192.168.2.11 Sent-by port: 10538 Branch: z9hG4bK-3501-49-4 Max-Forwards: 70 [truncated] Route: , , , , ,;tag=3501SIPpTag0049 SIP Display info: "subs003538" SIP from address: sip:subs003538 at open-ims.test SIP tag: 3501SIPpTag0049 To: "subs000663" ;tag=3501SIPpTag0150 SIP Display info: "subs000663" SIP to address: sip:subs000663 at open-ims.test SIP tag: 3501SIPpTag0150 Call-ID: 49-3501 at 192.168.2.11 CSeq: 1 ACK Sequence Number: 1 Method: ACK Content-Length: 0 ________________________________ From: Bogdan-Andrei Iancu To: Kaan Dandin ; OpenSIPS users mailling list Cc: Gunes Kurt ; "Ibrahim Hokelek, (B?LGEM-UEKAE)" Sent: Wednesday, October 15, 2014 10:22 AM Subject: Re: YNT: Re: YNT: Re: YNT: Re: [OpenSIPS-Users] RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE Hi Kaan, I'm glad the first part is properly working now. Your ACK (as it is for a 200 OK) should be routed based on Route headers (record route and loose route mechanism). TO better understand this, please take a look to this webinar: http://www.opensips.org/Documentation/Webinars#toc12 ( chapter 5.5 ) At INVITE time you should do record_route() and the ACK should carry the Route headers in order to follow the same path as the INVITE. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From aihuawu2012 at 163.com Thu Oct 16 10:45:30 2014 From: aihuawu2012 at 163.com (george wu) Date: Thu, 16 Oct 2014 16:45:30 +0800 (CST) Subject: [OpenSIPS-Users] udp or tcp for nat traversal? In-Reply-To: <543F71BA.9070404@opensips.org> References: <9f50cdb.2658d.1490f4e26ee.Coremail.aihuawu2012@163.com> <543D4DD6.1020405@opensips.org> <4dd40a9b.e54.14911311a6a.Coremail.aihuawu2012@163.com> <543E1E7C.4070407@opensips.org> <46185c1e.103bc.14913b36612.Coremail.aihuawu2012@163.com> <543E6C8A.6000802@opensips.org> <19a5f1b5.11c47.14914396a05.Coremail.aihuawu2012@163.com> <543E89C3.5030401@opensips.org> <1e45a505.12847.14914a82b85.Coremail.aihuawu2012@163.com> <543F71BA.9070404@opensips.org> Message-ID: <663df450.1fd3e.1491822237e.Coremail.aihuawu2012@163.com> For linphonec, if you run with flag -d, it will print all the debug information However, it shows nothing when mediaproxy is on. Actually the tcpdump is run on the server. so if it is truncated, it must be server truncate it. Is it possible to make rtpproxy work with ice if mediaproxy does not work? I need both ice and a relay server work. What can I do? Thanks. George At 2014-10-16 15:20:26, "Bogdan-Andrei Iancu" wrote: Hi George, If it is truncated, it is on the client side maybe...not server (because of MTU or others) - is there any way to check linphone logs ?? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 15.10.2014 19:33, george wu wrote: Is it because the packet MTU is too big? It can't handle size bigger than 1472 bytes? The last line looks strange to me. a=candidate:2 2 UDP 1694498814 124.193.138.210 5060 typ srflx raddr 192.168[|sip] At 2014-10-15 22:50:43, "Bogdan-Andrei Iancu" wrote: The trace definitely shows linphone not answering to the INVITE handled via mediaproxy (INVITE goes to linphone but nothing back). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 15.10.2014 17:32, george wu wrote: //part 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From miha at softnet.si Thu Oct 16 15:53:35 2014 From: miha at softnet.si (Miha) Date: Thu, 16 Oct 2014 15:53:35 +0200 Subject: [OpenSIPS-Users] NAT, UPDATE problem Message-ID: <543FCDDF.3050800@softnet.si> Hi, in my cfg file i have this: if (nat_uac_test("18")) { xlog("fixing nat"); if (method=="REGISTER") { fix_nated_register(); fix_nated_contact(); } else { fix_nated_contact(); } force_rport(); } But when 200ok with sdp is send this part of script does not execute as in contact is still private ip. I have 18 in nat_uac_test so if src port port in via are different this should be triggered but it is not that is why proxy sends media to private ip. Here is my sip trace: http://pastebin.com/KvNdttj9 Tnx miha From aihuawu2012 at 163.com Fri Oct 17 01:44:30 2014 From: aihuawu2012 at 163.com (george wu) Date: Fri, 17 Oct 2014 07:44:30 +0800 (CST) Subject: [OpenSIPS-Users] tcp keep-alive time Message-ID: <478de7f3.666.1491b5932da.Coremail.aihuawu2012@163.com> Hi, guys: How can I adjust the global tcp keep alive time? what's the default in opensips? I want it to close as soon as possible so that tcp deployment can scale. George Wu -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhouxiaoqiang.mstech at gmail.com Fri Oct 17 04:44:32 2014 From: zhouxiaoqiang.mstech at gmail.com (chow) Date: Thu, 16 Oct 2014 19:44:32 -0700 (PDT) Subject: [OpenSIPS-Users] branch computation failed In-Reply-To: <543D5199.4000204@opensips.org> References: <1412825847529-7593895.post@n2.nabble.com> <5436691D.4010006@opensips.org> <1412906905090-7593931.post@n2.nabble.com> <543B7EEE.9000505@opensips.org> <201410131535093743451@gmail.com> <543B82E2.7010003@opensips.org> <201410140951152215038@gmail.com> <543D5199.4000204@opensips.org> Message-ID: <1413513872354-7594086.post@n2.nabble.com> Hi: that error come out again. I doubt there have memory leak. that server have 32G memory. the opensips config: default Start option S_MEMORY=4096 and P_MEMORY=128 children(process) 128 then I think opensips have 4096 + 128*128 = 20480M memory, this is right? opensips hold memory never free , top command result: Tasks: 529 total, 1 running, 528 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 32830608k total, 32589824k used, 240784k free, 138720k buffers Swap: 16482296k total, 516k used, 16481780k free, 30601400k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 11928 opensips 20 0 4368m 455m 454m S 0.3 1.4 51:17.91 opensips 11791 opensips 20 0 4368m 6172 5004 S 0.0 0.0 0:00.19 opensips 11792 opensips 20 0 4368m 1960 728 S 0.0 0.0 0:00.18 opensips 11793 opensips 20 0 4368m 1404 240 S 0.0 0.0 0:00.06 opensips 11794 opensips 20 0 4368m 1952 776 S 0.0 0.0 0:00.07 opensips 11795 opensips 20 0 4368m 2512 1208 S 0.0 0.0 1:07.58 opensips 11796 opensips 20 0 4368m 2172 992 S 0.0 0.0 0:00.06 opensips 11797 opensips 20 0 4368m 1812 640 S 0.0 0.0 0:00.06 opensips 11798 opensips 20 0 4368m 1812 640 S 0.0 0.0 0:00.05 opensips 11799 opensips 20 0 4368m 514m 513m S 0.0 1.6 79:11.69 opensips 11800 opensips 20 0 4368m 514m 513m S 0.0 1.6 78:20.70 opensips 11801 opensips 20 0 4368m 514m 513m S 0.0 1.6 78:05.47 opensips 11802 opensips 20 0 4368m 514m 513m S 0.0 1.6 79:09.96 opensips 11803 opensips 20 0 4368m 514m 513m S 0.0 1.6 79:05.35 opensips 11804 opensips 20 0 4368m 514m 513m S 0.0 1.6 78:14.65 opensips 11805 opensips 20 0 4368m 514m 513m S 0.0 1.6 78:06.60 opensips 11806 opensips 20 0 4368m 514m 513m S 0.0 1.6 79:19.44 opensips 11807 opensips 20 0 4368m 514m 513m S 0.0 1.6 79:18.87 opensips 11808 opensips 20 0 4368m 514m 513m S 0.0 1.6 78:16.96 opensips 11809 opensips 20 0 4368m 514m 513m S 0.0 1.6 79:27.83 opensips 11810 opensips 20 0 4368m 514m 513m S 0.0 1.6 78:11.83 opensips 11811 opensips 20 0 4368m 514m 513m S 0.0 1.6 79:11.44 opensips 11812 opensips 20 0 4368m 514m 513m S 0.0 1.6 78:21.19 opensips 11813 opensips 20 0 4368m 514m 513m S 0.0 1.6 78:01.53 opensips 11814 opensips 20 0 4368m 514m 513m S 0.0 1.6 78:51.01 opensips the free command have result: free total used free shared buffers cached Mem: 32830608 32592164 238444 0 140008 30602304 -/+ buffers/cache: 1849852 30980756 Swap: 16482296 516 16481780 the opensips log: Oct 15 10:21:02 localhost /usr/sbin/opensips[11795]: ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe Oct 15 10:27:01 localhost /usr/sbin/opensips[11795]: ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe Oct 15 10:42:02 localhost /usr/sbin/opensips[11795]: ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe Oct 15 10:47:02 localhost /usr/sbin/opensips[11795]: ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe Oct 15 11:02:01 localhost /usr/sbin/opensips[11795]: ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe Oct 15 11:09:02 localhost /usr/sbin/opensips[11795]: ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe Oct 15 11:14:02 localhost /usr/sbin/opensips[11795]: ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe Oct 15 11:23:01 localhost /usr/sbin/opensips[11795]: ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe ... ... ... ... ... Oct 17 03:58:01 localhost /usr/sbin/opensips[11795]: ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe Oct 17 04:14:01 localhost /usr/sbin/opensips[11795]: ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe Oct 17 04:19:45 localhost /usr/sbin/opensips[11849]: ERROR:core:branch_builder: writing label failed, remaining size is 0 (initial 46) buf=[z9hG4bK76c7.00000008ffffffffffffffffffffffffffffffffffffff] Oct 17 04:19:45 localhost /usr/sbin/opensips[11849]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 17 04:19:45 localhost /usr/sbin/opensips[11849]: ERROR:tm:t_forward_nonack: failure to add branches Oct 17 04:19:45 localhost /usr/sbin/opensips[11859]: ERROR:core:branch_builder: writing label failed, remaining size is 0 (initial 46) buf=[z9hG4bK76c7.10000008ffffffffffffffffffffffffffffffffffffff] Oct 17 04:19:45 localhost /usr/sbin/opensips[11859]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 17 04:19:45 localhost /usr/sbin/opensips[11859]: ERROR:tm:t_forward_nonack: failure to add branches Oct 17 04:19:53 localhost /usr/sbin/opensips[11816]: ERROR:core:branch_builder: writing label failed, remaining size is 0 (initial 46) buf=[z9hG4bK76c7.20000008ffffffffffffffffffffffffffffffffffffff] Oct 17 04:19:53 localhost /usr/sbin/opensips[11816]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 17 04:19:53 localhost /usr/sbin/opensips[11816]: ERROR:tm:t_forward_nonack: failure to add branches Oct 17 04:19:53 localhost /usr/sbin/opensips[11862]: ERROR:core:branch_builder: writing label failed, remaining size is 0 (initial 46) buf=[z9hG4bK76c7.30000008ffffffffffffffffffffffffffffffffffffff] Oct 17 04:19:53 localhost /usr/sbin/opensips[11862]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 17 04:19:53 localhost /usr/sbin/opensips[11862]: ERROR:tm:t_forward_nonack: failure to add branches Oct 17 04:19:54 localhost /usr/sbin/opensips[11921]: ERROR:core:branch_builder: writing label failed, remaining size is 0 (initial 46) buf=[z9hG4bK76c7.40000008ffffffffffffffffffffffffffffffffffffff] Oct 17 04:19:54 localhost /usr/sbin/opensips[11921]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 17 04:19:54 localhost /usr/sbin/opensips[11921]: ERROR:tm:t_forward_nonack: failure to add branches Oct 17 04:19:54 localhost /usr/sbin/opensips[11829]: ERROR:core:branch_builder: writing label failed, remaining size is 0 (initial 46) buf=[z9hG4bK76c7.50000008ffffffffffffffffffffffffffffffffffffff] Oct 17 04:19:54 localhost /usr/sbin/opensips[11829]: ERROR:tm:pre_print_uac_request: branch computation failed Oct 17 04:19:54 localhost /usr/sbin/opensips[11829]: ERROR:tm:t_forward_nonack: failure to add branches -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/branch-computation-failed-tp7593895p7594086.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From bogdan at opensips.org Fri Oct 17 09:29:34 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 17 Oct 2014 10:29:34 +0300 Subject: [OpenSIPS-Users] YNT: Re: YNT: Re: YNT: Re: RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE In-Reply-To: <1413477332.98465.YahooMailNeo@web121506.mail.ne1.yahoo.com> References: <543BE104.6000507@opensips.org> <1413218726.55580.YahooMailNeo@web121503.mail.ne1.yahoo.com> <543C0643.8020906@opensips.org> <1413230483.7897.YahooMailNeo@web121502.mail.ne1.yahoo.com> <543D4657.70405@opensips.org> <1413347240.77902.YahooMailNeo@web121502.mail.ne1.yahoo.com> <543E20BE.5090307@opensips.org> <1413408334.56227.YahooMailNeo@web121506.mail.ne1.yahoo.com> <543F6D50.9000100@opensips.org> <1413477332.98465.YahooMailNeo@web121506.mail.ne1.yahoo.com> Message-ID: <5440C55E.3040608@opensips.org> Hi Kaan, The problem seems to the with the testing tool you use (sipp ?) which cannot work with a large set of Route headers. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 16.10.2014 19:35, Kaan Dandin wrote: > Hi Bogdan, > > Thanks for your support. > All of the messages until inbound ACK to OpenSIPS have record route > header. > Inbound ACK is having only truncated route information. > It seems that IMS bench is not putting Record Route header to ACK > although is it is configured like following. > > > related part of ims bench ims_uac.xml script > ================================== > > > > > > > > > ACK [next_url] SIP/2.0 > [last_Via:] > Max-Forwards: 70 > [routes:] > From: "[field0]" > ;tag=[pid]SIPpTag00[call_number] > [last_To:] > Call-ID: [call_id] > CSeq: 1 ACK > Content-Length: 0 > > ]]> > > > > 200 OK coming to OpenSIPS > =============================== > > > Sent-by port: 9048 > Branch: z9hG4bK-3672-12-4 > Max-Forwards: 70 > [truncated] Route: , > , > , > , > , From: "subs002048" ;tag=3672SIPpTag0012 > SIP Display info: "subs002048" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Fri Oct 17 09:31:15 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 17 Oct 2014 10:31:15 +0300 Subject: [OpenSIPS-Users] YNT: Re: YNT: Re: YNT: Re: RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE In-Reply-To: <1413484989.44115.YahooMailNeo@web121506.mail.ne1.yahoo.com> References: <543BE104.6000507@opensips.org> <1413218726.55580.YahooMailNeo@web121503.mail.ne1.yahoo.com> <543C0643.8020906@opensips.org> <1413230483.7897.YahooMailNeo@web121502.mail.ne1.yahoo.com> <543D4657.70405@opensips.org> <1413347240.77902.YahooMailNeo@web121502.mail.ne1.yahoo.com> <543E20BE.5090307@opensips.org> <1413408334.56227.YahooMailNeo@web121506.mail.ne1.yahoo.com> <543F6D50.9000100@opensips.org> <1413477332.98465.YahooMailNeo@web121506.mail.ne1.yahoo.com> <1413484989.44115.YahooMailNeo@web121506.mail.ne1.yahoo.com> Message-ID: <5440C5C3.1020004@opensips.org> Kaan, as per my previous email, the problem is in sipp, not in openims. To get rid of the large set of Route header, I suggest you to use dialog support on opensips with topologyhiding. http://www.opensips.org/html/docs/modules/1.11.x/dialog.html#id296413 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 16.10.2014 21:43, Kaan Dandin wrote: > Hi Bogdan, > > I have changed the ims_uac.xml of IMS Bench. Now it includes > record_route header. But via header in ACK is not having all of the > passed nodes. > > The reason looks, although Open IMS receives all of the passed nodes > in via header of 200 OK it received from Open SIPS, it does not > include all of them in via header of 200 Ok response sent to > OpenSIPS. Therefore ACK from UAC is ended now at Open SIPS instead of > Open IMS. > > Now I need to troubleshoot OpenIMS configuration. > > BR, > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaandandin at yahoo.com Thu Oct 16 18:35:32 2014 From: kaandandin at yahoo.com (Kaan Dandin) Date: Thu, 16 Oct 2014 09:35:32 -0700 Subject: [OpenSIPS-Users] YNT: Re: YNT: Re: YNT: Re: RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE In-Reply-To: <543F6D50.9000100@opensips.org> References: <543BE104.6000507@opensips.org> <1413218726.55580.YahooMailNeo@web121503.mail.ne1.yahoo.com> <543C0643.8020906@opensips.org> <1413230483.7897.YahooMailNeo@web121502.mail.ne1.yahoo.com> <543D4657.70405@opensips.org> <1413347240.77902.YahooMailNeo@web121502.mail.ne1.yahoo.com> <543E20BE.5090307@opensips.org> <1413408334.56227.YahooMailNeo@web121506.mail.ne1.yahoo.com> <543F6D50.9000100@opensips.org> Message-ID: <1413477332.98465.YahooMailNeo@web121506.mail.ne1.yahoo.com> Hi Bogdan, Thanks for your support. All of the messages until inbound ACK to OpenSIPS have record route header. Inbound ACK is having only truncated route information. It seems that IMS bench is not putting Record Route header to ACK although is it is configured like following. related part of ims bench ims_uac.xml script ================================== ;tag=[pid]SIPpTag00[call_number] [last_To:] Call-ID: [call_id] CSeq: 1 ACK Content-Length: 0 ]]> 200 OK coming to OpenSIPS =============================== Internet Protocol, Src: 192.168.2.3 (192.168.2.3), Dst: 192.168.2.141 (192.168.2.141) Version: 4 Source: 192.168.2.3 (192.168.2.3) Destination: 192.168.2.141 (192.168.2.141) User Datagram Protocol, Src Port: dsmeter_iatc (4060), Dst Port: dsmeter_iatc (4060) Source port: dsmeter_iatc (4060) Destination port: dsmeter_iatc (4060) Length: 1017 Checksum: 0x822b [correct] Session Initiation Protocol Status-Line: SIP/2.0 200 OK Status-Code: 200 [Resent Packet: False] Message Header Via: SIP/2.0/UDP 192.168.2.141:4060;received=192.168.2.141;rport=4060;branch=z9hG4bK8c0f.49ecef52.0 Transport: UDP Sent-by Address: 192.168.2.141 Sent-by port: 4060 Received: 192.168.2.141 RPort: 4060 Branch: z9hG4bK8c0f.49ecef52.0 Via: SIP/2.0/UDP 192.168.2.11:9048;branch=z9hG4bK-3672-12-4 Transport: UDP Sent-by Address: 192.168.2.11 Sent-by port: 9048 Branch: z9hG4bK-3672-12-4 Record-Route: Record-Route: Record-Route: Record-Route: Record-Route: Record-Route: 200 OK from OpenSIPS to IMS bench =============================== 2254 32.327316 192.168.2.141 192.168.2.11 SIP/SDP Status: 200 OK, with session description Frame 2254 (950 bytes on wire, 950 bytes captured) Ethernet II, Src: Vmware_22:e0:4c (00:0c:29:22:e0:4c), Dst: Vmware_d2:6a:2a (00:0c:29:d2:6a:2a) Internet Protocol, Src: 192.168.2.141 (192.168.2.141), Dst: 192.168.2.11 (192.168.2.11) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00) Total Length: 936 Identification: 0x2277 (8823) Flags: 0x04 (Don't Fragment) Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0x8ed5 [correct] Source: 192.168.2.141 (192.168.2.141) Destination: 192.168.2.11 (192.168.2.11) User Datagram Protocol, Src Port: dsmeter_iatc (4060), Dst Port: 9048 (9048) Source port: dsmeter_iatc (4060) Destination port: 9048 (9048) Length: 916 Checksum: 0xed25 [correct] Session Initiation Protocol Status-Line: SIP/2.0 200 OK Status-Code: 200 [Resent Packet: False] Message Header Via: SIP/2.0/UDP 192.168.2.11:9048;branch=z9hG4bK-3672-12-4 Transport: UDP Sent-by Address: 192.168.2.11 Sent-by port: 9048 Branch: z9hG4bK-3672-12-4 Record-Route: Record-Route: Record-Route: Record-Route: Record-Route: Record-Route: ACK from IMS bench to OpenSIPS ===================== No. Time Source Destination Protocol Info 2255 32.328365 192.168.2.11 192.168.2.141 SIP Request: ACK sip:subs002590 at 192.168.2.11:9590;transport=UDP Frame 2255 (635 bytes on wire, 635 bytes captured) Ethernet II, Src: Vmware_d2:6a:2a (00:0c:29:d2:6a:2a), Dst: Vmware_22:e0:4c (00:0c:29:22:e0:4c) Internet Protocol, Src: 192.168.2.11 (192.168.2.11), Dst: 192.168.2.141 (192.168.2.141) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 621 Identification: 0x5204 (20996) Flags: 0x04 (Don't Fragment) Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0x6093 [correct] Source: 192.168.2.11 (192.168.2.11) Destination: 192.168.2.141 (192.168.2.141) User Datagram Protocol, Src Port: 9048 (9048), Dst Port: dsmeter_iatc (4060) Source port: 9048 (9048) Destination port: dsmeter_iatc (4060) Length: 601 Checksum: 0x3460 [correct] Session Initiation Protocol Request-Line: ACK sip:subs002590 at 192.168.2.11:9590;transport=UDP SIP/2.0 Method: ACK [Resent Packet: False] Message Header Via: SIP/2.0/UDP 192.168.2.11:9048;branch=z9hG4bK-3672-12-4 Transport: UDP Sent-by Address: 192.168.2.11 Sent-by port: 9048 Branch: z9hG4bK-3672-12-4 Max-Forwards: 70 [truncated] Route: , , , , ,;tag=3672SIPpTag0012 SIP Display info: "subs002048" SIP from address: sip:subs002048 at open-ims.test SIP tag: 3672SIPpTag0012 To: "subs002590" ;tag=3672SIPpTag0113 SIP Display info: "subs002590" SIP to address: sip:subs002590 at open-ims.test SIP tag: 3672SIPpTag0113 Call-ID: 12-3672 at 192.168.2.11 CSeq: 1 ACK Sequence Number: 1 Method: ACK Content-Length: 0 ACK forwarded to wrong destination ============================== No. Time Source Destination Protocol Info 2256 32.333313 192.168.2.141 192.168.2.5 SIP Request: ACK sip:subs002590 at 192.168.2.11:9590;transport=UDP Frame 2256 (716 bytes on wire, 716 bytes captured) Ethernet II, Src: Vmware_22:e0:4c (00:0c:29:22:e0:4c), Dst: Vmware_0d:bf:1f (00:0c:29:0d:bf:1f) Internet Protocol, Src: 192.168.2.141 (192.168.2.141), Dst: 192.168.2.5 (192.168.2.5) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00) Total Length: 702 Identification: 0xf0d8 (61656) Flags: 0x04 (Don't Fragment) Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0xc163 [correct] Source: 192.168.2.141 (192.168.2.141) Destination: 192.168.2.5 (192.168.2.5) User Datagram Protocol, Src Port: dsmeter_iatc (4060), Dst Port: dsmeter_iatc (4060) Source port: dsmeter_iatc (4060) Destination port: dsmeter_iatc (4060) Length: 682 Checksum: 0x0f4e [correct] Session Initiation Protocol Request-Line: ACK sip:subs002590 at 192.168.2.11:9590;transport=UDP SIP/2.0 Method: ACK [Resent Packet: False] Message Header Record-Route: Via: SIP/2.0/UDP 192.168.2.141:4060;branch=z9hG4bK8c0f.49ecef52.2 Transport: UDP Sent-by Address: 192.168.2.141 Sent-by port: 4060 Branch: z9hG4bK8c0f.49ecef52.2 Via: SIP/2.0/UDP 192.168.2.11:9048;branch=z9hG4bK-3672-12-4 Transport: UDP Sent-by Address: 192.168.2.11 Sent-by port: 9048 Branch: z9hG4bK-3672-12-4 Max-Forwards: 70 Route: , , , , From: "subs002048" ;tag=3672SIPpTag0012 SIP Display info: "subs002048" SIP from address: sip:subs002048 at open-ims.test SIP tag: 3672SIPpTag0012 To: "subs002590" ;tag=3672SIPpTag0113 SIP Display info: "subs002590" SIP to address: sip:subs002590 at open-ims.test SIP tag: 3672SIPpTag0113 Call-ID: 12-3672 at 192.168.2.11 CSeq: 1 ACK Sequence Number: 1 Method: ACK Content-Length: 0 Kind regards, Kaan ________________________________ From: Bogdan-Andrei Iancu To: Kaan Dandin ; OpenSIPS users mailling list Cc: Gunes Kurt ; "Ibrahim Hokelek, (B?LGEM-UEKAE)" Sent: Thursday, October 16, 2014 10:01 AM Subject: Re: YNT: Re: YNT: Re: YNT: Re: [OpenSIPS-Users] RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE Hi Kaan, What you need to check is : do the ACK and BYE you receive in OpenSIPS have a Route hdr ? So, : check if the outbound INVITE (leaving OpenSIPS) has a Record-Route hdr check if the incoming 200 OK to INVITE (from UAS) has a Record-Route hdr check in inbound ACK (from UAC to OpenSIPS) has a Route hdr. Let me know. REgards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 16.10.2014 00:25, Kaan Dandin wrote: Hi Bogdan, > > >Thanks for your response. I have check the related documentation once more. >But it in fact, I was already using record_route and loose_route. > > >When I receive initial INVITE I use record_route. > > >When the following messages has to_tag , I am checking with loose_route and making the routing with t_relay. > > >This is working properly for the messages before ACK and BYE. > > >But for ACK and BYE messages it is not able to find route and making a DNS lookup and since >pcscf.open-ims.test is configured as 192.168.2.5 , it is always going to .5 openims node. > > >The difference between 180 Ringing , 200 OK which is passed properly and ACK and BYE messages seems Via headers. 180 Ringing has all the via headers. > > >related part of script for record_route() > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miha at softnet.si Fri Oct 17 10:44:02 2014 From: miha at softnet.si (Miha) Date: Fri, 17 Oct 2014 10:44:02 +0200 Subject: [OpenSIPS-Users] NAT, UPDATE problem In-Reply-To: <543FCDDF.3050800@softnet.si> References: <543FCDDF.3050800@softnet.si> Message-ID: <5440D6D2.5090101@softnet.si> hi, I have solved this by adding onreply route and it it I put fix_nated_contact(); Now contact in 200ok is fixed and media is ok. tnx miha On 16/10/2014 15:53, Miha wrote: > Hi, > > in my cfg file i have this: > > if (nat_uac_test("18")) { > xlog("fixing nat"); > if (method=="REGISTER") { > > fix_nated_register(); > fix_nated_contact(); > } else { > fix_nated_contact(); > } > force_rport(); > } > > But when 200ok with sdp is send this part of script does not execute > as in contact is still private ip. I have 18 in nat_uac_test so if src > port port in via are different this should be triggered but it is not > that is why proxy sends media to private ip. > > Here is my sip trace: > > http://pastebin.com/KvNdttj9 > > Tnx > > miha > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From bogdan at opensips.org Fri Oct 17 11:16:53 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 17 Oct 2014 12:16:53 +0300 Subject: [OpenSIPS-Users] branch computation failed In-Reply-To: <1413513872354-7594086.post@n2.nabble.com> References: <1412825847529-7593895.post@n2.nabble.com> <5436691D.4010006@opensips.org> <1412906905090-7593931.post@n2.nabble.com> <543B7EEE.9000505@opensips.org> <201410131535093743451@gmail.com> <543B82E2.7010003@opensips.org> <201410140951152215038@gmail.com> <543D5199.4000204@opensips.org> <1413513872354-7594086.post@n2.nabble.com> Message-ID: <5440DE85.4050200@opensips.org> Hi, Hopefully I found and fix the problem - see this fixing patch: https://gist.github.com/bogdan-iancu/2875ae7cc99a2180463d Apply it together with the prev one (just in case). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 17.10.2014 05:44, chow wrote: > Hi: > that error come out again. > I doubt there have memory leak. that server have 32G memory. > the opensips config: > default Start option S_MEMORY=4096 and P_MEMORY=128 > children(process) 128 > then I think opensips have 4096 + 128*128 = 20480M memory, this is > right? > opensips hold memory never free , top command result: > > Tasks: 529 total, 1 running, 528 sleeping, 0 stopped, 0 zombie > Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, > 0.0%st > Mem: 32830608k total, 32589824k used, 240784k free, 138720k buffers > Swap: 16482296k total, 516k used, 16481780k free, 30601400k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 11928 opensips 20 0 4368m 455m 454m S 0.3 1.4 51:17.91 opensips > 11791 opensips 20 0 4368m 6172 5004 S 0.0 0.0 0:00.19 opensips > 11792 opensips 20 0 4368m 1960 728 S 0.0 0.0 0:00.18 opensips > 11793 opensips 20 0 4368m 1404 240 S 0.0 0.0 0:00.06 opensips > 11794 opensips 20 0 4368m 1952 776 S 0.0 0.0 0:00.07 opensips > 11795 opensips 20 0 4368m 2512 1208 S 0.0 0.0 1:07.58 opensips > 11796 opensips 20 0 4368m 2172 992 S 0.0 0.0 0:00.06 opensips > 11797 opensips 20 0 4368m 1812 640 S 0.0 0.0 0:00.06 opensips > 11798 opensips 20 0 4368m 1812 640 S 0.0 0.0 0:00.05 opensips > 11799 opensips 20 0 4368m 514m 513m S 0.0 1.6 79:11.69 opensips > 11800 opensips 20 0 4368m 514m 513m S 0.0 1.6 78:20.70 opensips > 11801 opensips 20 0 4368m 514m 513m S 0.0 1.6 78:05.47 opensips > 11802 opensips 20 0 4368m 514m 513m S 0.0 1.6 79:09.96 opensips > 11803 opensips 20 0 4368m 514m 513m S 0.0 1.6 79:05.35 opensips > 11804 opensips 20 0 4368m 514m 513m S 0.0 1.6 78:14.65 opensips > 11805 opensips 20 0 4368m 514m 513m S 0.0 1.6 78:06.60 opensips > 11806 opensips 20 0 4368m 514m 513m S 0.0 1.6 79:19.44 opensips > 11807 opensips 20 0 4368m 514m 513m S 0.0 1.6 79:18.87 opensips > 11808 opensips 20 0 4368m 514m 513m S 0.0 1.6 78:16.96 opensips > 11809 opensips 20 0 4368m 514m 513m S 0.0 1.6 79:27.83 opensips > 11810 opensips 20 0 4368m 514m 513m S 0.0 1.6 78:11.83 opensips > 11811 opensips 20 0 4368m 514m 513m S 0.0 1.6 79:11.44 opensips > 11812 opensips 20 0 4368m 514m 513m S 0.0 1.6 78:21.19 opensips > 11813 opensips 20 0 4368m 514m 513m S 0.0 1.6 78:01.53 opensips > 11814 opensips 20 0 4368m 514m 513m S 0.0 1.6 78:51.01 opensips > > the free command have result: > free > total used free shared buffers cached > Mem: 32830608 32592164 238444 0 140008 30602304 > -/+ buffers/cache: 1849852 30980756 > Swap: 16482296 516 16481780 > > > > > the opensips log: > Oct 15 10:21:02 localhost /usr/sbin/opensips[11795]: > ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe > Oct 15 10:27:01 localhost /usr/sbin/opensips[11795]: > ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe > Oct 15 10:42:02 localhost /usr/sbin/opensips[11795]: > ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe > Oct 15 10:47:02 localhost /usr/sbin/opensips[11795]: > ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe > Oct 15 11:02:01 localhost /usr/sbin/opensips[11795]: > ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe > Oct 15 11:09:02 localhost /usr/sbin/opensips[11795]: > ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe > Oct 15 11:14:02 localhost /usr/sbin/opensips[11795]: > ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe > Oct 15 11:23:01 localhost /usr/sbin/opensips[11795]: > ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe > ... > ... > ... > ... > ... > Oct 17 03:58:01 localhost /usr/sbin/opensips[11795]: > ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe > Oct 17 04:14:01 localhost /usr/sbin/opensips[11795]: > ERROR:mi_fifo:mi_fifo_reply: fifo_error: write error: Broken pipe > Oct 17 04:19:45 localhost /usr/sbin/opensips[11849]: > ERROR:core:branch_builder: writing label failed, remaining size is 0 > (initial 46) > buf=[z9hG4bK76c7.00000008ffffffffffffffffffffffffffffffffffffff] > Oct 17 04:19:45 localhost /usr/sbin/opensips[11849]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 17 04:19:45 localhost /usr/sbin/opensips[11849]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 17 04:19:45 localhost /usr/sbin/opensips[11859]: > ERROR:core:branch_builder: writing label failed, remaining size is 0 > (initial 46) > buf=[z9hG4bK76c7.10000008ffffffffffffffffffffffffffffffffffffff] > Oct 17 04:19:45 localhost /usr/sbin/opensips[11859]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 17 04:19:45 localhost /usr/sbin/opensips[11859]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 17 04:19:53 localhost /usr/sbin/opensips[11816]: > ERROR:core:branch_builder: writing label failed, remaining size is 0 > (initial 46) > buf=[z9hG4bK76c7.20000008ffffffffffffffffffffffffffffffffffffff] > Oct 17 04:19:53 localhost /usr/sbin/opensips[11816]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 17 04:19:53 localhost /usr/sbin/opensips[11816]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 17 04:19:53 localhost /usr/sbin/opensips[11862]: > ERROR:core:branch_builder: writing label failed, remaining size is 0 > (initial 46) > buf=[z9hG4bK76c7.30000008ffffffffffffffffffffffffffffffffffffff] > Oct 17 04:19:53 localhost /usr/sbin/opensips[11862]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 17 04:19:53 localhost /usr/sbin/opensips[11862]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 17 04:19:54 localhost /usr/sbin/opensips[11921]: > ERROR:core:branch_builder: writing label failed, remaining size is 0 > (initial 46) > buf=[z9hG4bK76c7.40000008ffffffffffffffffffffffffffffffffffffff] > Oct 17 04:19:54 localhost /usr/sbin/opensips[11921]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 17 04:19:54 localhost /usr/sbin/opensips[11921]: > ERROR:tm:t_forward_nonack: failure to add branches > Oct 17 04:19:54 localhost /usr/sbin/opensips[11829]: > ERROR:core:branch_builder: writing label failed, remaining size is 0 > (initial 46) > buf=[z9hG4bK76c7.50000008ffffffffffffffffffffffffffffffffffffff] > Oct 17 04:19:54 localhost /usr/sbin/opensips[11829]: > ERROR:tm:pre_print_uac_request: branch computation failed > Oct 17 04:19:54 localhost /usr/sbin/opensips[11829]: > ERROR:tm:t_forward_nonack: failure to add branches > > > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/branch-computation-failed-tp7593895p7594086.html > Sent from the OpenSIPS - Users mailing list archive at Nabble.com. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From bogdan at opensips.org Fri Oct 17 11:18:43 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 17 Oct 2014 12:18:43 +0300 Subject: [OpenSIPS-Users] tcp keep-alive time In-Reply-To: <478de7f3.666.1491b5932da.Coremail.aihuawu2012@163.com> References: <478de7f3.666.1491b5932da.Coremail.aihuawu2012@163.com> Message-ID: <5440DEF3.8090803@opensips.org> Hi Geroge, You want to change the keepalive or the lifetime of the TCP conn ? As it sounds to me you are more looking for lifetime (to have closed asap): http://www.opensips.org/Documentation/Script-CoreParameters-1-11#toc91 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 17.10.2014 02:44, george wu wrote: > Hi, guys: > > How can I adjust the global tcp keep alive time? what's the default in > opensips? > I want it to close as soon as possible so that tcp deployment can scale. > > George Wu > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From aihuawu2012 at 163.com Fri Oct 17 13:05:12 2014 From: aihuawu2012 at 163.com (george wu) Date: Fri, 17 Oct 2014 19:05:12 +0800 (CST) Subject: [OpenSIPS-Users] tcp keep-alive time In-Reply-To: <5440DEF3.8090803@opensips.org> References: <478de7f3.666.1491b5932da.Coremail.aihuawu2012@163.com> <5440DEF3.8090803@opensips.org> Message-ID: <6c87981c.c7d9.1491dc8637c.Coremail.aihuawu2012@163.com> Bogdan-Andrei: Thank you very much for so many helps. Yes, tcp_connection_lifetime. As you said before, udp scale up very well. But tcp is not. However, I have no choice other than tcp. If the tcp get closed often, is it similar to udp? Recently I modify the udp_server.c so that I defragment the udp package manually. (For ice, the packet is about 1700+ bytes.) This approach works 80% of time. However the udp packages sometimes come out of order which makes the linphone parser gets a coredump. I googled a lot, some router's mtu is 1500 (payload 1472), some 1400. the only requirement is minimum 576 bytes. So I finally give up the udp. I think tcp is the only reliable way to deliver big packet. Unless your packet is less than 576 bytes. But my packet is 1700 bytes. George At 2014-10-17 17:18:43, "Bogdan-Andrei Iancu" wrote: Hi Geroge, You want to change the keepalive or the lifetime of the TCP conn ? As it sounds to me you are more looking for lifetime (to have closed asap): http://www.opensips.org/Documentation/Script-CoreParameters-1-11#toc91 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 17.10.2014 02:44, george wu wrote: Hi, guys: How can I adjust the global tcp keep alive time? what's the default in opensips? I want it to close as soon as possible so that tcp deployment can scale. George Wu _______________________________________________ Users mailing list Users at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From goup2010 at gmail.com Fri Oct 17 21:52:00 2014 From: goup2010 at gmail.com (Dragomir Haralambiev) Date: Fri, 17 Oct 2014 22:52:00 +0300 Subject: [OpenSIPS-Users] clear location table Message-ID: Hello, This is part of my script: modparam("registrar", "default_expires", 900) I see into location table: expires 2014-10-14 21:56:30 last_modified 2014-10-14 20:56:30 expires 2014-10-17 22:43:34 last_modified 2014-10-17 21:43:34 expires 2014-10-07 23:26:44 last_modified 2014-10-07 23:24:44 How to clear location table when registration is expaered? Best regards, PlayMen -------------- next part -------------- An HTML attachment was scrubbed... URL: From kondik at go2.pl Fri Oct 17 22:12:54 2014 From: kondik at go2.pl (kondik) Date: Fri, 17 Oct 2014 13:12:54 -0700 (PDT) Subject: [OpenSIPS-Users] OpenSIPS and Apple Push Notification In-Reply-To: <53971577.3050502@opensips.org> References: <1402325945452-7591783.post@n2.nabble.com> <53971577.3050502@opensips.org> Message-ID: <1413576774396-7594110.post@n2.nabble.com> Hello, Unfortunatelly this link: http://web.archive.org/web/20131018015829/http://techvoiper.com/opensips-and-apple-push-notification-service-integration/ doesn't work again :( If you could repair this link - I will be grateful Thanks in advance! Regards, Kondik -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-and-Apple-Push-Notification-tp7591783p7594110.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From kondik at go2.pl Fri Oct 17 22:34:30 2014 From: kondik at go2.pl (kondik) Date: Fri, 17 Oct 2014 13:34:30 -0700 (PDT) Subject: [OpenSIPS-Users] OpenSIPS and Apple Push Notification In-Reply-To: <1402376798211-7591786.post@n2.nabble.com> References: <1402325945452-7591783.post@n2.nabble.com> <1402376798211-7591786.post@n2.nabble.com> Message-ID: <1413578070559-7594111.post@n2.nabble.com> microx wrote > [...] Next, with the callee's SIP ID, the external process checks whether > the callee uses ios-version App. If so, the external process retrieves the > callee's APNS token based on the received SIP ID and sends an notification > with the token to the APNS server. [...] How do you check whether the calee uses ios ? And how you can obtain APNS token based on the SIP ID ? Could you explain this or provide any examples? Thanks in advance! -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-and-Apple-Push-Notification-tp7591783p7594111.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From tito at xsvoce.com Sat Oct 18 00:34:16 2014 From: tito at xsvoce.com (Tito Cumpen) Date: Fri, 17 Oct 2014 18:34:16 -0400 Subject: [OpenSIPS-Users] issues loading linbmongo.c.0.6 after compilation Message-ID: group im having issues after restarting opensips loading cache_db_mongol which module that depends on libmongo ERROR:core:sr_load_module: could not open module : libmongoc.so.0.6: cannot open shared object file: No such file or directory althought I used ln -s libmongoc.so.0.60 /usr/src/mongo-c-driver-0.6/libmongoc.so when I compiled any idea why opensips has issues finding it now? thanks, Tito -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Sat Oct 18 00:53:13 2014 From: liviu at opensips.org (Liviu Chircu) Date: Sat, 18 Oct 2014 01:53:13 +0300 Subject: [OpenSIPS-Users] issues loading linbmongo.c.0.6 after compilation In-Reply-To: References: Message-ID: <54419DD9.8060208@opensips.org> Hi Tito, You need to keep playing with the library paths until the command "ldd ...../cachedb_mongodb.so" has clean output, with all dependencies located. No need to start OpenSIPS until this is solved. Hint: If I remember correctly, libmongoc installs in /usr/local/lib, so I would run: echo "/usr/local/lib" > /etc/ld.so.conf.d/libmongoc.conf && ldconfig Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 18.10.2014 01:34, Tito Cumpen wrote: > > group im having issues after restarting opensips loading > cache_db_mongol which module that depends on libmongo > > ERROR:core:sr_load_module: could not open module > : libmongoc.so.0.6: cannot > open shared object file: No such file or directory > > althought I used > ln-slibmongoc.so.0.60/usr/src/mongo-c-driver-0.6/libmongoc.so when I > compiled > > > > any idea why opensips has issues finding it now? > > > > thanks, > > Tito > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Sat Oct 18 10:30:02 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Sat, 18 Oct 2014 11:30:02 +0300 Subject: [OpenSIPS-Users] tcp keep-alive time In-Reply-To: <6c87981c.c7d9.1491dc8637c.Coremail.aihuawu2012@163.com> References: <478de7f3.666.1491b5932da.Coremail.aihuawu2012@163.com> <5440DEF3.8090803@opensips.org> <6c87981c.c7d9.1491dc8637c.Coremail.aihuawu2012@163.com> Message-ID: <5442250A.1050406@opensips.org> George, If the TCP conn closes, it is not much you can do from the server side...you cannot open a TCP conn behind NAT. You have to wait for the UAC to re-connect again. About your manual UDP defrag - I do not think it is a good it - the UDP stack must to that for you, you cannot simulate it on top of datagram. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 17.10.2014 14:05, george wu wrote: > Bogdan-Andrei: > > Thank you very much for so many helps. > Yes, tcp_connection_lifetime. > As you said before, udp scale up very well. But tcp is not. > However, I have no choice other than tcp. If the tcp get closed often, > is it similar to udp? > > Recently I modify the udp_server.c so that I defragment the udp > package manually. > (For ice, the packet is about 1700+ bytes.) > This approach works 80% of time. > > However the udp packages sometimes come out of order > which makes the linphone parser gets a coredump. > I googled a lot, some router's mtu is 1500 (payload 1472), some 1400. > the only requirement is minimum 576 bytes. > So I finally give up the udp. I think tcp is the only reliable way to > deliver big packet. > Unless your packet is less than 576 bytes. But my packet is 1700 bytes. > > George > > > > > At 2014-10-17 17:18:43, "Bogdan-Andrei Iancu" wrote: > > Hi Geroge, > > You want to change the keepalive or the lifetime of the TCP conn ? > > As it sounds to me you are more looking for lifetime (to have > closed asap): > http://www.opensips.org/Documentation/Script-CoreParameters-1-11#toc91 > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 17.10.2014 02:44, george wu wrote: >> Hi, guys: >> >> How can I adjust the global tcp keep alive time? what's the >> default in opensips? >> I want it to close as soon as possible so that tcp deployment can >> scale. >> >> George Wu >> >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sermj2012 at gmail.com Sat Oct 18 14:34:38 2014 From: sermj2012 at gmail.com (Nandini madhu) Date: Sat, 18 Oct 2014 18:04:38 +0530 Subject: [OpenSIPS-Users] Regarding ARM architecture support of Opensips Message-ID: Dear all, Greetings. I am working on Opensips for Linux environment. But, i don't have any idea regarding usage of Opensips in arm environment/embedded Linux. Please help me in this regard, how can i port Opensips into an embedded linux device. Kindly advice. Regards Sermj2012 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aihuawu2012 at 163.com Sun Oct 19 01:46:08 2014 From: aihuawu2012 at 163.com (george wu) Date: Sun, 19 Oct 2014 07:46:08 +0800 (CST) Subject: [OpenSIPS-Users] tcp keep-alive time In-Reply-To: <5442250A.1050406@opensips.org> References: <478de7f3.666.1491b5932da.Coremail.aihuawu2012@163.com> <5440DEF3.8090803@opensips.org> <6c87981c.c7d9.1491dc8637c.Coremail.aihuawu2012@163.com> <5442250A.1050406@opensips.org> Message-ID: <82bcc34.52a.14925a767a5.Coremail.aihuawu2012@163.com> So it seems the sctp is the best. reliable and scalable. At 2014-10-18 16:30:02, "Bogdan-Andrei Iancu" wrote: George, If the TCP conn closes, it is not much you can do from the server side...you cannot open a TCP conn behind NAT. You have to wait for the UAC to re-connect again. About your manual UDP defrag - I do not think it is a good it - the UDP stack must to that for you, you cannot simulate it on top of datagram. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 17.10.2014 14:05, george wu wrote: Bogdan-Andrei: Thank you very much for so many helps. Yes, tcp_connection_lifetime. As you said before, udp scale up very well. But tcp is not. However, I have no choice other than tcp. If the tcp get closed often, is it similar to udp? Recently I modify the udp_server.c so that I defragment the udp package manually. (For ice, the packet is about 1700+ bytes.) This approach works 80% of time. However the udp packages sometimes come out of order which makes the linphone parser gets a coredump. I googled a lot, some router's mtu is 1500 (payload 1472), some 1400. the only requirement is minimum 576 bytes. So I finally give up the udp. I think tcp is the only reliable way to deliver big packet. Unless your packet is less than 576 bytes. But my packet is 1700 bytes. George At 2014-10-17 17:18:43, "Bogdan-Andrei Iancu" wrote: Hi Geroge, You want to change the keepalive or the lifetime of the TCP conn ? As it sounds to me you are more looking for lifetime (to have closed asap): http://www.opensips.org/Documentation/Script-CoreParameters-1-11#toc91 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 17.10.2014 02:44, george wu wrote: Hi, guys: How can I adjust the global tcp keep alive time? what's the default in opensips? I want it to close as soon as possible so that tcp deployment can scale. George Wu _______________________________________________ Users mailing list Users at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Sun Oct 19 11:37:26 2014 From: liviu at opensips.org (Liviu Chircu) Date: Sun, 19 Oct 2014 12:37:26 +0300 Subject: [OpenSIPS-Users] Regarding ARM architecture support of Opensips In-Reply-To: References: Message-ID: <54438656.3010608@opensips.org> Hello Nandini, The build system supports ARM architectures as well, so it should compile right away! If run into any sort of issue, please post it in this thread. Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 18.10.2014 15:34, Nandini madhu wrote: > Dear all, > Greetings. > > I am working on Opensips for Linux environment. But, i don't have any > idea regarding usage of Opensips in arm environment/embedded Linux. > > Please help me in this regard, how can i port Opensips into an > embedded linux device. > > Kindly advice. > > Regards > > Sermj2012 > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhouxiaoqiang.mstech at gmail.com Mon Oct 20 08:55:16 2014 From: zhouxiaoqiang.mstech at gmail.com (chow) Date: Sun, 19 Oct 2014 23:55:16 -0700 (PDT) Subject: [OpenSIPS-Users] branch computation failed In-Reply-To: <5440DE85.4050200@opensips.org> References: <1412825847529-7593895.post@n2.nabble.com> <5436691D.4010006@opensips.org> <1412906905090-7593931.post@n2.nabble.com> <543B7EEE.9000505@opensips.org> <201410131535093743451@gmail.com> <543B82E2.7010003@opensips.org> <201410140951152215038@gmail.com> <543D5199.4000204@opensips.org> <1413513872354-7594086.post@n2.nabble.com> <5440DE85.4050200@opensips.org> Message-ID: <1413788116516-7594122.post@n2.nabble.com> Hi: three days gone. that error not come out . thank you. -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/branch-computation-failed-tp7593895p7594122.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From zhouxiaoqiang.mstech at gmail.com Mon Oct 20 09:06:30 2014 From: zhouxiaoqiang.mstech at gmail.com (chow) Date: Mon, 20 Oct 2014 00:06:30 -0700 (PDT) Subject: [OpenSIPS-Users] add date header for every SIP Message Message-ID: <1413788790605-7594123.post@n2.nabble.com> Hi: I want to append Date header for every SIP Message. I called append_time function from opensips.cfg that work fine , but when called t_uac_dlg by mi Interface, that message not have Date header. is there have some way to add Date header for every SIP Message , like as From and To header? -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/add-date-header-for-every-SIP-Message-tp7594123.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From kaandandin at yahoo.com Mon Oct 20 09:25:31 2014 From: kaandandin at yahoo.com (Kaan Dandin) Date: Mon, 20 Oct 2014 10:25:31 +0300 Subject: [OpenSIPS-Users] YNT: Re: YNT: Re: YNT: Re: YNT: Re: RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE Message-ID: <87qjrvwjysax95g79onktby0.1413789931582@email.android.com> Hi Bogdan,? Thanks for your support. I am also trying dialog support as an option.? But I found one workaround for the previous option. I have changed the pcscf name of second openims instance which is .5 as pcscf2.? And added this hostname in /etc/hosts of opensips.? Now opensips is able to send the messages to correct openims pcscf after dns lookup.? But in the last message of Ok and Ack coming from openims nodes to ims bench I am making the routing with t_relay (udp:192.168.2.11:4060) instead of t_relay.? But this response is not accepted at ims bench it keeps sending Ok and ack messages.? What's the difference between t_relay() and t_relay (udp:192.168.2.11:4060) other than defining the destination.? What's may be reason at ims bench keeps sending the messages.? Kind regards,? Kaan Samsung Mobile taraf?ndan g?nderildi
-------- Orjinal mesaj --------
Kimden: Bogdan-Andrei Iancu
Tarih:17 10 2014 10:31 (GMT+02:00)
Al?c?: Kaan Dandin ,OpenSIPS users mailling list
Cc: Gunes Kurt ,"Ibrahim Hokelek, (B?LGEM-UEKAE)"
Konu: Re: YNT: Re: YNT: Re: YNT: Re: [OpenSIPS-Users] RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE
Kaan, as per my previous email, the problem is in sipp, not in openims. To get rid of the large set of Route header, I suggest you to use dialog support on opensips with topologyhiding. http://www.opensips.org/html/docs/modules/1.11.x/dialog.html#id296413 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 16.10.2014 21:43, Kaan Dandin wrote: Hi Bogdan, I have changed the ims_uac.xml of IMS Bench. Now it includes record_route header. But via header in ACK is not having all of the passed nodes. The reason looks, although Open IMS receives all of the passed nodes in via header of 200 OK it received from Open SIPS, it does not include all of them in via header of 200 Ok response sent to OpenSIPS. Therefore ACK from UAC is ended now at Open SIPS instead of Open IMS. Now I need to troubleshoot OpenIMS configuration. BR, -------------- next part -------------- An HTML attachment was scrubbed... URL: From miha at softnet.si Mon Oct 20 10:51:11 2014 From: miha at softnet.si (Miha) Date: Mon, 20 Oct 2014 10:51:11 +0200 Subject: [OpenSIPS-Users] table_version: invalid version Message-ID: <5444CCFF.9090102@softnet.si> Hi, i have installed opensips from repository. I am using centos os. From what i can see in logs my opensips does not start do to wrong db version Oct 20 10:48:26 sbc-adria /usr/sbin/opensips[22872]: ERROR:core:db_check_table_version: invalid version 0 for table suscriber found, expected 7 Oct 20 10:48:26 sbc-adria /usr/sbin/opensips[22872]: ERROR:auth_db:auth_fixup: error during table version check. I tried to import db also from source file on web but still the same. tnx for help miha From liviu at opensips.org Mon Oct 20 11:05:23 2014 From: liviu at opensips.org (Liviu Chircu) Date: Mon, 20 Oct 2014 12:05:23 +0300 Subject: [OpenSIPS-Users] table_version: invalid version In-Reply-To: <5444CCFF.9090102@softnet.si> References: <5444CCFF.9090102@softnet.si> Message-ID: <5444D053.6020109@opensips.org> Hi miha, It looks like you have a typo in your script. Probably something like "www_authorize("...", "*suscriber*")" !! Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 10/20/2014 11:51 AM, Miha wrote: > Hi, > > i have installed opensips from repository. I am using centos os. From > what i can see in logs my opensips does not start do to wrong db version > > Oct 20 10:48:26 sbc-adria /usr/sbin/opensips[22872]: > ERROR:core:db_check_table_version: invalid version 0 for table > suscriber found, expected 7 > Oct 20 10:48:26 sbc-adria /usr/sbin/opensips[22872]: > ERROR:auth_db:auth_fixup: error during table version check. > > > I tried to import db also from source file on web but still the same. > > tnx for help > miha > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From miha at softnet.si Mon Oct 20 11:17:51 2014 From: miha at softnet.si (Miha) Date: Mon, 20 Oct 2014 11:17:51 +0200 Subject: [OpenSIPS-Users] table_version: invalid version In-Reply-To: <5444D053.6020109@opensips.org> References: <5444CCFF.9090102@softnet.si> <5444D053.6020109@opensips.org> Message-ID: <5444D33F.7030702@softnet.si> Hi Liviu, tnx for quick reponse. Yes, you were right, I was looking at logs and did not know that this could mean also invalid syntax. tnx miha On 20/10/2014 11:05, Liviu Chircu wrote: > Hi miha, > > It looks like you have a typo in your script. Probably something like > "www_authorize("...", "*suscriber*")" !! > > Best regards, > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > On 10/20/2014 11:51 AM, Miha wrote: >> Hi, >> >> i have installed opensips from repository. I am using centos os. From >> what i can see in logs my opensips does not start do to wrong db version >> >> Oct 20 10:48:26 sbc-adria /usr/sbin/opensips[22872]: >> ERROR:core:db_check_table_version: invalid version 0 for table >> suscriber found, expected 7 >> Oct 20 10:48:26 sbc-adria /usr/sbin/opensips[22872]: >> ERROR:auth_db:auth_fixup: error during table version check. >> >> >> I tried to import db also from source file on web but still the same. >> >> tnx for help >> miha >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From miha at softnet.si Mon Oct 20 11:55:29 2014 From: miha at softnet.si (Miha) Date: Mon, 20 Oct 2014 11:55:29 +0200 Subject: [OpenSIPS-Users] table_version: invalid version In-Reply-To: <5444D33F.7030702@softnet.si> References: <5444CCFF.9090102@softnet.si> <5444D053.6020109@opensips.org> <5444D33F.7030702@softnet.si> Message-ID: <5444DC11.6060302@softnet.si> Liviu, this is the same thing: ERROR:core:db_check_table_version: invalid version 6 for table dr_gateways found, expected 5 as i do not find any syntax error. tnx miha On 20/10/2014 11:17, Miha wrote: > Hi Liviu, > > tnx for quick reponse. Yes, you were right, I was looking at logs and > did not know that this could mean also invalid syntax. > > tnx > miha > > On 20/10/2014 11:05, Liviu Chircu wrote: >> Hi miha, >> >> It looks like you have a typo in your script. Probably something like >> "www_authorize("...", "*suscriber*")" !! >> >> Best regards, >> Liviu Chircu >> OpenSIPS Developer >> http://www.opensips-solutions.com >> On 10/20/2014 11:51 AM, Miha wrote: >>> Hi, >>> >>> i have installed opensips from repository. I am using centos os. >>> From what i can see in logs my opensips does not start do to wrong >>> db version >>> >>> Oct 20 10:48:26 sbc-adria /usr/sbin/opensips[22872]: >>> ERROR:core:db_check_table_version: invalid version 0 for table >>> suscriber found, expected 7 >>> Oct 20 10:48:26 sbc-adria /usr/sbin/opensips[22872]: >>> ERROR:auth_db:auth_fixup: error during table version check. >>> >>> >>> I tried to import db also from source file on web but still the same. >>> >>> tnx for help >>> miha >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Mon Oct 20 12:48:41 2014 From: liviu at opensips.org (Liviu Chircu) Date: Mon, 20 Oct 2014 13:48:41 +0300 Subject: [OpenSIPS-Users] table_version: invalid version In-Reply-To: <5444DC11.6060302@softnet.si> References: <5444CCFF.9090102@softnet.si> <5444D053.6020109@opensips.org> <5444D33F.7030702@softnet.si> <5444DC11.6060302@softnet.si> Message-ID: <5444E889.5060002@opensips.org> It looks like you're using a pre-1.11 OpenSIPS and you are pointing it to a future (1.11+) dr_gateways table structure. There are several ways to fix this specific problem: - simply change version table entry from 6 -> 5 only if no other OpenSIPS instance uses it - create a new database for your current version with opensipsdbctl Liviu On 10/20/2014 12:55 PM, Miha wrote: > Liviu, > > this is the same thing: ERROR:core:db_check_table_version: invalid > version 6 for table dr_gateways found, expected 5 > > as i do not find any syntax error. > > tnx > miha > > On 20/10/2014 11:17, Miha wrote: >> Hi Liviu, >> >> tnx for quick reponse. Yes, you were right, I was looking at logs and >> did not know that this could mean also invalid syntax. >> >> tnx >> miha >> >> On 20/10/2014 11:05, Liviu Chircu wrote: >>> Hi miha, >>> >>> It looks like you have a typo in your script. Probably something >>> like "www_authorize("...", "*suscriber*")" !! >>> >>> Best regards, >>> Liviu Chircu >>> OpenSIPS Developer >>> http://www.opensips-solutions.com >>> On 10/20/2014 11:51 AM, Miha wrote: >>>> Hi, >>>> >>>> i have installed opensips from repository. I am using centos os. >>>> From what i can see in logs my opensips does not start do to wrong >>>> db version >>>> >>>> Oct 20 10:48:26 sbc-adria /usr/sbin/opensips[22872]: >>>> ERROR:core:db_check_table_version: invalid version 0 for table >>>> suscriber found, expected 7 >>>> Oct 20 10:48:26 sbc-adria /usr/sbin/opensips[22872]: >>>> ERROR:auth_db:auth_fixup: error during table version check. >>>> >>>> >>>> I tried to import db also from source file on web but still the same. >>>> >>>> tnx for help >>>> miha >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From miha at softnet.si Mon Oct 20 14:01:24 2014 From: miha at softnet.si (Miha) Date: Mon, 20 Oct 2014 14:01:24 +0200 Subject: [OpenSIPS-Users] table_version: invalid version In-Reply-To: <5444E889.5060002@opensips.org> References: <5444CCFF.9090102@softnet.si> <5444D053.6020109@opensips.org> <5444D33F.7030702@softnet.si> <5444DC11.6060302@softnet.si> <5444E889.5060002@opensips.org> Message-ID: <5444F994.2020508@softnet.si> Tnx Liviu, I have imported mysql shama of 1.10 and now it is ok. tnx miha On 20/10/2014 12:48, Liviu Chircu wrote: > It looks like you're using a pre-1.11 OpenSIPS and you are pointing it > to a future (1.11+) dr_gateways table structure. There are several > ways to fix this specific problem: > > - simply change version table entry from 6 -> 5 only if no other > OpenSIPS instance uses it > - create a new database for your current version with opensipsdbctl > > Liviu > > On 10/20/2014 12:55 PM, Miha wrote: >> Liviu, >> >> this is the same thing: ERROR:core:db_check_table_version: invalid >> version 6 for table dr_gateways found, expected 5 >> >> as i do not find any syntax error. >> >> tnx >> miha >> >> On 20/10/2014 11:17, Miha wrote: >>> Hi Liviu, >>> >>> tnx for quick reponse. Yes, you were right, I was looking at logs >>> and did not know that this could mean also invalid syntax. >>> >>> tnx >>> miha >>> >>> On 20/10/2014 11:05, Liviu Chircu wrote: >>>> Hi miha, >>>> >>>> It looks like you have a typo in your script. Probably something >>>> like "www_authorize("...", "*suscriber*")" !! >>>> >>>> Best regards, >>>> Liviu Chircu >>>> OpenSIPS Developer >>>> http://www.opensips-solutions.com >>>> On 10/20/2014 11:51 AM, Miha wrote: >>>>> Hi, >>>>> >>>>> i have installed opensips from repository. I am using centos os. >>>>> From what i can see in logs my opensips does not start do to wrong >>>>> db version >>>>> >>>>> Oct 20 10:48:26 sbc-adria /usr/sbin/opensips[22872]: >>>>> ERROR:core:db_check_table_version: invalid version 0 for table >>>>> suscriber found, expected 7 >>>>> Oct 20 10:48:26 sbc-adria /usr/sbin/opensips[22872]: >>>>> ERROR:auth_db:auth_fixup: error during table version check. >>>>> >>>>> >>>>> I tried to import db also from source file on web but still the same. >>>>> >>>>> tnx for help >>>>> miha >>>>> >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From gn62 at gmx.us Mon Oct 20 23:56:08 2014 From: gn62 at gmx.us (Gary Nyquist) Date: Mon, 20 Oct 2014 23:56:08 +0200 Subject: [OpenSIPS-Users] Call external program from reply_rote Message-ID: Hi, I need to call an external program from the REPLY_ROUTE (on getting 200 OK). As per the doc, "exec_msg" and "exec_avp" can be used from REQUEST_ROUTE & FAILURE_ROUTE only. Is there any alternative methods to run external programs from the REPLY_ROUTE? Best Regards, - Gary From pflowers at mergecom.co.nz Tue Oct 21 03:19:21 2014 From: pflowers at mergecom.co.nz (Peter Flowers) Date: Tue, 21 Oct 2014 14:19:21 +1300 Subject: [OpenSIPS-Users] Issue with /etc/init.d/opensips on new test install Message-ID: Hi I was following the OpenSIPS Kick Start video but using Debian 7.4 and OpenSIPS 1.11.3. Everything went pretty well till the end and starting openSIPS with the init script. I set the install prefix as /usr/local/opensips and created a residential cfg file. This I renamed to opensips_residential.cfg. When I went to start opensips with /etc/init.d/opensips start there were lots of critical errors like these Oct 20 22:43:44 [3363] CRITICAL:core:yyerror: parse error in config file /usr/local/opensips//etc/opensips/opensips.cfg, line 255, column 15-16: unknown command , missing loadmodule? Oct 20 22:43:44 [3363] CRITICAL:core:yyerror: parse error in config file /usr/local/opensips//etc/opensips/opensips.cfg, line 256, column 19-20: unknown command , missing loadmodule? Oct 20 22:43:44 [3363] CRITICAL:core:yyerror: parse error in config file /usr/local/opensips//etc/opensips/opensips.cfg, line 276, column 22-23: unknown command , missing loadmodule? Oct 20 22:43:44 [3363] ERROR:core:main: bad config file (79 errors) The new layout of the init.d script is a bit different than the video, particularly the beginning. It looks to me like the init.d script is not picking up the correct location of the opensips_residential.cfg file and picking a default opensips.cfg file. This is what I put in the init.d PATH=/sbin:/bin:/usr/sbin:/usr/bin DAEMON=*/usr/local/opensips/sbin/opensips* NAME=opensips DESC=opensips CFGFILE=*/usr/local/opensips/etc/opensips/opensips_residential.cfg* M4CFGFILE=/etc/opensips/opensips.m4 M4ARCHIVEDIR=/etc/opensips/archive HOMEDIR=/var/run/opensips PIDFILE=$HOMEDIR/$NAME.pid DEFAULTS=/etc/default/opensips RUN_OPENSIPS=no and the options line looks like this OPTIONS="-P $PIDFILE -m $S_MEMORY -M $P_MEMORY -u $USER -g $GROUP *-f /usr/local/opensips/etc/opensips/opensips_residential.cfg*" Any ideas very gratefully accepted -- Peter Flowers -------------- next part -------------- An HTML attachment was scrubbed... URL: From tito at xsvoce.com Tue Oct 21 03:34:27 2014 From: tito at xsvoce.com (Tito Cumpen) Date: Mon, 20 Oct 2014 21:34:27 -0400 Subject: [OpenSIPS-Users] Issue with /etc/init.d/opensips on new test install In-Reply-To: References: Message-ID: Peter, Verify that your modules path within the cfg is correct. From the look of the log output it looks as if the module is failing to load or you are no loading the tm module. Functions specific to a module are dependent of the module to execute. Is this a 64 bit os? Thanks, Tito On Oct 20, 2014 9:19 PM, "Peter Flowers" wrote: > Hi > I was following the OpenSIPS Kick Start video but using Debian 7.4 and > OpenSIPS 1.11.3. Everything went pretty well till the end and starting > openSIPS with the init script. > > I set the install prefix as /usr/local/opensips and created a residential > cfg file. This I renamed to opensips_residential.cfg. > > When I went to start opensips with /etc/init.d/opensips start there were > lots of critical errors like these > > Oct 20 22:43:44 [3363] CRITICAL:core:yyerror: parse error in config file > /usr/local/opensips//etc/opensips/opensips.cfg, line 255, column 15-16: > unknown command , missing loadmodule? > Oct 20 22:43:44 [3363] CRITICAL:core:yyerror: parse error in config file > /usr/local/opensips//etc/opensips/opensips.cfg, line 256, column 19-20: > unknown command , missing loadmodule? > Oct 20 22:43:44 [3363] CRITICAL:core:yyerror: parse error in config file > /usr/local/opensips//etc/opensips/opensips.cfg, line 276, column 22-23: > unknown command , missing loadmodule? > Oct 20 22:43:44 [3363] ERROR:core:main: bad config file (79 errors) > > The new layout of the init.d script is a bit different than the video, > particularly the beginning. It looks to me like the init.d script is not > picking up the correct location of the opensips_residential.cfg file and > picking a default opensips.cfg file. > > This is what I put in the init.d > > PATH=/sbin:/bin:/usr/sbin:/usr/bin > DAEMON=*/usr/local/opensips/sbin/opensips* > NAME=opensips > DESC=opensips > CFGFILE=*/usr/local/opensips/etc/opensips/opensips_residential.cfg* > M4CFGFILE=/etc/opensips/opensips.m4 > M4ARCHIVEDIR=/etc/opensips/archive > HOMEDIR=/var/run/opensips > PIDFILE=$HOMEDIR/$NAME.pid > DEFAULTS=/etc/default/opensips > RUN_OPENSIPS=no > > and the options line looks like this > > OPTIONS="-P $PIDFILE -m $S_MEMORY -M $P_MEMORY -u $USER -g $GROUP *-f > /usr/local/opensips/etc/opensips/opensips_residential.cfg*" > > Any ideas very gratefully accepted > -- > Peter Flowers > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pflowers at mergecom.co.nz Tue Oct 21 04:24:11 2014 From: pflowers at mergecom.co.nz (Peter Flowers) Date: Tue, 21 Oct 2014 15:24:11 +1300 Subject: [OpenSIPS-Users] Issue with /etc/init.d/opensips on new test install In-Reply-To: References: Message-ID: Hi Tito this is the mpath in opensips_residential.cfg: #set module path mpath="/usr/local/opensips/lib/opensips/modules/" This is the path to the modules. this is the mpath in the file opensips.cfg which is in the same directory as the _residential one I want to use. #set module path mpath="/opensips//lib/opensips/modules/" I think my problem is the init script is picking this cfg file not the _residential one hence all my errors. thanks On 21 October 2014 14:34, Tito Cumpen wrote: > Peter, > > Verify that your modules path within the cfg is correct. From the look of > the log output it looks as if the module is failing to load or you are no > loading the tm module. Functions specific to a module are dependent of the > module to execute. Is this a 64 bit os? > > Thanks, > Tito > On Oct 20, 2014 9:19 PM, "Peter Flowers" wrote: > >> Hi >> I was following the OpenSIPS Kick Start video but using Debian 7.4 and >> OpenSIPS 1.11.3. Everything went pretty well till the end and starting >> openSIPS with the init script. >> >> I set the install prefix as /usr/local/opensips and created a residential >> cfg file. This I renamed to opensips_residential.cfg. >> >> When I went to start opensips with /etc/init.d/opensips start there were >> lots of critical errors like these >> >> Oct 20 22:43:44 [3363] CRITICAL:core:yyerror: parse error in config file >> /usr/local/opensips//etc/opensips/opensips.cfg, line 255, column 15-16: >> unknown command , missing loadmodule? >> Oct 20 22:43:44 [3363] CRITICAL:core:yyerror: parse error in config file >> /usr/local/opensips//etc/opensips/opensips.cfg, line 256, column 19-20: >> unknown command , missing loadmodule? >> Oct 20 22:43:44 [3363] CRITICAL:core:yyerror: parse error in config file >> /usr/local/opensips//etc/opensips/opensips.cfg, line 276, column 22-23: >> unknown command , missing loadmodule? >> Oct 20 22:43:44 [3363] ERROR:core:main: bad config file (79 errors) >> >> The new layout of the init.d script is a bit different than the video, >> particularly the beginning. It looks to me like the init.d script is not >> picking up the correct location of the opensips_residential.cfg file and >> picking a default opensips.cfg file. >> >> This is what I put in the init.d >> >> PATH=/sbin:/bin:/usr/sbin:/usr/bin >> DAEMON=*/usr/local/opensips/sbin/opensips* >> NAME=opensips >> DESC=opensips >> CFGFILE=*/usr/local/opensips/etc/opensips/opensips_residential.cfg* >> M4CFGFILE=/etc/opensips/opensips.m4 >> M4ARCHIVEDIR=/etc/opensips/archive >> HOMEDIR=/var/run/opensips >> PIDFILE=$HOMEDIR/$NAME.pid >> DEFAULTS=/etc/default/opensips >> RUN_OPENSIPS=no >> >> and the options line looks like this >> >> OPTIONS="-P $PIDFILE -m $S_MEMORY -M $P_MEMORY -u $USER -g $GROUP *-f >> /usr/local/opensips/etc/opensips/opensips_residential.cfg*" >> >> Any ideas very gratefully accepted >> -- >> Peter Flowers >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- Peter Flowers DDI 04 9138149 www.mergecom.co.nz -------------- next part -------------- An HTML attachment was scrubbed... URL: From sunil.sipuser at gmail.com Tue Oct 21 06:59:41 2014 From: sunil.sipuser at gmail.com (Sunil P) Date: Tue, 21 Oct 2014 10:29:41 +0530 Subject: [OpenSIPS-Users] Convert SDP Connection IP Message-ID: > > Hi All, > > I need to make Opensips AS to act as IBCF, which is going to convert the > V6 SDP to V4 SDP and Vice Versa.Please suggest me in which functions I need > to change > to convert SDP Connection Parameter. > > Thanks and Regards, > Sunil > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Oct 21 19:52:41 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 21 Oct 2014 20:52:41 +0300 Subject: [OpenSIPS-Users] YNT: Re: YNT: Re: YNT: Re: YNT: Re: RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE In-Reply-To: <1413832141.7284.YahooMailNeo@web121505.mail.ne1.yahoo.com> References: <87qjrvwjysax95g79onktby0.1413789931582@email.android.com> <1413832141.7284.YahooMailNeo@web121505.mail.ne1.yahoo.com> Message-ID: <54469D69.6090607@opensips.org> Hi Kaan, I'm glad you managed to fix all your issues and now you have a successfully working configuration. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 20.10.2014 22:09, Kaan Dandin wrote: > Hi Bogdan, > > With the below workaround, I have managed to make load balancing with > Opensips dispather module . I am using record_route for INVITE message. > Thanks a lot for your support. > Kind regards, > Kaan > > > Related part of Opensips script > > ....... > > else if (is_method("INVITE")) { > #load_balance("1","pstn"); > xlog("xlog_initialinvite"); > if($si=="192.168.2.11") { > ds_select_dst("1","1"); > } > record_route(); > if(!t_relay()) { > sl_reply_error(); > xlog("xlog_invitereplyerror"); > } > exit; > > > ....... > > if (loose_route()) { > xlog("xlog_loose_route"); > if($si=="192.168.2.11") { > t_relay(); > exit; > } > else if($si=="192.168.2.3" or $si=="192.168.2.5" ) { > $du = "sip:192.168.2.11:4060"; > append_branch(); > t_relay(); > exit; > } > ..... > *ims_bench output* > > 1- ims_uac-0- Scenario Screen - [1-9]: Change Screen - 6663 > Call-rate(length) Port Total-time Total-calls Remote-host > 0.0(0 ms)/1.000s 5060 65.32 s 65 > 192.168.2.141:4060(UDP) > 0 new calls during 0.287 s period 1 ms scheduler resolution > 0 calls (limit 0) Peak was 32 calls, after 45 s > 0 Running, 1 Paused, 1 Woken up, 0 Sync > 0 out-of-call msg (discarded) > 0 open sockets > Messages Retrans Timeout Unexpected-Msg > 0 [ NOP ] > 1 [ SENDRMT ] 11 > 2 [ RECVRMT ] 11 0 > 3 [ SYNC ] 11 > 4 INVITE ----------> B1,2,4 11 0 0 > 5 100 <---------- 11 0 0 > 6 180 <---------- 11 0 0 > 7 183 <---------- 0 0 0 > 8 200 <---------- 11 0 0 > 9 ACK ----------> 11 0 > 10 180 <---------- 0 0 0 > 11 Pause [Exp(2:00)] 11 0 > 12 BYE ----------> B3 11 0 0 > 13 180 <---------- 0 0 0 > 14 200 <---------- E3,4 11 0 0 > 15 [ RECVRMT ] 11 0 > ------------------------------ Test Terminated > -------------------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Oct 21 20:24:29 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 21 Oct 2014 21:24:29 +0300 Subject: [OpenSIPS-Users] Convert SDP Connection IP In-Reply-To: References: Message-ID: <5446A4DD.1060308@opensips.org> Hi Sunil, See the fix_nated_sdp() function in the nathelper module: http://www.opensips.org/html/docs/modules/1.11.x/nathelper.html#id293864 Use the second parameter to push your own IP address into SDP. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 21.10.2014 07:59, Sunil P wrote: > > Hi All, > > I need to make Opensips AS to act as IBCF, which is going to > convert the V6 SDP to V4 SDP and Vice Versa.Please suggest me in > which functions I need to change > to convert SDP Connection Parameter. > > Thanks and Regards, > Sunil > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Oct 21 20:34:28 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 21 Oct 2014 21:34:28 +0300 Subject: [OpenSIPS-Users] branch computation failed In-Reply-To: <1413788116516-7594122.post@n2.nabble.com> References: <1412825847529-7593895.post@n2.nabble.com> <5436691D.4010006@opensips.org> <1412906905090-7593931.post@n2.nabble.com> <543B7EEE.9000505@opensips.org> <201410131535093743451@gmail.com> <543B82E2.7010003@opensips.org> <201410140951152215038@gmail.com> <543D5199.4000204@opensips.org> <1413513872354-7594086.post@n2.nabble.com> <5440DE85.4050200@opensips.org> <1413788116516-7594122.post@n2.nabble.com> Message-ID: <5446A734.5070607@opensips.org> Thank you ! I pushed the fix on GIT. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 20.10.2014 09:55, chow wrote: > Hi: > three days gone. that error not come out . > thank you. > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/branch-computation-failed-tp7593895p7594122.html > Sent from the OpenSIPS - Users mailing list archive at Nabble.com. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From bogdan at opensips.org Tue Oct 21 20:45:15 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 21 Oct 2014 21:45:15 +0300 Subject: [OpenSIPS-Users] clear location table In-Reply-To: References: Message-ID: <5446A9BB.9030408@opensips.org> Hi Dragomir, Assuming you use db mode 1 or 2 - the records are deleted from DB by usrloc when the records do expire from memory . If you ended with such old records in DB, it may be because your OpenSIPS was not aware (or stopped) when those records did expire. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 17.10.2014 22:52, Dragomir Haralambiev wrote: > Hello, > > This is part of my script: > modparam("registrar", "default_expires", 900) > > I see into location table: > expires 2014-10-14 21:56:30 last_modified 2014-10-14 20:56:30 > expires 2014-10-17 22:43:34 last_modified 2014-10-17 21:43:34 > expires 2014-10-07 23:26:44 last_modified 2014-10-07 23:24:44 > > How to clear location table when registration is expaered? > > Best regards, > PlayMen > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Oct 21 20:46:35 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 21 Oct 2014 21:46:35 +0300 Subject: [OpenSIPS-Users] Call external program from reply_rote In-Reply-To: References: Message-ID: <5446AA0B.3010608@opensips.org> Hi Gary, You can do an ugly trick like: route[EXEC] { exec(....); } onreply_route[...] { .... route(EXEC); .... } Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 21.10.2014 00:56, Gary Nyquist wrote: > Hi, > > I need to call an external program from the REPLY_ROUTE (on getting 200 OK). > As per the doc, "exec_msg" and "exec_avp" can be used from REQUEST_ROUTE & FAILURE_ROUTE only. > Is there any alternative methods to run external programs from the REPLY_ROUTE? > > Best Regards, > - Gary > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From bogdan at opensips.org Tue Oct 21 20:47:55 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 21 Oct 2014 21:47:55 +0300 Subject: [OpenSIPS-Users] add date header for every SIP Message In-Reply-To: <1413788790605-7594123.post@n2.nabble.com> References: <1413788790605-7594123.post@n2.nabble.com> Message-ID: <5446AA5B.6020800@opensips.org> Hi, For internally generated requests, use the "local_route" to gain access to them and to add the "Date" header: http://www.opensips.org/Documentation/Script-Routes-1-11#toc6 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 20.10.2014 10:06, chow wrote: > Hi: > I want to append Date header for every SIP Message. > > I called append_time function from opensips.cfg that work fine , but > when called t_uac_dlg by mi Interface, that message not have Date header. > > is there have some way to add Date header for every SIP Message , like > as From and To header? > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/add-date-header-for-every-SIP-Message-tp7594123.html > Sent from the OpenSIPS - Users mailing list archive at Nabble.com. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From tito at xsvoce.com Tue Oct 21 21:48:49 2014 From: tito at xsvoce.com (Tito Cumpen) Date: Tue, 21 Oct 2014 15:48:49 -0400 Subject: [OpenSIPS-Users] issues loading linbmongo.c.0.6 after compilation In-Reply-To: <54419DD9.8060208@opensips.org> References: <54419DD9.8060208@opensips.org> Message-ID: Liviu, That worked! thank you for your guidance. Thanks, Tito On Fri, Oct 17, 2014 at 6:53 PM, Liviu Chircu wrote: > Hi Tito, > > You need to keep playing with the library paths until the command "ldd > ...../cachedb_mongodb.so" has clean output, with all dependencies located. > No need to start OpenSIPS until this is solved. > > Hint: If I remember correctly, libmongoc installs in /usr/local/lib, so I > would run: > echo "/usr/local/lib" > /etc/ld.so.conf.d/libmongoc.conf && ldconfig > > Best regards, > > Liviu Chircu > OpenSIPS Developerhttp://www.opensips-solutions.com > > On 18.10.2014 01:34, Tito Cumpen wrote: > > group im having issues after restarting opensips loading cache_db_mongol > which module that depends on libmongo > > ERROR:core:sr_load_module: could not open module > : libmongoc.so.0.6: cannot open > shared object file: No such file or directory > > althought I used ln -s libmongoc.so.0.60 /usr/src/mongo-c-driver-0.6/libmongoc.so > when I compiled > > > > any idea why opensips has issues finding it now? > > > > thanks, > > Tito > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at supportedbusiness.com Wed Oct 22 09:42:22 2014 From: matt at supportedbusiness.com (matt) Date: Wed, 22 Oct 2014 08:42:22 +0100 Subject: [OpenSIPS-Users] Load balancer setup Message-ID: Hi, I was looking for some guidance on using the load balancer in a NAT environment. I have the following setup (the IP addresses are made up but should give an indication): 1 x opensips server with load balancer module - IP 192.168.0.1 2 x freeswitch servers - IP 192.168.0.2 & 192.168.0.3 All 3 servers have seperate external IP address routing to their internal IP via our firewall: 217.0.0.1 routed to 192.168.0.1 (Opensips) 217.0.0.2 routed to 192.168.0.2 (FS1) 217.0.0.3 routed to 192.168.0.3 (FS2) I have the load_balancer table with the following details: id, | group_id, | dst_uri, | resources, | probe_mode, | description '1', | '1', | 'sip:192.168.0.2:5080', | 'pstn=10', | '2', | 'FS1' '2', | '1', | 'sip:192.168.0.3:5080', | 'vm=1', | '2', | 'FS2' The call flow is: SIP Provider --> 217.0.0.1 Opensips --> 192.168.0.2/3 The issue is, that when the 200 ok response is sent to the SIP provider, the Freeswitch server's internal IP is being sent in the SDP connection information (c). This causes the ACK response from the SIP Provider to fail to be sent correctly. With the calls routed directly to the FS servers (removing opensips from the flow), the calls work fine. Any help would be much appreciated :) thanks Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhouxiaoqiang.mstech at gmail.com Wed Oct 22 10:46:51 2014 From: zhouxiaoqiang.mstech at gmail.com (chow) Date: Wed, 22 Oct 2014 01:46:51 -0700 (PDT) Subject: [OpenSIPS-Users] add date header for every SIP Message In-Reply-To: <5446AA5B.6020800@opensips.org> References: <1413788790605-7594123.post@n2.nabble.com> <5446AA5B.6020800@opensips.org> Message-ID: <1413967611128-7594166.post@n2.nabble.com> Hi thank you. it work for me! -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/add-date-header-for-every-SIP-Message-tp7594123p7594166.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From mustafin.aleksandr at gmail.com Wed Oct 22 12:13:07 2014 From: mustafin.aleksandr at gmail.com (Alexander Mustafin) Date: Wed, 22 Oct 2014 16:13:07 +0600 Subject: [OpenSIPS-Users] Get variables in failure route Message-ID: <1BB0DB97-920C-4F47-89EB-F693F827D3EF@gmail.com> Hello. I need to receive variables from 407 message in failure route, but when I tried it - I received a value from initial message. INVITE sip:055555534534 at sbc.sbc.sbc SIP/2.0. Via: SIP/2.0/UDP 54.55.56.57:12000;rport;branch=z9hG4bK37Ny7QvNF7Hrc. Max-Forwards: 70. From: ?User" ;tag=ct7BK7ccyaK7H. SIP/2.0 407 Proxy Authentication Required. From: ;tag=ct7BK7ccyaK7H. To: ;tag=9560995. failure_route[EXTERNAL_FAULT] { if (t_was_cancelled()) { xlog("L_INFO", "$ci|log|transaction was cancelled"); exit; } $var(auth_user) = $fU + "@" + $fd; } In variable $var(auth_user) I?ve seen 77777777777 at office.sbc.sbc. Can I receive values from 407 message? Best regards, Alexander Mustafin mustafin.aleksandr at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From zhouxiaoqiang.mstech at gmail.com Wed Oct 22 12:23:27 2014 From: zhouxiaoqiang.mstech at gmail.com (chow) Date: Wed, 22 Oct 2014 03:23:27 -0700 (PDT) Subject: [OpenSIPS-Users] core dump when use mi_xmlrpc module In-Reply-To: <1413972743978-7594167.post@n2.nabble.com> References: <1413972743978-7594167.post@n2.nabble.com> Message-ID: <1413973407012-7594169.post@n2.nabble.com> there have twice core dump file log: [root at localhost opensips]# gdb core.13897 GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /usr/sbin/opensips...Reading symbols from /usr/lib/debug/usr/sbin/opensips.debug...done. done. [New Thread 14099] [New Thread 13897] warning: Can't read pathname for load map: Input/output error. Reading symbols from /usr/lib64/opensips/modules/signaling.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/signaling.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/signaling.so Reading symbols from /usr/lib64/opensips/modules/sl.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/sl.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/sl.so Reading symbols from /usr/lib64/opensips/modules/tm.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/tm.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/tm.so Reading symbols from /usr/lib64/opensips/modules/rr.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/rr.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/rr.so Reading symbols from /usr/lib64/opensips/modules/maxfwd.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/maxfwd.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/maxfwd.so Reading symbols from /usr/lib64/opensips/modules/sipmsgops.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/sipmsgops.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/sipmsgops.so Reading symbols from /usr/lib64/opensips/modules/mi_fifo.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/mi_fifo.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/mi_fifo.so Reading symbols from /usr/lib64/opensips/modules/mi_xmlrpc.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/mi_xmlrpc.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/mi_xmlrpc.so Reading symbols from /usr/lib64/opensips/modules/uri.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/uri.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/uri.so Reading symbols from /usr/lib64/opensips/modules/usrloc.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/usrloc.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/usrloc.so Reading symbols from /usr/lib64/opensips/modules/registrar.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/registrar.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/registrar.so Reading symbols from /usr/lib64/opensips/modules/acc.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/acc.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/acc.so Reading symbols from /usr/lib64/opensips/modules/textops.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/textops.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/textops.so Reading symbols from /usr/lib64/opensips/modules/db_mysql.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/db_mysql.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/db_mysql.so Reading symbols from /usr/lib64/opensips/modules/avpops.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/avpops.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/avpops.so Reading symbols from /usr/lib64/opensips/modules/auth.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/auth.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/auth.so Reading symbols from /usr/lib64/opensips/modules/auth_db.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/auth_db.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/auth_db.so Reading symbols from /usr/lib64/opensips/modules/domain.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/domain.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/domain.so Reading symbols from /usr/lib64/opensips/modules/permissions.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/permissions.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/permissions.so Reading symbols from /usr/lib64/opensips/modules/alias_db.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/alias_db.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/alias_db.so Reading symbols from /usr/lib64/opensips/modules/stun.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/stun.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/stun.so Reading symbols from /usr/lib64/opensips/modules/dialog.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/dialog.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/dialog.so Reading symbols from /usr/lib64/opensips/modules/sst.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/sst.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/sst.so Reading symbols from /usr/lib64/opensips/modules/msilo.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/msilo.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/msilo.so Reading symbols from /usr/lib64/opensips/modules/nathelper.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/nathelper.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/nathelper.so Reading symbols from /usr/lib64/opensips/modules/mi_datagram.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/mi_datagram.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/mi_datagram.so Reading symbols from /usr/lib64/opensips/modules/xcap.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/xcap.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/xcap.so Reading symbols from /usr/lib64/opensips/modules/presence.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/presence.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/presence.so Reading symbols from /usr/lib64/opensips/modules/presence_xml.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/presence_xml.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/presence_xml.so Reading symbols from /usr/lib64/opensips/modules/presence_mwi.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/presence_mwi.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/presence_mwi.so Reading symbols from /usr/lib64/opensips/modules/pua.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/pua.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/pua.so Reading symbols from /usr/lib64/opensips/modules/pua_usrloc.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/pua_usrloc.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/pua_usrloc.so Reading symbols from /usr/lib64/opensips/modules/pua_mi.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/pua_mi.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/pua_mi.so Reading symbols from /usr/lib64/opensips/modules/presence_xcapdiff.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/presence_xcapdiff.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/presence_xcapdiff.so Reading symbols from /usr/lib64/opensips/modules/rls.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/rls.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/rls.so warning: Can't read pathname for load map: Input/output error. warning: Can't read pathname for load map: Input/output error. Core was generated by `/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 4096 -M 128 -w /var/log'. Program terminated with signal 11, Segmentation fault. #0 0x00000000004ec4c7 in fm_remove_free (qm=0x7fc1a1c59010, size=24) at mem/f_malloc.c:172 172 *pf=n->u.nxt_free; Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.132.el6.x86_64 keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.10.3-15.el6_5.1.x86_64 libcom_err-1.41.12-18.el6_5.1.x86_64 libgcc-4.4.7-4.el6.x86_64 libselinux-2.0.94-5.3.el6_4.1.x86_64 libxml2-2.7.6-14.el6.x86_64 mysql-libs-5.1.71-1.el6.x86_64 nss-softokn-freebl-3.14.3-9.el6.x86_64 openssl-1.0.1e-15.el6.x86_64 xmlrpc-c-1.16.24-1210.1840.el6.x86_64 zlib-1.2.3-29.el6.x86_64 (gdb) bt full #0 0x00000000004ec4c7 in fm_remove_free (qm=0x7fc1a1c59010, size=24) at mem/f_malloc.c:172 pf = 0x0 hash = 3 #1 fm_malloc (qm=0x7fc1a1c59010, size=24) at mem/f_malloc.c:383 frag = 0x7fc1a1c95838 n = hash = __FUNCTION__ = "fm_malloc" #2 0x00007fc1a15fab1b in new_str (cmd_tree=0x7fc1a1c959a8, param=) at mi.c:108 new = #3 get_hfblock (cmd_tree=0x7fc1a1c959a8, param=) at mi.c:150 i = frag_len = begin = 0x7fc090006b5d "P-ICast-Message-Expire: 7200\n" dst = ret = 0x0 portname = 0x0 sl = {s = {s = 0x7fc09c8b5640 "\220k", len = -1668590008}, next = 0x7fc1a1c95850} total_len = 24 sock_name = 0x0 to_su = {s = {sa_family = 51235, sa_data = "\272\240\301\177\000\000\000\000\000\000\000\000\000"}, sin = { sin_family = 51235, sin_port = 41146, sin_addr = {s_addr = 32705}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 51235, sin6_port = 41146, sin6_flowinfo = 32705, sin6_addr = {__in6_u = { __u6_addr8 = "\000\000\000\000\000\000\000\000\220k\000\220\300\177\000", __u6_addr16 = {0, 0, 0, 0, 27536, 36864, 32704, 0}, __u6_addr32 = {0, 0, 2415946640, 32704}}}, sin6_scope_id = 287}} foo = last = 0x7fc1a1c95850 hf_avail = 29 needle = d = ---Type to continue, or q to quit--- #4 mi_tm_uac_dlg (cmd_tree=0x7fc1a1c959a8, param=) at mi.c:491 err_buf = '\000' tmp_msg = {id = 0, first_line = {type = 0, len = 0, u = {request = {method = {s = 0x0, len = 0}, uri = { s = 0x0, len = 0}, version = {s = 0x0, len = 0}, method_value = 0}, reply = {version = {s = 0x0, len = 0}, status = {s = 0x0, len = 0}, reason = {s = 0x0, len = 0}, statuscode = 0}}}, via1 = 0x0, via2 = 0x0, headers = 0x7fc1a1c95770, last_header = 0x7fc1a1c95710, parsed_flag = 4120, h_via1 = 0x0, h_via2 = 0x0, callid = 0x0, to = 0x7fc1a1c95d48, cseq = 0x0, from = 0x7fc1a1c95770, contact = 0x0, maxforwards = 0x0, route = 0x0, record_route = 0x0, path = 0x0, content_type = 0x7fc1a1c95050, content_length = 0x0, authorization = 0x0, expires = 0x0, proxy_auth = 0x0, supported = 0x0, proxy_require = 0x0, unsupported = 0x0, allow = 0x0, event = 0x0, accept = 0x0, accept_language = 0x0, organization = 0x0, priority = 0x0, subject = 0x0, user_agent = 0x0, content_disposition = 0x0, accept_disposition = 0x0, diversion = 0x0, rpid = 0x0, refer_to = 0x0, session_expires = 0x0, min_se = 0x0, ppi = 0x0, pai = 0x0, privacy = 0x0, call_info = 0x0, www_authenticate = 0x0, proxy_authenticate = 0x0, min_expires = 0x0, sdp = 0x0, multi = 0x0, eoh = 0x0, unparsed = 0x7fc090006b7a "", rcv = {src_ip = {af = 0, len = 0, u = {addrl = {0, 0}, addr32 = {0, 0, 0, 0}, addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, addr = '\000' }}, dst_ip = {af = 0, len = 0, u = {addrl = {0, 0}, addr32 = {0, 0, 0, 0}, addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, addr = '\000' }}, src_port = 0, dst_port = 0, proto = 0, proto_reserved1 = 0, proto_reserved2 = 0, src_su = {s = {sa_family = 0, sa_data = '\000' }, sin = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 0, sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__in6_u = {__u6_addr8 = '\000' , __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}, bind_address = 0x0}, buf = 0x7fc090006b00 "From:\nTo:\nContent-Type:text/plain\nP-ICast-Message-Expire: 7200\n", len = 122, new_uri = {s = 0x0, len = 0}, dst_uri = {s = 0x0, len = 0}, parsed_uri_ok = 0, parsed_uri = {user = {s = 0x0, len = 0}, passwd = {s = 0x0, len = 0}, host = {s = 0x0, len = 0}, port = {s = 0x0, len = 0}, params = {s = 0x0, len = 0}, headers = {s = 0x0, len = 0}, port_no = 0, proto = 0, type = ERROR_URI_T, transport = {s = 0x0, len = 0}, ttl = {s = 0x0, len = 0}, user_param = {s = 0x0, len = 0}, maddr = {s = 0x0, len = 0}, method = {s = 0x0, len = 0}, lr = {s = 0x0, len = 0}, r2 = {s = 0x0, len = 0}, gr = {s = 0x0, len = 0}, transport_val = {s = 0x0, len = 0}, ttl_val = {s = 0x0, len = 0}, user_param_val = {s = 0x0, len = 0}, maddr_val = {s = 0x0, len = 0}, method_val = {s = 0x0, len = 0}, lr_val = {s = 0x0, len = 0}, r2_val = {s = 0x0, len = 0}, gr_val = { ---Type to continue, or q to quit--- s = 0x0, len = 0}, u_name = {{s = 0x0, len = 0}, {s = 0x0, len = 0}, {s = 0x0, len = 0}, {s = 0x0, len = 0}, {s = 0x0, len = 0}}, u_val = {{s = 0x0, len = 0}, {s = 0x0, len = 0}, {s = 0x0, len = 0}, { s = 0x0, len = 0}, {s = 0x0, len = 0}}, u_params_no = 0}, parsed_orig_ruri_ok = 0, parsed_orig_ruri = { user = {s = 0x0, len = 0}, passwd = {s = 0x0, len = 0}, host = {s = 0x0, len = 0}, port = {s = 0x0, len = 0}, params = {s = 0x0, len = 0}, headers = {s = 0x0, len = 0}, port_no = 0, proto = 0, type = ERROR_URI_T, transport = {s = 0x0, len = 0}, ttl = {s = 0x0, len = 0}, user_param = {s = 0x0, len = 0}, maddr = {s = 0x0, len = 0}, method = {s = 0x0, len = 0}, lr = {s = 0x0, len = 0}, r2 = { s = 0x0, len = 0}, gr = {s = 0x0, len = 0}, transport_val = {s = 0x0, len = 0}, ttl_val = {s = 0x0, len = 0}, user_param_val = {s = 0x0, len = 0}, maddr_val = {s = 0x0, len = 0}, method_val = {s = 0x0, len = 0}, lr_val = {s = 0x0, len = 0}, r2_val = {s = 0x0, len = 0}, gr_val = {s = 0x0, len = 0}, u_name = {{s = 0x0, len = 0}, {s = 0x0, len = 0}, {s = 0x0, len = 0}, {s = 0x0, len = 0}, {s = 0x0, len = 0}}, u_val = {{s = 0x0, len = 0}, {s = 0x0, len = 0}, {s = 0x0, len = 0}, {s = 0x0, len = 0}, { s = 0x0, len = 0}}, u_params_no = 0}, add_rm = 0x0, body_lumps = 0x0, reply_lump = 0x0, add_to_branch_s = '\000' , add_to_branch_len = 0, hash_index = 0, flags = 0, msg_flags = 0, set_global_address = {s = 0x0, len = 0}, set_global_port = {s = 0x0, len = 0}, force_send_socket = 0x0, path_vec = {s = 0x0, len = 0}, msg_cb = 0x0} dlg = {id = {call_id = {s = 0x7fc1a183c840 "66c4a36c360858e9-13897 at 127.0.0.1", len = 32}, rem_tag = {s = 0x0, len = 0}, loc_tag = {s = 0x7fc1a1850920 "533cb9e91f4b999cf76861cbb9ed54ed-5e40", len = 37}}, loc_seq = { value = 10, is_set = 1 '\001'}, rem_seq = {value = 0, is_set = 0 '\000'}, loc_uri = { s = 0x7fc098007ca6 "sip:iCast_weixin at 192.168.61.165>\nTo:\nContent-Type:text/plain\nP-ICast-Message-Expire: 7200\n", len = 31}, rem_uri = { s = 0x7fc09000564b "sip:1100 at 192.168.61.165>\nContent-Type:text/plain\nP-ICast-Message-Expire: 7200\n", len = 23}, obp = {s = 0x0, len = 0}, forced_to_su = {s = {sa_family = 0, sa_data = '\000' }, sin = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 0, sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__in6_u = {__u6_addr8 = '\000' , __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}, rem_target = {s = 0x0, len = 0}, loc_dname = { s = 0x0, len = 0}, rem_dname = {s = 0x0, len = 0}, T_flags = 0, state = DLG_NEW, route_set = 0x0, hooks = { ru = {s = 0x0, len = 0}, nh = {s = 0x0, len = 0}, request_uri = 0x7fc1a1c95b68, next_hop = 0x7fc1a1c95b68, first_route = 0x0, last_route = 0x0}, send_sock = 0x7fc1a1c8a270} rpl_tree = ---Type to continue, or q to quit--- node = pruri = {user = {s = 0x7fc090006aa4 "20000 at 192.168.61.165", len = 5}, passwd = {s = 0x0, len = 0}, host = { s = 0x7fc090006aaa "192.168.61.165", len = 14}, port = {s = 0x0, len = 0}, params = {s = 0x0, len = 0}, headers = {s = 0x0, len = 0}, port_no = 0, proto = 0, type = SIP_URI_T, transport = {s = 0x0, len = 0}, ttl = {s = 0x0, len = 0}, user_param = {s = 0x0, len = 0}, maddr = {s = 0x0, len = 0}, method = {s = 0x0, len = 0}, lr = {s = 0x0, len = 0}, r2 = {s = 0x0, len = 0}, gr = {s = 0x0, len = 0}, transport_val = { s = 0x0, len = 0}, ttl_val = {s = 0x0, len = 0}, user_param_val = {s = 0x0, len = 0}, maddr_val = {s = 0x0, len = 0}, method_val = {s = 0x0, len = 0}, lr_val = {s = 0x0, len = 0}, r2_val = {s = 0x0, len = 0}, gr_val = {s = 0x0, len = 0}, u_name = {{s = 0x0, len = 0}, {s = 0x0, len = 0}, {s = 0x0, len = 0}, {s = 0x0, len = 0}, {s = 0x0, len = 0}}, u_val = {{s = 0x0, len = 0}, {s = 0x0, len = 0}, {s = 0x0, len = 0}, { s = 0x0, len = 0}, {s = 0x0, len = 0}}, u_params_no = 0} pnexthop = {user = {s = 0x209387d "", len = 0}, passwd = {s = 0x0, len = 0}, host = {s = 0x0, len = 0}, port = { s = 0xa
, len = 1593142669}, params = {s = 0x0, len = 0}, headers = {s = 0x0, len = 0}, port_no = 0, proto = 0, type = ERROR_URI_T, transport = { s = 0x385eea52ce
, len = 0}, ttl = {s = 0x0, len = -1}, user_param = { s = 0x385ee554fa
, len = 8}, maddr = { s = 0x2
, len = -1668590384}, method = { s = 0x200000008
, len = -1668590810}, lr = { s = 0x7fc000000000
, len = 831214352}, r2 = {s = 0x7fc09c8b5326 "", len = 1595458272}, gr = {s = 0x7fc09c8b54af "", len = 34158032}, transport_val = {s = 0x7fc09c8b52d0 "", len = 16}, ttl_val = {s = 0x7fc09c8b54c0 "", len = -1668590592}, user_param_val = { s = 0x7fc09c8b53a0 "\020", len = -1668590610}, maddr_val = {s = 0x7fc09c8b53e4 "\300\177", len = -1668590612}, method_val = {s = 0x7fc09c8b53e4 "\300\177", len = 0}, lr_val = {s = 0x0, len = 33}, r2_val = {s = 0x8
, len = 1}, gr_val = {s = 0x230
, len = 0}, u_name = {{s = 0x385ef572c3
, len = -1879043540}, { s = 0x7fc09000122c "14:34:51 /usr/sbin/opensips[13897]: DBG:tm:get_hfblock: one more hf processed\n", len = 1595460288}, {s = 0x7
, len = 8187}, { s = 0x385eea4122
, len = -1668590620}, {s = 0x0, len = 14}}, u_val = { {s = 0x3800000000
, len = 3}, { s = 0x100000002
, len = 16}, {s = 0x7fc09c8b56a0 "P8\200", len = -1668590112}, {s = 0x7fc090001210 "0", len = 133}, {s = 0x7fc090000020 "", len = 8208}}, ---Type to continue, or q to quit--- u_params_no = 12832} sock = 0x0 method = 0x7fc1a1c95bc8 ruri = 0x7fc1a1c95570 nexthop = 0x0 socket = hdrs = body = s = {s = 0x7fc0900078f8 "\b", len = 0} callid = sip_error = proto = port = -1879020648 cseq = -1 n = #5 0x00007fc1a0ba93e3 in run_mi_cmd (env=0x7fc09c8b57c0, host=, methodName=, paramArray=, serverInfo=) at ../../mi/mi.h:109 ret = #6 default_method (env=0x7fc09c8b57c0, host=, methodName=, paramArray=, serverInfo=) at xr_server.c:221 ret = 0x0 mi_cmd = 0x7fc1a1c959a8 mi_rpl = 0x0 hdl = 0x7fc09cc27ae8 f = 0x7fc1a1c8d808 response = 0x0 is_shm = 0 __FUNCTION__ = "default_method" #7 0x00007fc1a0574eab in ?? () No symbol table info available. #8 0x00007fc09c8b5850 in ?? () ---Type to continue, or q to quit--- No symbol table info available. #9 0x0000000000000000 in ?? () No symbol table info available. (gdb) (gdb) (gdb) (gdb) ^C(gdb) Quit (gdb) quit [root at localhost opensips]# gdb core.17930 GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /usr/sbin/opensips...Reading symbols from /usr/lib/debug/usr/sbin/opensips.debug...done. done. [New Thread 18125] [New Thread 17930] [New Thread 18124] [New Thread 18123] warning: Can't read pathname for load map: Input/output error. Reading symbols from /usr/lib64/opensips/modules/signaling.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/signaling.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/signaling.so Reading symbols from /usr/lib64/opensips/modules/sl.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/sl.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/sl.so Reading symbols from /usr/lib64/opensips/modules/tm.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/tm.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/tm.so Reading symbols from /usr/lib64/opensips/modules/rr.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/rr.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/rr.so Reading symbols from /usr/lib64/opensips/modules/maxfwd.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/maxfwd.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/maxfwd.so Reading symbols from /usr/lib64/opensips/modules/sipmsgops.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/sipmsgops.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/sipmsgops.so Reading symbols from /usr/lib64/opensips/modules/mi_fifo.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/mi_fifo.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/mi_fifo.so Reading symbols from /usr/lib64/opensips/modules/mi_xmlrpc.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/mi_xmlrpc.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/mi_xmlrpc.so Reading symbols from /usr/lib64/opensips/modules/uri.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/uri.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/uri.so Reading symbols from /usr/lib64/opensips/modules/usrloc.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/usrloc.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/usrloc.so Reading symbols from /usr/lib64/opensips/modules/registrar.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/registrar.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/registrar.so Reading symbols from /usr/lib64/opensips/modules/acc.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/acc.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/acc.so Reading symbols from /usr/lib64/opensips/modules/textops.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/textops.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/textops.so Reading symbols from /usr/lib64/opensips/modules/db_mysql.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/db_mysql.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/db_mysql.so Reading symbols from /usr/lib64/opensips/modules/avpops.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/avpops.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/avpops.so Reading symbols from /usr/lib64/opensips/modules/auth.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/auth.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/auth.so Reading symbols from /usr/lib64/opensips/modules/auth_db.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/auth_db.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/auth_db.so Reading symbols from /usr/lib64/opensips/modules/domain.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/domain.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/domain.so Reading symbols from /usr/lib64/opensips/modules/permissions.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/permissions.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/permissions.so Reading symbols from /usr/lib64/opensips/modules/alias_db.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/alias_db.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/alias_db.so Reading symbols from /usr/lib64/opensips/modules/stun.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/stun.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/stun.so Reading symbols from /usr/lib64/opensips/modules/dialog.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/dialog.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/dialog.so Reading symbols from /usr/lib64/opensips/modules/sst.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/sst.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/sst.so Reading symbols from /usr/lib64/opensips/modules/msilo.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/msilo.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/msilo.so Reading symbols from /usr/lib64/opensips/modules/nathelper.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/nathelper.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/nathelper.so Reading symbols from /usr/lib64/opensips/modules/mi_datagram.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/mi_datagram.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/mi_datagram.so Reading symbols from /usr/lib64/opensips/modules/xcap.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/xcap.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/xcap.so Reading symbols from /usr/lib64/opensips/modules/presence.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/presence.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/presence.so Reading symbols from /usr/lib64/opensips/modules/presence_xml.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/presence_xml.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/presence_xml.so Reading symbols from /usr/lib64/opensips/modules/presence_mwi.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/presence_mwi.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/presence_mwi.so Reading symbols from /usr/lib64/opensips/modules/pua.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/pua.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/pua.so Reading symbols from /usr/lib64/opensips/modules/pua_usrloc.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/pua_usrloc.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/pua_usrloc.so Reading symbols from /usr/lib64/opensips/modules/pua_mi.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/pua_mi.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/pua_mi.so Reading symbols from /usr/lib64/opensips/modules/presence_xcapdiff.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/presence_xcapdiff.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/presence_xcapdiff.so Reading symbols from /usr/lib64/opensips/modules/rls.so...Reading symbols from /usr/lib/debug/usr/lib64/opensips/modules/rls.so.debug...done. done. Loaded symbols for /usr/lib64/opensips/modules/rls.so warning: Can't read pathname for load map: Input/output error. warning: Can't read pathname for load map: Input/output error. Core was generated by `/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 4096 -M 128 -w /var/log'. Program terminated with signal 11, Segmentation fault. #0 free_mi_node (parent=0x7ffcaf462050) at mi/tree.c:79 79 p = p->next; Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.132.el6.x86_64 keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.10.3-15.el6_5.1.x86_64 libcom_err-1.41.12-18.el6_5.1.x86_64 libgcc-4.4.7-4.el6.x86_64 libselinux-2.0.94-5.3.el6_4.1.x86_64 libxml2-2.7.6-14.el6.x86_64 mysql-libs-5.1.71-1.el6.x86_64 nss-softokn-freebl-3.14.3-9.el6.x86_64 openssl-1.0.1e-15.el6.x86_64 xmlrpc-c-1.16.24-1210.1840.el6.x86_64 zlib-1.2.3-29.el6.x86_64 (gdb) bt #0 free_mi_node (parent=0x7ffcaf462050) at mi/tree.c:79 #1 0x000000000053d5a2 in free_mi_tree (parent=0x7ffcaf462a28) at mi/tree.c:98 #2 0x00007ffcae376561 in default_method (env=, host=, methodName=, paramArray=, serverInfo=) at xr_server.c:267 #3 0x00007ffcadd41eab in ?? () #4 0x00007ffbaa082850 in ?? () #5 0x0000000000000000 in ?? () (gdb) bt full #0 free_mi_node (parent=0x7ffcaf462050) at mi/tree.c:79 p = 0x18 q = 0x18 #1 0x000000000053d5a2 in free_mi_tree (parent=0x7ffcaf462a28) at mi/tree.c:98 p = 0x0 q = #2 0x00007ffcae376561 in default_method (env=, host=, methodName=, paramArray=, serverInfo=) at xr_server.c:267 ret = mi_cmd = 0x7ffcaf462a28 mi_rpl = hdl = f = response = is_shm = __FUNCTION__ = "default_method" #3 0x00007ffcadd41eab in ?? () No symbol table info available. #4 0x00007ffbaa082850 in ?? () No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. (gdb) #0 free_mi_node (parent=0x7ffcaf462050) at mi/tree.c:79 p = 0x18 q = 0x18 #1 0x000000000053d5a2 in free_mi_tree (parent=0x7ffcaf462a28) at mi/tree.c:98 p = 0x0 q = #2 0x00007ffcae376561 in default_method (env=, host=, methodName=, paramArray=, serverInfo=) at xr_server.c:267 ret = mi_cmd = 0x7ffcaf462a28 mi_rpl = hdl = f = response = is_shm = __FUNCTION__ = "default_method" #3 0x00007ffcadd41eab in ?? () No symbol table info available. #4 0x00007ffbaa082850 in ?? () No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. (gdb) #0 free_mi_node (parent=0x7ffcaf462050) at mi/tree.c:79 p = 0x18 q = 0x18 #1 0x000000000053d5a2 in free_mi_tree (parent=0x7ffcaf462a28) at mi/tree.c:98 p = 0x0 q = #2 0x00007ffcae376561 in default_method (env=, host=, methodName=, paramArray=, serverInfo=) at xr_server.c:267 ret = mi_cmd = 0x7ffcaf462a28 mi_rpl = hdl = f = response = is_shm = __FUNCTION__ = "default_method" #3 0x00007ffcadd41eab in ?? () No symbol table info available. #4 0x00007ffbaa082850 in ?? () No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. (gdb) ^C(gdb) Quit (gdb) quit [root at localhost opensips]# -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/core-dump-when-use-mi-xmlrpc-module-tp7594167p7594169.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From liviu at opensips.org Wed Oct 22 13:20:08 2014 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 22 Oct 2014 14:20:08 +0300 Subject: [OpenSIPS-Users] Get variables in failure route In-Reply-To: <1BB0DB97-920C-4F47-89EB-F693F827D3EF@gmail.com> References: <1BB0DB97-920C-4F47-89EB-F693F827D3EF@gmail.com> Message-ID: <544792E8.3090307@opensips.org> Hello Alexander, You need to specify the context of a pseudo-var. [1] For your script, you should use $(fU) and $(fd). [1]: http://www.opensips.org/Documentation/Script-CoreVar-2-1 Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 10/22/2014 01:13 PM, Alexander Mustafin wrote: > Hello. > > I need to receive variables from 407 message in failure route, but > when I tried it - I received a value from initial message. > > INVITE sip:055555534534 at sbc.sbc.sbc SIP/2.0. > Via: SIP/2.0/UDP 54.55.56.57:12000;rport;branch=z9hG4bK37Ny7QvNF7Hrc. > Max-Forwards: 70. > From: ?User" ;tag=ct7BK7ccyaK7H. > > SIP/2.0 407 Proxy Authentication Required. > From: ;tag=ct7BK7ccyaK7H. > To: ;tag=9560995. > > failure_route[EXTERNAL_FAULT] { > if (t_was_cancelled()) { > xlog("L_INFO", "$ci|log|transaction was cancelled"); > > exit; > } > $var(auth_user) = $fU + "@" + $fd; > } > > In variable $var(auth_user) I've seen 77777777777 at office.sbc.sbc > . > > Can I receive values from 407 message? > > Best regards, > Alexander Mustafin > mustafin.aleksandr at gmail.com > > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Oct 22 17:41:19 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 22 Oct 2014 18:41:19 +0300 Subject: [OpenSIPS-Users] [Event] OpenSIPS @ Astricon Message-ID: <5447D01F.3010207@opensips.org> Hi, OpenSIPS project is present at Astricon event. We have a booth with the project and we are glad to have you visiting us. For meeting, for chatting, for questions. Also several speakers will give OpenSIPS related talks: Bogdan-Andrei Iancu Ali Pey Pete Kelly Flavio Goncalves Regards from Vegas, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com From gn62 at gmx.us Wed Oct 22 17:56:25 2014 From: gn62 at gmx.us (Gary Nyquist) Date: Wed, 22 Oct 2014 17:56:25 +0200 Subject: [OpenSIPS-Users] Call external program from reply_rote In-Reply-To: <5446AA0B.3010608@opensips.org> References: , <5446AA0B.3010608@opensips.org> Message-ID: Thanks Bogdan for the tips. It works! Best Regards, - Gary > Sent: Tuesday, October 21, 2014 at 2:46 PM > From: "Bogdan-Andrei Iancu" > To: "OpenSIPS users mailling list" , gn62 at gmx.us > Subject: Re: [OpenSIPS-Users] Call external program from reply_rote > > Hi Gary, > > You can do an ugly trick like: > > route[EXEC] { > exec(....); > } > > onreply_route[...] { > .... > route(EXEC); > .... > } > > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 21.10.2014 00:56, Gary Nyquist wrote: > > Hi, > > > > I need to call an external program from the REPLY_ROUTE (on getting 200 OK). > > As per the doc, "exec_msg" and "exec_avp" can be used from REQUEST_ROUTE & FAILURE_ROUTE only. > > Is there any alternative methods to run external programs from the REPLY_ROUTE? > > > > Best Regards, > > - Gary > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > From gn62 at gmx.us Thu Oct 23 01:06:29 2014 From: gn62 at gmx.us (Gary Nyquist) Date: Thu, 23 Oct 2014 01:06:29 +0200 Subject: [OpenSIPS-Users] Call external program from reply_rote Message-ID: Hi Bogdan, As I said, it works; but the following errors/warnings fill up the logs: ERROR:core:parse_uri: uri too short: <200> (3) WARNING:exec:append_fixed_vars: uri not parsed ERROR:core:parse_uri: uri too short: <200> (3) WARNING:exec:append_fixed_vars: orig URI not parsed Each "200 OK" reply logging above 4 lines. Any clues how to get rid of these logs? Best Regards, - Gary Thanks Bogdan for the tips. It works! Best Regards, - Gary > Sent: Tuesday, October 21, 2014 at 2:46 PM > From: "Bogdan-Andrei Iancu" > To: "OpenSIPS users mailling list" , gn62 at gmx.us > Subject: Re: [OpenSIPS-Users] Call external program from reply_rote > > Hi Gary, > > You can do an ugly trick like: > > route[EXEC] { > exec(....); > } > > onreply_route[...] { > .... > route(EXEC); > .... > } > > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 21.10.2014 00:56, Gary Nyquist wrote: > > Hi, > > > > I need to call an external program from the REPLY_ROUTE (on getting 200 OK). > > As per the doc, "exec_msg" and "exec_avp" can be used from REQUEST_ROUTE & FAILURE_ROUTE only. > > Is there any alternative methods to run external programs from the REPLY_ROUTE? > > > > Best Regards, > > - Gary > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > From pflowers at mergecom.co.nz Thu Oct 23 02:06:36 2014 From: pflowers at mergecom.co.nz (Peter Flowers) Date: Thu, 23 Oct 2014 13:06:36 +1300 Subject: [OpenSIPS-Users] Issue with /etc/init.d/opensips on new test install In-Reply-To: References: Message-ID: Plan B got around that problem. (Original problem still there) I renamed the original opensips.cfg in /usr/local/opensips/etc/opensips then changed opensips_residential.cfg to opensips.cfg. The init.d script then found the correct script and after fixing the few config errors and changing the init.d script back to original the init.d script did its thing and everything is good. regards On 21 October 2014 15:24, Peter Flowers wrote: > Hi Tito > > this is the mpath in opensips_residential.cfg: > #set module path > mpath="/usr/local/opensips/lib/opensips/modules/" > > This is the path to the modules. > > this is the mpath in the file opensips.cfg which is in the same directory > as the _residential one I want to use. > > #set module path > mpath="/opensips//lib/opensips/modules/" > > I think my problem is the init script is picking this cfg file not the > _residential one hence all my errors. > > thanks > > On 21 October 2014 14:34, Tito Cumpen wrote: > >> Peter, >> >> Verify that your modules path within the cfg is correct. From the look of >> the log output it looks as if the module is failing to load or you are no >> loading the tm module. Functions specific to a module are dependent of the >> module to execute. Is this a 64 bit os? >> >> Thanks, >> Tito >> On Oct 20, 2014 9:19 PM, "Peter Flowers" wrote: >> >>> Hi >>> I was following the OpenSIPS Kick Start video but using Debian 7.4 and >>> OpenSIPS 1.11.3. Everything went pretty well till the end and starting >>> openSIPS with the init script. >>> >>> I set the install prefix as /usr/local/opensips and created a >>> residential cfg file. This I renamed to opensips_residential.cfg. >>> >>> When I went to start opensips with /etc/init.d/opensips start there were >>> lots of critical errors like these >>> >>> Oct 20 22:43:44 [3363] CRITICAL:core:yyerror: parse error in config file >>> /usr/local/opensips//etc/opensips/opensips.cfg, line 255, column 15-16: >>> unknown command , missing loadmodule? >>> Oct 20 22:43:44 [3363] CRITICAL:core:yyerror: parse error in config file >>> /usr/local/opensips//etc/opensips/opensips.cfg, line 256, column 19-20: >>> unknown command , missing loadmodule? >>> Oct 20 22:43:44 [3363] CRITICAL:core:yyerror: parse error in config file >>> /usr/local/opensips//etc/opensips/opensips.cfg, line 276, column 22-23: >>> unknown command , missing loadmodule? >>> Oct 20 22:43:44 [3363] ERROR:core:main: bad config file (79 errors) >>> >>> The new layout of the init.d script is a bit different than the video, >>> particularly the beginning. It looks to me like the init.d script is not >>> picking up the correct location of the opensips_residential.cfg file and >>> picking a default opensips.cfg file. >>> >>> This is what I put in the init.d >>> >>> PATH=/sbin:/bin:/usr/sbin:/usr/bin >>> DAEMON=*/usr/local/opensips/sbin/opensips* >>> NAME=opensips >>> DESC=opensips >>> CFGFILE=*/usr/local/opensips/etc/opensips/opensips_residential.cfg* >>> M4CFGFILE=/etc/opensips/opensips.m4 >>> M4ARCHIVEDIR=/etc/opensips/archive >>> HOMEDIR=/var/run/opensips >>> PIDFILE=$HOMEDIR/$NAME.pid >>> DEFAULTS=/etc/default/opensips >>> RUN_OPENSIPS=no >>> >>> and the options line looks like this >>> >>> OPTIONS="-P $PIDFILE -m $S_MEMORY -M $P_MEMORY -u $USER -g $GROUP *-f >>> /usr/local/opensips/etc/opensips/opensips_residential.cfg*" >>> >>> Any ideas very gratefully accepted >>> -- >>> Peter Flowers >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > > > -- > Peter Flowers > DDI 04 9138149 > www.mergecom.co.nz > > -- Peter Flowers DDI 04 9138149 www.mergecom.co.nz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mustafin.aleksandr at gmail.com Thu Oct 23 08:28:27 2014 From: mustafin.aleksandr at gmail.com (Alexander Mustafin) Date: Thu, 23 Oct 2014 12:28:27 +0600 Subject: [OpenSIPS-Users] Get variables in failure route In-Reply-To: <544792E8.3090307@opensips.org> References: <1BB0DB97-920C-4F47-89EB-F693F827D3EF@gmail.com> <544792E8.3090307@opensips.org> Message-ID: <45283C04-7C43-4ABD-B345-1C8C1F1DA2A4@gmail.com> Hi, Liviu. Thank you very much for the advice. Now, all works fine! Best regards, Alexander Mustafin mustafin.aleksandr at gmail.com 22 ???. 2014 ?., ? 17:20, Liviu Chircu ???????(?): > Hello Alexander, > > You need to specify the context of a pseudo-var. [1] > > For your script, you should use $(fU) and $(fd). > > [1]: http://www.opensips.org/Documentation/Script-CoreVar-2-1 > > Best regards, > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > On 10/22/2014 01:13 PM, Alexander Mustafin wrote: >> Hello. >> >> I need to receive variables from 407 message in failure route, but when I tried it - I received a value from initial message. >> >> INVITE sip:055555534534 at sbc.sbc.sbc SIP/2.0. >> Via: SIP/2.0/UDP 54.55.56.57:12000;rport;branch=z9hG4bK37Ny7QvNF7Hrc. >> Max-Forwards: 70. >> From: ?User" ;tag=ct7BK7ccyaK7H. >> >> SIP/2.0 407 Proxy Authentication Required. >> From: ;tag=ct7BK7ccyaK7H. >> To: ;tag=9560995. >> >> failure_route[EXTERNAL_FAULT] { >> if (t_was_cancelled()) { >> xlog("L_INFO", "$ci|log|transaction was cancelled"); >> >> exit; >> } >> >> $var(auth_user) = $fU + "@" + $fd; >> } >> >> In variable $var(auth_user) I?ve seen 77777777777 at office.sbc.sbc. >> >> Can I receive values from 407 message? >> >> Best regards, >> Alexander Mustafin >> mustafin.aleksandr at gmail.com >> >> >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From razvan at opensips.org Thu Oct 23 19:53:43 2014 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Thu, 23 Oct 2014 10:53:43 -0700 Subject: [OpenSIPS-Users] OpenSIPS Public Meeting - WebRTC Message-ID: <544940A7.1000808@opensips.org> Hello, all! The next public meeting will take place on IRC Wednesday, 29th of October 2014, at 17:00 EET[1]. The topic of the meeting is to discuss whether we should integrate WebRTC in OpenSIPS or not. Make sure you don't miss it, your opinion is important to us! [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenSIPS+Public+Meeting+-+WebRTC&iso=20141029T17&p1=49&ah=1 [2] http://www.opensips.org/Community/IRCmeeting20141029 Best regards, -- R?zvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com From bogdan at opensips.org Thu Oct 23 20:48:48 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 23 Oct 2014 21:48:48 +0300 Subject: [OpenSIPS-Users] [OpenSIPS-Devel] OpenSIPS Public Meeting - WebRTC In-Reply-To: <544940A7.1000808@opensips.org> References: <544940A7.1000808@opensips.org> Message-ID: <54494D90.1030000@opensips.org> As a starting point for the discussion, please take a look at: http://www.opensips.org/Documentation/Tutorials-WebSocket Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 23.10.2014 20:53, R?zvan Crainea wrote: > Hello, all! > > The next public meeting will take place on IRC Wednesday, 29th of > October 2014, at 17:00 EET[1]. The topic of the meeting is to discuss > whether we should integrate WebRTC in OpenSIPS or not. > Make sure you don't miss it, your opinion is important to us! > > [1] > http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenSIPS+Public+Meeting+-+WebRTC&iso=20141029T17&p1=49&ah=1 > [2] http://www.opensips.org/Community/IRCmeeting20141029 > > Best regards, From tito at xsvoce.com Thu Oct 23 22:09:53 2014 From: tito at xsvoce.com (Tito Cumpen) Date: Thu, 23 Oct 2014 16:09:53 -0400 Subject: [OpenSIPS-Users] failure route cancel tcp restrans Message-ID: Group, What is the best way to cancel or keep tcp retransmissions from happening after a request has been deemed a 477?/failure In my current scenario the request is sent to its respective failure route although the initial invite persist on being sent to an unresponsive b side. At failure I am routing the call to an alternative location IE voicemail. Thanks, Tito -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhouxiaoqiang.mstech at gmail.com Fri Oct 24 05:11:37 2014 From: zhouxiaoqiang.mstech at gmail.com (chow) Date: Thu, 23 Oct 2014 20:11:37 -0700 (PDT) Subject: [OpenSIPS-Users] core dump when use mi_xmlrpc module In-Reply-To: <1413973407012-7594169.post@n2.nabble.com> References: <1413972743978-7594167.post@n2.nabble.com> <1413973407012-7594169.post@n2.nabble.com> Message-ID: <1414120297076-7594211.post@n2.nabble.com> Hi? I use mi_datagram instead of mi_xmlrpc. mi_datagram module work for me. Thank you for any advice. -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/core-dump-when-use-mi-xmlrpc-module-tp7594167p7594211.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From osas at voipembedded.com Fri Oct 24 05:30:28 2014 From: osas at voipembedded.com (Ovidiu Sas) Date: Thu, 23 Oct 2014 23:30:28 -0400 Subject: [OpenSIPS-Users] core dump when use mi_xmlrpc module In-Reply-To: <1414120297076-7594211.post@n2.nabble.com> References: <1413972743978-7594167.post@n2.nabble.com> <1413973407012-7594169.post@n2.nabble.com> <1414120297076-7594211.post@n2.nabble.com> Message-ID: Use mi_xmlrpc_ng: http://www.opensips.org/html/docs/modules/1.11.x/mi_xmlrpc_ng.html Regards, Ovidiu Sas On Oct 23, 2014 11:11 PM, "chow" wrote: > Hi? > I use mi_datagram instead of mi_xmlrpc. > mi_datagram module work for me. > > Thank you for any advice. > > > > -- > View this message in context: > http://opensips-open-sip-server.1449251.n2.nabble.com/core-dump-when-use-mi-xmlrpc-module-tp7594167p7594211.html > Sent from the OpenSIPS - Users mailing list archive at Nabble.com. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedric at oceanet.com Fri Oct 24 11:31:57 2014 From: cedric at oceanet.com (=?ISO-8859-1?Q?OCEANET_-_C=E9dric_BASSAGET?=) Date: Fri, 24 Oct 2014 11:31:57 +0200 Subject: [OpenSIPS-Users] lookup() questions Message-ID: <544A1C8D.7030705@oceanet.com> Hello, I'm actually trying to resolve NAT issues with opensips, and I have a problem using lookup() function. UAC register to my opensips server. When UAC is behind nat (detected with nat_uac_test()), I do a "fix_nated_register()" and save("location"). My usrloc table looks correct, I have a line with (important fields): - a username = 2015 (sip trunk identifier) - a domain = the domain my UAC is registering to (= the domain my opensips is listening on) - a contact = sip:2015@ - a received = sip:: (in my tests, port=1024) - and many other fields (...) When trying to relay an incoming INVITE to this UAC, if I understood well, I have to do a "lookup()" before t_relay, to tell opensips to send the request to the "usrloc.received" . I've tried couple things, like : - lookup("location") -> $ru is totally different from what we are looking for, so it does not work, that's normal - lookup("location","","2015@") -> got an error : ERROR:core:parse_uri: bad uri, state 0 parsed: <2015> (4) / <2015 at domain> (37) - lookup("location","","sip:2015@") -> $retcode=1, and debug shows me this : DBG:registrar:lookup: found a complete match DBG:registrar:lookup: setting as ruri > but nothing goes out to ip address of my UAC... (tcpdump). Can somebody tell me if I've correctly understood how lookup() function works ? Or if I'm doing totally aberrant things ? Regards, C?dric From razvan at opensips.org Fri Oct 24 20:15:55 2014 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Fri, 24 Oct 2014 11:15:55 -0700 Subject: [OpenSIPS-Users] lookup() questions In-Reply-To: <544A1C8D.7030705@oceanet.com> References: <544A1C8D.7030705@oceanet.com> Message-ID: <544A975B.2010804@opensips.org> Hi, Cedric! The third version is the correct version you should use, if the R-URI is different than the AOR you are looking for. Are you sure that your tcpdump trace is tracking the UDP traffic? Are you sure there are no errors generated by t_relay()? Do you see t_relay DBG lines in the logs? Best regards, R?zvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 10/24/2014 02:31 AM, OCEANET - C?dric BASSAGET wrote: > Hello, > > I'm actually trying to resolve NAT issues with opensips, and I have a > problem using lookup() function. > > UAC register to my opensips server. When UAC is behind nat (detected > with nat_uac_test()), I do a "fix_nated_register()" and save("location"). > My usrloc table looks correct, I have a line with (important fields): > - a username = 2015 (sip trunk identifier) > - a domain = the domain my UAC is registering to (= the domain my > opensips is listening on) > - a contact = sip:2015@ > - a received = sip:: (in my tests, port=1024) > - and many other fields (...) > > When trying to relay an incoming INVITE to this UAC, if I understood > well, I have to do a "lookup()" before t_relay, to tell opensips to send > the request to the "usrloc.received" . > > I've tried couple things, like : > - lookup("location") -> $ru is totally different from what we are > looking for, so it does not work, that's normal > - lookup("location","","2015@") -> got an error : > ERROR:core:parse_uri: bad uri, state 0 parsed: <2015> (4) / > <2015 at domain> (37) > - lookup("location","","sip:2015@") -> $retcode=1, and debug > shows me this : > > DBG:registrar:lookup: found a complete match > DBG:registrar:lookup: setting as ruri > > but nothing goes out to ip address of my UAC... (tcpdump). > > Can somebody tell me if I've correctly understood how lookup() function > works ? Or if I'm doing totally aberrant things ? > > Regards, > C?dric > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From john.mathew at divoxmedia.com Sun Oct 26 12:10:53 2014 From: john.mathew at divoxmedia.com (John Mathew) Date: Sun, 26 Oct 2014 16:40:53 +0530 Subject: [OpenSIPS-Users] RTP to SRTP Support Message-ID: Which module to be used for SRTP support?, I believe its rtpengine but, is this module officially supported by opensips? -- Regards, John Mathew CEO/Director Divox International Inc. Contact: +91-9037100001 Email/MSN: John.Mathew at divoxmedia.com WEB: www.divoxmedia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbcbooksmj at gmail.com Mon Oct 27 03:15:39 2014 From: gbcbooksmj at gmail.com (Michael Leung) Date: Mon, 27 Oct 2014 10:15:39 +0800 Subject: [OpenSIPS-Users] how to generate a config file for module carrierroute and getting error "sorry -- cannot open write fifo" on opensips-cp Message-ID: Hi Guys i run opensips and opensips-cp well on ubuntu 14.04 but i get error Array ( [0] => sorry -- cannot open write fifo when i run opensips and opensips-cp on CentosOS 6 x86_64 that is so wired i pretty so i modify /etc/default/opensip to make sure that opensips is run root use and i check the following lines in /usr/local/opensips_proxy/etc/ opensips/opensips_residential_xxxxx.cfg #### FIFO Management Interface loadmodule "mi_fifo.so" modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo") modparam("mi_fifo", "fifo_mode", 0666) i also check opensips_fifo in /tmp as the screenshot next seems rights of fifo are correct [root at opensips ~]# ls -l /tmp/ total 4 srwxrwxrwx 1 root root 0 10? 26 12:46 OpenSIPS.2729.UzgMCc *prw------- 1 root root 0 10? 27 02:30 opensips_fifo* drwxr-xr-x. 3 root root 4096 10? 23 09:19 pear prw-rw-rw- 1 root root 0 10? 26 11:40 webfifo_1073486329 prw-rw-rw- 1 root root 0 10? 26 11:45 webfifo_1470388925 prw-rw-rw- 1 root root 0 10? 26 11:46 webfifo_1476361529 prw-rw-rw- 1 root root 0 10? 26 11:44 webfifo_1502401728 prw-rw-rw- 1 root root 0 10? 26 11:43 webfifo_1518457939 prw-rw-rw- 1 root root 0 10? 26 11:38 webfifo_1873894080 prw-rw-rw- 1 root root 0 10? 26 11:47 webfifo_1952463342 prw-rw-rw- 1 root root 0 10? 26 11:42 webfifo_1972326408 prw-rw-rw- 1 root root 0 10? 26 11:36 webfifo_314032636 prw-rw-rw- 1 root root 0 10? 26 11:35 webfifo_411862295 prw-rw-rw- 1 root root 0 10? 26 11:39 webfifo_428297397 prw-rw-rw- 1 root root 0 10? 26 11:37 webfifo_452862263 prw-rw-rw- 1 root root 0 10? 26 11:41 webfifo_978440604 -rw-------. 1 root root 0 10? 23 06:15 yum.log from output of /var/log/httpd/error.log i was told user did not have permission to write /read /tmp/opensips_fifo file [Sun Oct 26 12:55:55 2014] [error] [client 10.67.67.11] PHP Notice: A session had already been started - ignoring session_start() in /var/www/opensips-cp/web/tools/system/smonitor/lib/put_select_boxes.php on line 25, referer:http://10.67.255.154/cp/menu.php [Sun Oct 26 12:55:55 2014] [error] [client 10.67.67.11] PHP Notice: Undefined variable: box_val in /var/www/opensips-cp/web/tools/system/smonitor/lib/functions.inc.php on line 306, referer: http://10.67.255.154/cp/menu.php [Sun Oct 26 12:55:55 2014] [error] [client 10.67.67.11] PHP Notice: Undefined variable: arg_list in /var/www/opensips-cp/web/common/mi_comm.php on line 178, referer: http://10.67.255.154/cp/menu.php [Sun Oct 26 12:55:55 2014] [error] [client 10.67.67.11] PHP Warning: fopen(/tmp/opensips_fifo): failed to open stream: *Permission denied* in /var/www/opensips-cp/web/common/mi_comm.php on line 193, referer: http://10.67.255.154/cp/menu.php anyone faced my problem before? there is another problem i read opensips support document http://www.opensips.org/html/docs/modules/1.11.x/carrierroute.html#id295092 for twice but i still dont figure out where and how can i generate a config file that required by carrierroute.so before opensips initialated . thanks for your help very much Michael Leung -------------- next part -------------- An HTML attachment was scrubbed... URL: From sunil.sipuser at gmail.com Mon Oct 27 07:05:08 2014 From: sunil.sipuser at gmail.com (Sunil P) Date: Mon, 27 Oct 2014 11:35:08 +0530 Subject: [OpenSIPS-Users] Convert SDP Connection IP Message-ID: Hi Bogdan, Thanks for your reply.Please let me know if there is anyway to know whether SDP Connection parameter(c) contains IPV4 or IPV6 address. Thanks and Regards, Sunil Date: Tue, 21 Oct 2014 21:24:29 +0300 From: Bogdan-Andrei Iancu Subject: Re: [OpenSIPS-Users] Convert SDP Connection IP To: OpenSIPS users mailling list Message-ID: <5446A4DD.1060308 at opensips.org> Content-Type: text/plain; charset="windows-1252"; Format="flowed" Hi Sunil, See the fix_nated_sdp() function in the nathelper module: http://www.opensips.org/html/docs/modules/1.11.x/nathelper.html#id293864 Use the second parameter to push your own IP address into SDP. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 21.10.2014 07:59, Sunil P wrote: > > Hi All, > > I need to make Opensips AS to act as IBCF, which is going to > convert the V6 SDP to V4 SDP and Vice Versa.Please suggest me in > which functions I need to change > to convert SDP Connection Parameter. > > Thanks and Regards, > Sunil -------------- next part -------------- An HTML attachment was scrubbed... URL: From GB at cm.nl Mon Oct 27 10:07:45 2014 From: GB at cm.nl (Grant Bagdasarian) Date: Mon, 27 Oct 2014 10:07:45 +0100 Subject: [OpenSIPS-Users] Selecting RTPproxy instance on 200 OK reply Message-ID: Hello, I have the following RTPproxy configuration: modparam("nathelper", "rtpproxy_sock", "1 == udp:127.0.0.1:12221") modparam("nathelper", "rtpproxy_sock", "2 == udp:127.0.0.1:12222") In the main route I decide which instance to select for each INVITE containing SDP: if($ru=~"1.1.1.10") { set_rtp_proxy_set("1"); xlog("L_INFO", "USE RTP PROXY 01 \r\n"); } else if($ru=~"2.2.2.10") { set_rtp_proxy_set("2"); xlog("L_INFO", "USE RTP PROXY 02 \r\n"); } else { t_reply("404", "Not Found"); exit; } rtpproxy_offer(); I'm getting the following error for a 200 OK: ERROR:nathelper:select_rtpp_node: script error -no valid set selected ERROR:nathelper:force_rtp_proxy_body: no available proxies Do I need to do the same decision for 200 OK messages, and call rtpproxy_answer()? Regards, Grant -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedric at oceanet.com Mon Oct 27 11:37:49 2014 From: cedric at oceanet.com (=?UTF-8?B?T0NFQU5FVCAtIEPDqWRyaWMgQkFTU0FHRVQ=?=) Date: Mon, 27 Oct 2014 11:37:49 +0100 Subject: [OpenSIPS-Users] lookup() questions In-Reply-To: <544A975B.2010804@opensips.org> References: <544A1C8D.7030705@oceanet.com> <544A975B.2010804@opensips.org> Message-ID: <544E207D.5010208@oceanet.com> Hello R?zvan, Thanks for your reply. Yes, I'm sure i'm tracking udp trafic, I can see SIP options for example. I've found my error, and it's a big one : I was doing "exit" in my switch() statement, instead of "break". So t_relay was never called... No comment... So the lookup function seems to work correctly, but it does not do what I expect. What I want is just to send SIP requests to UAC behind NAT on the good udp port (ex : 1025, corresponding to the "received" field in usrloc). Actually (when not using lookup() ), requests are sent to port 5060, whatever the value of "received" field is. But I don't want to change user and domain part of RURI, just adjust the port. With lookup() function : incoming INVITE RURI : sip:0970559986@:5060 INVITE RURI after lookup (to my UAC) : sip:2015@ invite is relayed to udp port 1025, which is a good thing. But username has been changed, and I don't want that. Without lookup() function, invite is relayed to port 5060, so my router/nat doesn't route it correctly -> nothing works. Don't hesitate to ask if this is not clear. I don't know where to look for, usrloc seems to be good, but is not used well... Should I do a mysql query to extract the port of the "received" in usrloc, and then play qith $dp and $rp ? I think there is something simpler than that, but I can't find it. I hope somebody can help me ...! Regards, C?dric OCEANET --------------------------------------------------------------- [AGENCE DU MANS] 7, rue des Fr?nes ZAC de la Pointe 72190 SARGE LES LE MANS [t] +33 (0)2.43.50.26.50 [f] +33 (0)2.43.72.21.14 [AGENCE D'ANGERS] 5, rue Fleming Angers Technopole 49066 ANGERS [t] +33 (0)2.41.19.28.65 [f] +33 (0)2.52.19.22.00 http://www.oceanet.com http://www.oceanet-telecom.com On 24/10/2014 20:15, R?zvan Crainea wrote: > Hi, Cedric! > > The third version is the correct version you should use, if the R-URI > is different than the AOR you are looking for. > Are you sure that your tcpdump trace is tracking the UDP traffic? Are > you sure there are no errors generated by t_relay()? Do you see > t_relay DBG lines in the logs? > > Best regards, > > R?zvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 10/24/2014 02:31 AM, OCEANET - C?dric BASSAGET wrote: >> Hello, >> >> I'm actually trying to resolve NAT issues with opensips, and I have a >> problem using lookup() function. >> >> UAC register to my opensips server. When UAC is behind nat (detected >> with nat_uac_test()), I do a "fix_nated_register()" and >> save("location"). >> My usrloc table looks correct, I have a line with (important fields): >> - a username = 2015 (sip trunk identifier) >> - a domain = the domain my UAC is registering to (= the domain my >> opensips is listening on) >> - a contact = sip:2015@ >> - a received = sip:: (in my tests, port=1024) >> - and many other fields (...) >> >> When trying to relay an incoming INVITE to this UAC, if I understood >> well, I have to do a "lookup()" before t_relay, to tell opensips to send >> the request to the "usrloc.received" . >> >> I've tried couple things, like : >> - lookup("location") -> $ru is totally different from what we are >> looking for, so it does not work, that's normal >> - lookup("location","","2015@") -> got an error : >> ERROR:core:parse_uri: bad uri, state 0 parsed: <2015> (4) / >> <2015 at domain> (37) >> - lookup("location","","sip:2015@") -> $retcode=1, and debug >> shows me this : >> >> DBG:registrar:lookup: found a complete match >> DBG:registrar:lookup: setting as ruri > >> but nothing goes out to ip address of my UAC... (tcpdump). >> >> Can somebody tell me if I've correctly understood how lookup() function >> works ? Or if I'm doing totally aberrant things ? >> >> Regards, >> C?dric >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From gbcbooksmj at gmail.com Tue Oct 28 07:05:22 2014 From: gbcbooksmj at gmail.com (Michael Leung) Date: Tue, 28 Oct 2014 14:05:22 +0800 Subject: [OpenSIPS-Users] how to generate a config file for module carrierroute and getting error "sorry -- cannot open write fifo" on opensips-cp In-Reply-To: References: Message-ID: seems no one care about my problem On Mon, Oct 27, 2014 at 10:15 AM, Michael Leung wrote: > Hi Guys > > i run opensips and opensips-cp well on ubuntu 14.04 but i get error > > Array ( [0] => sorry -- cannot open write fifo > > when i run opensips and opensips-cp on CentosOS 6 x86_64 > > that is so wired > > i pretty so i modify /etc/default/opensip to make sure that opensips is > run root use > > and i check the following lines in /usr/local/opensips_proxy/etc/ > opensips/opensips_residential_xxxxx.cfg > > #### FIFO Management Interface > loadmodule "mi_fifo.so" > modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo") > modparam("mi_fifo", "fifo_mode", 0666) > > i also check opensips_fifo in /tmp as the screenshot next > > seems rights of fifo are correct > > [root at opensips ~]# ls -l /tmp/ > total 4 > srwxrwxrwx 1 root root 0 10? 26 12:46 OpenSIPS.2729.UzgMCc > *prw------- 1 root root 0 10? 27 02:30 opensips_fifo* > drwxr-xr-x. 3 root root 4096 10? 23 09:19 pear > prw-rw-rw- 1 root root 0 10? 26 11:40 webfifo_1073486329 > prw-rw-rw- 1 root root 0 10? 26 11:45 webfifo_1470388925 > prw-rw-rw- 1 root root 0 10? 26 11:46 webfifo_1476361529 > prw-rw-rw- 1 root root 0 10? 26 11:44 webfifo_1502401728 > prw-rw-rw- 1 root root 0 10? 26 11:43 webfifo_1518457939 > prw-rw-rw- 1 root root 0 10? 26 11:38 webfifo_1873894080 > prw-rw-rw- 1 root root 0 10? 26 11:47 webfifo_1952463342 > prw-rw-rw- 1 root root 0 10? 26 11:42 webfifo_1972326408 > prw-rw-rw- 1 root root 0 10? 26 11:36 webfifo_314032636 > prw-rw-rw- 1 root root 0 10? 26 11:35 webfifo_411862295 > prw-rw-rw- 1 root root 0 10? 26 11:39 webfifo_428297397 > prw-rw-rw- 1 root root 0 10? 26 11:37 webfifo_452862263 > prw-rw-rw- 1 root root 0 10? 26 11:41 webfifo_978440604 > -rw-------. 1 root root 0 10? 23 06:15 yum.log > > > > from output of /var/log/httpd/error.log > i was told user did not have permission to write /read /tmp/opensips_fifo > file > > > [Sun Oct 26 12:55:55 2014] [error] [client 10.67.67.11] PHP Notice: A > session had already been started - ignoring session_start() in > /var/www/opensips-cp/web/tools/system/smonitor/lib/put_select_boxes.php on > line 25, referer:http://10.67.255.154/cp/menu.php > [Sun Oct 26 12:55:55 2014] [error] [client 10.67.67.11] PHP Notice: > Undefined variable: box_val in > /var/www/opensips-cp/web/tools/system/smonitor/lib/functions.inc.php on > line 306, referer: http://10.67.255.154/cp/menu.php > [Sun Oct 26 12:55:55 2014] [error] [client 10.67.67.11] PHP Notice: > Undefined variable: arg_list in /var/www/opensips-cp/web/common/mi_comm.php > on line 178, referer: http://10.67.255.154/cp/menu.php > [Sun Oct 26 12:55:55 2014] [error] [client 10.67.67.11] PHP Warning: > fopen(/tmp/opensips_fifo): failed to open stream: *Permission denied* in > /var/www/opensips-cp/web/common/mi_comm.php on line 193, referer: > http://10.67.255.154/cp/menu.php > > anyone faced my problem before? > > > there is another problem > > i read opensips support document > http://www.opensips.org/html/docs/modules/1.11.x/carrierroute.html#id295092 for > twice > > but i still dont figure out where and how can i generate a config file > that required by carrierroute.so before opensips initialated . > > > thanks for your help very much > > > Michael Leung > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhouxiaoqiang.mstech at gmail.com Tue Oct 28 07:37:32 2014 From: zhouxiaoqiang.mstech at gmail.com (chow) Date: Mon, 27 Oct 2014 23:37:32 -0700 (PDT) Subject: [OpenSIPS-Users] GMT format for date Message-ID: <1414478251986-7594225.post@n2.nabble.com> Hi I want get GMT format for date that use like this: append_hf("Date-Internal: $time(%a, %d %b %Y %H:%M:%S GMT)\r\n"); but the system tinezone is CST, then $time return CST format. how covert CST to GMT in opensips.cfg thanks for your advice -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/GMT-format-for-date-tp7594225.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From zhouxiaoqiang.mstech at gmail.com Tue Oct 28 08:10:22 2014 From: zhouxiaoqiang.mstech at gmail.com (zhouxiaoqiang.mstech at gmail.com) Date: Tue, 28 Oct 2014 15:10:22 +0800 Subject: [OpenSIPS-Users] how to generate a config file for module carrierroute and getting error "sorry -- cannot open write fifo" on opensips-cp References: , Message-ID: <201410281510200682322@gmail.com> Hi: tell me what user and group for httpd service start. may be there have diffirent user between opensips and httpd zhouxiaoqiang.mstech at gmail.com From: Michael Leung Date: 2014-10-28 14:05 To: Users Subject: Re: [OpenSIPS-Users] how to generate a config file for module carrierroute and getting error "sorry -- cannot open write fifo" on opensips-cp seems no one care about my problem On Mon, Oct 27, 2014 at 10:15 AM, Michael Leung wrote: Hi Guys i run opensips and opensips-cp well on ubuntu 14.04 but i get error Array ( [0] => sorry -- cannot open write fifo when i run opensips and opensips-cp on CentosOS 6 x86_64 that is so wired i pretty so i modify /etc/default/opensip to make sure that opensips is run root use and i check the following lines in /usr/local/opensips_proxy/etc/opensips/opensips_residential_xxxxx.cfg #### FIFO Management Interface loadmodule "mi_fifo.so" modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo") modparam("mi_fifo", "fifo_mode", 0666) i also check opensips_fifo in /tmp as the screenshot next seems rights of fifo are correct [root at opensips ~]# ls -l /tmp/ total 4 srwxrwxrwx 1 root root 0 10? 26 12:46 OpenSIPS.2729.UzgMCc prw------- 1 root root 0 10? 27 02:30 opensips_fifo drwxr-xr-x. 3 root root 4096 10? 23 09:19 pear prw-rw-rw- 1 root root 0 10? 26 11:40 webfifo_1073486329 prw-rw-rw- 1 root root 0 10? 26 11:45 webfifo_1470388925 prw-rw-rw- 1 root root 0 10? 26 11:46 webfifo_1476361529 prw-rw-rw- 1 root root 0 10? 26 11:44 webfifo_1502401728 prw-rw-rw- 1 root root 0 10? 26 11:43 webfifo_1518457939 prw-rw-rw- 1 root root 0 10? 26 11:38 webfifo_1873894080 prw-rw-rw- 1 root root 0 10? 26 11:47 webfifo_1952463342 prw-rw-rw- 1 root root 0 10? 26 11:42 webfifo_1972326408 prw-rw-rw- 1 root root 0 10? 26 11:36 webfifo_314032636 prw-rw-rw- 1 root root 0 10? 26 11:35 webfifo_411862295 prw-rw-rw- 1 root root 0 10? 26 11:39 webfifo_428297397 prw-rw-rw- 1 root root 0 10? 26 11:37 webfifo_452862263 prw-rw-rw- 1 root root 0 10? 26 11:41 webfifo_978440604 -rw-------. 1 root root 0 10? 23 06:15 yum.log from output of /var/log/httpd/error.log i was told user did not have permission to write /read /tmp/opensips_fifo file [Sun Oct 26 12:55:55 2014] [error] [client 10.67.67.11] PHP Notice: A session had already been started - ignoring session_start() in /var/www/opensips-cp/web/tools/system/smonitor/lib/put_select_boxes.php on line 25, referer:http://10.67.255.154/cp/menu.php [Sun Oct 26 12:55:55 2014] [error] [client 10.67.67.11] PHP Notice: Undefined variable: box_val in /var/www/opensips-cp/web/tools/system/smonitor/lib/functions.inc.php on line 306, referer: http://10.67.255.154/cp/menu.php [Sun Oct 26 12:55:55 2014] [error] [client 10.67.67.11] PHP Notice: Undefined variable: arg_list in /var/www/opensips-cp/web/common/mi_comm.php on line 178, referer: http://10.67.255.154/cp/menu.php [Sun Oct 26 12:55:55 2014] [error] [client 10.67.67.11] PHP Warning: fopen(/tmp/opensips_fifo): failed to open stream: Permission denied in /var/www/opensips-cp/web/common/mi_comm.php on line 193, referer:http://10.67.255.154/cp/menu.php anyone faced my problem before? there is another problem i read opensips support document http://www.opensips.org/html/docs/modules/1.11.x/carrierroute.html#id295092 for twice but i still dont figure out where and how can i generate a config file that required by carrierroute.so before opensips initialated . thanks for your help very much Michael Leung -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Tue Oct 28 09:54:48 2014 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 28 Oct 2014 10:54:48 +0200 Subject: [OpenSIPS-Users] how to generate a config file for module carrierroute and getting error "sorry -- cannot open write fifo" on opensips-cp In-Reply-To: References: Message-ID: <544F59D8.6040609@opensips.org> Hello Michael, Have you restarted OpenSIPS after making the permission changes? I'm saying this because: - you have correctly fixed the permissions issue in your script with: modparam("mi_fifo", "fifo_mode", 0666) - however, these changes are not yet visible in your /tmp directory!* prw------- 1 root root 0 10? 27 02:30 opensips_fifo* It could also be possible that OpenSIPS is running on a different script than you are expecting. Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 10/27/2014 04:15 AM, Michael Leung wrote: > Hi Guys > > i run opensips and opensips-cp well on ubuntu 14.04 but i get error > > Array ( [0] => sorry -- cannot open write fifo > > when i run opensips and opensips-cp on CentosOS 6 x86_64 > > that is so wired > > i pretty so i modify /etc/default/opensip to make sure that opensips > is run root use > > and i check the following lines in > /usr/local/opensips_proxy/etc/opensips/opensips_residential_xxxxx.cfg > > #### FIFO Management Interface > loadmodule "mi_fifo.so" > modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo") > modparam("mi_fifo", "fifo_mode", 0666) > > i also check opensips_fifo in /tmp as the screenshot next > > seems rights of fifo are correct > > [root at opensips ~]# ls -l /tmp/ > total 4 > srwxrwxrwx 1 root root 0 10? 26 12:46 OpenSIPS.2729.UzgMCc > *prw------- 1 root root 0 10? 27 02:30 opensips_fifo* > drwxr-xr-x. 3 root root 4096 10? 23 09:19 pear > prw-rw-rw- 1 root root 0 10? 26 11:40 webfifo_1073486329 > prw-rw-rw- 1 root root 0 10? 26 11:45 webfifo_1470388925 > prw-rw-rw- 1 root root 0 10? 26 11:46 webfifo_1476361529 > prw-rw-rw- 1 root root 0 10? 26 11:44 webfifo_1502401728 > prw-rw-rw- 1 root root 0 10? 26 11:43 webfifo_1518457939 > prw-rw-rw- 1 root root 0 10? 26 11:38 webfifo_1873894080 > prw-rw-rw- 1 root root 0 10? 26 11:47 webfifo_1952463342 > prw-rw-rw- 1 root root 0 10? 26 11:42 webfifo_1972326408 > prw-rw-rw- 1 root root 0 10? 26 11:36 webfifo_314032636 > prw-rw-rw- 1 root root 0 10? 26 11:35 webfifo_411862295 > prw-rw-rw- 1 root root 0 10? 26 11:39 webfifo_428297397 > prw-rw-rw- 1 root root 0 10? 26 11:37 webfifo_452862263 > prw-rw-rw- 1 root root 0 10? 26 11:41 webfifo_978440604 > -rw-------. 1 root root 0 10? 23 06:15 yum.log > > > > from output of /var/log/httpd/error.log > i was told user did not have permission to write /read > /tmp/opensips_fifo file > > > [Sun Oct 26 12:55:55 2014] [error] [client 10.67.67.11] PHP Notice: A > session had already been started - ignoring session_start() in > /var/www/opensips-cp/web/tools/system/smonitor/lib/put_select_boxes.php on > line 25, referer:http://10.67.255.154/cp/menu.php > [Sun Oct 26 12:55:55 2014] [error] [client 10.67.67.11] PHP Notice: > Undefined variable: box_val in > /var/www/opensips-cp/web/tools/system/smonitor/lib/functions.inc.php > on line 306, referer: http://10.67.255.154/cp/menu.php > [Sun Oct 26 12:55:55 2014] [error] [client 10.67.67.11] PHP Notice: > Undefined variable: arg_list in > /var/www/opensips-cp/web/common/mi_comm.php on line 178, referer: > http://10.67.255.154/cp/menu.php > [Sun Oct 26 12:55:55 2014] [error] [client 10.67.67.11] PHP Warning: > fopen(/tmp/opensips_fifo): failed to open stream:***Permission > denied* in /var/www/opensips-cp/web/common/mi_comm.php on line 193, > referer:http://10.67.255.154/cp/menu.php > > anyone faced my problem before? > > > there is another problem > > i read opensips support document > http://www.opensips.org/html/docs/modules/1.11.x/carrierroute.html#id295092 for > twice > > but i still dont figure out where and how can i generate a config file > that required by carrierroute.so before opensips initialated . > > > thanks for your help very much > > > Michael Leung > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbcbooksmj at gmail.com Tue Oct 28 10:57:06 2014 From: gbcbooksmj at gmail.com (Michael Leung) Date: Tue, 28 Oct 2014 17:57:06 +0800 Subject: [OpenSIPS-Users] how to generate a config file for module carrierroute and getting error "sorry -- cannot open write fifo" on opensips-cp In-Reply-To: <544F59D8.6040609@opensips.org> References: <544F59D8.6040609@opensips.org> Message-ID: to Zhou [root at opensips ~]# ps -axu | grep -i httpd Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.8/FAQ root 1798 0.0 0.5 285088 10616 ? Ss Oct26 0:04 /usr/sbin/httpd apache 1831 0.0 0.2 285000 5832 ? S Oct26 0:00 /usr/sbin/httpd apache 1834 0.0 0.5 287980 10964 ? S Oct26 0:00 /usr/sbin/httpd apache 1837 0.0 0.5 288000 10900 ? S Oct26 0:00 /usr/sbin/httpd apache 1840 0.0 0.5 287980 10964 ? S Oct26 0:00 /usr/sbin/httpd apache 1842 0.0 0.5 287716 10784 ? S Oct26 0:00 /usr/sbin/httpd apache 1844 0.0 0.4 287148 10060 ? S Oct26 0:00 /usr/sbin/httpd apache 1845 0.0 0.5 287744 10760 ? S Oct26 0:00 /usr/sbin/httpd apache 1847 0.0 0.4 287808 10188 ? S Oct26 0:00 /usr/sbin/httpd apache 1849 0.0 0.5 287632 10696 ? S Oct26 0:00 /usr/sbin/httpd root 1882 0.0 0.0 103252 864 pts/0 S+ 10:04 0:00 grep -i httpd i think httpd run as apache users to Livui i actually restart service and machine many times , OMG, i just to restart opensips service and opensips-cp work fine now , i really think i did this steps before, any way ,thanks a lot this the fifo issue has been solved , what about the carrierroute one? On Tue, Oct 28, 2014 at 4:54 PM, Liviu Chircu wrote: > Hello Michael, > > Have you restarted OpenSIPS after making the permission changes? I'm > saying this because: > > - you have correctly fixed the permissions issue in your script with: > modparam("mi_fifo", "fifo_mode", 0666) > > - however, these changes are not yet visible in your /tmp directory! > * prw------- 1 root root 0 10? 27 02:30 opensips_fifo* > > It could also be possible that OpenSIPS is running on a different script > than you are expecting. > > Best regards, > > Liviu Chircu > OpenSIPS Developerhttp://www.opensips-solutions.com > > On 10/27/2014 04:15 AM, Michael Leung wrote: > > Hi Guys > > i run opensips and opensips-cp well on ubuntu 14.04 but i get error > > Array ( [0] => sorry -- cannot open write fifo > > when i run opensips and opensips-cp on CentosOS 6 x86_64 > > that is so wired > > i pretty so i modify /etc/default/opensip to make sure that opensips is > run root use > > and i check the following lines in /usr/local/opensips_proxy/etc/ > opensips/opensips_residential_xxxxx.cfg > > #### FIFO Management Interface > loadmodule "mi_fifo.so" > modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo") > modparam("mi_fifo", "fifo_mode", 0666) > > i also check opensips_fifo in /tmp as the screenshot next > > seems rights of fifo are correct > > [root at opensips ~]# ls -l /tmp/ > total 4 > srwxrwxrwx 1 root root 0 10? 26 12:46 OpenSIPS.2729.UzgMCc > *prw------- 1 root root 0 10? 27 02:30 opensips_fifo* > drwxr-xr-x. 3 root root 4096 10? 23 09:19 pear > prw-rw-rw- 1 root root 0 10? 26 11:40 webfifo_1073486329 > prw-rw-rw- 1 root root 0 10? 26 11:45 webfifo_1470388925 > prw-rw-rw- 1 root root 0 10? 26 11:46 webfifo_1476361529 > prw-rw-rw- 1 root root 0 10? 26 11:44 webfifo_1502401728 > prw-rw-rw- 1 root root 0 10? 26 11:43 webfifo_1518457939 > prw-rw-rw- 1 root root 0 10? 26 11:38 webfifo_1873894080 > prw-rw-rw- 1 root root 0 10? 26 11:47 webfifo_1952463342 > prw-rw-rw- 1 root root 0 10? 26 11:42 webfifo_1972326408 > prw-rw-rw- 1 root root 0 10? 26 11:36 webfifo_314032636 > prw-rw-rw- 1 root root 0 10? 26 11:35 webfifo_411862295 > prw-rw-rw- 1 root root 0 10? 26 11:39 webfifo_428297397 > prw-rw-rw- 1 root root 0 10? 26 11:37 webfifo_452862263 > prw-rw-rw- 1 root root 0 10? 26 11:41 webfifo_978440604 > -rw-------. 1 root root 0 10? 23 06:15 yum.log > > > > from output of /var/log/httpd/error.log > i was told user did not have permission to write /read /tmp/opensips_fifo > file > > > [Sun Oct 26 12:55:55 2014] [error] [client 10.67.67.11] PHP Notice: A > session had already been started - ignoring session_start() in > /var/www/opensips-cp/web/tools/system/smonitor/lib/put_select_boxes.php on > line 25, referer:http://10.67.255.154/cp/menu.php > [Sun Oct 26 12:55:55 2014] [error] [client 10.67.67.11] PHP Notice: > Undefined variable: box_val in > /var/www/opensips-cp/web/tools/system/smonitor/lib/functions.inc.php on > line 306, referer: http://10.67.255.154/cp/menu.php > [Sun Oct 26 12:55:55 2014] [error] [client 10.67.67.11] PHP Notice: > Undefined variable: arg_list in /var/www/opensips-cp/web/common/mi_comm.php > on line 178, referer: http://10.67.255.154/cp/menu.php > [Sun Oct 26 12:55:55 2014] [error] [client 10.67.67.11] PHP Warning: > fopen(/tmp/opensips_fifo): failed to open stream: *Permission denied* in > /var/www/opensips-cp/web/common/mi_comm.php on line 193, referer: > http://10.67.255.154/cp/menu.php > > anyone faced my problem before? > > > there is another problem > > i read opensips support document > http://www.opensips.org/html/docs/modules/1.11.x/carrierroute.html#id295092 for > twice > > but i still dont figure out where and how can i generate a config file > that required by carrierroute.so before opensips initialated . > > > thanks for your help very much > > > Michael Leung > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Oct 28 11:40:16 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 28 Oct 2014 12:40:16 +0200 Subject: [OpenSIPS-Users] Call external program from reply_rote In-Reply-To: References: Message-ID: <544F7290.1000805@opensips.org> Hi Gary, It seems the exec() functions to expect to receive and parse a SIP requests after all. I can try to prepare a patch to have them working for replies too. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 23.10.2014 02:06, Gary Nyquist wrote: > Hi Bogdan, > > As I said, it works; but the following errors/warnings fill up the logs: > > ERROR:core:parse_uri: uri too short: <200> (3) > WARNING:exec:append_fixed_vars: uri not parsed > ERROR:core:parse_uri: uri too short: <200> (3) > WARNING:exec:append_fixed_vars: orig URI not parsed > > Each "200 OK" reply logging above 4 lines. > Any clues how to get rid of these logs? > > Best Regards, > - Gary > > > > > > > Thanks Bogdan for the tips. > > It works! > > Best Regards, > - Gary > > >> Sent: Tuesday, October 21, 2014 at 2:46 PM >> From: "Bogdan-Andrei Iancu" >> To: "OpenSIPS users mailling list" , gn62 at gmx.us >> Subject: Re: [OpenSIPS-Users] Call external program from reply_rote >> >> Hi Gary, >> >> You can do an ugly trick like: >> >> route[EXEC] { >> exec(....); >> } >> >> onreply_route[...] { >> .... >> route(EXEC); >> .... >> } >> >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> On 21.10.2014 00:56, Gary Nyquist wrote: >>> Hi, >>> >>> I need to call an external program from the REPLY_ROUTE (on getting 200 OK). >>> As per the doc, "exec_msg" and "exec_avp" can be used from REQUEST_ROUTE & FAILURE_ROUTE only. >>> Is there any alternative methods to run external programs from the REPLY_ROUTE? >>> >>> Best Regards, >>> - Gary >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> From bogdan at opensips.org Tue Oct 28 12:41:16 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 28 Oct 2014 13:41:16 +0200 Subject: [OpenSIPS-Users] Convert SDP Connection IP In-Reply-To: References: Message-ID: <544F80DC.3090908@opensips.org> Hi Sunil, You can use the sdp.line transformation to get the c line : http://www.opensips.org/Documentation/Script-Tran-1-11#toc70 Form there you can use a regexp to test the IP http://www.opensips.org/Documentation/Script-Tran-1-11#toc71 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 27.10.2014 08:05, Sunil P wrote: > Hi Bogdan, > > Thanks for your reply.Please let me know if there is anyway to > know whether SDP Connection parameter(c) contains IPV4 or IPV6 address. > > Thanks and Regards, > Sunil > > > > Date: Tue, 21 Oct 2014 21:24:29 +0300 > From: Bogdan-Andrei Iancu > > Subject: Re: [OpenSIPS-Users] Convert SDP Connection IP > To: OpenSIPS users mailling list > > Message-ID: <5446A4DD.1060308 at opensips.org > > > Content-Type: text/plain; charset="windows-1252"; Format="flowed" > > Hi Sunil, > > See the fix_nated_sdp() function in the nathelper module: > http://www.opensips.org/html/docs/modules/1.11.x/nathelper.html#id293864 > > Use the second parameter to push your own IP address into SDP. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 21.10.2014 07:59, Sunil P wrote: > > > > Hi All, > > > > I need to make Opensips AS to act as IBCF, which is going to > > convert the V6 SDP to V4 SDP and Vice Versa.Please suggest me in > > which functions I need to change > > to convert SDP Connection Parameter. > > > > Thanks and Regards, > > Sunil -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Tue Oct 28 13:23:32 2014 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Tue, 28 Oct 2014 14:23:32 +0200 Subject: [OpenSIPS-Users] Selecting RTPproxy instance on 200 OK reply In-Reply-To: References: Message-ID: <544F8AC4.1050502@opensips.org> Hi, Grant! For the reply, you have to select _the same_ set. You don't really have to add the same decision logic for reply, you can store the set used for requests in the AVP and use that AVP on the reply. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 10/27/2014 11:07 AM, Grant Bagdasarian wrote: > > Hello, > > I have the following RTPproxy configuration: > > modparam("nathelper", "rtpproxy_sock", "1 == udp:127.0.0.1:12221") > > modparam("nathelper", "rtpproxy_sock", "2 == udp:127.0.0.1:12222") > > In the main route I decide which instance to select for each INVITE > containing SDP: > > if($ru=~"1.1.1.10") { > > set_rtp_proxy_set("1"); > > xlog("L_INFO", "USE RTP PROXY 01 \r\n"); > > } else if($ru=~"2.2.2.10") { > > set_rtp_proxy_set("2"); > > xlog("L_INFO", "USE RTP PROXY 02 \r\n"); > > } else { > > t_reply("404", "Not Found"); > > exit; > > } > > rtpproxy_offer(); > > I?m getting the following error for a 200 OK: > > ERROR:nathelper:select_rtpp_node: script error -no valid set selected > > ERROR:nathelper:force_rtp_proxy_body: no available proxies > > Do I need to do the same decision for 200 OK messages, and call > rtpproxy_answer()? > > Regards, > > Grant > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Tue Oct 28 13:33:22 2014 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Tue, 28 Oct 2014 14:33:22 +0200 Subject: [OpenSIPS-Users] lookup() questions In-Reply-To: <544E207D.5010208@oceanet.com> References: <544A1C8D.7030705@oceanet.com> <544A975B.2010804@opensips.org> <544E207D.5010208@oceanet.com> Message-ID: <544F8D12.8060104@opensips.org> Hi, Cedric! So your problem is that the username in the R-URI is changed after the lookup() function? If that, you can restore it by using something like this: $var(username) = $rU; if (lookup("location", "", "sip:2015 at IP") { $rU = $var(username); } Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 10/27/2014 12:37 PM, OCEANET - C?dric BASSAGET wrote: > Hello R?zvan, > > Thanks for your reply. > Yes, I'm sure i'm tracking udp trafic, I can see SIP options for example. > I've found my error, and it's a big one : I was doing "exit" in my > switch() statement, instead of "break". So t_relay was never called... > No comment... > > So the lookup function seems to work correctly, but it does not do > what I expect. > > What I want is just to send SIP requests to UAC behind NAT on the good > udp port (ex : 1025, corresponding to the "received" field in usrloc). > Actually (when not using lookup() ), requests are sent to port 5060, > whatever the value of "received" field is. But I don't want to change > user and domain part of RURI, just adjust the port. > > With lookup() function : > incoming INVITE RURI : sip:0970559986@:5060 > INVITE RURI after lookup (to my UAC) : sip:2015@ > > invite is relayed to udp port 1025, which is a good thing. But > username has been changed, and I don't want that. > > Without lookup() function, invite is relayed to port 5060, so my > router/nat doesn't route it correctly -> nothing works. > > Don't hesitate to ask if this is not clear. I don't know where to look > for, usrloc seems to be good, but is not used well... > > Should I do a mysql query to extract the port of the "received" in > usrloc, and then play qith $dp and $rp ? I think there is something > simpler than that, but I can't find it. > > I hope somebody can help me ...! > Regards, > C?dric > > > > > > > OCEANET > --------------------------------------------------------------- > [AGENCE DU MANS] > 7, rue des Fr?nes > ZAC de la Pointe > 72190 SARGE LES LE MANS > [t] +33 (0)2.43.50.26.50 > [f] +33 (0)2.43.72.21.14 > > [AGENCE D'ANGERS] > 5, rue Fleming > Angers Technopole > 49066 ANGERS > [t] +33 (0)2.41.19.28.65 > [f] +33 (0)2.52.19.22.00 > > http://www.oceanet.com > http://www.oceanet-telecom.com > > On 24/10/2014 20:15, R?zvan Crainea wrote: >> Hi, Cedric! >> >> The third version is the correct version you should use, if the R-URI >> is different than the AOR you are looking for. >> Are you sure that your tcpdump trace is tracking the UDP traffic? Are >> you sure there are no errors generated by t_relay()? Do you see >> t_relay DBG lines in the logs? >> >> Best regards, >> >> R?zvan Crainea >> OpenSIPS Core Developer >> http://www.opensips-solutions.com >> >> On 10/24/2014 02:31 AM, OCEANET - C?dric BASSAGET wrote: >>> Hello, >>> >>> I'm actually trying to resolve NAT issues with opensips, and I have a >>> problem using lookup() function. >>> >>> UAC register to my opensips server. When UAC is behind nat (detected >>> with nat_uac_test()), I do a "fix_nated_register()" and >>> save("location"). >>> My usrloc table looks correct, I have a line with (important fields): >>> - a username = 2015 (sip trunk identifier) >>> - a domain = the domain my UAC is registering to (= the domain my >>> opensips is listening on) >>> - a contact = sip:2015@ >>> - a received = sip:: (in my tests, port=1024) >>> - and many other fields (...) >>> >>> When trying to relay an incoming INVITE to this UAC, if I understood >>> well, I have to do a "lookup()" before t_relay, to tell opensips to >>> send >>> the request to the "usrloc.received" . >>> >>> I've tried couple things, like : >>> - lookup("location") -> $ru is totally different from what we are >>> looking for, so it does not work, that's normal >>> - lookup("location","","2015@") -> got an error : >>> ERROR:core:parse_uri: bad uri, state 0 parsed: <2015> (4) / >>> <2015 at domain> (37) >>> - lookup("location","","sip:2015@") -> $retcode=1, and debug >>> shows me this : >>> >>> DBG:registrar:lookup: found a complete match >>> DBG:registrar:lookup: setting as ruri > >>> but nothing goes out to ip address of my UAC... (tcpdump). >>> >>> Can somebody tell me if I've correctly understood how lookup() function >>> works ? Or if I'm doing totally aberrant things ? >>> >>> Regards, >>> C?dric >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From bogdan at opensips.org Tue Oct 28 13:37:12 2014 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 28 Oct 2014 14:37:12 +0200 Subject: [OpenSIPS-Users] lookup() questions In-Reply-To: <544E207D.5010208@oceanet.com> References: <544A1C8D.7030705@oceanet.com> <544A975B.2010804@opensips.org> <544E207D.5010208@oceanet.com> Message-ID: <544F8DF8.5050800@opensips.org> Hello Cedric, First of all, do not forget about the nat flag (see nat_bflag in usrloc module): http://www.opensips.org/html/docs/modules/1.11.x/usrloc.html#id293683 You should set it before save(location), if REGISTER comes from behind a NAT. Now, if the usrloc records has a "received" field, when doing lookup(location), you will get: contact URI in $ru received URI in $du And when doing t_relay(), $du (outbound proxy) has priority over $ru, so the call should be sent to 1014 port. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 27.10.2014 12:37, OCEANET - C?dric BASSAGET wrote: > Hello R?zvan, > > Thanks for your reply. > Yes, I'm sure i'm tracking udp trafic, I can see SIP options for example. > I've found my error, and it's a big one : I was doing "exit" in my > switch() statement, instead of "break". So t_relay was never called... > No comment... > > So the lookup function seems to work correctly, but it does not do > what I expect. > > What I want is just to send SIP requests to UAC behind NAT on the good > udp port (ex : 1025, corresponding to the "received" field in usrloc). > Actually (when not using lookup() ), requests are sent to port 5060, > whatever the value of "received" field is. But I don't want to change > user and domain part of RURI, just adjust the port. > > With lookup() function : > incoming INVITE RURI : sip:0970559986@:5060 > INVITE RURI after lookup (to my UAC) : sip:2015@ > > invite is relayed to udp port 1025, which is a good thing. But > username has been changed, and I don't want that. > > Without lookup() function, invite is relayed to port 5060, so my > router/nat doesn't route it correctly -> nothing works. > > Don't hesitate to ask if this is not clear. I don't know where to look > for, usrloc seems to be good, but is not used well... > > Should I do a mysql query to extract the port of the "received" in > usrloc, and then play qith $dp and $rp ? I think there is something > simpler than that, but I can't find it. > > I hope somebody can help me ...! > Regards, > C?dric > > > > > > > OCEANET > --------------------------------------------------------------- > [AGENCE DU MANS] > 7, rue des Fr?nes > ZAC de la Pointe > 72190 SARGE LES LE MANS > [t] +33 (0)2.43.50.26.50 > [f] +33 (0)2.43.72.21.14 > > [AGENCE D'ANGERS] > 5, rue Fleming > Angers Technopole > 49066 ANGERS > [t] +33 (0)2.41.19.28.65 > [f] +33 (0)2.52.19.22.00 > > http://www.oceanet.com > http://www.oceanet-telecom.com > > On 24/10/2014 20:15, R?zvan Crainea wrote: >> Hi, Cedric! >> >> The third version is the correct version you should use, if the R-URI >> is different than the AOR you are looking for. >> Are you sure that your tcpdump trace is tracking the UDP traffic? Are >> you sure there are no errors generated by t_relay()? Do you see >> t_relay DBG lines in the logs? >> >> Best regards, >> >> R?zvan Crainea >> OpenSIPS Core Developer >> http://www.opensips-solutions.com >> >> On 10/24/2014 02:31 AM, OCEANET - C?dric BASSAGET wrote: >>> Hello, >>> >>> I'm actually trying to resolve NAT issues with opensips, and I have a >>> problem using lookup() function. >>> >>> UAC register to my opensips server. When UAC is behind nat (detected >>> with nat_uac_test()), I do a "fix_nated_register()" and >>> save("location"). >>> My usrloc table looks correct, I have a line with (important fields): >>> - a username = 2015 (sip trunk identifier) >>> - a domain = the domain my UAC is registering to (= the domain my >>> opensips is listening on) >>> - a contact = sip:2015@ >>> - a received = sip:: (in my tests, port=1024) >>> - and many other fields (...) >>> >>> When trying to relay an incoming INVITE to this UAC, if I understood >>> well, I have to do a "lookup()" before t_relay, to tell opensips to >>> send >>> the request to the "usrloc.received" . >>> >>> I've tried couple things, like : >>> - lookup("location") -> $ru is totally different from what we are >>> looking for, so it does not work, that's normal >>> - lookup("location","","2015@") -> got an error : >>> ERROR:core:parse_uri: bad uri, state 0 parsed: <2015> (4) / >>> <2015 at domain> (37) >>> - lookup("location","","sip:2015@") -> $retcode=1, and debug >>> shows me this : >>> >>> DBG:registrar:lookup: found a complete match >>> DBG:registrar:lookup: setting as ruri > >>> but nothing goes out to ip address of my UAC... (tcpdump). >>> >>> Can somebody tell me if I've correctly understood how lookup() function >>> works ? Or if I'm doing totally aberrant things ? >>> >>> Regards, >>> C?dric >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From GB at cm.nl Tue Oct 28 13:49:38 2014 From: GB at cm.nl (Grant Bagdasarian) Date: Tue, 28 Oct 2014 13:49:38 +0100 Subject: [OpenSIPS-Users] Selecting RTPproxy instance on 200 OK reply In-Reply-To: <544F8AC4.1050502@opensips.org> References: <544F8AC4.1050502@opensips.org> Message-ID: Awesome! Thank you for answering! :D From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea Sent: Tuesday, October 28, 2014 1:24 PM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] Selecting RTPproxy instance on 200 OK reply Hi, Grant! For the reply, you have to select _the same_ set. You don't really have to add the same decision logic for reply, you can store the set used for requests in the AVP and use that AVP on the reply. Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 10/27/2014 11:07 AM, Grant Bagdasarian wrote: Hello, I have the following RTPproxy configuration: modparam("nathelper", "rtpproxy_sock", "1 == udp:127.0.0.1:12221") modparam("nathelper", "rtpproxy_sock", "2 == udp:127.0.0.1:12222") In the main route I decide which instance to select for each INVITE containing SDP: if($ru=~"1.1.1.10") { set_rtp_proxy_set("1"); xlog("L_INFO", "USE RTP PROXY 01 \r\n"); } else if($ru=~"2.2.2.10") { set_rtp_proxy_set("2"); xlog("L_INFO", "USE RTP PROXY 02 \r\n"); } else { t_reply("404", "Not Found"); exit; } rtpproxy_offer(); I?m getting the following error for a 200 OK: ERROR:nathelper:select_rtpp_node: script error -no valid set selected ERROR:nathelper:force_rtp_proxy_body: no available proxies Do I need to do the same decision for 200 OK messages, and call rtpproxy_answer()? Regards, Grant _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Tue Oct 28 13:56:28 2014 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Tue, 28 Oct 2014 14:56:28 +0200 Subject: [OpenSIPS-Users] GMT format for date In-Reply-To: <1414478251986-7594225.post@n2.nabble.com> References: <1414478251986-7594225.post@n2.nabble.com> Message-ID: <544F927C.2090104@opensips.org> Hi, Chow! Unfortunately there is no method to change the timezone for the "time" pvar. You can add a feature request to support this here: https://github.com/OpenSIPS/opensips/issues Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 10/28/2014 08:37 AM, chow wrote: > Hi > I want get GMT format for date that use like this: > append_hf("Date-Internal: $time(%a, %d %b %Y %H:%M:%S GMT)\r\n"); > but the system tinezone is CST, then $time return CST format. > how covert CST to GMT in opensips.cfg > thanks for your advice > > > > -- > View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/GMT-format-for-date-tp7594225.html > Sent from the OpenSIPS - Users mailing list archive at Nabble.com. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From razvan at opensips.org Tue Oct 28 18:52:44 2014 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Tue, 28 Oct 2014 19:52:44 +0200 Subject: [OpenSIPS-Users] Call external program from reply_rote In-Reply-To: <544F7290.1000805@opensips.org> References: <544F7290.1000805@opensips.org> Message-ID: <544FD7EC.30703@opensips.org> Hi, Gary! I have pushed a patch for 1.11 downto 1.8 for this issue. However, if you can't update your sources now, setting the setvars[1] parameter to 0 should make this work. [1] http://www.opensips.org/html/docs/modules/1.11.x/exec.html#id248413 Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 10/28/2014 12:40 PM, Bogdan-Andrei Iancu wrote: > Hi Gary, > > It seems the exec() functions to expect to receive and parse a SIP > requests after all. I can try to prepare a patch to have them working > for replies too. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 23.10.2014 02:06, Gary Nyquist wrote: >> Hi Bogdan, >> >> As I said, it works; but the following errors/warnings fill up the logs: >> >> ERROR:core:parse_uri: uri too short: <200> (3) >> WARNING:exec:append_fixed_vars: uri not parsed >> ERROR:core:parse_uri: uri too short: <200> (3) >> WARNING:exec:append_fixed_vars: orig URI not parsed >> >> Each "200 OK" reply logging above 4 lines. >> Any clues how to get rid of these logs? >> >> Best Regards, >> - Gary >> >> >> >> >> >> >> Thanks Bogdan for the tips. >> >> It works! >> >> Best Regards, >> - Gary >> >> >>> Sent: Tuesday, October 21, 2014 at 2:46 PM >>> From: "Bogdan-Andrei Iancu" >>> To: "OpenSIPS users mailling list" , >>> gn62 at gmx.us >>> Subject: Re: [OpenSIPS-Users] Call external program from reply_rote >>> >>> Hi Gary, >>> >>> You can do an ugly trick like: >>> >>> route[EXEC] { >>> exec(....); >>> } >>> >>> onreply_route[...] { >>> .... >>> route(EXEC); >>> .... >>> } >>> >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> >>> On 21.10.2014 00:56, Gary Nyquist wrote: >>>> Hi, >>>> >>>> I need to call an external program from the REPLY_ROUTE (on getting >>>> 200 OK). >>>> As per the doc, "exec_msg" and "exec_avp" can be used from >>>> REQUEST_ROUTE & FAILURE_ROUTE only. >>>> Is there any alternative methods to run external programs from the >>>> REPLY_ROUTE? >>>> >>>> Best Regards, >>>> - Gary >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>> > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From michele.pinassi at unisi.it Wed Oct 29 11:49:19 2014 From: michele.pinassi at unisi.it (Michele Pinassi) Date: Wed, 29 Oct 2014 11:49:19 +0100 Subject: [OpenSIPS-Users] BLF and PRESENCE Message-ID: <5450C62F.9010208@unisi.it> Hi all, on our opensips system i'm trying to implement PRESENCE-BLF funcionality, where the boss phone (Snom 760) "subscribe" the workers line and see when they are busy/free. As i see, here's my opensips.cfg relevant parts: [...] #### PRESENCE modules loadmodule "presence.so" loadmodule "presence_xml.so" loadmodule "presence_mwi.so" loadmodule "presence_callinfo.so" loadmodule "xcap.so" modparam("presence", "server_address", "sip:sa at 172.20.1.2:5060") modparam("presence_xml", "force_active", 1) modparam("xcap","db_url","mysql://voip:4LaGjZCK8C6pp3RK at mysql.unisi.it/opensips") modparam("xcap", "integrated_xcap_server", 1) [...] and simply add a route for presence: [...] if( is_method("PUBLISH|SUBSCRIBE")) route(handle_presence); [...] # Presence route route[handle_presence] { xlog("L_INFO","Route PRESENCE [$fd/$fu/$rd/$ru/$si/]\n"); if(!t_newtran()){ sl_reply_error(); exit; } if (is_method("PUBLISH")) { handle_publish(); } if (is_method("SUBSCRIBE")) { handle_subscribe(); } exit; } [...] on the boss phone (5002) i set up BLF for 5009 but BLF simply don't work. On Opensips logs i have: Oct 29 11:47:05 proxy-voip01 /usr/sbin/opensips[5494]: Route PRESENCE [voip.unisi.it/sip:5002 at voip.unisi.it:5060/voip.unisi.it/sip:5008 at voip.unisi.it:5060;user=phone/172.20.1.10/] Oct 29 11:47:05 proxy-voip01 /usr/sbin/opensips[5494]: INFO:presence:handle_subscribe: Missing or unsupported event header field value Oct 29 11:47:05 proxy-voip01 /usr/sbin/opensips[5494]: INFO:presence:handle_subscribe: #011event= dialog [...] Oct 29 11:47:32 proxy-voip01 /usr/sbin/opensips[5496]: Route PRESENCE [voip.unisi.it/sip:5022 at voip.unisi.it:5060/voip.unisi.it/sip:*98 at voip.unisi.it:5060;user=phone/172.20.2.12/] Oct 29 11:47:32 proxy-voip01 /usr/sbin/opensips[5496]: INFO:presence:update_subscription: notify Oct 29 11:47:32 proxy-voip01 /usr/sbin/opensips[5496]: INFO:presence:send_notify_request: NOTIFY sip:5022 at voip.unisi.it via sip:5022 at 172.20.2.12:32768 on behalf of sip:*98 at voip.unisi.it for event message-summary, to_tag=f315b2d58ae8829149b784764c5a40e3-c2fb, cseq=1 Moreover, i've tried to see how watchers/presentity works but i'm not able to find any tutorial....hints ? Suggestions ? Thanks, Michele -- Michele Pinassi Responsabile Telefonia di Ateneo Servizio Reti, Sistemi e Sicurezza Informatica - Universit? degli Studi di Siena tel: 0577.(23)2169 - fax: 0577.(23)2053 Per trovare una soluzione rapida ai tuoi problemi tecnici consulta le FAQ di Ateneo, http://www.faq.unisi.it -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From cedric at oceanet.com Wed Oct 29 13:53:20 2014 From: cedric at oceanet.com (=?UTF-8?B?T0NFQU5FVCAtIEPDqWRyaWMgQkFTU0FHRVQ=?=) Date: Wed, 29 Oct 2014 13:53:20 +0100 Subject: [OpenSIPS-Users] lookup() questions In-Reply-To: <544F8D12.8060104@opensips.org> References: <544A1C8D.7030705@oceanet.com> <544A975B.2010804@opensips.org> <544E207D.5010208@oceanet.com> <544F8D12.8060104@opensips.org> Message-ID: <5450E340.6080608@oceanet.com> Thanks R?zvan, seems to fix part of my poblem ! Regards, C?dric OCEANET --------------------------------------------------------------- [AGENCE DU MANS] 7, rue des Fr?nes ZAC de la Pointe 72190 SARGE LES LE MANS [t] +33 (0)2.43.50.26.50 [f] +33 (0)2.43.72.21.14 [AGENCE D'ANGERS] 5, rue Fleming Angers Technopole 49066 ANGERS [t] +33 (0)2.41.19.28.65 [f] +33 (0)2.52.19.22.00 http://www.oceanet.com http://www.oceanet-telecom.com On 28/10/2014 13:33, R?zvan Crainea wrote: > Hi, Cedric! > > So your problem is that the username in the R-URI is changed after the > lookup() function? If that, you can restore it by using something like > this: > > $var(username) = $rU; > if (lookup("location", "", "sip:2015 at IP") { > $rU = $var(username); > } > > Best regards, > > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 10/27/2014 12:37 PM, OCEANET - C?dric BASSAGET wrote: >> Hello R?zvan, >> >> Thanks for your reply. >> Yes, I'm sure i'm tracking udp trafic, I can see SIP options for >> example. >> I've found my error, and it's a big one : I was doing "exit" in my >> switch() statement, instead of "break". So t_relay was never >> called... No comment... >> >> So the lookup function seems to work correctly, but it does not do >> what I expect. >> >> What I want is just to send SIP requests to UAC behind NAT on the >> good udp port (ex : 1025, corresponding to the "received" field in >> usrloc). Actually (when not using lookup() ), requests are sent to >> port 5060, whatever the value of "received" field is. But I don't >> want to change user and domain part of RURI, just adjust the port. >> >> With lookup() function : >> incoming INVITE RURI : sip:0970559986@:5060 >> INVITE RURI after lookup (to my UAC) : sip:2015@ >> >> invite is relayed to udp port 1025, which is a good thing. But >> username has been changed, and I don't want that. >> >> Without lookup() function, invite is relayed to port 5060, so my >> router/nat doesn't route it correctly -> nothing works. >> >> Don't hesitate to ask if this is not clear. I don't know where to >> look for, usrloc seems to be good, but is not used well... >> >> Should I do a mysql query to extract the port of the "received" in >> usrloc, and then play qith $dp and $rp ? I think there is something >> simpler than that, but I can't find it. >> >> I hope somebody can help me ...! >> Regards, >> C?dric >> >> >> >> >> >> >> OCEANET >> --------------------------------------------------------------- >> [AGENCE DU MANS] >> 7, rue des Fr?nes >> ZAC de la Pointe >> 72190 SARGE LES LE MANS >> [t] +33 (0)2.43.50.26.50 >> [f] +33 (0)2.43.72.21.14 >> >> [AGENCE D'ANGERS] >> 5, rue Fleming >> Angers Technopole >> 49066 ANGERS >> [t] +33 (0)2.41.19.28.65 >> [f] +33 (0)2.52.19.22.00 >> >> http://www.oceanet.com >> http://www.oceanet-telecom.com >> >> On 24/10/2014 20:15, R?zvan Crainea wrote: >>> Hi, Cedric! >>> >>> The third version is the correct version you should use, if the >>> R-URI is different than the AOR you are looking for. >>> Are you sure that your tcpdump trace is tracking the UDP traffic? >>> Are you sure there are no errors generated by t_relay()? Do you see >>> t_relay DBG lines in the logs? >>> >>> Best regards, >>> >>> R?zvan Crainea >>> OpenSIPS Core Developer >>> http://www.opensips-solutions.com >>> >>> On 10/24/2014 02:31 AM, OCEANET - C?dric BASSAGET wrote: >>>> Hello, >>>> >>>> I'm actually trying to resolve NAT issues with opensips, and I have a >>>> problem using lookup() function. >>>> >>>> UAC register to my opensips server. When UAC is behind nat (detected >>>> with nat_uac_test()), I do a "fix_nated_register()" and >>>> save("location"). >>>> My usrloc table looks correct, I have a line with (important fields): >>>> - a username = 2015 (sip trunk identifier) >>>> - a domain = the domain my UAC is registering to (= the domain my >>>> opensips is listening on) >>>> - a contact = sip:2015@ >>>> - a received = sip:: (in my tests, port=1024) >>>> - and many other fields (...) >>>> >>>> When trying to relay an incoming INVITE to this UAC, if I understood >>>> well, I have to do a "lookup()" before t_relay, to tell opensips to >>>> send >>>> the request to the "usrloc.received" . >>>> >>>> I've tried couple things, like : >>>> - lookup("location") -> $ru is totally different from what we are >>>> looking for, so it does not work, that's normal >>>> - lookup("location","","2015@") -> got an error : >>>> ERROR:core:parse_uri: bad uri, state 0 parsed: <2015> (4) / >>>> <2015 at domain> (37) >>>> - lookup("location","","sip:2015@") -> $retcode=1, and debug >>>> shows me this : >>>> >>>> DBG:registrar:lookup: found a complete match >>>> DBG:registrar:lookup: setting as ruri > >>>> but nothing goes out to ip address of my UAC... (tcpdump). >>>> >>>> Can somebody tell me if I've correctly understood how lookup() >>>> function >>>> works ? Or if I'm doing totally aberrant things ? >>>> >>>> Regards, >>>> C?dric >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From cedric at oceanet.com Wed Oct 29 14:04:27 2014 From: cedric at oceanet.com (=?UTF-8?B?T0NFQU5FVCAtIEPDqWRyaWMgQkFTU0FHRVQ=?=) Date: Wed, 29 Oct 2014 14:04:27 +0100 Subject: [OpenSIPS-Users] lookup() questions In-Reply-To: <544F8DF8.5050800@opensips.org> References: <544A1C8D.7030705@oceanet.com> <544A975B.2010804@opensips.org> <544E207D.5010208@oceanet.com> <544F8DF8.5050800@opensips.org> Message-ID: <5450E5DB.6020600@oceanet.com> Hi Bogdan, thanks for your reply. nat_bflag is set before save(location), so I have a "received" field in my usrloc table. Here's what I see with debug : route[1][BEFORE LOOKUP] ru=sip:0970559986@ , du= route[1][LOOKUP] lookup with aor=sip:2015@ route[1][AFTER LOOKUP] ru=sip:2015@ , du=sip::1024 so $du seems to be good too. Now I have to play with $rU as R?zvan said, tu replace 2015 with the real phone number I'm trying to reach. Thanks for your help again. Regards, C?dric OCEANET --------------------------------------------------------------- [AGENCE DU MANS] 7, rue des Fr?nes ZAC de la Pointe 72190 SARGE LES LE MANS [t] +33 (0)2.43.50.26.50 [f] +33 (0)2.43.72.21.14 [AGENCE D'ANGERS] 5, rue Fleming Angers Technopole 49066 ANGERS [t] +33 (0)2.41.19.28.65 [f] +33 (0)2.52.19.22.00 http://www.oceanet.com http://www.oceanet-telecom.com On 28/10/2014 13:37, Bogdan-Andrei Iancu wrote: > Hello Cedric, > > First of all, do not forget about the nat flag (see nat_bflag in > usrloc module): > http://www.opensips.org/html/docs/modules/1.11.x/usrloc.html#id293683 > > You should set it before save(location), if REGISTER comes from behind > a NAT. > > Now, if the usrloc records has a "received" field, when doing > lookup(location), you will get: > contact URI in $ru > received URI in $du > > And when doing t_relay(), $du (outbound proxy) has priority over $ru, > so the call should be sent to 1014 port. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 27.10.2014 12:37, OCEANET - C?dric BASSAGET wrote: >> Hello R?zvan, >> >> Thanks for your reply. >> Yes, I'm sure i'm tracking udp trafic, I can see SIP options for >> example. >> I've found my error, and it's a big one : I was doing "exit" in my >> switch() statement, instead of "break". So t_relay was never >> called... No comment... >> >> So the lookup function seems to work correctly, but it does not do >> what I expect. >> >> What I want is just to send SIP requests to UAC behind NAT on the >> good udp port (ex : 1025, corresponding to the "received" field in >> usrloc). Actually (when not using lookup() ), requests are sent to >> port 5060, whatever the value of "received" field is. But I don't >> want to change user and domain part of RURI, just adjust the port. >> >> With lookup() function : >> incoming INVITE RURI : sip:0970559986@:5060 >> INVITE RURI after lookup (to my UAC) : sip:2015@ >> >> invite is relayed to udp port 1025, which is a good thing. But >> username has been changed, and I don't want that. >> >> Without lookup() function, invite is relayed to port 5060, so my >> router/nat doesn't route it correctly -> nothing works. >> >> Don't hesitate to ask if this is not clear. I don't know where to >> look for, usrloc seems to be good, but is not used well... >> >> Should I do a mysql query to extract the port of the "received" in >> usrloc, and then play qith $dp and $rp ? I think there is something >> simpler than that, but I can't find it. >> >> I hope somebody can help me ...! >> Regards, >> C?dric >> >> >> >> >> >> >> OCEANET >> --------------------------------------------------------------- >> [AGENCE DU MANS] >> 7, rue des Fr?nes >> ZAC de la Pointe >> 72190 SARGE LES LE MANS >> [t] +33 (0)2.43.50.26.50 >> [f] +33 (0)2.43.72.21.14 >> >> [AGENCE D'ANGERS] >> 5, rue Fleming >> Angers Technopole >> 49066 ANGERS >> [t] +33 (0)2.41.19.28.65 >> [f] +33 (0)2.52.19.22.00 >> >> http://www.oceanet.com >> http://www.oceanet-telecom.com >> >> On 24/10/2014 20:15, R?zvan Crainea wrote: >>> Hi, Cedric! >>> >>> The third version is the correct version you should use, if the >>> R-URI is different than the AOR you are looking for. >>> Are you sure that your tcpdump trace is tracking the UDP traffic? >>> Are you sure there are no errors generated by t_relay()? Do you see >>> t_relay DBG lines in the logs? >>> >>> Best regards, >>> >>> R?zvan Crainea >>> OpenSIPS Core Developer >>> http://www.opensips-solutions.com >>> >>> On 10/24/2014 02:31 AM, OCEANET - C?dric BASSAGET wrote: >>>> Hello, >>>> >>>> I'm actually trying to resolve NAT issues with opensips, and I have a >>>> problem using lookup() function. >>>> >>>> UAC register to my opensips server. When UAC is behind nat (detected >>>> with nat_uac_test()), I do a "fix_nated_register()" and >>>> save("location"). >>>> My usrloc table looks correct, I have a line with (important fields): >>>> - a username = 2015 (sip trunk identifier) >>>> - a domain = the domain my UAC is registering to (= the domain my >>>> opensips is listening on) >>>> - a contact = sip:2015@ >>>> - a received = sip:: (in my tests, port=1024) >>>> - and many other fields (...) >>>> >>>> When trying to relay an incoming INVITE to this UAC, if I understood >>>> well, I have to do a "lookup()" before t_relay, to tell opensips to >>>> send >>>> the request to the "usrloc.received" . >>>> >>>> I've tried couple things, like : >>>> - lookup("location") -> $ru is totally different from what we are >>>> looking for, so it does not work, that's normal >>>> - lookup("location","","2015@") -> got an error : >>>> ERROR:core:parse_uri: bad uri, state 0 parsed: <2015> (4) / >>>> <2015 at domain> (37) >>>> - lookup("location","","sip:2015@") -> $retcode=1, and debug >>>> shows me this : >>>> >>>> DBG:registrar:lookup: found a complete match >>>> DBG:registrar:lookup: setting as ruri > >>>> but nothing goes out to ip address of my UAC... (tcpdump). >>>> >>>> Can somebody tell me if I've correctly understood how lookup() >>>> function >>>> works ? Or if I'm doing totally aberrant things ? >>>> >>>> Regards, >>>> C?dric >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From eahaselhoff at gmail.com Wed Oct 29 14:13:00 2014 From: eahaselhoff at gmail.com (Edwin) Date: Wed, 29 Oct 2014 06:13:00 -0700 (PDT) Subject: [OpenSIPS-Users] opensips-snmpstats-module and libsnmp15 Message-ID: <1414588380404-7594269.post@n2.nabble.com> I tried to install the opensips-snmpstats-module (1.11.3-1-dee7da41) on debian testing. I use the stable111 repro (deb http://apt.opensips.org/ stable111 main) The latest opensips-snmpstats-module is compiled against libsnmp15 which i believe to be deprecated (it's still available in debian stable and stable old...) Would it be possible to place the module compiled against libsnmp30 (and is this the right place to ask?) Regards, Edwin -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/opensips-snmpstats-module-and-libsnmp15-tp7594269.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From matt at supportedbusiness.com Wed Oct 29 14:21:58 2014 From: matt at supportedbusiness.com (Matt Broad) Date: Wed, 29 Oct 2014 13:21:58 +0000 Subject: [OpenSIPS-Users] Load balancer setup In-Reply-To: References: Message-ID: Hi, just seeing if anyone had any ideas? thanks Matt On 22 October 2014 08:42, matt wrote: > Hi, > > > I was looking for some guidance on using the load balancer in a NAT > environment. > > I have the following setup (the IP addresses are made up but should give > an indication): > > 1 x opensips server with load balancer module - IP 192.168.0.1 > 2 x freeswitch servers - IP 192.168.0.2 & 192.168.0.3 > > All 3 servers have seperate external IP address routing to their internal > IP via our firewall: > 217.0.0.1 routed to 192.168.0.1 (Opensips) > 217.0.0.2 routed to 192.168.0.2 (FS1) > 217.0.0.3 routed to 192.168.0.3 (FS2) > > I have the load_balancer table with the following details: > > id, | group_id, | dst_uri, | resources, | > probe_mode, | description > '1', | '1', | 'sip:192.168.0.2:5080', | 'pstn=10', | > '2', | 'FS1' > '2', | '1', | 'sip:192.168.0.3:5080', | 'vm=1', | > '2', | 'FS2' > > > The call flow is: > > SIP Provider --> 217.0.0.1 Opensips --> 192.168.0.2/3 > > The issue is, that when the 200 ok response is sent to the SIP provider, > the Freeswitch server's internal IP is being sent in the SDP connection > information (c). This causes the ACK response from the SIP Provider to > fail to be sent correctly. > > With the calls routed directly to the FS servers (removing opensips from > the flow), the calls work fine. > > Any help would be much appreciated :) > > > thanks > Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Wed Oct 29 14:32:56 2014 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Wed, 29 Oct 2014 15:32:56 +0200 Subject: [OpenSIPS-Users] OpenSIPS Public Meeting - WebRTC In-Reply-To: <54494D90.1030000@opensips.org> References: <544940A7.1000808@opensips.org> <54494D90.1030000@opensips.org> Message-ID: <5450EC88.8090601@opensips.org> Hi, all! Don't forget about the WebRTC meeting that's going to happen in about one hour! Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 10/23/2014 09:48 PM, Bogdan-Andrei Iancu wrote: > As a starting point for the discussion, please take a look at: > http://www.opensips.org/Documentation/Tutorials-WebSocket > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 23.10.2014 20:53, R?zvan Crainea wrote: >> Hello, all! >> >> The next public meeting will take place on IRC Wednesday, 29th of >> October 2014, at 17:00 EET[1]. The topic of the meeting is to discuss >> whether we should integrate WebRTC in OpenSIPS or not. >> Make sure you don't miss it, your opinion is important to us! >> >> [1] >> http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenSIPS+Public+Meeting+-+WebRTC&iso=20141029T17&p1=49&ah=1 >> [2] http://www.opensips.org/Community/IRCmeeting20141029 >> >> Best regards, > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From osas at voipembedded.com Wed Oct 29 16:21:35 2014 From: osas at voipembedded.com (Ovidiu Sas) Date: Wed, 29 Oct 2014 11:21:35 -0400 Subject: [OpenSIPS-Users] lookup() questions In-Reply-To: <544F8D12.8060104@opensips.org> References: <544A1C8D.7030705@oceanet.com> <544A975B.2010804@opensips.org> <544E207D.5010208@oceanet.com> <544F8D12.8060104@opensips.org> Message-ID: Even simpler, use $oU (original username): http://www.opensips.org/Documentation/Script-CoreVar-1-11#toc57 if (lookup("location", "", "sip:2015 at IP") { $rU = $oU; } -ovidiu On Tue, Oct 28, 2014 at 8:33 AM, R?zvan Crainea wrote: > Hi, Cedric! > > So your problem is that the username in the R-URI is changed after the > lookup() function? If that, you can restore it by using something like this: > > $var(username) = $rU; > if (lookup("location", "", "sip:2015 at IP") { > $rU = $var(username); > } > > Best regards, > > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > > On 10/27/2014 12:37 PM, OCEANET - C?dric BASSAGET wrote: >> >> Hello R?zvan, >> >> Thanks for your reply. >> Yes, I'm sure i'm tracking udp trafic, I can see SIP options for example. >> I've found my error, and it's a big one : I was doing "exit" in my >> switch() statement, instead of "break". So t_relay was never called... No >> comment... >> >> So the lookup function seems to work correctly, but it does not do what I >> expect. >> >> What I want is just to send SIP requests to UAC behind NAT on the good udp >> port (ex : 1025, corresponding to the "received" field in usrloc). Actually >> (when not using lookup() ), requests are sent to port 5060, whatever the >> value of "received" field is. But I don't want to change user and domain >> part of RURI, just adjust the port. >> >> With lookup() function : >> incoming INVITE RURI : sip:0970559986@:5060 >> INVITE RURI after lookup (to my UAC) : sip:2015@ >> >> invite is relayed to udp port 1025, which is a good thing. But username >> has been changed, and I don't want that. >> >> Without lookup() function, invite is relayed to port 5060, so my >> router/nat doesn't route it correctly -> nothing works. >> >> Don't hesitate to ask if this is not clear. I don't know where to look >> for, usrloc seems to be good, but is not used well... >> >> Should I do a mysql query to extract the port of the "received" in usrloc, >> and then play qith $dp and $rp ? I think there is something simpler than >> that, but I can't find it. >> >> I hope somebody can help me ...! >> Regards, >> C?dric >> >> >> >> >> >> >> OCEANET >> --------------------------------------------------------------- >> [AGENCE DU MANS] >> 7, rue des Fr?nes >> ZAC de la Pointe >> 72190 SARGE LES LE MANS >> [t] +33 (0)2.43.50.26.50 >> [f] +33 (0)2.43.72.21.14 >> >> [AGENCE D'ANGERS] >> 5, rue Fleming >> Angers Technopole >> 49066 ANGERS >> [t] +33 (0)2.41.19.28.65 >> [f] +33 (0)2.52.19.22.00 >> >> http://www.oceanet.com >> http://www.oceanet-telecom.com >> >> On 24/10/2014 20:15, R?zvan Crainea wrote: >>> >>> Hi, Cedric! >>> >>> The third version is the correct version you should use, if the R-URI is >>> different than the AOR you are looking for. >>> Are you sure that your tcpdump trace is tracking the UDP traffic? Are you >>> sure there are no errors generated by t_relay()? Do you see t_relay DBG >>> lines in the logs? >>> >>> Best regards, >>> >>> R?zvan Crainea >>> OpenSIPS Core Developer >>> http://www.opensips-solutions.com >>> >>> On 10/24/2014 02:31 AM, OCEANET - C?dric BASSAGET wrote: >>>> >>>> Hello, >>>> >>>> I'm actually trying to resolve NAT issues with opensips, and I have a >>>> problem using lookup() function. >>>> >>>> UAC register to my opensips server. When UAC is behind nat (detected >>>> with nat_uac_test()), I do a "fix_nated_register()" and >>>> save("location"). >>>> My usrloc table looks correct, I have a line with (important fields): >>>> - a username = 2015 (sip trunk identifier) >>>> - a domain = the domain my UAC is registering to (= the domain my >>>> opensips is listening on) >>>> - a contact = sip:2015@ >>>> - a received = sip:: (in my tests, port=1024) >>>> - and many other fields (...) >>>> >>>> When trying to relay an incoming INVITE to this UAC, if I understood >>>> well, I have to do a "lookup()" before t_relay, to tell opensips to send >>>> the request to the "usrloc.received" . >>>> >>>> I've tried couple things, like : >>>> - lookup("location") -> $ru is totally different from what we are >>>> looking for, so it does not work, that's normal >>>> - lookup("location","","2015@") -> got an error : >>>> ERROR:core:parse_uri: bad uri, state 0 parsed: <2015> (4) / >>>> <2015 at domain> (37) >>>> - lookup("location","","sip:2015@") -> $retcode=1, and debug >>>> shows me this : >>>> >>>> DBG:registrar:lookup: found a complete match >>>> DBG:registrar:lookup: setting as ruri > >>>> but nothing goes out to ip address of my UAC... (tcpdump). >>>> >>>> Can somebody tell me if I've correctly understood how lookup() function >>>> works ? Or if I'm doing totally aberrant things ? >>>> >>>> Regards, >>>> C?dric >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- VoIP Embedded, Inc. http://www.voipembedded.com From gn62 at gmx.us Wed Oct 29 22:26:45 2014 From: gn62 at gmx.us (Gary Nyquist) Date: Wed, 29 Oct 2014 22:26:45 +0100 Subject: [OpenSIPS-Users] Call external program from reply_rote In-Reply-To: <544FD7EC.30703@opensips.org> References: <544F7290.1000805@opensips.org>, <544FD7EC.30703@opensips.org> Message-ID: Thanks a ton R?zvan. It did the trick. Best Regards, - Gary > Sent: Tuesday, October 28, 2014 at 1:52 PM > From: "R?zvan Crainea" > To: users at lists.opensips.org > Subject: Re: [OpenSIPS-Users] Call external program from reply_rote > > Hi, Gary! > > I have pushed a patch for 1.11 downto 1.8 for this issue. > However, if you can't update your sources now, setting the setvars[1] > parameter to 0 should make this work. > > [1] http://www.opensips.org/html/docs/modules/1.11.x/exec.html#id248413 > > Best regards, > > R?zvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 10/28/2014 12:40 PM, Bogdan-Andrei Iancu wrote: > > Hi Gary, > > > > It seems the exec() functions to expect to receive and parse a SIP > > requests after all. I can try to prepare a patch to have them working > > for replies too. > > > > Regards, > > > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > > http://www.opensips-solutions.com > > > > On 23.10.2014 02:06, Gary Nyquist wrote: > >> Hi Bogdan, > >> > >> As I said, it works; but the following errors/warnings fill up the logs: > >> > >> ERROR:core:parse_uri: uri too short: <200> (3) > >> WARNING:exec:append_fixed_vars: uri not parsed > >> ERROR:core:parse_uri: uri too short: <200> (3) > >> WARNING:exec:append_fixed_vars: orig URI not parsed > >> > >> Each "200 OK" reply logging above 4 lines. > >> Any clues how to get rid of these logs? > >> > >> Best Regards, > >> - Gary > >> > >> > >> > >> > >> > >> > >> Thanks Bogdan for the tips. > >> > >> It works! > >> > >> Best Regards, > >> - Gary > >> > >> > >>> Sent: Tuesday, October 21, 2014 at 2:46 PM > >>> From: "Bogdan-Andrei Iancu" > >>> To: "OpenSIPS users mailling list" , > >>> gn62 at gmx.us > >>> Subject: Re: [OpenSIPS-Users] Call external program from reply_rote > >>> > >>> Hi Gary, > >>> > >>> You can do an ugly trick like: > >>> > >>> route[EXEC] { > >>> exec(....); > >>> } > >>> > >>> onreply_route[...] { > >>> .... > >>> route(EXEC); > >>> .... > >>> } > >>> > >>> > >>> Regards, > >>> > >>> Bogdan-Andrei Iancu > >>> OpenSIPS Founder and Developer > >>> http://www.opensips-solutions.com > >>> > >>> On 21.10.2014 00:56, Gary Nyquist wrote: > >>>> Hi, > >>>> > >>>> I need to call an external program from the REPLY_ROUTE (on getting > >>>> 200 OK). > >>>> As per the doc, "exec_msg" and "exec_avp" can be used from > >>>> REQUEST_ROUTE & FAILURE_ROUTE only. > >>>> Is there any alternative methods to run external programs from the > >>>> REPLY_ROUTE? > >>>> > >>>> Best Regards, > >>>> - Gary > >>>> > >>>> _______________________________________________ > >>>> Users mailing list > >>>> Users at lists.opensips.org > >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >>>> > >>> > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From linuxvenkey at gmail.com Thu Oct 30 07:03:17 2014 From: linuxvenkey at gmail.com (Venkatesh Macha) Date: Wed, 29 Oct 2014 23:03:17 -0700 (PDT) Subject: [OpenSIPS-Users] Problem with CDRTool and ubuntu 14.04 and apache 2.4.7 Message-ID: <1414648997713-7594275.post@n2.nabble.com> Hi, I am trying to install *CDRTool on Ubuntu 14.0*4, i have *apache 2.4.7* is installed on it. I installed CDRTool from Debian package from ag-projects repository. Created New database everything is OK,. But when i move to next section that is* PHP and Apache setu*p i am facing these problem. *I am unable to setup a Virtual host for cdrtool, 403 Forbidden*. i got this error in apache error log : * Cannot serve directory /var/www/CDRTool/: No matching DirectoryIndex (index.html,index.cgi,index.pl,index.php,index.xhtml,index.htm) found, and server-generated directory index forbidden by Options directive, referer: http://*.*.*.*:8080/* Then i realized apache is unable to identify the .pthml files(as our CDRTool have .phtml file). then i added* .phtml to DIrectoryIndex* of apache. Now 403 forbidden error is gone. But it is showing a text file Instead of CDRTool Login Page here is the partial part of that page. *"CDRTool_Session", "auth" => "CDRTool_Auth", "perm" => "CDRTool_Perm") ); $loginname=$auth->auth["uname"]; $title="Legal notice"; $db = new DB_CDRTool(); $query=sprintf("select * from settings where billing_party = '%s' and var_module= 'login' and var_name = 'I_agree_with_license'",addslashes($loginname)); if ($db->query($query)) { if ($db->num_rows()) { $refreshURL='callsearch.phtml'; $refreshTime=0; } } if (is_readable("/etc/cdrtool/local/header.phtml")) { include_once("/etc/cdrtool/local/header.phtml"); } else { include_once("header.phtml"); } $layout = new pageLayoutLocal(); $layout->showHeader(); $layout->showLegalNotice(); $layout->showFooter(); page_close(); } else { $Setup = new SETUP (); $Setup->showIntro(); } class SETUP { function showIntro() { print " * I thinks apache2 is unable to render PHP files. if not, what is the problem, why i am getting text page instead of Log-in page. I also made few changes like added .conf at the end of virtual host file name. *cdrtool.com to cdrtool.com.conf* also added *Require all granted* in directory section of virtual host file. Can anyone help me. Thank you in Advance. Venkatesh macha, Junior VOIP Engineer, @C Programming -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Problem-with-CDRTool-and-ubuntu-14-04-and-apache-2-4-7-tp7594275.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From zhouxiaoqiang.mstech at gmail.com Thu Oct 30 07:55:14 2014 From: zhouxiaoqiang.mstech at gmail.com (zhouxiaoqiang.mstech at gmail.com) Date: Thu, 30 Oct 2014 14:55:14 +0800 Subject: [OpenSIPS-Users] Content-Type Paramter issue Message-ID: <2014103014551218732912@gmail.com> Hi? have a strange issue? I sent message use t_uac_dlg by mi Interface. In this message, when set Content-type header like as: Content-Type: Multipart/related;boundary=--- but the table of silo in opensips DB, the column of ctype that value is Multipart/related, not Multipart/related;boundary=---. Content-Type header parameter lost? the flowing command that I use: opensipsctl fifo t_uac_dlg MESSAGE "sip:+962790000000 at 192.168.61.166" . . "\"From: sip:+962796638484 at 192.168.61.166\r\nTo: sip:+962790000000 at 192.168.61.166\r\nContent-Type: Multipart/related;boundary=---\r\n"\" "123456\r\n---\r\n123123\r\n" zhouxiaoqiang.mstech at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaandandin at yahoo.com Mon Oct 20 21:09:01 2014 From: kaandandin at yahoo.com (Kaan Dandin) Date: Mon, 20 Oct 2014 12:09:01 -0700 Subject: [OpenSIPS-Users] YNT: Re: YNT: Re: YNT: Re: YNT: Re: RFC3261 transaction matching failed error for the second 401 Unauthorized - Challenging the UE In-Reply-To: <87qjrvwjysax95g79onktby0.1413789931582@email.android.com> References: <87qjrvwjysax95g79onktby0.1413789931582@email.android.com> Message-ID: <1413832141.7284.YahooMailNeo@web121505.mail.ne1.yahoo.com> Hi Bogdan, With the below workaround, I have managed to make load balancing with Opensips dispather module . I am using record_route for INVITE message. Thanks a lot for your support. Kind regards, Kaan Related part of Opensips script ....... else if (is_method("INVITE")) { #load_balance("1","pstn"); xlog("xlog_initialinvite"); if($si=="192.168.2.11") { ds_select_dst("1","1"); } record_route(); if(!t_relay()) { sl_reply_error(); xlog("xlog_invitereplyerror"); } exit; ....... if (loose_route()) { xlog("xlog_loose_route"); if($si=="192.168.2.11") { t_relay(); exit; } else if($si=="192.168.2.3" or $si=="192.168.2.5" ) { $du = "sip:192.168.2.11:4060"; append_branch(); t_relay(); exit; } ..... ims_bench output 1- ims_uac-0- Scenario Screen - [1-9]: Change Screen - 6663 Call-rate(length) Port Total-time Total-calls Remote-host 0.0(0 ms)/1.000s 5060 65.32 s 65 192.168.2.141:4060(UDP) 0 new calls during 0.287 s period 1 ms scheduler resolution 0 calls (limit 0) Peak was 32 calls, after 45 s 0 Running, 1 Paused, 1 Woken up, 0 Sync 0 out-of-call msg (discarded) 0 open sockets Messages Retrans Timeout Unexpected-Msg 0 [ NOP ] 1 [ SENDRMT ] 11 2 [ RECVRMT ] 11 0 3 [ SYNC ] 11 4 INVITE ----------> B1,2,4 11 0 0 5 100 <---------- 11 0 0 6 180 <---------- 11 0 0 7 183 <---------- 0 0 0 8 200 <---------- 11 0 0 9 ACK ----------> 11 0 10 180 <---------- 0 0 0 11 Pause [Exp(2:00)] 11 0 12 BYE ----------> B3 11 0 0 13 180 <---------- 0 0 0 14 200 <---------- E3,4 11 0 0 15 [ RECVRMT ] 11 0 ------------------------------ Test Terminated -------------------------------- 1- ims_uac-0- Statistics Screen - [1-9]: Change Screen - 6663 Start Time | 2014-10-20 11:17:42 Last Reset Time | 2014-10-20 11:18:34 Current Time | 2014-10-20 11:18:34 -------------------------+---------------------------+-------------------------- Counter Name | Periodic value | Cumulative value -------------------------+---------------------------+-------------------------- Elapsed Time | 00:00:00:290 | 00:00:51:987 Call Rate | 0.000 cps | 0.212 cps -------------------------+---------------------------+-------------------------- Incoming call created | 0 | 0 OutGoing call created | 0 | 11 Total Call created | | 11 Current Call | 0 | -------------------------+---------------------------+-------------------------- Successful call | 3 | 11 Failed call | 0 | 0 -------------------------+---------------------------+-------------------------- Response Time 1 | 00:00:00:000 | 00:00:00:000 Response Time 2 | 00:00:44:121 | 00:00:55:011 Response Time 3 | 00:00:00:000 | 00:01:07:341 Response Time 4 | 00:00:00:000 | 04:08:44:054 Response Time 5 | 01:14:06:022 | 01:09:59:415 Response Time 7 | 00:01:01:869 | 00:01:10:633 Response Time 8 | 00:00:00:000 | 00:01:35:927 Response Time 9 | 00:00:00:000 | 04:31:24:539 Response Time 10 | 01:16:07:446 | 01:15:34:687 Response Time 12 | 00:00:00:000 | 00:00:00:000 Response Time 13 | 00:00:00:000 | 00:00:00:000 Response Time 14 | 00:00:00:000 | 00:00:00:000 Response Time 15 | 00:00:00:000 | 00:00:00:000 Call Length | 06:30:22:487 | 05:04:58:398 ------------------------------ Test Terminated -------------------------------- over 192.168.2.3 =================== No. Time Source Destination Protocol Info 1604 18.894833 192.168.2.11 192.168.2.141 SIP/SDP Request: INVITE sip:subs004467 at open-ims.test, with session description 1605 18.895716 192.168.2.141 192.168.2.11 SIP Status: 100 Giving a try 1606 18.896051 192.168.2.141 192.168.2.3 SIP/SDP Request: INVITE sip:subs004467 at open-ims.test, with session description 1607 18.918473 192.168.2.3 192.168.2.141 SIP Status: 100 trying -- your call is important to us 1608 18.929113 192.168.2.3 192.168.2.141 SIP/SDP Request: INVITE sip:subs004467 at 192.168.2.11:11468, with session description 1609 18.930230 192.168.2.141 192.168.2.3 SIP Status: 100 Giving a try 1611 18.930915 192.168.2.141 192.168.2.11 SIP/SDP Request: INVITE sip:subs004467 at 192.168.2.11:11468, with session description 1612 18.932105 192.168.2.11 192.168.2.141 SIP Status: 180 Ringing 1613 18.933501 192.168.2.141 192.168.2.3 SIP Status: 180 Ringing 1614 18.949184 192.168.2.3 192.168.2.141 SIP Status: 180 Ringing 1615 18.950056 192.168.2.141 192.168.2.11 SIP Status: 180 Ringing 1658 23.994779 192.168.2.11 192.168.2.141 SIP/SDP Status: 200 OK, with session description 1659 23.995366 192.168.2.141 192.168.2.3 SIP/SDP Status: 200 OK, with session description 1660 24.006893 192.168.2.3 192.168.2.141 SIP/SDP Status: 200 OK, with session description 1661 24.007967 192.168.2.141 192.168.2.11 SIP/SDP Status: 200 OK, with session description 1662 24.008743 192.168.2.11 192.168.2.141 SIP Request: ACK sip:subs004467 at 192.168.2.11:11468;transport=UDP 1663 24.010836 192.168.2.141 192.168.2.3 SIP Request: ACK sip:subs004467 at 192.168.2.11:11468;transport=UDP 1664 24.025223 192.168.2.3 192.168.2.141 SIP Request: ACK sip:subs004467 at 192.168.2.11:11468;transport=UDP 1665 24.027505 192.168.2.141 192.168.2.11 SIP Request: ACK sip:subs004467 at 192.168.2.11:11468;transport=UDP 2300 27.281032 192.168.2.11 192.168.2.141 SIP Request: BYE sip:subs004467 at 192.168.2.11:11468;transport=UDP 2301 27.283582 192.168.2.141 192.168.2.3 SIP Request: BYE sip:subs004467 at 192.168.2.11:11468;transport=UDP 2302 27.294955 192.168.2.3 192.168.2.141 SIP Request: BYE sip:subs004467 at 192.168.2.11:11468;transport=UDP 2303 27.297687 192.168.2.141 192.168.2.11 SIP Request: BYE sip:subs004467 at 192.168.2.11:11468;transport=UDP 2304 27.297689 192.168.2.141 192.168.2.11 SIP Request: BYE sip:subs004467 at 192.168.2.11:11468;transport=UDP 2305 27.297691 192.168.2.11 192.168.2.141 SIP Status: 200 OK 2307 27.299660 192.168.2.141 192.168.2.3 SIP Status: 200 OK 2308 27.307834 192.168.2.3 192.168.2.141 SIP Status: 200 OK 2309 27.308408 192.168.2.141 192.168.2.11 SIP Status: 200 OK over 192.168.2.5 =================== No. Time Source Destination Protocol Info 2040 25.595623 192.168.2.11 192.168.2.141 SIP/SDP Request: INVITE sip:subs004783 at open-ims.test, with session description 2041 25.596532 192.168.2.141 192.168.2.11 SIP Status: 100 Giving a try 2042 25.596952 192.168.2.141 192.168.2.5 SIP/SDP Request: INVITE sip:subs004783 at open-ims.test, with session description 2043 25.628108 192.168.2.5 192.168.2.141 SIP Status: 100 trying -- your call is important to us 2045 25.667842 192.168.2.5 192.168.2.141 SIP/SDP Request: INVITE sip:subs004783 at 192.168.2.11:11784, with session description 2046 25.668279 192.168.2.141 192.168.2.5 SIP Status: 100 Giving a try 2048 25.668533 192.168.2.141 192.168.2.11 SIP/SDP Request: INVITE sip:subs004783 at 192.168.2.11:11784, with session description 2049 25.668980 192.168.2.11 192.168.2.141 SIP Status: 180 Ringing 2050 25.669123 192.168.2.141 192.168.2.5 SIP Status: 180 Ringing 2051 25.698433 192.168.2.5 192.168.2.141 SIP Status: 180 Ringing 2052 25.698618 192.168.2.141 192.168.2.11 SIP Status: 180 Ringing 2407 30.767801 192.168.2.11 192.168.2.141 SIP/SDP Status: 200 OK, with session description 2408 30.768519 192.168.2.141 192.168.2.5 SIP/SDP Status: 200 OK, with session description 2409 30.831684 192.168.2.5 192.168.2.141 SIP/SDP Status: 200 OK, with session description 2410 30.831977 192.168.2.141 192.168.2.11 SIP/SDP Status: 200 OK, with session description 2411 30.832405 192.168.2.11 192.168.2.141 SIP Request: ACK sip:subs004783 at 192.168.2.11:11784;transport=UDP 2412 30.833398 192.168.2.141 192.168.2.5 SIP Request: ACK sip:subs004783 at 192.168.2.11:11784;transport=UDP 2413 30.855147 192.168.2.5 192.168.2.141 SIP Request: ACK sip:subs004783 at 192.168.2.11:11784;transport=UDP 2414 30.855872 192.168.2.141 192.168.2.11 SIP Request: ACK sip:subs004783 at 192.168.2.11:11784;transport=UDP 3425 40.770843 192.168.2.11 192.168.2.141 SIP/SDP Status: 200 OK, with session description 3439 43.412789 192.168.2.11 192.168.2.141 SIP Request: BYE sip:subs004783 at 192.168.2.11:11784;transport=UDP 3440 43.414207 192.168.2.141 192.168.2.5 SIP Request: BYE sip:subs004783 at 192.168.2.11:11784;transport=UDP 3441 43.467117 192.168.2.5 192.168.2.141 SIP Request: BYE sip:subs004783 at 192.168.2.11:11784;transport=UDP 3442 43.467826 192.168.2.141 192.168.2.11 SIP Request: BYE sip:subs004783 at 192.168.2.11:11784;transport=UDP 3443 43.467983 192.168.2.141 192.168.2.11 SIP Request: BYE sip:subs004783 at 192.168.2.11:11784;transport=UDP 3444 43.468176 192.168.2.11 192.168.2.141 SIP Status: 200 OK 3446 43.468627 192.168.2.141 192.168.2.5 SIP Status: 200 OK 3447 43.490269 192.168.2.5 192.168.2.141 SIP Status: 200 OK 3448 43.490468 192.168.2.141 192.168.2.11 SIP Status: 200 OK -------------- next part -------------- An HTML attachment was scrubbed... URL: From KWatson at geniusppt.com Thu Oct 23 22:40:09 2014 From: KWatson at geniusppt.com (Kenny Watson) Date: Thu, 23 Oct 2014 20:40:09 +0000 Subject: [OpenSIPS-Users] Load balancer setup In-Reply-To: References: Message-ID: Hi Matt, The SDP is being generated by freeswitch and you would need to make it think that when its sending to kamailio, that kamailio is an external host so freeswitch uses its public IP address in the SDP that it is then forwarded on directly to the carrier. I've never used freeswitch but thats roughly what you'd do with asterisk. Thanks Kenny Watson ________________________________ From: users-bounces at lists.opensips.org [users-bounces at lists.opensips.org] on behalf of matt [matt at supportedbusiness.com] Sent: 22 October 2014 08:42 To: users at lists.opensips.org Subject: [OpenSIPS-Users] Load balancer setup Hi, I was looking for some guidance on using the load balancer in a NAT environment. I have the following setup (the IP addresses are made up but should give an indication): 1 x opensips server with load balancer module - IP 192.168.0.1 2 x freeswitch servers - IP 192.168.0.2 & 192.168.0.3 All 3 servers have seperate external IP address routing to their internal IP via our firewall: 217.0.0.1 routed to 192.168.0.1 (Opensips) 217.0.0.2 routed to 192.168.0.2 (FS1) 217.0.0.3 routed to 192.168.0.3 (FS2) I have the load_balancer table with the following details: id, | group_id, | dst_uri, | resources, | probe_mode, | description '1', | '1', | 'sip:192.168.0.2:5080', | 'pstn=10', | '2', | 'FS1' '2', | '1', | 'sip:192.168.0.3:5080', | 'vm=1', | '2', | 'FS2' The call flow is: SIP Provider --> 217.0.0.1 Opensips --> 192.168.0.2/3 The issue is, that when the 200 ok response is sent to the SIP provider, the Freeswitch server's internal IP is being sent in the SDP connection information (c). This causes the ACK response from the SIP Provider to fail to be sent correctly. With the calls routed directly to the FS servers (removing opensips from the flow), the calls work fine. Any help would be much appreciated :) thanks Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From linuxvenkey at gmail.com Thu Oct 30 11:45:30 2014 From: linuxvenkey at gmail.com (Venkatesh Macha) Date: Thu, 30 Oct 2014 03:45:30 -0700 (PDT) Subject: [OpenSIPS-Users] Problem with CDRTool and ubuntu 14.04 and apache 2.4.7 and PHP 5.5 In-Reply-To: <1414648997713-7594275.post@n2.nabble.com> References: <1414648997713-7594275.post@n2.nabble.com> Message-ID: <1414665930055-7594280.post@n2.nabble.com> I think problem with *PHP*. I am using php 5.5, Is CDRTool is compatible with PHP 5.5 ?? I saw one post on this topic it was few months back one you can see here -> http://lists.opensips.org/pipermail/users/2013-February/024453.html If i use php 5.3 it is working fine on ubuntu 12.04 but it is not working with ubuntu* 14.04 and php 5.5.* is CDRTool is Compatible with PHP 5.5 ??? Venkatesh macha, Junior VOIP Engineer, @ C programming -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Problem-with-CDRTool-and-ubuntu-14-04-and-apache-2-4-7-tp7594275p7594280.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From snabel at lexifone.com Thu Oct 30 12:10:00 2014 From: snabel at lexifone.com (Snabel Kabiya) Date: Thu, 30 Oct 2014 13:10:00 +0200 Subject: [OpenSIPS-Users] opensips installation error Message-ID: Hi, I'm trying to install opensips following the instructions here: http://www.opensips.org/Documentation/Tutorials-OpenSIPSFreeSwitchIntegration#toc4 i got to this step: 2.3 Compile and install OpenSIPS - make menuconfig i got the following error: In file included from evi/../locking.h:68:0, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:42, from dset.c:34: evi/../lock_alloc.h:60:2: error: #error "locking requires shared memory support" #error "locking requires shared memory support" Details: VM on Hyper-V OS: 3.16.0-24-generic #32-Ubuntu SMP Tue Oct 28 13:07:32 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux RAM 2GB Thanks, Snabel -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Thu Oct 30 12:26:48 2014 From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=) Date: Thu, 30 Oct 2014 13:26:48 +0200 Subject: [OpenSIPS-Users] BLF and PRESENCE In-Reply-To: <5450C62F.9010208@unisi.it> References: <5450C62F.9010208@unisi.it> Message-ID: <54522078.5010200@opensips.org> Hi, Michele! Check the tutorial and description of the pua_dialoginfo module[1]. You can find some config examples over there. [1] http://www.opensips.org/Documentation/Tutorials-PUAExtensions#pua_dialoginfo Best regards, R?zvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 10/29/2014 12:49 PM, Michele Pinassi wrote: > Hi all, > > on our opensips system i'm trying to implement PRESENCE-BLF > funcionality, where the boss phone (Snom 760) "subscribe" the workers > line and see when they are busy/free. > > As i see, here's my opensips.cfg relevant parts: > > [...] > #### PRESENCE modules > loadmodule "presence.so" > loadmodule "presence_xml.so" > loadmodule "presence_mwi.so" > loadmodule "presence_callinfo.so" > loadmodule "xcap.so" > > modparam("presence", "server_address", "sip:sa at 172.20.1.2:5060") > modparam("presence_xml", "force_active", 1) > > modparam("xcap","db_url","mysql://voip:4LaGjZCK8C6pp3RK at mysql.unisi.it/opensips") > modparam("xcap", "integrated_xcap_server", 1) > > [...] > > and simply add a route for presence: > > [...] > if( is_method("PUBLISH|SUBSCRIBE")) > route(handle_presence); > > [...] > # Presence route > > route[handle_presence] { > xlog("L_INFO","Route PRESENCE [$fd/$fu/$rd/$ru/$si/]\n"); > if(!t_newtran()){ > sl_reply_error(); > exit; > } > > if (is_method("PUBLISH")) { > handle_publish(); > } > > if (is_method("SUBSCRIBE")) { > handle_subscribe(); > } > exit; > } > [...] > > on the boss phone (5002) i set up BLF for 5009 but BLF simply don't work. > > On Opensips logs i have: > > Oct 29 11:47:05 proxy-voip01 /usr/sbin/opensips[5494]: Route PRESENCE > [voip.unisi.it/sip:5002 at voip.unisi.it:5060/voip.unisi.it/sip:5008 at voip.unisi.it:5060;user=phone/172.20.1.10/] > Oct 29 11:47:05 proxy-voip01 /usr/sbin/opensips[5494]: > INFO:presence:handle_subscribe: Missing or unsupported event header > field value > Oct 29 11:47:05 proxy-voip01 /usr/sbin/opensips[5494]: > INFO:presence:handle_subscribe: #011event= dialog > [...] > Oct 29 11:47:32 proxy-voip01 /usr/sbin/opensips[5496]: Route PRESENCE > [voip.unisi.it/sip:5022 at voip.unisi.it:5060/voip.unisi.it/sip:*98 at voip.unisi.it:5060;user=phone/172.20.2.12/] > Oct 29 11:47:32 proxy-voip01 /usr/sbin/opensips[5496]: > INFO:presence:update_subscription: notify > Oct 29 11:47:32 proxy-voip01 /usr/sbin/opensips[5496]: > INFO:presence:send_notify_request: NOTIFY sip:5022 at voip.unisi.it via > sip:5022 at 172.20.2.12:32768 on behalf of sip:*98 at voip.unisi.it for event > message-summary, to_tag=f315b2d58ae8829149b784764c5a40e3-c2fb, cseq=1 > > > Moreover, i've tried to see how watchers/presentity works but i'm not > able to find any tutorial....hints ? Suggestions ? > > Thanks, Michele > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Thu Oct 30 12:28:20 2014 From: liviu at opensips.org (Liviu Chircu) Date: Thu, 30 Oct 2014 13:28:20 +0200 Subject: [OpenSIPS-Users] opensips installation error In-Reply-To: References: Message-ID: <545220D4.9050506@opensips.org> Hi Snabel, What is your OpenSIPS version? 1.8 like in the tutorial? Could you also please paste the output of 'cat Makefile.conf | tail -n35' ? Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 10/30/2014 01:10 PM, Snabel Kabiya wrote: > Hi, > > I'm trying to install opensips following the instructions here: > > http://www.opensips.org/Documentation/Tutorials-OpenSIPSFreeSwitchIntegration#toc4 > > i got to this step: > > > 2.3 Compile and install OpenSIPS > > - make menuconfig > > i got the following error: > > In file included from evi/../locking.h:68:0, > from evi/event_interface.h:31, > from evi/evi_modules.h:30, > from ut.h:42, > from dset.c:34: > evi/../lock_alloc.h:60:2: error: #error "locking requires shared memory support" > #error "locking requires shared memory support" > > > Details: > VM on Hyper-V > OS: 3.16.0-24-generic #32-Ubuntu SMP Tue Oct 28 13:07:32 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > RAM 2GB > > Thanks, > Snabel > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From sunil.sipuser at gmail.com Fri Oct 31 07:49:45 2014 From: sunil.sipuser at gmail.com (Sunil P) Date: Fri, 31 Oct 2014 12:19:45 +0530 Subject: [OpenSIPS-Users] Mangle SDP Connection IP Message-ID: > > Hi All, using sdp_mangle_ip we can change the sdp connection ip.In mangaler.cfg there is check if (method == "INVITE"){sdp_mangle_ip } call this function.Now how to call sdp_mangle_ip for 200 ok of INVITE. Thanks and Regards, Sunil -------------- next part -------------- An HTML attachment was scrubbed... URL: From sunil.sipuser at gmail.com Fri Oct 31 08:21:42 2014 From: sunil.sipuser at gmail.com (Sunil P) Date: Fri, 31 Oct 2014 12:51:42 +0530 Subject: [OpenSIPS-Users] Mangle SDP Connection IP In-Reply-To: References: Message-ID: Hi All, This is the sample mangler.cfg https://github.com/lemenkov/sip-router/blob/master/modules_s/mangler/mangler.cfg.Now I need to use it for 200 ok of INVITE.Please help if anybody knows. Thanks and Regards, Sunil On Fri, Oct 31, 2014 at 12:19 PM, Sunil P wrote: > Hi All, > > > using sdp_mangle_ip we can change the sdp connection ip.In > mangaler.cfg there is check if (method == "INVITE"){sdp_mangle_ip } call > this function.Now how to call sdp_mangle_ip for 200 ok of > INVITE. > > Thanks and Regards, > Sunil > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tijmen at ag-projects.com Fri Oct 31 11:14:40 2014 From: tijmen at ag-projects.com (Tijmen de Mes) Date: Fri, 31 Oct 2014 11:14:40 +0100 Subject: [OpenSIPS-Users] Problem with CDRTool and ubuntu 14.04 and apache 2.4.7 and PHP 5.5 In-Reply-To: <1414665930055-7594280.post@n2.nabble.com> References: <1414648997713-7594275.post@n2.nabble.com> <1414665930055-7594280.post@n2.nabble.com> Message-ID: Hi, We did not test it on 5.5 yet. The latest deb is compatible with 5.3. The code in darcs should work with 5.4.? --? Tijmen de Mes AG-Projects From:?Venkatesh Macha Reply:?OpenSIPS users mailling list > Date:?30 oktober 2014 at 11:45:44 To:?users at lists.opensips.org > Subject:? Re: [OpenSIPS-Users] Problem with CDRTool and ubuntu 14.04 and apache 2.4.7 and PHP 5.5 I think problem with *PHP*. I am using php 5.5, Is CDRTool is compatible with PHP 5.5 ?? I saw one post on this topic it was few months back one you can see here -> http://lists.opensips.org/pipermail/users/2013-February/024453.html If i use php 5.3 it is working fine on ubuntu 12.04 but it is not working with ubuntu* 14.04 and php 5.5.* is CDRTool is Compatible with PHP 5.5 ??? Venkatesh macha, Junior VOIP Engineer, @ C programming -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Problem-with-CDRTool-and-ubuntu-14-04-and-apache-2-4-7-tp7594275p7594280.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhouxiaoqiang.mstech at gmail.com Fri Oct 31 11:23:50 2014 From: zhouxiaoqiang.mstech at gmail.com (chow) Date: Fri, 31 Oct 2014 03:23:50 -0700 (PDT) Subject: [OpenSIPS-Users] Content-Type Paramter issue In-Reply-To: <2014103014551218732912@gmail.com> References: <2014103014551218732912@gmail.com> Message-ID: <1414751030634-7594295.post@n2.nabble.com> I read code in msilo module . It seems not contain parameter in content-type header when insert to DB, why? what consider for that. thank you any advice.! -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Content-Type-Paramter-issue-tp7594276p7594295.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. From matt at supportedbusiness.com Fri Oct 31 11:33:15 2014 From: matt at supportedbusiness.com (Matt Broad) Date: Fri, 31 Oct 2014 10:33:15 +0000 Subject: [OpenSIPS-Users] Load balancer setup In-Reply-To: References: Message-ID: Hi Kenny, thanks for the reply. For some reason this is only just showing in my email so sorry for the delayed response. Could you explain how you would do this is asterisk please? This may help in me solving the issue :) thanks Matt On 23 October 2014 21:40, Kenny Watson wrote: > Hi Matt, > > The SDP is being generated by freeswitch and you would need to make it > think that when its sending to kamailio, that kamailio is an external host > so freeswitch uses its public IP address in the SDP that it is then > forwarded on directly to the carrier. > > I've never used freeswitch but thats roughly what you'd do with asterisk. > > Thanks > Kenny Watson > > > ------------------------------ > *From:* users-bounces at lists.opensips.org [users-bounces at lists.opensips.org] > on behalf of matt [matt at supportedbusiness.com] > *Sent:* 22 October 2014 08:42 > *To:* users at lists.opensips.org > *Subject:* [OpenSIPS-Users] Load balancer setup > > Hi, > > > I was looking for some guidance on using the load balancer in a NAT > environment. > > I have the following setup (the IP addresses are made up but should give > an indication): > > 1 x opensips server with load balancer module - IP 192.168.0.1 > 2 x freeswitch servers - IP 192.168.0.2 & 192.168.0.3 > > All 3 servers have seperate external IP address routing to their > internal IP via our firewall: > 217.0.0.1 routed to 192.168.0.1 (Opensips) > 217.0.0.2 routed to 192.168.0.2 (FS1) > 217.0.0.3 routed to 192.168.0.3 (FS2) > > I have the load_balancer table with the following details: > > id, | group_id, | dst_uri, | resources, | > probe_mode, | description > '1', | '1', | 'sip:192.168.0.2:5080', | 'pstn=10', | > '2', | 'FS1' > '2', | '1', | 'sip:192.168.0.3:5080', | 'vm=1', | > '2', | 'FS2' > > > The call flow is: > > SIP Provider --> 217.0.0.1 Opensips --> 192.168.0.2/3 > > The issue is, that when the 200 ok response is sent to the SIP provider, > the Freeswitch server's internal IP is being sent in the SDP connection > information (c). This causes the ACK response from the SIP Provider to > fail to be sent correctly. > > With the calls routed directly to the FS servers (removing opensips from > the flow), the calls work fine. > > Any help would be much appreciated :) > > > thanks > Matt > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbcbooksmj at gmail.com Fri Oct 31 12:13:16 2014 From: gbcbooksmj at gmail.com (Michael Leung) Date: Fri, 31 Oct 2014 19:13:16 +0800 Subject: [OpenSIPS-Users] how to make a phone call to between two different domain sip server Message-ID: Hi all i know this is a stupid question but i dont use sip to make a phone call very often , i have setup up two opensips server in my intranet environment i use two phones to register on each server how to make a phone call from one to another one do i have to add the the destination domain name behind the alias number when i dial out ? or why can i dial the alias number without domain name , then the opensips server will routing it to a the opensips server automatically thanks Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: