[OpenSIPS-Users] Opensips drouting probing

[Denis via Users]

Hello! According to drouting module documentation i am trying to introduce a probing feature to control destination SIP UA access.Almost everything works correct, besides one thing.If i have only one destination, which became inaccessible, Opensips "freezes" a call, i.e. it sends 100 trying (script logging) and after does not sent any code (i expected, that Opensips will sent 408 code in such situation after fr_timeout triggering).Inaccessible destination has "probing" status and i see OPTIONS sent by Opensis to destination. Server:: OpenSIPS (2.2.3 (x86_64/linux)) Thank you for any help. -- С уважением, Денис.Best regards, Denis   

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

Re: [OpenSIPS-Users] Mediaproxy hanging sessions on high load

[Daniel Zanutti]

Adrian

You may be correct, overload can be the problem. But since the call is
already finished, how can I remove from the relay? The final problem is the
relay processing freezing, i need to avoid this.

Thanks

On Thu, Mar 16, 2017 at 10:40 PM, Adrian Georgescu 
wrote:

> Perhaps your virtual machine simply cannot handle the load. The commands
> to close sessions may also be dropped or lost under such environment.
>
> Adrian
>
>
>
> On 16 Mar 2017, at 11:22, Daniel Zanutti  wrote:
>
> Hi Dan
>
> Looks like this problem is only happening on virtual machines, not on
> physical machines. And only while they are on high load.
>
> But i'm not sure about the kernel rule, is there any way to check it?
>
> Please take a look at this case, this Relay will never halt because there
> are more than 3k sessions that will never finish internally (the call has
> already hangup hours ago):
>
> 8 2.2.2.2 2.6.1 44h01'05"
> 112.03kbps 3045
> audio 3045 Halting
>
> Some of these calls:
>
>
>
>
>
>
>
>
>
>
>
>
> 728 *From:* 22@4.4.4.4
> *To:* 3...@sip.aaa.com.br
> [image: unknown agent] [image: HG4000/1.0] 6.6.6.6:55632 2.2.2.2:46640
> 2.2.2.2:46866 7.7.7.7:4170 active G729 audio 21h35'34" 0 0
> 729 *From:* 222@4.4.4.4:5064
> *To:* 3...@sip.aaa.com.br
> [image: TS-v4.6.0-11eW] [image: Agitel GSM Bridge v2.0] 6.6.6.6:34908
> 2.2.2.2:58158 2.2.2.2:54372 7.7.7.7:16846 active G729 audio 16h11'51" 0 0
> 730 *From:* @4.4.4.4
> *To:* 3...@sip.aaa.com.br
> [image: Mediant 2000/v.6.60A.328.003] [image: unknown agent] 6.6.6.6:46324
> 2.2.2.2:50156 2.2.2.2:48182 7.7.7.7:18516 active G729 audio 19h45'38" 0 0
> 731 *From:* 22@4.4.4.4:5061
> *To:* ...@sip.aaa.com.br
> [image: TS-v4.6.0-14b] [image: gsm-gw-3.4.1] 6.6.6.6:54800 2.2.2.2:43998
> 2.2.2.2:46144 7.7.7.7:12360 active G729 audio 19h09'41" 0 0
> 732 *From:* 222@4.4.4.4
> *To:* 3...@sip.aaa.com.br
> [image: Trinit IVR] [image: HG4000/1.0] 6.6.6.6:18854 2.2.2.2:51924
> 2.2.2.2:40512 7.7.7.7:4200 active G729 audio 19h37'59" 0 0
>
> Is there any way to drop these sessions? Maybe using the internal timeout
> system of mediaproxy?
>
> If you could take a look personally, we could negotiate an hourly rate.
>
> Thanks again
>
>
>
> On Thu, Mar 16, 2017 at 10:54 AM, Dan Pascu  wrote:
>
>>
>> One thing came to mind. A case when the relay could get overloaded is if
>> a lot of clients start sessions and only one endpoint sends media. That is
>> the only case where the relay would have to deal with the media traffic
>> itself and having hundreds of such sessions at the same time could overload
>> the relay.
>>
>> The way the relay works is for each call it starts listening on 4 ports
>> (2 for RTP and 2 for RTCP). Each endpoint will send 2 streams (1 RTP one
>> RTCP) and initially the relay will just listen on these ports and when it
>> receives data it learns the endpoint's address. After it learns both
>> endpoint's addresses, it adds a conntrack rule in the kernel to allow the
>> kernel to directly relay the media streams between the endpoints and it
>> will never see a media packet from the endpoints again until the call ends.
>> This allows for very efficient data forwarding because it's done entirely
>> in the kernel with no data being transferred from kernel to user-space and
>> back like traditional solutions. We have seen media relays handling
>> hundreds of calls at a time with 0% CPU load on the relay.
>>
>> So the only thing I can think of causing something like what you describe
>> (even though I'm still not sure what you meant by hanging up sessions), is
>> that somehow this process didn't finish setting up completely and the relay
>> directly receives media streams from hundreds of devices because only one
>> endpoint sends data (or the other endpoint's data gets filtered at some
>> firewall), and because it cannot learn both endpoint's addresses it cannot
>> setup the kernel conntrack rule to move data forwarding to the kernel.
>>
>> On 14 Mar 2017, at 13:38, Dan Pascu wrote:
>>
>> >
>> > On 13 Mar 2017, at 18:58, Daniel Zanutti wrote:
>> >
>> >> Hi guys
>> >>
>> >> I sent this email a few days ago, anyone from Mediaproxy team could
>> take a look? I could debug it, just need some directions on where to look.
>> >
>> > We have never encountered this problem, so I', not sure what to
>> suggest, even more considering that the description is not very clear. What
>> do you mean when you say the relay starts to hang some sessions? That it
>> timeouts on them not having traffic and initiates a BYE for those sessions?
>> Because in the next paragraph you imply that they never timeout.
>> >
>> >>
>> >> Thanks
>> >>
>> >> On Tue, Mar 7, 2017 at 11:10 AM, Daniel Zanutti <
>> daniel.zanu...@gmail.com> wrote:
>> >> I'm using mediaproxy on several installations and have noticed that
>> when the machine is on high load (> 700 sessions), the media-relay process
>> starts to hang some sessions.
>> >>
>> >> These sessions doesn't have any RTP 

Re: [OpenSIPS-Users] Mediaproxy hanging sessions on high load

[Adrian Georgescu]

Perhaps your virtual machine simply cannot handle the load. The commands to 
close sessions may also be dropped or lost under such environment.

Adrian


> On 16 Mar 2017, at 11:22, Daniel Zanutti  wrote:
> 
> Hi Dan
> 
> Looks like this problem is only happening on virtual machines, not on 
> physical machines. And only while they are on high load.
> 
> But i'm not sure about the kernel rule, is there any way to check it?
> 
> Please take a look at this case, this Relay will never halt because there are 
> more than 3k sessions that will never finish internally (the call has already 
> hangup hours ago):
> 
> 8 2.2.2.2 2.6.1   44h01'05"
> 112.03kbps3045
> audio 3045Halting
> 
> Some of these calls:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 728   From: 22@4.4.4.4
> To: 3...@sip.aaa.com.br 
>   6.6.6.6:55632    2.2.2.2:46640 
>    2.2.2.2:46866    
> 7.7.7.7:4170  active  G729audio   21h35'34" 
>   0   0
> 729   From: 222@4.4.4.4:5064
> To: 3...@sip.aaa.com.br 
>   6.6.6.6:34908   2.2.2.2:58158   2.2.2.2:54372   7.7.7.7:16846   
> active  G729audio   16h11'51"   0   0
> 730   From: @4.4.4.4
> To: 3...@sip.aaa.com.br 
>   6.6.6.6:46324    2.2.2.2:50156 
>    2.2.2.2:48182    
> 7.7.7.7:18516    active  G729audio   19h45'38" 
>   0   0
> 731   From: 22@4.4.4.4:5061
> To: ...@sip.aaa.com.br 
>   6.6.6.6:54800   2.2.2.2:43998   2.2.2.2:46144   7.7.7.7:12360   
> active  G729audio   19h09'41"   0   0
> 732   From: 222@4.4.4.4 
> To: 3...@sip.aaa.com.br 
>   6.6.6.6:18854    2.2.2.2:51924 
>    2.2.2.2:40512    
> 7.7.7.7:4200  active  G729audio   19h37'59" 
>   0   0
> 
> Is there any way to drop these sessions? Maybe using the internal timeout 
> system of mediaproxy?
> 
> If you could take a look personally, we could negotiate an hourly rate.
> 
> Thanks again
> 
> 
> 
> On Thu, Mar 16, 2017 at 10:54 AM, Dan Pascu  > wrote:
> 
> One thing came to mind. A case when the relay could get overloaded is if a 
> lot of clients start sessions and only one endpoint sends media. That is the 
> only case where the relay would have to deal with the media traffic itself 
> and having hundreds of such sessions at the same time could overload the 
> relay.
> 
> The way the relay works is for each call it starts listening on 4 ports (2 
> for RTP and 2 for RTCP). Each endpoint will send 2 streams (1 RTP one RTCP) 
> and initially the relay will just listen on these ports and when it receives 
> data it learns the endpoint's address. After it learns both endpoint's 
> addresses, it adds a conntrack rule in the kernel to allow the kernel to 
> directly relay the media streams between the endpoints and it will never see 
> a media packet from the endpoints again until the call ends. This allows for 
> very efficient data forwarding because it's done entirely in the kernel with 
> no data being transferred from kernel to user-space and back like traditional 
> solutions. We have seen media relays handling hundreds of calls at a time 
> with 0% CPU load on the relay.
> 
> So the only thing I can think of causing something like what you describe 
> (even though I'm still not sure what you meant by hanging up sessions), is 
> that somehow this process didn't finish setting up completely and the relay 
> directly receives media streams from hundreds of devices because only one 
> endpoint sends data (or the other endpoint's data gets filtered at some 
> firewall), and because it cannot learn both endpoint's addresses it cannot 
> setup the kernel conntrack rule to move data forwarding to the kernel.
> 
> On 14 Mar 2017, at 13:38, Dan Pascu wrote:
> 
> >
> > On 13 Mar 2017, at 18:58, Daniel Zanutti wrote:
> >
> >> Hi guys
> >>
> >> I sent this email a few days ago, anyone from Mediaproxy team could take a 
> >> look? I could debug it, just need some directions on where to look.
> >
> > We have never encountered this problem, so I', not sure what to suggest, 
> > even more considering that the description is not very clear. What do you 
> > mean when you say the relay starts to hang some sessions? That it timeouts 
> > on them not having traffic and initiates a BYE for those sessions? Because 
> > in the next paragraph you imply that they never timeout.
> >
> >>
> >> Thanks
> >>
> >> On Tue, Mar 7, 2017 at 11:10 AM, Daniel Zanutti  >> > wrote:
> >> I'm using mediaproxy on 

Re: [OpenSIPS-Users] [Release] OpenSIPS 2.3.0 major release, beta version

[Ramachandran, Agalya (Contractor)]

Congrats team for the next mile stone achievement!!!

Regards,
Agalya

-Original Message-
From: Users [mailto:users-boun...@lists.opensips.org] On Behalf Of 
Bogdan-Andrei Iancu
Sent: Thursday, March 16, 2017 3:03 PM
To: users@lists.opensips.org; developensips ; 
n...@lists.opensips.org; busin...@lists.opensips.org
Subject: [OpenSIPS-Users] [Release] OpenSIPS 2.3.0 major release, beta version

Hi All !!

Almost 2 months ago I was posting [1] :  “A new year has arrived, so it is the 
time for a new OpenSIPS major release – for OpenSIPS version 2.3 “.

Well, this just happened !!

I’m happy to announce the beta version of the OpenSIPS 2.3.0 major release. 
Curios to find out more about this release ?
See the philosophy behind this release by reading the overview of OpenSIPS 
2.3.o, code name *integration* :

 http://www.opensips.org/About/Version-Overview-2-3-0

Enjoy it !!!


[1] https://blog.opensips.org/2017/01/12/introducing-opensips-2-3/

--
Bogdan-Andrei Iancu
   OpenSIPS Founder and Developer
   http://www.opensips-solutions.com

OpenSIPS Summit May 2017 Amsterdam
   http://www.opensips.org/events/Summit-2017Amsterdam.html


___
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] [Release] OpenSIPS 2.3.0 major release, beta version

[Bogdan-Andrei Iancu]

Hi All !!

Almost 2 months ago I was posting [1] :  “A new year has arrived, so it 
is the time for a new OpenSIPS major release – for OpenSIPS version 2.3 “.


Well, this just happened !!

I’m happy to announce the beta version of the OpenSIPS 2.3.0 major 
release. Curios to find out more about this release ?
See the philosophy behind this release by reading the overview of 
OpenSIPS 2.3.o, code name *integration* :


http://www.opensips.org/About/Version-Overview-2-3-0

Enjoy it !!!


[1] https://blog.opensips.org/2017/01/12/introducing-opensips-2-3/

--
Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com

OpenSIPS Summit May 2017 Amsterdam
  http://www.opensips.org/events/Summit-2017Amsterdam.html


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

Re: [OpenSIPS-Users] Monitoring Mediaproxy

[Johan De Clercq]

Use sip option messages

On 16 Mar 2017 12:25 AM, "Daniel Zanutti"  wrote:

> How can this be done?
>
> Or do you mean SIP options?
>
> On Wed, Mar 15, 2017 at 5:45 PM, Johan De Clercq  wrote:
>
>> Send options.
>>
>> On 15 Mar 2017 11:48 PM, "Daniel Zanutti" 
>> wrote:
>>
>>> Hi
>>>
>>> What's the best way to check if a mediaproxy is running fine? Monit is
>>> monitoring PID but how can I check the process has is not frozen?
>>>
>>> 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
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Monitoring Mediaproxy

[Daniel Zanutti]

Hi Robert

Acording to mediaproxy website:

MediaProxy is a media relay for RTP/RTCP and UDP streams that works in
tandem with OpenSIPS to provide NAT traversal capability for media streams
from SIP user agents located behind NAT. MediaProxy supports ICE
negotiation by behaving like a TURN relay candidate and the policy can be
controlled from OpenSIPS configuration.

Take a look at its website: http://mediaproxy.ag-projects.com/

Regards

On Thu, Mar 16, 2017 at 11:22 AM, Mundkowsky, Robert 
wrote:

> Sorry, I don't know much about telephony.
>
> Curious what I had wrong?
>
> Is it that only media is sent to Mediaproxy without SIP?
>
> Robert
>
>
> -Original Message-
> From: Users [mailto:users-boun...@lists.opensips.org] On Behalf Of Dan
> Pascu
> Sent: Thursday, March 16, 2017 9:41 AM
> To: OpenSIPS users mailling list 
> Subject: Re: [OpenSIPS-Users] Monitoring Mediaproxy
>
> Lol, what?!?
>
> On 15 Mar 2017, at 23:03, Mundkowsky, Robert wrote:
>
> > SIP Options is used as a “SIP ping”. You likely can have an time event
> trigger route that can send one and then based on that disable/enable
> accordingly.  Hopefully mediaproxy will not respond to the “SIP ping” if
> frozen.
> >
> > Robert
> >
> > From: Users [mailto:users-boun...@lists.opensips.org] On Behalf Of
> Daniel Zanutti
> > Sent: Wednesday, March 15, 2017 4:55 PM
> > To: OpenSIPS users mailling list 
> > Subject: Re: [OpenSIPS-Users] Monitoring Mediaproxy
> >
> > How can this be done?
> >
> > Or do you mean SIP options?
> >
> > On Wed, Mar 15, 2017 at 5:45 PM, Johan De Clercq 
> wrote:
> > Send options.
> >
> > On 15 Mar 2017 11:48 PM, "Daniel Zanutti" 
> wrote:
> > Hi
> >
> > What's the best way to check if a mediaproxy is running fine? Monit is
> monitoring PID but how can I check the process has is not frozen?
> >
> > 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
> >
> >
> >
> > This e-mail and any files transmitted with it may contain privileged or
> confidential information. It is solely for use by the individual for whom
> it is intended, even if addressed incorrectly. If you received this e-mail
> in error, please notify the sender; do not disclose, copy, distribute, or
> take any action in reliance on the contents of this information; and delete
> it from your system. Any other use of this e-mail is prohibited.
> >
> >
> > Thank you for your compliance.
> >
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> --
> Dan
>
>
>
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> 
>
> This e-mail and any files transmitted with it may contain privileged or
> confidential information. It is solely for use by the individual for whom
> it is intended, even if addressed incorrectly. If you received this e-mail
> in error, please notify the sender; do not disclose, copy, distribute, or
> take any action in reliance on the contents of this information; and delete
> it from your system. Any other use of this e-mail is prohibited.
>
>
> Thank you for your compliance.
>
> 
> ___
> 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] Mediaproxy hanging sessions on high load

