Hello
i need one info.
I have one phone behind NAT and it is registered on OpenSIPS. IN
register packet, which is send to OpenSIPS I can see contact:
"sip:11181600519@192.168.0.101:5060;transport=UDP"
and let says that the public ip for this device is xxx.xxx.xxx.xxx.
When opensips sends IN
Hi there!
It’s that time of the year again, time for FOSDEM paper submissions! Next
FOSDEM we’ll have a “Real Time Communications” devroom, which is a good fit for
OpenSIPS and all things VoIP / RTC.
All the information regarding the process is available here:
https://lists.fosdem.org/piperma
Thank you. Got it.
Regards,
Agalya
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Razvan Crainea
Sent: Friday, November 11, 2016 8:33 AM
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] usage of setdsturi
Hi, Agalya!
The setdsturi() func
Hi Razvan,
Here is the requested data.
*INITIAL INVITE: *Via: SIP/2.0/TLS 123.123.212.123:5061
;branch=z9hG4bK442.8373b213.0;i=35f5
*200 OK from the B party as received by OpenSIPS:*
Via: SIP/2.0/TLS 118.151.101.64:5061;branch=z9hG4bK442.9a584727.0;i=11
*200 OK as sent out by OpenSIPS:*
V
Sorry!, after I added the code, opensips does NOT tries to connect. That is
my wanted result
On Mon, Nov 14, 2016 at 2:10 PM, Federico Edorna
wrote:
> Right! Actually I've added the code in relay_reply function, not in
> reply_route, but I guess it has the same effect...
>
> Thanks!
>
>
> On Mo
Right! Actually I've added the code in relay_reply function, not in
reply_route, but I guess it has the same effect...
Thanks!
On Mon, Nov 14, 2016 at 2:02 PM, Răzvan Crainea wrote:
> I got you now: so you are trying to set the tcp_no_new_conn_bflag in the
> reply_route, but OpenSIPS still tr
I got you now: so you are trying to set the tcp_no_new_conn_bflag in the
reply_route, but OpenSIPS still tries to connect to the client?
After you added the code in reply_received function, OpenSIPS still
tries to connect?
Best regards,
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.
Hi Razvan, thanks for your response
I agree that it is dangerous to try to open a new tcp connection, that's
why we want to set always the flag and never try to open a new tcp
connection to the UAC.
What I'm trying to say is that setting tcp_no_new_conn_bflag doesn't seem
to work for a reply, for
Hi, Federico!
Not sure I understand your problem. That flag indicates OpenSIPS to
avoid opening a new connection if he doesn't have one available.
Therefore, if the connection to the caller closes between INVITE and 200
OK, that flag prevents OpenSIPS from opening a new one.
Why would you like
Hi Bogdan,
Took about a week in production for the problem to crop up again so I
was able to get the mem dump. I hope this can provide you some insight.
Let me know if you need anything else.
http://pastebin.com/WQWqhhiA
Thanks!!
---
Jim DeVito
On 2016-11-07 12:04, Bogdan-Andrei Iancu wrot
Hi Răzvan,
related to this topic, it seems that tcp_no_new_conn_bflag is not working
on "on_reply" routes
I've tried changing modules/tm/t_reply.c (opensips 2.2), using something
like this:
if (tcp_no_new_conn_bflag)
tcp_no_new_conn = 1;
in "relay_reply" function and now opens
Ok, Liviu, where this realization can be expected (if any)?
Thank you.
mailto:denis7...@mail.ru
The "sequential-calls" is the only statistic which may also benefit from a
periodical reset (daily / weekly / monthly, etc.). IMO, calls-per-min /
total-calls / concurrent-calls _should not_ reset
The "sequential-calls" is the only statistic which may also benefit from
a periodical reset (daily / weekly / monthly, etc.). IMO, calls-per-min
/ total-calls / concurrent-calls _should not_ reset to 0 at midnight.
Since a rule's "sequential-calls" cannot be easily reused with multiple
reset i
Hi, Răzvan,
Very helpful,
Thank you very much.
Best Regards,
Ehrny
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Razvan Crainea
Sent: Monday, November 14, 2016 11:03 AM
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] $ai transformation
H
Hi Schneur,
Well, this exact behavior cannot be achieved with OpenSIPS only, as some
advanced Class 5 capabilities are required.
What you can do is slightly different - when you call to the ringing
group (to pick the call), your call will be terminated and immediately
your phone will start r
Hello, Liviu!
Thank you very much for your answer!
I understood my main mistake. I thought that "call duration" is the total value
for all calls but not of only one.
Ok, "sequential-calls" may be that thing which can help to avoid such
situation, but the main problem is (and as you wrote in the
Hi, Denis!
First of all, thank you for taking the time to gather this nice data!
Looking at the calls, to me it looks like the module behaved as
expected. Here are some thoughts:
- all call durations were less under 1500 seconds, while your fraud rule
is set to 3600 seconds, so it never got
Hi, Samy!
Can you post on pastebin debugging logs related to this call? Also, can
you also post the Via headers of the initial INVITE and for the 200 OK
received by OpenSIPS?
Best regards,
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com
On 11/12/2016 12:33 AM, SamyGo wrote:
Hi
Hi, Chen-Che!
You are right; the building system has changed a bit and I forgot to
update the version in the new files! I've done a fix on all affected
branches. However, they will only be visible in the next release.
Until then, you can apply this patch[1] on the current archive in order
to g
Hi, Ehrny!
Yes, you can transform the P-Asserted-Identity header as you wish, by
dropping the existing one and creating a new one. Use the remove_hf()[1]
and append_hf()[2] headers for that, i.e.:
if (is_present_hf("P-Asserted-Identity")) {
remove_hf("P-Asserted-Identity");
$avp(rpid)
20 matches
Mail list logo
