from:"Yuri Ritvin"

Re: [OpenSIPS-Users] API Question

2021-02-10 Thread Yuri Ritvin

Please check this out:
https://blog.opensips.org/2020/06/11/calls-management-using-the-new-call-api-tool/
https://github.com/OpenSIPS/call-api


On Wed, Feb 10, 2021 at 11:53 AM  wrote:

> Send Users mailing list submissions to
> users@lists.opensips.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> or, via email, send a message with subject or body 'help' to
> users-requ...@lists.opensips.org
>
> You can reach the person managing the list at
> users-ow...@lists.opensips.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Users digest..."
>
>
> Today's Topics:
>
>1. Re: Retrieving parameters from file (Gerwin van de Steeg)
>2. Re: Retrieving parameters from file (Johan De Clercq)
>3. API Question (Alexander Perkins)
>4. Re: API Question (Gregory Massel)
>
>
> --
>
> Message: 1
> Date: Wed, 10 Feb 2021 17:26:10 +1300
> From: Gerwin van de Steeg 
> To: OpenSIPS users mailling list 
> Subject: Re: [OpenSIPS-Users] Retrieving parameters from file
> Message-ID:
> <
> cajs0f15lunxefronrpfqqzbudhjnnwyrvy8avl6scsq9t4a...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Or you could use a sane and legible templating language.  I like the look
> of consul-template, but there are many others out there as the article
> suggests.. like Jinja2 or ERB.
>
> On Wed, 10 Feb 2021 at 00:00, Johan De Clercq  wrote:
>
> > Interesting, speaking for myself, it is absolutely team that I add m4
> > support.
> >
> >
> > Op di 9 feb. 2021 om 11:35 schreef Liviu Chircu :
> >
> >> On 09.02.2021 05:53, Dinesh Krishnamurthy via Users wrote:
> >> > For example i would need to keep the IP Address/Port of the API
> >> > Gateway which i communicate via rest_get without hardcoding as they
> >> > would change based on the environment i am working with i.e.. staging,
> >> > dev or production
> >> >
> >> > Please advise the way to do this.
> >>
> >> Hi,
> >>
> >> Sounds to me like your opensips.cfg file needs templating. If you are
> >> using a 3.0 or newer OpenSIPS, this process is even further simplified,
> >> as OpenSIPS natively integrates with any preprocessor that's out there.
> >> See this guide [1] for more details.
> >>
> >> Regards,
> >>
> >> [1]: https://www.opensips.org/Documentation/Templating-Config-Files-3-2
> >>
> >> --
> >> Liviu Chircu
> >> www.twitter.com/liviuchircu | www.opensips-solutions.com
> >>
> >>
> >> ___
> >> 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
> >
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.opensips.org/pipermail/users/attachments/20210210/aa3664bb/attachment-0001.html
> >
>
> --
>
> Message: 2
> Date: Wed, 10 Feb 2021 07:00:43 +
> From: Johan De Clercq 
> To: OpenSIPS users mailling list 
> Subject: Re: [OpenSIPS-Users] Retrieving parameters from file
> Message-ID:
> <
> pr1pr06mb46834dc07bb3cc6152868e08a7...@pr1pr06mb4683.eurprd06.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> Gerwin, I will have a look.
>
> Outlook voor iOS downloaden
> 
> Van: Users  namens Gerwin van de Steeg <
> gerwin.van.de.st...@vadacom.com>
> Verzonden: Wednesday, February 10, 2021 5:26:10 AM
> Aan: OpenSIPS users mailling list 
> Onderwerp: Re: [OpenSIPS-Users] Retrieving parameters from file
>
> Or you could use a sane and legible templating language.  I like the look
> of consul-template, but there are many others out there as the article
> suggests.. like Jinja2 or ERB.
>
> On Wed, 10 Feb 2021 at 00:00, Johan De Clercq  jo...@democon.be>> wrote:
> Interesting, speaking for myself, it is absolutely team that I add m4
> support.
>
>
> Op di 9 feb. 2021 om 11:35 schreef Liviu Chircu  >:
> On 09.02.2021 05:53, Dinesh Krishnamurthy via Users wrote:
> > For example i would need to keep the IP Address/Port of the API
> > Gateway which i communicate via rest_get without hardcoding as they
> > would change based on the environment i am working with i.e.. staging,
> > dev or production
> >
> > Please advise the way to do this.
>
> Hi,
>
> Sounds to me like your opensips.cfg file needs templating. If you are
> using a 3.0 or newer OpenSIPS, this process is even further simplified,
> as OpenSIPS natively integrates with any preprocessor that's out there.
> See this guide [1] for more details.
>
> Regards,
>
> [1]: https://www.opensips.org/Documentation/Templating-Config-Files-3-2
>
> --
> Liviu Chircu
>