[Daniel Zanutti]

Hi Dan

Looks like this problem is only happening on virtual machines, not on
physical machines. And only while they are on high load.

But i'm not sure about the kernel rule, is there any way to check it?

Please take a look at this case, this Relay will never halt because there
are more than 3k sessions that will never finish internally (the call has
already hangup hours ago):

8 2.2.2.2 2.6.1 44h01'05"
112.03kbps 3045
audio 3045 Halting

Some of these calls:












728 *From:* 22@4.4.4.4
*To:* 3...@sip.aaa.com.br
[image: unknown agent] [image: HG4000/1.0] 6.6.6.6:55632 2.2.2.2:46640
2.2.2.2:46866 7.7.7.7:4170 active G729 audio 21h35'34" 0 0
729 *From:* 222@4.4.4.4:5064
*To:* 3...@sip.aaa.com.br
[image: TS-v4.6.0-11eW] [image: Agitel GSM Bridge v2.0] 6.6.6.6:34908
2.2.2.2:58158 2.2.2.2:54372 7.7.7.7:16846 active G729 audio 16h11'51" 0 0
730 *From:* @4.4.4.4
*To:* 3...@sip.aaa.com.br
[image: Mediant 2000/v.6.60A.328.003] [image: unknown agent] 6.6.6.6:46324
2.2.2.2:50156 2.2.2.2:48182 7.7.7.7:18516 active G729 audio 19h45'38" 0 0
731 *From:* 22@4.4.4.4:5061
*To:* ...@sip.aaa.com.br
[image: TS-v4.6.0-14b] [image: gsm-gw-3.4.1] 6.6.6.6:54800 2.2.2.2:43998
2.2.2.2:46144 7.7.7.7:12360 active G729 audio 19h09'41" 0 0
732 *From:* 222@4.4.4.4
*To:* 3...@sip.aaa.com.br
[image: Trinit IVR] [image: HG4000/1.0] 6.6.6.6:18854 2.2.2.2:51924
2.2.2.2:40512 7.7.7.7:4200 active G729 audio 19h37'59" 0 0

