Re: [OpenSIPS-Users] Cancel branch before failover on timeout
Bogdan, Thanks for the advice. Although it might be a long shot, I hope acc module can handle something like this in the future. I guess I'll just try to adjust/increase the fr_inv_timer_avp value for now to minimize this scenario. Cheers! On Thu, Jul 11, 2013 at 8:24 PM, Bogdan-Andrei Iancu wrote: > ** > Hi Ronald, > > I wouldn't go so far - even if you get 2 records for the transaction based > accounting, the values will be mixed. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > > On 07/10/2013 03:08 PM, Ronald Cepres wrote: > > Bogdan, > > I am currently using CDR based. Does it mean that if I use transaction > based, we will have more accurate resulting CDRs? > > Thanks. > > > On Mon, Jul 8, 2013 at 10:05 PM, Bogdan-Andrei Iancu > wrote: > >> Hi Ronald, >> >> I never experienced such race (with multiple 200 oks on different >> branches)But depending on what kind of accounting you do: >> - transaction based = you will get 2 START records and 2 STOP records, >> but with different TO tags >> - cdr based = you will get the values of the last 200 OK (which will >> overwrite the values of the first one).. >> >> I guess the ACC module was never designed to deal with such scenarios. >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >> >> >> On 07/06/2013 02:25 AM, Ronald Cepres wrote: >> >> Bogdan, >> >> Understood, and thanks for the info. >> >> However, I have some concerns with regards to the resulting CDR using >> the acc and drouting modules. I think if both GWs sent 200 OK at the same >> time, it would result in a CDR with the values of AVPs specified by >> carrier_id_avp and gw_id_avp drouting parameters set only to GW2. Also, if >> GW1 is the last GW in the gwlist and this type of race condition happens, >> the value of the AVPs will be set to blank. >> >> >> On Fri, Jul 5, 2013 at 2:15 AM, Bogdan-Andrei Iancu > > wrote: >> >>> Hello Ronald, >>> >>> If the first GW sent any reply before the timeout, than OpenSIPS will >>> cancel it before hitting the failure route. If no reply at all sent by GW1, >>> OpenSIPS will hit the failure route on timeout without canceling. If after >>> this point (call send to GW2) first GW sends a reply : >>> 1) if a provisional reply (<200), it will be canceled on the spot >>> 2) if a 200 ok reply -> it will be accepted and fwd to calling device >>> a) if the GW2 did not send a 200 OK, it will be canceled >>> b) if GW2 also sent a 200 OK in the same time, both 200 OK will >>> be sent to calling device and it that device will decide what call to keep >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >>> >>> >>> On 07/04/2013 07:41 PM, Ronald Cepres wrote: >>> >>> Bogdan, >>> >>> Thanks for the informative reply. >>> >>> What I really want to solve is a problem I encounter when the first GW >>> doesnt respond after a defined timeout then Opensips does failover to next >>> GW. A few seconds after the call is routed to second GW, the first GW >>> responds with 200 OK, which may cause problems. It seems that the first GW >>> has a slow response time. >>> >>> The solution I am thinking of to prevent this is to send a cancel to the >>> first GW before doing failover to next gateway. Does this make sense or is >>> there a better solution? >>> >>> Thanks. >>> >>> -Ronald >>> On Jul 4, 2013 11:58 PM, "Bogdan-Andrei Iancu" >>> wrote: >>> >>>> Hello Ronald, >>>> >>>> When you hit the failure route, there is no ongoing branch left >>>> (doesn't matter how many you previously created) - so you should not worry >>>> about this. >>>> >>>> By SIP definition, a transaction fails (and OpenSIPS gets into failure >>>> route) only when all branches failed. >>>> >>>> Regards, >>>> >>>> Bogdan-Andrei Iancu >>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >>>> >>>> >>>> On 07/03/2013 10:43 PM, Ronald Cepres wrote: >>>> >>>> Hi all, >>>> >>>> Is there a w
Re: [OpenSIPS-Users] Cancel branch before failover on timeout
Bogdan, I am currently using CDR based. Does it mean that if I use transaction based, we will have more accurate resulting CDRs? Thanks. On Mon, Jul 8, 2013 at 10:05 PM, Bogdan-Andrei Iancu wrote: > ** > Hi Ronald, > > I never experienced such race (with multiple 200 oks on different > branches)But depending on what kind of accounting you do: > - transaction based = you will get 2 START records and 2 STOP records, > but with different TO tags > - cdr based = you will get the values of the last 200 OK (which will > overwrite the values of the first one).. > > I guess the ACC module was never designed to deal with such scenarios. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > > On 07/06/2013 02:25 AM, Ronald Cepres wrote: > > Bogdan, > > Understood, and thanks for the info. > > However, I have some concerns with regards to the resulting CDR using > the acc and drouting modules. I think if both GWs sent 200 OK at the same > time, it would result in a CDR with the values of AVPs specified by > carrier_id_avp and gw_id_avp drouting parameters set only to GW2. Also, if > GW1 is the last GW in the gwlist and this type of race condition happens, > the value of the AVPs will be set to blank. > > > On Fri, Jul 5, 2013 at 2:15 AM, Bogdan-Andrei Iancu > wrote: > >> Hello Ronald, >> >> If the first GW sent any reply before the timeout, than OpenSIPS will >> cancel it before hitting the failure route. If no reply at all sent by GW1, >> OpenSIPS will hit the failure route on timeout without canceling. If after >> this point (call send to GW2) first GW sends a reply : >> 1) if a provisional reply (<200), it will be canceled on the spot >> 2) if a 200 ok reply -> it will be accepted and fwd to calling device >> a) if the GW2 did not send a 200 OK, it will be canceled >> b) if GW2 also sent a 200 OK in the same time, both 200 OK will >> be sent to calling device and it that device will decide what call to keep >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >> >> >> On 07/04/2013 07:41 PM, Ronald Cepres wrote: >> >> Bogdan, >> >> Thanks for the informative reply. >> >> What I really want to solve is a problem I encounter when the first GW >> doesnt respond after a defined timeout then Opensips does failover to next >> GW. A few seconds after the call is routed to second GW, the first GW >> responds with 200 OK, which may cause problems. It seems that the first GW >> has a slow response time. >> >> The solution I am thinking of to prevent this is to send a cancel to the >> first GW before doing failover to next gateway. Does this make sense or is >> there a better solution? >> >> Thanks. >> >> -Ronald >> On Jul 4, 2013 11:58 PM, "Bogdan-Andrei Iancu" >> wrote: >> >>> Hello Ronald, >>> >>> When you hit the failure route, there is no ongoing branch left (doesn't >>> matter how many you previously created) - so you should not worry about >>> this. >>> >>> By SIP definition, a transaction fails (and OpenSIPS gets into failure >>> route) only when all branches failed. >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >>> >>> >>> On 07/03/2013 10:43 PM, Ronald Cepres wrote: >>> >>> Hi all, >>> >>> Is there a way I can cancel a pending branch before doing a fail-over >>> to next gateway (due to timeout from previous gateway)? This way I can make >>> sure that the call to the previous gateway will not go through anymore >>> after fail-over to the next gateway, thus preventing us "double-charged" >>> situations if the previous gateway and the new gateway both answered the >>> call. >>> >>> Thanks in advance. >>> >>> >>> -- >>> >>> Regards, >>> >>> Ronald >>> >>> >>> ___ >>> Users mailing >>> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> > > > -- > > Regards, > > Ronald Cepres > > -- Ronald Cepres Network Operations Center Net Voip Communications, Inc. This message contains confidential information and is
Re: [OpenSIPS-Users] Cancel branch before failover on timeout
Bogdan, Understood, and thanks for the info. However, I have some concerns with regards to the resulting CDR using the acc and drouting modules. I think if both GWs sent 200 OK at the same time, it would result in a CDR with the values of AVPs specified by carrier_id_avp and gw_id_avp drouting parameters set only to GW2. Also, if GW1 is the last GW in the gwlist and this type of race condition happens, the value of the AVPs will be set to blank. On Fri, Jul 5, 2013 at 2:15 AM, Bogdan-Andrei Iancu wrote: > ** > Hello Ronald, > > If the first GW sent any reply before the timeout, than OpenSIPS will > cancel it before hitting the failure route. If no reply at all sent by GW1, > OpenSIPS will hit the failure route on timeout without canceling. If after > this point (call send to GW2) first GW sends a reply : > 1) if a provisional reply (<200), it will be canceled on the spot > 2) if a 200 ok reply -> it will be accepted and fwd to calling device > a) if the GW2 did not send a 200 OK, it will be canceled > b) if GW2 also sent a 200 OK in the same time, both 200 OK will be > sent to calling device and it that device will decide what call to keep > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > > On 07/04/2013 07:41 PM, Ronald Cepres wrote: > > Bogdan, > > Thanks for the informative reply. > > What I really want to solve is a problem I encounter when the first GW > doesnt respond after a defined timeout then Opensips does failover to next > GW. A few seconds after the call is routed to second GW, the first GW > responds with 200 OK, which may cause problems. It seems that the first GW > has a slow response time. > > The solution I am thinking of to prevent this is to send a cancel to the > first GW before doing failover to next gateway. Does this make sense or is > there a better solution? > > Thanks. > > -Ronald > On Jul 4, 2013 11:58 PM, "Bogdan-Andrei Iancu" > wrote: > >> Hello Ronald, >> >> When you hit the failure route, there is no ongoing branch left (doesn't >> matter how many you previously created) - so you should not worry about >> this. >> >> By SIP definition, a transaction fails (and OpenSIPS gets into failure >> route) only when all branches failed. >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >> >> >> On 07/03/2013 10:43 PM, Ronald Cepres wrote: >> >> Hi all, >> >> Is there a way I can cancel a pending branch before doing a fail-over >> to next gateway (due to timeout from previous gateway)? This way I can make >> sure that the call to the previous gateway will not go through anymore >> after fail-over to the next gateway, thus preventing us "double-charged" >> situations if the previous gateway and the new gateway both answered the >> call. >> >> Thanks in advance. >> >> >> -- >> >> Regards, >> >> Ronald >> >> >> ___ >> Users mailing >> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> -- Regards, Ronald Cepres ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Cancel branch before failover on timeout
Bogdan, Thanks for the informative reply. What I really want to solve is a problem I encounter when the first GW doesnt respond after a defined timeout then Opensips does failover to next GW. A few seconds after the call is routed to second GW, the first GW responds with 200 OK, which may cause problems. It seems that the first GW has a slow response time. The solution I am thinking of to prevent this is to send a cancel to the first GW before doing failover to next gateway. Does this make sense or is there a better solution? Thanks. -Ronald On Jul 4, 2013 11:58 PM, "Bogdan-Andrei Iancu" wrote: > ** > Hello Ronald, > > When you hit the failure route, there is no ongoing branch left (doesn't > matter how many you previously created) - so you should not worry about > this. > > By SIP definition, a transaction fails (and OpenSIPS gets into failure > route) only when all branches failed. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > > On 07/03/2013 10:43 PM, Ronald Cepres wrote: > > Hi all, > > Is there a way I can cancel a pending branch before doing a fail-over to > next gateway (due to timeout from previous gateway)? This way I can make > sure that the call to the previous gateway will not go through anymore > after fail-over to the next gateway, thus preventing us "double-charged" > situations if the previous gateway and the new gateway both answered the > call. > > Thanks in advance. > > > -- > > Regards, > > Ronald > > > ___ > Users mailing > listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Cancel branch before failover on timeout
Hi all, Is there a way I can cancel a pending branch before doing a fail-over to next gateway (due to timeout from previous gateway)? This way I can make sure that the call to the previous gateway will not go through anymore after fail-over to the next gateway, thus preventing us "double-charged" situations if the previous gateway and the new gateway both answered the call. Thanks in advance. -- Regards, Ronald ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] [OpenSIPS-Devel] [DROUTING] Crash on use_next_gw/get_gw_by_id
Thanks, will apply this patch and let you know if the bug still occurs. On Tue, May 21, 2013 at 12:44 AM, Bogdan-Andrei Iancu wrote: > ** > Ups, sorry...here is the proper patch. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > > On 05/20/2013 07:40 PM, Ronald Cepres wrote: > > Hi Bogdan, > > Thanks for the reply. However, the patch that is attached is empty (0 > bytes and doesn't contain anything). > > Regards, > > > On Tue, May 21, 2013 at 12:36 AM, Bogdan-Andrei Iancu > wrote: > >> Hello, >> >> Thanks to the help in debugging this, the bug was found and a patch is >> available for testing (see attached). Please have it tested and let me know >> if it fixes the problem. >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >> >> >> On 05/16/2013 07:28 PM, Ronald Cepres wrote: >> >> Drouting crashes when selecting next gateway. Did a little >> investigation, and FWIW the next gateway's carrier status is disabled but >> the carrier's only gateway is enabled. Looked at the backtrace of the core >> dump, and found that it crashed while comparing two strings on get_gw_by_id >> called by use_next_gw. The strings compared were apparently GW ID strings. >> >> I attached the GDB btfull logs (replaced some sensitive info with dummy >> text) for reference. Take note that 'dont optimize' flag was not set so >> some of the values were optimized and the crash happened randomly so I >> can't actually reproduce the crash. >> >> I'm using Opensips 1.9 using this source tarball: >> http://opensips.org/pub/opensips/latest/src/opensips-1.9.0_src.tar.gz >> >> -- >> >> Regards, >> >> Ronald Cepres >> >> >> ___ >> Devel mailing >> listDevel@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/devel >> >> > > > -- > > Ronald Cepres > Network Operations Center > Net Voip Communications, Inc. > > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please notify > the sender immediately by e-mail if you have received this e-mail by > mistake and delete this e-mail from your system. E-mail transmission > cannot be guaranteed to be secure or error-free as information could > be intercepted, corrupted, lost, destroyed, arrive late or incomplete, > or contain viruses. The sender therefore does not accept liability for > any errors or omissions in the contents of this message, which arise > as a result of e-mail transmission. If verification is required please > request a hard-copy version. Net Voip Communications, Inc., 2721 > Forsyth Rd #256, Winter park, FL 32792. www.netvoipcommunications.com > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- Ronald Cepres Network Operations Center Net Voip Communications, Inc. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Net Voip Communications, Inc., 2721 Forsyth Rd #256, Winter park, FL 32792. www.netvoipcommunications.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] [OpenSIPS-Devel] [DROUTING] Crash on use_next_gw/get_gw_by_id
Hi Bogdan, Thanks for the reply. However, the patch that is attached is empty (0 bytes and doesn't contain anything). Regards, On Tue, May 21, 2013 at 12:36 AM, Bogdan-Andrei Iancu wrote: > ** > Hello, > > Thanks to the help in debugging this, the bug was found and a patch is > available for testing (see attached). Please have it tested and let me know > if it fixes the problem. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > > On 05/16/2013 07:28 PM, Ronald Cepres wrote: > > Drouting crashes when selecting next gateway. Did a little > investigation, and FWIW the next gateway's carrier status is disabled but > the carrier's only gateway is enabled. Looked at the backtrace of the core > dump, and found that it crashed while comparing two strings on get_gw_by_id > called by use_next_gw. The strings compared were apparently GW ID strings. > > I attached the GDB btfull logs (replaced some sensitive info with dummy > text) for reference. Take note that 'dont optimize' flag was not set so > some of the values were optimized and the crash happened randomly so I > can't actually reproduce the crash. > > I'm using Opensips 1.9 using this source tarball: > http://opensips.org/pub/opensips/latest/src/opensips-1.9.0_src.tar.gz > > -- > > Regards, > > Ronald Cepres > > > _______ > Devel mailing > listDevel@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/devel > > -- Ronald Cepres Network Operations Center Net Voip Communications, Inc. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Net Voip Communications, Inc., 2721 Forsyth Rd #256, Winter park, FL 32792. www.netvoipcommunications.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] is_method crash when used on pike triggered route
Hi Bogdan,
OpenSIPS didn't crash anymore after I used your patch. Thanks for the help!
Regards,
Ronald
On Wed, Jan 18, 2012 at 11:35 PM, Ronald Cepres wrote:
> Hi Bogdan,
>
> Thanks for the quick patch. I'll try it out tomorrow and let you know the
> result at the end of the day.
>
> Regards,
> Ronald
>
>
> On Tue, Jan 17, 2012 at 11:21 PM, Bogdan-Andrei Iancu > wrote:
>
>> **
>> Hi Ronald,
>>
>> Thanks for the useful information - find attached a patch that should fix
>> the problem - please apply it, recompile and let me know if works ok - if
>> yes, I will update on SVN.
>>
>> The crash seams to be triggered by a bogus SIP message where the parsing
>> of the first line fails - and this message hits the pike route crashing in
>> some parsing functions.
>>
>> Regards,
>> Bogdan
>>
>>
>> On 01/16/2012 06:08 AM, Ronald Cepres wrote:
>>
>> Hi Bogdan,
>>
>> Thanks for your reply.
>>
>> The crash happened often (every less than hour) on live traffic, but I
>> was not able to reproduce the bug on my own.
>> Here's the last part of OpenSIPS logs that I saved after the crash:
>>
>> Jan 13 09:31:39 ASTPROD-03 kernel: [25303999.864022] opensips[12133]:
>> segfault at 0 ip 080f639c sp bfffc620 error 4 in opensips[8048000+139000]
>> Jan 13 09:31:39 ASTPROD-03 /sbin/opensips[12133]:
>> INFO:core:parse_first_line: method not followed by SP
>> Jan 13 09:31:39 ASTPROD-03 /sbin/opensips[12133]:
>> INFO:core:parse_first_line: bad message
>> Jan 13 09:31:39 ASTPROD-03 /sbin/opensips[12133]: ERROR:core:parse_msg:
>> message=<-15#015#012REGISTER sip:server.example.com;transport=tcp
>> SIP/2.0#015#012Via: SIP/2.0/TCP
>> client.example.com:13851;rport;branch=z9hG4bKPj-HwYov6D5txKI6aVe5WxpubPXFTKtkHM#015#012Max-Forwards:
>> 70#015#012From:
>> ;tag=e3o0uokXbnsOsn0HWFiw2Pn5D2TuAcmB#015#012To:
>> #015#012Call-ID:
>> m2n.UnXe-HLK-XaiL0m6sWnOF1lQ71O.#015#012CSeq: 26361
>> REGISTER#015#012User-Agent: 12Connect Lite SIP v3.0#015#012Contact:
>> #015#012Expires:
>> 300#015#012Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE,
>> NOTIFY, REFER, MESSAGE, OPTIONS#015#012Content-Length: 0#015#012#015#012>
>> Jan 13 09:31:39 ASTPROD-03 /sbin/opensips[12133]: ERROR:core:receive_msg:
>> parse_msg failed
>> Jan 13 09:31:40 ASTPROD-03 /sbin/opensips[12145]:
>> CRITICAL:core:receive_fd: EOF on 38
>> Jan 13 09:31:40 ASTPROD-03 /sbin/opensips[12106]: INFO:core:handle_sigs:
>> child process 12133 exited by a signal 11
>> Jan 13 09:31:40 ASTPROD-03 /sbin/opensips[12106]: INFO:core:handle_sigs:
>> core was generated
>> Jan 13 09:31:40 ASTPROD-03 /sbin/opensips[12106]: INFO:core:handle_sigs:
>> terminating due to SIGCHLD
>>
>> On Sun, Jan 15, 2012 at 8:45 PM, Bogdan-Andrei Iancu <
>> bog...@opensips.org> wrote:
>>
>>> Hi Ronald,
>>>
>>> The crash happens on a reply and not a request - see the frame 14, where
>>> "buf" (the buffer containing the
>>> sip message) shows a reply like text.
>>>
>>> But the is_method() should not crash at allbefore diving into
>>> debugging:
>>> 1) can you reproduce this crash ?
>>> 2) before the crash, do you see any errors in the logs
>>>
>>> Regards,
>>> Bogdan
>>>
>>>
>>> On 01/13/2012 01:16 PM, Ronald Cepres wrote:
>>>
>>> Hi all,
>>>
>>> I'm using OpenSIPS 1.7.1 and based from the attached back trace, it
>>> crashed when it is trying to parse the method of a REGISTER message
>>> received by the server, triggered by pike route.
>>>
>>> Here is a snippet of my opensips.cfg:
>>> ...
>>> loadmodule "pike.so"
>>> modparam("pike", "sampling_time_unit", 30)
>>> modparam("pike", "reqs_density_per_unit", 75)
>>> modparam("pike", "check_route", "pike")
>>> ...
>>> route[pike] {
>>> if (($si == $Ri) || ($si == "192.168.1.60") || ($si == "
>>> 192.168.1.61") || ($si == " 192.168.1.65")) {
>>> drop;
>>> }
>>> if (!is_method("REGISTER")) {
>>> drop;
>>> }
>>> }
>>> ...
>>>
>>> Basically, I just want to check REGISTER messages only on the pike
>>> route. Does anyone have a workaround on this?
>>>
>>> FWIW, should I also post this on the dev list?
>>>
>>> Thanks!
>>>
>>> Regards,
>>> Ronald
>>>
>>>
>>> ___
>>> Users mailing
>>> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>> --
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developer
>>> OpenSIPS solutions and "know-how"
>>>
>>>
>>
>>
>> --
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> OpenSIPS solutions and "know-how"
>>
>>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] is_method crash when used on pike triggered route
Hi Bogdan,
Thanks for the quick patch. I'll try it out tomorrow and let you know the
result at the end of the day.
Regards,
Ronald
On Tue, Jan 17, 2012 at 11:21 PM, Bogdan-Andrei Iancu
wrote:
> **
> Hi Ronald,
>
> Thanks for the useful information - find attached a patch that should fix
> the problem - please apply it, recompile and let me know if works ok - if
> yes, I will update on SVN.
>
> The crash seams to be triggered by a bogus SIP message where the parsing
> of the first line fails - and this message hits the pike route crashing in
> some parsing functions.
>
> Regards,
> Bogdan
>
>
> On 01/16/2012 06:08 AM, Ronald Cepres wrote:
>
> Hi Bogdan,
>
> Thanks for your reply.
>
> The crash happened often (every less than hour) on live traffic, but I
> was not able to reproduce the bug on my own.
> Here's the last part of OpenSIPS logs that I saved after the crash:
>
> Jan 13 09:31:39 ASTPROD-03 kernel: [25303999.864022] opensips[12133]:
> segfault at 0 ip 080f639c sp bfffc620 error 4 in opensips[8048000+139000]
> Jan 13 09:31:39 ASTPROD-03 /sbin/opensips[12133]:
> INFO:core:parse_first_line: method not followed by SP
> Jan 13 09:31:39 ASTPROD-03 /sbin/opensips[12133]:
> INFO:core:parse_first_line: bad message
> Jan 13 09:31:39 ASTPROD-03 /sbin/opensips[12133]: ERROR:core:parse_msg:
> message=<-15#015#012REGISTER sip:server.example.com;transport=tcp
> SIP/2.0#015#012Via: SIP/2.0/TCP
> client.example.com:13851;rport;branch=z9hG4bKPj-HwYov6D5txKI6aVe5WxpubPXFTKtkHM#015#012Max-Forwards:
> 70#015#012From:
> ;tag=e3o0uokXbnsOsn0HWFiw2Pn5D2TuAcmB#015#012To:
> #015#012Call-ID:
> m2n.UnXe-HLK-XaiL0m6sWnOF1lQ71O.#015#012CSeq: 26361
> REGISTER#015#012User-Agent: 12Connect Lite SIP v3.0#015#012Contact:
> #015#012Expires:
> 300#015#012Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE,
> NOTIFY, REFER, MESSAGE, OPTIONS#015#012Content-Length: 0#015#012#015#012>
> Jan 13 09:31:39 ASTPROD-03 /sbin/opensips[12133]: ERROR:core:receive_msg:
> parse_msg failed
> Jan 13 09:31:40 ASTPROD-03 /sbin/opensips[12145]:
> CRITICAL:core:receive_fd: EOF on 38
> Jan 13 09:31:40 ASTPROD-03 /sbin/opensips[12106]: INFO:core:handle_sigs:
> child process 12133 exited by a signal 11
> Jan 13 09:31:40 ASTPROD-03 /sbin/opensips[12106]: INFO:core:handle_sigs:
> core was generated
> Jan 13 09:31:40 ASTPROD-03 /sbin/opensips[12106]: INFO:core:handle_sigs:
> terminating due to SIGCHLD
>
> On Sun, Jan 15, 2012 at 8:45 PM, Bogdan-Andrei Iancu > wrote:
>
>> Hi Ronald,
>>
>> The crash happens on a reply and not a request - see the frame 14, where
>> "buf" (the buffer containing the
>> sip message) shows a reply like text.
>>
>> But the is_method() should not crash at allbefore diving into
>> debugging:
>> 1) can you reproduce this crash ?
>> 2) before the crash, do you see any errors in the logs
>>
>> Regards,
>> Bogdan
>>
>>
>> On 01/13/2012 01:16 PM, Ronald Cepres wrote:
>>
>> Hi all,
>>
>> I'm using OpenSIPS 1.7.1 and based from the attached back trace, it
>> crashed when it is trying to parse the method of a REGISTER message
>> received by the server, triggered by pike route.
>>
>> Here is a snippet of my opensips.cfg:
>> ...
>> loadmodule "pike.so"
>> modparam("pike", "sampling_time_unit", 30)
>> modparam("pike", "reqs_density_per_unit", 75)
>> modparam("pike", "check_route", "pike")
>> ...
>> route[pike] {
>> if (($si == $Ri) || ($si == "192.168.1.60") || ($si == "
>> 192.168.1.61") || ($si == " 192.168.1.65")) {
>> drop;
>> }
>> if (!is_method("REGISTER")) {
>> drop;
>> }
>> }
>> ...
>>
>> Basically, I just want to check REGISTER messages only on the pike
>> route. Does anyone have a workaround on this?
>>
>> FWIW, should I also post this on the dev list?
>>
>> Thanks!
>>
>> Regards,
>> Ronald
>>
>>
>> ___
>> Users mailing
>> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> --
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> OpenSIPS solutions and "know-how"
>>
>>
>
>
> --
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> OpenSIPS solutions and "know-how"
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] is_method crash when used on pike triggered route
Hi Bogdan,
Thanks for your reply.
The crash happened often (every less than hour) on live traffic, but I was
not able to reproduce the bug on my own.
Here's the last part of OpenSIPS logs that I saved after the crash:
Jan 13 09:31:39 ASTPROD-03 kernel: [25303999.864022] opensips[12133]:
segfault at 0 ip 080f639c sp bfffc620 error 4 in opensips[8048000+139000]
Jan 13 09:31:39 ASTPROD-03 /sbin/opensips[12133]:
INFO:core:parse_first_line: method not followed by SP
Jan 13 09:31:39 ASTPROD-03 /sbin/opensips[12133]:
INFO:core:parse_first_line: bad message
Jan 13 09:31:39 ASTPROD-03 /sbin/opensips[12133]: ERROR:core:parse_msg:
message=<-15#015#012REGISTER sip:server.example.com;transport=tcp
SIP/2.0#015#012Via: SIP/2.0/TCP
client.example.com:13851;rport;branch=z9hG4bKPj-HwYov6D5txKI6aVe5WxpubPXFTKtkHM#015#012Max-Forwards:
70#015#012From:
;tag=e3o0uokXbnsOsn0HWFiw2Pn5D2TuAcmB#015#012To:
#015#012Call-ID:
m2n.UnXe-HLK-XaiL0m6sWnOF1lQ71O.#015#012CSeq: 26361
REGISTER#015#012User-Agent: 12Connect Lite SIP v3.0#015#012Contact:
#015#012Expires:
300#015#012Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE,
NOTIFY, REFER, MESSAGE, OPTIONS#015#012Content-Length: 0#015#012#015#012>
Jan 13 09:31:39 ASTPROD-03 /sbin/opensips[12133]: ERROR:core:receive_msg:
parse_msg failed
Jan 13 09:31:40 ASTPROD-03 /sbin/opensips[12145]: CRITICAL:core:receive_fd:
EOF on 38
Jan 13 09:31:40 ASTPROD-03 /sbin/opensips[12106]: INFO:core:handle_sigs:
child process 12133 exited by a signal 11
Jan 13 09:31:40 ASTPROD-03 /sbin/opensips[12106]: INFO:core:handle_sigs:
core was generated
Jan 13 09:31:40 ASTPROD-03 /sbin/opensips[12106]: INFO:core:handle_sigs:
terminating due to SIGCHLD
On Sun, Jan 15, 2012 at 8:45 PM, Bogdan-Andrei Iancu wrote:
> **
> Hi Ronald,
>
> The crash happens on a reply and not a request - see the frame 14, where
> "buf" (the buffer containing the
> sip message) shows a reply like text.
>
> But the is_method() should not crash at allbefore diving into
> debugging:
> 1) can you reproduce this crash ?
> 2) before the crash, do you see any errors in the logs
>
> Regards,
> Bogdan
>
>
> On 01/13/2012 01:16 PM, Ronald Cepres wrote:
>
> Hi all,
>
> I'm using OpenSIPS 1.7.1 and based from the attached back trace, it
> crashed when it is trying to parse the method of a REGISTER message
> received by the server, triggered by pike route.
>
> Here is a snippet of my opensips.cfg:
> ...
> loadmodule "pike.so"
> modparam("pike", "sampling_time_unit", 30)
> modparam("pike", "reqs_density_per_unit", 75)
> modparam("pike", "check_route", "pike")
> ...
> route[pike] {
> if (($si == $Ri) || ($si == "192.168.1.60") || ($si == "
> 192.168.1.61") || ($si == " 192.168.1.65")) {
> drop;
> }
> if (!is_method("REGISTER")) {
> drop;
> }
> }
> ...
>
> Basically, I just want to check REGISTER messages only on the pike
> route. Does anyone have a workaround on this?
>
> FWIW, should I also post this on the dev list?
>
> Thanks!
>
> Regards,
> Ronald
>
>
> ___
> Users mailing
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> --
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> OpenSIPS solutions and "know-how"
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] is_method crash when used on pike triggered route
Hi all,
I'm using OpenSIPS 1.7.1 and based from the attached back trace, it crashed
when it is trying to parse the method of a REGISTER message received by the
server, triggered by pike route.
Here is a snippet of my opensips.cfg:
...
loadmodule "pike.so"
modparam("pike", "sampling_time_unit", 30)
modparam("pike", "reqs_density_per_unit", 75)
modparam("pike", "check_route", "pike")
...
route[pike] {
if (($si == $Ri) || ($si == "192.168.1.60") || ($si == "
192.168.1.61") || ($si == " 192.168.1.65")) {
drop;
}
if (!is_method("REGISTER")) {
drop;
}
}
...
Basically, I just want to check REGISTER messages only on the pike route.
Does anyone have a workaround on this?
FWIW, should I also post this on the dev list?
Thanks!
Regards,
Ronald
(gdb) bt full
#0 get_hdr_field (buf=0x0, end=0xaf6c95df "", hdr=0x81d9280) at
parser/msg_parser.c:83
tmp =
match =
vb =
cseq_b =
to_b =
integer =
__FUNCTION__ = "get_hdr_field"
_c = 89 'Y'
#1 0x080f7342 in parse_headers (msg=0x81cac00, flags=32, next=0) at
parser/msg_parser.c:322
hf = (struct hdr_field *) 0x81d9280
itr =
tmp = 0x0
rest = 0xaf683c40 "Content-Length: 0\r\n\r\nCK, BYE, CANCEL, UPDATE,
SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS\r\nAccept: application/sdp,
application/pidf+xml, application/xpidf+xml,
application/simple-message-summary, mes"...
end = 0xaf6c95df ""
orig_flag = 0
__FUNCTION__ = "parse_headers"
#2 0xb752734a in is_method_f (msg=0x81cac00, meth=0x81caabc "", str2=0x0) at
textops.c:1220
__FUNCTION__ = "is_method_f"
#3 0x08057e64 in do_action (a=0x81c98c0, msg=0x81cac00) at action.c:1280
val_s = {s = 0xbfffee48 "Øïÿ¿Ê\r\v\b", len = 134811270}
aux = {s = 0x81c9550 "\"", len = 136096768}
ret =
v =
sec =
usec =
to =
---Type to continue, or q to quit---
p =
tmp =
new_uri =
end =
crt =
len =
i =
user =
vals = {{s = 0x0, len = 0}, {s = 0x0, len = 136090492}, {s = 0x81c9370
"\"", len = 136096768}, {s = 0xbfffee18 "\214ïÿ¿Ê\r\v\b", len = 134811270}, {s
= 0x81cac00 ")", len = 11}}
result = {s = 0xbfffef8c "Àû\033\b\016", len = 134942154}
uri = {user = {s = 0xb75f2cd3 "\201Ã!£\016", len = 138188100}, passwd =
{s = 0x1110 , len = 0}, host = {s = 0x83cb81f
"sg: parse_msg failed\n", len = 0}, port = {
s = 0x83c9544 "àÈm·", len = -1218689948}, params = {s = 0xb76dcff4
"\234m\025", len = 11}, headers = {s = 0xa , len =
-1073745128}, port_no = 23703, proto = 46940,
type = 3077427188, transport = {s = 0x8167d09 ": message=<%.*s>\n", len =
11}, ttl = {s = 0xb32c "8¸<\bHóÿ¿8¸<\bÈg\001", len = -1218683753},
user_param = {s = 0x83c94b0 "\220ám·\220ám·",
len = -1218499373}, maddr = {s = 0xb , len =
4368}, method = {s = 0xb7612d09 "\205Àu\033\213U´\213E¸3\203\200\030", len =
138197000}, lr = {s = 0xb75f2cd3 "\201Ã!£\016",
len = 138188100}, r2 = {s = 0x1110 , len =
-1217649655}, transport_val = {s = 0x83cb821 ": parse_msg failed\n", len = 0},
ttl_val = {s = 0x83c9544 "àÈm·",
len = -1218689948}, user_param_val = {s = 0xb76dcff4 "\234m\025", len =
19}, maddr_val = {s = 0x12 , len = -1073745032},
method_val = {
s = 0xb75c5c97 "9Ç\017\205\201ýÿÿ\213µxûÿÿ\001½túÿÿ\200>", len =
-1217540108}, lr_val = {s = 0x815c49d ": parse_msg failed\n", len = 19}, r2_val
= {s = 0xb38c "\001", len = -1218683753},
u_name = {{s = 0x83c94b0 "\220ám·\220ám·", len = 135644317}, {s = 0x13
, len = 4368}, {s = 0x0, len = 0}, {s = 0xb
, len = 50331604}, {
s = 0x1110 , len = -1217649655}}, u_val =
{{s = 0xb76c2408 "%d]", len = -1218681976}, {s = 0x81c919c "", len =
13609}, {s = 0x81cac00 ")", len = -1073746456}, {
s = 0x8090e86
"\205À\017\205Ûþÿÿ\213V0\205Ò\017\204Ðþÿÿ\213u\020\211t$\b\211T$\004\211<$è)\233\004",
len = 136096768}, {s = 0xb , len = 50327340}},
u_params_no = 0}
next_hop = {user = {s = 0xb76c167f "", len = -1217540108},
passwd = {s = 0x0, len = 138205152}, host = {s = 0xbfffec14 "", len =
-1218477610}, port = {s = 0xb76de160 "", len = 0},
params = {s = 0x0, len = 0}, headers = {s = 0x0, len = -1352123843}, port_no
= 23, proto = 0, type = ERROR_URI_T, transport = {s = 0x0, len = -1352123819},
ttl = {s = 0xd ,
len = 0}, user_param = {s = 0x0, len = 131072}, maddr = {s = 0x1 , len = -1352123819}, method = {s = 0xd , len = 0}, lr = {s = 0x0, len = 0},
r2 = {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 = 0xb75f2cd3
"\201Ã!£\016", len = -1352123809},
method_val = {s = 0x3 , len = 0}, lr_val = {s =
0x83cb808 "]: ERROR:core:receive_msg: parse_msg failed\n", len = -1218499373},
r2_val = {s = 0x83c9544 "àÈm·",
len = 135698488}, u_name = {{s =
[OpenSIPS-Users] Source IP address on Asterisk integration
Hi all, I'm trying to set up Opensips so that it simply relays the requests it receives to Asterisk on the same server, only using a different port. The set-up is working but my problem is Asterisk uses the IP of OpenSIPS as peer contact even if the domain on the Contact header is from the actual sender of the request. The peer's setting on Asterisk is nat=yes, and I'm not allowed to change this value. Can I tweak something on Opensips so that Asterisk can see the real sender's IP address even with nat=yes on Asterisk? Thanks! Regards, Ronald ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opensips crashing due to out of memory error
Have you tried increasing the amount of allocated memory for OpenSIPS? On Sun, Apr 10, 2011 at 5:53 AM, Nauman Sulaiman wrote: > Hi, I'm getting random crashes of Opensips 1.6.2, here are the entries in > the log, seems to be out of memory, how should i try to solve this issue. > > ERROR:tm:_reply_light: failed to allocate shmem buffer > ERROR:tm:_reply_light: failed to allocate shmem buffer > ERROR:tm:relay_reply: no more share memory > ERROR:core:new_avp: no more shm mem > ERROR:core:add_avp: Failed to create new avp structure > > > Regards > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] sst module killing calls
I also tried parsing the Session-Expires header value and re-set the
timeout_avp to this value during re-INVITE. The results are still the same.
Has anyone encountered this problem and fixed it?
Any help would be appreciated. Thanks!
Regards,
Ronald
On Thu, Mar 3, 2011 at 2:58 AM, Ronald Cepres wrote:
> Hi Bogdan,
>
> I get a very similar behavior as what Jeff gets. I can see the re-INVITE
> coming and I'm sure that it goes through loose_route block. I can also see
> the "Update by a REQUEST" log. Here's a snippet of the logs after getting
> the re-INVITE:
>
> DBG:dialog:dlg_onroute: route param is '04e.1dc98a86' (len=12)
> DBG:dialog:lookup_dlg: ref dlg 0x780a4fe0 with 1 -> 3
> DBG:dialog:lookup_dlg: dialog id=1755880657 found on entry 3648
> DBG:core:parse_headers: flags=48
> DBG:core:parse_to_param: tag=9979
> DBG:core:parse_to: end of header reached, state=29
> DBG:core:parse_to: display={}, ruri={sip:nxxnxxx...@opensips.ip:5060}
> DBG:dialog:next_state_dlg: dialog 0x780a4fe0 changed from state 4 to state
> 4, due event 8
> DBG:dialog:dlg_onroute: sequential request successfully processed
> (dst_leg=0)
> DBG:dialog:get_dlg_timeout: invalid AVP value, use default timeout
> DBG:dialog:dlg_update_cseq: dlg 0x780a4fe0[0]: cseq is 1
> DBG:dialog:run_dlg_callbacks: dialog=0x780a4fe0, type=16
> DBG:sst:sst_dialog_request_within_CB: Update by a REQUEST. INVITE
> DBG:core:parse_headers: flags=
> 7fcf80a53e41f75c431e5b7d0300c...@opensips.ip: entering loose_route block..
>
> Dialogs still expire after the timeout set by sst module. What else can I
> check to see where might probably be wrong?
>
> Thanks!
>
> Regards,
> Ronald
>
> On Thu, Feb 3, 2011 at 6:23 AM, Bogdan-Andrei Iancu
> wrote:
>
>> Hi Jeff,
>>
>> are you sure your re-INVITE is going through loose_route() and attached to
>> the dialog context (to update it) ?
>>
>> if running in debug mode, at re-INVITE time you could see a log from SST
>> module like "Update by a REQUEST..."
>>
>> Regards,
>> bogdan
>>
>> Jeff Pyle wrote:
>>
>>> And another issue…
>>>
>>> With a call that went to a carrier that does support sst, I see they
>>> refreshed the call at 15 seconds into it. Or, 15 seconds before the session
>>> expired. You can look at it either way. They included the following in their
>>> refresher INVITE:
>>> Session-Expires: 90;refresher=uac
>>> Min-SE: 90
>>>
>>> So they've bumped the timer to 90 seconds from my 30. Cool. It seems the
>>> sst module doesn't see this refresh, and the dialog module still doinks the
>>> call at 30 seconds into it. Bummer. Is this normal?
>>>
>>> On the initial INVITE I create the dialog with create_dialog() then set
>>> the flag for the sst module.
>>>
>>>
>>>
>>> - Jeff
>>>
>>>
>>> From: Jeff Pyle mailto:jp...@fidelityvoice.com
>>> >>
>>> Reply-To: OpenSIPS users mailling list >> users@lists.opensips.org>>
>>>
>>> Date: Thu, 27 Jan 2011 13:49:44 -0500
>>> To: OpenSIPS users mailling list >> users@lists.opensips.org>>
>>>
>>> Subject: [OpenSIPS-Users] sst module killing calls
>>>
>>> Hello,
>>>
>>> I'm experimenting with the sst module once again. It's configured as
>>> follows:
>>>
>>> modparam("dialog|sst", "timeout_avp", "$avp(s:dialog_timeout)")
>>> modparam("sst", "sst_flag", 6)
>>> modparam("sst", "min_se", 30)
>>>
>>> Dialogs are set for all calls.
>>>
>>> Calls I sent contain the following header:
>>> Session-Expires: 30
>>>
>>> So far, so good. When I get a 200 OK from a carrier that supports sst, I
>>> see the following headers:
>>> Supported: timer
>>> Session-Expires: 30;refresher=uas
>>>
>>> (The 30 second expiration is an experimentally low value.) When I get a
>>> 200 OK from a carrier that doesn't support sst, I don't see those two
>>> headers. In this case it seems the sst module still sets the dialog
>>> expiration to 30 seconds, after which the call goes poof.
>>>
>>> Is that correct behavior? If neither end advertise support for sst, and
>>> neither side is going to refresh it, it seems a bit strange the sst module
>>> would still cause the dialog to expire at the expiration time.
>>>
>>>
>>> - Jeff
>>>
>>>
>>>
>>> ___
>>> Users mailing list
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>>
>> --
>> Bogdan-Andrei Iancu
>> OpenSIPS Event - expo, conf, social, bootcamp
>> 2 - 4 February 2011, ITExpo, Miami, USA
>> OpenSIPS solutions and "know-how"
>>
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] ratelimit: per group/account limiting
Hi Ovidiu and Bogdan, I see your point. Thanks for clearing my thoughts about this issue! Regards, Ronald On Sun, Feb 27, 2011 at 5:53 PM, Bogdan-Andrei Iancu wrote: > Hi Ovidiu, > > I got your point - I was making a comment to complete your statement. > > I agree that rate limit and concurrent call limit are 2 protection > mechanism that normally are more suitable in different scenarios. > > But more or less, this is up to the admin to decide :) (which to use and in > what scenarios). > > > Regards, > Bogdan > > Ovidiu Sas wrote: > >> Hello Bogdan, >> >> Just for the record, I am not against having more flexibility in >> building scripts and new features (like dynamic creation of pipes) are >> more then welcome. In my previous replies I was just pointing out >> that ratelimit-ing basic accounts and small trunks doesn't add more >> protection for the server itself or better subscriber management. >> Setting a ratelimit for a SIP account that has a channel limit of two >> is an overkill, IMHO. >> Ratelimit-ing really makes sense for large SIP trunks and whole SIP >> traffic (server protection). >> >> >> Regards, >> Ovidiu Sas >> >> On Fri, Feb 25, 2011 at 11:59 AM, Bogdan-Andrei Iancu >> wrote: >> >> >>> Hi Ovidiu, >>> >>> actually we were flirting for some time with extending the ratelimit >>> module >>> to allow dynamic creation of pipes - this will give you more flexibility >>> in >>> scripting and scenarios (like dynamic number of trunke, DB provisioning, >>> etc).But this was a bit postponed as there are other more important >>> things to do and resources are limited ;) >>> >>> Regards, >>> Bogdan >>> >>> Ovidiu Sas wrote: >>> >>> >>>> There are two different things: >>>> a. channel limitation or concurrent call limit; >>>> b. ratelimit or cps limitation (cps = cals per second). >>>> >>>> With the dialog module, you limit _only_ the number of concurrent >>>> calls (a). How fast will a SIP trunk be saturated is up to the cps. >>>> If you have a limit of 30 calls and the calls are coming in at a rate >>>> of 1 cps, in 30s you will reach your limit. If the calls are coming >>>> in at a rate of 15 cps, you will reach the limit in 2s. >>>> >>>> With the ratelimit module, you limit _only_ the number of calls per >>>> second that are processed. >>>> If you set a cps limit of 5 cps and your incoming traffic is 100cps, >>>> then every second the first 5 calls will go through and the next 95 >>>> will be rejected (based on TAILDROP algorithm). If the traffic is >>>> steady for 10s, then you will have 10x5=50 active calls and 10x95=950 >>>> rejected calls due to cps limitation. >>>> >>>> Now, if you combine both (30 channels max and 5cps limit for incoming >>>> traffic at 100 cps), during the first 6s you will saturate the trunk >>>> (by accepting the first 5 calls and rejecting the other 95 every >>>> second) and all calls after that will be rejected. >>>> >>>> Hope this helps. >>>> >>>> >>>> Regards, >>>> Ovidiu Sas >>>> On Wed, Feb 23, 2011 at 12:51 PM, Ronald Cepres >>>> wrote: >>>> >>>> >>>> >>>>> On Wed, Feb 23, 2011 at 6:10 AM, Ovidiu Sas >>>>> wrote: >>>>> >>>>> >>>>> >>>>>> If a virtual PRI is set up (23 channels for NA or 30 channels for >>>>>> Europe), again the cps doesn't really count. As soon as the virtual >>>>>> PRI is maxed out (in terms of channels) all subsequent calls will be >>>>>> rejected (and the cps will be 0). >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Hi Ovidiu, >>>>> Does that mean that if i have a concurrent call limit of 30 for a user >>>>> and >>>>> he bursts 500 cps, he still wouldn't exceed 30 cps? >>>>> By the way, I use a method similar to the one posted in the tutorials >>>>> to >>>>> limit concurrent calls >>>>> (link: http://www.opensips.org/Resources/DocsTutConcurrentCalls) >>>>> Thanks! >>>>> Regards, >>>>> Ronald >>>>> ___ >>>>> Users mailing list >>>>> Users@lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> >>>>> >>>>> >>>>> >>>> ___ >>>> Users mailing list >>>> Users@lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>>> >>>> >>> -- >>> Bogdan-Andrei Iancu >>> OpenSIPS eBootcamp - 28th February 2011 >>> OpenSIPS solutions and "know-how" >>> >>> >>> ___ >>> Users mailing list >>> Users@lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >> > > -- > Bogdan-Andrei Iancu > OpenSIPS eBootcamp - 28th February 2011 > OpenSIPS solutions and "know-how" > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] How to use sst to account missing BYEs
Hi Bogdan,
I see the Session-Timer header sent to callee. In most cases, only the
callee supports SST.
I can also see the re-INVITE coming from the callee but after the duration
of session interval, the dialog associated with the call gets expired and
probably destroyed. What could possibly be wrong with my setup?
Regards,
Ronald
On Mon, Jan 10, 2011 at 8:02 PM, Bogdan-Andrei Iancu wrote:
> Hi Ronald,
>
> If you look at the SIP capture, do you see the Session-Timer header sent to
> callee ? does your caller/callee supports SST ?
>
> Regards,
> Bogdan
>
> Ronald Cepres wrote:
>
>> Hi to all!
>>
>> I've been setting up a media-less SIP proxy server using OpenSIPS. We need
>> to account (and bill) every call that goes through the proxy and one of our
>> main concerns is the issue of missing BYEs wherein we can't account the call
>> without a BYE.
>>
>> I tried to use sst module to solve this problem but I'm not sure if I used
>> it correctly for the purpose that I want.
>>
>> Here is a snippet of my opensips.conf (some of the values are just for
>> testing purposes though):
>>
>> ...
>>
>> loadmodule "dialog.so"
>> modparam("dialog", "default_timeout", 10)
>> modparam("dialog", "timeout_avp", "$avp(i:10)")
>> modparam("dialog", "dlg_flag", 4)
>> modparam("dialog", "bye_on_timeout_flag", 5)
>>
>> loadmodule "sst.so"
>> modparam("sst", "timeout_avp", "$avp(i:10)")
>> modparam("sst", "sst_flag", 6)
>> modparam("sst", "min_se", 90)
>> modparam("sst", "sst_interval", 30)
>>
>> ...
>>
>> if (is_method("INVITE")) {
>> # Check minimum SE for SST
>> if (sstCheckMin("1")) {
>> xlog("$ci: $C(rx)422 Session Timer Too Small reply sent.$C(xx)\n");
>> route(EXIT);
>> }
>> # Set INVITE flags
>> setflag(1); # Accounting
>> setflag(2); # Account Missed Calls
>> setflag(3); # Account failed transactions
>> setflag(4); # Dialog flag
>> setflag(5); # Bye-on-dialog-timeout flag
>> setflag(6); # SST flag
>>
>>...
>> }
>>
>> ...
>>
>> Am I using sst module correctly here or is it even possible to use sst
>> module for the said purpose?
>>
>> Thanks!
>>
>> Regards,
>> Ronald
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
> --
> Bogdan-Andrei Iancu
> OpenSIPS Event - expo, conf, social, bootcamp
> 2 - 4 February 2011, ITExpo, Miami, USA
> www.voice-system.ro
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] sst module killing calls
Hi Bogdan,
I get a very similar behavior as what Jeff gets. I can see the re-INVITE
coming and I'm sure that it goes through loose_route block. I can also see
the "Update by a REQUEST" log. Here's a snippet of the logs after getting
the re-INVITE:
DBG:dialog:dlg_onroute: route param is '04e.1dc98a86' (len=12)
DBG:dialog:lookup_dlg: ref dlg 0x780a4fe0 with 1 -> 3
DBG:dialog:lookup_dlg: dialog id=1755880657 found on entry 3648
DBG:core:parse_headers: flags=48
DBG:core:parse_to_param: tag=9979
DBG:core:parse_to: end of header reached, state=29
DBG:core:parse_to: display={}, ruri={sip:nxxnxxx...@opensips.ip:5060}
DBG:dialog:next_state_dlg: dialog 0x780a4fe0 changed from state 4 to state
4, due event 8
DBG:dialog:dlg_onroute: sequential request successfully processed
(dst_leg=0)
DBG:dialog:get_dlg_timeout: invalid AVP value, use default timeout
DBG:dialog:dlg_update_cseq: dlg 0x780a4fe0[0]: cseq is 1
DBG:dialog:run_dlg_callbacks: dialog=0x780a4fe0, type=16
DBG:sst:sst_dialog_request_within_CB: Update by a REQUEST. INVITE
DBG:core:parse_headers: flags=
7fcf80a53e41f75c431e5b7d0300c...@opensips.ip: entering loose_route block..
Dialogs still expire after the timeout set by sst module. What else can I
check to see where might probably be wrong?
Thanks!
Regards,
Ronald
On Thu, Feb 3, 2011 at 6:23 AM, Bogdan-Andrei Iancu wrote:
> Hi Jeff,
>
> are you sure your re-INVITE is going through loose_route() and attached to
> the dialog context (to update it) ?
>
> if running in debug mode, at re-INVITE time you could see a log from SST
> module like "Update by a REQUEST..."
>
> Regards,
> bogdan
>
> Jeff Pyle wrote:
>
>> And another issue…
>>
>> With a call that went to a carrier that does support sst, I see they
>> refreshed the call at 15 seconds into it. Or, 15 seconds before the session
>> expired. You can look at it either way. They included the following in their
>> refresher INVITE:
>> Session-Expires: 90;refresher=uac
>> Min-SE: 90
>>
>> So they've bumped the timer to 90 seconds from my 30. Cool. It seems the
>> sst module doesn't see this refresh, and the dialog module still doinks the
>> call at 30 seconds into it. Bummer. Is this normal?
>>
>> On the initial INVITE I create the dialog with create_dialog() then set
>> the flag for the sst module.
>>
>>
>>
>> - Jeff
>>
>>
>> From: Jeff Pyle mailto:jp...@fidelityvoice.com
>> >>
>> Reply-To: OpenSIPS users mailling list > users@lists.opensips.org>>
>>
>> Date: Thu, 27 Jan 2011 13:49:44 -0500
>> To: OpenSIPS users mailling list > users@lists.opensips.org>>
>>
>> Subject: [OpenSIPS-Users] sst module killing calls
>>
>> Hello,
>>
>> I'm experimenting with the sst module once again. It's configured as
>> follows:
>>
>> modparam("dialog|sst", "timeout_avp", "$avp(s:dialog_timeout)")
>> modparam("sst", "sst_flag", 6)
>> modparam("sst", "min_se", 30)
>>
>> Dialogs are set for all calls.
>>
>> Calls I sent contain the following header:
>> Session-Expires: 30
>>
>> So far, so good. When I get a 200 OK from a carrier that supports sst, I
>> see the following headers:
>> Supported: timer
>> Session-Expires: 30;refresher=uas
>>
>> (The 30 second expiration is an experimentally low value.) When I get a
>> 200 OK from a carrier that doesn't support sst, I don't see those two
>> headers. In this case it seems the sst module still sets the dialog
>> expiration to 30 seconds, after which the call goes poof.
>>
>> Is that correct behavior? If neither end advertise support for sst, and
>> neither side is going to refresh it, it seems a bit strange the sst module
>> would still cause the dialog to expire at the expiration time.
>>
>>
>> - Jeff
>>
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
> --
> Bogdan-Andrei Iancu
> OpenSIPS Event - expo, conf, social, bootcamp
> 2 - 4 February 2011, ITExpo, Miami, USA
> OpenSIPS solutions and "know-how"
>
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] ratelimit: per group/account limiting
Hi Ovidiu, Some of my subscribers use dialers which has an average cps of 100. In this case, does it still make sense to limit the rate of each subscriber? If it is, is there a way to implement it, considering there are limited number of pipes that can be used with opensips? Thanks! Regards, Ronald On Sat, Feb 26, 2011 at 1:09 AM, Ovidiu Sas wrote: > Hello Bogdan, > > Just for the record, I am not against having more flexibility in > building scripts and new features (like dynamic creation of pipes) are > more then welcome. In my previous replies I was just pointing out > that ratelimit-ing basic accounts and small trunks doesn't add more > protection for the server itself or better subscriber management. > Setting a ratelimit for a SIP account that has a channel limit of two > is an overkill, IMHO. > Ratelimit-ing really makes sense for large SIP trunks and whole SIP > traffic (server protection). > > > Regards, > Ovidiu Sas > > On Fri, Feb 25, 2011 at 11:59 AM, Bogdan-Andrei Iancu > wrote: > > Hi Ovidiu, > > > > actually we were flirting for some time with extending the ratelimit > module > > to allow dynamic creation of pipes - this will give you more flexibility > in > > scripting and scenarios (like dynamic number of trunke, DB provisioning, > > etc).But this was a bit postponed as there are other more important > > things to do and resources are limited ;) > > > > Regards, > > Bogdan > > > > Ovidiu Sas wrote: > >> > >> There are two different things: > >> a. channel limitation or concurrent call limit; > >> b. ratelimit or cps limitation (cps = cals per second). > >> > >> With the dialog module, you limit _only_ the number of concurrent > >> calls (a). How fast will a SIP trunk be saturated is up to the cps. > >> If you have a limit of 30 calls and the calls are coming in at a rate > >> of 1 cps, in 30s you will reach your limit. If the calls are coming > >> in at a rate of 15 cps, you will reach the limit in 2s. > >> > >> With the ratelimit module, you limit _only_ the number of calls per > >> second that are processed. > >> If you set a cps limit of 5 cps and your incoming traffic is 100cps, > >> then every second the first 5 calls will go through and the next 95 > >> will be rejected (based on TAILDROP algorithm). If the traffic is > >> steady for 10s, then you will have 10x5=50 active calls and 10x95=950 > >> rejected calls due to cps limitation. > >> > >> Now, if you combine both (30 channels max and 5cps limit for incoming > >> traffic at 100 cps), during the first 6s you will saturate the trunk > >> (by accepting the first 5 calls and rejecting the other 95 every > >> second) and all calls after that will be rejected. > >> > >> Hope this helps. > >> > >> > >> Regards, > >> Ovidiu Sas > >> On Wed, Feb 23, 2011 at 12:51 PM, Ronald Cepres > >> wrote: > >> > >>> > >>> On Wed, Feb 23, 2011 at 6:10 AM, Ovidiu Sas > >>> wrote: > >>> > >>>> > >>>> If a virtual PRI is set up (23 channels for NA or 30 channels for > >>>> Europe), again the cps doesn't really count. As soon as the virtual > >>>> PRI is maxed out (in terms of channels) all subsequent calls will be > >>>> rejected (and the cps will be 0). > >>>> > >>>> > >>> > >>> Hi Ovidiu, > >>> Does that mean that if i have a concurrent call limit of 30 for a user > >>> and > >>> he bursts 500 cps, he still wouldn't exceed 30 cps? > >>> By the way, I use a method similar to the one posted in the tutorials > to > >>> limit concurrent calls > >>> (link: http://www.opensips.org/Resources/DocsTutConcurrentCalls) > >>> Thanks! > >>> Regards, > >>> Ronald > >>> ___ > >>> Users mailing list > >>> Users@lists.opensips.org > >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >>> > >>> > >>> > >> > >> ___ > >> Users mailing list > >> Users@lists.opensips.org > >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> > >> > > > > > > -- > > Bogdan-Andrei Iancu > > OpenSIPS eBootcamp - 28th February 2011 > > OpenSIPS solutions and "know-how" > > > > > > ___ > > Users mailing list > > Users@lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] pseudo-variable problem with increasing cps
Hi Tyler,
Yes it is. It's on the first part of the page (syntax section).
-Ronald
On Thu, Feb 24, 2011 at 4:35 PM, Tyler Merritt wrote:
> Is this construct in the scripting variables page and I just missed it?
>
> $(rs)
>
> I had no idea you could throw in stuff like that to the variables.
>
> On Thu, Feb 24, 2011 at 6:13 AM, Dave Singer wrote:
>
>> Ronald,
>>
>> The only time I've seen it be null in failure route is if there was no
>> reply received,
>> you might add a check to see if it was a local timeout:
>>
>> if ( t_local_replied("all") ) {
>>xlog("did not get any response");
>> } else {
>> xlog("$(ci): $C(rx)failure route: $(rs)
>> $(rr)$C(xx)\n");
>> }
>>
>> Dave
>>
>> On Wed, Feb 23, 2011 at 10:04 AM, Ronald Cepres wrote:
>>
>>> Hi all,
>>>
>>> I'm setting up opensips as a stateful proxy, and i have the following
>>> snippet of code on the failure route:
>>>
>>> failure_route[1] {
>>> xlog("$(ci): $C(rx)failure route: $(rs)
>>> $(rr)$C(xx)\n");
>>>
>>> # Failure route routine...
>>> }
>>>
>>> The values of the call-id, response code and reason are normally there.
>>>
>>> but on higher cps, i often get this:
>>>
>>> : failure route:
>>>
>>> Does this mean that the transaction was already destroyed before opensips
>>> got the reply?
>>>
>>> I wonder if anyone comes across this problem. Any help would be
>>> appreciated. Thanks!
>>>
>>>
>>>
>>> Regards,
>>>
>>> Ronald
>>>
>>> ___
>>> Users mailing list
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] pseudo-variable problem with increasing cps
Hi Dave,
That makes sense. I'll try it out.
-Ronald
On Thu, Feb 24, 2011 at 5:13 AM, Dave Singer wrote:
> Ronald,
>
> The only time I've seen it be null in failure route is if there was no
> reply received,
> you might add a check to see if it was a local timeout:
>
> if ( t_local_replied("all") ) {
>xlog("did not get any response");
> } else {
> xlog("$(ci): $C(rx)failure route: $(rs)
> $(rr)$C(xx)\n");
> }
>
> Dave
>
> On Wed, Feb 23, 2011 at 10:04 AM, Ronald Cepres wrote:
>
>> Hi all,
>>
>> I'm setting up opensips as a stateful proxy, and i have the following
>> snippet of code on the failure route:
>>
>> failure_route[1] {
>> xlog("$(ci): $C(rx)failure route: $(rs)
>> $(rr)$C(xx)\n");
>>
>> # Failure route routine...
>> }
>>
>> The values of the call-id, response code and reason are normally there.
>>
>> but on higher cps, i often get this:
>>
>> : failure route:
>>
>> Does this mean that the transaction was already destroyed before opensips
>> got the reply?
>>
>> I wonder if anyone comes across this problem. Any help would be
>> appreciated. Thanks!
>>
>>
>>
>> Regards,
>>
>> Ronald
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] pseudo-variable problem with increasing cps
Hi all,
I'm setting up opensips as a stateful proxy, and i have the following
snippet of code on the failure route:
failure_route[1] {
xlog("$(ci): $C(rx)failure route: $(rs)
$(rr)$C(xx)\n");
# Failure route routine...
}
The values of the call-id, response code and reason are normally there.
but on higher cps, i often get this:
: failure route:
Does this mean that the transaction was already destroyed before opensips
got the reply?
I wonder if anyone comes across this problem. Any help would be appreciated.
Thanks!
Regards,
Ronald
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] ratelimit: per group/account limiting
On Wed, Feb 23, 2011 at 6:10 AM, Ovidiu Sas wrote: > > If a virtual PRI is set up (23 channels for NA or 30 channels for > Europe), again the cps doesn't really count. As soon as the virtual > PRI is maxed out (in terms of channels) all subsequent calls will be > rejected (and the cps will be 0). > > Hi Ovidiu, Does that mean that if i have a concurrent call limit of 30 for a user and he bursts 500 cps, he still wouldn't exceed 30 cps? By the way, I use a method similar to the one posted in the tutorials to limit concurrent calls (link: http://www.opensips.org/Resources/DocsTutConcurrentCalls) Thanks! Regards, Ronald ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] ratelimit: per group/account limiting
Hi everyone, I would like to ask all of you if it is possible to use ratelimit module to limit cps per account/group (i.e.: account A has limit of 10 cps, account B's is 20 cps, etc.)? Is it even possible to implement this set-up on opensips? Thanks for any kind of help. Regards, Ronald ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Weird routing of ACK on INVITE
Hi all,
After relaying an INVITE from my PBX to the carrier side (and after carrier
responded as expected), I receive an expected ACK from my PBX with the
domain part of the RURI of the ACK is the same as the IP of my OpenSIPS,
which seems to be impossible to route back to the carrier side because it
would just be relayed to my OpenSIPS if I try to relay it again based on the
domain of the RURI.
What could be the possible causes to this situation or did I just miss
something?
Here is a snippet of my opensips.cfg if this could help:
...
if (has_totag()) {
if (loose_route()) {
if (is_method("INVITE")) {
record_route();
}
route(RELAY);
} else {
if ( is_method("ACK") ) {
route(RELAY);
route(EXIT);
}
sl_send_reply("404","Not here");
}
route(EXIT);
}
t_check_trans();
...
if (!is_method("REGISTER|MESSAGE"))
record_route();
...
route(RELAY);
}
Any kind of help would be appreciated.
Regards,
Ronald
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] dialog flag and create_dialog function
Hi Bogdan, Ok. It's clear to me now. Thanks! Regards, Ronald On Fri, Feb 4, 2011 at 1:32 PM, Bogdan-Andrei Iancu wrote: > Hi Ronald, > > there is no problem with using the flag and create_dilalog() in the same > time - the dialog will be create only once. > > Regards > Bogdan > > Ronald Cepres wrote: > >> Hi to all, >> >> Does setting the dialog flag and calling the create_dialog function create >> redundant dialogs for a transaction? Just wondering since I didn't find it >> indicated in the dialog module documentation. >> >> Thanks! >> >> Regards, >> Ronald >> >> >> ___ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > > > -- > Bogdan-Andrei Iancu > OpenSIPS Event - expo, conf, social, bootcamp > 2 - 4 February 2011, ITExpo, Miami, USA > OpenSIPS solutions and "know-how" > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] dialog flag and create_dialog function
Hi to all, Does setting the dialog flag and calling the create_dialog function create redundant dialogs for a transaction? Just wondering since I didn't find it indicated in the dialog module documentation. Thanks! Regards, Ronald ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] drouting: no valid routing rules
Hi Dovid! Thanks for that idea! Regards, Ronald On Sun, Jan 9, 2011 at 3:57 AM, Dovid Bender wrote: > Just to add my 2c. When ever I have a db issue I enable verbose logging > to a file and then try to replicate the queries that OpenSipS is trying to > do. Saves a lot of time. > > > - Original Message - > *From:* Ronald Cepres > *To:* OpenSIPS users mailling list > *Sent:* Friday, January 07, 2011 19:16 > *Subject:* Re: [OpenSIPS-Users] drouting: no valid routing rules > > Hi Bogdan, > > yes it is the right url. anyway, i solved my own problem now. it appears to > me that when i migrated my data, the previous data on the 'description' > column of my 1.6.3 table was placed on the new 'attrs' column on 1.6.4 > instead of on the 'description' column. That might have caused an error > somewhere but there are no logs regarding that issue. > > Thanks for attending anyway! > > Regards, > Ronald > > On Sat, Jan 8, 2011 at 12:23 AM, Bogdan-Andrei Iancu < > bog...@voice-system.ro> wrote: > >> Hi Ronald, >> >> may sound as a stupid question, but are you sure the db_url of drouting >> module points to the right database ? >> >> Regards, >> Bogdan >> >> Ronald Cepres wrote: >> >>> Hi to all! >>> >>> After upgrading from 1.6.3 to 1.6.4, I keep on getting this log when >>> starting OpenSIPS: >>> >>> WARNING:drouting:dr_load_routing_info: table "dr_rules" is empty >>> DBG:drouting:dr_load_routing_info: 0 records found in dr_rules >>> WARNING:drouting:dr_load_routing_info: no valid routing rules -> >>> discarding all destinations. >>> >>> Yet, my "dr_rules" table contains at least 100k rules and here is the >>> description of the table: >>> >>> >>> +-+--+--+-+-++ >>> | Field | Type | Null | Key | Default | Extra >>> | >>> >>> +-+--+--+-+-++ >>> | ruleid | int(10) unsigned | NO | PRI | NULL| auto_increment >>> | >>> | groupid | char(255)| NO | | NULL| >>> | >>> | prefix | char(64) | NO | | NULL| >>> | >>> | timerec | char(255)| NO | | NULL| >>> | >>> | priority| int(11) | NO | | 0 | >>> | >>> | routeid | char(255)| NO | | NULL| >>> | >>> | gwlist | char(255)| NO | | NULL| >>> | >>> | attrs | char(255)| YES | | NULL| >>> | >>> | description | char(128)| NO | | | >>> | >>> >>> +-+--+--+-+-++ >>> >>> Am I missing something here? >>> >>> Thanks! >>> >>> Regards, >>> Ronald >>> >>> >>> >>> >>> ___ >>> Users mailing list >>> Users@lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >> >> >> -- >> Bogdan-Andrei Iancu >> OpenSIPS Event - expo, conf, social, bootcamp >> 2 - 4 February 2011, ITExpo, Miami, USA >> www.voice-system.ro >> >> >> ___ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > -- > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] How to use sst to account missing BYEs
Hi to all!
I've been setting up a media-less SIP proxy server using OpenSIPS. We need
to account (and bill) every call that goes through the proxy and one of our
main concerns is the issue of missing BYEs wherein we can't account the call
without a BYE.
I tried to use sst module to solve this problem but I'm not sure if I used
it correctly for the purpose that I want.
Here is a snippet of my opensips.conf (some of the values are just for
testing purposes though):
...
loadmodule "dialog.so"
modparam("dialog", "default_timeout", 10)
modparam("dialog", "timeout_avp", "$avp(i:10)")
modparam("dialog", "dlg_flag", 4)
modparam("dialog", "bye_on_timeout_flag", 5)
loadmodule "sst.so"
modparam("sst", "timeout_avp", "$avp(i:10)")
modparam("sst", "sst_flag", 6)
modparam("sst", "min_se", 90)
modparam("sst", "sst_interval", 30)
...
if (is_method("INVITE")) {
# Check minimum SE for SST
if (sstCheckMin("1")) {
xlog("$ci: $C(rx)422 Session Timer Too Small reply sent.$C(xx)\n");
route(EXIT);
}
# Set INVITE flags
setflag(1); # Accounting
setflag(2); # Account Missed Calls
setflag(3); # Account failed transactions
setflag(4); # Dialog flag
setflag(5); # Bye-on-dialog-timeout flag
setflag(6); # SST flag
...
}
...
Am I using sst module correctly here or is it even possible to use sst
module for the said purpose?
Thanks!
Regards,
Ronald
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] drouting: no valid routing rules
Hi Bogdan, yes it is the right url. anyway, i solved my own problem now. it appears to me that when i migrated my data, the previous data on the 'description' column of my 1.6.3 table was placed on the new 'attrs' column on 1.6.4 instead of on the 'description' column. That might have caused an error somewhere but there are no logs regarding that issue. Thanks for attending anyway! Regards, Ronald On Sat, Jan 8, 2011 at 12:23 AM, Bogdan-Andrei Iancu wrote: > Hi Ronald, > > may sound as a stupid question, but are you sure the db_url of drouting > module points to the right database ? > > Regards, > Bogdan > > Ronald Cepres wrote: > >> Hi to all! >> >> After upgrading from 1.6.3 to 1.6.4, I keep on getting this log when >> starting OpenSIPS: >> >> WARNING:drouting:dr_load_routing_info: table "dr_rules" is empty >> DBG:drouting:dr_load_routing_info: 0 records found in dr_rules >> WARNING:drouting:dr_load_routing_info: no valid routing rules -> >> discarding all destinations. >> >> Yet, my "dr_rules" table contains at least 100k rules and here is the >> description of the table: >> >> +-+--+--+-+-++ >> | Field | Type | Null | Key | Default | Extra | >> +-+--+--+-+-++ >> | ruleid | int(10) unsigned | NO | PRI | NULL| auto_increment | >> | groupid | char(255)| NO | | NULL|| >> | prefix | char(64) | NO | | NULL|| >> | timerec | char(255)| NO | | NULL|| >> | priority| int(11) | NO | | 0 || >> | routeid | char(255)| NO | | NULL|| >> | gwlist | char(255)| NO | | NULL|| >> | attrs | char(255)| YES | | NULL|| >> | description | char(128)| NO | | || >> +-+--+--+-+-++ >> >> Am I missing something here? >> >> Thanks! >> >> Regards, >> Ronald >> >> >> >> >> ___ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > > > -- > Bogdan-Andrei Iancu > OpenSIPS Event - expo, conf, social, bootcamp > 2 - 4 February 2011, ITExpo, Miami, USA > www.voice-system.ro > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] drouting: no valid routing rules
Hi to all! After upgrading from 1.6.3 to 1.6.4, I keep on getting this log when starting OpenSIPS: WARNING:drouting:dr_load_routing_info: table "dr_rules" is empty DBG:drouting:dr_load_routing_info: 0 records found in dr_rules WARNING:drouting:dr_load_routing_info: no valid routing rules -> discarding all destinations. Yet, my "dr_rules" table contains at least 100k rules and here is the description of the table: +-+--+--+-+-++ | Field | Type | Null | Key | Default | Extra | +-+--+--+-+-++ | ruleid | int(10) unsigned | NO | PRI | NULL| auto_increment | | groupid | char(255)| NO | | NULL|| | prefix | char(64) | NO | | NULL|| | timerec | char(255)| NO | | NULL|| | priority| int(11) | NO | | 0 || | routeid | char(255)| NO | | NULL|| | gwlist | char(255)| NO | | NULL|| | attrs | char(255)| YES | | NULL|| | description | char(128)| NO | | || +-+--+--+-+-++ Am I missing something here? Thanks! Regards, Ronald ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Drouting module parameters not found
Thanks Bogdan!
Regards,
Ronald
On Mon, Dec 20, 2010 at 10:48 PM, Bogdan-Andrei Iancu <
bog...@voice-system.ro> wrote:
> Ronald,
>
> use the SVN check out for 1.6 branch -
> http://www.opensips.org/Resources/Downloads#svn
>
>
> Regards,
> Bogdan
>
> Ronald Cepres wrote:
>
>> Not actually from SVN but from the website. Here is the actual download
>> link:
>> http://opensips.org/pub/opensips/latest/src/opensips-1.6.3-tls_src.tar.gz
>>
>> Btw, I have also tried recompiling the source code successfully. However,
>> the previously mentioned errors when running OpenSIPS itself remains the
>> same.
>>
>> On Mon, Dec 13, 2010 at 9:25 PM, Bogdan-Andrei Iancu <
>> bog...@voice-system.ro <mailto:bog...@voice-system.ro>> wrote:
>>
>>Hi Ronald,
>>
>>Are you sure you have the latest 1.6.3 sources from SVN ?
>>
>>Regards,
>>Bogdan
>>
>>Ronald Cepres wrote:
>>
>>Hi to all,
>>
>>I have a problem about the drouting module. Here is a snippet
>>of my script configuration:
>>
>>...
>>loadmodule "drouting.so"
>>modparam("drouting", "db_url",
>>"mysql://user:p...@localhost/opensips")
>>modparam("drouting", "gw_id_avp", "$avp(s:gw_id)")
>>modparam("drouting", "rule_id_avp", "$avp(s:rule_id)")
>>...
>>
>>Starting OpenSIPS gives me these errors:
>>
>>ERROR:core:set_mod_param_regex: parameter not
>>found in module
>>CRITICAL:core:yyerror: parse error in config file, line 111,
>>column 33-34: Parameter not found in module
>> - can't set
>>ERROR:core:set_mod_param_regex: parameter not
>>found in module
>>CRITICAL:core:yyerror: parse error in config file, line 112,
>>column 35-36: Parameter not found in module
>> - can't set
>>
>>Is there a way to fix this problem? I would appreciate any
>>kind of help. Thanks!
>>
>>By the way, I am using the OpenSIPS 1.6.3 release version.
>>
>>
>>
>>
>>
>>___
>>Users mailing list
>>Users@lists.opensips.org <mailto:Users@lists.opensips.org>
>>
>>http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>-- Bogdan-Andrei Iancu
>>OpenSIPS Bootcamp
>>15 - 19 November 2010, Edison, New Jersey, USA
>>www.voice-system.ro <http://www.voice-system.ro>
>>
>>
>>___
>>Users mailing list
>>Users@lists.opensips.org <mailto:Users@lists.opensips.org>
>>
>>http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
> --
> Bogdan-Andrei Iancu
> OpenSIPS Event - expo, conf, social, bootcamp
> 2 - 4 February 2011, ITExpo, Miami, USA
>
> www.voice-system.ro
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Not enough free memory
Hi Ovidiu, I tried enabling memory manager debug but doing so causes it to somewhat crash (no error logs but opensips stops running) with just a single call. Here is the link to download the logs i fetched with memory manager debug enabled if this would help: http://www.2shared.com/file/npidL9pz/opensips.html Thanks! Regards, Ronald On Fri, Dec 17, 2010 at 1:56 AM, Ovidiu Sas wrote: > Here's how to investigate/debug memory issues: > http://www.opensips.org/Resources/DocsTsMem > > Regards, > Ovidiu Sas > > On Thu, Dec 16, 2010 at 12:44 PM, Ronald Cepres > wrote: > > Hi to all, > > If I run OpenSIPS (1.6.3 ) for a long time while calls are coming in, it > > suddenly stops with the following sample logs: > > Dec 16 12:26:43 [12114] ERROR:core:new_avp: no more shm mem > > Dec 16 12:26:43 [12114] ERROR:core:add_avp: Failed to create new avp > > structure > > Dec 16 12:26:43 [12114] ERROR:avpops:db_query_avp: unable to add avp > > Dec 16 12:26:43 [12103] ERROR:core:new_avp: no more shm mem > > Dec 16 12:26:43 [12103] ERROR:core:add_avp: Failed to create new avp > > structure > > Dec 16 12:26:43 [12103] ERROR:avpops:db_query_avp: unable to add avp > > Dec 16 12:26:43 [12106] WARNING:core:fm_malloc: Not enough free memory, > will > > atempt defragmenation > > Dec 16 12:26:43 [12106] WARNING:core:fm_malloc: Not enough free memory, > will > > atempt defragmenation > > Dec 16 12:26:43 [12106] ERROR:dialog:dlg_add_leg_info: no more shm mem > > Dec 16 12:26:43 [12106] ERROR:dialog:init_leg_info: dlg_add_leg_info > failed > > Dec 16 12:26:43 [12106] ERROR:dialog:push_reply_in_dialog: could not add > > further info to the dialog > > Dec 16 12:26:43 [12105] WARNING:core:fm_malloc: Not enough free memory, > will > > atempt defragmenation > > Dec 16 12:26:43 [12105] ERROR:core:new_avp: no more shm mem > > Dec 16 12:26:43 [12105] ERROR:core:add_avp: Failed to create new avp > > structure > > Dec 16 12:26:43 [12102] WARNING:core:fm_malloc: Not enough free memory, > will > > atempt defragmenation > > Dec 16 12:26:43 [12105] ERROR:avpops:db_query_avp: unable to add avp > > Dec 16 12:26:43 [12102] ERROR:dialog:build_new_dlg: no more shm mem (277) > > Dec 16 12:26:43 [12105] WARNING:core:fm_malloc: Not enough free memory, > will > > atempt defragmenation > > Dec 16 12:26:43 [12105] ERROR:tm:new_t: out of mem > > Dec 16 12:26:43 [12105] ERROR:tm:t_newtran: new_t failed > > Dec 16 12:26:43 [12117] WARNING:core:fm_malloc: Not enough free memory, > will > > atempt defragmenation > > Dec 16 12:26:43 [12102] ERROR:dialog:dlg_create_dialog: failed to create > new > > dialog > > Dec 16 12:26:43 [12102] ERROR:dialog:set_dlg_profile: dialog was not yet > > created - script error > > Dec 16 12:26:43 [12102] ERROR:dialog:w_set_dlg_profile: failed to set > > profile > > Is there a way that memory leak would happen from a mis-configured > routing > > script? If so, how do I trace the part of the routing script that causes > the > > leak? > > Thanks! > > ___ > > Users mailing list > > Users@lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Not enough free memory
Hi to all, If I run OpenSIPS (1.6.3 ) for a long time while calls are coming in, it suddenly stops with the following sample logs: Dec 16 12:26:43 [12114] ERROR:core:new_avp: no more shm mem Dec 16 12:26:43 [12114] ERROR:core:add_avp: Failed to create new avp structure Dec 16 12:26:43 [12114] ERROR:avpops:db_query_avp: unable to add avp Dec 16 12:26:43 [12103] ERROR:core:new_avp: no more shm mem Dec 16 12:26:43 [12103] ERROR:core:add_avp: Failed to create new avp structure Dec 16 12:26:43 [12103] ERROR:avpops:db_query_avp: unable to add avp Dec 16 12:26:43 [12106] WARNING:core:fm_malloc: Not enough free memory, will atempt defragmenation Dec 16 12:26:43 [12106] WARNING:core:fm_malloc: Not enough free memory, will atempt defragmenation Dec 16 12:26:43 [12106] ERROR:dialog:dlg_add_leg_info: no more shm mem Dec 16 12:26:43 [12106] ERROR:dialog:init_leg_info: dlg_add_leg_info failed Dec 16 12:26:43 [12106] ERROR:dialog:push_reply_in_dialog: could not add further info to the dialog Dec 16 12:26:43 [12105] WARNING:core:fm_malloc: Not enough free memory, will atempt defragmenation Dec 16 12:26:43 [12105] ERROR:core:new_avp: no more shm mem Dec 16 12:26:43 [12105] ERROR:core:add_avp: Failed to create new avp structure Dec 16 12:26:43 [12102] WARNING:core:fm_malloc: Not enough free memory, will atempt defragmenation Dec 16 12:26:43 [12105] ERROR:avpops:db_query_avp: unable to add avp Dec 16 12:26:43 [12102] ERROR:dialog:build_new_dlg: no more shm mem (277) Dec 16 12:26:43 [12105] WARNING:core:fm_malloc: Not enough free memory, will atempt defragmenation Dec 16 12:26:43 [12105] ERROR:tm:new_t: out of mem Dec 16 12:26:43 [12105] ERROR:tm:t_newtran: new_t failed Dec 16 12:26:43 [12117] WARNING:core:fm_malloc: Not enough free memory, will atempt defragmenation Dec 16 12:26:43 [12102] ERROR:dialog:dlg_create_dialog: failed to create new dialog Dec 16 12:26:43 [12102] ERROR:dialog:set_dlg_profile: dialog was not yet created - script error Dec 16 12:26:43 [12102] ERROR:dialog:w_set_dlg_profile: failed to set profile Is there a way that memory leak would happen from a mis-configured routing script? If so, how do I trace the part of the routing script that causes the leak? Thanks! ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Drouting module parameters not found
Not actually from SVN but from the website. Here is the actual download
link:
http://opensips.org/pub/opensips/latest/src/opensips-1.6.3-tls_src.tar.gz
Btw, I have also tried recompiling the source code successfully. However,
the previously mentioned errors when running OpenSIPS itself remains the
same.
On Mon, Dec 13, 2010 at 9:25 PM, Bogdan-Andrei Iancu wrote:
> Hi Ronald,
>
> Are you sure you have the latest 1.6.3 sources from SVN ?
>
> Regards,
> Bogdan
>
> Ronald Cepres wrote:
>
>> Hi to all,
>>
>> I have a problem about the drouting module. Here is a snippet of my script
>> configuration:
>>
>> ...
>> loadmodule "drouting.so"
>> modparam("drouting", "db_url", "mysql://user:p...@localhost/opensips")
>> modparam("drouting", "gw_id_avp", "$avp(s:gw_id)")
>> modparam("drouting", "rule_id_avp", "$avp(s:rule_id)")
>> ...
>>
>> Starting OpenSIPS gives me these errors:
>>
>> ERROR:core:set_mod_param_regex: parameter not found in module
>>
>> CRITICAL:core:yyerror: parse error in config file, line 111, column 33-34:
>> Parameter not found in module - can't set
>> ERROR:core:set_mod_param_regex: parameter not found in
>> module
>> CRITICAL:core:yyerror: parse error in config file, line 112, column 35-36:
>> Parameter not found in module - can't set
>>
>> Is there a way to fix this problem? I would appreciate any kind of help.
>> Thanks!
>>
>> By the way, I am using the OpenSIPS 1.6.3 release version.
>>
>>
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
> --
> Bogdan-Andrei Iancu
> OpenSIPS Bootcamp
> 15 - 19 November 2010, Edison, New Jersey, USA
> www.voice-system.ro
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Drouting module parameters not found
Hi to all,
I have a problem about the drouting module. Here is a snippet of my script
configuration:
...
loadmodule "drouting.so"
modparam("drouting", "db_url", "mysql://user:p...@localhost/opensips")
modparam("drouting", "gw_id_avp", "$avp(s:gw_id)")
modparam("drouting", "rule_id_avp", "$avp(s:rule_id)")
...
Starting OpenSIPS gives me these errors:
ERROR:core:set_mod_param_regex: parameter not found in module
CRITICAL:core:yyerror: parse error in config file, line 111, column 33-34:
Parameter not found in module - can't set
ERROR:core:set_mod_param_regex: parameter not found in module
CRITICAL:core:yyerror: parse error in config file, line 112, column 35-36:
Parameter not found in module - can't set
Is there a way to fix this problem? I would appreciate any kind of help.
Thanks!
By the way, I am using the OpenSIPS 1.6.3 release version.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
