Re: [OpenSIPS-Users] SUBSCRIBE & NOTIFY - NAT Problems
Hi Everyone,
I figured it out. I needed to add fix_nated_contact() on the reply route for
the notify messages. The 200 OK messages were overwriting the contact from the
corrected SUBSCRIBE request. After doing this, OpenSIPS now sends the NOTIFY
messages to the correct address.
if (has_totag()) {
if (topology_hiding_match()) {
xlog("Successfully matched this request to a topology
hiding dialog. \n");
xlog("Calller side callid is $ci \n");
xlog("Callee side callid is $TH_callee_callid \n");
if (is_method("NOTIFY")){
fix_nated_contact();
t_on_reply("NOTIFYReply");
}
t_relay();
exit;
}
onreply_route[NOTIFYReply] {
#NAT for 200 OK replys
if (t_check_status("(200)")) {
fix_nated_contact();
}
}
Thank you,
-Sam Anderson
-Original Message-
From: Samuel Anderson
Sent: Thursday, June 25, 2020 5:29 PM
To: 'users@lists.opensips.org'
Subject: SUBSCRIBE & NOTIFY - NAT Problems
Hi Everyone,
I use OpenSIPS as an SBC for an Asterisk server. The OpenSIPS server is
multi-homed and has an interface on the WAN and DMZ. I'm able to make calls and
send sequential requests in a dialog, such as INVITEs and BYEs, from endpoints
behind NAT without any issues. My problem is when the endpoints try to
SUBSCRIBE, and Asterisk sends a NOTIFY message back. OpenSIPS is sending the
NOTIFY to the original contact header specified in the SUBSCRIBE request. It is
not sending the NOTIFY to the address it received it from. It does rewrite the
contact header when the SUBSCRIBE message is sent to Asterisk, and OpenSIPS
also sends the 200 OK reply to the correct address.
How can I configure OpenSIPS to send the additional NOTIFY messages within the
dialog to the address it received it from? I've tried to create a dialog for
SUBSCRIBE requests, but it looks like that only works for INVITEs. Any help
would be appreciated. It currently works fine with INVITEs and BYEs.
I use double record routes, topology hiding, and the dialog module. I also set
"fix_nated_contact" when the SUBSCRIBE is received.
Thank you for your assistance.
-Sam
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this message
immediately if this is an electronic communication.
Thank you.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] rtpengine errors: can't send command to a RTP proxy (22:Invalid argument)
It looks like the hidden IOV_MAX is set to 1024 in debian.
I tested a patch and all looks good.
It seems that there is an error in the code: writev has the wrong
number of iovcnt (should be one less).
I tested and all looks ok (the code in rtpproxy.c has the proper iovcnt).
-ovidiu
On Thu, Jun 25, 2020 at 1:03 PM Ovidiu Sas wrote:
>
> We will need to add a param to control the max number of buffers.
>
> -ovidiu
>
> On Thu, Jun 25, 2020 at 1:02 PM Ovidiu Sas wrote:
> >
> > It seems that when we have more than roughly 1000 buffers, the send fails.
> >
> > -ovidiu
> >
> > On Wed, Jun 24, 2020 at 8:54 AM Ovidiu Sas wrote:
> > >
> > > Hello Razvan,
> > >
> > > The system is a debian buster one.
> > > I patched the code:
> > > #ifdef IOV_MAX
> > > LM_NOTICE("IOV_MAX=[%d]\n", IOV_MAX);
> > > #else
> > > LM_NOTICE("no IOV_MAX\n");
> > > #endif
> > >
> > > and I get:
> > > NOTICE:rtpengine:send_rtpe_command: no IOV_MAX
> > > in the logs.
> > >
> > > Then I patched the code again to check how many buffers are being used:
> > > The max so far was 73:
> > > LM_NOTICE("writev(rtpe_socks[node->idx], v , %d)\n", vcnt + 1);
> > > got me:
> > > NOTICE:rtpengine:send_rtpe_command: writev(rtpe_socks[node->idx], v , 73)
> > >
> > > I will continue to monitor the system to see if there is a correlation
> > > between the error and the number of buffers.
> > >
> > > Thanks,
> > > Ovidiu
> > >
> > > On Wed, Jun 24, 2020 at 1:59 AM Răzvan Crainea
> > > wrote:
> > > >
> > > > Hi, Ovidiu!
> > > >
> > > > I doubt this is a problem of OpenSIPS version, but rather of the OS you
> > > > are running on. I suspect that error comes from the fact that the bson
> > > > resulted has more than IOV_MAX elements, which if I recall correctly it
> > > > was 15 on some OSes.
> > > > We had a similar problem in rtpproy[1], where we had merged the buffers
> > > > in a single one just to pass over this limitation. Could you check if
> > > > you are facing a similar issue?
> > > >
> > > > [1]
> > > > https://github.com/OpenSIPS/opensips/blob/master/modules/rtpproxy/rtpproxy.c#L2031
> > > >
> > > > Răzvan Crainea
> > > > OpenSIPS Core Developer
> > > > http://www.opensips-solutions.com
> > > >
> > > > On 6/24/20 7:32 AM, Ovidiu Sas wrote:
> > > > > This is happening also on the latest 3.0.
> > > > > The weird thing is that opensips doesn't send anything to rtpengine.
> > > > > The first opensips/rtpengine exchange on the initial INVITE works ok,
> > > > > but the opensips/rtpengine exchange on the 200ok fails (no command is
> > > > > sent by opensips - confirmed by running ngrep on the loopback
> > > > > interface).
> > > > > On the next call, the initial offer works fine, but the answer fails
> > > > > due to no command issued by opensips.
> > > > >
> > > > > version: opensips 3.0.2 (x86_64/linux)
> > > > > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
> > > > > Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
> > > > > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
> > > > > MAX_URI_SIZE 1024, BUF_SIZE 65535
> > > > > poll method support: poll, epoll, sigio_rt, select.
> > > > > git revision: 3a8f6f137
> > > > > main.c compiled on 09:36:42 Jun 22 2020 with gcc 9
> > > > >
> > > > > -ovidiu
> > > > >
> > > > >
> > > > > On Wed, Jun 10, 2020 at 2:49 PM Ovidiu Sas
> > > > > wrote:
> > > > >>
> > > > >> Hello all,
> > > > >>
> > > > >> I'm running opensips 3.1.0-beta (latest version) and experiencing
> > > > >> connectivity issues to the rtpengine daemon running on the same host:
> > > > >> ERROR:rtpengine:send_rtpe_command: can't send command to a RTP proxy
> > > > >> (22:Invalid argument)
> > > > >> ERROR:rtpengine:send_rtpe_command: timeout waiting reply from a RTP
> > > > >> proxy
> > > > >> ERROR:rtpengine:send_rtpe_command: proxy does
> > > > >> not
> > > > >> respond, disable it
> > > > >> ERROR:rtpengine:rtpe_function_call: no available proxies
> > > > >>
> > > > >> After an opensips restart, everything comes to normal.
> > > > >> I was running previously opensips 3.1.0-dev and everything was
> > > > >> working fine.
> > > > >>
> > > > >> The issue starts showing up after a few days with very little
> > > > >> traffic.
> > > > >> Is there anyone experiencing this issue?
> > > > >>
> > > > >>
> > > > >> Thanks,
> > > > >> Ovidiu
> > > > >>
> > > > >> --
> > > > >> VoIP Embedded, Inc.
> > > > >> http://www.voipembedded.com
> > > > >
> > > > >
> > > > >
> > > >
> > > > ___
> > > > Users mailing list
> > > > Users@lists.opensips.org
> > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> > >
> > >
> > >
> > > --
> > > VoIP Embedded, Inc.
> > > http://www.voipembedded.com
> >
> >
> >
> > --
> > VoIP Embedded, Inc.
> > http://www.voipembedded.com
>
>
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
--
VoIP Embedded, Inc.
http://www.voipembedded.com
___
Users m
[OpenSIPS-Users] SUBSCRIBE & NOTIFY - NAT Problems
Hi Everyone, I use OpenSIPS as an SBC for an Asterisk server. The OpenSIPS server is multi-homed and has an interface on the WAN and DMZ. I'm able to make calls and send sequential requests in a dialog, such as INVITEs and BYEs, from endpoints behind NAT without any issues. My problem is when the endpoints try to SUBSCRIBE, and Asterisk sends a NOTIFY message back. OpenSIPS is sending the NOTIFY to the original contact header specified in the SUBSCRIBE request. It is not sending the NOTIFY to the address it received it from. It does rewrite the contact header when the SUBSCRIBE message is sent to Asterisk, and OpenSIPS also sends the 200 OK reply to the correct address. How can I configure OpenSIPS to send the additional NOTIFY messages within the dialog to the address it received it from? I've tried to create a dialog for SUBSCRIBE requests, but it looks like that only works for INVITEs. Any help would be appreciated. It currently works fine with INVITEs and BYEs. I use double record routes, topology hiding, and the dialog module. I also set "fix_nated_contact" when the SUBSCRIBE is received. Thank you for your assistance. -Sam This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication. Thank you. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Problem with add_rr_param() in v2.4.7
On 25.06.2020 19:25, Liviu Chircu wrote: Currently investigating what happened over there and working towards a solution! :) A fix for the issue [1] is now available on latest 2.4.7 and above. Many thanks for the report and for your patience, John! Cheers, [1]: https://github.com/OpenSIPS/opensips/commit/e3ca95ecd0b -- 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
Re: [OpenSIPS-Users] Useless NAT check with IPV6
The bug report was deemed unnecessary. For those searching the archive you can
eliminate this
type of error by ensuring that your script employs fix_nated_register and
fix_nated_contact.
Without it the contact will contain gibbrish and the location table will not
record the actual
address in the "received" field. Call routing will fail. This applies whether
or not the contact is
nated when GRUU is in use. Perhaps uncommon once but always present in WEBRTC.
On Thursday, June 25, 2020 9:56:39 A.M. PDT Robert Dyck wrote:
I have submitted bug #2154.
I believe it is a registration problem. The "received" should never be null in
the location table.
On Wednesday, June 24, 2020 2:36:04 P.M. PDT Robert Dyck wrote:
Context: opensips 3.0.2
I wanted to cleanup a working configuration so I eliminated the NAT check if
the address family
was IPV6. This was in the initial request route. I was surprised to see that an
IPV6 INVITE would
fail. The REGISTERs were good.
Could someone explain to me what is happening.
Thanks, Rob
Config and debug on failure
if ($af == "INET") {
un 24 10:09:34 [1682250] Branch index is 0
Debug of NAT check, working scenario
Jun 24 13:59:52 [1707071] Received request from WAN, Method is INVITE
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Possibilities to handle short duration calls using new capabilities in opensips 3.1
This is what my snippets look like. I save the actual receive time for
the BYE for accounting purposes, as the CDR will have the time of the
dialog timeout or when the called party hangs up. I didn't find a way
to prevent the BYE message from going to both parties on dialog
timeout, but by then the caller side just ignores it with an 481
Transaction Does Not Exist.
if (is_method("BYE")) {
if(match_dialog_only()) { # this is my hacked match_dialog
which basically just does the load_ctx without triggering the chain
reaction of callbacks
xlog("$ci: Dialog status is $DLG_status . Direction
$DLG_dir $dlg_val(caller_bye_ts)");
$var(holdup_time) = $dlg_val(holdup_sec); #get the
dialog holdup timer value
$var(holdup_time) = $(var(holdup_time){s.int});
if ($DLG_dir=="downstream" && $var(holdup_time) !=
NULL && $var(holdup_time) > 0) { # only trigger if the caller hung up
and the timer is set
xlog("$ci: BYE holdup timer is $var(holdup_time)
seconds. Call has run $DLG_lifetime seconds");
if($DLG_lifetime < $var(holdup_time)) {
$dlg_val(caller_bye_ts)=""+$Ts; # save the
actual bye receive time to put in a cdr avp
$var(holdup_secs) = $var(holdup_time) - $DLG_lifetime;
xlog("$ci: BYE holdup timer started for
$var(holdup_secs) seconds.");
sl_send_reply("200", "OK");
$DLG_timeout = $var(holdup_secs)+1;
async(sleep("$var(holdup_secs)"), after_sleep);
}
}
match_dialog_process(); # match_dialog() would go here
}
}
route[after_sleep] {
xlog("$ci: BYE holdup timer finished. Dialog status is $DLG_status");
if ($DLG_status == 4) { # make sure we haven't received a bye from
the called party
if (match_dialog_process()) { # you would want to do the
dialog_match() here
xlog("$ci: Relaying delayed BYE");
t_relay();
}
else {
xlog("$ci: Dialog not matched. Callee bye preempted.");
}
}
else {
xlog("$ci: Delayed bye dialog is terminated. Not forwarding.");
}
exit;
}
On Thu, Jun 25, 2020 at 11:43 AM ryan embgrets wrote:
>
> Thanks, Jon , Bogdan for the assistance.
> So, I added the below snippet after the has_totag section of my configuration.
>
>if (is_method("BYE") && $si = "192.168.10.20") {
> if ( load_dialog_ctx("$ci") ) {
> xlog("The dialog $var(callid) has an already duration
> of $DLG_lifetime seconds with $DLG_dir\n");
> if($DLG_lifetime < 10 ) {
> $DLG_timeout = 10 - $DLG_lifetime ;
> send_reply(200, "OK");
> exit;
> }
> unload_dialog_ctx();
> }
> }
>
> And it seems to work, I wanted to check if the above snippet looks good?
>
> Is there a way to send bye to only Carrier side?
>
> I see CDRs get written after dialog timeouts, but can I get CDRs with
> duration when I receive a bye from the client not on dialog timeout?
>
> Thanks again for your time.
>
> Ryan.
>
>
>
>
>
> On Wed, 24 Jun 2020 at 17:55, Bogdan-Andrei Iancu wrote:
>>
>> Nice one Jon !
>>
>> doing a ++ here, maybe when loading the dialog ctx (before the match),
>> in the call duration is less than 6 secs, you can reply with 200 OK to
>> the BYE and set a dialog timeout for whatever number of sec you still
>> have to get to the 6 secs duration - so when you get to the overall 6
>> secs, OpenSIPS will send the BYEs to both parties.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>https://www.opensips-solutions.com
>>
>> On 6/23/20 10:43 PM, Jon Abrams wrote:
>> > You may be able to use the load_dialog_ctx()/unload_dialog_ctx()
>> > dialog functions to peek at the dialog when a BYE is received, prior
>> > to invoking match_dialog(). If it is a BYE from the calling party that
>> > you wish to delay, use an async sleep() to delay the call of
>> > match_dialog() and relay of the BYE to the far end. I do something
>> > similar now in 2.2 with a slightly patched dialog module.
>> >
>> > - Jon
>> >
>> >
>> > On Tue, Jun 23, 2020 at 1:58 AM ryan embgrets wrote:
>> >> Greetings,
>> >>
>> >> I would like to have awesome community suggestions in handling the short
>> >> duration calls.
>> >>
>> >> My clients send short duration calls towards opensips.
>> >> So if a client sends me BYE within 6 seconds of the call, I would like to
>> >> terminate the client leg and keep carrier leg alive beyond a few seconds,
>> >> either by transferring the second leg(carrier side) to freeswitch, or
>> >> playing some media using rtpengine/rtpproxy at opensips side.
>> >>
>> >> I would li
Re: [OpenSIPS-Users] rtpengine errors: can't send command to a RTP proxy (22:Invalid argument)
We will need to add a param to control the max number of buffers.
-ovidiu
On Thu, Jun 25, 2020 at 1:02 PM Ovidiu Sas wrote:
>
> It seems that when we have more than roughly 1000 buffers, the send fails.
>
> -ovidiu
>
> On Wed, Jun 24, 2020 at 8:54 AM Ovidiu Sas wrote:
> >
> > Hello Razvan,
> >
> > The system is a debian buster one.
> > I patched the code:
> > #ifdef IOV_MAX
> > LM_NOTICE("IOV_MAX=[%d]\n", IOV_MAX);
> > #else
> > LM_NOTICE("no IOV_MAX\n");
> > #endif
> >
> > and I get:
> > NOTICE:rtpengine:send_rtpe_command: no IOV_MAX
> > in the logs.
> >
> > Then I patched the code again to check how many buffers are being used:
> > The max so far was 73:
> > LM_NOTICE("writev(rtpe_socks[node->idx], v , %d)\n", vcnt + 1);
> > got me:
> > NOTICE:rtpengine:send_rtpe_command: writev(rtpe_socks[node->idx], v , 73)
> >
> > I will continue to monitor the system to see if there is a correlation
> > between the error and the number of buffers.
> >
> > Thanks,
> > Ovidiu
> >
> > On Wed, Jun 24, 2020 at 1:59 AM Răzvan Crainea wrote:
> > >
> > > Hi, Ovidiu!
> > >
> > > I doubt this is a problem of OpenSIPS version, but rather of the OS you
> > > are running on. I suspect that error comes from the fact that the bson
> > > resulted has more than IOV_MAX elements, which if I recall correctly it
> > > was 15 on some OSes.
> > > We had a similar problem in rtpproy[1], where we had merged the buffers
> > > in a single one just to pass over this limitation. Could you check if
> > > you are facing a similar issue?
> > >
> > > [1]
> > > https://github.com/OpenSIPS/opensips/blob/master/modules/rtpproxy/rtpproxy.c#L2031
> > >
> > > Răzvan Crainea
> > > OpenSIPS Core Developer
> > > http://www.opensips-solutions.com
> > >
> > > On 6/24/20 7:32 AM, Ovidiu Sas wrote:
> > > > This is happening also on the latest 3.0.
> > > > The weird thing is that opensips doesn't send anything to rtpengine.
> > > > The first opensips/rtpengine exchange on the initial INVITE works ok,
> > > > but the opensips/rtpengine exchange on the 200ok fails (no command is
> > > > sent by opensips - confirmed by running ngrep on the loopback
> > > > interface).
> > > > On the next call, the initial offer works fine, but the answer fails
> > > > due to no command issued by opensips.
> > > >
> > > > version: opensips 3.0.2 (x86_64/linux)
> > > > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
> > > > Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
> > > > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
> > > > MAX_URI_SIZE 1024, BUF_SIZE 65535
> > > > poll method support: poll, epoll, sigio_rt, select.
> > > > git revision: 3a8f6f137
> > > > main.c compiled on 09:36:42 Jun 22 2020 with gcc 9
> > > >
> > > > -ovidiu
> > > >
> > > >
> > > > On Wed, Jun 10, 2020 at 2:49 PM Ovidiu Sas
> > > > wrote:
> > > >>
> > > >> Hello all,
> > > >>
> > > >> I'm running opensips 3.1.0-beta (latest version) and experiencing
> > > >> connectivity issues to the rtpengine daemon running on the same host:
> > > >> ERROR:rtpengine:send_rtpe_command: can't send command to a RTP proxy
> > > >> (22:Invalid argument)
> > > >> ERROR:rtpengine:send_rtpe_command: timeout waiting reply from a RTP
> > > >> proxy
> > > >> ERROR:rtpengine:send_rtpe_command: proxy does not
> > > >> respond, disable it
> > > >> ERROR:rtpengine:rtpe_function_call: no available proxies
> > > >>
> > > >> After an opensips restart, everything comes to normal.
> > > >> I was running previously opensips 3.1.0-dev and everything was working
> > > >> fine.
> > > >>
> > > >> The issue starts showing up after a few days with very little traffic.
> > > >> Is there anyone experiencing this issue?
> > > >>
> > > >>
> > > >> Thanks,
> > > >> Ovidiu
> > > >>
> > > >> --
> > > >> VoIP Embedded, Inc.
> > > >> http://www.voipembedded.com
> > > >
> > > >
> > > >
> > >
> > > ___
> > > Users mailing list
> > > Users@lists.opensips.org
> > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
> >
> >
> > --
> > VoIP Embedded, Inc.
> > http://www.voipembedded.com
>
>
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
--
VoIP Embedded, Inc.
http://www.voipembedded.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] rtpengine errors: can't send command to a RTP proxy (22:Invalid argument)
It seems that when we have more than roughly 1000 buffers, the send fails.
-ovidiu
On Wed, Jun 24, 2020 at 8:54 AM Ovidiu Sas wrote:
>
> Hello Razvan,
>
> The system is a debian buster one.
> I patched the code:
> #ifdef IOV_MAX
> LM_NOTICE("IOV_MAX=[%d]\n", IOV_MAX);
> #else
> LM_NOTICE("no IOV_MAX\n");
> #endif
>
> and I get:
> NOTICE:rtpengine:send_rtpe_command: no IOV_MAX
> in the logs.
>
> Then I patched the code again to check how many buffers are being used:
> The max so far was 73:
> LM_NOTICE("writev(rtpe_socks[node->idx], v , %d)\n", vcnt + 1);
> got me:
> NOTICE:rtpengine:send_rtpe_command: writev(rtpe_socks[node->idx], v , 73)
>
> I will continue to monitor the system to see if there is a correlation
> between the error and the number of buffers.
>
> Thanks,
> Ovidiu
>
> On Wed, Jun 24, 2020 at 1:59 AM Răzvan Crainea wrote:
> >
> > Hi, Ovidiu!
> >
> > I doubt this is a problem of OpenSIPS version, but rather of the OS you
> > are running on. I suspect that error comes from the fact that the bson
> > resulted has more than IOV_MAX elements, which if I recall correctly it
> > was 15 on some OSes.
> > We had a similar problem in rtpproy[1], where we had merged the buffers
> > in a single one just to pass over this limitation. Could you check if
> > you are facing a similar issue?
> >
> > [1]
> > https://github.com/OpenSIPS/opensips/blob/master/modules/rtpproxy/rtpproxy.c#L2031
> >
> > Răzvan Crainea
> > OpenSIPS Core Developer
> > http://www.opensips-solutions.com
> >
> > On 6/24/20 7:32 AM, Ovidiu Sas wrote:
> > > This is happening also on the latest 3.0.
> > > The weird thing is that opensips doesn't send anything to rtpengine.
> > > The first opensips/rtpengine exchange on the initial INVITE works ok,
> > > but the opensips/rtpengine exchange on the 200ok fails (no command is
> > > sent by opensips - confirmed by running ngrep on the loopback
> > > interface).
> > > On the next call, the initial offer works fine, but the answer fails
> > > due to no command issued by opensips.
> > >
> > > version: opensips 3.0.2 (x86_64/linux)
> > > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
> > > Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
> > > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
> > > MAX_URI_SIZE 1024, BUF_SIZE 65535
> > > poll method support: poll, epoll, sigio_rt, select.
> > > git revision: 3a8f6f137
> > > main.c compiled on 09:36:42 Jun 22 2020 with gcc 9
> > >
> > > -ovidiu
> > >
> > >
> > > On Wed, Jun 10, 2020 at 2:49 PM Ovidiu Sas wrote:
> > >>
> > >> Hello all,
> > >>
> > >> I'm running opensips 3.1.0-beta (latest version) and experiencing
> > >> connectivity issues to the rtpengine daemon running on the same host:
> > >> ERROR:rtpengine:send_rtpe_command: can't send command to a RTP proxy
> > >> (22:Invalid argument)
> > >> ERROR:rtpengine:send_rtpe_command: timeout waiting reply from a RTP proxy
> > >> ERROR:rtpengine:send_rtpe_command: proxy does not
> > >> respond, disable it
> > >> ERROR:rtpengine:rtpe_function_call: no available proxies
> > >>
> > >> After an opensips restart, everything comes to normal.
> > >> I was running previously opensips 3.1.0-dev and everything was working
> > >> fine.
> > >>
> > >> The issue starts showing up after a few days with very little traffic.
> > >> Is there anyone experiencing this issue?
> > >>
> > >>
> > >> Thanks,
> > >> Ovidiu
> > >>
> > >> --
> > >> VoIP Embedded, Inc.
> > >> http://www.voipembedded.com
> > >
> > >
> > >
> >
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
--
VoIP Embedded, Inc.
http://www.voipembedded.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Useless NAT check with IPV6
I have submitted bug #2154.
I believe it is a registration problem. The "received" should never be null in
the location table.
On Wednesday, June 24, 2020 2:36:04 P.M. PDT Robert Dyck wrote:
Context: opensips 3.0.2
I wanted to cleanup a working configuration so I eliminated the NAT check if
the address family
was IPV6. This was in the initial request route. I was surprised to see that an
IPV6 INVITE would
fail. The REGISTERs were good.
Could someone explain to me what is happening.
Thanks, Rob
Config and debug on failure
if ($af == "INET") {
un 24 10:09:34 [1682250] Branch index is 0
Debug of NAT check, working scenario
Jun 24 13:59:52 [1707071] Received request from WAN, Method is INVITE
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Possibilities to handle short duration calls using new capabilities in opensips 3.1
Thanks, Jon , Bogdan for the assistance.
So, I added the below snippet after the has_totag section of my
configuration.
if (is_method("BYE") && $si = "192.168.10.20") {
if ( load_dialog_ctx("$ci") ) {
xlog("The dialog $var(callid) has an already
duration of $DLG_lifetime seconds with $DLG_dir\n");
if($DLG_lifetime < 10 ) {
$DLG_timeout = 10 - $DLG_lifetime ;
send_reply(200, "OK");
exit;
}
unload_dialog_ctx();
}
}
And it seems to work, I wanted to check if the above snippet looks good?
Is there a way to send bye to only Carrier side?
I see CDRs get written after dialog timeouts, but can I get CDRs with
duration when I receive a bye from the client not on dialog timeout?
Thanks again for your time.
Ryan.
On Wed, 24 Jun 2020 at 17:55, Bogdan-Andrei Iancu
wrote:
> Nice one Jon !
>
> doing a ++ here, maybe when loading the dialog ctx (before the match),
> in the call duration is less than 6 secs, you can reply with 200 OK to
> the BYE and set a dialog timeout for whatever number of sec you still
> have to get to the 6 secs duration - so when you get to the overall 6
> secs, OpenSIPS will send the BYEs to both parties.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>https://www.opensips-solutions.com
>
> On 6/23/20 10:43 PM, Jon Abrams wrote:
> > You may be able to use the load_dialog_ctx()/unload_dialog_ctx()
> > dialog functions to peek at the dialog when a BYE is received, prior
> > to invoking match_dialog(). If it is a BYE from the calling party that
> > you wish to delay, use an async sleep() to delay the call of
> > match_dialog() and relay of the BYE to the far end. I do something
> > similar now in 2.2 with a slightly patched dialog module.
> >
> > - Jon
> >
> >
> > On Tue, Jun 23, 2020 at 1:58 AM ryan embgrets
> wrote:
> >> Greetings,
> >>
> >> I would like to have awesome community suggestions in handling the
> short duration calls.
> >>
> >> My clients send short duration calls towards opensips.
> >> So if a client sends me BYE within 6 seconds of the call, I would like
> to terminate the client leg and keep carrier leg alive beyond a few
> seconds, either by transferring the second leg(carrier side) to freeswitch,
> or playing some media using rtpengine/rtpproxy at opensips side.
> >>
> >> I would like to ask, is it something that can efficiently be done using
> new capabilities in opensips 3.1?
> >>
> >> How do other people handle this?
> >>
> >> PS: I cannot restrict my client to not send me short duration calls, so
> looking for an opensips way to handle this.
> >>
> >> Ryan
> >> ___
> >> 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] Problem with add_rr_param() in v2.4.7
On 21.05.2020 23:57, John Quick wrote:
I finally made some more time to investigate this bug and can now confirm
that it only happens when a dialog is created before you call add_rr_param()
So, in your test, please add this line at the start:
create_dialog("B");
then you should see the error happening.
Hi, John!
Thanks to your excellent instructions, I was able to reproduce your
scenario and confirm that:
* latest 2.4.7 release (96517d4860e0) has this bug
* initial 2.4.6 release (edef893c5af) does _not_ have the bug
Using this information and the ol' trusty `git bisect`, I managed to
pinpoint the exact commit which broke things:
commit c263182ee4dd692212ca310feb8a902714b93b45
Author: Varghese Paul
Date: Wed Jun 19 13:39:51 2019 -0700
Do not simply link the buffered lumps, but better clone them ->
this will avoid a mixage of lump types (shm versus pkg) when using async()
modules/rr/record.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
Currently investigating what happened over there and working towards a
solution! :)
Best regards,
--
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
Re: [OpenSIPS-Users] do_routing with failover to shorter prefix
Yes, our configuration calls do_routing multiple times for different failover
cases. You may want to verify this but I believe that the additional calls will
append to the relevant AVPs used by the module, so if you haven’t routed to all
destinations, you may need to clear out the AVPs prior to calling it again. I’m
not positive on that part though; it may overwrite existing values.
We created a little helper route to do this:
route[clear_dr_avps]
{
avp_delete("$avp(dr_ruri)/g");
avp_delete("$avp(dr_gw_id)/g");
avp_delete("$avp(dr_gw_prfx)/g");
avp_delete("$avp(dr_rule_id)/g");
avp_delete("$avp(dr_rule_prfx)/g");
avp_delete("$avp(dr_carr_id)/g");
}
Ben Newlin
From: Users on behalf of Vic Jolin
Reply-To: OpenSIPS users mailling list
Date: Thursday, June 25, 2020 at 10:49 AM
To: "users@lists.opensips.org"
Subject: [OpenSIPS-Users] do_routing with failover to shorter prefix
Hi,
So I have this in my opensips.cfg
if ( !do_routing($(avp(drgID){s.int}),$var(gw_attributes)) ) {
send_reply(404,"No Route found");
exit;
}
And I know that do_routing will match on the longer prefix on dr_rules table
first.
My question is
Now after failing on all the routes, can we still do another do_routing with
shorter prefix matching?
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] do_routing with failover to shorter prefix
Hi,
So I have this in my opensips.cfg
if ( !do_routing($(avp(drgID){s.int}),$var(gw_attributes)) ) {
send_reply(404,"No Route found");
exit;
}
And I know that do_routing will match on the longer prefix on dr_rules
table first.
My question is
Now after failing on all the routes, can we still do another do_routing
with shorter prefix matching?
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] opensips-cli dp_reload not working
Bogdan, Below is the debug output when reloading dialplan >From what I have noticed, after a successful dp_reload, and then making the 1st test call, the next calls will have the same context result as the first one, even if the dialplan is different. So, for example we tested and got context drgID=1 from the dialplan that matches, the consecutive dial plan matches will have the same context. *Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc8ad38: pr 0 next 0x7f458dc8b140 match_exp ^662261(.+) match_flags 0, subst_exp ^662261(.+), repl_exp 61\1 and attrs and timerec * *Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc8b140: pr 0 next 0x7f458dc96470 match_exp ^2266(.+) match_flags 0, subst_exp ^2266(.+), repl_exp \1 and attrs user=2266; gateway=gtps and timerec * *Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc96470: pr 0 next 0x7f458dc96800 match_exp ^6[0-9][0-9][0-9](.+) match_flags 0, subst_exp ^6[0-9][0-9][0-9](.+), repl_exp \1 and attrs and timerec * *Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc96800: pr 0 next 0x7f458dc96bc0 match_exp ^1(.+) match_flags 0, subst_exp ^1(.+), repl_exp 1\1 and attrs drgID=12 and timerec * *Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc96bc0: pr 0 next 0x7f458dc96f88 match_exp ^979744(.+) match_flags 0, subst_exp ^979744(.+), repl_exp 44\1 and attrs user=9797; gateway=gtps and timerec * *Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc96f88: pr 0 next 0x7f458dc97308 match_exp ^8000(.+) match_flags 0, subst_exp ^8000(.+), repl_exp \1 and attrs and timerec * *Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc97308: pr 0 next 0x7f458dc976d0 match_exp ^40011(.+) match_flags 0, subst_exp ^40011(.+), repl_exp 1\1 and attrs gateway=GTPS_VTTel and timerec * *Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc976d0: pr 0 next 0x7f458dc97a98 match_exp ^22001(.+) match_flags 0, subst_exp ^22001(.+), repl_exp 1\1 and attrs gateway=GTPS_VTTel and timerec * *Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc97a98: pr 0 next 0x7f458dc97e18 match_exp ^9000(.+) match_flags 0, subst_exp ^9000(.+), repl_exp \1 and attrs and timerec * *Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc97e18: pr 0 next 0x7f458dc98198 match_exp ^400244(.+) match_flags 0, subst_exp ^400244(.+), repl_exp 44\1 and attrs and timerec * *Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc98198: pr 65 next 0x7f458dc98568 match_exp ^12121(.+) match_flags 0, subst_exp ^12121(.+), repl_exp 1\1 and attrs user=1212; gateway=GTPS_VTTel and timerec * *Jun 25 07:46:14 [13757] DBG:dialplan:list_rule: RULE 0x7f458dc98568: pr 99 next (nil) match_exp ^30111(.+) match_flags 0, subst_exp ^30111(.+), repl_exp 1\1 and attrs and timerec * *Jun 25 07:46:14 [13757] DBG:core:db_free_columns: freeing result columns at 0x7f45a142e5a0* *Jun 25 07:46:14 [13757] DBG:core:db_free_rows: freeing 0 rows* *Jun 25 07:46:14 [13757] DBG:core:db_free_result: freeing result set at 0x7f45a13fd7d0* On Tue, Jun 23, 2020 at 12:41 AM Bogdan-Andrei Iancu wrote: > Vic, > > What is the exact opensips version you have ? (opensips -V) > > Also, please provide the log (in debug mode) generated during the reload > attempt. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > > On 6/17/20 10:01 PM, Vic Jolin wrote: > > Bogdan, > > Hi, the dialplan loads properly on start up, it just doesn't reload on > opensips-cli > > although when I do > opensips-cli -x mi dp_reload > > It returns OK > > On Thu, Jun 18, 2020 at 2:29 AM Bogdan-Andrei Iancu > wrote: > >> Hi, >> >> Do you see any errors in the logs, after reload ? >> >> Also, if you switch the DBG/4 log_level, do you see the logs for the >> reload ? >> >> Maybe your tests are not accurate enough to spot the reload. >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> >> On 6/17/20 9:18 PM, Vic Jolin wrote: >> >> Hi, >> >> I've been trying to get my dialplan to reload but Im still getting the >> old dialplan when I test. >> the old dialplan has attributes on it, but I removed it, and when I tried >> >> opensips-cli -x mi dp_reload >> >> I am still getting the old attribute. >> >> Anything else I should do or check? >> >> ___ >> 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