Is there any way to drop these sessions? Maybe using the internal timeout
system of mediaproxy?

If you could take a look personally, we could negotiate an hourly rate.

Thanks again



On Thu, Mar 16, 2017 at 10:54 AM, Dan Pascu  wrote:

>
> One thing came to mind. A case when the relay could get overloaded is if a
> lot of clients start sessions and only one endpoint sends media. That is
> the only case where the relay would have to deal with the media traffic
> itself and having hundreds of such sessions at the same time could overload
> the relay.
>
> The way the relay works is for each call it starts listening on 4 ports (2
> for RTP and 2 for RTCP). Each endpoint will send 2 streams (1 RTP one RTCP)
> and initially the relay will just listen on these ports and when it
> receives data it learns the endpoint's address. After it learns both
> endpoint's addresses, it adds a conntrack rule in the kernel to allow the
> kernel to directly relay the media streams between the endpoints and it
> will never see a media packet from the endpoints again until the call ends.
> This allows for very efficient data forwarding because it's done entirely
> in the kernel with no data being transferred from kernel to user-space and
> back like traditional solutions. We have seen media relays handling
> hundreds of calls at a time with 0% CPU load on the relay.
>
> So the only thing I can think of causing something like what you describe
> (even though I'm still not sure what you meant by hanging up sessions), is
> that somehow this process didn't finish setting up completely and the relay
> directly receives media streams from hundreds of devices because only one
> endpoint sends data (or the other endpoint's data gets filtered at some
> firewall), and because it cannot learn both endpoint's addresses it cannot
> setup the kernel conntrack rule to move data forwarding to the kernel.
>
> On 14 Mar 2017, at 13:38, Dan Pascu wrote:
>
> >
> > On 13 Mar 2017, at 18:58, Daniel Zanutti wrote:
> >
> >> Hi guys
> >>
> >> I sent this email a few days ago, anyone from Mediaproxy team could
> take a look? I could debug it, just need some directions on where to look.
> >
> > We have never encountered this problem, so I', not sure what to suggest,
> even more considering that the description is not very clear. What do you
> mean when you say the relay starts to hang some sessions? That it timeouts
> on them not having traffic and initiates a BYE for those sessions? Because
> in the next paragraph you imply that they never timeout.
> >
> >>
> >> Thanks
> >>
> >> On Tue, Mar 7, 2017 at 11:10 AM, Daniel Zanutti <
> daniel.zanu...@gmail.com> wrote:
> >> I'm using mediaproxy on several installations and have noticed that
> when the machine is on high load (> 700 sessions), the media-relay process
> starts to hang some sessions.
> >>
> >> These sessions doesn't have any RTP being sent/received anymore and
> they never hangup. After some hours of frozen sessions, the media-relay
> process doesn't connect to the dispatcher anymore, but keep using high CPU
> on the machine. Maybe it's on loop internally, not sure.
> >>
> >> Is there any solution for this? Maybe a timer to cleanup old sessions
> (2 or 4+ hours old).
> >>
> >> Thanks
> >>
> >>
> >>
> >> ___
> >> Users mailing list
> >> Users@lists.opensips.org
> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
> >
> > --
> > Dan
> >
> >
> >
> >
> >
> > __

Re: [OpenSIPS-Users] Monitoring Mediaproxy

[Mundkowsky, Robert]

Sorry, I don't know much about telephony.

Curious what I had wrong?

Is it that only media is sent to Mediaproxy without SIP?

Robert


-Original Message-
From: Users [mailto:users-boun...@lists.opensips.org] On Behalf Of Dan Pascu
Sent: Thursday, March 16, 2017 9:41 AM
To: OpenSIPS users mailling list 
Subject: Re: [OpenSIPS-Users] Monitoring Mediaproxy

Lol, what?!?

On 15 Mar 2017, at 23:03, Mundkowsky, Robert wrote:

> SIP Options is used as a “SIP ping”. You likely can have an time event 
> trigger route that can send one and then based on that disable/enable 
> accordingly.  Hopefully mediaproxy will not respond to the “SIP ping” if 
> frozen.
>
> Robert
>
> From: Users [mailto:users-boun...@lists.opensips.org] On Behalf Of Daniel 
> Zanutti
> Sent: Wednesday, March 15, 2017 4:55 PM
> To: OpenSIPS users mailling list 
> Subject: Re: [OpenSIPS-Users] Monitoring Mediaproxy
>
> How can this be done?
>
> Or do you mean SIP options?
>
> On Wed, Mar 15, 2017 at 5:45 PM, Johan De Clercq  wrote:
> Send options.
>
> On 15 Mar 2017 11:48 PM, "Daniel Zanutti"  wrote:
> Hi
>
> What's the best way to check if a mediaproxy is running fine? Monit is 
> monitoring PID but how can I check the process has is not frozen?
>
> 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
>
>
>
> This e-mail and any files transmitted with it may contain privileged or 
> confidential information. It is solely for use by the individual for whom it 
> is intended, even if addressed incorrectly. If you received this e-mail in 
> error, please notify the sender; do not disclose, copy, distribute, or take 
> any action in reliance on the contents of this information; and delete it 
> from your system. Any other use of this e-mail is prohibited.
>
>
> Thank you for your compliance.
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Dan





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



This e-mail and any files transmitted with it may contain privileged or 
confidential information. It is solely for use by the individual for whom it is 
intended, even if addressed incorrectly. If you received this e-mail in error, 
please notify the sender; do not disclose, copy, distribute, or take any action 
in reliance on the contents of this information; and delete it from your 
system. Any other use of this e-mail is prohibited.


Thank you for your compliance.


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

Re: [OpenSIPS-Users] Monitoring Mediaproxy

[Daniel Zanutti]

Hi Dan

This is exactly how I'm monitoring but looking to the dispatcher it's kind
hard on a Nagios like system, because I'm monitoring Relay A, B and C, but
the status will be on dispatcher machine D. But ok, if it's the only way.

Thanks

---

"Lol, what?!?"

I preferred to drop this =)