Re: [OpenSIPS-Users] Users Digest, Vol 138, Issue 48

2020-01-21 Thread Yuri Ritvin

Another approach you may consider is to drop inbound OPTIONS packets by
means of iptables (if you'd prefer not to touch the OpenSIPS configuration).
Just run from CLI the command like this:
iptables -I INPUT -p udp -m udp --dport 5060 -m string --string "OPTIONS
sip:" --algo bm --to 65535 -j DROP

And then delete this rule when not needed anymore:
iptables -D INPUT -p udp -m udp --dport 5060 -m string --string "OPTIONS
sip:" --algo bm --to 65535 -j DROP

Of course, the parameters will be pertinent to your specific implementation
- protocol, port and optionally source IP(s).


On Tue, Jan 21, 2020 at 8:09 AM  wrote:

> Send Users mailing list submissions to
> users@lists.opensips.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> or, via email, send a message with subject or body 'help' to
> users-requ...@lists.opensips.org
>
> You can reach the person managing the list at
> users-ow...@lists.opensips.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Users digest..."
>
>
> Today's Topics:
>
>1. Re: opensips - graceful maintenance mode? (solarmon)
>2. Re: opensips - graceful maintenance mode? (Liviu Chircu)
>3. Re: opensips - graceful maintenance mode? (solarmon)
>4. Re: opensips - graceful maintenance mode? (Liviu Chircu)
>5. Re: opensips - graceful maintenance mode? (solarmon)
>
>
> --
>
> Message: 1
> Date: Tue, 21 Jan 2020 12:21:56 +
> From: solarmon 
> To: OpenSIPS users mailling list 
> Subject: Re: [OpenSIPS-Users] opensips - graceful maintenance mode?
> Message-ID:
>  go-anxyggspzxtg9bjmsutaf1-c3jc...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Liviu,
>
> Apologies, I should be more clear.
>
> The dispatcher endpoints that I have configured are used for routing the
> SIP calls to. They are also the endpoints that we are receiving SIP calls
> from.
>
> I understand that opensips are sending SIP Options pings to these
> endpoints. And these endpoints are sending SIP Options pings to opensips
> and getting a response.
>
> I would like to understand if I set these endpoints to 'inactive' whether
> that means opensips will stop responding to SIP Options pings from that
> particular endpoint.
>
> However, now I have checked our opensips.cfg script (that was created for
> us) it looks like it has been hardcoded in:
>
> route[handle_pings]
> {
> # keepalive notifies replied ok
> if ( is_method("NOTIFY|OPTIONS") && !has_totag() && $rU==NULL) {
> send_reply("200", "OK");
> exit;
> }
> }
>
>
>
>
> On Tue, 21 Jan 2020 at 11:58, Liviu Chircu  wrote:
>
> > On 21.01.2020 13:47, solarmon wrote:
> > >
> > > So to be clear, I cannot use the dispatcher endpoint method to stop
> > > responding to SIP Options pings? If I can do that, then that is the
> > > equivalent - since our platform would see opensips as unhealthy and
> > > not send calls to it.
> >
> > What do you mean by "dispatcher endpoint method"?  Also, the dispatcher
> > module
> > ORIGINATES pings to its destinations, it does not RESPOND to them.
> > Maybe I'm
> > not on par with your terminology here :)
> >
> > --
> > Liviu Chircu
> > www.twitter.com/liviuchircu | www.opensips-solutions.com
> >
> > OpenSIPS Summit, Amsterdam, May 2020
> >www.opensips.org/events
> > OpenSIPS Bootcamp, Miami, March 2020
> >www.opensips.org/training
> >
> >
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.opensips.org/pipermail/users/attachments/20200121/7e426355/attachment-0001.html
> >
>
> --
>
> Message: 2
> Date: Tue, 21 Jan 2020 14:28:20 +0200
> From: Liviu Chircu 
> To: OpenSIPS users mailling list 
> Subject: Re: [OpenSIPS-Users] opensips - graceful maintenance mode?
> Message-ID: <6377cb24-0509-1435-bffa-888c5f282...@opensips.org>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 21.01.2020 14:21, solarmon wrote:
> > However, now I have checked our opensips.cfg script (that was created
> > for us) it looks like it has been hardcoded in:
> >
> > route[handle_pings]
> > {
> > # keepalive notifies replied ok
> > if ( is_method("NOTIFY|OPTIONS") && !has_totag() && $rU==NULL) {
> > send_reply("200", "OK");
> > exit;
> > }
> > }
> >
> Exactly!  That's where the ping responses are generated.  You should
> hook the "drain mode"
> login somewhere before that block.
>
> Best regards,
>
> --
> Liviu Chircu
> www.twitter.com/liviuchircu | www.opensips-solutions.com
>
> OpenSIPS Summit, Amsterdam, May 2020
>

