Re: [OpenSIPS-Users] Issue Using avp_db_query()

2021-02-03 Thread Alain Bieuzent
Hi Mark, 

 

For me correct syntax will be :

avp_db_query("SELECT customer FROM customer_sbcs WHERE sbc1 = $avp(sbc)", 
"$avp(custID)", 1);

 

Regards

 

 

De : Users  au nom de Mark Farmer 

Répondre à : OpenSIPS users mailling list 
Date : mercredi 3 février 2021 à 18:22
À : OpenSIPS users mailling list 
Objet : [OpenSIPS-Users] Issue Using avp_db_query()

 

Hello everyone.

 

I am trying to do a database lookup using avp_db_query() and getting an error 
in my log:

 

ERROR:core:get_cmd_fixups: Variable in param [2] is not a string

ERROR:core:do_action: Failed to get fixups for command 

 

It seems the query is erroring as $rc is always -1

 

CUSTOM_LOG: DB Query Return Code: -1

 

I have a database connection setup with a numerical ID.

This is my avp_db_query() line:

 

avp_db_query("SELECT customer FROM customer_sbcs WHERE sbc1 = 
'$avp(sbc)'",$avp(custID), 1);

 

$avp(sbc) is set just before and has a valid text value that should match.

 

Is anyone able to tell me where I am going wrong please?

 

Many thanks!

Mark.

 

___ 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] Issue Using avp_db_query()

2021-02-03 Thread Mark Farmer
Hello everyone.

I am trying to do a database lookup using avp_db_query() and getting an
error in my log:

ERROR:core:get_cmd_fixups: Variable in param [2] is not a string
ERROR:core:do_action: Failed to get fixups for command 

It seems the query is erroring as $rc is always -1

CUSTOM_LOG: DB Query Return Code: -1

I have a database connection setup with a numerical ID.
This is my avp_db_query() line:

avp_db_query("SELECT customer FROM customer_sbcs WHERE sbc1 =
'$avp(sbc)'",$avp(custID), 1);

$avp(sbc) is set just before and has a valid text value that should match.

Is anyone able to tell me where I am going wrong please?

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


[OpenSIPS-Users] [BLOG] Improved series-based call statistics using OpenSIPS 3.2

2021-02-03 Thread Răzvan Crainea

Hi, everyone!

I've just published a new blog[1] that shows you how simple it is to 
compute calls statistics (ASR, ACR, PDD, NER, CCR) using the new 
statistics series available[2] in the statistics module.


Have fun using the new statistics!

[1] 
http://blog.opensips.org/2021/02/02/improved-series-based-call-statistics-using-opensips-3-2/
[2] 
https://opensips.org/docs/modules/3.2.x/statistics.html#section_stat_series


Cheers,
--
Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

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


[OpenSIPS-Users] OpenSIPS 3.1 - Mid_Registrar AOR throttling & FreePBX/Asterisk Expiry problem

2021-02-03 Thread Mark Allen
I'm seeing strange behaviour using mid_registrar with AOR throttling...

On initial registration, I do a mid_registrar_save():

mid_registrar_save("location","mp0v","sip:$tU@midreg",,"vipx");

Return value from save is "1" (success) and then I successfully forward the
REGISTER to the FreePBX/Asterisk main registrar (so far so good!).

Asterisk returns a "200 OK" to OpenSIPS which has the registration expiry
value set in both the "Expires" header and in the "Contact" header...

SIP/2.0 200 OK
Expires: 600
Contact: ;expires=600

Mid_Registrar forwards this on to the UAC after modifying the expiry value
for AOR throttling, but only the "expires" setting in the "Contact" header
gets modified...

SIP/2.0 200 OK
Expires: 600
Contact: ;expires=300

This leads to the unpredictable behaviour I'm seeing. MicoSIP seems to
prefer to use the "Contact" header expiry value, and so works fine,
however, Blink and a test MizuTech softphone seem to prefer the "Expires"
header value, and so are not using the AOR throttling value.

In the above example, Mid_Registrar is expecting the UAC to REGISTER again
before 300 seconds have elapsed to maintain the registration, but Blink or
the MizuTech softphone believe they should renew their registration before
600 seconds. When Mid_Registrar does not get the expected registration at
around 300 seconds it assumes the connection is lost and de-registers on
Asterisk. Finally, the UAC renews the registration at around 600 seconds
meaning the UAC is effectively cycling between being available/unavailable.

I have written a workaround in our config file to remove the invalid value
before the "200 OK" gets forwarded to the UAC, but should mid_registrar be
changing the expiry value in both places?
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] To-tag value in ACK