On Thu, Mar 16, 2017 at 10:41 AM, Dan Pascu  wrote:

> Lol, what?!?
>
> On 15 Mar 2017, at 23:03, Mundkowsky, Robert wrote:
>
> > SIP Options is used as a “SIP ping”. You likely can have an time event
> trigger route that can send one and then based on that disable/enable
> accordingly.  Hopefully mediaproxy will not respond to the “SIP ping” if
> frozen.
> >
> > Robert
> >
> > From: Users [mailto:users-boun...@lists.opensips.org] On Behalf Of
> Daniel Zanutti
> > Sent: Wednesday, March 15, 2017 4:55 PM
> > To: OpenSIPS users mailling list 
> > Subject: Re: [OpenSIPS-Users] Monitoring Mediaproxy
> >
> > How can this be done?
> >
> > Or do you mean SIP options?
> >
> > On Wed, Mar 15, 2017 at 5:45 PM, Johan De Clercq 
> wrote:
> > Send options.
> >
> > On 15 Mar 2017 11:48 PM, "Daniel Zanutti" 
> wrote:
> > Hi
> >
> > What's the best way to check if a mediaproxy is running fine? Monit is
> monitoring PID but how can I check the process has is not frozen?
> >
> > 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
> >
> >
> >
> > This e-mail and any files transmitted with it may contain privileged or
> confidential information. It is solely for use by the individual for whom
> it is intended, even if addressed incorrectly. If you received this e-mail
> in error, please notify the sender; do not disclose, copy, distribute, or
> take any action in reliance on the contents of this information; and delete
> it from your system. Any other use of this e-mail is prohibited.
> >
> >
> > Thank you for your compliance.
> >
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> --
> Dan
>
>
>
>
>
> ___
> 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] ERROR:presence:update_presentity cause OpenSIPS eat all memory and crash...