Re: [OpenSIPS-Users] Users Digest, Vol 131, Issue 82

2019-06-28 Thread Yuri Ritvin

You may try this:
https://www.opensips.org/Documentation/Script-Tran-2-4#ip.resolve


On Fri, Jun 28, 2019 at 12:00 PM  wrote:

> Send Users mailing list submissions to
> users@lists.opensips.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> or, via email, send a message with subject or body 'help' to
> users-requ...@lists.opensips.org
>
> You can reach the person managing the list at
> users-ow...@lists.opensips.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Users digest..."
>
>
> Today's Topics:
>
>1. Re: Feature request - pseudo-variable for destination IP
>   address (Ben Newlin)
>
>
> --
>
> Message: 1
> Date: Fri, 28 Jun 2019 15:38:01 +
> From: Ben Newlin 
> To: OpenSIPS users mailling list 
> Subject: Re: [OpenSIPS-Users] Feature request - pseudo-variable for
> destination IP address
> Message-ID: <9d325f82-e29f-4e7a-98f7-40e229d74...@genesys.com>
> Content-Type: text/plain; charset=UTF-8
>
> As far as I know, the equivalent variable to $si on the destination side
> is either $dd, which may not always be set, or $rd. Those are not
> guaranteed to be IP addresses, however. If DNS is being used, I don't
> believe OpenSIPS provides the results of the DNS lookup to the script in
> any variable, so I don't think there is a way to find the actual IP aside
> from doing your own DNS lookup (or possibly using the dns_cache module and
> snooping the cache, but I have had issues with this module in the past.)
>
> Ben Newlin
>
> On 6/28/19, 10:16 AM, "Users on behalf of rob.d...@telus.net" <
> users-boun...@lists.opensips.org on behalf of rob.d...@telus.net> wrote:
>
> Unfortunately the address of the interface where the request was
> receeived is private. I am using 1 to 1 NAT.
>
> - Original Message -
> From: "Ovidiu Sas" 
> To: "OpenSIPS users mailling list" 
> Sent: Thursday, June 27, 2019 3:31:34 PM
> Subject: Re: [OpenSIPS-Users] Feature request - pseudo-variable for
> destination IP address
>
> Check out the $Ri pvar:
> https://www.opensips.org/Documentation/Script-CoreVar-3-0#toc78
>
> -ovidiu
>
> On Thu, Jun 27, 2019 at 6:23 PM rob.d...@telus.net 
> wrote:
> >
> > I was looking for something similar to the $si PV but for the
> destination IP address. Either it doesn't exist or I am blind. I can't find
> things in the refrigerator either.
> >
> > The motivation.
> >
> > I have a working instance of Opensips with a basic residential
> configuration. I extended it to allow calling UAs on the LAN from the
> outside. It is a typical residential LAN without a fixed IP address.
> Dynamic DNS is working for me. I read the tutorial about Opensips behind
> NAT. Following the recommendations there I was able to setup rtpproxy, the
> advertised address and an alias for my Opensips. Initial testing using a
> softphone on a laptop using either WiFi or a mobile phone tethered to the
> laptop worked well. However it seems that some UAs will not accept a domain
> name in the SDP connection. The UAs that failed could be made to work by
> coding in an IP address. This is not a satisfactory solution because the
> router's address may chaange. There is probably some convoluted way to
> import the needed address into the script.  A pseudo-variable representing
> the destination IP address of the received INVITE or 200 OK could then be
> passed as the advertised address to the rtpproxy module.
> >
> > Thank you for having a look.
> > Rob
> >
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
>
> ___
> 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
>
>
>
>
> --
>
> Subject: Digest Footer
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> --
>
> End of Users Digest, Vol 131, Issue 82
> **
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] "477 Send failed" processing