2021-02-03 Thread Donat Zenichev
Good day John,
it looks like your own deduction is absolutely right!

If we talk about the SIP protocol in terms of RFC 3261, then I guess it's
clear that the acknowledgement which has a To tag,
which is different from the previously defined one (in 200 OK) of the same
dialog, should be essentially considered as out of the dialog request.
Which will not be correlated with the dialog is being established (the one
in the early stage you are talking about).

So that, it's known - "Call-ID" + "To tag" + "From tag" gives us a full
uniqueness of certain dialog/call branch (in your case it looks like it's
only one branch though).
If you change at least a To tag in the subsequent request (in-dialog
request) for the same dialog/call branch,
then the remote side will likely fail to match it to a needed dialog
(transaction check).

Please see this section of RFC 3261 to understand the concept:
https://tools.ietf.org/html/rfc3261#section-19.3

I hope I was clear enough and you find my response useful.
Have a nice day!

On Tue, Feb 2, 2021 at 6:50 PM John Quick  wrote:

> Johan,
> Thanks for your comment, but in this instance the problem is something
> very subtle.
> OpenSIPS is acting as a Proxy, not as an endpoint. So the Contact header
> in the ACK contains the address of the UAC.
> OpenSIPS identified itself earlier in the dialog using the correct FQDN in
> the topmost Record-Route header of the INVITE request and using TLS with a
> certificate whose subject name matches the FQDN.
>
> Like I said, I have been able to put this ACK side-by-side with the ACK in
> a similar case where the call works correctly.
> Doing an A-B comparison, the only obvious difference I could identify was
> in the order of the headers.
> For example, the Route header is before the Via headers in one case and
> after in the other. I don't believe this is important.
>
> So then I looked at values in the 200 OK to see if they were the same in
> the ACK:
> The R-URI in the ACK is the same as the Contact in the 200 OK, including
> parameters.
> The From tag is identical in both
> The To tag in the ACK is not the same as the To tag in the 200 OK, but in
> my sip trace for a call that worked okay, the To tag did not get changed.
>
> My question is about the To tag. Should it be the same in the ACK as it
> was in the 200 OK?
>
> John Quick
> Smartvox Limited
> Tel:  +44-1727-221221
>
>
> > From: Johan De Clercq 
> > Sent: 02 February 2021 14:42
> > To: John Q ; OpenSIPS users mailling list <
> users@lists.opensips.org>
> > Subject: Re: [OpenSIPS-Users] To-tag value in ACK
> >
> > is contact an fqdn ?
> > If not, look no further.
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 

Best regards,
Donat Zenichev
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] avps in onreply_route

2021-02-03 Thread Fabian Gast

Hi,

On 2021-02-03 10:11, Liviu Chircu wrote:

On 03.02.2021 11:09, Fabian Gast wrote:
The second one works, but not the first one, which should be the same 
and i don't get why.


( Talking about Opensips 2.4.x )


Hi,

Per the documentation [1], the global onreply_route is stateless
(unrelated to the SIP transaction, you're just viewing a SIP message),
while the other one is stateful (the SIP transaction has been matched,
and your request-bound AVPs are now available as well).

[1]: https://www.opensips.org/Documentation/Script-Routes-3-2#toc4


Thanks for the hint!

Fabian

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


Re: [OpenSIPS-Users] avps in onreply_route

2021-02-03 Thread Liviu Chircu

On 03.02.2021 11:09, Fabian Gast wrote:
The second one works, but not the first one, which should be the same 
and i don't get why.


( Talking about Opensips 2.4.x )


Hi,

Per the documentation [1], the global onreply_route is stateless 
(unrelated to the SIP transaction, you're just viewing a SIP message), 
while the other one is stateful (the SIP transaction has been matched, 
and your request-bound AVPs are now available as well).


[1]: https://www.opensips.org/Documentation/Script-Routes-3-2#toc4

--
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


[OpenSIPS-Users] avps in onreply_route

2021-02-03 Thread Fabian Gast

Hello @all,
maybe you could help me to understand the behaviour of avps in 
onreply_routes.


I have to configs:
a)
modparam("tm", "onreply_avp_mode", 1)
route {
$avp(aa) = 1;
t_relay();
}

onreply_route {
xlog("$avp(aa)\n");  # avp NOT set!
}

b)
modparam("tm", "onreply_avp_mode", 1)
route {
t_on_reply("1");
$avp(aa) = 1;
t_relay()
}

onreply_route[1] {
xlog("$avp(aa)\n"); # avp set!
}

The second one works, but not the first one, which should be the same 
and i don't get why.


( Talking about Opensips 2.4.x )

Thanks!

Fabian

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