[Michele Pinassi]

More on this issue:

/usr/sbin/opensips[1050]: 313438393637323537333232383031-kto38ogzez62 -
Failure route 0  
/usr/sbin/opensips[1052]: INFO:db_mysql:switch_state_to_disconnected:
disconnect event for 0xb7292054
/usr/sbin/opensips[1052]: INFO:db_mysql:reset_all_statements: reseting
all statements on connection: (0xb728c8ec) 0xb7292054
/usr/sbin/opensips[1052]: INFO:db_mysql:connect_with_retry: re-connected
successful for 0xb7292054
/usr/sbin/opensips[1049]: ERROR:presence:update_presentity: No E_Tag
match [a.1489656643.1049.47170.35]
/usr/sbin/opensips[1047]: ERROR:presence:update_presentity: No E_Tag
match [a.1489656643.1047.47360.76]
/usr/sbin/opensips[1048]: ERROR:presence:update_presentity: No E_Tag
match [a.1489656643.1047.47329.35]
/usr/sbin/opensips[1050]: ERROR:presence:update_presentity: No E_Tag
match [a.1489656643.1047.47330.35]
/usr/sbin/opensips[1052]: INFO:db_mysql:switch_state_to_disconnected:
disconnect event for 0xb7292054
/usr/sbin/opensips[1052]: INFO:db_mysql:reset_all_statements: reseting
all statements on connection: (0xb728c8ec) 0xb7292054
/usr/sbin/opensips[1052]: INFO:db_mysql:connect_with_retry: re-connected
successful for 0xb7292054
/usr/sbin/opensips[1052]: CRITICAL:db_mysql:db_mysql_submit_query: too
many mysql server reconnection failures
/usr/sbin/opensips[1052]: ERROR:core:db_do_query: error while submitting
query - [select username,domain,etag,event from presentity where
expires<1489672563 order by username]
/usr/sbin/opensips[1052]: ERROR:presence:msg_presentity_clean: querying
database for expired messages
/usr/sbin/opensips[1052]: CRITICAL:core:timer_ticker: timer handler
 lasted (394 us) for more than timer tick (100
us) -> potential timer shifting
/usr/sbin/opensips[1049]: INFO:db_mysql:switch_state_to_disconnected:
disconnect event for 0xb7292054
/usr/sbin/opensips[1049]: INFO:db_mysql:reset_all_statements: reseting
all statements on connection: (0xb728c7e0) 0xb7292054
/usr/sbin/opensips[1049]: INFO:db_mysql:connect_with_retry: re-connected
successful for 0xb7292054
/usr/sbin/opensips[1050]: INFO:db_mysql:switch_state_to_disconnected:
disconnect event for 0xb7292054
/usr/sbin/opensips[1050]: INFO:db_mysql:reset_all_statements: reseting
all statements on connection: (0xb728c7e0) 0xb7292054
/usr/sbin/opensips[1050]: INFO:db_mysql:connect_with_retry: re-connected
successful for 0xb7292054
/usr/sbin/opensips[1047]: INFO:db_mysql:switch_state_to_disconnected:
disconnect event for 0xb7292054
/usr/sbin/opensips[1047]: INFO:db_mysql:reset_all_statements: reseting
all statements on connection: (0xb728c8ec) 0xb7292054
/usr/sbin/opensips[1048]: INFO:db_mysql:switch_state_to_disconnected:
disconnect event for 0xb7292054
/usr/sbin/opensips[1048]: INFO:db_mysql:reset_all_statements: reseting
all statements on connection: (0xb728c7e0) 0xb7292054
/usr/sbin/opensips[1047]: INFO:db_mysql:connect_with_retry: re-connected
successful for 0xb7292054
/usr/sbin/opensips[1048]: INFO:db_mysql:connect_with_retry: re-connected
successful for 0xb7292054
/usr/sbin/opensips[1049]: INFO:db_mysql:switch_state_to_disconnected:
disconnect event for 0xb7292054
/usr/sbin/opensips[1049]: INFO:db_mysql:reset_all_statements: reseting
all statements on connection: (0xb728c7e0) 0xb7292054
/usr/sbin/opensips[1049]: INFO:db_mysql:connect_with_retry: re-connected
successful for 0xb7292054
/usr/sbin/opensips[1049]: CRITICAL:db_mysql:db_mysql_submit_query: too
many mysql server reconnection failures
/usr/sbin/opensips[1049]: ERROR:core:db_do_update: error while
submitting query
/usr/sbin/opensips[1049]: ERROR:presence:update_presentity: updating
published info in database
/usr/sbin/opensips[1049]: ERROR:presence:handle_publish: when updating
presentity
/usr/sbin/opensips[1050]: INFO:db_mysql:switch_state_to_disconnected:
disconnect event for 0xb7292054
/usr/sbin/opensips[1050]: INFO:db_mysql:reset_all_statements: reseting
all statements on connection: (0xb728c7e0) 0xb7292054
/usr/sbin/opensips[1050]: INFO:db_mysql:connect_with_retry: re-connected
successful for 0xb7292054
/usr/sbin/opensips[1050]: CRITICAL:db_mysql:db_mysql_submit_query: too
many mysql server reconnection failures
/usr/sbin/opensips[1050]: ERROR:core:db_do_update: error while
submitting query
/usr/sbin/opensips[1050]: ERROR:presence:update_presentity: updating
published info in database
/usr/sbin/opensips[1050]: ERROR:presence:handle_publish: when updating
presentity
/usr/sbin/opensips[1047]: INFO:db_mysql:switch_state_to_disconnected:
disconnect event for 0xb7292054
/usr/sbin/opensips[1047]: INFO:db_mysql:reset_all_statements: reseting
all statements on connection: (0xb728c8ec) 0xb7292054
/usr/sbin/opensips[1048]: INFO:db_mysql:switch_state_to_disconnected:
disconnect event for 0xb7292054
/usr/sbin/opensips[1048]: INFO:db_mysql:reset_all_statements: reseting
all statements on connection: (0xb728c7e0) 0xb7292054
/usr/sbin/opensips[1049]: ERROR:presence:update_presentity: No E_Tag
match [a.1489656643.1047.47331.25]
/usr/sbin/opensips[1048]