2016-05-04 Thread Yuri Ritvin

Thanks a lot, Bogdan.
The flag has been implemented and works as expected.

Best regards,
Yuri

On Wed, May 4, 2016 at 4:26 AM, Bogdan-Andrei Iancu <bog...@opensips.org>
wrote:

> Hi Yuri,
>
> That 477 is a result of a failed send (opensips was not able to send out
> the requests) ; failure route is triggered by negative replies after the
> request was sent out (this is why you do not see it there).
>
> But, if you use the 0x02 flag in t_relay()
> http://www.opensips.org/html/docs/modules/2.2.x/tm.html#id294529
>
> you can see the failure in the script (t_relay() will return with negative
> code) and you can do your own replying there.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
> On 04.05.2016 06:19, Yuri Ritvin wrote:
>
> Hi,
> I'm looking into a way to convert a response code "477 Send failed" into
> "404".
> It looks like the failure_route doesn't take care of the "477" cases (at
> least in ver.2.2).
> Is it by design or something is missing in the picture ?
>
> Thank you.
>
>
> ___
> 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] "477 Send failed" processing

2016-05-03 Thread Yuri Ritvin

Hi,
I'm looking into a way to convert a response code "477 Send failed" into
"404".
It looks like the failure_route doesn't take care of the "477" cases (at
least in ver.2.2).
Is it by design or something is missing in the picture ?

Thank you.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] SIPTRACE module behavior in 2.2

2016-04-26 Thread Yuri Ritvin

The problem is solved.
The fix for the bug is 3c6b693
<https://github.com/OpenSIPS/opensips/commit/3c6b6930d615adb978dd2779b6cd4054c3bc49df>
( dbdc46c
<https://github.com/OpenSIPS/opensips/commit/dbdc46c994c69b43bb124a397056268ddaf2f543>
for 2.2 branch).

Many thanks to Ionut !

On Tue, Apr 12, 2016 at 6:29 PM, Yuri Ritvin <yuri.rit...@gmail.com> wrote:

> It looks like some information is missing in the SIPTRACE module
> documentation for OpenSIPS 2.2, or apparently it bears a bug. With the
> given example of the configuration the log file displays these messages:
> ERROR:siptrace:save_siptrace: invalid trace info
> ERROR:siptrace:trace_msg_out: failed to save siptrace
>
> And this is the config snippet:
>
>  SIPTRACE module
> loadmodule "siptrace.so"
> modparam("siptrace", "trace_id",
> "[tid]uri=mysql://opensips:opensipsrw@dbserver/opensips;table=sip_trace;")
> modparam("siptrace", "trace_on", 1)
>
> 
>
> if (method==INVITE && !has_totag()) {
> $var(user)="os...@thisnetwork.com";
> $var(trace_id) = "tid";
> sip_trace("$var(trace_id)", "d", "$var(user)");
> }
>
>
> Then at some particular scenario SIPTRACE module crashes the OpenSIPS 2.2
> application:
> #0  save_siptrace (info=0x7f6878bf6b58, msg=,
> vals=0x7f68722bcf80, keys=0x7f68722bd180) at siptrace.c:878
> hash = 
> it = 
> #1  0x7f68720b5415 in trace_onreply_out (t=,
> type=, ps=0x7fff0548a820) at siptrace.c:1982
> faked = 
> fromip_buff = "udp1XX.2X.XXX.185", '\000' 
> toip_buff = "udp1XX.2X.XXX.78", '\000' 
> msg = 0x7f6878c00740
> to_ip = {af = 2, len = 4, u = {addrl = {1310254956, 0}, addr32 =
> {1310254956, 0, 0, 0}, addr16 = {59244, 19992, 0, 0, 0, 0, 0, 0}, addr =
> "l\347\030N", '\000' }}
> len = 3
> statusbuf = "408\000\001\000\000"
> sbuf = 
> dst = 
> __FUNCTION__ = "trace_onreply_out"
> #2  0x7f68748789a1 in run_trans_callbacks (type=128,
> trans=0x7f6878bfecc8, req=, rpl=,
> code=) at t_hooks.c:209
> params = {req = 0x7f6878c00740, rpl = 0x, code =
> 408, param = 0x7f6878bfeb28, extra1 = 0x7fff0548a9a0, extra2 =
> 0x7f6878bfede0}
> cbp = 0x7f6878bfeb18
> backup = 0x7816c0
> trans_backup = 0x7f6878bfecc8
> __FUNCTION__ = "run_trans_callbacks"
> #3  0x7f6874878b00 in run_trans_callbacks_locked (type= optimized out>, trans=0x7f6878bfecc8, req=, rpl= optimized out>, code=)
> at t_hooks.c:262
> No locals.
> #4  0x7f68748851b1 in relay_reply (t=0x7f6878bfecc8, p_msg= optimized out>, branch=, msg_status= out>, cancel_bitmap=0x7fff0548aa7c)
> at t_reply.c:1255
> relay = 0
> save_clone = 0
> buf = 0x7f6888aa78a8 "SIP/2.0 408 Request Timeout\r\nVia:
> SIP/2.0/UDP
> 1XX.2X.XXX.78:8408;received=1XX.2X.XXX.78;branch=z9hG4bK-524287-1---af6608797b55630d;rport=8408\r\nTo:
> <sip:testingsubscriber1...@sip.thisnetwork.com>;tag=3b8d"...
> res_len = 412
> relayed_code = 408
> relayed_msg = 0x
> bm = {to_tag_val = {
> s = 0x7f6888aa796c
> "3b8d6d10a54b0752c937c18d274bef37-402e\r\nFrom: \"TestingSubscriber1001\"<
> sip:testingsubscriber1...@sip.thisnetwork.com>;tag=735c442d\r\nCall-ID:
> PKSLf7Smdwyk-hULVsGkKg..\r\nCSeq: 2 INVITE\r\nServer: SBC-185\r\nConte"...,
> len = 37}}
> totag_retr = 0
> reply_status = RPS_COMPLETED
> uas_rb = 0x7f6878bfedc8
> cb_s = {
>   s = 0x7f6888aa78a8 "SIP/2.0 408 Request Timeout\r\nVia:
> SIP/2.0/UDP
> 1XX.2X.XXX.78:8408;received=1XX.2X.XXX.78;branch=z9hG4bK-524287-1---af6608797b55630d;rport=8408\r\nTo:
> <sip:testingsubscriber1...@sip.thisnetwork.com>;tag=3b8d"..., len = 412}
> text = {s = 0x50daf3 "Request Timeout", len = 15}
> __FUNCTION__ = "relay_reply"
> #5  0x7f68746e in fake_reply (ticks=70, set=)
> at timer.c:260
> cancel_bitmap = 0
> do_cancel_branch = 
> reply_status = 
> #6  final_response_handler (ticks=70, set=) at
> timer.c:391
> old_ctx = 0x0
> my_ctx = 0x7f6888aa7f08
> r_buf = 0x7f6878bfeea0
> ---Type  to continue, or q  to quit---
> t = 0x7f6878bfecc8
> #7  timer_routine (ticks=70, set=) at timer.c:1066
> tl = 0x7f6878bfef18
> tmp_tl = 0x0
> id = 
>

[OpenSIPS-Users] SIPTRACE module behavior in 2.2

2016-04-12 Thread Yuri Ritvin

It looks like some information is missing in the SIPTRACE module
documentation for OpenSIPS 2.2, or apparently it bears a bug. With the
given example of the configuration the log file displays these messages:
ERROR:siptrace:save_siptrace: invalid trace info
ERROR:siptrace:trace_msg_out: failed to save siptrace

And this is the config snippet:

 SIPTRACE module
loadmodule "siptrace.so"
modparam("siptrace", "trace_id",
"[tid]uri=mysql://opensips:opensipsrw@dbserver/opensips;table=sip_trace;")
modparam("siptrace", "trace_on", 1)



if (method==INVITE && !has_totag()) {
$var(user)="os...@thisnetwork.com";
$var(trace_id) = "tid";
sip_trace("$var(trace_id)", "d", "$var(user)");
}


Then at some particular scenario SIPTRACE module crashes the OpenSIPS 2.2
application:
#0  save_siptrace (info=0x7f6878bf6b58, msg=,
vals=0x7f68722bcf80, keys=0x7f68722bd180) at siptrace.c:878
hash = 
it = 
#1  0x7f68720b5415 in trace_onreply_out (t=,
type=, ps=0x7fff0548a820) at siptrace.c:1982
faked = 
fromip_buff = "udp1XX.2X.XXX.185", '\000' 
toip_buff = "udp1XX.2X.XXX.78", '\000' 
msg = 0x7f6878c00740
to_ip = {af = 2, len = 4, u = {addrl = {1310254956, 0}, addr32 =
{1310254956, 0, 0, 0}, addr16 = {59244, 19992, 0, 0, 0, 0, 0, 0}, addr =
"l\347\030N", '\000' }}
len = 3
statusbuf = "408\000\001\000\000"
sbuf = 
dst = 
__FUNCTION__ = "trace_onreply_out"
#2  0x7f68748789a1 in run_trans_callbacks (type=128,
trans=0x7f6878bfecc8, req=, rpl=,
code=) at t_hooks.c:209
params = {req = 0x7f6878c00740, rpl = 0x, code =
408, param = 0x7f6878bfeb28, extra1 = 0x7fff0548a9a0, extra2 =
0x7f6878bfede0}
cbp = 0x7f6878bfeb18
backup = 0x7816c0
trans_backup = 0x7f6878bfecc8
__FUNCTION__ = "run_trans_callbacks"
#3  0x7f6874878b00 in run_trans_callbacks_locked (type=, trans=0x7f6878bfecc8, req=, rpl=, code=)
at t_hooks.c:262
No locals.
#4  0x7f68748851b1 in relay_reply (t=0x7f6878bfecc8, p_msg=, branch=, msg_status=, cancel_bitmap=0x7fff0548aa7c)
at t_reply.c:1255
relay = 0
save_clone = 0
buf = 0x7f6888aa78a8 "SIP/2.0 408 Request Timeout\r\nVia:
SIP/2.0/UDP
1XX.2X.XXX.78:8408;received=1XX.2X.XXX.78;branch=z9hG4bK-524287-1---af6608797b55630d;rport=8408\r\nTo:
;tag=3b8d"...
res_len = 412
relayed_code = 408
relayed_msg = 0x
bm = {to_tag_val = {
s = 0x7f6888aa796c
"3b8d6d10a54b0752c937c18d274bef37-402e\r\nFrom: \"TestingSubscriber1001\"<
sip:testingsubscriber1...@sip.thisnetwork.com>;tag=735c442d\r\nCall-ID:
PKSLf7Smdwyk-hULVsGkKg..\r\nCSeq: 2 INVITE\r\nServer: SBC-185\r\nConte"...,
len = 37}}
totag_retr = 0
reply_status = RPS_COMPLETED
uas_rb = 0x7f6878bfedc8
cb_s = {
  s = 0x7f6888aa78a8 "SIP/2.0 408 Request Timeout\r\nVia:
SIP/2.0/UDP
1XX.2X.XXX.78:8408;received=1XX.2X.XXX.78;branch=z9hG4bK-524287-1---af6608797b55630d;rport=8408\r\nTo:
;tag=3b8d"..., len = 412}
text = {s = 0x50daf3 "Request Timeout", len = 15}
__FUNCTION__ = "relay_reply"
#5  0x7f68746e in fake_reply (ticks=70, set=)
at timer.c:260
cancel_bitmap = 0
do_cancel_branch = 
reply_status = 
#6  final_response_handler (ticks=70, set=) at
timer.c:391
old_ctx = 0x0
my_ctx = 0x7f6888aa7f08
r_buf = 0x7f6878bfeea0
---Type  to continue, or q  to quit---
t = 0x7f6878bfecc8
#7  timer_routine (ticks=70, set=) at timer.c:1066
tl = 0x7f6878bfef18
tmp_tl = 0x0
id = 
__FUNCTION__ = "timer_routine"
#8  0x0047e28b in handle_timer_job () at timer.c:632
t = 0x7f687890d760
l = 
__FUNCTION__ = "handle_timer_job"
#9  0x004ed64d in handle_io (fm=0x7f6888a9c388, idx=1,
event_type=) at net/net_tcp_proc.c:117
ret = 0
n = 
con = 
s = 
rw = 
resp = 
response = {140733282036968, 140086962256117}
__FUNCTION__ = "handle_io"
#10 0x004ee140 in io_wait_loop_epoll (repeat=0, t=2, h=) at ./io_wait_loop.h:221
n = 1
r = 1
e = 0x7f6888a9c388
ret = 1
#11 0x004ef407 in tcp_worker_proc (unix_sock=)
at net/net_tcp_proc.c:312
__FUNCTION__ = "tcp_worker_proc"
#12 0x004eb31d in tcp_start_processes (chd_rank=0x7653c8,
startup_done=0x0) at net/net_tcp.c:1758
r = 
reader_fd = {92, 94}
pid = 0
si = 
load_p = 0x7f6878bc58c8
__FUNCTION__ = "tcp_start_processes"
#13 0x0042f4af in main_loop (argc=,
argv=) at main.c:677
startup_done = 0x0
chd_rank = 44
#14 main (argc=, argv=) at
main.c:1252
cfg_stream = 
c = 
r