Re: [OpenSIPS-Users] Monitoring Mediaproxy

[Alex Balashov]

If MediaProxy is a SIP endpoint, that would be news to me. 

-- Alex

--
Principal, Evariste Systems LLC (www.evaristesys.com)

Sent from my Google Nexus.

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

Re: [OpenSIPS-Users] Mediaproxy hanging sessions on high load

[Dan Pascu]

One thing came to mind. A case when the relay could get overloaded is if a lot 
of clients start sessions and only one endpoint sends media. That is the only 
case where the relay would have to deal with the media traffic itself and 
having hundreds of such sessions at the same time could overload the relay.

The way the relay works is for each call it starts listening on 4 ports (2 for 
RTP and 2 for RTCP). Each endpoint will send 2 streams (1 RTP one RTCP) and 
initially the relay will just listen on these ports and when it receives data 
it learns the endpoint's address. After it learns both endpoint's addresses, it 
adds a conntrack rule in the kernel to allow the kernel to directly relay the 
media streams between the endpoints and it will never see a media packet from 
the endpoints again until the call ends. This allows for very efficient data 
forwarding because it's done entirely in the kernel with no data being 
transferred from kernel to user-space and back like traditional solutions. We 
have seen media relays handling hundreds of calls at a time with 0% CPU load on 
the relay.