[OpenSIPS-Users] CLUSTERER and PROTO_BIN modules in ver.2.2

2016-03-25 Thread Yuri Ritvin

Since introduction of the CLUSTERER and PROTO_BIN modules the previous
approach of contacts / dialogues replication between OpenSIPS servers has
rendered obsolete. The addition of the actual use case description of the
aforementioned modules (as a replacement of the BIN_LISTEN directive) will
be highly beneficial , particularly a DB table "clusterer" population
method.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Opensips 1.9.1 stopped writing into log

2013-11-10 Thread Yuri Ritvin

I have installed Opensips 1.9.1 which works fine, but recently it stopped
writing into the opensips.log file - just in the middle.
Enough space, memory, CPU resources. Something triggered this issue.
I tried to revive logging by restarting rsyslog and opensips processes, but
it doesn't help. Reboot didn't change this phenomenon too.
Any ideas / hints on this subject   ?

Thank you,
Yuri
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] API Question

Re: [OpenSIPS-Users] Users Digest, Vol 138, Issue 48

Re: [OpenSIPS-Users] Users Digest, Vol 131, Issue 82

Re: [OpenSIPS-Users] "477 Send failed" processing

[OpenSIPS-Users] "477 Send failed" processing

Re: [OpenSIPS-Users] SIPTRACE module behavior in 2.2

[OpenSIPS-Users] SIPTRACE module behavior in 2.2

[OpenSIPS-Users] CLUSTERER and PROTO_BIN modules in ver.2.2

[OpenSIPS-Users] Opensips 1.9.1 stopped writing into log

9 matches

Site Navigation

Mail list logo

Footer information