So the only thing I can think of causing something like what you describe (even 
though I'm still not sure what you meant by hanging up sessions), is that 
somehow this process didn't finish setting up completely and the relay directly 
receives media streams from hundreds of devices because only one endpoint sends 
data (or the other endpoint's data gets filtered at some firewall), and because 
it cannot learn both endpoint's addresses it cannot setup the kernel conntrack 
rule to move data forwarding to the kernel.

On 14 Mar 2017, at 13:38, Dan Pascu wrote:

> 
> On 13 Mar 2017, at 18:58, Daniel Zanutti wrote:
> 
>> Hi guys
>> 
>> I sent this email a few days ago, anyone from Mediaproxy team could take a 
>> look? I could debug it, just need some directions on where to look.
> 
> We have never encountered this problem, so I', not sure what to suggest, even 
> more considering that the description is not very clear. What do you mean 
> when you say the relay starts to hang some sessions? That it timeouts on them 
> not having traffic and initiates a BYE for those sessions? Because in the 
> next paragraph you imply that they never timeout.
> 
>> 
>> Thanks
>> 
>> On Tue, Mar 7, 2017 at 11:10 AM, Daniel Zanutti  
>> wrote:
>> I'm using mediaproxy on several installations and have noticed that when the 
>> machine is on high load (> 700 sessions), the media-relay process starts to 
>> hang some sessions.
>> 
>> These sessions doesn't have any RTP being sent/received anymore and they 
>> never hangup. After some hours of frozen sessions, the media-relay process 
>> doesn't connect to the dispatcher anymore, but keep using high CPU on the 
>> machine. Maybe it's on loop internally, not sure.
>> 
>> Is there any solution for this? Maybe a timer to cleanup old sessions (2 or 
>> 4+ hours old).
>> 
>> Thanks
>> 
>> 
>> 
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> 
> --
> Dan
> 
> 
> 
> 
> 
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Dan





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

Re: [OpenSIPS-Users] Monitoring Mediaproxy

[Dan Pascu]

Lol, what?!?

On 15 Mar 2017, at 23:03, Mundkowsky, Robert wrote:

> SIP Options is used as a “SIP ping”. You likely can have an time event 
> trigger route that can send one and then based on that disable/enable 
> accordingly.  Hopefully mediaproxy will not respond to the “SIP ping” if 
> frozen.
>  
> Robert
>  
> From: Users [mailto:users-boun...@lists.opensips.org] On Behalf Of Daniel 
> Zanutti
> Sent: Wednesday, March 15, 2017 4:55 PM
> To: OpenSIPS users mailling list 
> Subject: Re: [OpenSIPS-Users] Monitoring Mediaproxy
>  
> How can this be done?
>  
> Or do you mean SIP options?
>  
> On Wed, Mar 15, 2017 at 5:45 PM, Johan De Clercq  wrote:
> Send options.
>  
> On 15 Mar 2017 11:48 PM, "Daniel Zanutti"  wrote:
> Hi
>  
> What's the best way to check if a mediaproxy is running fine? Monit is 
> monitoring PID but how can I check the process has is not frozen?
>  
> 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
> 
>  
> 
> This e-mail and any files transmitted with it may contain privileged or 
> confidential information. It is solely for use by the individual for whom it 
> is intended, even if addressed incorrectly. If you received this e-mail in 
> error, please notify the sender; do not disclose, copy, distribute, or take 
> any action in reliance on the contents of this information; and delete it 
> from your system. Any other use of this e-mail is prohibited.
> 
> 
> Thank you for your compliance.
> 
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Dan





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

Re: [OpenSIPS-Users] Monitoring Mediaproxy

[Dan Pascu]

On 15 Mar 2017, at 22:18, Daniel Zanutti wrote:

> Hi
> 
> What's the best way to check if a mediaproxy is running fine? Monit is 
> monitoring PID but how can I check the process has is not frozen?

You can connect to the dispatcher on the control port and issue a statistics 
command that will fetch statistics from all the connected relays. The sample 
media sessions web application included with mediaproxy does that to show the 
active sessions. You can use that or use it as an example of how to do it from 
a monitoring script.

--
Dan





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

Re: [OpenSIPS-Users] Detecting zombie registrations

[Liviu Chircu]

Hi, John!

I do not recall such a feature, nor did I find it in the keynotes [1]. 
Regarding your specific issue - have you tried using the already current 
features, such as properly setting a timer interval / db_mode, or using 
MI commands such as ul_sync or ul_flush?


PS: if you're referring to contacts being immediately discarded upon TCP 
connection teardown, this has been discussed, but is still on the 
"ideas" list.


Best regards,

[1]: 
https://www.youtube.com/watch?v=tNFV-u4MJGo&list=PLMMZA6ketvKqriYN-cYWjQ0wPCR06HULA


Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

OpenSIPS Summit May 2017 Amsterdam
  http://www.opensips.org/events/Summit-2017Amsterdam.html

On 15.03.2017 23:39, John Quick wrote:

At the last OpenSIPS Summit, I thought they announced in the keynote speech
that a mechanism was being introduced in v2.2 to detect and discard zombie
registrations.
I cannot find anything about this in the documentation (or in documentation
for v2.3).
Did this happen?  Is there a description somewhere please?

John Quick
Smartvox Limited


___
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] ERROR:presence:update_presentity cause OpenSIPS eat all memory and crash...

[Michele Pinassi]

Opensips 1.11.9-notls on a Debian 8.7 x64, with more that 700 phones
registered.

Sometimes, almost twice a week, i got a lot of:

/usr/sbin/opensips[1585]: ERROR:presence:update_presentity: No E_Tag
match [a.1489409482.1585.24993.147]
/usr/sbin/opensips[1586]: ERROR:presence:update_presentity: No E_Tag
match [a.1489409482.1584.24871.146]
/usr/sbin/opensips[1584]: ERROR:presence:update_presentity: No E_Tag
match [a.1489409482.1586.24799.146]

that, after few hours, results in a:

/usr/sbin/opensips[1585]: ERROR:tm:new_t: out of mem
/usr/sbin/opensips[1584]: WARNING:core:fm_malloc: Not enough free
memory, will attempt defragmentation
/usr/sbin/opensips[1585]: ERROR:tm:t_newtran: new_t failed
/usr/sbin/opensips[1584]: ERROR:tm:new_t: out of mem

of course, users were not happy :-) so i need suggestions how to solve
the problem or how to avoid that error cause opensips to eat all the
memory available...

Thanks, Michele

-- 
Michele Pinassi
Responsabile Telefonia di Ateneo
Servizio Reti, Sistemi e Sicurezza Informatica - Università degli Studi di Siena
tel: 0577.(23)5000 - central...@unisi.it

Per trovare una soluzione rapida ai tuoi problemi tecnici consulta le FAQ di 
Ateneo, http://www.faq.unisi.it 




signature.asc
Description: OpenPGP digital signature
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users